Record the tool and version that produced the SBOM, the directory it started from, the date, which directories used lockfiles and which were approximate, and what was excluded. Without these notes, a reader cannot judge how complete the SBOM is, and neither can you in six months.
Why method matters
An SBOM from a legacy monorepo is not a perfect census. It reflects what the tool could see: some directories from exact lockfiles, some from loose manifests, some not at all. Two SBOMs with the same format can differ greatly in reliability.
The CycloneDX specification overview says BOM metadata includes the supplier, manufacturer and target component the BOM describes, and also the tools used to create it. So the format already has a place for provenance. Use it, and add what the format cannot express in a short companion note.
The fields to capture
| Field | Why it helps |
|---|---|
| Tool name and version | Different versions find different things |
| Commit hash scanned | Ties the SBOM to an exact state of the code |
| Scan root and included directories | Shows what the SBOM covers |
| Exclusions with reasons | Explains what is missing |
| Lockfile status per directory | Separates exact from approximate |
| Date and time | Dependencies change; so do advisories |
| Who ran it and where | Helps reproduce the result |
The commit hash deserves emphasis. An SBOM without one describes an unspecified moment, and nobody can later rebuild the same list.
One SBOM or a companion note
Keep the SBOM file clean and put the human readable method in a short note beside it. A single page works: what was scanned, what was not, and known limits. Link it from the place where the SBOM is stored so they travel together.
An example opening for the note:
Scanned commit: <hash>
Tool: <name and version>
Included: services/*, libs/*
Excluded: build output, test fixtures (reviewed 2026-10-19)
Exact (lockfile): 41 of 63 directories
Approximate (manifest only): 19 directories
Not scanned: 3 directories (build removed; owners notified)
Replace the placeholders and counts with your own. The pattern is what matters: numbers a reader can check.
Be careful with claims
Do not call an SBOM complete unless you can show it is. "Covers all directories with a manifest, as of this commit" is a claim you can defend. "Complete inventory of our software" usually is not.
Regenerate on a schedule
Generate on each release and at least monthly for the default branch, and keep older ones so you can answer "were we affected on that date" later. Store them in a place with access controls, because an SBOM is useful to an attacker as well as to you.
Where Safeguard fits
Safeguard generates SBOMs from its dependency scanning and supports compliance and evidence automation, so the method notes can sit with the evidence. Try the free scan at https://gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at what an inventory records, then think about which method notes a reader would need next to it.
Quick check
Is the commit hash really necessary?
Yes. It is the cheapest way to make an SBOM reproducible and to answer questions about a past release.
Should the method note be public?
Share it with customers who ask for the SBOM, but review it first for internal paths and names you would rather not expose.
Sources
Last reviewed: 19 October 2026.
