Store a small dated record per dependency, such as last publish date, deprecation flag, advisory count and Scorecard result, then compare it with the previous record each week. The change between two records is often more informative than either value. A flat file in version control is enough to start.
Why snapshots
Most signals are point-in-time. The deps.dev documentation notes that a Scorecard result carries the date it was produced, and a publish time is a fact about one version. A package that looked fine in March can look different in October, and without a record you cannot say what changed or when.
The OpenSSF Concise Guide asks you to confirm things like release recency and security response. Those are questions about time. Snapshots give you the time dimension.
What to record
| Field | Source | Why it helps |
|---|---|---|
| Package, version in use, default version | Lockfile, registry | Shows how far behind you are |
| Last publish date | Registry or deps.dev | Cadence and dormancy |
| isDeprecated and reason | deps.dev | Maintainer's own message |
| Advisory count on your version | deps.dev advisoryKeys | Known issues today |
| Scorecard date and key checks | deps.dev project data | Review and maintenance practice |
| Provenance present | Registry or deps.dev | Origin signal |
| Date checked | Your script | Needed for comparison |
A minimal routine
- Export your direct dependencies from the lockfile to a list.
- For each, fetch the fields above and write one line per package to a dated CSV or JSON file.
- Commit the file to a repository, or store it where you keep audit evidence.
- Diff this week against last week and print only the changes.
- Send the diff to the owner of the repository with the package's role: build, runtime, helper.
- Keep eight to twelve weeks, then thin out.
A diff worth noticing includes a first deprecation flag, a long gap that ends in a new version, a provenance field that disappeared, or a Scorecard drop on review or maintenance checks.
Keep the noise down
Do not alert on every change. Alert on a short list of transitions and put the rest in a weekly summary. Review quarterly which alerts led to action and retire the ones that never did.
Limits
Snapshots depend on data coverage. Some fields are only populated if available, so an empty field is unknown, not bad. Scorecard results lag the repository. And a diff tells you something changed, not why. Use it to start a review, not to end one.
Try it yourself
Click through it at your own pace, or open it full screen. See how a baseline and later scans make change visible.
Where Safeguard fits
Safeguard provides SBOM and dependency scanning with ongoing monitoring and policies and gates, so you do not have to maintain the scripts per repository. A free scan is at gold.safeguard.sh/scan.
Quick check
How often should I take a snapshot?
Weekly is a reasonable start for direct dependencies. Move critical build tools to daily if you can.
Do I need all transitive dependencies?
Start with direct ones, plus any transitive package that runs install scripts or sits in your build.
Sources
Last reviewed: 19 October 2026.
