Use it as one input among several. A project SBOM can save you time and show how the maintainers see their own dependencies, but no one is obliged to keep it current, answer questions, or issue VEX. Check it against your own scan and record where it came from.
How it differs from a commercial supplier
With a paid supplier you can ask follow-ups, set expectations, and escalate. With an open source project you have a public release page and an issue tracker. The NTIA minimum elements report notes that open source maintainers may feel their interests are served by making SBOM data public, and that access terms for others are set by licensing or contract. For a public project the terms are simply that the file is there for anyone.
That changes how you treat it:
| Question | Commercial supplier | Open source project |
|---|---|---|
| Can you ask for a fix? | Yes, under your agreement | You can open an issue or send a patch |
| Is the SBOM promised for each release? | Possibly | Not unless the project says so |
| Who is accountable for errors? | The supplier | No one in particular |
| Will VEX be issued? | A business decision | Rarely |
Step by step
- Find where it is published. Release assets, a repository folder, or a documented link. Prefer the file attached to the specific release you use over a file in the main branch.
- Match version to release. The NTIA report suggests SBOM data can be made available through a version specific location. Confirm the file refers to your version.
- Check who authored it and how. Is it generated by the project's build, or written by hand?
- Run your own scan on the artifact you actually downloaded and compare. See the post on when a supplier SBOM and your scan disagree.
- Record the source. URL, date retrieved, release version and a checksum of the file.
- Keep a copy. A project may remove or move old files.
What the file adds beyond your own scan
If maintainers generate the SBOM from their build, it can list components that a scan of the final package misses, such as build-time inputs or things vendored into the source. That is useful context when you need to understand what a library is made of.
It can also list less than your scan does, because projects often stop at declared dependencies.
When a flaw shows up in a project dependency
You may need to act without waiting for the project. Options are to pin to a fixed version of the dependency if the project allows it, upgrade the project, apply a workaround, or replace the library. Opening a clear issue with the component, version and advisory helps maintainers, and sending a patch helps more.
Respect the maintainers
Maintainers are often volunteers. A polite issue with specifics gets better results than a demand. If you rely heavily on a project, consider whether your organization can support it in ways that fit your policy.
If you want a first look at a published file, Safeguard's free scan is at gold.safeguard.sh/scan.
Quick check
Can we rely on a project SBOM for compliance evidence?
Use it as one input and pair it with your own scan of what you deploy. The project is not obliged to keep it accurate.
Should we ask the project for VEX?
You can ask, but do not count on it. CISA describes issuing VEX as a business decision for most suppliers and possibly a more individual decision for independent open source developers.
Sources
- The Minimum Elements For a Software Bill of Materials (SBOM), NTIA
- When to Issue VEX Information, CISA
Last reviewed: 19 October 2026.
