The build-environment SBOM
Useful depth for technical documentation and long-support rebuilds, not the September 2026 Article 14 lead. Start with the product inventory of what you shipped.
Important: Article 14 readiness (from 11 September 2026) is about actively exploited vulnerabilities in products already on the market. A toolchain SBOM does not replace that spine. Use this page after you have product inventory, continuous scan, and triage working.
Most SBOM tools answer one question: what is in my final artifact? For cross-compiled firmware the build environment, compiler, sysroot, SDK, can still matter for technical documentation and for reconstructing the environment that built an affected release years later.
What a build-environment SBOM captures
- The cross-compiler (e.g. arm-linux-gnueabihf-gcc) and its version
- The sysroot and its system libraries (glibc, OpenSSL, …)
- The SDK / BSP used to build the firmware
- Build-time dependencies pulled in during compilation
- The exact pinned versions of all of the above
How alloy-it generates one (reproduce leg)
Because alloy-it describes your build environment as a versioned blueprint, it already knows every toolchain, sysroot, SDK, and package in that environment. Each provisioning event can produce a lock file, an SBOM (CycloneDX/SPDX) covering the build environment, and a CVE scan across it, and link that blueprint to a release as build provenance.
When you must ship a patch years into the support period, the rebuild target is already recorded. See the full CRA compliance checklist →
CRA compliance hub
CRA overview for embedded & firmware
What the Cyber Resilience Act requires, the deadlines, and how manufacturers of products with digital elements comply.
CRA SBOM requirements
Format, scope, and per-version rules for a CRA-compliant product Software Bill of Materials.
CRA for embedded & firmware
Why firmware needs vendor SBOM plus binary-derived inventory, and how HEX/encrypted images differ.
CRA compliance checklist
A practical checklist mapping each CRA obligation to what your team must do.
Vulnerability handling & Article 14
24h / 72h / 14-day reporting, KEV/EUVD, awareness clock, and what Sep 2026 actually requires.
This page provides general information about the EU Cyber Resilience Act and is not legal advice. The regulation and its harmonised standards are still evolving: consult the official EU, ENISA, and BSI sources and qualified counsel for your specific product. alloy-it helps with product inventory, SBOM monitoring, triage, Article 14 evidence, and the rebuild path; it is not CE-marking software, not a notified body, and does not submit reports to ENISA or national CSIRTs.
Start with the product inventory
Article 14 readiness first. Add build-environment depth when you need it for technical docs and long-support rebuilds.