A generator can usually fill name, version, purl, dependency relationships, timestamp and creator on its own, because those come from manifests and the run itself. Supplier, concluded license, copyright notices and explanations for odd cases often need a human decision or a policy. Plan for both, or the gaps will be silent.
Fields that come from the machine
Read straight from lockfiles and manifests: component name, group, version and the identifier built from them such as a purl. Dependency relationships come from the resolved tree. The generator also knows its own name and version, which goes in the creator field, and the time of the run, which is the timestamp.
NTIA's 2021 report says the author field reflects the source of the metadata and can be a tool, and that timestamp records when the data was assembled. A tool is well placed to supply both.
Hashes are the middle case. They need access to the actual artifact. NTIA notes that a tool without direct access to the underlying component, such as a binary analysis tool, may be unable to credibly determine the exact bits and so unable to produce a hash.
Fields that need judgment
| Field | Why a tool struggles | Who helps |
|---|---|---|
| Supplier | Registries host packages but rarely state the supplying organization | Procurement or the owning team |
| Concluded license | Declared and concluded can differ and the reason needs explanation | Open source review |
| Copyright notice | Needs reading the files and keeping original wording | Review, with tool extraction |
| Originator and source info | Repackaging history is not in the manifest | The team that adopted the component |
| Scope for odd packages | A tool may call something required that never runs | Engineering |
| Completeness statements | Only a person knows what was not covered | SBOM owner |
A workable split
- Let the tool generate everything it can in CI on each build.
- Keep a small curated override file in the repo, with supplier names and license conclusions for components the tool cannot resolve, and a reason for each.
- Merge the overrides during generation so the final SBOM carries both, with the manual entries marked as such.
- Report the fill rate per field on each release so gaps show up as a number.
Pitfalls
Backfilling by guess. A confident wrong supplier is worse than a blank, and the SPDX specification gives NOASSERTION for exactly this reason.
Hand edits to the output. They vanish on the next build. Put corrections in the override file, where they survive.
Treating the tool's defaults as decisions. A generator that leaves license blank or writes NOASSERTION is telling you it did not decide. Do not read that as clean.
Ask the vendor the same question
When you evaluate a tool, ask which fields it fills from data and which it leaves for you. A tool that fills every field for every component has probably guessed in some of them.
Safeguard can generate SBOMs and run dependency scanning across your repositories, so the fields discussed here are checked on real projects instead of by hand. You can try the free scan at gold.safeguard.sh/scan.
Try it yourself
Open the demo, click through the component list, and look at how each package is identified and what is missing.
Click through it at your own pace, or open it full screen.
Quick check
Should a tool or a person write the concluded license?
A person or a documented review process. A tool can suggest, but concluded means a decision was made.
Where should manual corrections live?
In a version controlled override file that the generator merges on every run, so they are not lost.
Sources
- NTIA, The Minimum Elements for a Software Bill of Materials (2021)
- SPDX 2.3.1, Clause 7: Package information
Last reviewed: 19 October 2026.
