Software Evidence in a Minute
Dependency Evidence
Using manifests and lockfiles as evidence of what third-party code you actually resolve.
In one sentence
Dependency evidence is the observable record of which third-party packages and versions a build is configured to resolve.
Why it matters
Runtime behavior often comes from libraries you did not write. Claims about security and behavior must include what you depend on.
How it works
- Read the manifest for direct intent and the lockfile for resolved versions.
- Diff lockfiles across releases to see what actually moved.
- Attach advisory scans to specific lockfile hashes when discussing vulnerabilities.
- Separate “we intended version X” from “the lockfile resolves Y.”
Example
Claim: “We are not affected by advisory CVE-… in libfoo.” Evidence needs the lockfile revision showing the resolved version and a clear statement whether that version is in the affected range.
What this proves
Dependency evidence proves configured and/or locked package identities for a revision—not necessarily what every machine will fetch if installs are non-hermetic.
What this does not prove
A clean advisory scan does not prove secure application logic. A lockfile does not prove the dependency is used safely.
Last reviewed 2026-09-06. Title for citation: Software Evidence in a Minute: Dependency Evidence.