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

0:00In mobile application security, good enough is a vulnerability. GartSquare delivers the highest level of security for your mobile apps without compromise. Discover how GartSquare provides industry-leading security for your Android and iOS apps at GartSquare.com. Hello, everybody. I'm Olim Pupop, the InfoQ Editor, and I have in front of me Victor Peterson. And here we'll try to bring more details about what happened in the S-Bomb part, especially with the legislative changes. And also what's actually really important for us to know is 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. Quick intro. Don, a few startups. I got kind of throw-in to the world of S-bombs in one of my companies where we started doing secure by design a few years ago. We had a mandate as part of that to start doing S-bombs generation for our product.

1:04I thought that would be really like a tick-book 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-sharing one of the working groups at CISIA back in the one CISIA was acting 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 Spotify 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 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.

2:05And actually, I think starting with this year, it's true, especially for the European Union. The cyber resilience side, the CISIA is coming to force. I think the U.S. has some legislation in place. I know that you came to spoke about it, so maybe let's start from looking at the sticks before going to the garage. S-bomb has 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, in the U.S., we basically were selling software that the U.S. government were required to start providing S-bombs. That was kind of the first stick, as you say, for software vendors to start generating S-bombs. The much bigger stick is to a point, CRA, in Europe. And the software enforcement window starts this year. And I would say that most people are fully aware 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.

3:08And the little stuff they use in the legislation is obviously intentionally vague, and the idea is basically to make it anything that connects it into it, more or less needs to be compliant with CRA. CRA 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 a S-bombs, or well, actually, the labels show in 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 METTI and these big boys, they just assume the cost of GDPR fines,

4:08essentially, as a cost of doing this in Europe. They learned from this, and now it's the block end of a market, which is much greater stick to have Hitler. What they particularly liked about the way how the CIA 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 AI Act, that's not in the focus of our discussion, but also the CIA, 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 formula for that.

5:11Yeah, Germany's BSI is the first real implementation. I think there have been 2.2 now off their interpretation of that block 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, my financial perspective, to invest in security, and the cause was that is, they be cameras, they expose public elements and so forth. I think there's a good reason why this exists, because 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 of the benefit for us as software developer 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,

6:11for other developers to know about S-bombs? Yeah. If you purely treat this exercise as a tech 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-loom work. But the real thing is, if you actually make this operational, a lot of companies are ready. 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 the same GP. They'll be three code in our source code or in our libraries. So that's, you can use an S-bombs for license compliance audits. More commonly, it's used for security audits. If you can generate an S-bombs on the look file, you can then, in turn, find CVEs that are affected. And the ecosystem is a bit more mature, because there's also something they call vex that goes on top of this,

7:12where you can say, yes, I'm affected by the CVE, but the CVE impact is 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 order the CVE because we're not impacted by it. So it's a bit more sophisticated than what you would have and say, dependable in GitHub, which is saying, 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 this is exactly how libraries evolve with time and so forth. 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 than this busy work to be compliant with regulation. So we shouldn't treat it like, SOKTO or ISO certification in a chore that you have to pass through. I mean, I think that Nadhi holds true there as well, because if you look at SOKTO and ISO,

8:13and all the controllers are on the line, the controllers can be very helpful, 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 form it off to some kind of team that has no real-world involvement, then yes, you have no utilities. 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 way how actually companies or individuals in companies are looking to that and just waving, OK, 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 look for 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 struts.

9:17And what was funny is that at that point of time, it was working in a company that had built everything on top of the JavaScript ecosystem. So it was no JS and all the source and everybody was just capping around that, OK, we're 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 other customers are all affected by the look for 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-bonds 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 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,

10:18it'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-bonds 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 S-bond journey that you realize is that you actually do have to capture things in lock files. So going down the example of JavaScript, for instance, if you want to actually do S-bonds for your JavaScript stack, you can't just like load things and include in the header. You need to have them in a lock file and I just start with that. You actually trace that. By virtue of doing that, you have an inventory. And that is like, regardless of the S-bond 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're talking about transitive dependencies

11:18and that is kind of 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 at different problem spaces and I would definitely treat them at different S-bombs. But capturing that is easier. Now, it gets really difficult in the case of Docker, for instance, what if you have a Docker file, were you copying things in and so forth? There gets a bit more complicated. It's a solve a problem. But I think one of the most important things is when you're starting your S-bomb 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.

12:20Requirements.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.r, requinds.txt, it will happily do the tree expansion and pull dependencies so that your look 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 started to realize that there are more modern packaged 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 much higher quality look farther, like to capture trends to dependency much better. The same is true for the JavaScript world, right? You look at a new packet match like bun, for instance, would generate a lot better lock files than just having a package of Jason, 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.

13:22We're not even using the S bombs by just getting on to 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 infrastructure. You pointed Python, which it was quite known for its inconsistency and especially typosquoting and other typos of attacks or the MPM ecosystem, which again had its challenges. But just listening to you is that I think we were both two engineers that tried to over-engineer a problem that every tickle 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 S bombs. So our direct dependencies will be more than enough, given that theoretically speaking,

14:23in order to be compliant, each and every company should have their own S bombs. And then that will go at a different level. So I would start with that tack surface almost. 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 to start with. Because then obviously there could be operations in vulnerabilities. But 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. Yeah, I would say the application system is usually more hard. And 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. He's in love 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 going always with the only tool

15:24that 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 S-bombing 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 going to look at the latest hypervisor technology to speed up the runtime. They will be companies that they have some kind of sauce product. They have some kind of product in the market. They're not necessarily engineering first companies. Engineering is a cost center to all 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. We shouldn't forget about the easy button for the vast when you have the companies that will need to be compliant.

16:25So first and foremost, it's a good place to start the application level. Look at that, have the S-bombing place. Then there are two different things. One of them is we can use that operationally. So we can consume ourselves the S-bombing or continuous integration pipeline to ensure that whether there is a CV, there is 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 will start coming in place, probably starting with next year. Now it's still just a transition period. So probably that will happen and move you 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,

17:26but it should be part of the process. In the living organism of your pipeline, do you have to elaborate a bit on that? Yeah, I think, again, going back to the whole sister working group that we spun up. One of the hard requirements we had is part of our recommendation for generations that you must do the generation in SCICD pipeline. And this ties very closely to the import 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, firmwares have been built on somebody's workstation, right? And then they just shipped off over some unsecured mechanism. Tooling has got a lot better looking both like Sefer and Yachto. These tools can be built in the CI pipeline now and they can generate S-bombs 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 CRCD fabric

18:26for 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 throw us backwards, you can go back and look at the S-bomb 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 what it's important to do in the CI is because of trust, right? Because then you have a repute useful way of doing it. At least you have proof about the station of how it was executed. And you can work backwards and you can see that trait trail. I'm smirking because I know at least a handful of people from World FreeBSD that when you say that that's reproducible, they will have a lot of things to debate around it, especially with FreeBSD 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, a machine infrastructure. So something that you don't have human touching it.

19:27So 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 it was not tampered with. And the reason why this is even more important the world of S-POM is because that S-POM will most likely be sent off somewhere else to some kind of platform. So I mentioned in my talk a product 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? So in the case of, in exchange for all this we do, it's Spotify. One of the core premises for us

20:28and the core file, my belief 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 T-provider you're using. You don't have to trust it. You can all the way go back. And I think that's a really, really important philosophical concept in this problem supply chain. Thinking back, there are three pillars of the supply chain security, a couple of years back, at the point when I was more focused on this topic and those were the S-bombs. 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 signatory, about a notary where you just have this information and I suppose that's maybe TI, but you have to correct me if I'm wrong. And then it was the ability of reproducing the reproducibility of the content that you have. But let's go first with the TEA.

21:30So TI is basically a standardized API that you can discover. So I give you an example. A box like this from a store, right? And it has a barcode. With T, all the right 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 at the station. It relies on at the station back from the source, right? One of the most common ways of doing S-bombs today is to use the SIG-store ecosystem, right? And that's very well integrated in GitHub already. So that's kind of all we recommend people to do it, but there are other ways to do it. The reason is in TI, we provide the hashers and so forth, but the hashers are kind of useless. If you can't work your way back to the source, because that could be is tampered with in transit.

22:30So this is actually the mechanism through which you have the ability of checking the information that's out there, right? Let's say you have 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 for an electronic store, right? And you're picking up like a webcam, or well, maybe the 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 TI, you can work your way all the way down to the S-bombs, right? And that's really a really powerful concept. And in terms of adoption, how far along is it? So TI is part of ECMA, and we are aspiring to become an ISO standard, and we're going into standardization for ECMA at the middle of tail of this year. And it lives under O-bospin cycle 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 knowledge.

23:30And there was a NISA paper published this week, and they kind of highlight TI as one of those mechanisms as well. So I think we're gaining momentum. To my knowledge, there are only two implementations of TI that are open source out there. So rearm and spomify are the only two implementations of TI right now. But there will probably be more to follow. As you mentioned, TI is coming as maybe a spin-off from the group that brought also cyclone DX, so from all of us. Yes, but it's important to note that TI is vendor neutral, right? So it's not biased towards cycle over SPDX, for instance. It's the distribution mechanism. Yeah, I agree with you. But I also agree that we in technology, we are like football fans. And if we were born cheating for a football team, it's seldomly decayed until 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,

24:30now SPDX and Cyclone DX are actually the ones that gain more momentum. And that's my hope that TI will be actually vendor neutral and adopted all over the place regardless of the format that you use. It also goes beyond S-bombs, right? So it's important to stress that TI is a security artifact discovery mechanism. So it's not just limited to S-bombs. It can 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, I just bought from the shop, scanning the barcode, might bring, okay, but maybe some Vex files, some S-bombs 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

25:32because I don't want to use something that is using an EOL version of, I 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 S-bombs if I 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 a 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 history. If you're selling a commercial product, it gets a lot more difficult. And this is where people when they go on their S-bombs journey only start to realize, because even a relatively simpler product

26:34will have not one S-bombs. You probably can have 10, 20, 30 S-bombs because just the backend, there are containers, there's firmware, there are so many things that makes up a real product. And your S-bombs needs to represent all of that. And this kind of where, or S-bombs if I was born out of, was 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 a 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 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's going to be very expensive.

27:34You have to probably go into Git 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. It's basically being able to cut a release, it spans more 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 to two years ago, I was looking into SIFT and all that three viewers out there to what are vendor of neutral tools or tools that you can use and have them to your pipeline, living aside the giants like GitHub and others, if I just play an old pipeline, what should I use? So I've biased on SIFT, which is we have SIFT which is like a superset of tools

28:34where 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 generic tools. So if you say, the cycle on DX tooling for Python will generate, generally speaking, a better S-bomb, than, say, trivia, 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 the UVM bond as a good example of that lately. 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

29:34cyclone tools out there than there are SPDX tools out there because the SPDX tools favoring more libraries whereas cyclone favors more end-user tool links. So in the case of Yachto, 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. The generic tool says, here's my Python look file, build the S-bombs from that. The side of 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 the ecosystem orders, the tool that we are choosing, and then stay close to the ecosystem that we are actually in, that then using one hammer for each nail uses the appropriate tool for each and every one of them. 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 is a compromise there. And if you actually want to operationalize this and actually use the data,

30:35the quality of the data matters, of course. Garbage is garbage out. If you want to make a decision on this, you want to have that best quality S-bombs is possible. But then what you're really aiming for is to get high quality S-bombs. So, living 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-bombs 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 what we started, doing it all to lock files is really, really valuable. Like, so I'm looking at your pipelines, making sure that it's best practice, because if you work a lot of co-bests, 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 learning bias bombs,

31:35and applying S-bombs to your pipeline, force you to do that inventory check. And I think that's really, really important. Once you've done that, you can then focus on the lifecycle and release management, and then making sure S-bombs 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 NTIA, or system now minimum element, and making sure that all that data represented in S-bombs. But it might be a bit too from heavy to try to do that off the gecko. 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 a S-bombs linker that ensures that you are okay? So there are a few tools out there. We have tools in Spotify that can do checks on this, and see if they are compliant with various regulations. So there are, like I mentioned, Sysa 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.

32:35So 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 not a tool out there called S-bombs. That can do S-bombs analysis. But I would say NTIA minimum element. It's probably the closest thing to the 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 a draw for the system in the element that was published in the fall. That probably can be published later this year. That kind of takes that and makes some changes to it. But it makes the assessment of, like, who were you as a company? Are there hatches represented in S-bombs and so forth? And there are quite a few things in that to make sure that you quality is tighter than just, and for collective, none of those generic tools will produce an S-bombs 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?

33:35The time to get on top of S-bombs is now. I expect all future compliance frameworks to require S-bombs. 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 a software inventory. My guess is that updates to ISO and the update to SOC2, they will all require S-bombs, right? And I think it cannot reshapes your trust center, because obviously we've been a lot of hype in the last few years about trust centers, but I think the S-bombs can easily be front and center along with your compliance documents, because that's equally important that you know what you're going into your software, and I would argue it's actually even more important than very can show that you have like 2FA on your various services, right? So I think in what I predicted the future happiness and we're going to see S-bombs being a first class citizen in your trust centers, and it's going to be part of almost all upcoming regulations

34:36and certificates going forward. And last question before closing, please speak before hitting the record button about what happened with Trivi. Oh, yeah. These days, careful comment. Yeah, I have a lot of sympathy for the people over at Takwa. I mean, they've done a lot of good job for the S-bombs community, but I guess we're still seeing how it's playing out, but for those who are not familiar, Trivi was one of the most popular generic S-bombs generation tools out there that didn't around for quite some time. They have been compromised in two releases now, where they essentially had info-stealers 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 pipa package called Light and Lamp, which was compromised a few days ago. We don't really know the extent yet, but there's evidence that suggests

35:37that the entire Aqua GitHub work has been compromised. So they basically manage to compromise Trivi and then work their way to the entire Aqua GitHub work. So we don't really know how bad this is, but it looks pretty bad. We've removed Trivi from our pipeline, so we used to use Trivi in S-bombs action as one of the S-bombs generation tools. We never used affected versions, but we've still preructively removed Trivi from the generation tool, just rather safe and sorry, to be honest. I anticipate to see a greater fallout of this. Light and Lamp is probably one of the first ones that we know of, but I doubt it's going to be the last one. And the reason why Trivi is such a juicy target for an interest deal is because it runs the SDI 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

36:41in 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 Trivi incident is that they overlook 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, this is not news. Everybody working in the security world are fully aware about you should be doing this, but this is kind of a caution or tale what happens if you don't. Okay, thank you for sharing and thank you for your time. Thank you.