On adoption day, make sure your SBOM shows the library's name, exact version, ecosystem, source location, license, a checksum or lockfile hash, and which services use it. Add the owner and decision link as extra notes. That is enough to answer most audit and incident questions quickly.
Why capture it at adoption
Reconstructing facts later is slow and sometimes impossible. A registry page may change, a license may be edited in a later release, and a package may be removed. Recording facts on the day you decide gives you a stable reference.
The minimum fields
| Field | Why it matters |
|---|---|
| Name and ecosystem | Identifies the package unambiguously |
| Exact version | Advisories apply to versions |
| Source location | Registry URL and repository link, for provenance questions |
| License | Identifier in SPDX form where possible; see reading license expressions |
| Hash or lockfile entry | Detects tampering and confirms the same artifact |
| Direct or transitive | Shows who chose it and what pulled it in |
| Where used | Services or applications that ship it |
Optional but valuable: owner, link to the decision record, exit trigger and review date.
Formats
The SPDX specification and CycloneDX are the common SBOM formats. Either can hold these fields. See CycloneDX versus SPDX in practice for choosing between them. What matters more than the format is that you generate the SBOM from the real build, not from a hand-edited list.
Generate, do not hand write
- Commit the lockfile with the dependency change.
- Generate the SBOM in CI on every build, from the lockfile or the built artifact.
- Store the SBOM with the release, so you can look up any past version.
- Compare SBOMs between releases to see exactly what a change added.
Handwritten inventories go stale within weeks. Generated ones stay current.
Questions this answers later
- Incident: Which of our services ship version X of this package?
- Audit: What open source licenses are in this product?
- Procurement: Can you give us a component list for this release?
- Exit: Where would we have to change code if we dropped this library? See removing a library safely.
Try it yourself
Click through it at your own pace, or open it full screen. Look at what is recorded for each component and how direct and transitive entries are distinguished.
A short adoption day routine
Four steps keep the record honest. Add the dependency and commit the lockfile in the same pull request. Let CI generate the SBOM and attach it to the build. Open the generated file and confirm the new library appears with the version and license you expect. Finally, link the pull request to your decision record. If the generated entry shows an unknown license or a missing source link, fix that now, while the details are fresh and the maintainers are easy to ask.
Where Safeguard fits
Safeguard provides SBOM and dependency scanning and compliance and evidence automation, so an inventory like this is generated from your code rather than maintained by hand. Try the free scan at gold.safeguard.sh/scan.
Quick check
Is a lockfile enough instead of an SBOM?
A lockfile is a good input but is ecosystem specific and lacks license and source detail. An SBOM adds a shared, portable format.
Do transitive dependencies belong in the SBOM?
Yes. They ship in your product, and most incidents involve them.
Last reviewed: 19 October 2026.
