What is an SBOM — and how to create one without a DevOps team

An SBOM — Software Bill of Materials — is exactly what the name suggests: a structured list of every software component inside your product, the way a physical bill of materials lists every bolt and bearing in a machine. Component names, versions, suppliers, and how they relate to each other, in a machine-readable file.

Until recently, SBOMs were a nice-to-have from the security world. The EU Cyber Resilience Act turns them into a legal requirement: manufacturers of products with digital elements must draw up an SBOM covering at least the top-level dependencies of the product. If you sell connected hardware, firmware, or installable software on the EU market, an SBOM is now part of your technical documentation.

Not sure whether the CRA applies to your product? Run the free 3-minute scope check first.

Why regulators want a parts list for software

Modern software is assembled, not written from scratch. A typical application contains dozens to hundreds of third-party components — open-source libraries, SDKs, an RTOS, drivers. When a vulnerability like Log4Shell surfaces in one widely used library, the urgent question for every manufacturer is: are we affected?

Without an SBOM, answering that question takes days of digging through build files. With one, it takes a database query. That is the entire point: an SBOM makes your product's supply chain searchable — for you, and for the customers and authorities who may ask.

Under the CRA this becomes operational, not theoretical: from 11 September 2026 you must report actively exploited vulnerabilities within 24 hours of becoming aware. You cannot assess impact in hours if you do not know what is inside your product. The SBOM is the foundation the reporting duty stands on — see our deadline guide for the full timeline.

The two formats: CycloneDX and SPDX

Two open standards dominate, and both are accepted:

• CycloneDX (OWASP): security-focused, JSON-first, the most common choice for CRA purposes and the easiest to generate with modern tools.
• SPDX (Linux Foundation, ISO/IEC 5962): older, license-compliance roots, widely used in large enterprises.

Practical advice for a small manufacturer: pick CycloneDX JSON unless a customer specifically asks for SPDX. Every serious tool can convert between them.

A minimal SBOM entry describes one component — name, version, ecosystem, and ideally a purl (package URL, a standardised identifier like pkg:npm/express@4.18.2) plus a hash. Multiply by every dependency and you have your file.

How to generate an SBOM — three situations

1. You have a modern build (npm, pip, Go, Rust, Maven…)

This is the easy case. Your lockfile already contains the full dependency tree; an SBOM tool converts it:

• Syft (open source, free): point it at a project directory or container image and it emits CycloneDX or SPDX in seconds.
• CycloneDX generators: official plugins exist for npm, Maven, Gradle, pip, .NET and more, and can run as a build step so every release produces a fresh SBOM automatically.

If you do nothing else this week: run one of these once and look at the output. Most teams are surprised by how many components they actually ship.

2. You build firmware or embedded software

Harder, because dependencies are often vendored — copied into the tree — rather than declared in a manifest. Three routes, in order of preference:

1. If you use a package-based build system (Yocto, Zephyr with west, PlatformIO), use its SBOM support or manifest as the source of truth — Yocto and Zephyr can emit SPDX natively.
2. Binary analysis: tools can scan a compiled firmware image and identify embedded open-source components. Useful for legacy products where the build knowledge is gone.
3. Manual inventory: list every third-party component you consciously include — RTOS, TCP/IP stack, crypto library, bootloader, vendor SDKs — with versions, and maintain it as a spreadsheet that you export to CycloneDX. Less elegant, fully acceptable: the CRA requires top-level dependencies, not a forensic bit-level analysis.

3. You inherited a product and nobody knows what is inside

Combine routes 2 and 3: binary scan for discovery, then a manual review to confirm and complete. Budget a day or two — it is one-time archaeology that every future release builds on.

The five mistakes that make SBOMs useless

1. Generating it once. An SBOM describes one version. Regenerate on every release — automate it in CI if you can.
2. Forgetting the firmware side. Teams SBOM their cloud backend (out of CRA scope) and skip the device software (in scope). The product on the market is what counts.
3. No identifiers. A list of names without versions or purls cannot be matched against vulnerability databases. Always include versions.
4. Treating it as a compliance artifact only. The SBOM's real value is operational: feed it to a vulnerability scanner so new CVEs in your components trigger alerts. That workflow is what makes the 24-hour reporting deadline survivable.
5. Waiting for perfect. A top-level SBOM today beats a complete dependency graph in six months. Start, then improve.

What "good" looks like for a small manufacturer

• One CycloneDX JSON file per product, per release, stored with your build artifacts
• Generated automatically where possible, manually maintained where not
• Matched against a vulnerability database (OSV, NVD) on a schedule, with findings reviewed
• Referenced in your CRA technical documentation

That is the whole discipline. It costs an afternoon to set up with free tools, and it is the single most load-bearing piece of CRA compliance — the SBOM feeds your vulnerability monitoring, your 24-hour reporting readiness, and your technical documentation. Our CRA compliance checklist shows where it fits in the full sequence.

Step one is knowing your obligations: check your product's scope and risk class free — it takes three minutes.