Executives need a few trend lines: coverage, exposure on internet facing systems, time to fix and overdue items. Engineering teams need a ranked, owned, fixable list with a clear next step. A good SCA tool serves both from the same data without manual spreadsheets.
Two audiences, two questions
A leader asks: are we getting safer, and where should I spend attention? A developer asks: what do I fix today, and how? Reports built for one fail the other. A 40 page export bores a director. A single risk score gives a developer nothing to act on.
What leadership views should contain
| Metric | Why it is useful | Watch out for |
|---|---|---|
| Coverage: repos scanned out of repos known | Shows blind spots | Needs an independent list of repos |
| Open findings by severity, trended | Direction of travel | Raw counts can rise as coverage rises |
| Median and worst time to fix | Measures responsiveness | Report by severity, not blended |
| Overdue items and active exceptions | Shows risk accepted | Include expiry dates |
| Share of findings with a named owner | Shows routing health | See the ownership metric post |
| Reachable versus unreachable findings | Focuses effort | Method must be explained |
A common trap: counts rise after you expand coverage, and someone reads it as getting worse. Always show coverage beside the count.
What team views should contain
- Findings for repos the team owns, sorted by what to do first.
- For each: package, version, fixed version if one exists, whether it is reachable, and how it entered (direct or transitive).
- A link to the fix pull request or the exact upgrade step.
- Exception status and expiry.
- Newly introduced versus inherited.
The NTIA minimum elements for an SBOM list data fields such as supplier, component name, version, unique identifiers, dependency relationship, author and timestamp. Those fields are the raw material for both views, so check that an exported SBOM carries them (see Sources).
Questions to ask in an evaluation
- Can I save a view per audience and schedule it by email or export?
- Are the numbers on the leadership view the same ones the teams see, or a separate calculation?
- Can I filter by unit, product, tier and owner?
- Is there an API so our own dashboards can pull the data?
- Can I show a trend since a chosen date, such as the day we started enforcement?
Avoid vanity measures
Counts of scans run or findings found say little. Prefer outcome measures: time to remediate, coverage, overdue items and exposure on critical systems. For a program with a baseline, report new findings separately from inherited ones, as covered in new versus inherited vulnerabilities report separately.
A monthly rhythm
Send leadership one page monthly: three trend lines, three overdue items, one decision needed. Give teams their list weekly inside the tools they already use.
Safeguard's dependency scanning, SBOM output and compliance and evidence automation are designed to support both views. Try a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at which fields appear on each finding and decide which ones your developers would need.
Quick check
Why did our finding count go up after rollout?
Usually because coverage grew. Show repos scanned beside open findings so the trend reads correctly.
Sources
Last reviewed: 19 October 2026.
