 All right. We're at time. So first, welcome and thank you for coming to this session. It's a I don't know, a very kind of exciting time for me because we're going to show Vex working, actually making use of Vex from end to end, which is exciting. The title of this session is Enabling Vex and Full Exxon Courage. I had to trim it a little bit because the proper title would also have included all of that because we're going to demo how you can do it the easy way and also another way which requires a little bit more of work but still works. So just before I start a little bit about me, my name is Adolfo Garcia or also Puerco everywhere on the internet. I am an open source engineer at Cengar, a software supply chain security company. I also do some open source work. I one of the technical leads with Kubernetes Secret Release. This year, I'm sitting on the Knative Cine committee. I also consider myself to be an SPDX contributor and I am a maintainer of probably too many S1 tools at this point. I also like to ride my bike around the world. You can see that picture of me in Mexico City forcing my kid to like what I like. So before we start, oh, I left the subtitles, sorry. So I want to start with a short story about cars and I'm sorry because I'm going to probably say all the wrong things about cars. I hate cars but they're useful for this. So around the year 2000, complaints like report started surfacing that tires were mysteriously blowing up. I'm probably some of you are familiar with the story. I know most young people perhaps not so much so. But after some investigation, it turned out that the reason for those tires blowing up were tracked. The tires were, the faults were severe enough that vehicles started flipping and actually killing people in those accidents. And after some investigations, they found out that the reason was a fault in the tires that were shipping in the 1990s model of the Ford Explorer. These tires were manufactured by Firestone and apparently they were the only ones having that flaw. And some more research was done and they started locating that those tires also shipped with some Bronco models and some whatever that Mazda thing is. And so this was severe enough that they issued massive recall of the tires, millions of tires started to be recalled. And in the middle of that, more news started surfacing that vulnerable tires may have been shipped in other models. So that gave way to somehow some panic because people started wondering if their cars could somehow have a tire blow up and flip. I had a Ford SUV at the time with Firestone tires so I know I was pretty worried. I also had that phone picture there. But then since news started surfacing that those tires may be in other models, people who had other 90s SUVs started wondering, like, oh, am I affected? So what about my Durango, I think that is? Or what about my beautiful Aztec? Or what about cars derived from other Ford vehicles like, for example, is my Ford NASCAR racer a little bit affected? Or my Ford monster truck limo, I don't know, cars. So jokes aside, the problem was severe enough that action needed to be taken, information needed to be sorted out to locate all of the affected tires. So in the end, around 270 people were killed in accidents related to the tires. And my sense, putting on my historian hat and going back into the archives, is that there was not such a good sense of which tire lots were affected. So during this talk, I'm going to be using the car as your software application and the tire as one of the components in your software application. For S-Bomb nuts and fans like me, which I see many here, this analogy should already be familiar. It's the software and its components. But yeah, let's start going into that. So the first thing we want to talk about is S-Bomb completeness. For people unfamiliar with S-Bomb, an S-Bomb is a manifest list of components of all of the dependencies that conform a piece of software. And more information can be added to it. I won't go into what an S-Bomb is because if you're here for Bex, probably you know what an S-Bomb is. So why is an S-Bomb and especially a complete S-Bomb important? When you consider a complex system like a car, you need to make sure that you keep track of all of its pieces. So whenever there's a flow in one of the parts, you need to take that S-Bomb, which is the same in applications, locate the component, and that can tell you if that component is contained in your application. Obviously, if the S-Bomb is missing parts, is missing information, or some of the components are not listed there, you are in a somewhat of a problem. Especially for example, if you don't have an S-Bomb, what can you do? Well, what do you do when you don't have questions about the safety of your car? You take it to the mechanic. And with the mechanic, it's kind of the same, and it needs information to do their job. You need to think about the mechanic as an entity, which may not be part of the production of the car that gives you some certainty about the safety of that vehicle. As I said, the mechanic needs information to do their job. One is the S-Bomb. The mechanic is going to have a much better time if they have the complete car S-Bomb to go look at the parts and make sure it's working. But what do you do when the information is missing there? Where if information is missing, the mechanic has to pull apart the car, look at every piece, and make sure that the car is working. And sometimes the methods of breaking things apart are not the best. So the mechanic has to figure out how to put it apart. So in software, I think that assessment is performed today by security vulnerability scanners. But the vulnerability scanners also need complete information. And when they bring the car apart, which is what we call software composition analysis, some software may be easier to compose or may give you more information than others. So they can also benefit from a complete S-Bomb. But not only that, there's another problem with a vulnerability scanner. And so to give you a quick dive into how vulnerability scanner works, it's just fancy database lookups. So here's how a vulnerability scanner works. When you have a piece of software and you run your security scanner through it, what it does is that it looks inside of the application, or in this case, if you have an S-Bomb, it can use the S-Bomb to locate the components living inside of that application. Here's Graip looking with its big eye. So it locates the list of components, and then it performs a database lookup in one or more security databases. And if it finds a match, it gives you back a report of the vulnerabilities that apply to your software project. Now, the problem with that is that sometimes that matching is not perfect. If you have the incomplete list, that's a problem. But there's also more challenges like actually matching the software identifiers, clashes between components that are named the same. Sometimes the information contained in the databases is not of very high quality or it's missing bits to actually do a correct matching and other problems. And this leads to lots of false positives in the information. And to show you one, I hope it's still true. I ran it a while ago. I'm going to scan. And this is scanning the latest Alpine image on... This is the Alpine image for Linux AMD 64. And when I scan it with Graip, it will find CVE-2023-4807 classified as high. Now, if it's a high vulnerability, it must be serious. But the thing here is, if we look at that vulnerability in the NVIDIA, that information only applies to Windows 64 platforms. Here you can see Red Hat knacking it in their own advisory because it doesn't apply to their products. So this leads to lots of noise. It leads to a miserable life for people who have to react to these vulnerabilities. And when we left the tire story, panic wasn't suing, but also a call for patience because during the tire chaos, people started asking, like, calling whatever had to do with tires, like car dealerships, tire vendors, and all of them just trying to find information about their vehicles. So here's where VEX can enter the picture and help. So how can VEX help in this situation? Whenever you're having that anxiety of not knowing if things are safe and especially being drawn in information that seems redundant that may not apply to you, VEX is like in our tire analogy, is like having VEX opens a new channel for more expertise to flow and give you more assessments on your vulnerabilities. So we already saw the analogy with the mechanic, but you can also get like a thumbs up from the car dealership. You can get it from an independent researcher or maybe the company is involved in the car or the tires themselves can also give you information that makes you feel better about the status and safety of your car. So VEX stands for the vulnerability, explorability exchange. There are many implementations of VEX and Open VEX is one of them and we're going to be focusing on Open VEX for this talk. VEX is a community project led by the CISA, well not led but facilitated by CISA, the Cyber Security Infrastructure Security Agency. We have a recurring VEX meeting every morning, which if you're interested in shaping the future of VEX you can join. And here's how VEX works. VEX is a system of documents that convey statements that inform about the impact that a vulnerability has on a piece of software. A VEX statement contains groups together, three main things. The first one a vulnerability. The second one is a product and that product can specify also one or more subcomponents. In this case the product would be the car, subcomponent, the tire. And finally a VEX status. And the VEX status can be one of three outcomes. You're affected and VEX can tell you if mitigations are available or how to apply them. You're not affected, in that case it can give you machine readable justifications of why it doesn't apply to your software and finally it can inform you if the software authors or whoever is looking at the vulnerabilities researching it. So it's under investigation. VEX statements also contain a timestamp because they form sequences as knowledge of the impact evolves. So here's how you use VEX documents in our car analogy. So supposing that you have a tire researcher, this is more of a value or something, but supposing someone is researching the impact on tires and finds that one of the tires has a flaw. So that person can issue a VEX document containing a statement about the tire as a product. And it lets it down the supply chain and then where the executives that car companies, for example, can pick up that statement and what we call in VEX transition it to become the subcomponent of the product. So the first person researches the tire, issues VEX about the tire, and the second one issues a new VEX statement with the tire transition as the subcomponent of the new document. And that new document can be picked up by interested parties like the mechanic or the car dealership and leading to happy drivers. Business clip art, I love it. So now, how do you generate VEX data? So to generate VEX data, you need to have the information that you want to encode in whatever VEX flavor you want to do. So the first option I'm going to show you is using Wulfi. So my company, Cengar, produces maintenance, open source Linux on distribution. It's on distribution because it's a Linux distribution optimized for containers, so it doesn't include a kernel. But we package all sorts of software. And the focus of Wulfi is high security, especially for supply chain applications. All of the Wulfi packages contain S-bombs describing them, which are generated at build time. So you have full coverage of each of the operating system packages. And the tooling to create images from Wulfi reads those S-bombs, composes them into a new S-bomb describing the image. So you have full coverage of all of the layers of the image, plus all of the information down to the file level with all of their hashes and all the information that you need. And the other important part about Wulfi is that Wulfi has its own advisory feed. So whenever there's any vulnerability, one of the Cengar engineers will go get paged, looked at it, and do an assessment, and patch the operating system package, often far quicker than any of the other distributions, or knack it if it doesn't apply to us. And based on that information, my team, I work at the Research and Development Area of Cengar, produced this tool called Vexi. And Vexi, which is a super clever composed name of Vex an image, what it does is that it takes the Wulfi S-bombs, it takes the feed from the Wulfi advisories and produces Vex out of it. So I can give you a quick, I can show you a quick demo of Vexi. It's not, I mean, it's not very impressive because when I hit the button, it's going to do things really quick. But what it does is it clones all of the advisory data from Wulfi, and then generates the Vex. So clones the advisory data from Wulfi, fetches the S-bombs from the image, which in this case I generated an S-bombs, I generated Vex for the Node.js image, and then composes Vex information for that image. So as you can see here, here are the components of the statement, the CVE, the timestamp when it was generated, the product, which in this case is the Node.js image, and the components for which the Vex statement applies. In this case, it's a Wulfi JLVC package. And the status here is not affected. In this statement, the engineer, whoever wrote this, didn't include a human readable justification. Sometimes the packages have them and you would see them here in the Wulfi case. So this is, I mean, I think it's pretty cool, because you are taking advantage of the S-bombs to generate Vex, of the advisory data to generate Vex. In effect, for your daily applications, it means that you have your Wulfi car is serviced by the full team of change-order engineers, which is cool, but may not be the case, who for some reason or another, you cannot use Wulfi. And it's, I mean, you should, because it's pretty cool, but perhaps it doesn't, you can't for whatever reason. So what's the alternative for people who don't have Wulfi in their systems or are using other types of software? Okay, so we, let's compare it. So we had the Wulfi car and let's try to look at another car. I tried to pick another cool car. I don't know if it's cool, but I didn't want to like pick a cool one and I don't know if we want it. So let's compare them both. With Wulfi, you get the S-bombs right away from a generation. And when you build an image for Wulfi, it's there. That means that using the advisory feed, you can also get Vex for free. Now, on the regular car, you need an S-bombs and you can generate it. If you don't have it, you can use BOM, the tool that we maintain for generation, S-bombs generation in Kubernetes. Or if you're not, don't want to be as cool, you can use something like SIFT. And that should give you a good enough S-bombs describing your image or any other piece of software. It doesn't have to be container. I use container images a lot because I'm involved with Kubernetes, but it applies to any piece of software really. So once you have the S-bombs, let's move the Wulfi car away. Presentation chops. So when you have your regular piece of software, the first thing that you need is to have open Vex data about the components. And this is where we're trying to work with all sorts of communities and projects so that they can start generating their own Vex data. And right now, the uses that we've seen are companies internally trying to Vex. And then, so one of the security teams inside of companies will generate Vex data for their own components and then using those they can do Vex today. But our hope is that in the near future, especially since our tooling has reached a good level of maturity, other projects will start publishing Vex. So if you're maintaining an open source project and you don't want to get bugged constantly about false positives and things that don't apply to you, Vex could be a good solution. So once you generate the S-bombs for your application, you're done because using the S-bombs, you can look up the components, check out the available Vex data and generate an S-bombs that the security scanners can give you the thumbs up. So how do you do that? And the answer for that is the open Vex tooling. So let me show you. So the first thing that we need, remembering the vulnerable image that we have here, we need to Vex this to CVE. Well, it's just a CVE but in found in two components. So what you need is, first we need the S-bombs for that image. So I'm going to generate the S-bombs for that image and I'm going to pipe it through the visualizer so that you can see the results. So this generates, let me show you first this. So if I generate the S-bombs, I'm going to get the raw S-bdx for that image. It has information about the packages and everything and by visualizing it we can understand better how it looks like. So at the top we have the image and then one layer and all of the operating system components. These are all Alpine packages and our vulnerability is found in these two here. So let's suppose that OpenSSL decided, oh, we need to start vexing, which if they were doing it, we could be using those files instead of generating them ourselves. So hopefully soon. So let me show you what they look like. For example, this is one of them. So here's the file, the document of vex.vcv in LiveSSL. So it's again the vulnerability, the name of the vulnerability, the timestamp, the product ID, which is a PURL that defining that package and I'm specifying here the architecture and then the status which is not affected and then I added a human readable note which vex processors may choose or not to surface to the users. They can just opt to do the operation fully automatically. And here's the machine readable justification. Vulnerable code node in execute path, which I don't know if it's the best fitting one, but it's one of them that could apply. So I have that document and now what? Well, now I need to build, if you think about this, this is the vex document for the component, for the tire of the car, but I want to build the vex document for the car itself. So how do I do that? And the way you do it is you use vexctl, which is the main tool from the OpenVex project. This doesn't blow up. This is like 21st century S1 technology, so it's not even merged yet, but this is the way it works. So the way it works, this sub-command reads an S1, analyzes all of the components it finds, and then it will give me, I can pass it more OpenVex documents, where you will look for information about them, our hope is to at some point out though discover all of this, and then it should give me a new document describing not the tire, but the car, which is my container image. So I run it and it's here. So if you see the new document, I mean, all of these fields are not, I didn't define them so they're empty, but you can pass your name and all those fields, value for those fields. So here's a vulnerability, the timestamp when I generated the document, and here is the new product. I'm using the PURL, the packet URL for the Alpine image that I was just showing you. And OpenVex has more fields to do the matching on the software that you're doing, so it's, here's a packet URL, which I'm using as an ID because it can fit as an RI, and then it can also match on the hashes and other identifiers. And here's the sub-component, here's the tire, so the image is the car, and the tire is here. Not affected, and here's the transitioned human readable message and the justification. Now, if you have that document, your question is, well, what good does it, what purpose does it have? How do I use it? And the way you use it is when you scan the image, you get this false positive here. And what you do with the Vex document is that you feed it into one scanner that is Vex-enabled, and as of last week, we merged OpenVex support into GRIP, so you just pass it the documents. Here it is. So this is a new flag in the latest release of GRIP. You pass it the Vex, the Vex flag with the document that I just generated, and when I run it, it says no vulnerability is found. But if you look closely, you'll see that the vulnerabilities are still there, but they just have been ignored because I'm choosing to trust those Vex documents and they in GRIP is still finding them but not showing them to me. So if I run GRIP with the show suppressed flag, it will show me what Vex did. So you see here that those vulnerabilities are still there, but Vex chose to suppress them. So this is Vex end-to-end from generation all the way to the scanner. And so our hope is that the new channel of information that Vex is going to open is going to enable this sort of thing fully automatic. There's still some work that we need to do, especially around the areas of auto discovery and trust, but things are moving really, really fast. There are many interested parties, so we hope to see some progress really, really soon. So thank you. And I wanted to just open the invitation, open invite for anybody that wants to participate in this open source project. Open Vex is a project that's incubating in the OpenSSF. We have bi-weekly meetings. That's a repo or join us on the OpenSSF, see OpenVex channel on the OpenSSF Slack. That's the Wolfie main repository and the tooling, which you can use to generate the images, and that's Mac and the Tata. So yeah, that's it. And I think we have time for questions if anybody has some. So my question is pretty basic. So let's say internally in my org, someone found a vulnerability and it's a proprietary tool, so we don't want to expose it. So we generated a CV kind of internally and then we also created a Vex for it. So how can I notify my entire org? So let's say we have an SBOM in, you know, a process is there, every product has an SBOM. How can I notify all of them about this vulnerability along with the Vex to check whether their product is vulnerable or not? Well, so if you're producing SBOMs, the best way is add the Vex file as an external reference on the SBOM. That's the key. And then you solve all, I mean, we want to make sure that Vex is sort of discoverable, but nothing beats the component itself pointing to the Vex file. And so that's the one. And what was the other part of the question? The part is like, is there a way I can publish this Vex information? So every product can, you know, from their SBOM just go through it and make sure it's not vulnerable. Yeah, so that's the discoverability part. So right now, our tooling supports automatically fetching the Vex data from images that are attached to the image, like six-store style in signing them as well. Another feature being built is finding open Vex at a well-known location in GitHub repositories. That's another one. But I think so far, that's the only ones I think are fine, unless you feed them manually like that. But using the SBOM, that's the best way because if you distribute the SBOM and you have already a way of distributing it, the SBOM can point to the open Vex document. Good. Thank you. So in one of your slides, you were using the Vex CTL that was reading an SBOM. What was the output of that? Was it another SBOM or...? So it was in the demo, right? Yeah, in the demo. This one? Yeah, that one. This? Yeah. So is that the enriched SBOM or...? So yeah, the flow is you call Vex CTL. And what Vex CTL does is it reads the SBOM. So the SBOM in this case is the standard SPDX SBOM. And then it uses the list of components from the SBOM and the information contained in the Vex from the components does the crossing and gives you back this document, which is an open Vex document. So this is pure Vex information and nothing else.