Security Scanning for Websites and GitHub Repositories

AURIX SHIELD Scan is the security scanning workflow used to analyze websites and GitHub repositories for security issues. A scan combines specialized security engines, processes their results, and converts relevant detections into persistent AURIX SHIELD security findings. The scan workflow is designed to answer a simple question:

What security issues exist in the target right now?

From there, AURIX SHIELD can track those findings through investigation, remediation, verification, and monitoring. Use the Scan workspace to start or review security scans from the authenticated AURIX SHIELD dashboard. A security scan is an analysis performed against a configured security target.

AURIX SHIELD supports two primary scanning environments:

• Website Security
• GitHub Security

The scanning process is different for each environment because websites and source repositories require different analysis techniques. The results from both environments are brought into the AURIX SHIELD security finding model.

Website Security Scans

Website scans analyze web applications and publicly reachable website targets. The Website Security Engine combines:

• Katana
• httpx
• Nuclei
• OWASP ZAP

Each engine performs a different stage or type of analysis. The combined pipeline provides a broader view of the target than relying on a single scanning technique.

Website Scan Pipeline

A website scan can be understood as: Target → Crawl → HTTP Probe → Security Detection → Result Processing → Finding Comparison

Target

The configured website target becomes the starting point for the scan.

Crawl

Katana discovers URLs and application endpoints that can be analyzed.

HTTP Probe

httpx validates and analyzes discovered HTTP targets.

Security Detection

Nuclei and OWASP ZAP perform security analysis using their respective detection approaches.

Result Processing

Scanner output is processed into the AURIX SHIELD security model.

Finding Comparison

The current scan is compared with existing security findings to determine how the security state has changed.

Website Scan Engines

GitHub Security Scans

GitHub scans analyze source repositories using specialized repository security engines. AURIX SHIELD currently uses:

• CodeQL
• Gitleaks
• Trivy
• OSV-Scanner
• AURIX Custom

Each engine focuses on a different security area. A GitHub scan can be understood as: Repository → Engine Analysis → Result Collection → Normalization → Finding Persistence The repository is analyzed by the configured engines. Their results are collected and normalized into the AURIX SHIELD security finding model.

This allows findings from different scanners to be viewed through the same platform.

GitHub Scan Engines

Scan Results

A completed scan can produce: For GitHub scans, the Scan Overview can show results from: This gives users a unified view of the repository scan. The Scan Overview provides a consolidated view of a completed scan. Depending on the scan type, it can contain:

• Target or repository information
• Scan status
• Security findings
• Finding counts
• Top findings
• Scanner engine results

For GitHub scans, repository information and engine-specific results are included in the unified Scan Overview. The purpose is to let users understand the outcome of a scan without having to inspect every scanner separately.

Finding Counts

AURIX SHIELD uses persistent security findings rather than treating every scan as an isolated event. During scan comparison, the system can distinguish changes such as:

• NEW
• EXISTING
• REAPPEARED
• RESOLVED
• CHANGED

These states describe how the current scan relates to previously known findings. A finding appearing again after previously being resolved can therefore be treated differently from a completely new finding.

Severity in Scan Results

Security findings are organized using the AURIX SHIELD severity hierarchy: Unknown severity values are handled separately rather than silently being assigned to a known severity. This ordering is also used when presenting findings and overview information.

Scan History

AURIX SHIELD maintains scan-related information so users can understand security activity over time. Historical scan information can help users compare security states and investigate changes in findings. Pro additionally includes broader monitoring and scan-history capabilities as part of the continuous protection workflow.

See the Pricing documentation for the current Free and Pro plan differences.

Scan and Security Findings

A scan produces detection results. AURIX SHIELD then converts relevant detections into persistent security findings. This distinction is important. A scanner result represents what an engine detected during a particular scan. A security finding represents an issue that AURIX SHIELD can continue tracking across scans. The relationship is:

Scan → Detection → Finding → Tracking

Scan and Fix & Verify

A scan identifies security issues. Fix & Verify provides the remediation and verification workflow around those issues. The overall lifecycle is: Detect → Explain → Fix → Verify A finding should not be considered fixed simply because a user has taken a remediation action.

The appropriate verification workflow determines whether the original detection remains present. See the Fix documentation for the complete remediation workflow.

Scan and Monitor

A manual or on-demand scan represents a point-in-time security analysis. Monitoring extends security visibility beyond an individual scan. Pro includes continuous monitoring and automated scheduled scans so the security state can continue to be checked as the product changes.

See the Monitor documentation for the monitoring workflow.

Scan and Ask AURIX

Scan findings can provide context for Ask AURIX. AURIX AI can use security information such as:

• Finding
• Scanner
• Repository
• File
• Evidence
• Severity

This allows users to ask questions about the results of their security scans. See the AURIX AI documentation for more information.

Scan Does Not Mean Complete Security

A successful scan does not guarantee that a target contains no vulnerabilities. Detection depends on:

• Scanner coverage
• Detection rules
• Target accessibility
• Repository contents
• Programming language support
• Dependency information
• Application behavior
• Individual engine limitations

AURIX SHIELD combines multiple security engines to provide broader security visibility, but no security scanning system can guarantee detection of every possible security issue. The scan is the detection stage of the broader AURIX SHIELD security lifecycle. The broader AURIX SHIELD lifecycle can be represented as:

Scan → Findings → Explain → Fix → Verify → Monitor

Scan

Detect security issues.

Findings

Persist and organize detected security issues.

Explain

Understand what was detected and why it matters.

Fix

Take appropriate remediation action.

Verify

Check whether the original detection remains present.

Monitor

Continue watching the security state over time.

When to Run a Scan

A scan can be useful when:

• A website is being tested for security issues.
• A repository needs security analysis.
• New code or dependencies have been introduced.
• A security issue needs to be investigated.
• A previous finding needs to be checked again.
• A user wants a current security snapshot.

For ongoing security changes, Pro's monitoring and scheduled scanning capabilities extend beyond individual manual scans.

Frequently Asked Questions

Explore AURIX SHIELD

• Product Documentation
• Security Engine
• AURIX AI
• GitHub Security
• Pricing
• Monitor
• Fix
• Ask AURIX