# SBOM automation: generate an SBOM for every release
> SBOM automation in CI. Generate the SBOM from resolved components, validate it against SPDX or CycloneDX, and diff it against the last release.
URL: https://factory.com/articles/sbom-automation-coding-agents
Published: 2026-09-24
Updated: 2026-10-23
SBOM automation means producing a software bill of materials (SBOM) for every release without manual steps. To automate it, generate the SBOM in CI from the resolved dependency graph or the finished artifact, validate it against the SPDX or CycloneDX schema, and compare it with the previous release before publishing. Coding agents can add and repair the generator, while the generator and schema validation stay deterministic.
SBOM automation turns a resolved software build into a machine-readable component inventory. Coding agents can add generators, repair metadata, and investigate drift, but they should not claim complete coverage from a package manifest alone. A useful software bill of materials identifies what entered a release, how the inventory was produced, and which gaps remain.
The US National Telecommunications and Information Administration defines an [SBOM as a nested software inventory](https://www.ntia.gov/page/software-bill-materials). Its minimum-elements report groups requirements around data fields, automation support, and practices and processes. Those elements support vulnerability management, software inventory, and license analysis.
## Define the SBOM automation boundary
Name the artifact being described. A repository can produce several containers, binaries, libraries, plugins, and deployment bundles with different dependency sets. Choose the build stage where dependencies are resolved and generated code, vendored packages, operating system layers, and bundled assets are visible.
Select the required format and version, such as SPDX or CycloneDX, based on the consumer. Record the generator version and configuration. Keep stable identifiers and supplier data where the build can establish them. Mark unknown fields as unknown rather than inferring ownership or license data from a package name.
A coding agent should receive the build command, artifact target, existing inventory policy, and validation command. Factory's [delegation guides](https://docs.factory.com/delegations) recommend supplying the desired outcome, acceptance criteria, and verification steps, which keeps an inventory task tied to a reproducible artifact.
## Generate from resolved components
Generate the SBOM from lockfiles, build graphs, container layers, or the finished artifact when tooling supports it. Manifests often contain optional ranges and development dependencies that never ship. A resolved graph better represents the versions included in the output.
Compare a new inventory with the previous release. Investigate added, removed, or unexpectedly changed components. Check that direct and transitive dependencies appear, internal packages have stable identifiers, and files created during the build are represented according to policy. Validate the document against its format schema.
The checks in this section fit in one list that a CI job can enforce on every release.
| Check | Pass condition |
| --- | --- |
| Artifact named | The SBOM describes one container, binary, library, or bundle |
| Format and version | SPDX or CycloneDX, chosen for the consumer |
| Generator recorded | Generator version and configuration are stored with the output |
| Resolved source | Built from a lockfile, build graph, container layers, or the artifact |
| Unknown fields | Marked unknown, never inferred from a package name |
| Schema validation | The document validates against its format schema |
| Release diff | Added, removed, and changed components are explained |
Keep vulnerability scanning separate from inventory generation. An SBOM records components and relationships. A scanner combines that inventory with advisory data and matching logic. A clean scan does not prove the inventory is complete, and an SBOM does not prove the release is free of known vulnerabilities.
## Review and retain SBOM evidence
The pull request should include the generator configuration, validation result, a concise inventory diff, and the release artifact it describes. Avoid committing a generated file when the repository’s policy instead attaches signed build artifacts in CI. The durable requirement is reproducibility and traceability, not a specific storage location.
Stop when the target artifact cannot be built, dependency resolution uses an unknown environment, or the generator omits a package ecosystem present in the release. Reporting those limits gives security and release teams a truthful inventory boundary.
## How Factory keeps SBOMs current
Factory is a platform for running a software factory, where agents called Droids take work from a signal to a reviewed pull request. For SBOMs, the signal is a release build or a schedule, and the Droid's job is to explain changes the deterministic pipeline cannot explain on its own.
Release build
or a scheduled Automation"]
B["Pinned SBOM generator
from resolved components"]
C["Schema validation
SPDX or CycloneDX"]
D["Diff against last release"]
E{"Unexpected change?"}
F["Attach to release
signed build artifact"]
G["Droid opens a review task
explains the inventory change"]
A --> B --> C --> D --> E
E -- no --> F
E -- yes --> G
`}
/>
**Run the check on a schedule or event.** [Factory Automations](https://docs.factory.com/software-factory/automations) start a Droid session on a schedule, from a Slack message, on a GitHub event such as a push to a branch, or from an inbound webhook while that trigger is in private preview. A scheduled or webhook run can use a service account identity and run on a Droid Computer, a persistent environment that keeps installed tools between sessions.
**Review supply chain changes.** Factory's [security review](https://docs.factory.com/software-factory/security-review) includes supply chain analysis, and its published severity scale lists a very new dependency as a P1 finding. That review flags risky components in the pull request that introduces them, before they reach the inventory.
**Keep the generator deterministic.** The Droid adds or repairs generator configuration and opens a pull request. The generator, schema validation, and release diff run as ordinary CI steps, so the SBOM does not depend on a model's output.
## Frequently asked questions
### What is an SBOM?
A software bill of materials is a machine-readable inventory of the components in a software release. The NTIA describes it as a nested software inventory that supports vulnerability management, software inventory, and license analysis.
### What is SBOM automation?
SBOM automation generates a software bill of materials in CI for every release, from the resolved dependency graph or the finished artifact, then validates it against the SPDX or CycloneDX schema and compares it with the previous release.
### Should an SBOM come from the manifest or the build?
Generate it from resolved components such as lockfiles, build graphs, container layers, or the finished artifact. Manifests contain ranges and development dependencies that may never ship.
### Does a clean vulnerability scan mean the SBOM is complete?
No. An SBOM records components and relationships, and a scanner matches that inventory against advisories. A clean scan says nothing about missing components.
### How does Factory help automate SBOMs?
Factory Automations can run a Droid on a schedule or GitHub event to detect inventory drift and open a review task, while the SBOM generator and schema validation stay deterministic CI steps.
## Further reading
- [Container image hardening](https://factory.com/articles/container-image-hardening-coding-agents)
- [Build provenance for coding agent artifacts](https://factory.com/articles/build-provenance-coding-agent-artifacts)
- [CVE explained](https://factory.com/articles/cve-explained)
- [Safer dependency updates](https://factory.com/articles/coding-agent-dependency-updates)
- [NTIA SBOM guidance](https://www.ntia.gov/page/software-bill-materials)