How SBOMs and Engineering Discipline Can Help You Avoid Trivy’s Compromise

Transcript

Olimpiu Pop: Hello everybody. I'm Olimpiu Pop, an InfoQ editor, and I have Viktor Peterson in front of me. And he will try to bring more details about what happened in the SBOM space, especially regarding the legislative changes, and also what's actually important for us to know as developers, without the big stick looking at us.

Viktor, you have a couple of things that you're working on, so please give us a short intro on what you're doing.

Viktor Peterson: Thank you so much for having me. Quick intro: done a few startups. I got kind of thrown into the world of SBOMs in one of my companies when we started doing Secure by Design a few years ago.

We had a mandate, as part of that, to start generating SBOMs for our product. I thought that would be a really tick box exercise done in a week, and then 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 CISA back when CISA was actually in the SBOM world. And we ended up creating a white paper on SBOM 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 sbomify, where we implement that blueprint from the working group, basically letting you create high-quality SBOMs because it's actually a lot more challenging than most people realise. So that was kind of the goal there.

Olimpiu Pop: Thank you. It's very important because supply chain attacks are becoming increasingly 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's coming from outside.

And actually, I think starting with this year, it's true, especially for the European Union. On the cyber resilience side, the CRA is coming into force. I think the US has some legislation in place. I know that the UK did speak about it, so maybe let's start by looking at the sticks before going to the carrots.

SBOM Enforcing Legislation [02:24]

Viktor Peterson: SBOMs have been around for a long time. They're not new by any means, but what we've started as CEO over the last few years, starting with executive order 4989, in the US, we've already been selling software to the US government were required to start providing SBOMs. That was kind of the first stick, as you say, for software vendors to start generating SBOMs.

The much bigger stick is, to your point, CRA in Europe. And the soft enforcement window starts this year. And I would say most people are completely unaware that they will be affected 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 test as they use it in the legislation is obviously intentionally vague. And the idea is basically to make it so that anything that connects to the internet more or less needs to be compliant with CRA. CRA, in turn, requires you to generate an SBOM. So that's kind of why we're here today.

Olimpiu Pop: So that means that pretty much any electronic or software should have an SBOM or... Well, actually, the label shows the ingredients that are in. So that's scary?

Viktor Peterson: Yes. 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 block in the fund market, which is a much greater stick to hit with.

Olimpiu Pop: What I particularly liked about the way the CRA came to be 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 as a regulator, but I have to be happy as a consumer of digital services, digital products, and AI on these two points.

The AI Act, that's not in the focus of our discussion, but also the CRA, because actually you saw it. What I'm afraid of currently is the way it'll come to be implemented. And that's especially from the way 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 form for that.

Viktor Peterson: Yes. Germany's BSI is the first real implementation. I think there have been 2.2 now of their interpretation of that far, which has been kind of evolving. But just bringing back to your previous point, 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 from a financial perspective to invest in security. And the consequence of that is baby cameras being exposed to the public on the internet and so forth. So I think there's a good reason this exists: the market really failed to self-regulate, I'd say.

Developers Should Care About SBOMs Too [05:51]

Olimpiu Pop: Yes. And I think it's very important to take that responsibility and people who are actually part of it to do it. But on the other side, what are the benefits for us as software developers and practitioners, because it comes with added benefits as well. Let's look into those things. What would be useful for other developers to know about SBOMs from your perspective as a developer?

Viktor Peterson: Yes. If you purely treat this exercise as a tick-box exercise, which is, "I'm doing this for the sake of being compliant," then you're not really reaping the benefits of generating this, and you're creating a lot of work for no reward, right?

But the reality is, if you actually make this operational... A lot of companies are already, this is not theoretical. Many companies use this heavily as part of their workflow. They're using SBOMs to do security audits of their code base, and they're using it to do a license-compliant audit of their supply chain.

So a lot of companies have policies for "We're not allowed to use," say, "GPLv3 code in our source code or in our libraries." So you can use an SBOM for license compliance audits. More commonly, it's used for security audits. If you can generate an SBOM from a lock file, you can then, in turn, find CVEs that are affecting it.

And the ecosystem is a bit more mature because there's also something that's called VEX that goes on top of this, where you can say, "Yes, I'm affected by the CVE, but this CVE 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, "Yes, I can go with the CVE because we're not impacted by it."

So it's a bit more sophisticated than what you would have in say Dependabot and GitHub, which just says, "Hey, here's a vulnerability in this library, upgrade." Because sometimes that's not necessarily the best path forward.

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 you see exactly how libraries evolve with time and so forth.

So there's a great deal of utility in this if you actually use it properly and use it as an operational vehicle rather than just busywork to be compliant with regulations.

SBOMs Might Seem Similar to Compliance Frameworks [08:00]

Olimpiu Pop: So we shouldn't treat it like a SOC2 or ISO certification chore that you have to pass through?

Viktor Peterson: I mean, I think that analogy holds true there as well, because if you look at SOC2 and ISO, at least all the controllers are underlying, the controllers can be very helpful in order to ensure your compliance with the framework, because they're not made out of thin air.

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 farm it off to some kind of team that has no real-world involvement, then yes, you have no utilities. I think there are many analogies between compliance and SBOM generation in general.

Olimpiu Pop: Yes, I agree with you. I'm not talking about the content because obviously there are good practices in that. I'm just about the way how actually companies or individuals in companies are looking at that and just waving, "Okay, that's something that we have to do, and it's 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 Log4Shell. 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 Struts.

And what was funny is that at that point in time, I was working in a company that had built everything on top of the JavaScript ecosystem. So it was not just an old source, and everybody was just coping around it, "Okay, we are not affected then," blah, blah, blah.

Two hours later, we got an email from GCP saying that, unfortunately, the 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 Log4Shell and they have to put it offline because we didn't have anything to do. And where do you stop?

How to Tackle the SBOM Generation Challenge [09:53]

Because that was always a question for me and also for the audience when discussing SBOMs, 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 stop somewhere with your references. How should you approach that kind of problem?

Viktor Peterson: It's a fantastic question. I think the first thing to flag there is that ecosystems have very different maturity levels, and even within a given ecosystem, you have a very different quality of tooling because ultimately most SBOMs are generated from lock files, and lock files vary in quality a great amount.

But I think the first thing when you go on your SBOM journey that you realise is that you actually do have to capture things in a 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 load things and include them in a header. You need to have them in a lock file, and you should start with that. So you actually trace that.

By virtue of doing that, you have an inventory, and that is like... Regardless of whether there's an SBOM, that is a step in the right direction because you now 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 because you could say, "Well, I want to know everything down to source code." 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 different SBOMs, and 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, it gets a bit more complicated. It's a solvent problem. But I think one of the most important things 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 realise that... I'm just going to use the Python example. Requirements.txt has been like the standard for a long time in the Python world, but it makes no guarantees that it captures all the dependencies because it will happily, if you do pip install -r requirements.txt, you will happily do the tree expansion and pull dependencies so that your lock file is not capturing that role. 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 realise that there are more modern package managers out there that do a better job, that will capture the dependency tree much better.

So in Python, for 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 trends to dependency much better.

The same is true for the JavaScript world. You look at new package matches like Bun, for instance, would generate a lot better lock files than just having a package adjacent, which may or may not be pinned properly.

So I think that is one of the biggest wins that you get from day zero, without even using the SBOMs, by just getting onto that journey, you end up having high-quality software.

Olimpiu Pop: So just to frame the main idea is that lock 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 typosquatting and other types of attacks, and the NPM ecosystem, which again had its challenges.

But just listening to you, I think we were both two engineers who tried to over-engineer a problem that the vertical shouldn't be like that, because actually, if you think about it, all these pieces that you're looking into are all digital products, and actually, they should come with their own SBOMs.

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 SBOMs, and then that will go to a different level.

Start with the Inventory of Your Direct Dependencies [14:32]

Viktor Peterson: I would start with that attack surface, almost, right? So if you're looking at any application, it's the application stack that is exposed, so starting there makes sense from a security perspective to do an inventory check first, right? Because there could be operators and vulnerabilities as well, your most common attack vector will be the application layer. So that's kind of where you want to start, regardless. And it's probably less. Yes, I would say the application system is usually harder anyway in the first place.

Olimpiu Pop: 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 Zenla from 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 always going with the only tool that is out there in containers, maybe a micro virtual machine would be better, especially if you can have these kind of attacks and something sensible. So I think there is a new wave of tooling and a lot of people who are doing a lot of excellent work. So I think we should open our ears, besides having the SBOM in place.

Viktor Peterson: 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 are going to look at it like the latest hypervisor technology to speed up the runtime.

They will be companies that have some kind of SaaS product, or they have some kind of product in the market. They're not necessarily engineering-first companies. Engineering is a cost centre to a lot of these companies, and they are just going to look for the quickest solution.

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 will need to be compliant.

SBOM Generation Should Be Part of the Pipeline [16:27]

Olimpiu Pop: 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 that we can use it operationally. So we can consume the SBOM in our continuous integration pipeline to ensure that whether there is a CV, there is a new problem out there, we know whether we are effective or not. As you mentioned, it might be that we are not actually using that 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 we are using in terms of generating that. And then it's about regulatory, and that will start coming into 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 that the SBOM 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. Can you have to elaborate a bit on that?

Viktor Peterson: Yes. I think, again, going back to the whole CISA working group we spun up, one of the hard requirements we had was that, for generation, you must do it in a CI/CD pipeline.

And this ties very closely to the importance of signing SBOMs. 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, firmware's been built on somebody's workstation, and then they just shipped off over some unsecured mechanism.

Tooling has got a lot better, looking both like Sypher 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? It becomes part of the CI/CD fabric for all the projects across your company. So they have a unified way of doing this, and you also have a good paper trail.

So if you want to traverse backwards, you can go back and look at the SBOM from a given release and diff it, or use that data operationally so that, again, it becomes useful rather than just busywork.

So I think why it's important to do this in CI because of trust, 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 the trade trail.

Olimpiu Pop: I'm smirking because I know at least a handful of people from FreeBSD who, when you say that, that's reproducible, they will have a lot of things to debate around it, especially FreeBSD, which they are very eager to generate 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 a human in the loop. Here, it's important to have safe infrastructure, such as machines that ensure it is generated in a constant manner. And as you said, up to a point, it's something that, more or less, you have a paper trail and something that is auditable. And on the other side, you know exactly how it was, and you have the digital signature on it that ensures that was not been tampered with.

Viktor Peterson: And the reason why this is even more important in the world of SBOM is that the 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 artefacts.

In the context of that context, the signing becomes even more important, right? How do you prevent that from being tampered with in transit? So, in the case of, in extent as we do with sbomify, one of the core premises for us and a core fundamental belief in us is 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 TEA provider you're using; you don't have to trust it. You can go all the way back. And I think that's a really, really important philosophical concept in the SBOM supply chain.

Olimpiu Pop: 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 to trace all of them, as you mentioned
• the signatories, about a notary, where you just have this information, and I suppose that's maybe TEA, but you have to... Correct me if I'm wrong. And then it was the ability to reproduce it, the reproducibility of the content that you have. But let's start with the TEA first

TEA Provides In-Depth Build Information to Consumers [21:31]

Viktor Peterson: So TEA is basically a standardised API that you can discover. So I'll give you an example. If I pull a box like this from a store, and it has a barcode. With TEA, all that I need to know is the barcode or SKU and combined with the company's domain, I can find security artefacts. So it's a standardised discovery mechanism that allows you to find the artefacts.

So it's not a storage mechanism; it doesn't do attestation; it relies on attestation from the source. One of the most common ways of doing SBOMs today is to use the Sigstore ecosystem, right? And that's already very well integrated into GitHub.

So that's kind of how we recommend people to do it, but there are other ways to do it. And the reason is that in TEA we provide the hashes and so forth, but the hashes are kind of useless if you can't work your way back to the source because that could be tampered with in transit.

Olimpiu Pop: So this is actually the mechanism through which you have the ability to check the information that's out there, right? Let's say you have a yoghurt or whatever food product, you have the ability to actually know what's inside, and that's the ability to check it.

Viktor Peterson: Well, it's more like... Imagine for an electronic store, and you're picking up a webcam or, well, maybe a surveillance camera is a better example because it's going to be more connected, right? But if you can find the barcode for that product and if they have adopted TEA, you can work your way all the way down to the SBOM. And that's really a powerful concept.

Olimpiu Pop: And in terms of adoption, how far along is it?

Viktor Peterson: So TEA is part of ECMA, and we are aspiring to become an ISO standard, and we're going into standardisation for ECMA at the middle of the tail of this year, and it lives under OWASP and CycloneDX, which in turn is connected to ECMA.

And the idea is to become like a fully standardised process so that it will gain more adoption. There was an ENISA paper published this week, and they can highlight TEA as one of those mechanisms as well. We're gaining momentum.

To my knowledge, there are only two implementations of TEA that are open source out there. So ReARM and sbomify are the only two implementations of TEA right now, but there will probably be more to follow.

Olimpiu Pop: As you mentioned, TEA is coming as maybe a spinoff from the group that also brought CycloneDX, so from OWASP.

Viktor Peterson: Yes, but it's important to note that TEA is vendor-neutral, right? So it's not biased towards Cyclone over SPDX, for instance, which is the distribution mechanism.

Olimpiu Pop: Yes, I agree with you, but I also agree that we, in technology, are like football fans. And if we were born cheering for a football team, it's seldom the case that it will change. And that's why I'm saying that there used to be three standards that were pushed upfront for the SBOMs. Now, SPDX and CycloneDX are actually the ones that gain more momentum. And that's my hope that TEA will be actually vendor-neutral and adopted all over the place, regardless of the format that you use.

Viktor Peterson: Yes. It also goes beyond SBOMs, right? So it's important to stress that TEA is a security artefact discovery mechanism. So it's not just limited to SBOMs. It could be VEX files, or it could be compliance documents. So it goes beyond just SBOMs as a delivery mechanism.

Olimpiu Pop: Okay. So, going back to your surveillance camera that I just bought from the shop. Scanning the barcode might bring, okay, maybe some VEX files, some SBOM files, maybe some advisories?

Viktor Peterson: Yes, manuals or anything you want, really, right?

Olimpiu Pop: So it's actually everything that can affect my security when using this product.

Viktor Peterson: Yes. 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 something that is using an EOL version of," I don't know, insert blank, "framework" or insert blank, "operating system."

What Would Regulators Check For? [25:41]

Olimpiu Pop: The regulatory boards, when coming and checking, might ask you about SBOMs, so ingredients that went back a couple of releases. How can you approach that in a stress-free manner?

Viktor Peterson: The answer is it depends. This is one of the things that people haven't realised until they start doing SBOMs. And I didn't realise this until we were doing SBOMs. And this is literally why sbomify was born because of the problems around that we discovered firsthand when doing SBOMs at scale.

If you're an open-source project, stashing your SBOMs on GitHub makes perfect sense. You just make it part of the release artefacts and voila. Now you have an easy way to look back and trace back in 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 realise that even a relatively simple product will have not one SBOM. You probably can have 10, 20, 30 SBOMs because there's the backend, there are containers, there's firmware, there are so many things that make up a real product, right? And your SBOM needs to represent all of that. And this is kind of where sbomify was born, to do that release management.

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, giving 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 going to 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 would be very expensive. You have to probably go on the date, to Git, and find the date, and then it's going to be very difficult. So that's a big part of this release lifecycle management, being able to tag a release that spans other releases.

And that's like one of the big things that we built out in that product, which 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 SBOM for this particular version and all the components that made up that."

What Tools to Use? [28:06]

Olimpiu Pop: But now it's about tooling as well. Two years ago, I was looking into Syft. I know that Trivy was out there. What are vendor-neutral tools or tools that you can use and add to your pipeline? Leaving aside the giants like GitHub and others, if I just play an old pipeline, what should I use?

Viktor Peterson: So I have a biased answer, which is we have something called sbomify action, which is like a super set 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 that the ecosystem-specific tools tend to generate better quality SBOMs than the generic tools.

So if you say the CycloneDX tooling for Python will generally generate a better SBOM than, say, Trivy, right? Because generic tools, they tend not to extrapolate on all the metadata that all the various languages can do. In each ecosystem, we've actually seen quite a lot of innovation in the package management space in the last few years. 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.

First, please 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 favour more libraries, whereas Cyclone favours more end-user tooling.

So in the case of Yocto, they're using the SPDX toolkit libraries to build their SBOMs directly in their pipeline, whereas Cyclone have a lot more generic tools. Generic tool says, "Here's my Python lock file, build an SBOM from that." Decide which camp you live in; that's probably a good starting point, and then pick a tool within that ecosystem.

Olimpiu Pop: Okay. So first of all, we have to choose, as developers or ecosystem holders, 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 nail.

Viktor Peterson: That's right. I mean, it's very compelling at the surface to look at the generic tools because they can do everything, but there's a compromise there. And if you actually want to operationalise this and actually use the data, the quality of the data matters, of course--garbage in, garbage out. If you want to make the decision on this, you want to have the best quality SBOM as possible. But then what you're really aiming for is to get a high-quality SBOM.

So, looping 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 standard for SBOMs. None of these tools, to my knowledge, will produce an SBOM that is NTIA minimum-element compliant out of the box. So you need additional tooling for that. But that's kind of the quality barrier that many compliance regulations are starting to nudge towards.

SBOMs Might Be First-Class Citizens in the Future [31:12]

Olimpiu Pop: What else should we know to be safe out there?

Viktor Peterson: It's a really good conversation to start with a team. I think going back to where we started, doing an audit of lock files is a really, really valuable exercise. Looking at your pipelines, making sure that it's best to practice because if you work on a lot of code, you forget about this stuff. You leave things, and then you forget about them, and it just sits there to rot.

So doing that inventory and applying and learning by SBOMs and applying SBOMs in your pipeline forces you to do that inventory check. And I think that's really, really important. Once you've done that, you can focus on lifecycle and release management, and on ensuring SBOMs fit into your lifecycle management. And once you've done that, then you can start focusing on the quality of SBOMs.

And that's the next step with NTIA or CISA, now minimum elements, and making sure that all that data is represented in the SBOMs. 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, tweak, and refine the process rather than try to solve it all in one big bang.

Olimpiu Pop: Is there an SBOM linter that ensures that you are okay?

Viktor Peterson: So there are a few tools out there. We have tools in sbomify that can perform checks on this and determine whether they are compliant with various regulations. So there are, as I mentioned, CISA and NTIA even development, we have checks for that. The FDA got some things as well. They have checks for... CRA got their own interpretation of this.

So, if you remember in my presentation, I had 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 called sbomqs that can perform SBOM analysis.

But I would say NTIA minimum element is probably the closest thing to a 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 draft of a system in minimum elements 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 assessment of like, who are you as a company? Are there hashes represented in the SBOM and so forth? And there are quite a few things in there to make sure that your quality is tighter than just... And for clarity, none of those generic tools will produce an SBOM that is even close to complete with the NTIA minimum elements.

Olimpiu Pop: Thank you for all the insights. Is there anything else that you think is useful for us to know?

Viktor Peterson: The time to get on top of SBOMs 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 that the updates to ISO and the updates to SOC 2 will all require SBOMs. And I think it kind of reshapes your trust centre because obviously we've seen a lot of hype in the last few years about trust centres, but I think the SBOM needs to be front and centre along with your compliance documents because that's equally important that you know what you're going to do with your software.

And I would argue it's even more important than ensuring you have 2FA on your various services. So I think, and what I predict the future will be is that we get SBOM being a first-class citizen in your trust centres, and it's going to be part of almost all upcoming regulations and certificates going forward.

Even Security Tools Can Be Compromised [34:39]

Olimpiu Pop: And last question before closing: we spoke before hitting the record button about what happened with Trivy lately. Care to comment?

Viktor Peterson: Yes. I have a lot of sympathy for the people over at Aqua. I mean, they've done a lot of good job for the SBOM community, but I guess we're still seeing how it's playing out. But for those who are not familiar, Trivy was one of the most popular generic SBOM generation tools out there that has been around for quite some time.

They have been compromised in two releases now, where they essentially had infostealers baked into the Trivy package. And that in turn has had a blast radius when there've been other packages that have been compromised because of that, including a PyPI package called LiteLLM, which was compromised a few days ago.

We don't know the extent yet, but there's evidence that the entire Aqua GitHub org has been compromised. So they managed to compromise Trivy and then worked their way into the entire Aqua GitHub org. So we don't really know how bad this is, but it looks pretty bad.

We've removed Trivy from our pipeline. So we used to use Trivy in the sbomify action as one of the SBOM generation tools. We never used affected versions, but we've still proactively removed Trivy from the generation tool, just better safe than sorry, to be honest. I anticipate seeing a greater fallout of this.

LiteLLM is probably one of the first we know of, but I doubt it's going to be the last. And the reason why Trivy is such a juicy target for infosteal is that it runs the CI/CD pipeline. And people tend to use long-lived credentials in their pipelines, which is how they manage to work their way.

So, the more of the story here is move towards OIDC and 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 Trivy incident is that they over-release.

So we can't think of Git tags and Git releases as like firm, but they're not. You can overwrite them. So, if you pin it to a hash instead, you can make sure that you know what you're doing with it.

Again, this is not like rocket science; it's not news. Everybody working in the security world is fully aware of that you should be doing this, but this is kind of a cautionary tale of what happens if you don't.

Olimpiu Pop: Okay. Thank you for sharing, and thank you for your time.

Viktor Peterson: Thank you.

Mentioned:

• The Minimum Elements For a Software Bill of Materials (SBOM)
• Open Source Security Tool Trivy Hit by Supply Chain Attack, Prompting Urgent Industry Response