GitHub Security for Source Code, Dependencies, Secrets, and Repository Risk

AURIX SHIELD GitHub Security analyzes repositories using multiple specialized security engines to identify security issues across source code, dependencies, secrets, repository files, and custom security conditions. Instead of relying on a single scanner, AURIX SHIELD combines:

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

The resulting detections are normalized into persistent security findings that can be investigated, verified, and monitored through the AURIX SHIELD platform. The GitHub Security workflow is built around: Repository → Scan → Findings → Investigate → Fix → Verify → Monitor

GitHub Security is the repository security environment inside AURIX SHIELD. It allows a repository to be analyzed by multiple security engines and brings their results into a unified security workflow.

The system is designed to identify different categories of security issues rather than treating repository security as a single problem. Depending on the engine, analysis can include:

• Source-code security
• Exposed secrets
• Dependency vulnerabilities
• Repository and filesystem security
• Custom security detections

The resulting findings are persisted so that security issues can be tracked across scans. A GitHub security scan follows a staged process: Repository → Engine Analysis → Result Collection → Normalization → Finding Persistence

1. Repository

The repository is provided as the target for security analysis. The configured security engines analyze the repository using their specialized detection methods. Results from the individual engines are collected by the GitHub scanning pipeline. Scanner-specific output is converted into the AURIX SHIELD finding model.

The resulting findings are stored as persistent security findings that can be viewed and managed throughout the platform. AURIX SHIELD currently uses five security engines for GitHub repository analysis: Each engine produces a different type of security signal. CodeQL performs source-code security analysis. 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 security query suite against the repository. CodeQL results are collected as SARIF output and converted into AURIX SHIELD security findings.

CodeQL is particularly useful for security issues that require understanding relationships between different parts of a codebase.

Gitleaks

Gitleaks focuses on exposed secrets and credentials. It can identify potential sensitive information such as:

• API keys
• Access tokens
• Credentials
• Other secret-like values

Gitleaks results are converted into persistent AURIX SHIELD findings. This allows a detected secret to remain connected to the broader finding lifecycle instead of existing only as a temporary scanner result.

Trivy

Trivy provides repository and filesystem security analysis. Within GitHub Security, Trivy can identify security issues associated with repository content and dependencies. Its results are normalized into the same AURIX SHIELD finding model used by the other GitHub security engines.

This allows Trivy findings to participate in the same investigation, Fix & Verify, and monitoring workflow.

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 affecting project dependencies.

OSV-Scanner therefore provides dependency-focused security analysis that complements source-code analysis from CodeQL.

AURIX Custom

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

• Detect
• Explain
• Fix
• Verify
• Monitor

lifecycle.

Why Multiple GitHub Security Engines?

Different security problems require different detection techniques. For example:

• CodeQL analyzes source-code relationships.
• Gitleaks focuses on exposed secrets.
• OSV-Scanner focuses on known dependency vulnerabilities.
• Trivy analyzes repository and filesystem security.
• AURIX Custom provides platform-specific detection.

Using multiple engines allows AURIX SHIELD to analyze repository security from several complementary perspectives. No individual engine should be treated as complete coverage of every possible security issue.

GitHub Scan Results

After the engines complete their analysis, AURIX SHIELD processes their results into the unified security model. A completed scan can contain results from:

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

Each engine can report its own result state and findings. The platform then presents the combined security state through the GitHub Security experience and Scan Overview.

Scan Overview

The GitHub Scan Overview provides a unified view of a completed repository scan. It can include:

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

The overview allows users to understand the result of a repository scan without having to inspect each scanner independently. A scanner result is not the same as a persistent security finding. A scanner produces detections during a scan. AURIX SHIELD converts those detections into persistent findings.

This allows the platform to track a security issue across multiple scans. For example:

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

This persistent model provides continuity between scans. AURIX SHIELD uses deterministic finding identity and fingerprints to associate repeated detections with existing findings. For GitHub findings, identity is scoped using the relevant user, repository, and finding fingerprint context.

This helps prevent findings from unrelated repositories or users from being incorrectly treated as the same security issue. Finding identity is important for:

• Deduplication
• Persistent tracking
• Verification
• Resolution
• Reappearance detection

Security Finding Information

A GitHub security finding can contain information such as: This context is used throughout the AURIX SHIELD security workflow. GitHub security findings use the AURIX SHIELD severity hierarchy: Unknown or unsupported severity values are handled separately rather than silently being converted into a known severity.

The same severity ordering is used when presenting findings and overview information.

GitHub Security Findings

The GitHub Security findings interface provides a persistent view of repository security findings. Instead of displaying only the latest raw scanner output, the system works with persistent findings. This allows users to investigate security issues and follow their state across scans. Findings can be associated with their:

• Repository
• File
• Scanner
• Rule
• Evidence
• Severity

This context helps users understand where a security issue originated. A GitHub finding can be investigated using its available security context. Important investigation information can include:

• What was detected
• Which scanner detected it
• Which repository contains it
• Which file is involved
• Which rule or detection produced it
• What evidence was collected
• What its current verification state is

This information also provides context for Ask AURIX. AURIX AI can work with GitHub security findings. Ask AURIX can use context such as:

• Repository
• File
• Scanner
• Finding
• Evidence
• Rule identifier

This allows users to ask questions about repository security without manually reconstructing the relevant scanner context. Ask AURIX provides the conversational intelligence layer. The GitHub Security Engine remains responsible for security detection.

GitHub Security and Fix & Verify

GitHub Security provides the detection and finding context used by Fix & Verify. The workflow is: Finding → Fix → Verification A user can investigate a finding and then use the verification workflow to determine whether the original detection remains present. Verification is performed against the relevant repository and scanner context.

A finding should not be considered verified as fixed simply because a user has taken a remediation action.

GitHub Finding Verification

AURIX SHIELD supports engine-specific verification for GitHub findings. The verification method depends on the scanner that originally produced the finding. Supported verification approaches include:

• AURIX Custom → targeted rule-based verification
• Gitleaks → file-local verification
• OSV-Scanner → dependency or lockfile verification
• Trivy → filesystem verification
• CodeQL → repository-wide CodeQL analysis

This allows verification to remain connected to the original detection. CodeQL findings require repository-wide analysis for authoritative verification. A CodeQL security issue can depend on relationships between multiple parts of a repository.

For this reason, AURIX SHIELD does not treat a file-local check as sufficient verification for a CodeQL finding. Instead, the repository is analyzed again using CodeQL. The resulting analysis is then evaluated against the original finding.

Targeted Verification

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

This helps the system verify the original detection rather than treating an unrelated clean scan as evidence that the issue was fixed.

Verification Results

GitHub finding verification can produce results such as: These results distinguish an actual verification outcome from a simple manual status change. Verification and finding status are related but different concepts. A finding can exist as persistent security data while a verification process determines whether its original detection remains present.

The verification result provides evidence for the security state. This prevents the system from treating a user action alone as proof that a security issue has been fixed.

GitHub Security and Monitoring

Monitoring extends repository security beyond a single scan. A monitored target can continue to be tracked for changes in its security state. The monitoring workflow can use the existing GitHub scanning infrastructure to identify changes in security findings over time.

This allows AURIX SHIELD to provide ongoing security visibility instead of relying only on manual scans.

Security Boundaries

GitHub security data is tied to the authenticated user's security context. AURIX SHIELD performs authentication and ownership checks when retrieving GitHub security information. This is important because repository findings must remain associated with the correct authorized user and repository.

The same security boundaries also apply when GitHub findings are provided as context to Ask AURIX.

What GitHub Security Does Not Guarantee

AURIX SHIELD GitHub Security is designed to detect security issues using the implemented security engines and detection methods. It does not guarantee detection of every possible vulnerability. Results depend on factors including:

• Repository contents
• Programming language support
• Dependency information
• Detection rules
• Scanner coverage
• Repository configuration
• The limitations of individual security engines

GitHub Security should therefore be understood as a multi-engine security detection and monitoring system, not as a guarantee that a repository contains no vulnerabilities.

GitHub Security Terminology

GitHub Security

The repository security environment within AURIX SHIELD.

Repository Scan

A security analysis performed against a GitHub repository.

Security Engine

A specialized scanner used to analyze repository security.

Finding

A persistent security issue identified and tracked by AURIX SHIELD.

Fingerprint

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

Verification

A follow-up analysis used to determine whether the original detection remains present.

Targeted Verification

A focused verification method used by supported security engines.

Repository-Wide Verification

Verification that analyzes the entire repository, as required for CodeQL findings.

Frequently Asked Questions

Explore AURIX SHIELD

Learn how GitHub Security connects with the rest of AURIX SHIELD:

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