ASPM can only rank what it can identify. From SCA it needs exact component identity, resolved version, where the component sits in the dependency tree, which application and build it belongs to, fix information, and a stable finding ID. Missing any of these, and deduplication and ownership fail.
Why input quality decides the outcome
ASPM correlates and prioritizes. It does not re-scan your code. If SCA hands over a vague alert such as "lodash is vulnerable" with no version or location, nothing can be matched, deduplicated or routed. The aggregator then shows a bigger list, not a better one.
The checklist
1. Component identity. A package URL or equivalent that names the ecosystem, name and version. Name alone is ambiguous across ecosystems.
2. Resolved version. The version actually installed, taken from the lockfile or built artifact, not the range in the manifest.
3. Dependency path. Direct or transitive, and the chain that brought it in. This tells you which upgrade will remove it.
4. Application and build context. Repository, branch, build or image digest, and service name. Without these, findings cannot be mapped to a running application.
5. Vulnerability identifier. A CVE or advisory ID, so the finding can be joined to exploit data. The CISA KEV catalog and FIRST's EPSS scores are both keyed by CVE.
6. Fix data. The first fixed version, if one exists, and whether it is a major version jump. This feeds effort estimates.
7. Reachability signal. Whether your code calls the vulnerable function, where the tool can tell. This is context ASPM cannot recreate by itself.
8. Stable finding ID. The same issue should keep the same ID across scans, so closing and reopening can be tracked.
9. Timestamps. First seen, last seen and fixed dates. Age is a core metric.
10. Ownership hint. A code owner file, team tag or repository owner, to route the ticket.
How to test your SCA output
Take ten recent findings and check them against the list. Score each one. If more than a couple miss items one to four, fix the SCA configuration first. Common causes are scanning manifests instead of lockfiles, scanning without build context, or exporting a report format that drops fields.
CISA describes an SBOM as a nested inventory of the ingredients that make up software. A good SBOM export carries many of these fields, so using it as the exchange format between SCA and ASPM is a sensible default.
Common failure patterns
- Ranges instead of resolved versions. A finding based on a version range cannot be confirmed.
- No application link. The finding lives in a repository but not in any service record.
- Unstable IDs. Every scan produces new IDs, so closed issues reappear as new.
- Severity only. The export has a score but no CVE, so exploit data cannot be joined.
A worked example
Here is a poor SCA finding as it might arrive, followed by a good one. Both describe the same issue.
Poor: "A vulnerable version of a logging library was detected. Severity: high."
Good: a record with the package URL, the resolved version from the lockfile, the CVE identifier, the dependency path from the top level package, the repository and build digest, the first fixed version, a reachability flag, the first seen date, and a stable ID.
From the poor record, ASPM can do almost nothing. It cannot match the finding to a service, join it to KEV or EPSS, estimate the fix, or detect that the same finding reappeared. From the good record, it can do all of those.
Step by step: audit your SCA output in an afternoon
- Export 20 recent findings in the format your ASPM or sheet will receive.
- Make a grid with the ten fields above as columns.
- Mark each cell as present, partial or missing.
- Count the gaps by field. The most common missing fields point to configuration problems.
- Trace each gap to a cause. Manifest scanning instead of lockfiles, no build context, a report format that strips fields, or a tool that does not collect the data at all.
- Fix the biggest gap first, rescan, and repeat the audit.
Typical causes and fixes
| Gap | Likely cause | Fix |
|---|---|---|
| No resolved version | Scanning manifests only | Scan lockfiles or built artifacts |
| No application link | Scans run without project metadata | Pass repository and service name at scan time |
| No dependency path | Report format drops it | Use a richer export, such as an SBOM with relationships |
| Unstable IDs | IDs generated per scan | Derive IDs from component, CVE and application |
| No fix data | Tool does not look up fixed versions | Add a lookup step or switch format |
Why SBOMs help
CISA describes an SBOM as a nested inventory of the ingredients in software. Because it records relationships between components, it carries the dependency path in a standard form. Using an SBOM as the handoff between SCA and ASPM avoids custom parsing and gives the aggregator a clean base to build on.
Questions to ask your SCA owner
- Which fields are present on every finding, and which only sometimes?
- Do identifiers stay the same between scans?
- Can we export history, not just the latest result?
- How are findings tied to a specific build?
Improving these answers raises the quality of everything downstream, including the metrics leadership sees.
Try it yourself
Open the demo and look at how direct and transitive components are listed for one project.
Click through it at your own pace, or open it full screen.
Where Safeguard fits
Safeguard generates SBOMs and dependency findings with reachability analysis, so the fields above are available from one place, and its asset discovery helps tie findings to applications. A free scan is at gold.safeguard.sh/scan.
Quick check
What is the single most important field?
Exact component identity with a resolved version. Without it nothing can be matched or deduplicated.
Do I need reachability data for ASPM to work?
No, but it is context the aggregator cannot generate itself, and it removes a lot of noise when available.
Do I need an SBOM to feed ASPM?
Not strictly, but an SBOM is a convenient standard carrier for component identity and dependency relationships.
Sources
Last reviewed: 19 October 2026.
