SBOM
SBOM automation
SBOM automation means every build produces its own software bill of materials, with nobody copying versions into a spreadsheet. If your team maps components by hand across several products, the list is out of date by the next release, and the work grows with every product you add.
Updated
Why manual SBOMs stop working
- They go stale on the next build. Dependencies change with every release, and a spreadsheet only changes when someone remembers to update it.
- They stop at what people can see. Direct dependencies are easy to list. The transitive dependencies underneath them are not, and nobody can follow those by hand.
- They multiply. Several products with several supported versions each means dozens of files, each with its own owner and its own idea of the truth.
- They can't answer the question that matters. When a new vulnerability lands, you need to know which releases contain the package. Searching a folder of spreadsheets is slow, and you can't trust the answer.
- They aren't what others ask for. Customers and tools expect a machine-readable format such as CycloneDX or SPDX. See how to answer a customer SBOM request.
What good SBOM automation does
- Produces an SBOM for every build, with no one needing to run or remember anything.
- Covers the full tree, transitive dependencies included, at every depth.
- Ties each SBOM to one build, so that you know which file describes which release.
- Says what it could not see, rather than presenting a partial list as a whole one.
- Exports a standard format, so that the SBOM works with the next tool and the next customer.
- Keeps watching what shipped, because a release that was clean on Monday can be affected on Tuesday.
Three ways to keep SBOMs, compared
| Question | Spreadsheet | Scanner in CI | Recorded during the build |
|---|---|---|---|
| When is it updated? | When someone remembers | When the scan step runs | On every build |
| Where does the data come from? | People | Lockfiles or the finished output | What the build actually pulled in |
| Transitive dependencies? | Rarely | Those it can work out | At every depth |
| Hidden dependencies, such as install script downloads? | No | Missed | Recorded |
| Packages restored from a CI cache? | No | Depends on the tool | Recorded and marked as cached |
| Vulnerability monitoring? | Manual | Usually a separate tool | Built in with CRACI |
Automating with a scanner is a real improvement on a spreadsheet, and it still guesses at what went in. For the reasoning, see why the build is the source of truth.
What happens to your spreadsheets
The component data moves out: versions and packages come from the build, so nobody has to type them. What stays is the knowledge only your team has, such as which products exist, who owns them and which versions are still supported. That is the part worth a person's time.
How CRACI handles this
CRACI replaces your GitHub-hosted runners with faster, lower-cost ones, and records the SBOM as each build runs. You
set runs-on: craci, and your runs still appear in GitHub. Standard builds get a complete SBOM without
configuration. Builds with their own package registries or unusual container setups may need some.
- Recorded, not scanned. CRACI sees the traffic coming into each build, including the hidden dependencies that lockfile-based tools miss. Every component in the SBOM was in the build.
- A completeness state on every job, so that you know when a build could not be fully recorded and why.
- CycloneDX and SPDX export, including transitive dependencies and the vulnerabilities found in the components.
- One view across products. The inventory view shows which software versions are deployed to which products, and CRACI keeps re-evaluating monitored SBOMs.
To roll this out across teams with different pipelines, see SBOM generation across engineering teams.
SBOM automation: frequently asked questions
What is SBOM automation?
Producing a software bill of materials as part of the build, so that every release has one without anyone creating it by hand. The better setups also monitor each SBOM for new vulnerabilities after the release ships.
Can we keep our SBOMs in Excel?
A spreadsheet can work as a first inventory, but it is hard to keep current and it doesn't reach transitive dependencies. It also isn't a standard SBOM format. Customers and security tools generally expect CycloneDX or SPDX, and the Cyber Resilience Act asks for a commonly used, machine-readable format.
Does SBOM automation need a new step in every pipeline?
With most generators it does: you add a step to each workflow and keep it up to date. CRACI records the SBOM in the runner, so there is no step to add to your jobs.
Which ecosystems does CRACI record?
npm, PyPI, RubyGems, Composer, Cargo, Go, Nix, OCI, Debian and Ubuntu packages (apt), Alpine packages (apk) and Git sources, plus Yocto and OpenEmbedded downloads. Maven and Java are on the roadmap.
Which CI systems and platforms does CRACI support?
GitHub Actions today, with other CI systems on the roadmap. Runners are Linux x86-64 and ARM64 today, with Windows and macOS on the roadmap.
What about components we buy from vendors?
You can add vendor SBOMs to CRACI, so that bought-in components are monitored alongside your own builds.
What does it cost?
CRACI charges only for build minutes: $0.002 per vCPU-minute ($0.004 for a default 2 vCPU runner), metered per second, with no monthly fee and no per-SBOM charge.
Replace the spreadsheet with your next build
See a recorded SBOM, with its completeness state, for a build you already run. Book a demo and we'll walk through it with you.
Book a demo