Examples in this article are illustrative, not customer case studies. Product availability and coverage are described on the linked capability pages.
The checkout service’s vulnerable XML library has been reported three times, by two tools under three different identifiers, and the team has marked it fixed twice without the risk going away. This post shows how security finding correlation turns that chain into one finding with one owner, one rank and one closure record, and what the underlying graph needs to contain.
Security finding correlation is the step that recognises when results from different scanners describe one underlying issue. It works by attaching every finding to a shared model of the estate, in which repository, commit, build, image, registry and running workload are linked entities, so duplicates collapse into a single finding that carries one owner and one rank.
Most organisations instead route findings through five queues: static analysis, software composition analysis, container scanning, infrastructure-as-code scanning and cloud posture. Each has its own severity scale, its own identifiers and no awareness that the others exist. The fix is not a better queue; it is the graph.
ASPM starts where tool-per-category triage fails
Routing each tool’s output to the specialist team for that category looks tidy on paper. In practice it breaks on the most common path a vulnerability takes. In the checkout service, the vulnerable library enters through the dependency manifest, is built into a container image, is pushed to a registry and is deployed as a workload that takes traffic from the public storefront.
Three of the five queues report a piece of that chain. The SCA tool flags the manifest, the container scanner flags the image and flags it again under another identifier when it rescans the registry, and the IaC scanner flags the ingress that exposes the service. Nothing reports the chain itself: a vulnerable package, shipped, running and reachable. An engineer looking at any one queue sees a fragment, and the only place the fragments meet is somebody’s memory.
Manual finding correlation decays faster than teams can maintain it
Teams bridge the gap with spreadsheets that map SCA identifiers to container scan identifiers. Those sheets depend on whoever remembers to update them, and they decay as soon as someone changes team or a new scanner arrives. Severity disagreements between tools turn into arguments about whose number wins, because there is no shared ground truth to settle them.
The worst cost falls on the case that matters most. A vulnerability that is both present in shipped code and exposed in production gets no extra signal, because no single tool can see both halves. The checkout service’s library ranks exactly the same as a copy sitting in an unused test image.
An ASPM finding graph treats artefacts as one lifecycle
A repository, a commit, a build, an image, a registry entry and a running workload are not six unrelated things that happen to be scanned separately. They are the same software at different points in its life, and a finding graph should represent them that way. Each link below adds context that a single queue cannot hold.
A line of code belongs to a commit, an author and a pull request
The first link turns an anonymous line number into a specific line, in a specific commit, from a specific pull request. Without that context, a finding may or may not still exist on the current branch, and nobody knows whom to ask about it.
A commit becomes a build, and a build becomes an image
The second link records which build consumed the commit and which image that build produced. Once it exists, the vulnerable library in the checkout manifest and the vulnerable package inside the shipped image are the same node observed at two points, rather than two findings that happen to share a CVE. This link helps distinguish repeated observations from separate affected deployments.
An image lands in a registry and runs as a workload
The final link connects the static artefact to runtime: which registry holds the image, and which workloads, in which clusters and namespaces, are running it now. This is what turns “a vulnerability exists” into “a vulnerability exists in something an attacker can reach today”, and that distinction is what prioritisation should rest on. The runtime half is explored further in binding images to running workloads.
Ownership routing falls out of the graph
With these links in place, routing stops being a separate problem with its own mapping table. A container finding against the production checkout image traces back through the build and the commit to the repository, and the repository already carries its owning team. The ticket lands with the people who can change the manifest.
The routing is also durable. When the checkout repository changes owners, the change is made once, upstream, instead of in every tool that keeps its own copy of ownership. Vulnerability ownership routing by graph covers the harder cases, such as shared libraries and monorepos.
A scoped decision stays attached to its evidence
Queues also get closure wrong. In a queue model, one person resolves one ticket in one tool while the same risk stays open elsewhere under another identifier, which is exactly how the checkout team came to fix the same issue twice. On a graph, a disposition records its affected scope and supporting evidence. Related deployments can share context without automatically inheriting a false-positive or accepted-risk decision.
A documented false-positive decision can inform later reviews of the same code path. Reassess it when the code, deployment context or analysis changes. An auditor or a new engineer can see not only that a finding was closed, but why, by whom and against what evidence.
Key takeaways
- Trace one vulnerable dependency from manifest to running workload and note every tool that reported a piece of it.
- Link commits to builds and builds to images first, because that link collapses the most duplicate findings.
- Store ownership on the repository and let every downstream finding inherit it.
- Attach dispositions to the underlying entity, with a reason, and re-evaluate the decision when its scope or evidence changes.
How SecurityVault approaches this
SecurityVault connects scanner observations to shared asset and deployment context. Matching observations can be correlated while distinct environments and affected versions remain distinguishable. Teams can inspect the available chain from repository to image and workload, including missing links, before assigning ownership or recording a risk decision.
For an evaluation, choose two scanners that report the same package in one repository, then add a second deployment with a different version. Ask the team to show why observations were combined or kept separate, how the owner was selected and what happens when a reviewer changes the disposition. This tests whether reduced noise comes from accurate correlation rather than discarded records. Keep the original observations available so another engineer can challenge the match and understand the decision without reconstructing the scan.
Explore Vulnerability management or talk to our team about an evaluation with your engineering, security and compliance stakeholders.