It should show the package path, its owner, the ecosystem, the lockfile used, the scan time, the in scope flag, and the findings with the dependency chain. A flat list of vulnerabilities cannot tell you what was covered, and coverage is what makes a clean result believable.
Coverage comes before findings
A clean report only means something if you know what was checked. For each package, record what the scan actually read.
| Field | Why it matters |
|---|---|
| Package path | Routes the result and proves the package was seen |
| Ecosystem | A folder can hold more than one |
| Input file | Which lockfile or manifest was read |
| Input status | Lockfile found, manifest only, or nothing found |
| Scan time | Old results mislead |
| Scope flag | In scope, excluded, or unknown |
| Owner | Who acts on it |
An input status of nothing found should not render as zero findings. It should render as not scanned.
Finding level fields
For each finding, include enough to act on it.
- Advisory identifier and severity.
- Library, resolved version and fixed version if one exists.
- The dependency chain from the package to the library, including internal hops.
- Whether it is a direct or transitive dependency.
- Reachability status, with unknown kept separate from not reachable.
- Whether the library is in a runtime or a development context.
- Known exploitation signals, if your tool provides them.
Summary level fields
At the top of the report, show the numbers that make the rest trustworthy.
- Packages found, scanned, excluded and failed.
- Lockfile coverage as a count out of total.
- Findings by root cause and by occurrence. See counting one vulnerability across many packages.
- Unowned packages.
If packages failed to scan, say so loudly. A silent failure is worse than a finding.
Design traps
- Rolling up to a single score. It hides which package is the problem.
- Sorting only by severity. A medium that is reachable and has a fix may deserve attention before a high that is not reachable.
- Dropping history. Keep the previous report so new findings are distinguishable from old.
- No machine readable output. If you cannot export it, you cannot route it.
Use the report to test a tool
When evaluating tools, ask to see a report for your own repository. Check that the package count matches your inventory, and see how they show failures. SCA monorepo and container coverage checks covers more tests.
Where Safeguard fits
Safeguard generates SBOMs and scan results per project, with reachability analysis and policy checks. Try one project with the free scan at https://gold.safeguard.sh/scan.
Try it yourself
Open the demo and look at which fields appear for each finding. Compare them with the list above.
Click through it at your own pace, or open it full screen.
Quick check
Is a package with no lockfile a clean package?
No. It should show as not scanned or manifest only, never as zero findings.
Why keep reachability unknown separate from not reachable?
Unknown means the tool could not decide, and treating it as safe hides real exposure.
Last reviewed: 19 October 2026.
