Supply chain dependency reviews
Count unresolved dependency exposure, not just open alerts
Alert totals need context about execution, reachability and ownership. A smaller number can reflect better risk treatment or merely broader suppression.
In this article
Establish inventory coverage
Measure whether deployed artifacts have a current dependency inventory linked to their source and build. Include relevant transitive and build-time components, not only the application manifest.
An alerting system cannot assess a dependency it does not know exists. Track unsupported package types or missing build inventories as coverage gaps rather than reporting them as clean.
Keep artifact identity in the report so the team can distinguish a fixed branch from the release still running in production.
Classify findings by practical exposure
Record the affected path, execution stage and available mitigation. Known severity is useful, but the application's use and environment determine the response needed.
A development dependency can execute in a powerful CI job. A runtime package can contain an affected feature that the application does not currently use. Both need reasoned review rather than automatic dismissal based on a manifest category.
Treat an exception as an active decision with an owner and expiry. A suppressed alert should remain discoverable when its assumptions change.
Measure time to a verified outcome
Track the interval from detection to triage, mitigation and deployment of the corrected artifact. A merged update does not establish that the exposed release has been replaced.
For an illustrative incident, a patch is merged in one hour but the old artifact runs for two days. Reporting only merge time hides most of the exposure window.
Include failed upgrades and their blocking tests. That evidence helps distinguish neglected maintenance from a compatibility problem requiring engineering work.
Preserve quality around the update
Measure update-related regressions and the coverage of dependency-specific behaviour tests. A process that closes advisories by repeatedly breaking core workflows will encourage unsafe avoidance of updates.
Check provenance verification and rollback availability where those controls are part of the release design. These are separate from advisory counts and should not be collapsed into a single green badge.
Acceptance should show that the reviewed dependency graph produced the deployed artifact, important findings have a disposition and relevant workflows still behave correctly. Zero alerts alone cannot establish those facts.
Primary sources
OWASP: vulnerable dependency managementSLSA: provenanceReferences checked 11 September 2026.