# The Rise of SBOMs and Software Supply Chain Security

**Podcast:** The InfoQ Podcast
**Published:** 2026-04-13

## Transcript

In mobile application security, good enough is a vulnerability.
Guardsquare delivers the highest level of security for your mobile apps without compromise.
Discover how Guard Square provides industry leading security for your Android and iOS apps at GuardSquare.com.
Hello everybody, I'm Olympia Pope, InfoQ editor.
And I have in front of me Victor Peterson.
And he will try to bring more details about what happened in the SBOM part, especially with the legislative changes, and also what's actually really important for us to know as developers without having the big stick looking at us.
Victor, you have a couple of things that you're working on.
So please give us a short intro on what you're doing.
Thank you so much for having me.
A quick intro, done a few startups.
We had a mandate as part of that to start doing S Bomb generation for our product.
I thought that would be really like a TikTok exercise done in a week and move on with it.
Turns out it wasn't quite that straightforward.
So I kind of got really deep into that.
I ended up joining and co-chairing one of the working groups at Cisia back in the when Cisa was active in the S Bomb world.
And we ended up creating a white paper on S Bomb generation.
That in turn turned out to be a lot more interesting than I expected.
And I actually ended up creating a new company called Sponify where we implement that blueprint from the working group in basically letting you create high quality S-bombs because it's actually a lot more challenging than most people realize.
So that's that was kind of the goal there.
Thank you.
It's very important because the supply chain attacks are getting more and more pervasive, especially nowadays.
But actually, it's not the easiest thing to push because a lot of the people are just looking into and they feel like it's yet another certification, or it's something that it's coming from outside.
And actually, I think starting with this year, it's true, especially for the European Union.
The cyber resilience act, the Psy RA is coming to force.
I think the US has some legislation in place.
I know that the UK spoke about it, so maybe let's start from looking at the sticks before going to the carrots.
So S bombs have been around for a long time, right?
They're not new by any means.
But what we've started to see over the last few years, starting with the executive order 49, 89, I believe it is in the US.
We basically moved already selling software to the US government were required to start providing S bombs.
That was kind of the first stick, as you say, for software editors to start generating S bombs.
The much bigger stick is to your point, CRA in Europe.
And the soft enforcement window starts this year.
And I would say that most people are fully unaware that they are going to be impacted by this.
And just for those who are not familiar with CRA, it's a piece of legislation that affects anybody selling products into the European market.
And the litmus stuff they use in the legislation is obviously intentionally vague.
And the idea is basically to make it anything that connects to the internet more or less needs to be compliant with CRA.
CRA in turn requires you to generate S bombs.
So that's kind of why we're here today.
So that means that pretty much any electronic or software should have an S-bond.
Or well, actually the label showing the ingredients that are in.
So that's scary.
Yeah, I mean, so many people are fully unaware of this.
And it's kind of a GDPR moment, I would say for Europe.
But I guess people are less aware of this than they were about GDPR in many ways.
But unlike GDPR, where the stick was large fines, the stick here is having a product block from the European market, which is a much, much bigger stick than just fines, as you can see in the case of Meta and these big boys, they just assume the cost of GDPR fines essentially as a cost of doing business in Europe.
They learned from this, and now it's the blocking of the market, which is a much greater stick to hit with.
What they particularly liked about the way how the CRA came to being was the fact that the community was quite involved.
And it seemed that the EU learned and actually listened.
And I don't want to be on that side of the fence of the regulators, but I have to be happy as the consumer of digital services and digital products and also AI about these two points.
The DAI Act, that's not in the focus of our discussion, but also the CRA, because actually you saw it.
What I'm afraid currently is the way how it will come to be implemented.
And that's especially from the way how the European Union is built.
So now you have the legislation in place, and then it's up to each of the countries of the European Union to implement it and to give it shape.
I think Germany is one of the countries that already has a formal for that.
Yeah, Germany's BSI is the first kind of real implementation.
I think they're in two point two now of their interpretation of that talk has been kind of uh evolving.
But just bringing back to your previous point, and I'm not a fan of heavy-handed legislation either.
But I think it's important to acknowledge that security is a market failure.
We've seen this for so long, vendors do not care because it's not in their interest, my financial perspective, to invest in security.
And the consequence of that is uh baby cameras being exposed publicly on the internet and and so forth.
So I think there's a good reason why this exists, because it's the market really failed to like self-regulate, I'd say.
Yeah, and I think it's very important to take that responsibility and people that are actually part of it to do it.
But on the other side, what are the benefits for us as software developers, practitioners?
Because it comes with added benefits as well.
Let's look into those things.
What would be useful from your perspective as a developer for other developers to know about S-bombs?
Yeah.
If you purely treat this exercise as a tick box exercise, where it's just I'm doing this for the sake of being compliant, then you're not really reaping at the benefits of generating this.
And you're creating a lot of work for no remote word, right?
But the reality is like if you actually make this operational, and a lot of companies are already, this is not theoretical.
A lot of companies are using this heavily as part of their workflow.
They're using S bombs to do security audits of their code base, and they're using it to do a license compliant audits of their supply chain, right?
So a lot of companies have policies for we're not allowed to use, say, GPL B3 code in our source code or in our library.
So that's you can use an S bomb for license compliance audits.
More commonly, it's used for security audits.
If you can generate an S bomb from a log file, you can then in turn find CVEs that are affecting.
And the ecosystem is a bit more mature because there's there's also something called VEX that goes on top of this, where you can say, yes, I'm affected by the CVE, but this C V impacts this particular function in this library, but we're not using that.
So you can issue what's called the VEX statement and say, yeah, I can do the CV because we're not impacted by it.
So it's a bit more sophisticated than what you would have in, say, the Pendabot in GitHub, where you're just saying, hey, here's the vulnerability, this library, upgrade.
Because sometimes that's not necessarily the best path forward, right?
So I think if you're using it operationally and you're actually using the insights from this, it becomes a very, very powerful tool.
And you can diff different versions and see exactly how libraries evolve with time and so forth, right?
So there's a great amount of utility in this if you actually use it properly and you actually use it as an operational vehicle rather just busy work to be compliant with regulation.
So we shouldn't treat it like SOC2 where ISO certification is a chore that you have to pass through.
I mean, I I think that Nagy holds true there as well because if you look at SOC2 and ISO and all the controllers are underlying, the controllers can be very helpful, right?
In order to ensure your compliance with the framework, because they're not made out of thin air.
Like I'm not saying they are perfect, but they do help you improve your security.
And if you use it to help improve your security posture rather than just farming off to some kind of team that has no real involvement, then yes, you have no utility.
So I think there are a lot of analogies with compliance and S bomb generation in general.
Yeah, I agree with you.
I'm not talking about the content because obviously there are good practices into that.
I'm just about the the way how actually companies or individuals in companies are looking to that and just waving, okay, that's something that we have to do and just an Excel to have to fill in.
And it's very interesting, especially as there are points when you don't even know that you have a library.
I'm just thinking about the log4 shell.
Well, that's ancient history already, but it was probably one of the biggest security holes, especially in the Java ecosystem since the era of Apache Strats.
And what was funny is that at that point of time I was working in a company that had built everything on top of the JavaScript ecosystem.
So it was Node.js and all the source, and everybody's like just cocking around that okay, we are not affected, then blah, blah, blah.
Two hours later, we got an email from GCP saying that unfortunately, that service and that service and that service, and also that service that we are using currently for a couple of our customers are all affected by Lock4 Shell, and they have to put it offline because we didn't have anything to do.
And where do you stop?
Because that was always a question for me and also for the audience when discussing about S-bombs, because it's like an iceberg, and everything is built on top of the other stuff and so on and so forth.
And then if you go recursively, you have to start somewhere in terms of your references.
How should you approach that kind of problem?
It's a fantastic question.
I think the first thing to flag there, it's that ecosystems have very different maturity levels.
And even within a given ecosystem, you have very different quality of tooling, right?
Because ultimately, most S-bombs are generated from log files.
And log files vary in quality a great amount.
But I think the first thing when you go on your SBOM journey that you realize is that you actually do have to capture things in lock file.
So going down the example of JavaScript, for instance, if you want to actually do SBOMs for your JavaScript stack, you can't just like load things and include in a header.
You need to have them in a lock file and not just start with that.
So you actually trace that.
By virtue of doing that, you have an inventory.
And that is like, regardless of the SPA or not, that is a step in the right direction because now you know what's going into your software.
So I think the first discipline of leveraging lock files and having good lock files is the first principle that is really, really important here.
Now we talk about transitive dependencies, and that is kind of a slippery slope, right?
Because you could say, well, I want to know everything down to source code, right?
But I think it's a very, very ambitious goal for most companies right now.
I think if you can start by focusing on your application library dependencies as the first initial target, that's a really good starting point.
Then capturing operating system dependencies is kind of easier in many ways.
I would treat them as different problem spaces, and I would definitely treat them as different SBOMs.
But capturing that is easier.
Now it gets really difficult in the case of Docker, for instance.
What if you have a Docker file where you're copying things in and so forth?
There it gets it a bit more complicated.
It's a solvable problem.
But I think one of the most important things is when you're starting your SBOM journey is that you start doing a sanity check and an inventory check.
And I've seen this firsthand when we started doing this in one of my companies.
We're like, oh wow, we forgot about this.
That hasn't been touched for a while.
Or you realize that I'm just going to use the Python example.
Requirements.txt has been kind of like the standard for a long time in the Python world, but it makes no guarantees that it captures all the dependencies, right?
Because it will happily, if you do pip install dash r requirements.txt, it will happily do the tree expansion and pull in dependencies so that your lock file is not capturing that at all.
And it also doesn't do hashes and so forth.
You can, but it's not built in.
So I guess what I'm saying is by going on that journey, you start to realize that there are more modern package managers out there that do a better job that will capture dependency tree much better.
So in Python example, moving to something like UV will give you not only a performance boost, but it also gives you a much higher quality lock file that will actually capture transit dependency much better.
The same is true for the JavaScript world, right?
You look at new packet mesh like Bun, for instance, which generates a lot better lock files than just having a package of JSON, which may or may not be pinned properly, right?
So I think that is one of the biggest wins that you get from day zero without even using the S bombs by just getting onto that journey, you end up having high quality software.
So just to frame, the main idea is that log files are quite important.
And there is a good moment on this journey to revisit what you're actually using in terms of tooling, build tools and the infrastructure.
You pointed Python, which was quite known for its inconsistency and especially typo squatting and other types of attacks, or um the NPM ecosystem, which again had its challenges, but just listening to you is that I I think we were both two engineers that try to overengineer a problem that theoretically shouldn't be like that.
Because actually, if you think about it, all these pieces that we're looking into are all digital products, and actually they should come with their own S bombs.
So our direct dependencies will be more than enough given that theoretically speaking, in order to be compliant, each and every company should have their own S bombs.
And then that will go at uh at a different level.
So I I would start with like that tax surface almost, right?
So, like if you're looking at any application, it's the application stack that is exposed.
So starting there makes sense from a security perspective and to do an inventory check to start with, right?
Because then obviously there could be operators in vulnerabilities as well.
But but your most common attack factor will be the application layer.
So that's kind of where you want to start regardless.
And it's probably less, yeah.
I would say the application system is usually more hard anyways in the first place.
Okay, so look at the dependencies in the application layer, and then look at the other ones.
Because around your presentation, we spoke or I spoke a bit with Alex Zenlaff from uh Edera, and obviously he's at the hardcore level of the operating system.
And I know that they have a lot of work into that part where they are just saying that rather than going always with the only tool that is out there in containers, maybe a micro virtual machine would be better, especially if you can have this kind of attacks and something sensible.
So I think there is a new wave of tooling and a lot of people that are doing a lot of excellent work.
So I think we should open our ears besides having the SBOM in place.
Absolutely.
I couldn't agree more.
But the one thing I would say is that 99% of all the people that is going to be impacted by CRA.
They are not the hardcore engineering companies that's gonna look at like the latest hypervisor technology to speed up the runtime.
They will be companies that they have some kind of source product or they have some kind of product in the market.
They're not necessarily engineering first companies.
Engineering is a cost center to a lot of these companies, and they're just gonna look for the quickest solution, right?
So I think it's important to highlight that.
Yes, that's great, and there are great ways to solve that, but we still shouldn't forget about the easy button for the vast majority of the companies that well needs to be compliant.
So, first and foremost, it's a good place to start the application level, look at that, have the SBOM in place.
Then there are two different things.
One of them is we can use that operationally, so we can consume ourselves the S-BOM in our continuous integration pipeline to ensure that whether there is a CV, there is uh a new problem out there, we know whether we are affected or not.
As you mentioned, it might be the case that we are not actually using that particular part of the code.
And it's about being compliant.
So, from the legal point of view, the compliance department will want to know what kind of libraries are we using in terms of generating that.
And then it's about regulatory, and that'll start coming in place, probably starting with next year.
Now it's still just a transition period, so probably that will happen moving forward.
You had a couple of other interesting points.
One of them is the S-bomb is not something that you should generate on your PC, but it should be part of the process in the living organism of your pipeline.
Care to elaborate a bit on that?
Yeah, I think again, going back to the whole CISA working group that we spun up, like one of the hard requirements we had as part of our recommendation for generation is that you must do the generation in a CI CD pipeline.
And this ties very closely to the importance of signing S-bombs.
How you sign them doesn't matter so much as the fact that you do do it, so that you can trace it all the way back.
But in particular, if you're looking in the embedded world, for far too long, firmwares have been firmware has been built on somebody's workstation, right?
And then they just shipped off over some like unsecured mechanism.
Tooling has got a lot better.
Look in both like Cephir and Yocto, these tools can be built in the CI pipeline now, and they can generate SBOMs and they can be signed in the pipeline.
But it's important that it becomes part of your blueprint, right?
That it becomes part of the CI CD fabric for all the projects across your company.
So do you have a unified way of doing this and you also have a good paper trail.
So like if you want to traverse backwards you can go back and look at the SBOM from a given release historically and diff that or do things operational with that data right so that again it becomes useful rather than just busy work.
So I think why it's important doing the CI is because of trust right because then you have a reproducible way of doing it at least you have proof of attestation of how it was executed and you can work backwards and you can see that trape trail.
I'm smirking because I know at least a handful of people from FreeBSD that when you say that that's reproducible they will have a lot a lot of things to debate around it especially with free PSD which they are very eager on generating everything up to the last bit.
So then the important part is signing and using let's say machine infrastructure so something that you don't have humans touching it.
So it's the reverse trend as with AI in the AI space you want human in the loop.
Here it's important to have safe infrastructure, safe machines that are ensuring that first of all it's generated in a constant manner.
And as you said, up to a point, it's something that it's more or less you have a paper trail and something that is auditable.
And on the other side is you know exactly how it was, and you have the digital signature on it that ensures that was not tampered to it.
And the reason why this is even more important in the world of SBOM is because that SBOM will most likely be sent off somewhere else to some kind of platform.
So I mentioned in my talk a project that I'm involved with called Transparency Exchange API, which is kind of the discovery mechanism for downloading and discovering security artifacts.
In the context of that, the signing becomes even more important, right?
Because how do you prevent that to be tampered with in transit, right?
So in the case of in example as we do with Sponmify, one of the core premises for us and core fundamental beliefs in us that you should never have to trust us as a distribution mechanism.
You should always be able to work your way back to the CI CD pipeline where it was signed, so that we have not made any alterations to that document.
So you can always traverse back.
You never have to trust us or whatever T provider you're using.
You don't have to trust them.
You can all the way go back.
And I think that's a really, really important philosophical concept in the S bomb supply chain.
Thinking back, there were three pillars of the supply chain security a couple of years back, the point when I was more focused on this topic, and those were the SBOM.
So the ingredients that are going in the cake and the ability of tracing all of them, as you mentioned.
Then it was about the signatories, about uh a notary where you just have this information, and I suppose that's maybe TIM, but you have to correct me if I'm wrong.
And then it was the ability of reproducing it, the reproducibility of the content that you have.
But let's go first with the TEA.
So TE is basically a standardized API that you can discover.
So I'll give you an example.
So if I pull a box like this from a store, right?
And it has a barcode.
With T, all that I need to know is that barcode or SKU.
And combined with the company's domain, I can find security artifacts.
So it's a standardized discovery mechanism that allows you to find the artifacts.
So it's not a storage mechanism.
It doesn't do attestation, it relies on attestation back from the source, right?
One of the most common ways of doing S bombs today is to use like the six store ecosystem, right?
And that's very well integrated in GitHub already.
So that's kind of what we recommend people do it.
But there are other ways to do it.
And the reason is in T we provide the hashes and so forth, but the hashes are kind of useless if you can't work your way back to like the source, because that could be tampered with, right?
In transit.
So this is actually the mechanism through which you have the ability of checking the information that's out there, right?
Let's say you you have like a yogurt or whatever food product, you have the ability of actually knowing what's inside, and that's the ability of checking it.
Well, it's more like imagine if you're an electronic store, right?
And you're picking up like a webcam, or well, maybe a surveillance camera is a better example because it's gonna be more connected, right?
But if you can find the barcode for that product, and if they have adopted T, you can work your way all the way down to the S-bomb, right?
And and that's really a really powerful concept.
And in terms of adoption, how far along is it?
So T is part of ECMA, and we are aspiring to become an ISO standard.
And we're going into standardization for ECMA at uh middle of tail of this year.
And it lives under OBASP and Cyclone DX, which in turn is connected to ECMA.
And the idea is to become like a fully, fully standardized process so that it will be gaining more adoption.
There was an ISA paper published this week, and they kind of highlight T as one of those mechanisms as well.
So I think we're gaining momentum.
To my knowledge, there are only two implementations of T that are open source out there.
So Rearm and Splumify are the only two implementations of T right now.
But there will probably be more to follow.
As you mentioned, T is coming as a maybe a spin-off or from the group that brought also Cyclone DX.
So from OWASP.
Yes, but it's important to note that T is vendor neutral, right?
So it's not biased towards Cyclone over SPDX, for instance.
Yes, the distribution mechanism.
Yeah, I agree with you, but uh I also agree that we in technology we are like football fans.
And if we if we were born uh cheering for a football team, it's seldom the case that will change it.
And that's why I'm saying that there used to be three standards that are pushed up front for the S bombs.
Now SPDX and Sightmon DX are actually the ones that gain more momentum.
And that's my hope that C will be actually vendor neutral and adopted all over the place, regardless of the format that you use.
Yeah, it also goes beyond S bombs, right?
So it's important to stress that T is a security artifact discovery mechanism.
So it's not just limited to S bombs.
It could be VEX files, it can be compliance documents.
So it goes beyond just S bombs as a delivery mechanism.
Okay, so going back to your surveillance camera that I just bought from the shop, scanning the barcode might bring okay, but maybe some VEX files, some S bomb files, maybe some advisories.
Yeah, manuals or anything you want, really, right?
So it's actually everything that can affect my security by using this product.
Yeah.
So you could discover, for instance, that oh, this device is using an end-of-life software or a very, very outdated software.
You can maybe decide that actually I don't want to buy this camera because I don't want to use somebody that is using an EOL version of I don't know, insert blank framework or insert blank operating system.
The regulatory boards, when coming and checking, they might ask you about S bombs, so ingredients that went a couple of releases back.
How can you approach that in a stress-free manner?
The answer is it depends.
This is one of the things that people haven't realized until they start doing S bombs.
And I didn't realize this until we're doing S bombs.
And this is literally why Sponify was born, because of the problems around that we discovered firsthand when doing S bombs at scale.
If you're an open source project, stashing your S bombs on GitHub makes perfect sense.
You just make it part of the release artifacts, and voila, now you have an easy way to look back and traverse back in the history.
If you're selling a commercial product, it gets a lot more difficult.
And this is where people, when they go on their SBOM journey, only start to realize because even a relatively simple product will have not one SBOM.
You probably can have 10, 20, 30 S bombs because there's the back end, there are containers, there is firmware, there are so many things that makes up a real product, right?
And your S bomb needs to represent all of that.
Was to do that release management, right?
So how do you say, okay, this release of my software is composed of these components?
And some of these components or many of these components might be reused in their next release, right?
There's essentially the top-level release, and you point to these components.
And then that is an important thing that gives you an audit trail of what made up a given release.
Because in the real world, when you're doing a software release like that, it's gonna be rather challenging in a year or two years or three years from now to try to reverse engineer what particular constellation of software made up a given release.
I mean, you could do it, but it's going to be very expensive.
You have to probably go into digit and like find the date, and then it's going to be very difficult, right?
So that's a big part of this release lifecycle management, is being able to tag a release that spans other releases, right?
And that's kind of like one of the big things that we built out in that product is basically being able to cut release, it spans multiple components.
And that then allows you to say if an auditor were to come and say, hey, what was the constellation of version 2.1.0, you can say, here's the S bomb for this particular version, and all the components made up that.
But now it's about tooling as well.
One two years ago, I was looking into SIFT and other trivials out there.
What are vendors' neutral tools or tools that you can use and have them to your pipeline, leaving aside the giants like GitHub and others.
If I just play an old pipeline, what should I use?
So I have a biased answer, which is we have something called Spawn with Action, which is like a superset of tools where we pick the best tool in our opinion for any given job.
But the logic for that you can extrapolate from.
And our logic is the ecosystem-specific tools tend to generate better quality S bombs than the generic tools.
So if you say the Cyclone DX tooling for Python would generate, generally speaking, a better S-bomb than say Trivi, for instance, right?
Because generic tools, they tend to not extrapolate on all the metadata that all the various languages can do, right?
Because each ecosystem, I mean, we've actually seen quite a lot of innovation in the package management space in the last few years, right?
We mentioned UV and Bun as a good example of that lately.
And many of the generic tools haven't really picked up with that.
So first you probably want to pick one camp, SPDX or Cyclone.
And once you pick that camp, the tooling becomes a little bit easier to decide on.
Both have tools that can do things.
I would say there are probably more cyclone tools out there than there are SPDX tools out there, because the SPDX tools favoring more libraries, whereas Cyclone favors more end user toolings.
So in the case of Yocto, they're using the SPDX tool libraries, right, to build their S bombs directly in their pipeline.
Whereas Cyclone have a lot more generic tool.
Build an SBOM from that.
Decide which camp you live in, that's probably the good starting point, and then pick a tool within that ecosystem.
Okay.
So, first of all, we have to choose as developers of ecosystem hurders, the tool that we are choosing.
And then stay close to the ecosystem that we are actually in, rather than using one hammer for each nail, use the appropriate tool for each and every one of them.
That's right.
Yeah, I mean, it's very compelling at the surface to like look at the generic tools because they can do everything, but there is a compromise there.
And if you actually want to operationalize this and actually use the data, the quality of the data matters, of course, garbage in garbage out.
If you want to make decisions on this, you want to have that best quality S bombs as possible.
But then what you're really aiming for is to get high quality S bombs.
So looking this back to the working group, what we set out to do was to achieve NTIA minimum element compliance.
And that's kind of the gold standards for S bombs.
None of these tools, to my knowledge, will produce an S bomb that is NTIA minimum element compliant out of the box.
So you need additional toolings for that.
But that's kind of the quality barrier that a lot of compliance regulations are starting to nudge towards.
What else should we know to be safe out there?
It's a really good conversation to start with a team.
Like I think going back to where we started, doing it audit of log files is really, really valuable exercise.
Looking at your pipelines, making sure that's it's best practice.
Because if you work in a lot of code base, you forget about this stuff.
You leave things and then you forget about it, and it just sits there to rot, right?
So doing that inventory and applying and learning by S bombs and applying S bombs in your pipeline forces you to do that inventory check.
And I think that's a really, really important.
Once you've done that, you can then focus on the lifecycle and release management and making sure S balls fit into your lifecycle management.
And once you've done that, then you can start focusing on the quality of S bombs.
And that's the next step with like MTIA and or SysA now minimum elements, and making sure that all that data is represented in the S bombs.
But it might be a bit too front-heavy to try to do that off the get-go.
I would rather start with something.
So you build the processes and then you iterate and tweak and refine the process rather than try to solve it all in one big bang.
Is there an SBOM linter that ensures that if you are okay?
So there are a few tools out there.
We have tools in Sponmify that can do checks on this and see if they are compliant with various regulations.
So there are like I mentioned Syssa and NTIA minimum element.
We have checks for that.
There is FDA got some things as well.
They have checks for CRA got their own interpretation of this.
So like if you remember in my presentation, I had like a Venn diagram between CRA and NTIA.
That's kind of what you want.
You want to incorporate both of those.
And there are various tools.
There's another tool out there called S Bomb QS that can do S Bomb analysis.
But I would say MTIA minimum element is probably the closest thing to universal standard we have that is starting to become more and more referenced in what good looks like in terms of quality.
And then there's this draw-off of a SysA minimum element that was published in the fall that probably going to be published later this year that kind of takes that and makes some changes to it.
But it makes assessments of like, who are you as a company?
Are there hashes represented in the S bomb and so forth?
And there are quite a few things in there to make sure that your quality is tighter than just and and for clarity, none of those generic tools will produce an S bomb that is even close to complete with NTIA minimum element.
Thank you for all the insights.
Is there anything else that you think it's useful for us to know?
The time to get on top of S Bombs is now.
I expect all future compliance frameworks to require SBOMs.
It becomes a litmus test of do you know what's going into your software?
We've already seen PCI DSS 4.0 calling for software inventory.
My guess is the updates to ISO and the update to SOC2, they will all require S bombs, right?
And I think it kind of reshapes your trust center, because obviously we've been in a lot of hype in the last few years by trust centers.
But I think the S bomb kind of needs to be front and center along with your compliance documents, because that's equally important that you know what's going into your software.
And I would argue it's actually even more important than making sure that you have like 2FA on your various services, right?
So I think and what I predict the future happen is that we can see S bombs being a first-class citizen in your trust centers, and it's going to be part of almost all upcoming regulations and certificates going forward.
And last question before closing.
We spoke before hitting the record button about what happened with Trivi these days.
Kir to comment.
Yeah, I um I have a lot of sympathy for the people over at DACWA.
I mean, they've done a lot of good job for the S Bomb community, but I guess we're still seeing how this playing out.
But for those who're not familiar, Trivi was one of the most popular generic S Bomb generation tools out there that have been around for quite some time.
They have been compromised in two releases now, where they essentially had infastealers baked into the Trivi package.
And that in turn has had blast radius when there have been other packages that has been compromised because of that, including a pipeline package called Light LM, which was compromised a few days ago.
We don't really know the extent yet, but there's evidence that suggests that the entire Aqua GitHub org has been compromised.
So they basically managed to compromise Trivi and then work their way to the entire Aqua GitHub org.
So we don't really know how bad this is, but it's it looks pretty bad.
We've removed Trivi from our pipeline.
So we used to use Trivia in Sponify Action as one of the SPOM generation tools.
We never used affected versions, but we've still proactively removed Trivi from the generation tool, just rather safe than sorry, to be honest.
I anticipate to see a greater fallout of this.
Light LM is probably one of the first ones that we know of, but I doubt it's gonna be the last one.
And the reason why Trivi is such a juicy target for an Infasteal is because it runs the US CI pipeline.
And people tend to use long-lived credentials in their pipeline.
And that's how they manage to kind of work their way.
So the moral of the story here is move towards OIDC and like more short-lived credentials in your pipeline.
Make sure that you pin all your GitHub action modules to hashes rather than versions.
Because the moral that we learned from the Trivia incident is that they overwrote releases, right?
So we kind of think of Git tags and git releases as kind of like firm, but they're not.
You can overwrite them, right?
So but if you pin it to a hash instead, you can make sure that you know what you're doing with.
Again, this is not like rocket science, it's not news.
Everybody working in the security world are fully aware of that.
You should be doing this.
But this is kind of a cautionary tale.
What happens if you don't?
Okay.
Thank you for sharing and thank you for your time.
Thank you.