Summary
The world of software bill of materials (SBOMs) is both complex and fascinating. And few people know the SBOM community better than Adolfo García Veytia — aka Puerco — Staff Software Engineer at Stacklok. Puerco is also a Technical Lead with Kubernetes SIG Release specializing in supply chain improvements to the software that drives the automation behind the release process.
He’s also one of the original authors of OpenVEX, an OpenSSF project working towards a minimal implementation of VEX that can be easily embedded and attested. Puerco is also a contributor to the SPDX project and a maintainer of several SBOM OSS tools. He’s passionate about writing software with friends, helping new contributors and amplifying the Latinx presence in the cloud-native community.
Conversation Highlights
- 01:04 – Puerco shares his background
- 02:21 – What SBOMs are and why they’re so important
- 06:42 – An overview of standards in the SBOM space
- 09:58 – Puerco details his work on VEX projects
- 14:05 – Puerco enters the rapid-fire portion of the interview
- 15:06 – Advice Puerco would offer aspiring open source or security professionals
- 16:12 – Puerco’s call to action for listeners
Episode Links
Transcript
Adolfo García Veytia soundbite (00:01)
So imagine if you were looking at the video and you see the cook not washing their hands when they cook. That would suck, right? We see a transparent supply chain kind of in the same spirit. The more information you have about your supper, you may be able to do better decisions on whether or not to consume it.
CRob (00:18)
Hello everyone, I’m CRob. I do security stuff on the internet and I’m also a community leader at the OpenSSF. And one of the cool things I get to do as part of the OpenSSF is I get to co-host What’s in the SOSS podcast. With us this week, we have my friend Adolfo, who goes by the handle Puerco out there on the internet. Puerco, bienvenido, al show.
Adolfo García Veytia (00:41)
Gracias, CRob. It’s super exciting to be in a podcast, but also in a podcast with one of my favorite people in the world. So thank you.
CRob (00:50)
I know, right? For those uninitiated in the audience, they might not be aware of the origin story of yourself. Could you maybe just explain a little bit of like what you do with open source and upstream and just kind of maybe some of the projects you’ve worked on?
Adolfo García Veytia (01:04)
Yeah, for sure. I’ve been working on open source projects probably over 10 years or so. I started contributing back in the era of Perl, writing, you know, filing bug reports and documentation for Perl modules. Then did some contributions for PHP. And then when I really started doing more contributions was when I joined the Kubernetes project.
I started up going up the ladder and I became one of the technical leads for Kubernetes Secret release where I specialized on the release process and working on the security features that we have in our releases. And then from then, I started creating lots of different tools that we needed to secure Kubernetes itself, which some of them became projects of their own. And now I’m working on some of the same stuff here in the OpenSSF.
CRob (01:59)
Nice, excellent. So I have a very important topic that you and I get to talk about all the time, but the audience might not be as familiar with. Let’s talk a little bit about software bills of materials, SBOM. Could you maybe describe why SBOMs are important for both developers and also downstream consumers?
Adolfo García Veytia (02:21)
Yeah, for sure. So SBOM, the software bill of materials, to give it a description of what it is in a short sentence, it’s just a list of components that make up your software. That’s the most basic definition of it. Some people may be familiar with SBOM or if not what it is with a term because of some legal requirements and regulation that has come up.
But the fact is that SBOM is kind of the base of the transparent supply chain. So if you’ve seen the news in the past couple of years, there’s a big push to make our software supply chain more secure. And that means can I do good decisions on the risk I’m taking when I’m ingesting third-party software? And to me and to some other SBOM enthusiasts, SBOM is kind of the base of that transparent supply chain. So the way we’re trying to make the supply chain more secure is combating it with information.
So whenever, imagine if you went to a restaurant and before you tried your dinner, imagine you could know exactly the ingredients that went to it, who cooked it. Imagine if you could see a video when they were cooking it. That would give you the ultimate assurance of your plate, right? Of your dinner plate. So imagine if you were looking at the video and you see the cook not washing their hands when they cook. That would suck, right? So we see a transparent supply chain kind of in the same spirit. So the more information you have about your software, you may be able to do better decisions on whether or not to consume it.
And this one is kind of the first layer of that transparent supply chain. As a developer, when you have an SBOM about your project, you kind of have a key to go to a lot of different services that are starting to come up to ask information about your dependencies. So for example, I think the most basic use case is you go to a security scanner and you present an SBOM and say, okay, scanner, give me all of the vulnerabilities that you know are present in this SBOM. And based on the information on your SBOM, the scanner replies back. So that’s kind of the basic use case I see for it.
CRob (04:38)
That’s pretty cool. And I’m correct in remembering there are different types of SBOM. SBOM isn’t just one monolithic thing. You might issue or create an SBOM at different points within the development process, right?
Adolfo García Veytia (04:5:0)
Yeah, exactly. So as the software lifecycle moves forward from idea to software repository or code base to builds and deployment, more information becomes available. And some of the information that goes into your SBOM may not be, it may not be possible to know it at the different stages of the software lifecycle.
So to give an example, if your project requires OpenSSL and it’s dynamically linked, you will not know the effective version until you deploy that binary and it links against your system binaries. So based on that idea that information becomes available as the software moves forward, different kinds of SBOMs have been developed. So there’s the design SBOM, which captures more or less the plan that you want to do.
There’s the source SBOM that looks that a generator looks at your code base, extracts the information that it can and gives it back to you. And then there’s a build SBOM where once you run the build, your compiler or interpreter may do the decision on which version of the dependencies it’s gonna pull down. And even the dependencies of the dependencies, because those may change as your dependencies get new releases. And that gets captured.
And then there’s the, I think the next one is analyzed where basically you take something like an SCA scanner and then point it at your artifact, make some deductions by looking at it from the outside. Gives you that, gives you another kind of SBOM. And finally, there’s the deploy SBOM, which looks at your software once it’s installed and running in a system.
CRob (06:32)
Wow. It’s a lot to keep track of. What types of tools or what are some of the standards that people might bump into in this SBOM space?
Adolfo García Veytia (06:42)
Yeah, so there are two main standards of SBOM. One is SPDX from the Linux Foundation, and the other one is CycloneDX, which is hosted on OWASP, currently undergoing standardization as well. Both standards are more than enough to capture that list of materials. Both standards share more or less the same abstractions when regarding that list of components. And both standards have also grown to capture much more than just a list of dependencies. They can capture things like build provenance and information about machine learning and AI workloads and others.
CRob (07:21 )
And I know that there’s a couple tools that you’re personally involved with. Can you talk about your project, Protobom, and then the bomctl?
Adolfo García Veytia (07:30)
Protobom was born out of a contract or yeah, I think the Radware’s contract from DHS and CISA. They put out like a call for to design a way to exchange information between those formats, and then the company I was working on back at the time, we looked at it and decided that it was a good opportunity to create one abstraction that can handle any SBOM data so that you could basically work with any kind of present or future SBOM formats and without having to care about the implementations. There are a bunch of reasons why. I could happily go, but probably it’s too boring for non-SBOM nerds like me.
CRob (08:19)
No, I think that’s really cool that such a thing exists. Pretty awesome.
Adolfo García Veytia (08:23)
If you think about SBOM tooling as a stack, at the very bottom you have the very strong foundations of both formats, CycloneDX and SPDX, but then Protobom is kind of the next layer in the stack. So that gives you like a universal IO layer to write and read between two formats in your application. That sits on top of Protobom.
And on top of Protobom, we’ve seen a number of tools starting to use it to interact with the formats, but also work with SBOM data. One of those is a bomctl. So full disclosure, I’m not yet part of the bomctl project. I work closely with them because it’s based on Protobom. And the idea of bomctl is that it will be a CLI tool to basically do the most basic operations that most people need to do with SBOMs. Things like updating data in your SBOMs, mixing them, changing formats, those basic operations that most people need to do when they get an SBOM, process an SBOM or share an SBOM are going to be handled by bomctl.
The aim is that bomctl, will provide that great user experience in the CLI, but also the idea is that Protobom will house the required functionality to perform those operations.
CRob (9:43)
So let’s talk about another SBOM-adjacent effort that you and I get to collaborate on together. VEX, the vulnerability exchange. Could you talk about what VEX is and how it kind of plugs into or complements an SBOM?
Adolfo García Veytia (9:58)
Yeah, for sure. So VEX, the way I see VEX helping the overall situation of the secure supply chain is that its main goal is to reduce noise. So part of the work that anybody trying to assess the risk in their supply chain involves triaging vulnerabilities. So when you have a super transparent supply chain as enabled by SBOM and other technologies, you start to get more information.
And with that information, you get things like false positives in scanners. And when your SBOM starts to capture things like your build environment or your build tooling and the dependencies in our container image, you start getting more and more components, which leads to more and more false positives. So to combat this, the idea of VEX came up in the SBOM circles organized by mainly CISA. So VEX, the Vulnerability Exploitability Exchange, is a way for software producers or I hate the word producers, but maybe software authors or maintainers to communicate the impact that vulnerabilities and their components have on their software.
So to give you an idea, if I share a container image and it has some old operating system package that I’m not using, it cannot be triggered in any way, that vulnerability may show up in my user scanners when they scan my container image, but they may not be affected. So VEX is a mean for me as a software publisher to create a small bit of information that gets communicated to my consumers, ideally to their scanners, so that those warnings can be, if not turned off, given more context so that they can make better decisions, and especially to help them triage those vulnerabilities more in a more efficient way.
CRob (12:00)
And when folks are issuing VEX statements, there’s a couple different types, a couple diffrent states that that statement can represent. And what are those?
Adolfo García Veytia (12:10)
Well we think about VEX as a one-shot message that turns off the lights in my security scanner, so to speak. But in reality, VEX is designed to be a communications channel to inform downstream consumers of the whole life cycle of the assessment of vulnerability in my project. So when a new vulnerability gets discovered or reported in one of my dependencies, VEX can give me different statuses that I can communicate to inform them about the evolution of the assessment. So you start by issuing a VEX statement that says that the vulnerability is under investigation, letting them know that you’re aware of it and they’re looking at it. So it’s not getting ignored.
Then the next one, once you have an assessment, you can send another message telling them you’re affected. So if it pops up in their scanner, it’s a true positive, but more importantly, you can send through the VEX channel some extra information about how to mitigate or other information. Or you can also let them know that it’s not affected and then you can inform them why not and that message can potentially turn off some lights or warnings in scanners and alerts. And the last one is fixed, right? So if I got a new release but that new release is showing up as vulnerable, you can send a fixed message.to let them know that this new release is not affected.
CRob (13:35)
It sounds like a really useful kind of emerging tool. I’m looking forward to watching this develop.
Adolfo García Veytia (13:42)
Yeah, I mean, we’re excited on how this is evolving and because it’s a really simple communications channel.
CRob (13:50)
Excellent. Well, let’s move on to the rapid-fire part of our questions. I’m gonna have a couple questions, and generally they’re binary, but if you want to add a little embellishment, please do. First question, spicy or mild food?
Adolfo García Veytia (14:05)
Oh, spicy, of course. I’m Mexican, what else?
CRob (14:12)
(Laughter) Well played, sir. Next question, VI or Emacs?
Adolfo García Veytia (14:18)
VI but not by choice, just by default on my distro.
CRob (14:23)
Do you have an alternative, better alternative?
Adolfo García Veytia (14:25)
Yes, I use JOE.
CRob (14:27)
I haven’t heard
of that one. I’ll have to look that up. Very nice. And our last question, very controversial out there in the ecosystem, tabs or spaces?
Adolfo García Veytia (14:37)
So my thinking is tabs, but I’ve been finding out that spaces plays better with others. So I like tabs because you get control of the indentation visually, but most everywhere it doesn’t work as expected. So I end up defaulting to spaces.
CRob (14:57)
Excellent, excellent. So now as we wind down, do you have any advice to someone? A young developer or someone getting into open source or cybersecurity that any advice for these newcomers to our field?
Adolfo García Veytia (15:06)
Oh yeah. So first of all, the two most important pieces of advice that I can give: one, do not be afraid to take on projects, to ask questions, most importantly, ask your questions. You’ll find that most open source nowadays is very friendly. And the other is show up. Most of those communities are built by people who recognize each other. Even just showing up, showing your face, hearing about the problems, giving simple or complex opinions, everything is super valid. Sometimes just listening to others rant is super valuable. And that’s how you find yourself super quickly on a track to become a maintainer of one of some of the most important projects out there. Yeah.
CRob (15:59)
That’s awesome. Thank you. That’s good advice for newbies. And final question here. Do you have some kind of call to action? Are you looking to inspire our listeners to maybe take up some causes or help out somewhere?
Adolfo García Veytia (16:12)
Yeah, for sure. So I probably could have some calls to action for both projects. So for Protobom, I think we’re looking for folks who maintain SBOM tools. So right now, the strongest implementation is in Go. So if you have an SBOM tool in Go and you want to or you’re planning to start a new SBOM project in Go, come talk to us or look at our repos in github.com slash Protobom.
We hope that you’ll find the project very compelling and helpful for your new project or existing project. So let us know if something is missing or whatever. Also, if you’re familiar with SBOM and in another language, we would like to see more implementations of Protobom in other languages. That’s one.
And for OpenVEX, help us bootstrap the ecosystem. So we’re trying to spread little VEX feeds wherever we can so that when you build artifacts, we can start recognizing those VEX feeds and trying to issue more accurate vulnerability scans. So if you want to help out, let us know and we can help you kick off your your VEX stream.
CRob (17:29)
Excellent. Well, thank you so much for joining us, Adolfo. I really appreciate your collaboration and your leadership in the upstream ecosystem. Thank you for joining What’s in the SOSS? today.
Adolfo García Veytia (17:39)
No, thank you for inviting me, CRob. I’m always happy to chat with you.
CRob (17:43)
Excellent.
Announcer (17:44)
Thank you for listening to What’s in the SOSS? An OpenSSF podcast. Be sure to subscribe to our series of conversations on Spotify, Apple, Amazon or wherever you get your podcasts. And to keep up to date on the Open Source Security Foundation community, join us online at OpenSSF.org/getinvolved. We’ll talk to you next time on What’s in the SOSS?