In the first blog post of this SBOM series, Driving Software Supply Chain Security: Practical Support for Open Source Projects in SBOM Implementation, we introduced our initiative and outlined how we are offering hands-on implementation support to early adopters projects.
The second blog post, Project-Led SBOM Implementation: Our Journey in Empowering Teams to Take Charge of Their Supply Chain Security, examined the challenges of implementing SBOMs at scale and highlighted our approach to complementing direct project support with initiatives that enable project teams to take greater ownership. We showcased the resources and guidance we developed to empower projects to adopt SBOM practices independently.
As the Eclipse Foundation Security Team continues to support projects through both hands-on implementation support as well as independent implementation guides, in this blog post we turn the spotlight on the real-world experience of the projects that took on this challenge.
Eclipse Kura project committers gladly accepted our invitation to share their experience being part of this initiative, as well as talk about the challenges they faced during implementation and the lessons they learned along the way. The insights in this blog post, in the teams’ own words, will reveal valuable takeaways from anyone embarking on an SBOM implementation journey.
An initial challenge to SBOM adoption is that many teams do not actively seek them out - SBOMs often find you. As Mattia Dal Ben, Eclipse Kura committer and one of the main drivers of the SBOM integration, recalled: "Although many of the contributors to Eclipse Kura have strong cybersecurity background, the official Eclipse Kura SBOM adoption journey began at EclipseCon 2023 and OCX 2024, where the Eclipse Foundation security team introduced us to these concepts and their broader implications.", highlighting how awareness often only emerges in contexts where questions about dependencies, risk or accountability arise.
At the time, SBOM tooling was still in early stages and often seen as a niche concern that teams could afford to ignore. Adoption was sporadic, and for many engineers it remained an abstract concept rather than a practical necessity. That began to change as regulatory pressure started to mount, prominently with the U.S. Executive Order 14028 and EU Cyber Resilience Act. As Mattia recalls: “In the following months, emerging regulations such as RED-DA, NIS2, and CRA underscored the critical importance of SBOM implementation and comprehensive dependency management. This became particularly pressing for Eclipse Kura, which is the basis for commercial offerings targeting enterprise and critical IIoT infrastructure, a notably sensitive domain”. These emerging regulations brought on various dilemmas that projects had to face, specifically: “Like many teams, we confronted the classic "make or buy" dilemma: develop custom tooling or adopt existing solutions. We initially attempted to build our own, but quickly discovered that Kura's Tycho 3.0-based build system created compatibility issues with standard SBOM generation tools like the CycloneDX Maven plugin. This realization prompted the need for a set of changes to make the project compatible with the overall requirements to interact with standard plugins for SBOM generation. We took the chance to introduce these changes during the development of our next major release, Kura 6, which introduces major architectural changes and upgraded several build system tools. ”.
Adopting SBOMs quickly became a two-way street. On one hand, projects such as Eclipse Kura needed to make adaptations to fit the capabilities of existing SBOM tooling. On the other hand, SBOM tooling itself continues to evolve, expanding to support a wider range of use cases, languages, and development practices. This dynamic interplay means that both teams and tools are learning from each other: projects shape the development of the tooling, while tooling pushes projects to reconsider how they manage and document their software supply chain.
The Eclipse Foundation Security Team aims to track developments on both sides of this evolving landscape and bridge the knowledge gap between projects and SBOM tooling. To support this, we regularly monitor for emerging best practices, provide infrastructure for dependency tracking, maintain a curated resource library and offer guidance to help projects navigate the growing SBOM ecosystem. Mattia described a moment that changed Eclipse Kura’s approach: “The turning point came earlier this year through a cybersecurity course organized by the Eclipse Foundation Security Team. The course revealed remarkable advances in Eclipse's security infrastructure and tooling, advances that aligned perfectly with the fundamental changes our development team had made to the Kura framework. The timing proved ideal, and the integration process proceeded almost seamlessly, requiring only minor adjustments to accommodate our build system's specific characteristics. ”. By staying up to date with the latest SBOM technologies and lowering the knowledge barrier for projects, we believe we can help accelerate adoption and make these practices more accessible to project teams.
Building on the lessons learned from SBOM adoption and our collaboration, Matteo Maiero, Eclipse Kura Project Lead and Engineering Manager for Eurotech, shared how the insights gathered during this process will be really beneficial in additional SBOM implementations for other products: “The positive experience with CycloneDX and Dependency-Track has encouraged us to extend this approach beyond our open-source project. We are now evaluating the adoption of these tools for our commercial offerings, particularly Dependency-Track, as a replacement for our internal tooling. This shift would streamline maintenance, strengthen our security posture, and align with upcoming compliance requirements such as the Cyber Resiliency Act (CRA).”
The Eclipse Foundation Security Team together with Eclipse Kura will join efforts to share the full story at OCX 2026, offering a deep dive into the challenges, lessons and innovations that emerged from our collaboration, as well as providing actionable advice on how other open source projects can get started with SBOM adoption straightaway. We encourage all participants to attend and engage directly with the teams driving this work.
