AI-Powered Security Scanning for Websites, Software, and GitHub Repositories

AURIX SHIELD Security Engine is the scanning layer that powers security detection across websites and GitHub repositories. It combines multiple specialized security engines with AURIX Custom detection to identify security issues, normalize their results, preserve finding identity, and feed verified findings into the AURIX SHIELD security lifecycle.

The Security Engine is designed around a simple principle:

Detect security issues with specialized engines, explain what was found, verify the result, and continuously track the security state.

The AURIX SHIELD Security Engine is the core detection system behind the platform. It supports two primary scanning environments:

• Website Security
• GitHub Security

Each environment uses engines appropriate to the type of target being analyzed. For websites, AURIX SHIELD combines crawling, HTTP probing, template-based vulnerability detection, and dynamic application security testing.

For GitHub repositories, AURIX SHIELD analyzes source code, dependencies, secrets, configuration, and repository content using specialized security engines. The resulting detections are converted into persistent security findings that can be investigated, verified, monitored, and managed from the AURIX SHIELD dashboard.

Security Engine Architecture

AURIX SHIELD does not depend on a single scanner. Instead, the platform uses multiple specialized engines because different security problems require different detection techniques. The architecture can be understood as: Target → Scanner Engines → Normalization → Finding Identity → Verification → Security Dashboard

This allows each engine to focus on the type of analysis it performs best while AURIX SHIELD provides the common security workflow around those results.

Website Security Engine

The Website Security Engine is designed to analyze web applications and publicly reachable websites. It combines four major components:

• Katana
• httpx
• Nuclei
• OWASP ZAP

Each component performs a different part of the website security analysis. Katana is used for web crawling and endpoint discovery. The crawler helps AURIX SHIELD discover URLs and application paths that can be analyzed during a scan.

The discovered endpoints provide the Security Engine with a broader view of the target instead of relying only on a single starting URL. The resulting crawl data can then be passed into subsequent security analysis stages.

httpx

httpx is used for HTTP probing and target validation. It helps determine which discovered endpoints are reachable and provides HTTP-level information that can be used by the scanning pipeline. This creates a practical transition between endpoint discovery and deeper security analysis.

Nuclei

Nuclei performs template-based security detection. AURIX SHIELD uses Nuclei to evaluate web targets against security detection templates covering different classes of vulnerabilities and exposures.

Nuclei findings are converted into the AURIX SHIELD finding model so they can be displayed and managed consistently with findings from other security engines. The Nuclei engine is therefore one part of the broader Website Security Engine rather than the entire security system.

OWASP ZAP

OWASP ZAP provides dynamic web application security testing. ZAP can interact with the target application and perform security analysis that complements endpoint discovery and template-based detection. AURIX SHIELD integrates ZAP as a dedicated scanning stage within the website scanning pipeline.

The results are processed alongside the other website security engines.

Website Scanning Flow

A typical website scan follows a staged process: Target → Crawl → HTTP Probe → Security Detection → Result Processing → Finding Comparison The scanner can:

• Discover application endpoints.
• Validate reachable HTTP targets.
• Run template-based security detection.
• Perform dynamic application security testing.
• Process scanner results.
• Compare results against existing findings.
• Identify new, existing, changed, reappeared, or resolved findings where applicable.
• Persist the resulting security state.

This allows AURIX SHIELD to track security findings across repeated scans instead of treating every scan as an isolated event. The GitHub Security Engine is designed for analyzing source repositories. It uses multiple specialized security engines:

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

Each engine focuses on a different security signal. Together they provide broader repository security coverage than a single scanning technique.

CodeQL

CodeQL performs code analysis against supported programming languages. AURIX SHIELD currently uses CodeQL for:

• JavaScript
• TypeScript
• Python
• Go

The GitHub scanner creates a CodeQL analysis database outside the repository workspace and runs the configured CodeQL security query suite against the repository. CodeQL results are processed from SARIF output and converted into AURIX SHIELD security findings.

CodeQL is particularly useful for identifying security issues that require understanding relationships between source-code elements rather than simply matching individual strings or files.

Gitleaks

Gitleaks analyzes repositories for exposed secrets and credentials. It is used to detect potential sensitive information such as credentials, API keys, tokens, and other secret-like patterns. AURIX SHIELD processes Gitleaks results into persistent findings so detected secrets can be investigated and subsequently verified.

Gitleaks is especially focused on secret exposure, rather than general application vulnerabilities.

Trivy

Trivy provides repository and filesystem security analysis. Within the GitHub Security Engine, Trivy can identify security issues associated with repository content and dependencies. Its results are normalized into the AURIX SHIELD finding system alongside the results from CodeQL, Gitleaks, OSV-Scanner, and AURIX Custom.

OSV-Scanner

OSV-Scanner focuses on known vulnerabilities in open-source dependencies. It analyzes dependency information and matches packages against the OSV vulnerability database. This allows AURIX SHIELD to identify known vulnerabilities associated with project dependencies.

OSV-Scanner therefore complements source-code analysis by focusing on the security state of third-party packages.

AURIX Custom

AURIX Custom is the platform's custom detection layer. It allows AURIX SHIELD to detect security conditions that are not necessarily covered by the external security engines. AURIX Custom findings use the same persistent finding model as other scanner results. This means custom detections can participate in the same:

• Detect
• Explain
• Fix
• Verify
• Monitor

workflow.

Why Multiple Security Engines?

No single security scanner is designed to detect every type of security issue. A source-code analyzer, dependency scanner, secret scanner, web crawler, and dynamic application scanner all examine security from different perspectives.

AURIX SHIELD therefore combines specialized engines rather than treating one scanner as the complete security solution. For example:

These engines operate as components of the AURIX SHIELD Security Engine. Different scanners produce different output formats. AURIX SHIELD converts scanner-specific results into a common finding model. This provides a consistent structure for security findings across the platform. A normalized finding can contain information such as:

• Finding identity
• Severity
• Scanner engine
• Rule or detection identifier
• Target
• Repository
• File
• Location
• Evidence
• Status
• Verification state

This common structure allows findings from different engines to appear consistently throughout the dashboard. Finding identity is important because repeated scans should not create an entirely new finding every time the same security issue is detected.

AURIX SHIELD uses deterministic finding identity and fingerprints to associate detections with existing security findings. This enables the platform to distinguish between security states such as:

• New findings
• Existing findings
• Reappeared findings
• Resolved findings
• Changed findings

The exact identity depends on the scanner and the context of the detection. For GitHub findings, identity can be scoped using repository and user context together with the finding fingerprint. This helps prevent unrelated repositories or users from accidentally sharing the same finding state.

Severity

AURIX SHIELD organizes security findings using severity levels: Unknown or unsupported severity values are handled separately rather than being silently treated as a known severity. This ordering is used consistently when displaying security findings and overview data.

Security Finding Lifecycle

AURIX SHIELD treats a security finding as part of a lifecycle rather than simply a scanner result. The broader product lifecycle is:

• Detect
• Explain
• Fix
• Verify
• Monitor

Detect

A security engine identifies a potential security issue. The finding is presented with relevant information such as its source, scanner, location, evidence, and security context. The user can investigate the issue and take appropriate remediation action.

AURIX SHIELD can perform verification against the relevant target to determine whether the original issue is still detected. The platform can continue tracking monitored targets and their security state over time. Verification is an important distinction between a scanner result and a security state.

AURIX SHIELD supports targeted verification for GitHub findings. The verification process uses the original finding context and scanner engine to perform an appropriate follow-up analysis. Different engines use different verification strategies. For example:

• AURIX Custom can perform targeted rule-based verification.
• Gitleaks can perform file-local verification.
• OSV-Scanner can verify dependency or lockfile-related findings.
• Trivy can perform filesystem verification.
• CodeQL requires repository-wide analysis.

The verification result can indicate: A verification result is therefore based on a follow-up scan rather than simply changing a finding status manually. CodeQL findings require repository-wide analysis for authoritative verification.

This is different from file-local verification because CodeQL findings can depend on relationships between multiple parts of a codebase. For this reason, AURIX SHIELD uses repository-wide CodeQL analysis when verifying CodeQL findings. The verification process then evaluates whether the original detection is still present.

Targeted Verification

For engines that support targeted verification, AURIX SHIELD can preserve the original detection context and perform a focused follow-up check. The verification request contains the relevant finding identity and scanner context.

This allows the system to verify the original detection instead of treating any unrelated clean scan as proof that the finding was fixed.

Scanner Results vs. Security Findings

A scanner result and a persistent security finding are related but not identical. A scanner produces detections during a scan. AURIX SHIELD then processes those detections into persistent findings. This distinction allows the platform to track a security issue across multiple scans. For example:

• Scan 1 → Finding detected
• Scan 2 → Same finding detected → Existing finding
• Later scan → Finding no longer detected → Potentially resolved
• Future scan → Finding detected again → Reappeared

This persistent model is important for monitoring security over time. A GitHub security scan can be understood as: Repository → Engine Analysis → Result Collection → Normalization → Finding Persistence The repository is analyzed by the configured engines. The results are then collected and processed into the AURIX SHIELD security model.

The resulting findings can appear in:

• GitHub Security
• Scan Overview
• Findings
• Fix
• Ask AURIX

This creates a connected workflow rather than separate scanner-specific pages. The Scan Overview provides a unified view of a completed scan. For GitHub scans, the overview can include:

• Repository information
• Scan status
• Engine results
• Finding counts
• Top findings
• Security findings generated by the scan

The supported GitHub security engines represented in the scan overview include: This gives users a single place to understand what the scan discovered. Security findings generated by the Security Engine can also provide context for Ask AURIX. Ask AURIX can use finding information such as:

• Repository
• File
• Scanner
• Finding
• Security evidence

This allows users to ask questions about findings without manually reconstructing the scanner context. Ask AURIX is an analysis and explanation layer around security data; it does not automatically commit code changes to a repository.

Security Engine and Fix & Verify

The Security Engine provides the detection information that powers Fix & Verify. A finding identifies what was detected. The Fix workflow provides the remediation context. Verification then checks whether the original detection remains present. This creates a closed security workflow: Detection → Remediation → Verification

rather than simply marking findings as resolved based on user action.

Security Engine and Monitor

Monitoring extends the scanning lifecycle beyond a single scan. A monitored target can continue to be tracked for changes in its security state. The monitoring system maintains the target's monitoring state and can trigger future scanning according to the configured monitoring workflow.

This allows AURIX SHIELD to move from one-time security testing toward continuous security visibility.

What the Security Engine Does Not Guarantee

AURIX SHIELD Security Engine is designed to detect security issues using the implemented scanning engines and detection methods. However, no security scanner can guarantee detection of every possible vulnerability. Results depend on factors such as:

• Target accessibility
• Repository contents
• Scanner coverage
• Detection rules
• Dependency information
• Programming language support
• Application behavior
• Configuration
• The limitations of individual security engines

AURIX SHIELD should therefore be understood as a security detection and monitoring platform, not as a guarantee that a target contains no security vulnerabilities.

Security Engine Terminology

Scanner Engine

A specialized security analysis component such as CodeQL, Gitleaks, Trivy, OSV-Scanner, Nuclei, or OWASP ZAP.

Finding

A persistent security issue identified and tracked by AURIX SHIELD.

Fingerprint

A deterministic identifier used to associate detections with a security finding.

Verification

A follow-up security analysis used to determine whether an original finding remains detected.

Targeted Verification

A verification method focused on the original finding context where supported.

Repository-Wide Verification

A verification process that analyzes the entire repository, such as the approach required for CodeQL findings.

Security Engine

The combined scanning and detection infrastructure responsible for analyzing targets and producing security findings.

Frequently Asked Questions

Explore AURIX SHIELD

Learn how the Security Engine fits into the complete AURIX SHIELD platform:

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