A dependency adoption record should fit on one page and answer: what did we approve, which version, who reviewed it, what did we see, what conditions did we attach, and when do we look again. Keeping it next to the code means auditors, customers and your future self can see why the package was allowed.
Why bother
When a package has an incident, the first questions are "did we ever look at this?" and "what has changed since?" Without a record you rebuild the answers from memory. With one, you compare the current state against what you accepted.
Questionnaires also ask how you choose open source components. A set of dated records is a concrete, truthful answer. It documents your process. It is not a certification of anything.
The template
Copy these fields into an issue template or a file in the repository.
| Field | Example entry |
|---|---|
| Package and ecosystem | example-lib, npm |
| Version approved | 2.4.1 |
| Date and reviewer | 2026-10-19, A. Reviewer |
| Use and blast radius | Runtime parsing of untrusted input |
| Registry owners at review | Two accounts listed |
| Source repository | Matches registry metadata |
| Release method | CI build, provenance present or not |
| Advisory history | Number and handling summary |
| Maintainer continuity | Bus factor estimate, org backing |
| Scorecard notes | Rows of concern, not just the aggregate |
| Conditions | Pin exact version, monitor, no auto-merge |
| Exit plan | Who would fork or replace, and how |
| Re-review triggers | Owner change, new advisory, 90 days silent |
The example values are placeholders, not a real review.
How to fill it quickly
Most rows come from three sources. The registry page gives owners, release dates and repository link. OpenSSF Scorecard gives practice results through its CLI or public API. The GitHub Advisory Database and OSV give advisories. OSV aggregates vulnerability databases that use the OpenSSF vulnerability format, and deps.dev indexes advisories from OSV alongside the dependency graph for Cargo, Go, Maven, npm, NuGet, PyPI and RubyGems.
Rules that keep it honest
- Record what you saw, including negatives. "No security policy file" is useful.
- Date every record and name the version. Approval of 2.4.1 is not approval of 3.0.
- Keep conditions testable. "Monitor" should name the tool or alert.
- Review the record when its triggers fire. See what events should trigger a re-review.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how a single piece of evidence can map to several framework controls. An adoption record is exactly that kind of reusable evidence.
Safeguard can help here. Its SBOM and dependency scanning, reachability analysis and policy gates cover the checks that should repeat after adoption, and the free scan at gold.safeguard.sh/scan shows what a project already depends on.
Quick check
Do I need a record for transitive dependencies?
No. Keep full records for direct dependencies with real blast radius, and rely on automated inventory for the rest.
Where should the record live?
Beside the code, such as in the repository or the pull request that adds the package, so it travels with the change.
Sources
Last reviewed: 19 October 2026.
