Read a software composition analysis (SCA) report in this order: confirm what was scanned, split findings by direct and indirect dependency, check the fixed version, weigh exploit signals beyond severity, then group the work by the upgrade that closes the most findings. Severity alone is the wrong place to start.
What an SCA report is
Software composition analysis lists the open source packages in your application, then matches each package and version against databases of known vulnerabilities and, usually, license data. The report is the output of that matching. It is only as good as the inventory underneath it, which is why the first step is not about vulnerabilities at all.
The six steps
- Check coverage. Which repositories, manifests, lockfiles and ecosystems did the scan read? A short report can mean a healthy project or a scan that missed half of it. The coverage check post walks through this.
- Find the dependency path. For each finding, see which package pulled the vulnerable one in. A direct dependency you can upgrade yourself. An indirect one may need a parent upgrade.
- Read the fixed version. Note the first version that contains the fix and whether any upgrade is possible within your version constraints.
- Add exploit context. Severity describes the flaw in general. Look for signals such as whether the vulnerability is on CISA's Known Exploited Vulnerabilities list, an exploit probability score, and whether your code can reach the vulnerable function.
- Separate runtime from development. A flaw in a test tool is not the same exposure as a flaw in a library that ships to production.
- Group by fix. One upgrade often closes several findings. Work from the upgrade, not from the row.
What each common column means
| Column | What it tells you | What it does not tell you |
|---|---|---|
| Severity or CVSS | How bad the flaw is in the abstract | Whether you are exposed |
| Fixed in | First version with a fix | Whether upgrading breaks your build |
| Introduced by | The parent package in the chain | Whether the parent has a newer release |
| Exploit signal | Whether attackers are using it | Whether your usage is exposed |
| Scope | Runtime or development | How the build output is used |
FIRST, which maintains CVSS, states that the CVSS Base Score represents only the intrinsic characteristics of a vulnerability and should be supplemented with contextual analysis of the environment. That is the reason step four exists.
A worked example in words
Say a report lists 40 findings. After step one you learn one service was never scanned, so you add it. After steps two and five, 15 findings sit in development-only tools and 25 in runtime code. After step three, 12 of the runtime findings are fixed by upgrading a single framework. That leaves 13 findings, a smaller and more honest queue than 40 rows sorted by severity.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how each dependency is listed alongside the package that introduced it.
Where Safeguard fits
Safeguard produces SBOM and dependency scanning results with reachability analysis, so the exploit-context step in this list is already attached to each finding. You can run a free scan at gold.safeguard.sh/scan and read the output with these six steps.
Quick check
Should I read the highest severity findings first?
Not on their own. Start with coverage and dependency path, then use exploit signals and reachability to decide which high severity items are really exposed.
Is a short SCA report a good sign?
Only after you confirm coverage. A short report can also mean missing lockfiles or unsupported ecosystems.
Sources
- FIRST, CVSS v3.1 user guide
- CISA, Reducing the Significant Risk of Known Exploited Vulnerabilities
- npm Docs, npm explain
Last reviewed: 19 October 2026.
