 Hi, my name is Jonah Castro. I'm one of the Solutions Architects here at Appuro and today we're going to be talking about extended software bill of materials and how we can help set the new gold standard for software bill of materials. So when we talk about software bill of materials, why is it something that everybody is even talking about to begin with, right? We've seen software bill of materials in the application security space for quite a while now. You can see that, you know, OWASC created their SBOM standard called Cyclone DX in May of 2017. Prior to that, we had other standards like SPDX. But over the last couple of years, software bill of materials have taken on a much more important role in application security programs. And the reason for that, or one of the reasons for that is largely because of the White House executive order that came out in March of 2021. In due to, I should say, the SolarWindows and Colonial Pipeline attacks that came about. And so the goal of this executive order is really to get more clarity on the different types of technology, as well as software supply chain security controls that are in place for software that's being developed for different types of government agencies. And part of that executive order was largely getting a new development framework created around software, secure software development, right? And this is what spurred NIST 800218, which again goes into depth on different types of controls that you should have in place for that development lifecycle. And then really dives into things like the software bill of materials where you need to have some capability of exporting an attestation report on all of the different types of technology that comprises of that application. Additionally, we're starting to see substantially more compliance requirements require having a software bill of materials in order to be compliant with that overall certification. So you can see things like the CMMC, as well as different types of regulatory agencies like the FDA, Medicare, Medicaid start to enforce this and say that they cannot purchase software or you cannot be certified without having some level of attestation of your application with a software bill of materials. Additionally, we're starting to see substantially more open source frameworks come about around software supply chain security, primarily again things like Cyclone DX where we talked about earlier. This is something that's constantly being iterated on and expanded as to what should be a part of that software bill of materials. And then additionally, you have organizations like Google coming out with things like Salsa or frameworks around the different types of controls that you should have within your CICD pipeline or again that entire secure software development lifecycle. So why do I even need an SBOM? As an organization, why is it something that I should have? And it really comes down to three things. Having an SBOM gives you the ability to improve transparency, it gives you additional visibility into that application and the types of technology that makes up that application as well as gives you an additional layer of accountability. So when you do have a proper SBOM, you understand not only what that application does but it also gives you a complete understanding of all the technology that comprises of that overall application. So now you know again are there vulnerabilities on a particular package, things like that. It also gives you the ability to track and manage those technologies within that application, right? If I know what it is that exists in that application as far as technologies, now I can start setting up guardrails and policies around what types of technology I want within my applications. Are there specific frameworks that maybe we do allow within our organizations versus certain types of frameworks, packages, whatever that may be that we don't, can't set up those guardrails if you don't even have visibility to what's in those applications to begin with, right? Additionally, like we talked about earlier, having an understanding of what types of packages or frameworks or technologies are within that application also gives you the ability to assess additional security risks on that overall application, right? If I know that I have package A, version one, two, three, and that package has known vulnerabilities on it and somebody ships me that software with a software bill of materials that has that particular package in it, I now know that there is an additional security risk to that application because it contains that overall package, right? And this is one of the primary reasons for having that software bill of material at a station is so that as an organization that's either purchasing software or selling software to other people, it gives them the ability to understand what security risks exist within that application as they're, again, transferring it between entities. And then lastly, it gives you the ability to address potential vulnerabilities and compliance requirements, right? Again, if I know what it is that I have and I know where those security risks exist, it does give me the ability to go through and start to fix those or address those concerns with the overall manufacturer of that software so that they can go about getting them fixed as well, right? So what is an S-bomb, right? When we talk about software bill of materials, what does that actually encompass from a technology standpoint, right? And right now I think this is kind of nebulous and really depends on who it is that you're asking, right? So if you ask an SCA tool or a software composition analysis company, you know, what is an S-bomb, they're largely going to tell you it's a list of all of the third party dependencies. What package versions are they using? You know, what licenses come with those packages and are there any vulnerabilities that tie to those overall packages, right? Additionally, if you ask somebody like, you know, a bridge crew or a check-off, you know, hey, you know, what is your particular software bill of materials provide? Typically it's going to be a list of, you know, infrastructure as code components, where are those particular code components located? And then again, are there any particular vulnerabilities that may be sitting on top of any of that infrastructure as well, right? But I think all of us really realize that, you know, there's substantially more that encompasses your overall application than just those third party dependencies or the infrastructure as code that they happen to be sitting on, right? So really, you know, what about all of the rest that makes up your software? And this is really where this definition, you know, starts to get a little bit more concrete, right? Where, you know, when we talk about what actually is an S-bomb, if you look at the executive order, you know, they also mentioned not just the third party software components and tools, but also, you know, what types of services are present? What are your first party code that you're writing? Are there any internal tools that you're using throughout that CICDR, that software development life cycle, right? So it's really encompassing of all of the technology that comprises that software, not just those third party software components, right? And then when you look at something like an OOS Cyclone DX and their overall formatting, you can see again, it does comprise of substantially more than just those third party dependencies, where we're seeing things like what services belong to this particular application. Are there different types of components such as frameworks, containers, operating systems that are a part of it, right? Where do we see things like vulnerabilities? So again, you can see that the software bill of materials definition is encompassing of substantially more than what we're seeing in the market at the moment, right? So when we talk about what's missing from a typical SBOM, there's quite a bit that goes into software development that we're not capturing in that software bill of materials, right? Things like the overall code modules that are being brought in. What frameworks are we seeing? Are there any data access objects? Where do we see things like data models? Of those data models, you know, where do we see things like APIs? Or again, of those data models, where do we see things like sensitive data? Do we have any types of serverless technology that's being utilized within this application, right? Do we have any secrets that are embedded in this application, whether unencrypted or encrypted? Do we see things like security controls, right? Where do we have authorization, authentication, encryption, usages? How are those being used? All the way through things like, you know, what source control management system are we using? Are there proper branch protections or are there proper security controls being implemented on that source control management system? Again, as we're pushing this through build pipelines or CICD implementations, do we have proper controls there? Are there any plugins that are being utilized there that could potentially add additional risk, right? All of these entities within your development lifecycle offer some capabilities to that application as they're being built and potentially could introduce some level of risk as well. Which is largely the reason why here at Appuro, we feel as if your software bill of materials should encompass substantially more. It should encompass all of these things that have a direct relationship within that application and could potentially introduce risk, right? So this is why we introduced our extended software bill of materials. When we talk about our extended software bill of materials or XBOM, largely we're talking about all of the, again, application components as well as risks that tie to those application components across your development lifecycle, right? So some of the things that we include in our XBOM, things like code modules, what APIs do you have? Again, do you have any serverless technology? What data models? Where do you have sensitive data? What types of security controls are you using? Frameworks, SDKs, open source dependencies, et cetera, right? But it also ties to things like what types of vulnerabilities or risks are we seeing within that application, right? As we run SAS scanners or SCA scanners, where are those vulnerabilities and how do those vulnerabilities tie directly to the components within that application, right? As well as things like developer behavior, right? Who's actually working on these particular applications? And which part of these code repositories are they working in? Are they new developers? Are they experienced developers, et cetera, right? All the way through things like runtime security and different types of APSEC processes, like threat modeling, pen testing, security training, compliance reviews, et cetera, right? All of these things are really what make up at the end of the day that software and determine what that software does, what types of technologies in it, as well as whether or not that particular software has any inherent risks that you as either the buyer or as the creator of the manufacturer of that software should know about. Some of the other relevant information that we're seeing being provided on our side by our extended software bill of materials are things like your overall metadata, right? So not only knowing what types of technology is in that application, but also where that technology is coming from with regards to material changes, right? Where do we see new APIs being created? Where do we see new frameworks being added to the overall organization? Where do we see sensitive data coming from? And then from there, where are these actual changes coming from as far as provenance, right? Do we see, you know, an API being created? And if so, what pull request is it coming from? What overall commit? Who's the developer and the code owner that that particularly belongs to, right? Additionally, like we talked about tying the vulnerability and misconfiguration data back to these particular artifacts as well, right? As we scan for things like infrastructure as code, do we see vulnerabilities on those? And again, can we tie them together so that you know, hey, this particular piece of code has this particular misconfiguration, which offers this particular risk, right? And again, this can be done across all of the different types of artifacts or technologies being utilized within your application, right? It also gives us the ability to start doing things like build out parent-child relationships or sibling relationships between this technology, which now gives us an understanding of how these particular components or these particular technologies are working together. And what is that risk relationship between those two multiple pieces of technology within that application, right? And all of this gives us the ability to really track and give you a complete history of all of the changes that are happening within your overall organization or within that particular application as it's being developed, as well as, again, give you that change attribution where now I know where those changes came from within my SDLC process as well as who that code owner that made that specific change was. So why is all of this important, right? What is the purpose of even having all of this information available to you, right? And it really comes down to a couple of things. One, streamlined processes, right? Again, as I understand what's in my application and I have more visibility, I can start to create better processes earlier on in my software development lifecycle to prevent risks from being added into my overall application, right? I can start doing things like guard railing around specific types of technology packages that I want brought in. I can start guard railing around things like specific frameworks that I want brought in. I can start kicking off additional processes when I see new types of changes coming in. Maybe, you know, anytime that I see a new API being added, this is something that I want to kick off to, you know, maybe one of my enterprise architecture teams to validate and make sure that things are being implemented properly, right? Additionally, it gives you the ability to understand enhanced security, right? Now that I know, again, not only all of the technology that makes up my application and all the vulnerabilities and risks that go with them, I can also start to understand how those particular risks or technologies come together, again, from a relationship standpoint, so that I understand whether or not there is a concern as these particular pieces come together, right? Do I have a SQL injection inside of an API that's touching some sensitive data that's also internet exposed, right? Again, all of these things are things that we can come to a conclusion on because of the fact that we have this complete picture of the application, what it's doing, and all of the technology that comprises of this particular application, right? Also gives us the ability to do things that can prove our compliance standards, right? As we start to apply for things like CMMC or want to work with government agencies, having this entire understanding of the application gives us the ability to not only attest to what it is that we have within our applications for other outside organizations, but then also gives us the ability to know when we may be out of that compliance so that we can go about fixing that and know, again, where we need to go about fixing that, who the overall code owner is, and where in my overall application this particular issue lies, right? And then lastly, greater transparency, right? Again, the more visibility that we have into what comprises of these applications or what makes up these applications, the more capabilities that we have on our side of giving this visibility to others as well as start to create better development lifecycle processes earlier on in order to make sure that we're creating cleaner code on the back end. So hopefully this has been helpful. I really appreciate your time. If there's any additional information that you would like from us with regards to APIRO, our capabilities, or what we can help you out with with regards to extended software bill of materials, please don't hesitate to visit our website at www.apiro.com. We'd love to hear from you and see if there's anything that we can help out with. Thanks so much. Appreciate your time. Take care and have a great day.