Podcast
Join Viktor, a proud nerd and seasoned entrepreneur, whose academic journey at Santa Clara University in Silicon Valley sparked a career marked by innovation and foresight. From his college days, Viktor embarked on an entrepreneurial path, beginning with YippieMove, a groundbreaking email migration service, and continuing with a series of bootstrapped ventures.
Links
Follow Me
Follow Me
Join Viktor, a proud nerd and seasoned entrepreneur, whose academic journey at Santa Clara University in Silicon Valley sparked a career marked by innovation and foresight. From his college days, Viktor embarked on an entrepreneurial path, beginning with YippieMove, a groundbreaking email migration service, and continuing with a series of bootstrapped ventures.
Unveiling SBOMs: Insights from Allan Friedman of CISA
Play On
28 JUL • 2024
1 hour 26 mins
Share:
In this captivating episode of “Nerding Out with Viktor,” Viktor welcomes Allan Friedman, a cybersecurity expert from the Cybersecurity and Infrastructure Security Agency (CISA), to delve into the fascinating world of Software Bill of Materials (SBOMs). As the conversation unfolds, listeners embark on a comprehensive journey through the realm of SBOMs, their significance, and the latest advancements in cybersecurity.
Allan’s expertise shines as he explains CISA’s pivotal role in defending today and securing tomorrow. He highlights the agency’s operational roles, including securing the American civilian government, addressing ongoing threats against businesses and communities, and building more secure infrastructure. Viktor and Allan also touch upon CISA’s international partnerships and collaborations with other US government cybersecurity hubs.
As they explore the concept of SBOMs, Allan draws parallels between software transparency and food labeling, emphasizing the importance of knowing what’s in our software. The conversation takes a deep dive into the evolution of SBOMs, from their inception at the National Telecom and Information Administration (NTIA) to their current status as a driving force behind global implementation.
Technical intricacies are unpacked as Viktor and Allan discuss the two major formats: CycloneDX and SPDX. They delve into the origins, key differences, and the communities that support these formats. This insightful discussion highlights the importance of these formats in ensuring software transparency and security across various sectors.
The practical challenges in generating and using SBOMs are addressed as Allan shares valuable insights into automation, dynamic software environments, and data accuracy/integrity. Related tools like VEX (Vulnerability Exploitability Exchange) and attestation in securing SBOMs are also explored.
Allan’s expert perspective on the intersection of open-source software and SBOMs offers a unique value proposition for listeners. The critical role SBOMs play in enhancing transparency and security in software development and deployment is underscored, as well as their impact on international policies and frameworks.
Practical advice for organizations starting their SBOM journey is shared, along with insights into the future of secure software supply chains. This episode serves as a must-listen for anyone involved in software development, cybersecurity, or IT management, providing a thorough understanding of SBOMs, practical guidance on implementing them, and a glimpse into the future of software security.
Key topics discussed include:
- CISA’s role in defending today and securing tomorrow
- The evolution of SBOMs from inception to global implementation
- Technical aspects and formats: CycloneDX and SPDX
- Challenges and solutions: automation, dynamic software environments, and data accuracy/integrity
- Auxiliary features: VEX and attestation
- Future trends: integration of additional data layers like cryptographic build materials and AI-generated software components
Links:
- SBOM-o-Rama Winter 2024
- Episode Sponsor: sbomify
Transcript
Show/Hide Transcript
Before we dive into the show, I want to talk about a project I created called Spomify.
See, there are three parts to Nestbom.
There is the generation side, there is the collaboration side, and then there is the analysis side.
sbomify solves for the collaboration part.
It can integrate directly into your CI CD pipeline, and then you can invite and share both internal and external stakeholders.
So check out spomify at sbomify.com.
and now onto the show.
Welcome back to another episode of nerding out with Victor today.
I have Alan Friedman on the pedicle podcast with me today, and we are going to talk about all things s bombs.
Alan is from Scisa.
And welcome to the show, Alan.
Thanks so much for having me.
So maybe before we dive in, we should talk about where you actually work.
So, Saisa, what Saisa and what does it do?
Or what does the agency do?
I guess so.
The Cybersecurity and Infrastructure Security Agency is the lead us government civilian cybersecurity agency.
Our mission is to defend today and secure tomorrow.
So we have a variety of roles, some of them operational, securing the american civilian government, working to address ongoing threats against american businesses, american communities, and also looking to build better, more secure infrastructure.
So we spend a lot of time thinking about critical infrastructure.
We do international partnerships with our partner agencies in cybersecurity.
And of course, we work with the other hubs of cybersecurity expertise in the us government, including cyber Command and the NSA.
We work with our friends overseas, especially close relationship with NCSC UK.
And we work a lot with industry.
So most of my work is actually outward facing, helping with the broader cybersecurity community.
And my understanding is that SaiSA is an advisory agency to other agencies inside the us government and outside as well.
So it's not exactly, we are not a regulator, but we do spend a lot of time working with other government organizations.
And one of the things we do is we have a role in helping secure other government agencies.
So we do have some ability to sort of say, hey, everyone.
Now, in the us government do this?
Develop blueprints and best practices, I presume.
Yeah, and even some of your audience is probably familiar with the known exploitable vulnerability list or the Kev list, where we say, hey, these are high profile vulnerabilities.
So every government agency needs to drop what they're doing and fix those immediately.
And we have some force to compel.
We have some ability, legal ability to compel that.
Okay.
And this is a relatively new agency, I presume, or we are.
I think we're still the newest government agency in the us government.
We nominally sit under the Department of Homeland Security, which, of course, is a very broad mission, and we grew out of the Department of Homeland Security.
We're small, but growing.
I think we've grown by 50% in the last four years.
And covering just as you know, cybersecurity is a pretty big waterfront, and so we're trying to cover as much of it as possible.
Amazing.
All right, so the reason why I wanted to have you on the show today is because I was introduced to you from, actually, a fellow guest on the podcast.
What I was really curious about on deep diving into the world of s bombs, and you have kind of played a hub in becoming, like, a person that is affiliated with all things Sbom.
We dive into the different camps in a second, but you have your fingers in a lot of pies across the whole world of SBom and have a really good understanding of what it is, why it matters, and the latest development of in the world of Sboms.
Really.
So we've talked about s bombs on the podcast before, but maybe we should do a quick recap for people who haven't actually listened to the podcast before.
What are s bombs?
What's the origin story, and why do they exist?
Sure.
Software bill of materials is the radical notion that we should actually know what's in our software.
You go to the store, you buy a chocolate, comes with lists of ingredients.
Why do we expect more transparency from a mid afternoon snack than we do from the software that's running our businesses, our critical infrastructure, our national security systems?
So the list of ingredients metaphor isn't perfect, but it is helpful.
And we can dive into what nice bomb won't do a little later.
But the notion behind it is machine readable, built for automation, and it's also just a data layer on which we can build further use and applications.
And this came out of the National Telecom and Information Administration, I believe, right?
It did.
So NTIA is a tiny part of the US Department of Commerce, and their mission is really to sort of think about how do we promote a better and healthier, more useful digital ecosystem.
And I was there at the time doing some work on various cybersecurity topics.
So, for example, back in 2015, we ran the first public private discussion on coordinated vulnerability disclosure.
Remember back ten years ago?
This used to be a really hot button topic where were still fighting overdose.
How should researchers and producers and maintainers of software work together?
We said, you know, we're going to throw everyone in a room.
We're going to have a big american flag behind us.
So at least the big tech companies have to show up.
And when the big tech companies show up, I was able to go to the hacker community and say, hey, guys, you're going to want to join because you want to sort of make sure that your voice is in the room.
And we actually got a pretty good mixed, including some great leaders in the security research community.
Dan Kaminsky spoke at our kickoff meeting.
We had Katie Viserys, we had Josh Korman.
So people that have been leaders in the hacking community and sort of found some common ground and software build materials seemed like a good fit for developing in this model.
The idea wasn't new.
It's been around for a while, been advocated.
People like Hardy mentioned Josh Corman.
Jeff Williams, one of the founders of OwASP, has been talking about it, but there wasn't a common way of doing it.
It wasn't common practice, and there wasn't even a generally accepted idea of what it should be, especially not cross sector.
So there were movements already happening in certain communities, like the medical device community.
But we wanted to make sure that this didn't end up as, okay, here's the way it's done in the military, and here's the way it's done for web apps.
We needed a common vision.
And so that vision began back in 2018 where we really said, okay, let's define the basics and move from there.
And this was really, I guess, accelerated industry when the executive order came out.
Right.
Because that was really when they came, not just not a draft document, but rather, oh, if we do not do this, there are bottom line implications.
And I think that's where the industry really woke up.
So maybe speak a bit about that for a moment.
Sure.
So the initiative at NTI started in 2018, began Pikmin momentum.
We had a lot of participation from different corners of the community, major medical device manufacturers, energy manufacturers, a lot of the large software manufacturers were involved.
And were starting to see a market.
There were people who were saying, hey, we can help other people build this data, manage this data, consume this data.
And so when the Biden administration came and said, we want to do an executive order that focuses on making sure that we have better quality software in the ecosystem, S BOM was a natural building block of their vision.
So the executive order back in 2021, executive order 14028, for those of you who love to track your government documents.
I'll link to it in the show notes.
In the introduction, the president says, the trust we place in our digital infrastructure should be based on how trustworthy and how transparent that digital infrastructure is.
And so transparency sort of is a foundational piece of it.
It sets out a vision that says we're not going to buy software that doesn't have basic security properties qualify to be used in the us government.
It's got to have these basic properties.
I'll give you a hint.
The us government buys a lot of stuff and these were basics.
This is stuff that should have been table stakes.
Already have multifactor authentication.
Make sure that your build environment is separate from your development environment.
Use vulnerability management tooling on your software.
And of course, the new thing that you mentioned is it said, and by the way, you're going to have a software bill of materials.
And so that meant people who are just sort of vaguely aware of it.
I think we have done a good job.
You mentioned that.
I'm often known for it.
I think my real contribution is not anything technical, it's just being the guy who would always chime in and say, and to s bomb whenever were talking about software security.
So the executive order really sort of made everyone stand up, focus on it.
And for organizations that were starting to think about it, accelerate towards building that out.
And also it helped the community that was looking to provide solutions both in the open source world and in the commercial tooling world, and say, oh, now we actually have to get our game up and we can go find people and help them do this.
So it went from a nice to have to, oh shit, we actually need to do this.
Right.
And I think that was the fire or the sense of urgency that really kicked off the whole ecosystem, I would say.
Right.
I think it was right.
This is an example of, you know, to zoom out when we talk about what's the role of government in cybersecurity, I think this sort of shows these two roles, which is one, we can start the conversation, we won't run it, but we'll sort of help it.
And then as progress is made, we can say, all right, now let's make it an actual part of how we think about our commercials.
They used to talk about part of a balanced breakfast.
So now this is part of the balanced breakfast that is supply chain and security.
And what we have seen since is obviously a lot more debate around S bombs, but you've also seen it creeping into other frameworks.
So NIST two, which was released, what, two months ago, three months ago, which was an overhaul on NIST one, obviously it stops just shy of stating s bombs as a requirement, but it kind of hints at, well, I guess the word used was transparency software transparency.
And I think that's, they don't say S bombs, but it kind of implies it, I guess.
And I would say you start to see more and more of that creeping into various frameworks beyond government as a buyer.
Right.
I think there's been some people have looked at payment card industry, PCI, DSS Standard and said, oh, you need to know everything that you're running.
And that according to some interpretations would include the full dependency model.
We're seeing some great work advanced from other governments.
So the Netherlands published a starters gig to help dutch companies make progress on this.
The Japanese are now on version 1.1 of their national guidance on how to think about S bomb.
So one thing is even while it's starting to enter long term requirements, we're realizing, okay, we need to give a little more help and guidance to help people move in that direction.
Yeah.
And yeah, Japan indeed seems to be a pretty strong country for the S bomb, in the S bomb community, even though they're not like a country you think of usually in the tech world, but in this, they are punching above their weight in the contributions, I would say, in this space.
Right.
I agree completely.
The Ministry of Economics, Trade and Industry, METI has just been doing great work in promoting this in the japanese industry as well as working with global partners on this front.
And I think they are looking at the supply chain and taking it very seriously.
And we can go all the way back to thinking about the origins of modern supply chain science.
The Toyota revolution with Deming.
That's something that Japan has always been a leader on.
And so that's one of the stories we can tell about how they became such a great leader.
But I think you're right, this is a real feather in their cap for sort of being in some ways even more advanced than we are here at CisA.
Yeah.
And it's funny, I've been invited to a few of these s balm working groups or various things.
One company that stands out is Lockheed Martin.
Right.
They've been very vocal in supporting, and Ayan is one of the guys leading a lot of things in the S bam world.
And I guess there are some parallels with how a company like Lockheed and the manufacturing sector in Japan sees the world.
Right.
They are very process oriented and very structured, and I guess that plays to their strength.
S bombs really plays to their strength culturally, I guess so.
I'll give echo your shout out to Ian Dunbar hall, who is one of the leads at Lockheed, and his focus has been on open source.
And I think that's one of the other pieces that has really helped us appreciate the importance of transparency, is we all kind of knew that very few people write their own software anymore.
Everyone was sort of vaguely aware of the importance of open source, but especially with the log four j crisis and the realization that really made senior policymakers stand up, the White House had a sort of emergency meeting just a few weeks after that vulnerability broke, saying, guys, what are we going to do about this?
This is something that now needs to be addressed at the highest levels.
So that realization of the widespread use of open source and a recognition that it's not bad, open source is great, but it requires those of us who use open source to track the data.
And that's where SBOM comes in, which is it helps give transparency on the use of open source.
And it also highlights something that people like myself have been working with open source and in open source world for a very long time now.
It shows you that how dependent we are on a very small amount of people.
I mean, just look at the OpenSSL vulnerabilities two years ago, and there are so many of these libraries that are maintained by one or two people that are used as transient dependencies for so much of the blueprint for the modern web based applications or any modern applications.
And I guess Sbon's really put spotlight on that, right?
And we need to figure out a long term strategy for this.
I think you hit on a couple things there.
One is the idea of transitive dependencies.
Yes, I know that I'm using this library, but it turns out this library depends on a dozen, and each of those depends on another dozen.
And so we sort of this radical massive under the water line set of dependencies.
And then two, having visibility in and of itself is not the goal.
The goal is using that visibility.
So you talked about single maintainer projects.
Well, if you're a corporate risk officer, that should be high on your risk.
What happens?
There's a common term in the community called the bus problem.
What happens if someone gets hit by the bus?
It's always been very macabre to me.
I prefer either talking about what happens if someone wins the lottery, or what happens if someone gets a romantic partner and then says, oh, this is a lot more fun than maintaining an open source project.
And so having that risk on book is critical.
And so again, it's not just about finding known vulnerabilities, but understanding the overall risk picture.
And absolutely and I think an extension of this debate is really how do we fix this and make open source sustainable?
The glib C vulnerability earlier this year about the openssage is a good example of that.
It's like, yeah, it was a few overworked people that just were a bit too trigger happy on hitting the merge button.
And who can blame them?
It's not for a lot of people, it's not their day job.
It puts spotlight on that show problem that we've seen the open source world, we'd known about it for a long time, and much of it comes down to purely about funding at the end of the day.
And this is where I can give a shout out.
CisA does a lot of work across cybersecurity and we have recently, along with everyone else in the world, looked at open source from a security perspective.
We stood up a special office.
We've hired a couple of great people who come from the open source world and indeed are skeptical of not just government, but also big corporate model to help us build.
And we recently published an open source security roadmap of what we need to do features prominently, both in terms of how we're going to use open source in the government.
One of the things we call for is having open source policy offices in government agencies.
So most big companies, both in the US, Europe, Asia, have auspos, and government should too.
And also making sure and prioritizing the idea that not only were you responsibly using it, but part of responsible use means giving back, making sure that we are aware of the communities that are building and maintaining them, and ideally helping out in time, in resources, in other ways.
And so that's been a priority for us at CISA, independent of the whole s bond thing.
Yeah, I mean, I think that's a great priority.
I mean, I think open source should be almost considered a public utility in almost like road czar, because we are all dependent on them.
So there is, I think, a valid argument to say that, yes, taxpayer money should, it probably support this, just like roads in a sense.
And I want to sort of tip my cap to the german government, which has funded a number of efforts to do exactly that, sort of identify key areas in the open source world and support them through direct grants using the existing foundation structures and organizational structures that the open source world has created.
Yeah, no, that's a good example.
So let's go back to cybersecurity frameworks a bit, because the other thing beyond NIST is the EU Cyber Salient act.
And Dora, which I believe EU Cybersecurity act is a subsection of Dora.
Or maybe they're independent, I'm not fully aware.
But that's another legislation that is pushing the european side to play catch up on the s bomb side.
So maybe if you want to speak a few moments, a few minutes about how you see that.
Sure.
And this is where I get to do the caveat that, of course, I am not an expert on european policy, but we do try to work closely with both.
The European Commission staff is helping to assemble these as well as Anisa, the European Network Information Security Agency, which often gets tasked by the commission to sort of drive technical standards.
And the Cyber Resilience act calls trying to raise the floor of security properties, not just for things that are purchased by governments, but in their case, they are addressing everything that is sold in the European Union, which is pretty large market.
Everyone who sees themselves selling things sells into that market for s bomb.
The vision that's spelled out is not that it has to be made public.
I'm sympathetic to that.
I think we may not be ready for every organization to make their s bombs public, and we can talk about that if you want to.
But their vision is you must have an S bomb internally.
And I think that's half the battle, is saying you should not be selling things without having the data easily available in a machine readable form so that you know what you're selling and so that you can respond when I.
There's the next log for J Glib, C crisis, et cetera, and potentially make it available when asked to your national regulator.
And so that is going to again be more of helping national cybersecurity regulators sort of up their game as well.
So that's the vision that is spelled out in the CRA, which is sort of, hey, everything has to have an S mark, right?
And then let's go back to the executive order, because that was a mandate for anybody selling software to the us government.
They need to provide an S bomb through like an S bomb portal.
But that got pushed back, right?
There was a deadline, I believe, last fall.
Was it?
And then it was pushed forward until.
Yeah, you tell me the day I forgot.
But I know it was delayed, at least for the implementation.
So here we're getting to the nuts and bolts of how sausage is made, where an executive order, high level vision shared by the president and the White House, and then it's up for other parts of the government to spell out exactly what that means.
We need to be right.
You can't just say, do something without defining exactly what you mean by something is.
And so a different part of the White House office of Management and Budget said, well, actually, let's go further, which is first, NIST, the National Institute for Standards and Technology, incredibly smart technical standards people defined what secure development means writ large.
So they published a document called the Secure software development Framework, SSDF.
And that framework is really helpful.
It sort of lays out, if you want to get a secure development process for your organization, here are all the things that you need to think about, and it's organized hierarchically.
Think about these broad buckets.
Inside each of these buckets, here are sub buckets.
Inside each of these sub buckets, here are some technical standards that you can go and look at to find out exactly how to do it.
So it's very helpful for organizing strategy.
Then different part of the White House office of Management Budget came along and said, okay, now, to make this a reality for purchasing, we're going to create something called a self attestation form, where we're going to map specific pieces of that secure development framework.
And each company had to say, okay, I pledge, I'm putting my name signing a document that says, I am doing this.
So in this case, it was, I'm using multi factor authentication across my organization.
I am tracking, I'm using vulnerability scanning on this software.
And for Sbom, it was, I am tracking the provenance of my code and third party code to the greatest extent feasible.
And so that's now sort of written into this form.
We wanted to get that form right.
This is the first version of the form.
So we've publicly said we're going to be updating it, but this is the first version.
And so we gave ourselves an extension as government, but we don't think that too many people industry were complaining because we wanted, they would sort of rather us, hey, get this right.
Still working on making forward progress.
We wanted to make sure we could incorporate technical feedback that we had heard.
And so that went into effect in June for critical software, and then it'll go into effect for September, for June of this year.
So it's already in effect as we're recording.
And by September of 2024, it will apply to all software.
Okay, and I guess we're going to zoom in on sboms and actually, from a tech perspective next.
I think that kind of brings it into a natural transition into, like, the neon's the best bombs, because, yeah, I think most people can agree on that's a great idea.
But the devil is always in the details, right?
So there are two major formats of S bombs.
There are more, but two major formats that are, I guess, considered quasi standards at this point in time.
There's Cyclone DX and there's SPDX.
Do you want to speak a bit about both what they are, their purpose, and who's backing and supporting them?
Sure.
So we want to convey this data.
Data should be conveyed in a machine readable format.
And, you know, when we set out to do this, were hoping that we would avoid having to make a new standard, a new way of conveying this data.
And the good news was there was at least one data format that was already out there in 2018.
The bad news was that there were two, and it didn't look like they were going to merge any time soon.
And there has been some healthy competition between the two data formats.
Competition is good, right.
It breeds quality.
Sometimes we could do with a little less sniping because it has fed.
When they criticize each other publicly, it tends to give fuel to people who don't want to do anything.
As an example, from my perspective, in the us government, we've adopted a position of radical neutrality, which is, they're both great, they're both open source, they both have active communities developing them, they both have active communities making tools for them.
They both have companies that are shipping s bombs in those formats today.
More importantly, at the end of the day, it's just JSON, or in some cases, still just XML.
And you know what computers are really good at?
Well structured data.
Right?
So we've adopted a position from the beginning that we're not going to interfere in or pick a winner in a standards discussion.
Again, the United States government doesn't have the best track record in picking a winner or a loser, a technical standards fight.
So we're ticking very.
One thing we have done is working with some colleagues at the Science and Technology Directorate of DHS.
We have helped create and fund a translator tool.
It's now an open source security foundation opensSF project called Protobomb Public.
And the vision here is it'll translate between them.
It can be freestanding, but it can also be integrated into tooling.
And so that really, for us, means everyone should be able to produce an S bom in either format and consume an S Bom in either format, and it shouldn't matter which.
And when we talk to large organizations, almost everyone else, almost everyone who's sort of starting to mature said, yeah, maybe we'll start in one or the other.
But we, and again, one exercise, they're both great.
We love all of our children equally, but they are.
At the end of the day most organizations are sort of gearing up to say, yeah, we can handle both.
And if you submit to the government portal, the portal itself is agnostic.
I think it only accepts Jason, but it's agnostic either side.
Either format you use.
Yes, at the moment the way to submit to the general us government submission model is we're not doing any validation at the moment to say is this one or the other?
Yeah, right.
All right, let's dive into what's the actual content of an S bomb because this is where it gets interesting and a lot more complicated because in theory we can agree, yes, it makes up for what the software includes, but it gets a lot more murky than that, obviously.
And the same goes for the formats.
In theory they have the same data, but in reality they don't.
So maybe speak a few words on what does that look like and how does that, what's in these JSON files?
Sure.
So from our interest, when we sort of say thou shalt have an S bomb, the first natural question that everyone should ask is what's an S bomb?
And so we want to be specific.
So we start out with some easy ones.
It's got to be machine readable in a widely used data format.
So some of the early language said here are three potential formats.
S wid was originally sort of potentially seen as an option.
Software id tags.
There hasn't really been uptake, there aren't tools.
So now we really talk about two formats.
So that part's easy.
Then we start asking a couple of different questions.
First, got to have the software components okay, what data do you need for each component?
And trying to flesh this out is important.
The overall goal is you need to have enough data so that most of the people that are using the SBom data can say okay, this is the component, we're all on the same page that it's this blob of bits.
What does that look like?
Well, we can start talking about who's the supplier, what's the component, what's the version.
We're good, except these are sometimes a little tricky to define.
Is it Microsoft or Microsoft Inc.
Is the component Windows ten or Windows ten?
So we're bumping into the naming problem.
There's no obvious solution.
We can talk a little bit about that in a moment.
Then there's some of the identifiers.
So the government funded vulnerability databases tend to use CPE, common platform enumeration, large amounts of open source has sort of settled into package URL's or perls.
Perl isn't an identifier per se.
It's an identifier wrapper that takes advantage of the fact that many, though not all, package managers have a unique local namespace.
So I just point you to NPM, and NPM's job is to make sure that there's only one foo in that database or in that package.
Then we start to walk into some of the other types of things that we may want.
Well, hash is always useful when you're talking about bits.
How do we take the hash?
What format do we use?
And as we look at complex systems and complex directories, what am I taking the hash of for a directory?
So if I do that, and there are always fun edge cases on how to take that.
So there's some basic data that we want for each component.
One other thing that often comes up is key use cases, license management.
It's not always a security issue.
You can tell the security story around licensing.
Let's put a pin in that for a second, because I want to dive into the whole use case afterwards.
Let's start with the structure, and then we can zoom into the actual use case after, because I think that's worth a longer discussion.
We've got the basic type of data that we need for each component.
This has been spelled out in a document called the NTI minim elements.
That was written in 2021.
That's a lifetime ago, three years ago, which it's nice to look behind us and say, oh, we've made a lot of progress.
So there are a number of efforts to try to update this so that we have a shared vision, not in the formats, but a little higher up to, say, specification.
What counts as an S bomb?
Then we talk about the structure itself.
So in theory, a simple vision of an S bomb is just a tree graph or directed acyclic graph, and there'll be some joining.
Right.
Two different parts of your supply chain can use the same product.
Depends on the language and context about whether you have multiple copies or not.
So one key question is, what's the depth?
Three years ago, when we first started saying this, wasn't sure that we could actually say, have a complete sbom.
Tell us everything that's in your software.
So the language that's used from three years ago is have all the information for your direct dependencies, your top level dependencies, with enough information about each of them so that you can find out more.
Right.
I think moving forward, there are going to be calls to have better ways of describing depth and pushing for more depth.
Thinking about log for j, that was almost no one's direct dependency.
It was definitely transitive for most approaches, but there are some that are conquered.
So the german government, for example, has written an s bomb specification that calls for a complete s bomb.
I think that's a wonderful aspiration, but it's unclear whether we actually will get there today, also very next year.
It's possible, yeah.
It's also very language specific.
Right.
Some languages are more mature than others to do these transient lookups because it's fairly complicated to do this well at scale.
Right.
And now we're getting into the nuances.
If we're trying to apply this to all software, the language is important and the type of tool that we're using to capture the data is going to be important as well.
Absolutely, yeah.
And then we've spoken largely about an SBom being a JSON file, but in reality, in any real beyond like a hello world reference implementation.
And if you look at a product we can use like a smart thermostat as an example.
Right.
You would have, you would have an iOS app, you would have a backend, you would have probably a web front end, you have a firmware.
All of them would have separate S bombs.
That needs to be all linked to.
And there is, in Cyclodx, at least there is a reference model where you can say, here is a pointed to another component.
Because the argument we saw earlier almost like, well, let's just flatten everything to a list.
But that becomes completely unusable because then you're like, oh, I have this vulnerable dependency.
I have no idea where it actually comes from.
Indeed.
And for, even for something straight forward of a system, we can say this is the hierarchy here.
I've got this system with this subsystems.
As you start to look to more complex, especially embedded space systems of systems, that's where we are sort of bumping into some challenges where there isn't an intrinsic hierarchy.
And so we just need some way, some common way of having, of relating these.
We're spinning up a work stream at CISA that is trying to look at this exact question, which is how do we think about complex systems of systems?
A cardinal where, okay, what's the top, what's actually dependency?
Are these subsystems all in direct dependence of the car?
And then they have their own.
Is there a better way that we can do it?
And again, trying to focus on the use case and then working backwards, say, okay, that's how we should represent them.
And I think you don't have to go that advanced and complicated as a car.
You just have to look at, say, microservices.
Right.
If you have a Kubernetes cluster that runs a few microservices, well, each service would have some language specific dependencies.
So that rust, Python, go, whatever that may be, you then have a docker container that runs it, which would have its own set of dependencies there.
You have already here at a per container basis, you now have two sboms for each microservice, and then you might have 20 microservices running in the same cluster.
That makes up for a product, a simple source product, because having.
Right, 510 microservices is kind of boilerplate or very common today, like, as we've moved away from monoliths.
Right.
So I think that's, there's a problem far earlier than that.
Agree.
And modern, dynamic applications sort of bump into things where, okay, hey, how do we treat these dependencies?
Since not everything will be called in a deterministic fashion.
Two for third party API calls, or even local but ephemeral APIs, also a little tricky in terms of being able to track them.
There's some really good work that's happening in different corners of the ecosystem.
CNCF has been doing some great work on this.
OWasp has been doing some good work on this, of sort of trying to say, here's a way to describe at least most of the problem, and we'll document the tricky edge cases as we go.
Yeah.
So, as I've been kind of like emerging myself in the sbom world, one thing, the first thing I discovered when I started to apply this at screenly, and building SBom to screen was first, was the whole, like, well, we have ten microservices that all have separate s bombs.
Then we have some other things here, but then finally we have a device side of that as well.
So building this whole device structure became somewhat complicated.
And then once we started to realize that was the first problem, the second problem was, well, an S bom is a snapshot in time truth.
It's not an absolute truth.
Right.
Every CI CD pipeline run, you do, even if you pin your dependencies, your transient dependencies may not be pinned.
So every single run would potentially produce a different s bom, unless you have a deterministic build, which is a nice idea, but in reality, nobody really does.
Be nice to debian.
They're great.
Right?
But I mean, like, but even if, regardless of your distro, right, like, it's, the reality is that it's not, it shouldn't be considered a static element, as I think a lot of the debates talk about s bomb tend to treat it, but rather a dynamic element.
And this is where we get back to the idea of why are we doing this?
And the goal isn't to just have the data, it's to make sure we have the data available for use.
So last year, CiSa published a document that was drafted by the community on what does SBom mean for SAS?
And acknowledged that there are some differences.
So in terms of a use, if I'm looking at a blinking box that's keeping grandma alive in the hospital, I need to know what's on that because the manufacturer may disappear or there may be a short term vulnerability.
I can't patch it since grandma is still plugged in, but I can know about what's on there, so I can take other mitigations.
If my data is in a SAS platform, then I won't have the same operational role.
I can't patch SAS.
And my option may only be just to like, say, I'm going to pull my data off.
Now, most of the major attacks we know about, it's too late, but there's still lots of use cases that we can have.
So one is just compliance.
Let me just make a regular approach to say, okay, I need to know on a regular basis that my data isn't touching software that was created by a company that's on a government's no list.
So, you know, for example, in the United States, we just said no Kaspersky labs.
So people will need to be able to show that they are complying with that.
But also, let's go even further back, which is before I sign the check and before I commit to putting my data and my customers data on SaaS or having that SaaS integrated into my operations, I want that snapshot.
That snapshot still has huge value, and we can talk about how often I'm going to want that.
So I agree that, yes, a daily build, an hourly build something faster means that the data isn't going to be fixed.
But that's okay, because a lot of what I need to know is either is one, does my supplier of the s bomb, my supplier needs to be able to instantly say, oh, God, someone's exploiting this now let's go make sure that we're covered.
So that's one piece of value, too.
We bucket this in terms of s bomb is value for the people who make software, for the people who choose software before I make that decision.
And then once we're operating it and just in SAS, we break that last bucket into the operators and the subscribers because, you know, hey, you know, my local instance may be run by a third party that's not the supplier, but they still have admin rights eyes the subscriber don't.
So there's roles for everyone in that, in this model.
Yeah.
No.
The reason why sbombs even appeared on my radar, I've heard the phrase from time to time at conference talks and whatnot.
But the reason why I started paying attention to it was really like we started to get a, our customers asking for response.
And that's kind of that screen.
That's when I started to like, oh, this is more than theoretical.
Nice to have is actually, this will become a thing.
Right.
And that's when I'm like, how do you make that operational?
And that's why I was like, I, for me as a SaaS, coming from a SaaS world, like the whole generation and sharing needs to live in a CI CD pipeline.
Otherwise it's just a snapshot in time, which you are correct, it has value, but not as much value.
Right, right.
And in fact, where we see the most adoption for s Bom today is internally developed software by mature organizations, you know, banks, large corporations that produce a massive amount of software.
But it's all written internally, ideally with good modern tools, good modern processes.
And Ns bom should just fall out of your CI CD pipeline.
It should be a natural part of as you track where your containers are deployed.
Great.
Track the metadata in that.
Metadata should be, heres everything thats in that stripped down operating system thats running in your container.
Yeah.
And that takes me to another thing.
There was a report bringing out from Saisa about, I think was called the sharing prime or something like that.
The sharing report that talked about how s pumps are being sent and shared.
And to me it seems like the way sbums are dealt with today is much like we dealt with software patches in the nineties.
Like we're sending patches by email.
Right.
That's still, I've spoken to quite a few companies about their spons in last few months.
And to a great degree, it's just a tick box.
It's just like, yes, I received it and I put in my sharepoint.
Cool.
That's the extent of it, right?
So I can say, oh, cool, I have received it.
Great.
And that again is a snapshot in time.
At one point it's probably like 45 build releases behind what is actually running production.
So again, it depends on how we're deploying our software.
If I'm sending an update, pretty straightforward.
If I'm sending software that's ending up as bits on a platter someplace, then it's pretty straightforward.
You move your blob, your metadata comes with your blob.
We get a little more complicated when we get to devices, embedded systems, where of course, in the SaaS context, right now, what a lot of the major manufacturers are doing is they're setting up portals.
Now, I was an adolescent in the 1990s.
For me, the best year of music was 1994.
And kids these days, they need to know about music from the nineties.
But we don't need to tell them about portals.
We don't need to go back to a web portal model.
We need to have a better way of having this scale.
The biggest challenge is, of course, for access control.
So how do I make sure that my customer can get the data but that it's not public?
Totally get the idea that we don't want this to be, or many organizations don't want this to be public today, I think where we will head eventually may involve more of this data being public, just because it's such a hassle to have scalable access control where I can have the data and I can feed the data into my vuln management, my asset management, my data lake, my CMBB.
And managing that flow at scale is going to be key.
The newest market that I've seen has been in the vulnerability of the SBom management space, where, as you say, okay, how do I track data is coming in?
How do I automate that?
How do I map that data to where things are deployed?
How do I map that data to my compliance engines?
And that is right.
Plumbing, as folks who work in it know, plumbing is boring.
And it's also one of the things that everyone at the end of the day is going to have to pay for, because data management at scale in an automated fashion means you've got to usually have some system that just puts all of the pipes to each other.
There are a couple of great organizations that are doing this, some of the big players, but also a number of really cool startups in this space.
Yeah, because what we really need is the equivalent of GitHub for s pumps.
That's really what we're looking for.
I think that's a reasonable analogy for the context.
Cool.
Well, we've spoken at length now about what sboms are, and a bit going at that.
So now we talked about cycling DX and we talked about SPDX.
But let's talk a bit about why there are two formats, and you kind of hint at this already with licensing being one of them, which is where SPDX coming from.
But let's talk there.
Let's start with SPDX.
Their focus is licensing and SPDX.
So SPDX was the first approach for managing this data, and its original model was for licensing.
Right.
It was a Linux foundation project, because the open source community was tired of I've got this lovely project, maybe it's under a patch here at MIT, and then someone does some commits and whoops, I've been running GPL code.
So even the commercial world sort of has some challenges.
Even the open source world is challenging that.
Cyclone DX came along out of the Oauth world.
The DX is actually sort of a nod to SPDX for that.
They're both, again, I'm going to read it.
They're both great, and both of them get the job done very well.
Both of them are evolving.
And all of the problems we've talked about in terms of the nuts and bolts of implementation exist in both.
The implementation stuff is at a higher level because the philosophies are different.
There are some subtle differences.
So SPDX was built to convey data across supply chain, and so there was sort of an intrinsic idea that it's going to flow across organizational boundaries.
And so that's why I think we've seen uptick the most adoption from large organizations that are supply chain focused, that are thinking about the data is going to move.
And the implementation of SBOM comes from engineers and managers who are thinking about supply chain.
Cyclone DX comes out of Owasp, and so it's sort of built by devs for devs.
And so that's for people who are saying, I want to implement Sbom that are wearing their developer hat or their appsec hat, as opposed to a product security hat.
If they're wearing an appsec hat, Cyclone DX is just.
It's going to resonate a little more, right?
It's sort of one of these sort of, you see rhymes and it sort of.
It wears your clothes.
That's not a universal thing.
I know plenty of appsec people use who uses SPDX.
I know a number of major P certs who use Cyclone DX, but that's sort of where you sort of see the resonance.
Both of them are aiming for international standard status.
But again, where I think we should be ultimately focusing on for governments and for policy is don't standardize the format, standardize the specification above it.
Right.
And at least as of this recording, it seems like Cyclone DX is the one that has more momentum right now, at least from what I can see in terms of tooling at least.
But maybe that's, maybe you have a different opinion on that.
You know, I haven't done the legwork.
I talked to a lot of people who like both.
And again, I think it's sort of, it speaks to the communities.
Right.
If you're in a dev world, you have many small open source tools.
If you're wearing a product security hat, then you're going to have a little more of custom rig and you're going to be sort of building for scale.
And that's just again, I really don't see either moving more.
Both of them keep adding new features.
Cyclone DX has sort of added a lot of saying, okay, well, we can provide bills of material in other formats.
SPDX has done a very similar thing where they built out with a different philosophy, where they built out a formal data model, which is a very big deal in the standards world with a new SPDX 3.0.
But tooling is only beginning to emerge that is specifically targeted at 3.0.
I wish they had been a little faster on the 3.0 rev.
Yeah.
Because a good example of that is this notion of referencing other s bombs in SBOM.
Right.
Cyclone DX added that in 15176.
I believe they're one seven now, I think.
Right.
And that's just coming into SPDX three, which for me feels like a fairly critical building block in doing this at scale.
It is.
I mean, to get deep into the background and again, the Cyclone DX, sort of reflective of, sort of the appsec world, has done a bunch of small revs, introducing features that sort of said, okay, we'll figure out the details as we go.
SPDX, I think, because again, they're working with some larger organizations, said we're going to create a more formal model.
Again, personally, I wish they had moved a little bit faster, but I think it's one of those invest now so that you can scale more later.
I don't think either of them are inherently better or worse.
My advice is look at both of them and see what meets your needs the best.
That's fair and pragmatic.
And just to recap that SPDX is more oriented towards licensing and cycle NDX, more oriented towards security due to their roots I guess lithe federation versus OWASP.
I don't think it's licensing per se.
I think it's that because SPDX can definitely convey security, it's the.
Are you oriented towards keeping?
Is this, is the data going to be used locally?
It's going to be used where the focus is.
And again, Cyclone DX can definitely be shared with customers and things like that.
I don't want to dismiss this, but it's sort of the philosophy behind it is I want this data to keep it as I'm doing my dev and AppSec work, whereas SPDX is saying, yeah, I want the data locally, but I also, right, it seems to have a philosophy of saying, let me share it on the supply chain side.
So it's sort of the.
And you need security data on both pieces.
So both of them, I think are, yeah, I do.
No one benefits from having two standards that actively, publicly fight.
And so this is where I keep coming back to.
If you're an organization that is going to be using S bombs or sharing S bombs with your customers, you should have a long term plan to think of it to be bilingual.
Right.
We're all going to be Canada.
And in the short run, either one is great.
Pick the vendor you like, pick the tool you like.
Start with that.
Right?
That's fair.
That's fair.
All right, so let's talk about tooling, because this week, just this week, or last week, I think, was, there was a report coming out of an italian university where they'd done some work around s bombs on what SBom generated from GitHub's dependency graph, right?
Because we all agree that s bombs are nice and they have utility, the devil's in detail.
How do you implement it?
How do you use them?
How do you build them?
And it seems to be that the obvious thing for most people, including myself, when I started looking at this, it's like, well, GitHub is probably where I want to start looking at this.
GitHub has my source code, they have my dockerfiles.
They're in a pretty good position to build a high quality sbom.
Turns out that it wasn't quite as straightforward.
Do you want to speak a bit about that report and kind of like the, I guess, controversy in a sense of their findings?
Sure.
So this is work out of the University of Sano and the University of Salerno down in southern Italy.
Really exciting.
One of the things that I love about my job is I got to say, hey, let's get this random.
I think he's a first.
The author wrote it as part of his master's thesis.
His advisors joined it and so he published it at a pretty good tier ACM conference.
And then I got to say, hey, come, I want you to talk to 150s bomb experts.
I didn't get to do that when I was a junior PhD student, so that was just a lot of fun to sort of engage that.
It's not that GitHub data is useless, it's still valuable.
The question is, how do we get as complete data as possible?
And I think we're now at a point where when we started off with s bom, it was a dear God, have anything is better than nothing because we just had so little visibility, especially as we had more complex projects that were multi language and that we're using other people's dependencies that enlarge dependencies.
We're now at a level, at a point where collectively we're talking about the quality of data.
And so where we wanna, if we're looking for good data we want to get into, how do we make sure that we're getting the max amount?
This is where some of that first wave of free tools may not be getting us as complete information as we want.
It's definitely a good starting point, but for organizations that want certain assertions, I refer to this as proving the negative.
How do I say with a high degree of confidence that something is not in my product?
If something is not running on my network, then you're probably going to want to use some specialized tools that are built for the language, for the architecture, for the sector, because there are, you know, a car is not a heart monitor.
And we now have companies that specialize in S bombs for automotive systems and S bombs for medical devices.
Similarly, you know, go Lang isn't c.
And there are communities that are specializing in sort of building out s bombs for different types.
And I think because one of the problems with generating S bombs in an automated fashion is it's hard to differentiate by.
Neon says, right, how do you programmatically determine what's a dev dependency or what's a test dependency versus a production dependency?
Sure, you could structure a repo so that it makes sense for a human to parse that by just naming conventions, but there are no standards to that scale across languages.
So that normal tool can do that for you right now.
Exactly.
You've hit one of the key things that has really risen is, okay, if I'm just looking at a source repo, I may have a lot of other things in there.
Is this detrimental?
It's going to oversample, right?
It's going to give you a false inclusion, which I would argue for almost all use cases is better than a false exclusion.
But it still doesn't give you this sort of accuracy where we measure this.
I think it sort of does.
It's almost a philosophy of science question or philosophy of technology question, which is there a true platonic absolute correct s bomb out there or does what's in my software really change based on when and how I measure it?
And other parts of science have dealt with this question, and it's fascinating.
I spent time studying philosophy of science because it was a nice change of pace from engineers.
And the common ways of where we look for s bombs and how we measure them, we can say, okay, first case where a lot of people start is source repository, and that's where a lot of the research is happening because.
Right, GitHub open data.
So you can see, but there are many reasons why source won't give you truth.
There's, one of them is, as you mentioned, there's a lot of other things that are going to be in a repo that look like dependencies, but that are the not actually prod.
Another is your compiler is going to do weird things.
I think there are like seven people in the world that actually understand how compilers work.
It's dark arts, and trying to manage that is tricky.
People will often say the purest place to actually measure and build your s bomb is at time of build.
And the, that's great if you can.
Sometimes folks will say, after I don't have access to the build, right, the software already exists, or I'm using a, you know, I'm using a binary as part of my build, so I still need it.
So then we have binary analysis tools.
This may not be optimal, but it is often what we have.
And I'll also say that binary analysis tools have gotten a lot better in the last three or four years.
It started off as pretty basic stuff, which is just you throw a commodity decompiler and then you do some string matching.
There are now organizations that really have specialized in different kinds of binaries.
They know the languages, they have experts in languages, and they just have incredible data as well.
So this is almost, it's usually going to be proprietary, but there are lots of cool things out there.
We see this a lot.
There are a couple companies that are doing build s bombs for embedded systems, but a lot of the embedded and critical infrastructure stuff that matters to governments happens in binary analysis.
And then there's a long tail of where else we can measure so we can say, hey, listen, if I'm spending $5 million on a piece of software, chances are it's going to be custom.
And so I want to look at not what was built, but what was actually deployed in a complex ot system or in a complex web, you know, private cloud system.
Then the last place that people are measuring it is there's a term of a runtime s bomb where they say, ok, the only thing that matters is it's running.
So I'm just going to build based on what's running.
I think that's really powerful, that fits into the XDR model of cybersecurity, but it isn't as useful for some use cases.
Like I need to know what's in there before I run it because I want to make the decision.
Or like the Glibz example is a good one for that.
Right?
Like you might have an openssh and like, yeah, that looks fine, but the reality is that it's actually vulnerable because of the sub dependency or this library.
Exactly.
Yeah.
All right, so that's, I think is a good way of painting all the neon sets there.
Then the last thing I want touch on is kind of like auxiliary features around their spawns.
So we have a whole family of S bombs, and the one I kind of start with is O bomb, which is an operational material, which kind of goes into what we're talking about, where S bomb is one tree.
Oh, sorry, one.
One arm in this tree, or one branch, I guess, in a tree.
And then you have more information about how is it actually running.
So maybe talk a bit about how does this fit into the whole framework and structure.
Sure, sure.
So S bomb will not solve everything, right?
I had to sort of repeatedly say the SB and S bomb does not stand for silver bullet.
An S bomb will not go pick up your dry cleaning or watch your kids if you're running late.
But so as we think about this, we want to look at other types of data.
There are a couple of different philosophies of how we assemble our data.
One is to say, let's build a single model that can cover everything.
And another approach says, hey, let's focus on gathering data through separate models and then linking both of them are challenging.
Very large data structures don't have a great track record.
Trying to have sort of some one size fits all approach where we can put all the use cases together often disappoints, especially if we don't have a very expensive and time consuming formal data model.
On the other hand, the assumption that says, well, let's have data and link it together, well, that requires really good identity and the ability to sort of actually say, this is correlated with this, and we can track them all the time.
And they're dynamic.
It's a dynamic object, not a static.
It'S a dynamic system.
What I try to focus on is let's make sure that they're all built for automation.
And I'll give an example of some work that's happening right now on something called AI bombing.
Hey, we can't have a podcast on cybersecurity without mentioning Aih.
So you almost.
Yes, and some people say we have software builds of material.
Let's talk about what we have for generative AI.
And the vision is to, there is some work that exists already.
So we have data cards, we have model cards and things like that.
But are they machine readable and are they machine generatable?
And sort of, for me, that's sort of the table stakes is making sure that we're not just logging the data, because if you log data can be thrown over in a corner, in a pile, but we're actually keeping the data in a way that I can slot it into other tools to use.
And that's some of the discussion that's happening right now.
This has a working group that's run by some super smart people who have both security expertise and AI expertise and sort of trying to say, okay, how do we move towards transparency that's built towards use cases?
Same thing.
There's been some great work on cryptographic build materials where as we shift and orient towards a post quantum world, let's start tracking key material.
Let's start tracking what algorithms are being implemented.
And Cyclon DX has done some great work on this.
But again, it's good to make sure we can map them.
There's no reason why we keep it.
In the same structure.
Yeah, exactly.
Because that needs to live side by side with your s bomb for your backend.
Right.
Because it's a function of the backend.
So they are inherently related.
Right, agree.
But the data, the challenge of keeping things together is if there are hidden assumptions that aren't there.
Right.
So my cryptographic build materials is based on my work, but I also have s bomb data that came from somewhere else.
Well, do we assume that data is there?
Same thing, similar thing with the keeping vulnerability data with the s bomb.
If I know how all the data was generated and it's live, then by all means, it would be stupid not to keep your vulnerability data closely bound and integrated to your SBOm data, and that's why a lot of teams do it.
However, if we think there's a chance that mysbom data is going to move to a different organization, then we're introducing a huge risk, because I don't know if that vulnerability data is going to be kept live.
That's one of the core challenges is making sure that we can do this.
My counter argument that would be.
Well, if you assume that the Sbom is a snapshot in time generated at build CI CD, however you do that you can then if you include or nothing, it's relatively trivial with open source tools today to generate a list of CV's or vulnerable packages based on any sbom, right?
So I guess including or not, it's kind of like.
It's kind of like.
What's the phrase I'm looking for?
It's a silly way of obfuscation, right?
It's not really.
You're not actually solving anything, you're purely obfuscating it.
It's still there.
You could easily look it up.
So it's not like you actually.
It's not unless you run the version of it.
No, I agree completely.
But again, that speaks to how the data is going to be used.
And that's where we need to be explicit about what assumptions are in the metadata.
And so as long as everyone has that slotted in, it's great.
When we have a mismatch between how the data was collected and maintained and how it's being used, that's where you're going to have.
Right.
Whoops.
That slipped through.
And now we have another.
The famous Equifax breach.
Equifax had a scanning tool.
It just wasn't scanning the right things.
And so that's why their infrastructure was still using Apache struts, the vulnerable version.
And we have one of the most costly data breaches.
Right, fair enough.
Fair enough.
The last thing I want to figure, I want to talk about is the security side of this.
You already mentioned Vex.
And maybe for people not savvy in both terminology and Sbom Lingo, what's Vex and how does it fit into the whole SBom conversation?
Vex is the vulnerability exploitability exchange.
Probably one of the worst name projects in all cybersecurity.
It was my fault.
They said, we need a temporary name for this.
Let's just give it this name.
And some of you may know that the most permanent things in the world are temporary government ideas.
So we have that.
But the idea is pretty straightforward, but also I think, really important, which is that we need to not all vulnerabilities actually put someone at risk.
There's lots of times where I may be using a piece of software and having, and using vulnerable software.
Right, OpensSL version, old, but I'm only using the pseudo random number generator and so the web server piece is not even going to be included in my product.
Maybe the compiler strips it out and so there is no heartbleed risk.
But a naive scanner will see versionold old and it will just light up saying heartbleed, heartbleed.
Vex is just a machine readable way of communicating whether or not a vulnerability affects a given piece of software.
So it's a binding of some sort of software identifier, some sort of vulnerability identifier, and then a status.
And the status says you're affected, which is just an ordinary security advisory, you're not affected, and that's valuable.
And then there's also, I patched it.
So there's a new version, or the last one is just under consideration, which is, I know about this, I'm working on it.
Give me a second.
This can be linked in the sbom file.
It can, it can be linked in the sboms file and it can also live independently.
And again, that gets back to the, what are you trying to use?
How are you doing it?
So if you have a local dev shop, right, you're making software internally, then, yeah, this is great.
Someone can say, okay, here's a vulnerability that's showing up from my basic.
I have an s bomb.
I've scanned my s bomb against a vulnerability database.
Oh, it lights up now I don't have, now policy forbids me from pushing this to production.
Damn it, we need to get this out.
Okay, let me look at this.
Oh, this vulnerability doesn't actually affect the product, right?
We've got inline controls or, you know, I'm really good at thinking about software and I can tell that the attacker can't actually touch this piece of code.
And in fact, all of these are automatic flags are in vex.
And now if I have a Vex, then my policy will let me push it, or alternatively I have an S bomb that ships with the product.
And now I as a vendor can publish a Vex that my customer can integrate into their vulnerability management system that says, okay, Sbom turns the dashboard light on.
Vex turns it off.
Right, okay.
And this takes me to the last point I have on my talking points here, which is attestation because it kind of a hot topic around s bombs and I guess highly relevant for VEX as well because if it's just a plain text without any cryptographic signature of any kind, any shape or form, it's obviously subject to exploit.
So maybe like bring the audience up to speed on what's the state of attestation and signed s bombs and how do you see that world shaping up?
I think the future of software security and supply chain security is going to be attestations where we have the ability to document every action in the process of software creation, software build, software deployed, and as we go we can document that and securely sign the action.
So we can show that I did the action securely, and then securely document that action was taken.
This is a very grand vision.
It'll be a while before we get this for all software, but I think that's where we should be headed is having these machine generated attestations and machine generated assertions that we can then link to very specific tools so that I can say listen, I trust that you're using Jenkins did this.
I trust that it was this version of Jenkins, I trust that Jenkins did this securely.
And so now we can move forward or I pulled this into my Monorepo and we can actually show this is the bits that were pulled in and then we can trace that to this is the bits that were used in the build and so on.
There are some projects out there that are doing this.
So in Toto is probably the open source project that's the most advanced, that's Linux Foundation, I think it's CNCF project.
A couple of years ago I looked at it and said this is cool, this is just research.
And now there are a number of organizations that are sort of helping instrument this and other companies that are instrumenting this and there are startups that are focusing on helping companies actually implement this and delivery.
And again, as we sort of orient, nothing we do in security today could be done without automation from the beginning.
And ideally we should start to add to that sentence, nothing should be done without automation and cryptographic validation and cryptographically supported documentation.
Yeah, just every time you see about this thing, attestation and the likes of all roads lead to PGP and it's just one of those things that it's a project that will never die and because it's just you forget about it for a few years but then you always like, you always run across it every once in a while so good.
This has been super fun, at least for me.
Alan, I kind of want to do a shout out for the conference you were organizing, or sliced or Guido, which is in the four.
Unfortunately, I would not be able to make it.
I wish I could make it in person, but unfortunately won't be able to do it.
Fortunately, it's going to be a hybrid event, but in person is always better.
If you want to meet 200 people who are all active in SBOM, come to Denver, September 11 and 12th, Denver, Colorado in the United States.
It's a two day event.
Day one is we're just going to talk about SBOM.
We'll hear from governments, we'll check in with sectors, we'll talk about new technologies.
It'll be vendor neutral.
Day two, we're going to flip it around.
We're going to have the first s bomb solution showcase.
Got two dozen s bomb vendors, including at least one group representing an open source project that will say, hey, here's all the different ways that we can address these challenges.
So if you're looking for S bomb solutions, you're simply not going to find a better place.
Free for everyone to attend.
Amazing.
Anything else you want to shout out about before we wrap up?
If you want to know, we have a weekly s bomb meetup meeting.
We cover a huge range of topics.
We've got announcements.
You hear about research, you hear about new technology advances, completely biz dev free that meets at 11:00 a.m.
uS east coast time, which is 05:00 p.m.
central european time, which I guess is 04:00 p.m.
london time these days, depending on daylight savings.
I believe it's 05:00 p.m.
my time.
Currently 05:00 p.m.
your time.
Great.
Thank you.
I'm american.
We're bad at other countries.
And then if you want to know more, Cisa dot gov sbom.
Cisa dot gov sbom for all your Sbom needs, we have a library with a huge amount of resources.
Papers published by the community, papers published by governments around the world.
Your one stop shop.
Feel free to reach out if you want to know more.
Amazing.
Thanks again, Alan, much having gone to show.
Amazing.
Thanks much.
Cheers.
Really appreciate it, Victor.
A lot of fun.
Found an error or typo? File PR against this file or the transcript.