DAST-to-SAST Correlation

DAST findings confirm that a vulnerability is exploitable in your live application — but they rarely tell you where in the code the problem lives or who introduced it. That gap forces developers into hours or days of manual root cause investigation, while the vulnerable application remains in production.

DAST-to-SAST Correlation closes that gap. Invicti ASPM connects each DAST finding to the exact source code locations responsible for it, mapping one runtime vulnerability to the specific SAST findings across the call chain. Teams can see the exploitability proof from DAST alongside the precise file, line, and developer context from SAST — in a single view.

How It Works

After each SAST scan, Invicti ASPM analyzes your connected code repositories to detect the API endpoints that depend on the scanned source code and builds a dependency graph for each one. DAST findings are then mapped against these endpoints, producing a correlation between runtime vulnerabilities and their source code context.

The result is a one-to-many correlation: one DAST finding linked to the relevant SAST findings across the dependency chain. This tells you not just that an endpoint is vulnerable, but which code is involved and who owns it.

Runtime Exposure

The Runtime Exposure view is where DAST-to-SAST Correlation surfaces in the product. It gives you a project-level security heatmap of all API endpoints, classified by their combined DAST and SAST risk status.

Navigate to Runtime Exposure

1. Open a project in Invicti ASPM.
2. Click the Runtime Exposure tab.

The Summary Heatmap

At the top of the page, a summary bar shows the total endpoint count broken into four categories:

Filtering the List

Use the filters to focus on what matters most:

Viewing Endpoint Details

Click any endpoint to open the detail panel. This shows the individual DAST and SAST vulnerabilities linked to that endpoint side by side, each with name, severity, status, CWE, scanner, file path, and line number. This is where you hand off to the developer — they have everything they need to find and fix the code without any additional investigation.

Verifying a Fix

After a developer resolves the SAST finding and the fix is merged, both the SAST and DAST scanners need to run again to reflect the change in Invicti ASPM.

Invicti ASPM closes a vulnerability when it no longer appears in a subsequent scan. This means:

1. Run a new SAST scan — using the same or any connected SAST scanner on the project. If the fix is complete, the finding will not appear in the scan results and Invicti ASPM will mark it as closed.
2. Run a new DAST scan — on the affected endpoint. If the vulnerability is no longer exploitable at runtime, the DAST finding will also close in that scan cycle.

Once both findings are closed, the endpoint's category in Runtime Exposure will update accordingly — from Correlated to Clean if no other findings remain.

This creates a verifiable, closed loop: the SAST re-scan confirms the code fix, the DAST re-scan confirms the runtime risk is gone.

Recommended Workflow

1. Open Runtime Exposure on any project that has both SAST and DAST scans completed.
2. Review the summary heatmap — focus on the Correlated count first.
3. Filter by Correlated and sort by Critical severity.
4. Click into each endpoint to review the linked DAST and SAST findings.
5. Assign the SAST findings to the responsible developer — the file, line number, and committer are already surfaced.
6. Once the fix is merged, trigger a new DAST scan on the endpoint.
7. Verify the DAST finding has closed in the updated Runtime Exposure view.

Which Vulnerabilities Are Correlated

DAST-to-SAST Correlation applies to vulnerability types that both static and dynamic scanners can detect. If a vulnerability is only detectable by one type of scanner, it will appear in either the DAST Only or SAST Only category rather than Correlated.

Common vulnerability types eligible for correlation include SQL Injection, Cross-Site Scripting (XSS), Command Injection, Path Traversal, Insecure Deserialization, and authentication-related weaknesses that manifest in both code patterns and runtime behavior.

---

Prerequisites

• The project must have at least one completed SAST scan and one completed DAST scan.
• The SAST scanner must be connected to the same code repository that serves the scanned API.
• For full dependency call graph resolution, the Sentinel code analyzer must be enabled on the project. Without it, SAST matching falls back to file-level matching only.

---

Best Practices

• Run SAST and DAST scans on the same branch and as close together in the pipeline as possible, so the correlation reflects the current state of the codebase.
• Use the Correlated category as your primary triage queue — these are the findings with both exploitability proof and code location context, making them the fastest and safest to remediate.
• When assigning fixes, include the correlated DAST finding link in the ticket so developers understand the runtime impact, not just the code smell.
• After each deployment, run a targeted DAST scan on recently changed endpoints to verify fixes and keep the Runtime Exposure view current.

---

Limitations

• Runtime Exposure requires at least one completed SAST scan and one completed DAST scan on the same project.
• DAST findings are matched to endpoints by path and HTTP method. Endpoints with dynamic or parameterized paths may require manual review.
• SAST findings outside the dependency paths of discovered endpoints will appear in the vulnerability list but will not be linked to a specific endpoint in Runtime Exposure.