Generate an SBOM from your lockfile on every build and keep each one. When an assistant keeps adding packages, the SBOM becomes your record of what was in each release, and a diff between two SBOMs shows exactly what changed, including indirect packages nobody typed.
Why assistants make this more important
People add dependencies deliberately. Assistants add them as a side effect of solving a task. Over a quarter, a project can gain dozens of packages that no one recalls approving. If a vulnerability or a malicious package is announced, you need an answer to "are we using it" in minutes.
What to generate and when
- From the lockfile, not the manifest. The lockfile lists exact resolved versions, including transitive packages. A manifest lists only intentions.
- On every build. Store the file next to the build artifact with a build identifier.
- At release. Keep the release SBOM as the record for that version.
A frozen install such as npm ci ties the build to the lockfile, so the SBOM describes what was actually installed. See npm ci vs npm install.
Use the diff
Compare the SBOM from the last release with the new one. Review the list of added packages the way you would review code. Ask for each: why is it here, who publishes it, and was it intended?
GitHub's dependency review gives a pull request level version of this view, covering added, removed and updated dependencies, including indirect ones in lockfiles.
Questions an SBOM answers fast
- Do we use package X at any version?
- Which services contain it?
- When did it first appear, and in which pull request?
- Which components have no recent releases?
What an SBOM does not do
It lists components. It does not say whether a component is exploitable in your code or whether it behaves badly. Pair it with vulnerability matching, reachability analysis and review of new additions.
Keep it honest
If an SBOM is produced by a tool that guesses from source files instead of reading lockfiles, check its accuracy against the lockfile occasionally. Missing transitive packages defeat the purpose.
Safeguard's SBOM and dependency scanning does this work across projects, and you can try the free scan at gold.safeguard.sh/scan.
Format choice
The common SBOM formats are both widely supported, so choose the one your tools and customers already accept and stay consistent. Consistency matters more than the format, because comparing two files across releases only works when they come from the same generator with the same settings.
Quick check
How long should I keep old SBOMs?
At least as long as you support that release. Check any customer or contract requirements, since retention terms vary.
Sources
Last reviewed: 19 October 2026.
