Why one problem is one finding

A runtime observation and the source that caused it are joined. The code finding is canonical; the live observation is attached as proof.

Run a DAST tool and a SAST tool over the same application and you get the same bug twice, in two vocabularies, with no indication that they are the same bug. AppScan joins them before you ever see them.

1
The browser sees it
A data API answers a request with no session and returns 148 rows.
2
The analyzer finds it
A route has no guard before the query, at a specific file and line.
3
Correlation joins them
One finding: the code location is canonical, because that is what you change.
4
The proof rides along
The response that proves it is exploitable in production is attached to the same finding.

What this changes

You fix a line rather than closing two tickets.
A code finding confirmed at runtime is marked CONFIRMED and ranked accordingly - it is not theoretical.
A runtime finding with no code behind it stays on its own, which usually means it comes from configuration or a third party.

Questions

What if the runtime and source findings disagree?

Both are kept and the disagreement is visible. Most often it means the running deployment is not the commit we analyzed, which is itself worth knowing.

Does correlation work without a repository?

No. Without source there is nothing to correlate to, so runtime findings stand alone.

Something here wrong, missing or out of date? Tell us and we will fix the page.