Investigate, Fix, and Verify Security Findings

AURIX SHIELD Fix & Verify connects security findings with remediation guidance and scanner-based verification. Detecting a vulnerability is only the beginning of a security workflow. After investigating a finding and applying an appropriate fix, users need a way to check whether the original security issue is still detectable.

Fix & Verify provides this workflow for website and GitHub security findings. Finding → Investigate → Apply Fix → Verify → Review Result

Open Fix & Verify

Access the authenticated AURIX SHIELD Fix workspace to review findings, investigate remediation guidance, and initiate supported verification workflows. Fix & Verify is the remediation and verification workspace within AURIX SHIELD. It connects findings produced by the Security Engine with the actions users take to address them.

Its two principal functions are:

Fix:

Understand a finding and determine the appropriate remediation.

Verify:

Run the appropriate security check to determine whether the original detection remains present.

A recommendation to fix a vulnerability is not proof that the vulnerability has been fixed. Verification provides the follow-up evidence needed to evaluate the result. The Fix workspace has two distinct sections: Both sections are available within the unified Fix workspace.

Their verification methods differ because a website vulnerability and a source-code finding may require different types of analysis.

The Fix & Verify Workflow

1. Detect

A security engine identifies an issue.

2. Investigate

Review the finding, evidence, scanner, and affected target.

3. Fix

Apply the appropriate remediation to the website or repository.

4. Verify

Recheck the original detection using the applicable verification method.

5. Review

Inspect the verification outcome and updated finding state.

Finding Investigation

Before applying a fix, users can inspect the security information associated with a finding. Depending on the finding type, this can include its severity, scanner engine, detection rule, affected website or repository, file location, evidence, current status, and verification history.

This information helps connect remediation to the actual detection rather than a generic description of a vulnerability.

Fix Guidance

Fix guidance helps users understand possible remediation steps for a security issue. For example, guidance may explain why a detected configuration, exposed secret, vulnerable dependency, or source-code pattern requires attention.

The user remains responsible for reviewing and applying appropriate changes to the affected website, application, configuration, or repository. Fix guidance does not automatically modify or deploy the user's application.

Website Fix

Website Fix works with findings produced by the website scanning pipeline. These findings may originate from Nuclei, OWASP ZAP, or other applicable detection results processed by AURIX SHIELD.

A website remediation might involve changing an application configuration, updating vulnerable software, correcting application behavior, or deploying a code change. After remediation, the appropriate verification workflow checks whether the original website security issue remains detectable.

The exact verification behavior depends on the finding and the supported website verification method.

GitHub Fix

GitHub Fix works with persistent security findings associated with repositories. Its finding context can include:

• Repository and file
• Scanner engine
• Detection rule
• Finding fingerprint
• Security evidence
• Current finding status

GitHub verification is associated with the original finding and its scanner engine. AURIX SHIELD does not use a single generic verification method for every GitHub finding.

GitHub Engine-Specific Verification

Different scanners require different verification approaches. AURIX Custom supports targeted verification of the original custom detection. The relevant detection rule and finding context are used to perform the follow-up check.

Gitleaks

Gitleaks supports file-local verification of the original secret detection. The verification focuses on the relevant file and original finding context.

OSV-Scanner

OSV-Scanner verification uses the relevant dependency or lockfile context to check whether the original vulnerability remains detectable. Trivy uses filesystem security analysis for verification. The result is evaluated against the original finding rather than treating every unrelated scanner result as evidence of remediation.

CodeQL

CodeQL requires repository-wide analysis for authoritative verification. A source-code security issue can depend on relationships between multiple files and functions. A local check of a single file is therefore not sufficient for every CodeQL finding. AURIX SHIELD reruns CodeQL analysis and evaluates the result against the original finding.

Targeted Verification

Targeted verification is designed to check the original security issue. A GitHub verification request preserves the relevant finding identity, scanner, and detection context. For supported engines, the verification worker performs a focused analysis rather than requiring every available repository scanner to run again.

CodeQL is an important exception: its verification requires repository-wide analysis.

Verification Results

AURIX SHIELD distinguishes four GitHub verification outcomes. Changing a finding's status and verifying a finding are different actions. AURIX SHIELD's GitHub verification workflow checks the result of the appropriate scanner before automatically resolving a finding.

A finding is not automatically considered fixed merely because a user clicked Verify or reported that remediation was completed. If verification fails, remains inconclusive, or detects the original issue again, the system must not represent that outcome as a verified fix.

Missing Files During GitHub Verification

A previously affected file may no longer exist after a repository change. For supported targeted verification, AURIX SHIELD handles the missing-file condition as part of the verification workflow.

If the relevant verification completes successfully and the original detection is no longer present, the result can be VERIFIED_FIXED. A missing file does not justify declaring an unrelated scanner failure to be a successful verification.

Verification Failures

Verification depends on successful execution of the appropriate security engine. An engine crash, timeout, or unsuccessful analysis must not be interpreted as a clean security result. Verification failed ≠ Vulnerability fixed. Users should inspect the failure and repeat verification when the underlying problem has been addressed.

Verification Summary

The GitHub verification interface can present information including: These details help users understand which finding was checked, how it was checked, and what the result means. GitHub findings use deterministic fingerprints and repository context to identify the original detection.

Verification is scoped to the relevant authenticated user, repository, and finding fingerprint. AURIX SHIELD performs authentication and ownership checks before carrying out the relevant finding operations. This prevents an unrelated repository or another user's finding from being treated as the verification target.

Fix & Verify and Ask AURIX

Ask AURIX can help users investigate the security context of a finding. For supported website and GitHub findings, this context can include the scanner, evidence, severity, repository, and file information where applicable.

Ask AURIX provides explanation and investigation assistance. Fix & Verify provides the workflow for checking whether the original detection remains present. AI-generated explanations are not verification results.

Fix & Verify and Monitor

Fix & Verify evaluates remediation of a specific finding. Monitor tracks security changes over time through scheduled scanning and finding comparison. Together, they support a continuing workflow: Detect → Fix → Verify → Monitor → Detect Changes

A finding that was previously resolved may be detected again during a later scan. AURIX SHIELD's persistent finding model supports reappearance tracking.

Free and Pro

AURIX SHIELD's current pricing structure distinguishes basic and full Fix & Verify capabilities. The exact availability and usage limits are governed by the current plan configuration.

See Pricing Documentation or View Pricing & Plans for the current plan comparison.

What Fix & Verify Does Not Do

• Fix & Verify does not guarantee that every vulnerability can be detected or remediated.
• It does not automatically commit changes to a GitHub repository.
• It does not automatically deploy fixes to a website.
• It does not treat an unsuccessful scanner execution as evidence that a vulnerability is resolved.
• It does not replace the need to review security findings or apply appropriate remediation.

A successful verification concerns the original detection and applicable verification method. It is not a guarantee that the entire application or repository is secure.

Fix & Verify Terminology

Fix Guidance:

Information that helps users understand and remediate a security finding.

Finding Fingerprint:

A deterministic identifier used to associate a detection with its persistent finding.

Targeted Verification:

A focused follow-up security check of the original detection.

Repository-Wide Verification:

Analysis of the entire repository, required for CodeQL verification.

Verified Fixed:

A successful verification outcome indicating that the original detection is no longer present under the applicable check.

Still Detected:

A successful verification that confirms the original detection remains present.

Verification Failed:

An unsuccessful verification execution that cannot establish a valid remediation result.

Verification Inconclusive:

A verification outcome that does not provide sufficient evidence to establish whether the finding is fixed.

Frequently Asked Questions

Explore AURIX SHIELD

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