SBOMs in practice: What we learned turning software inventory into continuous security
Why the CRA makes software transparency operational – and how Eclipse Kura and Eurotech’s Everyware Software Framework (ESF) turned it into an engineering workflow.
Software Bills of Materials (SBOMs) are no longer a nice-to-have. Under the EU Cyber Resilience Act, a machine-readable software inventory is a regulatory requirement for manufacturers, and customers increasingly expect one as proof of due diligence before they trust a product on their network. Think of an SBOM as the ingredient list for a recipe for your software: far more reliable to write it down while you cook than to reverse-engineer it from the finished cake. That is why, in line with OWASP guidance, we generate SBOMs at build time, from the toolchain that assembles the software, instead of scanning released binaries after the fact. It is more work up front, but the result is an inventory that is correct by construction rather than inferred.
At Eurotech, we treat that requirement as an engineering discipline rather than a formality: we build SBOMs into our development and release processes with the same rigour, validation and long-term ownership we apply to any other production-critical capability.
My day-to-day work sits at the intersection of industrial IoT edge platforms, open-source development and engineering automation. That perspective has taught me to be cautious whenever a complex security problem is presented as a checkbox. Software Bills of Materials, or SBOMs, are a good example. The concept is straightforward: create a machine-readable inventory of the software components and dependencies inside a product. The implementation is not. A useful SBOM means understanding how the software is built, validating the result and running the infrastructure that keeps analysing it across the product lifecycle.
That is the journey we followed with Eclipse Kura and its enterprise counterpart, Eurotech’s Everyware Software Framework (ESF). It involved several attempts, a build-system refactoring, support from the Eclipse Foundation and, ultimately, a new internal model for vulnerability monitoring across more than one hundred software projects and maintained releases.
The CRA turns software transparency into an operational requirement
The EU Cyber Resilience Act changes the context in which manufacturers manage software dependencies. Its vulnerability-handling requirements include identifying and documenting vulnerabilities and components, including an SBOM in a commonly used, machine-readable format covering at least top-level dependencies.
The timing matters. The CRA’s reporting obligations for actively exploited vulnerabilities and severe security incidents apply from 11 September 2026, ahead of the Regulation’s general application on 11 December 2027. For an actively exploited vulnerability, the first early-warning notification is due within 24 hours of becoming aware of it.
A 24-hour window changes the engineering question. It is no longer enough to know that a vulnerable library exists somewhere in the organisation. Teams need to identify which products and releases contain it, understand its path through the dependency tree, assess exposure and coordinate the response. An SBOM provides the inventory to start that work; it does not do the work itself.
An SBOM is only useful if it reflects the build
Modern software is assembled from layers of open-source libraries, commercial components, operating-system packages and internal modules. A source repository may describe what the team intended to use; the released artefact must tell us what was built and shipped.
There are currently two major competing standards for SBOM formats, CycloneDX and SPDX, but in practice they’re broadly interchangeable. Each carries a slight historical bias, CycloneDX towards security and dependency workflows, SPDX towards licence and provenance management, yet both handle either job, and most modern toolchains can emit either format.
The format is only part of the problem. Components also need consistent identifiers so that vulnerability intelligence can be matched to the right package and version. Package URLs work well when dependencies come from established ecosystems such as Maven, npm or PyPI. CPE identifiers remain important when mapping vendor products, operating systems and hardware to vulnerability databases. In a mixed industrial stack, both may be needed.
This is why we favour generating SBOMs during the build, following the OWASP Foundation’s guidance on dependency graphs and SBOMs. Source scanning can miss build configuration and runtime dependencies. Binary scanning relies on reverse engineering and often loses the metadata that package managers already know. Those approaches help when nothing better exists, but a build-time SBOM gives the clearest link between a release and its components.
What Eclipse Kura taught us about real-world adoption
Eclipse Kura is an open-source IoT edge framework used to connect field devices, process data locally, manage the edge system and integrate with cloud services. Everyware Software Framework (ESF) builds on that open foundation with enterprise capabilities, validation, security features and long-term support. These platforms are often deployed in industrial, energy and transportation environments, where software security and lifecycle management are product requirements.
Our first exposure to the modern SBOM ecosystem came through Eclipse community events in 2023 and 2024. The turning point arrived in 2025, when Eclipse Foundation security training and the early-adopter programme gave us both the knowledge and the infrastructure to move from exploration to implementation.
We were already refactoring the build system for a major release, so we used that opportunity to make dependency information more explicit and SBOM-friendly. By July 2025 we could generate an inventory that was meaningful enough to validate and automate. Once the build model was right, integration with the Eclipse Foundation workflow moved quickly.
From inventory to continuous monitoring
The Eclipse Foundation provided more than a generator. Its workflow automated SBOM creation and upload, while an OWASP Dependency-Track instance supplied continuous software component analysis, vulnerability matching and triage.
This distinction is important. An SBOM describes a release whose dependencies do not change after shipment. Vulnerability knowledge does change when new CVEs are published, severity assessments evolve and additional affected versions are identified. The efficient model is therefore to upload the inventory once for each release and continuously analyse it against updated vulnerability intelligence.
Before adopting this model internally, our vulnerability workflow repeatedly scanned every maintained project and release, in some cases daily and in others weekly. With more than one hundred projects, that was operationally heavy. In the SBOM-based model, generation runs once per release, and the analysis platform performs the continuing monitoring. Developers triage findings in the same environment that understands projects, versions, components and dependency relationships.
This is the point at which an SBOM becomes more than documentation. It becomes shared infrastructure for development, product security, compliance and incident response.
Open-source as a training ground and a blueprint
The Eclipse Foundation’s SBOM programme gave our team a structured environment in which to learn: training, example workflows, a registry, continuous analysis and direct collaboration with security specialists. Eclipse Kura was the practical training ground; the model became a blueprint for our broader Eurotech adoption.
That experience also illustrates an advantage of well-governed open source. The architecture, dependency practices and security tooling are visible. Projects and tools can evolve together: the project exposes edge cases, while the tooling pushes the project towards more explicit and maintainable dependency management.
Transparency that can be acted on
The simplest analogy describes an SBOM as a nutrition label for software. It is a useful starting point, but it understates the operational goal. In an industrial product, the inventory must stay connected to releases, vulnerability intelligence, engineering ownership and customer communication.
The CRA gives manufacturers a clear regulatory reason to build that capability. The engineering reason is even broader: when the next vulnerability appears, knowing what is inside the product changes the first hours of the response from investigation to action. Our experience with Eclipse Kura and Eurotech ESF showed that the transition is achievable, but it is not a file-format project. It is a software lifecycle project. Start with an accurate build-time inventory, validate it, automate it and connect it to continuous analysis. That is how software transparency becomes cyber resilience.
We walked through this whole implementation in a recent webinar, from build-time SBOM generation to the continuous monitoring that keeps it useful.