A credible SBOM story can start in one day: generate an SBOM for your main product, open it, and write four honest sentences about it. Automate generation in a week, and add response and sharing routines within a month. Each stage only needs to be true, not complete.
Day one: have something real
Goal: answer a buyer today without bluffing.
- Pick your main production service and generate an SBOM with an open or commercial tool, in SPDX or CycloneDX.
- Open the file. Confirm it lists transitive dependencies. CISA's 2026 minimum elements guidance says an SBOM should include all components including transitive dependencies (see Sources).
- Note what is missing: other services, container images, copied code.
- Write four sentences: how it is made, how often, what you can share, what you do on a new advisory. Mark any that are not yet true as planned.
At the end of day one you have a sample and an honest description.
Week one: make it repeatable
Goal: remove the dependency on one person remembering.
- Add SBOM generation to the CI release step, so each version gets one, as the guidance expects for each software version or update.
- Store each file with its release record.
- Write a one page process note with tool, trigger, format, storage and owner.
- Name a backup who can retrieve and send an SBOM.
- Decide your sharing route: terms, channel and approver.
Month one: connect it to action
Goal: show the SBOM is used, not just produced.
- Schedule rescans against new advisories, or use a tool that does it continuously.
- Write a short vulnerability response routine and test it on a recent public advisory.
- Extend coverage to container images and the remaining services.
- Decide how you will state status, for example a plain message or a VEX statement.
- Run a mock buyer review with a teammate.
What each stage can honestly claim
| Stage | You can say | You should not say |
|---|---|---|
| Day one | "We can generate an SBOM and share a sample" | "Fully automated" |
| Week one | "We generate one on every release in CI" | "Covers everything" |
| Month one | "We rescan and have a documented response routine" | "Zero vulnerabilities" |
What can wait
Signing, publishing VEX for every advisory, and public SBOM downloads can come later. The guidance lists an author signature as a field, but a startup can say it has not added one yet. Adding too much too soon creates things to maintain and explain.
Typical blockers
- No lockfiles committed. Generators lean on them. Commit them.
- Several package ecosystems. Start with the one that holds most of your code.
- Nobody owns it. Assign a name before building anything else.
Keep it moving
Put one recurring task on the calendar: open the latest SBOM monthly and check it still matches the product. If a buyer asks for the history, you will be glad you kept it.
Where Safeguard fits
Safeguard's SBOM and dependency scanning can produce the first inventory in minutes, and the free scan at gold.safeguard.sh/scan is a way to do day one without setup.
Try it yourself
Click through it at your own pace, or open it full screen.
Check how much of the inventory is transitive; that is usually the surprise on day one.
Quick check
Is one day really enough to answer a buyer?
Enough for an honest first answer with a sample and stated gaps. It is not enough for a mature program, and you should not describe it as one.
What if we use several languages?
Start with the language that holds most of your production code, then add the others as you extend coverage.
Sources
Last reviewed: 19 October 2026.
