Bills of materials (SBOMs)
A bill of materials, or SBOM, is the list of every component and version inside a release's image or bundle. When the next widely exploited vulnerability is announced, it lets you answer "which of our releases contain it?" in minutes, and hand customers the list they increasingly ask for.
Why you would use it
A vulnerability is announced in a logging library that half the industry ships. Within the hour, customers start asking whether your product is affected. Without a bill of materials, someone rebuilds or pulls old images to look inside them, one release at a time, and hopes the images still exist.
With a bill of materials stored against each release's artifacts, the question becomes a lookup: which releases carry the library, at which versions, and where those releases are reported running.
Customers and regulators increasingly expect it too. Security questionnaires ask for SBOMs by release, and rules such as the EU Cyber Resilience Act expect manufacturers to know the components in what they ship. A bill kept with the release record is ready when the request arrives.
When you don't need it
If you ship nothing that contains third-party components, or nobody downstream ever asks what is inside your software, a bill of materials has little to answer. Most software that ships a container image or a bundle has both.
How it works in Logmarq
- Kept with the digest. A bill is stored against the artifact's digest, so every release that ships the same content shows the same bill, and a release whose images did not change needs nothing new.
- Generated or handed over. Logmarq generates a bill for a container image pinned to a digest, with Syft, on request or on every record. Or your pipeline uploads the CycloneDX or SPDX document it already makes, for any artifact with a digest; an uploaded document is kept byte for byte.
- Compared between releases. Each artifact shows what changed in its bill since the previous release: packages changed, added, and removed.
- Exported. An artifact's bill as CycloneDX, with its findings and decisions, or as SPDX. A project with a public page can publish them there too.
- Scanned, when you turn scanning on. See Vulnerability scanning.
What it will not claim
- A bill describes what the tool found. Generated bills are Syft's reading of the image; uploaded bills are exactly what your pipeline made. Logmarq does not second-guess either.
- No bill, no answer. A release whose artifacts have no bill says so wherever it matters, rather than reading as having no components.
- Export limits. The SPDX export has not yet been validated against the official SPDX schema or read by a customer's tools. The CycloneDX export built from real Syft output validates against its schema.
Get started
Open a release and its Supply chain section, and Generate a bill for an image, or upload the one your pipeline made. To generate one on every record, add this to the project's configuration:
supply_chain:
generate: true
Related pages
Vulnerability scanning · VEX: vulnerability decisions · Customer-response packages