 My name is Justin Murphy, and I first just want to welcome everybody. I really appreciate you attending the session, and thank you for having me. It's an honor to be here today to speak. Just to give you just a little bit of a background of myself, I'm a former high school mathematics teacher who decided I was interested in software engineering, but it didn't necessarily happen that way. I ended up being a cyber security professional who works for the United States government. And so I work for the Cyber Security and Infrastructure Security Agency, or better known as CISA. Yes, the news app, is that what you said? Oh, the music is still playing. Could we kill that, please? Okay, yay. So quick intro, Justin Murphy worked for CISA, right? Cyber Security Infrastructure Security Agency. If you don't know anything about CISA, we are the operational lead for the U.S. federal government for cyber security. And we are responsible for understanding, managing, and reducing the nation's risk for our both cyber and physical infrastructure. To kind of tell you a little bit about the corner of CISA I work in, I work in the vulnerability management, specifically the vulnerability management disclosure branch. So a good way to describe what we do, as you can see my title is vulnerability analyst. What we do is basically from the time that someone writes not so good code to the time that there's a national level response and everything that happens in between that our branch handles that for the U.S. government. And so some of the other work that we do is related to software assurance. And I have the pleasure of working with Dr. Alan Friedman. I'm guessing you possibly might be familiar with Alan. You might be wondering what is somebody other than Alan from the U.S. government speaking about SBOM? What is he doing? Sometimes I wonder that same thing. Alan always refers to himself the guy who doesn't shut up about SBOM. I would like to say that I am the other guy who doesn't shut up about SBOM. I'm much more of an introvert than Alan. I wouldn't really describe myself as somebody who has trouble shutting up about anything. But I really care a lot about it. I think it's important and I'm excited to be here to talk to you about it. So let's get started. I know that I am almost, I think there's one presentation after me that is between you and lunch. But I know we're getting there. People are getting hungry. You've been here all morning. I really appreciate the attendance here. There's a lot of people here. That's great. But will this be worth your time? I hope the answer is yes. We're going to kind of walk through vulnerabilities. As I said, I work for the vulnerability management disclosure branch. So just kind of talk about how do we deal with known vulnerabilities? And as this vulnerability landscape evolves, how do we think about that? We're going to talk about SBOM. Who here is not familiar with SBOM? Great. That's actually the first time that's ever happened. So that's kind of exciting. But I won't get too remedial. But we're going to talk about SBOM as just really a model of transparency. We're off to a good start. We're going to talk about VEX. Who here is not familiar with VEX? Oh, okay. Cool. Great. And we'll talk about some of the opportunities and challenges and ongoing work we have going on at CISA. And we hopefully will have some of you, if you're not already involved, get involved with some of that work. Because it is led by industry and led by community. And a lot of cases, we're just facilitators of that. And we need your help, especially in the open source domain. And then we'll talk a little bit about maybe somewhat of a controversial topic as the challenge of software identity. We're going to talk about the naming issue. We're going to talk why is it so challenging from our perspective and how we might think about some potential solutions related to that. So let's talk first about vulnerabilities. You would think or you would hope in an ideal world that dealing with known vulnerabilities would be obvious and easy and straightforward, right? Is that everybody's experience? No, right? For some reason, and there's probably a lot of people who would offer opinions of why that is, and they might all be correct, that dealing with known vulnerabilities, even though it should be an easy, straightforward, obvious side of security, it really what we have had in our experience and what we've heard from people in the open source domain and in the commercial domain as well, is it's really difficult to manage all of this. And so even though that is the case, I think it's also good to talk about some of the positives. Now we have seen why would vulnerabilities be difficult to deal with? It's a scale problem is one of the issues. We've seen that as the years have gone on, we've seen an increase in vulnerabilities, which means we've seen an increase in risk. But there have been good outcomes from that. We see an increase in the amount of security advisories. We see an increase in the amount of S-bombs. And that's good. However, and something that we often say, is that a lot of times cybersecurity problems become data management problems. So with the increase in vulnerabilities, we also have the increase in managing all of this data. What do we do with it? Some of the positives that have come out of that, and this is maybe a little bit of a pat on the back for the agency at work, who is familiar with Kev, the known exploited vulnerability catalog? Oh, wow. Okay, great. So in the fall of 2021, late fall of 2021, CISA released what was called Binding Operational Directive 22-01 or BOD 22-01. And what that said is that all federal civilian agencies were required to remediate any known vulnerabilities that are found in the known exploited vulnerability catalog, or as we affectionately refer to it as the Kev. And so this was great. And it's great that the federal agencies are required to do that. It's also heavily, heavily recommended, and we've gotten a lot of great feedback from industry. It's heavily recommended that all organizations remediate vulnerabilities that are found in the Kev. And we're hearing lots of good things. We're getting lots of great feedback, and we're excited that we have that now in this vulnerability landscape to help. And it's really, I think, making a difference. But why are known vulnerabilities so hard? And how do we think about this from a vulnerability management perspective? How do you think about this? And so the things that you're asking are going to be which of my projects are at risk? And these are projects that you build? Maybe also projects that you're using to build? Maybe these are projects or products that are just found on your network. We need to know which of my projects and where on, in my software, where on my network can I find these vulnerabilities? And if that is the case, what are the mitigation measures that are necessary? What do I need to do about it? That's what, those are the main questions. Am I at risk? Am I affected? What do I need to do about it? And there's a lot of different ways we can find out that information. This is not an all-encompassing list. We have security advisories, and those come in a lot of different shapes and forms. We have security advisories that are posted on websites. But then there's also the customer portal model. Maybe it sends you directly if you're a customer, or maybe there's some portal that you have to go and retrieve that information. You can ask the maintainers or in the commercial space, you call the support line. You know that they're waiting by the phone right now, waiting to hear from you. And they want to hear from you, they want to help you. They miss you so much when you don't call. And there's other ways. We're of course going to talk about SBOM. Your own investigation is one way. SBOM is what we're going to be mainly focusing on moving forward. But let's talk about just some of the challenges that come with these. Security advisories. We talked about the increase in vulnerabilities, increase in risk, increase in security advisories. The problem with the scale of that is also they come in different way shapes and forms. It makes it really difficult when we're talking about automation, when you have a lot of different data formats. You also have situations where maybe the vendor hasn't issued one, or if they have issued one, it doesn't even contain the information that you need. We're not even talking about issues of machine readability. We're talking about issues of human readability in some cases. When you have to ask the maintainers or call a support line, what kind of response are you going to get? Are you going to get a response at all? You've probably had experiences where this has gone well. You've probably had horror stories. And sometimes you might just get some form of like a support ticket in the commercial space and open source. Maybe you would just get, yeah, we're looking into it, but not much detail. Your own investigation. That can be difficult. It's going to be resource intensive. It's going to be expensive. It's going to be time consuming. Sometimes you don't know where to start. And I'm not really able, as the hub of SBOM, Alan forbids me from saying anything negative about SBOM. So I'm just going to skip this. I'm just kidding. There are challenges with SBOM, and we recognize that. First is, can you get it? Do you have it? Do you have the SBOM? Does it have enough information if you do have it? Are you able to retrieve it? Once you have it, do you have the tools? Do you have the capabilities to turn that into something meaningful that helps you understand, hey, this is where I'm affected? What do I need to do about it? We recognize, and this has been something that, if you're familiar with some of the NTIA work that Alan did when he was with the NTIA, before he came over to CISA, is this is sort of a myth, is that people might think that SBOM is going to be the cure-all. We recognize that that's not the case. The SB and SBOM does not stand for silver bullet, is what we say. Really, all the SBOM is, is a model for transparency. Transparency is something we're going to build on. If you've ever seen a presentation with Alan, you've probably seen a slide that's similar to this. If you've seen him in person, he has Twinkies behind him. I don't have any Twinkies, I'm sorry. I'd love to throw them in the crowd. This is a good example of transparency and how it can be helpful. We're going to be talking not only about transparency from the SBOM perspective, but also from the naming. CVE is a really good example of that, that we experience in our space, where we're working with the CVE, we're working with MITRE every single day at CVE, with the known vulnerabilities, and the KEV, all of those are CVEs. One thing that when we're talking about how transparency is really, really helpful, and it's very obvious, is if you go to, let's say a grocery store, and you're concerned, maybe you're on a diet. Maybe you have food allergies, maybe your kid has food allergies. You want to be able, and you expect to be able to, go in there, look at the food you're going to consume, and try to identify, is there anything in here that I don't want to consume? Conversely, you can even say, is there something in here that I want to consume? But that model of transparency is something that is extremely, extremely valuable. We expect it when we go into a grocery store. Why don't we expect this from our software? And that's really the question that is important to ask when we're talking about the value of SBOM. Once again, it's not a silver bullet. And I think it's also really important to recognize that transparency in itself doesn't actually fix anything, right? Even though you can go into the grocery store and you can see this ingredient is in here, I don't want to buy it, you still have to not buy it, right? You still have to make that decision to do or not do something about it. And so transparency in itself isn't necessarily going to do anything. A CBE ID doesn't actually do anything unless you can identify if that is in your software and if you have to do something about it, right? And so that is, you know, SBOM is that model that's going to provide the community with transparency and be a common data layer that we can build off of. And so we're going to talk a little bit about something we're all familiar with here. One of the most important things that comes with this model of transparency is knowing what's in your software, right? This is step zero in vulnerability management, not even step one. Step zero. But a lot of people struggle with it. And it's because it's challenging. We're all building complicated projects for ourselves, for others. We're inventing really, really, really innovative, really, really cool and great things that are helping not only ourselves but the broader industry and making the world a better place. And I hope that all of you can say that you feel that you're doing that. But we have this problem of do we actually know what is in our software? I think we all remember last December. Anybody? Yeah, log4j, right? If you don't remember December 2021, the Apache's log4j software library, there was a vulnerability found in there. Many people all of a sudden needed to figure out and figure out quickly where log4j was in their project, if it was in their project and where it was in their project or product. And it turned out that that was not so easy because it could be in a whole bunch of different places. When you're talking about dependencies, when you're talking about not only were you looking for log4j, you were looking for other things that had log4j somewhere in it, right? And then there was also the converse of you're looking for where log4j is because you think you might be vulnerable. Well, what if you weren't vulnerable, even if you had log4j? And we're going to talk a little bit about that because that's an important piece too. Sbom is really, really helpful in identifying where you're potentially affected. That word potential is important. It's going to tell you where you might be potentially vulnerable. But what if you're not? There's ways that even if you have something vulnerable in your code in your project, do you actually have to do something about it? And that's what we're going to start talking about. I'm going to tease a little bit is Vex. And that's something I saw a lot of hands go up that we're maybe not so familiar with that. So we'll talk about that. I apologize for doing this. I'll go through it quickly because I think everybody's familiar with Sbom. But just a refresher in case somebody else has walked in. All the Sbom really is a dependency graph. So this is maybe a slide you've seen before. If you've seen one of Allen's presentations. You have ACME application. It has two direct dependencies. Bingo buffer, Bob's browser. And then Bob's browser also has a dependency. It's dependent upon Carroll's compression engine. And when we look at these different components, we may want to... We may think that we need to know a lot of information, but really, we don't need to know too much. We need to know who makes the product, what's the name of the product, the version is going to be helpful. Some identifiers, are there some unique identifiers that are going to help us when we're talking about and we need to maybe find these in a vulnerability database or something like that to know if we're affected? And that's really... And where did it come from? Where did it come from? Did it come from the... For an open source project, did it come from the maintainer? Did the SBOM come from the maintainer? Did it come from a security company, the security advisory? How did you get that information? And so, we also need it to be machine readable. That's also an important aspect of SBOMs. One thing we want to remember is that SBOMs, we talked a little about some of the challenges and that really only helps us identify where we're potentially affected. But it is helpful because the thing is, even though it tells us where we're potentially affected, just like that, those food ingredients, we go in and we see, hey, I don't want to eat this because that's in it. You still have to make that decision of not to buy it, right? SBOM, if you are a producer of software in the open source community and maybe you want to make an attestation that, hey, we did this, we made this project using a secure software development practice. Good luck doing that without providing an SBOM and telling people what's in your software. So SBOM is going to be really helpful there. If you're somewhere in the middle of the supply chain, maybe you're selecting software, you're purchasing software, whatever it might be. You're somewhere in the middle. You need some visibility. You need some transparency into that supply chain so you can understand your risk management. And then if we're at the end of the chain to it, I told you I work for the vulnerability management branch. When we're talking about vulnerability management, software that's already out there, production code, already been released, we need to understand the emergent risks. Maybe it wasn't vulnerable or maybe it was vulnerable. It just hadn't been found yet. How do we handle that? What do we do with that? SBOM is going to help us with all of that. Depth is also an important consideration. Anybody familiar with the Minimum Elements document? Part of Executive Order 14338? Got a couple of hands. We'll talk about a little bit more of the Executive Order here shortly. So part of the Executive Order was Allen when he was at NTIA, drafted what was the Minimum Elements document of an SBOM. And all of that says is that you need to be able to provide your top level dependencies at minimum. When we really think about that, it's a good start, but we'd like to go further in that. So you need to also have the ability to recurse. You need to recurse down the dependency tree. When we're talking about getting to the level of open source, that's maybe when it gets a little bit complicated. So depth matters. We saw that in December. Once again, log4j. It was really, really difficult to find where log4j was in a software project. I know someone who works for a very large banking company, and they're still dealing with log4j. I would say that there's probably some people in the crowd out there still dealing with log4j. I know it's coming up for all of us, because it is. It's really, really difficult to find where it is in our software. There's also the part, too, that we keep finding it in our software, but we're not affected by it. And that's a frustrating aspect of it, too, dealing with that. So we'll talk a little bit about the executive order. When Alan worked at the NTIA, some of the people who were involved in that early work were members of product security teams at really well-known security companies. And one of them said to him one time, we like this idea. It's really good. We like this idea of SBOM. We'll do it when someone makes us. I think that's a pretty common sentiment. Well, the White House helped us out. They decided they wanted to move a little bit faster. This is executive order 14-0-8, which was released last summer, early fall, improving our nation's cybersecurity. I'd like to point out that first bullet point. I try not to have too much text in my slides, but every once in a while it's important. The trust we place in our digital infrastructure should be proportional to how trustworthy and transparent that infrastructure is. And so that line right there is really foundational, really important when we're talking about the emphasis of SBOM and why it's going to be a core part of our understanding of what we invest in moving forward. And so some of the work that's already happened is the NTIA mentioned the minimum elements document. So the minimum elements document was released in July of 2021. And then you had the NIST. If you're not familiar with NIST, it's the National Institute of Standards and Technology. They have a special project, I believe it's dash 218, which is the secure software development framework. They have folded SBOM into that, suggesting that that is part of a secured software development practice. And we're expecting to see hopefully any day fingers crossed some guidance from the Office of Management and Budget, OMB, that is going to highlight for us some acquisition rules. And we expect it to end up in the FAR, which is the Federal Acquisition Regulation. That's U.S. government. If you don't work for the U.S. government, it may be new information. If you do it, it probably sounds very familiar. I think all governments probably work in acronyms, and we are no stranger to that. But all that SBOM really is, you saw my first slide, it's that model of transparency, and it is really, really helping us, and it's a really, really good start, but there's more work that we need to do. We know about more potential vulnerabilities with SBOM, right? How do we actually answer the question, whether it's affected or not? And that's when we start talking about this question of vulnerable versus exploitable. Exploitable is kind of a word that... I wouldn't necessarily say controversial, but I think it could mean a lot of different things to a lot of different people. A word that we like to use instead in the context of VEX is we use the word affected, and then the converse of that is not affected. And really what VEX is, and VEX stands for the Vulnerability Exploitability Exchange. Alan does not like this name. He often says that it's the worst name security project in Infosec, but he also makes the joke that there's nothing more permanent than it was supposed to be a temporary name, and he says there's nothing more permanent in government than a temporary name. And so we are stuck with VEX. It is a very, very popular topic these days. We have ongoing work around it, and I'll talk a little bit more about that and how you might get involved. We'd love to have your help. What VEX is, is we like to think of it as a negative security advisory. Not all vulnerabilities are going to be exploitable. And there's a lot of different reasons that might be the case. Let's say that you have a third-party dependency, and it says that the code is vulnerable, but because maybe the compiler rips it out or something like that, you're not actually affected by it, right? So in this case, SBOM is actually producing a false positive. There's a lot of different reasons. Let's say it's a library that has vulnerable functions in it, but you're not using those vulnerable functions, or even let's say it's input validation, but you build your own protections around that unsafe input validation to where you're not affected by it. That's one of the gaps that we have with SBOM, is it's going to tell you you're affected by this vulnerability. VEX is going to come in and tell you, do you actually need to do something about it? Are you actually affected by it? And so the metaphor that we often use is that SBOM turns on all the flashing lights on the dashboard for you, and VEX is going to help you figure out which ones can you turn off. Which ones do I not have to devote time and resources to actually figure out? And so VEX can be implemented in the OASIS-CSAP standard. This is a international standards body. We have on sysa.gov slash SBOM, which is our SBOM website. We have some documents that have been put out in the past four or five months around use cases around VEX, and we have one on status justifications for VEX. Status justifications have to do with you can either be not affected, can be affected. It can also be under investigation, which is a very, very valuable thing to be able to communicate like that to your downstream customers that says, hey, we're trying to figure it out. We know that this vulnerability is a thing. We're trying to figure out if we're affected or not. As soon as you find out not affected or affected, VEX is designed to be machine readable and built for automation as well. And CSAP is something that is built for that. We also want to recognize our friends at Cyclone DX. The two SBOM formats, I'm guessing you're probably familiar, Cyclone DX and SPDX. We love both our children equally is what Alan often says. We love the work that is happening there. We know that a lot of organizations adopt both of SBOM formats. And we love that. Our emphasis at CISA is around interoperability, making sure those things work together. And with VEX, we have CSAP and Cyclone DX. Cyclone DX can implement VEX. Once again, our standpoint at CISA is we emphasize interoperability. We want that to be, we want to make sure whatever you want to use, whatever works best for you, that's your decision. But we want to make sure that we're always striving for that interoperability to help the greater industry, greater community. Oasis CSAP makes sense for us. This is also, this is just a slide that VEX was also called out in the minimum element. The reason that CSAP works for us is because, mainly because of the broader context of security advisories. We're in the vulnerability management disclosure branch. So we're working with that all the time. So it just makes more sense for us that CSAP, it's a machine-readable data format for security advisories. Our friends at the German government have been very vocal in their support and very active in the development of this standard. We are joining in on that effort as well. I'll give a little bit of a tease that you will be seeing in the coming months. Some information that's coming out from CISA about our support for CSAP. And really CSAP is built with that notion of machine-readability and automated ability to where you are making that evaluation process and what you're going to prioritize instant. You're making it automatable, which would be huge from a vulnerability management standpoint. I mentioned it comes out of the Oasis Open Standard. We are involved in the technical committee for that and look out for more information coming from CISA in the coming months regarding CSAP. So one thing that we want to recognize with SBOM, also with VEX, is that there are gaps. We talked a little bit about that already, but we'll talk a little bit more about it. There's more work to be done. Was anybody able to attend back in December the CISA SBOM or AMA? A couple hands. Great. Guess what? If you want to watch it, you can't attend it, but you can still watch it. It's on cisa.gov.slice.sbom. If you want to watch the two-day event that we had surrounding SBOM and we called it the SBOM Marama. The first day was sort of a bringing up to speed, also sort of a review of and sort of a tying of the bow on the work that was done at the NTIA as an official transition from NTIA to CISA, as CISA is now the hub for SBOM. That first day of the SBOM Marama was devoted to just kind of, this is the work that we've done, this is what we want to do next. And that's what day two was. It was a brainstorming session where the community led that effort of what's going to be next. And we need voices from the open source domain still. We needed it back then, but we still need it now too. You can watch both days from the SBOM Marama. I'm going to talk about now some of the work that we have ongoing. We have active working groups that we just launched around these four, so sharing and exchanging SBOMs, tooling and implementation, cloud and online applications and then on-ramps and adoptions are four new working groups. These came out of the SBOM Marama. We heard from the community and we listened and they said, these are the things that we need to work on next. We've done a lot of great work up to this point, but we need to figure out how do we move this data around for both SBOMs and DAX? How do we move this data around? How do we share it? Is a push-first-pull model better? Centralization is federation necessary? These are questions that we need to answer and we need your help. We need your input. Tooling and implementation. Tooling is still emerging. There's a lot of great generation tools for SBOMs, but we still need a lot of work on the consumption side. Great work is being done, but we still need help there and we need progress there. And once again, we're always pushing towards interoperability. I brought up the two SBOM data formats, SPDX and Cyclone DX. We're always pushing and striving towards interoperability. Cloud is one of the groups that a lot of people are excited about because really all of the work around SBOM so far has been focused on on-prem. And that makes sense. You need to know that it was a natural starting point. And what we are hoping to do now is bring people in from the cloud-native community for help, but also taking our knowledge around on-prem software and seeing how can we adapt what we have learned and what works well and how can we apply that to the cloud domain. So that's a really exciting green field right there that once again we need a lot of help in and we welcome that. At the end of this presentation, we'll share that information of how you can get involved. It's open to all, it's open to all, which we want to emphasize. And then also just as important, we're making progress in SBOM and we want to keep making progress, but we don't want to forget about less mature and small organizations who need to figure out inexpensive and cheap inexpensive ways to get involved with SBOM. How can we help them do that? So that's where on-rants and adoption comes in. But it's not only for the new companies and the under-resourced companies and things like that. The on-rants and adoption group can potentially be one that sort of is a broads involved in all the different efforts around SBOM. How do we evangelize SBOM? How do we get more people involved? How do we get more people using it? Also VEX, right? Some of the other considerations that we're taking into account with these working groups and just our general efforts, we're always pushing towards automation. We believe that everybody can be producing SBOMs right now. But what we don't expect yet is maturity, automation just yet. We know that there's organizations out there doing it and that's great, but we don't expect that across the globe. And then we have this idea of we're going to probably need to link the SBOM and VEX data, right? SBOM and VEX are separate. They're independent. They're parallel. They're complementary. But they are independent. And so I'm running out of time, so I'm going to move on. But that's when we're going to start talking about software identifiers. That's in the naming problem, right? We have SBOMs. We have SBOM components. But when we start getting into unique identifiers and linking those documents, that's where we get into a real problem. You may be familiar with this quote. There are only two hard things in computer science, cache and validation and naming things. It's attributed to Phil Carlton. Really, this is just a statement on the fact that there's really no universal way, really universal agreed upon way that we can name different software components. And because of that, we might have, depending on when I guess you implemented SBOM, you might have com.sun.java, or you might have com.oracle.java. Are those the same thing? Yeah? Probably. Do we know? And that's the problem is things, when we need to link them up, things are named differently and they could be referring to the same thing, or conversely, they may be actually two different components but are named the same thing, so they're actually not referring to the same thing. And why does this matter? If that isn't obvious to you, when you're talking about identifying vulnerabilities, like let's say a vulnerability database, and you need to know, am I vulnerable? Well, if your identifier doesn't match up with what it's named in that vulnerability database, because it's often listed by names and version numbers, well, you're going to think you're not affected in a situation where maybe you are affected. So that's one simple example right there of why this matters. There's that problem that I just mentioned of the component identity. There's a situation where you could have two different S-bomb authors that are going to have two different identifiers for the same component, right? I gave that Java example. A converse problem, that can also occur where two authors have the same identifier, but they're for different components, right? Maybe in an open source domain that comes from a package manager or a registry, right? Got it? A package manager or a registry. Conversely, in different package managers or registries, the same name and version string might not refer to the exact same product. And so that name of proprietary products as well is going to... When we talk about proprietary products, we get that confused as well. And so we have obstacles with the software identity problem, with that challenge of software identity. The main problem is that we don't really get the full potential of S-bomb. The primary impact is that it's probably currently impossible to reliably automate this process. The lack of clarity around component identity also, it makes it difficult for S-bomb to be mapped to vulnerabilities, to licenses, and other relevant data that we might need to know. There's a lot of choices. Why is that the case? Well, suppliers of the software components, they really define names a lot of times according to their own needs, which makes sense. Why wouldn't they do that? And so we have a lot of different examples out there. We have CPE, we have common platform enumeration, you may be familiar with this. It is linked up with the National Vulnerability Database, or the NVD. I'm not going to talk about some of the challenges that come with CPE or the NVD, A, because I'm running out of time, some information about CPE, it enables identification of specific applications with or without version numbers, but does not by itself identify subcomponents. So they're useful because they facilitate components of vulnerability matching via the NVD, but there also are some challenges that come with it. Have you heard of Perl? Anybody? Package URL. It's an attempt to standardize existing approaches to reliably identify and locate software packages. We're excited about the work that's being done there. It's useful to reliably reference the same software package using a simple and expressive syntax and conventions based on just familiar URLs. Package managers automatically resolve dependencies at build time. And so every component available through any package manager already has a corresponding Perl. So Perl is a really, really, really cool potential solution. Swid tags. You may be familiar with swid tags. It once was referred to as an S-bomb data format. It's not really being utilized in that way, but it is what a swid tag is. They're designed to provide a transparent way of organizations to track the software installed on their managed devices. They contain descriptive information about a specific release of a software product. And then you have software heritage IDs. Because I'm short on time, I'm going to also go to Gitbomb. Gitbomb is a really, really innovative and really, really cool project. It is not Git, but it does construct a concise and verifiable dependency graph. And that's going to help you have runtime detection of potential vulnerabilities regardless of the depth in the dependency graph for every software artifact that the vulnerability originated. And it also gives you close exploit forensics. So basically what you need to know is it's going to help you answer the question, does this product contain log4j? So that's a good plug for Gitbomb. Naming versus identification, there's some debate about that. It's part of, but it's not equivalent to identification. It really is, a name alone may or may not be sufficient to identify a component and a component can have more than one name. So a comprehensive component identification system will need to account for multiple names for the same component, right? So likely that's going to happen through maybe aliases or equivalency relationships. What are some potential solutions? We just looked at some of them. What we believe is that there's not going to be just one. It has to be a heterogeneous solution, at least in the short term. Many software identification systems are based on DNS and related mechanisms. And so we believe that that could be used to leverage that as an example. You know, while further testing and iteration are going to be needed, a globally scalable model will almost certainly involve concepts from distributed and federated systems and leveraging what we know from existing solutions like DNS. And they might require intrinsic component attributes like cryptographic hashes. So we believe that it's going to take a combination of all the existing solutions. There's not just one answer, at least in the short term. Lots of opportunities and challenges with this. We need your help. More works needed in designing, testing and implementation. These are just some of the challenges that you're going to face multiple and conflicting identifiers. When you have mergers and acquisitions in the commercial space, project forking you probably are familiar with that. Allen always says that you can spell forking with an OR or EU. And then you have scope problems. You have a lot of internal schemas that are being defined by the developers and the organizations. To sum up, we talked about SBOM and we talked about vulnerabilities. SBOM is coming. The government said if we're buying software from you, you have to pariah us with an SBOM. The number of vulnerabilities are increasing so there's going to be a lot of SBOMs, a lot of VEXs out there. We have to learn how to manage that data, how to share and exchange it, how to move it around. Right now that's challenging because the lack of a robust comprehensive global identification solution is impeding those full benefits of SBOM and VEX. Right now we're imagining a solution that's heterogeneous. We're also imagining other examples that we've seen that have worked. We need your help. We need more work. We need more leadership to design, test and implement these potential solutions. This is the slide. Take a picture of it if you want. Please get involved. You can go to our website sysa.gov. You can email sbom at sysa.dhs.gov. I'll tell you a secret. It goes to me and Allen. You can email me. I'm happy to answer it when I get back in the states. I don't have access to email until then. Just wait. Be patient. I will respond. I am not active on social media, but Allen is very active. Please reach out to him at Allen Freedman, hashtag SBOM, hashtag VEX, CSAF, all the above. And lastly, the community efforts. We have a VEX working group. We have cloud and online applications sharing and exchanging, tooling and implementation, and adoption. If you are interested in any or all of these, please reach out sbom at sysa.dhs.gov. We'd love your help. I'll be around. I'm sorry I took so long. I'll stick around. Please come talk to me. Please come ask me questions. I really appreciate you being here today. Hopefully you learned something or hopefully it was helpful in some way. So thank you so much.