Generating SBOM: Understanding the why, mastering the how & learning from Eclipse Kura's experience

This talk focuses on Software Bill of Materials (SBOM), a crucial component for improving software supply chain security. The speaker, Yana, defines SBOM as an inventory of software components that includes essential metadata such as version and license, while emphasizing its importance in identifying vulnerabilities across transitive dependencies. The session discusses the complexities surrounding SBOM generation, including the challenges open source projects face in adopting them due to competing standards, limited guidance, and the integration of SBOMs into existing CI/CD pipelines. Additionally, the speaker shares insights on an initiative by the Eclipse Foundation to support projects in generating SBOMs to enhance security. Matia follows with a case study on the Eclipse Kura project, detailing their journey of SBOM implementation and the specific hurdles encountered during the process.

Hello everyone. Um, welcome to our talk. My name is Yana. I am um the technic of the security team for Eclipse Foundation. And joining me today is Matia um commiter of Eclipse Kora project and also principal software engineer for Euroch. Um the plan for today and for the next 30 to 40ish minutes of your life is to talk about um asbombs. Um we've structured this talk into

two parts. Um in the first part I will be discussing um like what um I will expl be explaining for someone who's not familiar with the concept what an SBOM is. Then we'll be talking about why they are increasingly important in today's software landscape and why is it challenging for projects to start generating them and start using them to improve their security posture. And lastly, um I

will be talking about an initiative we started at the Eclipse Foundation to um lower the entry bar for SBO adoption and to try to help as many as as many opensource projects to um start generating them. And in the second part uh I will be handing over the mic to Matia who will be talking about his project's um real world story and journey um in ESBOM implementation

and all the challenges they had to overcome to um reach the point where they're at. So these are all the spoilers that I have to give. So I think we can get started um and we can get started with um briefly explaining what an Esbomb is for um some of you who might be unfamiliar with the concept. So um here's the reality that we live in. Um

modern software uses hundreds of third party components. Um so a typical application may have 200 to 500 plus dependencies. Um and most of these are not dependencies that your project team selects. These just um get pulled in. Um so these are never directly um seen uh by someone or managed. Um they just come along um in your project. And this is also case where vulnerabilities um often

love to to hide. Um so there's real risk um the compromise of one such transitive dependency can lead to the compromise of the entire software that is using it. Um so um it's not just hypothetical scenario. Um so you can think about log for shell um when one transitive dependency um logging library affected thousands um of applications overnight. And the issue is that organizations were scrambling to

even figure out for days if they were even affected um not to say reaching um the mitigation stage. Um so this is um the blackbox problem that we're trying um to solve. So how can we say um for sure what is um inside your software? So let's take um a hypothetical example. You're a maintainer of um task management app. Um this has various components that you need

to to pick like a front end framework and so on. you choose some tools uh with a version um and a license. Um but then as you see these components pull in their own and these goes this thing goes layers deep. Um so how can you accurately capture everything that's nested um and comes along with your software? Um this is exactly the the problem that an um

an SBOM or software bill of materials um is trying to solve. So it's an inventory of software components um component metadata. So stuff like version, license, things like this and most importantly their hierarchical relationships. So you're able to um have an accurate snapshot of everything that's comprised within your project. And if the concept is still um hard to to grasp um think of it this way um

a neboom is to your app project. Um the same thing um as a recipe is to to a meat. Um so um in app in your app you might have components transitive dependencies whereas if you were to make chocolate chip cookies you'd have um ingredients um and also you would have um a list of steps on how these ingredients are combined to form um intermediary products. Um

this applies to in the case of esbombs. So, for example, if a batch of flour is contaminated, you would be able to go to back to the recipe and see um did I use flour uh and what kind? Um and the same uh concept applies to um vulnerable dependencies. So, I hope that makes it a little bit more clear. Um and with that, we can move on

to why we need them. Um there are uh a lot of reasons why we need them. Um but the the one to start with um is um for software supply chain security. It's a big that has gained a lot of traction in um in recent years. So basically to uh be able to identify um vulnerable components um in your uh software project and also if things go

really wrong um they help a lot um in the event of um incident response um for security teams to be able to um act fast and mitigate the issue. So when the next log for shell happens, and it probably will, um you'll be able to answer all these questions really fast. Um if you don't have an asbomb, then you will be having to look through a bunch

of source code and uh spend days trying to figure out if you're affected. If you have a sbomb registry, then it's just a query. Um and that's it. Uh, and another driver that I'm going to go through really fast is um regulatory pressure. Um, for example, the CRA uh which is in force uh with obligations kicking in in September and all of these um are converging towards

the the same set of ideas. Um mainly that no release um is created with known exploitable vulnerabilities. Um, and in order to be able to say that about a product, you need to know what is inside the product, including transitive dependencies. And this is exactly where an SBOM comes in handy. Um, so so far I hope that I convinced you just a little bit that sbombs um

are really important. So, if they're so great and they're just a basically a lengthy file, um you might be wondering why aren't more projects generating them. Um and why is it um this a problem that's worth um today? Um well, because um as boom generation grows quite complex. Um as you can see here this is a list of steps that you need to go through u like

an engineer has to go through um to build an automated pipeline that generates an sbomb for every new release of a software product. Um so fairly complex to begin with. Um and then if you you scale it um then it becomes even more overwhelming because one project might contain one product but it also may contain two or 10 depending um on project specifics. Um and given these

products might differ in terms of um platform language um all these workflows to generate the SBO might need um tweaking um and um it involves a lot of time. It's not a plug and play solution. Um and also for context at the Eclipse Foundation we uh have around like more than 400 projects. So 400 projects each with a number of products. We can see that the the

scale um really grows the the complexity. Um so to summarize um the challenges that um projects face in asbomb adoption um there's a really high uh knowledge entry bar especially that maintainers are engineers focusing on on feature work and security. Sometimes it's not um a topic that can take a great portion of their time. Um so there are multiple competing standards. You might have heard about SPDX

and Cyclone DX. And there's also fast changing tooling. So for each um ecosystem language there isn't there there are multiple tools um that generate asbot each with um its own pros and cons. So it's really hard to digest all that information to select which one um is the best for your project. And then there's um confusing integrations um integration with CI/CD pipeline. So you already have your

release pipelines. Where does an SBOM generation step fit in? And um there's limited guidance available on what to do with an asboom after. So there are um regulator there is um regulatory pressure to have them on hand. uh but um there is um no on how to use them to also improve the security posture um of your so um I described um scale uh with multiple products

um per project and al there's maintainer availability and buying um as I said security work rarely makes it on maintainer road maps unfortunately and it's dep prioritize um in favor of um feature work. So um this is the context um we've noticed that um at the foundation and what we try to do is to make committers lives easier um as the security team um and try to

really lower that entry bar for esbomb generation um and we started this initiative doing project collaborations. So, so far we've helped over 15 um early adopter projects. We supported them with hands-on implementation um of sbomb generation and upload pipelines. So now these projects um automatically generate sbombs for all their products and upload them to our um Eclipse Foundation sbomb registry. So they have now the ability to

quickly assess um and mitigate potential um dependency risks um and vulnerabilities. Um this is a table with the projects that have been part of our early adopter groups. Um and variety in ecosystems is not um random. We selected um some of the most popular ecosystem at the foundation and the reason behind that was that we try to um experiment as much as possible and gain ourselves a

lot of experience from all these um hands-on implementation support to then develop um plugandplay um GitHub actions workflow templates. I previously said that um it always almost always require customization. But what at least make some templates available that projects can copy and then just quickly adapt to their needs. We also developed some documentation. I especially recommend the how to generate and upload this bombs for your project

guide. It's really short but it's like the essence of the steps that um a project need to do. Um and we also did um security training for developers. These are also publicly accessible um and online on the on the topic. Um so in terms of resources, this is where you can find our resource library um in our security handbook. um most of the resources are linked to

that and also in the um on the YouTube channel for the So, we highly recommend you check that out if you want to get started with it. And lastly, uh in terms of engineering and infrastructure support, our biggest goal for last year was to have our own um ESBO registry. So, one place where all projects can upload asbombs for all of their products um and for all

um users to go to to assess risk uh for the products that they choose to use. Um so it's sbomb.e eclipse.org and you can um log in with your Eclipse Foundation credentials. Um and we also have upload integrations. Um again uh reusable workloads that you can use to upload your rest bomb quickly. So no token management and stuff like that. Um and in terms of the future,

we want to keep helping more projects and and reaching our resource library with more and more ecosystems. um and also improve um our infrastructure. Um lastly, I want to to make a quick mention that this work is part of an investment um by the sovereign tech fund um a program of the sovereign tech agency. Um we're really grateful for that to improve the infrastructure and tooling um

for open source projects. um to comply with um upcoming regulations. Um so this is all um on my side and now I'll be handing over the mic to Matia to hear real Esboom adoption journey. So thank you. >> Thank you everyone. So let's briefly talk what I will cover in this part of the presentation. Firstly I'll talk about why we decided to adopt asbonds. Then I'll focus

on asbomb generation side of things. How much it took us, what challenges we faced and so on. Then I'll talk about the infrastructure required to generate the sbomb and perform continuous analysis and for vulnerability monitoring. So why bbombs for kura? What motivated us to participate in the early adopter programs? To understand why I have to explain what our project is all about. What is Eclipse Kura? Eclipsecura

is an open source IoT age framework. It performs device management, data collection and processing. It's cloud agnostic and provides multiple connectors for the most popular cloud providers. Essentially we connect to field devices things PLC's PLC's stuff like that manage them grab data from them and shoot uh the data to the cloud. To achieve this, we also need to perform some device management for for example we need

to configure network interfaces, firewalls, etc. What is ESF? We are using an open core model for our software. ESF is the commercial counterpart of Eclipse Kura and shares uh 90% of the code base with additionally we have an extensive add-on ecosystem that allows us to interface with a multip multitude of industrial IoT protocols, cloud providers and so on and so forth. Let's take a quick look at

where Kura and ESF are actually used. It will make sense all in a bit, I promise. This first deployment comes from the TSK group, an EPC company mainly focused on energy uh projects such as renewable renewable energy plants, energy transition and electrical infrastructures. They're using Eclipsecura to monitor photo plants, thermal solar etc. They're based in northern Spain. Then we have Mrise. uh they are a building material

manufacturing company. Think concrete aggregates asphalt and so on. They leverage ESF for fleet telemetics and lab monitoring. This deployment is based in Canada. Then we have uh Arti uh which is based in Rome and they have a fleet of more than 5,000 devices running Eclipsecura for electrical power transmission management and monitoring. Other relevant projects in the transportation sector are the Grand Perry Express and our collaboration with

Deutsban. Additionally, we have very we were recently involved in a project for water infrastructure monitoring and control. As a company, we have much more much more use cases we can show you, but as you can see, these are the main area main areas we work in. So, why bonds? As you might have noticed, our use cases are particularly sensitive from the cyber security point of view. Eclipse,

Kura and ESF are commonly used in critical infrastructure and this implies increased security demands. Some of our deployments contractually require constant monitoring of new vulnerabilities and strict policies for updates. This even without taking into account regulatory compliance and the CRA. In summary, uh cyber security is not optional for us. It is a product requirement, a contractual obligation and increasingly a regulatory one. ESBON give us the visibility

we need to know exactly what is inside our software, assesses assess exposure quickly when we when new CVE emerge and support certification and compliance efforts. With that out of the way, let's focus on our experience with generating asbumps for Eclipse Gura. We first started being exposed to asbumps in Eclipse 2023 and later in OCX 2024. The Eclipse Foundation was instrumental in making us aware of the ecosystem

and its maturity. As you can see, it took us quite a lot of attempts to get as right. Uh I'll get back to that to that later. But spoiler alert, our our build system put us in a bad place for generation. The turning point was June 2025 when we attended the eclipse foundation cyber security training held by Johanna by the way where we were given additional information

and tools that allowed us to go uh further in this exploration. Concurrently we were start we started heavily refactoring our build system for our next major release. We took the chance to perform a field exploration and finally at the end of July 2025 we were able to successfully generate a meaningful ad. From there it took us very little time to fully automate the process and integrate with

the Eclipse Foundation infrastructure. We were so happy in fact that in December 2025 we decided to adopt ESBONS in uh to adopt the same tools at our company migrating our old vulnerability monitoring system to an ESBON based one. You might be asking yourself why did why did it take so long? our build system mainly I don't know how many of you are familiar with the OSGI ecosystem

but we used tao uh for our builds and leveraged p2 repos rep repositories to store part of our artifacts this meant that our dependencies used a mechanism that was completely sidest stepping maiden and thus the most commonly used tools for esbone generation were completely blindsided essentially the cyclone dx maven plug-in was not able to understand our dependencies because they were not being listed as maven dependencies In

the end, since we already had to overall our build system for our major release, we walked the extra mile and refactoried uh refactory that to be more admin friendly, essentially bringing in the dependencies into Maven. I won't cover this much this too much into the details since it's very specific to our uh our project, but audience still using OSGI and Tao. I have the following information nuggets.

take a look at into tao tao 5 uh support for asbond generation which under it leverages eclipse repo sbond tool and above all else good luck okay so uh let's talk about some more generic challenges and limitation you might face when working with elbombs let's start from a pretty interesting one uh as you said asbombs are a list of dependencies used in your project you need to

uniquely identify your dependencies in some so that they can be referenced by vulnerability databases. The main identifier is the PRL or the package. I think that some of you might already see the issue. It is fundamentally built on the concept of package. What about languages that don't have a package ecosystem? current and ESF wraps some C C++ library for low-level protocol stuff and we had quite some

trouble in finding a way to let the tools correctly pick up uh pick them up. This is both a representational problem and a tooling problem. From the representation point of view, how can I have a purl for either for either only library? And from the tooling point of view, how do I recognize a library when there's no manifest nor package? For now, we only have the following

suggestions. If you have if you maintain a CC++ project, you might want to uh adopt and look into a package manager like Conan or VC package or you can rely on OS package managers like AP and uh stuff like that. Some commercial tools uh claim to be able to scan the code and correctly pick up the CC+ library you use, but I I don't have experience with

those. I feel like this is still kind of a an open problem for the S1 ecosystem. Speaking of tooling, uh what tools should I use to generate my asbombs? Uh as Yana said, uh there's a lot of uh choice here. It depends. It depends on your language, build system, package manager. There's no end all be all solution that I'm aware of. Also, keep in mind that some

tools only generate spdx sbombs. Remember, that's two major competing sbomb standards at the moment. But you should always be able to convert one framework to the to the other with some limitation. Here I listed some of the tools we used uh use and used at urek. Uh one thing to note about is uh cdx gen. We tried using cdx gen in the jar scanning mode due to

our issues with the with the build system. I don't recommend it since it essentially works on huristics to infer package metadata but h it might be the best available solution in some situations. So yeah one of the challenges in ify is finding the right tool for your project. Let's say we now have an asbomb. How do I check it is correct? There's no good answer to this

question. Uh in our case, I manually reviewed 200 dependencies crossstacking with our notice file. It was not fun. Um this basically boils down to having a human go through the sbomb and uh and see if it makes sense. Please note, do not try to read the asbomb JSON as is. Uh use something like dependency track to parse the asbomb and visualize the data. Thank me later. Speaking

of dependency track, we should now tackle the infrastructure part of this talk. So the process of generating sbombs varies slightly depending on the technology stack used. Uh but the approach remains the same. Generate one automatically when the software is built and once the bone is produced the components within can be tracked and continuously analyzed throughout the software life cycle. Software component analysis tools are specifically designed for

this purpose. In other words, generating an ESBON in only one is only one piece of the puzzle. You need tools and processes to continually analyze and monitor them. Fortunately for fortunately for us, uh the Eclipse Foundation provides all what we need for this goal. The foundation hosts as Yana said the Eclipse Foundation as registry in the form of a dependency track instance. Dependency track is a software

component analysis platform developed by OASP. You might have heard about them. In layman's term, it ingests. It periodically queries known vulnerability databases like the NVD, GitHub advisories and so on and so forth and matches the vulnerability found on these databases with the software component listed in the admin using the URLs we already mentioned. Let's take a a quick look at how this works. Um really simply upon

pushing but you can actually change the trigger. The GitHub action the GitHub action is triggered. The GitHub action will then generate the ESBON and upload the JSON on the on Eclipse autodog which then is responsible to uploading the artifacts uh on dependency track. The reason for fordog being the middleman is due to permission limitation but you don't need to worry about that. You just need to know

that alter dog is a requirement for being able to upload as on the eclipse foundation dependence direct instance. At UERT, we already had a vulnerability monitoring and management process in place, but it was getting quite old and quite expensive. It was set up long before the ESBON ecosystem reached the the maturity we see today. Once we adopted Esbon in our open source project, we realized how big

of an improvement it would be and decided to adopt it internally as well. The Eclipse Foundation infrastructure was both a training ground and a blueprint we could adopt internally for our own process. So let's take a look at what it meant us internally. Let's start with the old infrastructure. We relied on a proprietary piece of software responsible for scanning our project for vulnerabilities. The output was a

proprietary again format which reported it each CVE affecting the project dependencies. Then uh we had uh Jenx automation responsible for downloading this report and with an internally developed developed tool we would download additional details from the MVD and open a ticket for each new CVE on a Jira board. Then developers would perform triage on new uh on new CVE on that board. Since the output of the

tool was a vulnerability report, we needed to perform the scan at least once per week. For some projects, the scan was performed on a daily basis. To give you a sense of scale, we have more than 100 projects between OSS, Kura, and ESF addons, etc. Each of them with multiple releases. We had to run this job once per week for every project for every release. Suffice to

say, AWS was quite happy with with our build. We then decided to switch to an Essombbased workflow, which is much more efficient. We simply have a job that run once per release, not once per week, which uploads the ESBON to our own dependency track instance. Why does it need to roll to run only once per release? The output here is a list of dependencies, not a list

of vulnerabilities. Vulnerabilities changes changes over time as more are found. Obviously, the dependencies are set in stone once you release your project. Also developers now perform triage uh directly on dependency track which supports this kind of workflow extremely well. Finally a couple of words about migrating our infrastructure. Uh as Yana said with more than 100 project to monitor we felt that the overwhelm at scale she mentioned

we are still working on it but the model provided by the Eclipse Foundation and the knowh how we acquired really simplified the process. We really think that this approach should serve as a blueprint for companies like Aerotch starting to adopt Abbons. This also let us appreciate the work the foundation went through to build this its infrastructure and supporting the ASBON adopters project. Replicating everything on our end

uh was no joke. So that's everything on my end. Uh if you have any question for both me and Yanna. Okay, we have question there. two questions. Okay, >> mostly not a hard one. >> Um, yes. So, thanks for the for the presentation. Um, is there any momentum to uh yeah collaborate in the evolution of dependency track? Because at the moment, as I know it from some

tests weeks ago, the dependency track is not able to monitor the European vulnerability database. Is that correct? >> Sorry. >> The vulnerability database of the European Union. SAP. See also keeping in mind that dependency track is an open source project so everybody can contribute and I've seen a couple of issues that we faced during the integration that were addressed. test during the time that it took us

to prepare the presentation. Uh for example, the notification they added recently the filtering of the yeah the critical vulnerabilities. So it Yeah. >> Okay. And um the next thing about the instance of dependency tracker of Eclipse Foundation is this open to non Eclipse member companies or is there any business model that we can buy in or How it works right now. Everyone maybe another question. Thanks a

lot for the presentation. Uh so it's like two questions. Um the first question would be like I think GitHub is also working on different tools and workflows and also in the insights tab. Uh have you looked at this and why are you guess what are the reasons why using like >> If you want I can answer this one because I looked into it not too long ago.

Um GitHub does provide sbombs but it is quite limiting. It only produces asbomb for the head of the git the the the top branch and only in spdx format. Uh so it depends on how you for for us it wouldn't work us because we have a different branching policy. Uh we need to maintain also um all the all the releases which can uh diverge from the dependency

point of view from the head branch. So uh essentially we it wouldn't work for us. It doesn't mean that it wouldn't work for you. So you you need to look into that. But it is quite more limiting than having a a custom deployment a custom setup like the the one that is provided by auto the GitHub templates provided provided by the G foundation plus the dependency track.

>> Okay. Thank you. And the second question is am I right that the like the sbomb is not included directly inside the repository because it's uploaded like I think different Eclipse projects still have this dependency file that's generated with uh the dash tool for example which is also like an an sbomb but more or less for checking the licenses. Yeah, Thank you. Um I have a combination

of questions and and remarks maybe to the uh previous uh questions. So uh just about the European uh vulnerability database thing. So I I've been looking into that as well and I think one of the problems is that it simply doesn't offer an API yet to query vulnerabilities by Pearl for example. So it's quite useless currently. It's just a database that you can browse in the web.

But there is no real rest API or so. Then maybe just sorry for to to amend what you said about the quality of asbombs generated by GitHub dependency insights. It's it's very poor quality. It has very limited support for only a few technologies. So don't bother with it. And also the yeah that the quality of the asbombs being generated is very poor. There's very little metadata in

there and the metadata that's in there is not correct in all cases. Now to the real question. So um sorry short maintain disclaimer. So um I'm the maintainer of a tool called OSS review toolkit and I'm also a contributor to the Eclipse apps project which creates the O server based on the OSS review toolkit. I'm I'm just curious since it is a complete compliance suite to generate

sbombs whether that was also part of your evaluation. So the Eclipse po project is called Eclipse apps and it's a it's a server basically similar to you could say dependency track but dependency track has a few limitations for example it's not an SCA platform it cannot perform software composition analysis by itself you have to import sbombs and in that sense Eclipse apps is more complete because it

will analyze your codebase from the outside it supports tao python java whatever that um can query vulnerability databases, various ones uh all the ones that dependency track supports plus more and blah blah. So uh I I just wanted to know whether you're aware of the project and if you're not we should probably talk offline. >> I'll answer this one if you don't mind. Um so like when

we decided to go with dependency track uh apothesis was not yet created at the at the foundation it was not a naked foundation project. Uh so we were of course we were aware about but not about apothesis and server. Um we took the decision to go with dependency track because we wanted to promote the the sbomb generation at build time. ORT is heavily promoting that the SCA

capability that it has and uh that we we thought that we would want to promote best practices to projects to generate asbomb at build time so that we get the more the most accurate information. I know that is very good at it as well. It generates much better information much better asbomb than github as you said. Um but I would like to complement also this center by

the fact that we are using um something in the middle between the project and dependency track. Uh currently it's autodog. We will replace that with something else. Um nothing prevents us from adding one more tool or one more registry that would provide us with additional feature uh that dependency track would be um not providing today and that maybe epopsis would be in the future.