Securing the Software Supply Chain Transparency in the Age of the Software Driven Society | DevOps Connect: DevSecOps 2023

All right, so my name is Chris Hughes. I'm a csom co-founder of the company named aquia. And I'll be talking today about software transparency, a push for software supply chain security.

I'm gonna cover quite a bit of topics and different areas of technology, so I hope you can bear with me throughout the talk. Uh, so first off, I'm gonna start with open source software adoption. Uh, we all know that there's been a thriving ecosystem of open source software.

You know, organizations of all shapes and sizes, every sector in the industry are increasingly using open source software. I don't wanna read all the metrics off to you, uh, but as you can see, you know, almost every organization is using open source software to some extent. That includes, includes, uh, critical infrastructure systems, national security, uh, every sector you can essentially think of.

And organizations are starting to sponsor more and more open source software projects as well. Uh, we're seeing the biggest growth in areas such as DevOps and Cloud Native and C I C D tooling, uh, which is kind of, uh, I guess timely given we're here at DevOps Connect. Uh, that said, there's some challenges associated with open source software adoption as well.

When we think of things like Log four J, obviously that one comes out, you know, to top of mind right away when we think of, uh, software supply chain attacks. Uh, but organizations such as Sonotype and others have pointed out that there's been over a 742% increase year over year in the last three years, uh, when it comes to software supply chain attacks. And if you look at the image on the right from the Atlantic console, you'll see that the challenge of the open source software is it gets baked into, you know, an application, uh, a service, a product, and downstream it kind of flows into the consumer, the customer, and you don't have really good understanding of, you know, where do these open source software libraries and components exist in our environment?

Uh, where, where, you know, what applications and, and systems are impacted, you know, uh, where do these components reside and how do we respond to incidents, for example, if something does occur. Uh, so the bad side of open source software adoption, as I talked about, you know, organizations of all shapes and sizes are using open source software. And studies are starting to show that, you know, modern applications, 60 to 80% of 'em are composed of open source software components.

Uh, that said, software supply chain attacks are also on the rise. If you look at the, uh, the mular left there, you can see a massive increase. And the reason for this is, you know, malicious actors have realized that they can target, you know, one in one, uh, organization, you know, one, uh, program or customer, for example, and have an impact.

Or they can target one open source software component or a library and have a massive downstream impact across the entire ecosystem, impacting thousands of organizations and millions of individuals. Uh, another uh, challenge with open source software adoption is mainly these projects are ultimately supported by unpaid volunteers. Uh, so we often think of software supply chain, uh, you know, but in the context of open source software, your open source software maintainers and contributors, they're, they're not your suppliers.

You can't make any demands of them. You have no service level agreements. They're, they owe you nothing.

Essentially, you're using their software at will. Uh, and then if you look at the, the ecosystem studies are showing that over a quarter of projects have a single maintainer. Uh, so if you think about the term, a bus factor, if you ever heard, like, you know, weapons happens if Joe gets hit, hit by a bus, well, if Joe's your one maintainer, uh, for this open source software component library that you're using, uh, that puts you at some great risk.

And 94% of the projects out there have less than 10 developers. Uh, so the overwhelming majority of the open source software ecosystem is essentially maintained by a very small group of individuals. You know, for every, you know, Kubernetes or Linux kernel, there's thousands and thousands of other projects that have very little support at all.

Uh, and an incident such as Log four J essentially sent organizations scrambling cuz they have a lack of visibility at the software component level to understand, you know, where does this, uh, component or library exist in my environment? And as you can see on the right, uh, we're seeing an uptick of these type of attacks. You know, many different examples, whether it's, you know, uh, typo squatting or compromising a software package or, you know, things of that nature.

There's a lot of different unique attacks that they take. And another great resource I wanna bring up is, uh, CNCF has created, uh, what they call a software supply chain attack, uh, uh, catalog. And you can go look and see the different attack types that are there, but as you can see, there's been quite a few just in the last couple years now.

So what do we do about this? We're starting to see organizations try to get a handle on their open source software adoption, put some governance and rigor around it, and try to add some security, you know, to their open source software consumption without a course. You know, introducing too much rigor, too much friction, slowing down developers, and essentially, you know, uh, being the office says no of no as we're typically known.

Uh, so NIST has put out some great guidance in their cybersecurity supply chain risk management. It's, uh, NIST 801 61, and they laid out some capabilities in that publication that are found, uh, you know, kind of in a maturity aspect. If you've heard of maturity models, I'm sure all of us have.

They have foundational, sustaining and enhancing capabilities, which I'll be discussing here soon. And among those, they discuss things like software composition analysis, uh, software build materials, which I'll discuss some more effects, which is the vulnerability exploitability exchange. And then also doing activities like, uh, creating centralized hardened internal repositories for your open source software components.

This way you don't have developers just going out and grabbing whatever they want off their open internet, you know, using it at will with no understanding of, you know, what's in it, what vulnerabilities are associated with it, who contributed to it, what's the pedigree and providence of it, et cetera. Uh, so as I said, there's been a lot of interest in the industry lately around SBO m a software bill of materials. Uh, if you haven't heard of the term, it's essentially a nested inventory or a list of ingredients of an application or a software component.

And it started off with N T I A, uh, with Dr. Allen Freeman, who I'm sure many of you will see here, speaking at, uh, at the event this week. Uh, and then it went from there to ssa.

Uh, so CSA held many events, you know, in early 2021, they held the Esba Rama, and from there they stood up different Esba m work streams around areas like cloud and online applications, uh, sharing and exchanging SBOs tooling and implementation. And there's some different SBO m formats that are leading in the industry. Uh, among those are swd, cyclone, dx, and spdx.

Uh, but that said that two that have primarily taken up, uh, industry adoption and use are the bottom two. Cyclone dx, which is led by the OWA Foundation, uh, you know, co-created by individual named Steve, Steve Spring. It, uh, who's the co-author of a book I just recently finished up.

And then spdx a software packet data exchange from Linux Foundation. Uh, that one actually just became, uh, an ISO standard as well. Uh, and then another ef an effort that's getting a lot of adoption is called vulnerability Exploitability Exchange.

Uh, and SBOs gonna tell you, you know, what are, what's, what's the ingredients in the software? You know, what vulnerabilities or CVS are associated with it. Uh, but the problem with that is there's a lot of noise in that, you know, we need to know what vulnerabilities are actually exploitable, what do I need to be concerned with?

What actually poses the most risk to me as an organization? And this is where we're seeing vulnerability, exploitability exchange, you know, start to get traction. It's essentially a companion document to an SBO m.

This way, if a vendor gives me an sbo, they can also give me a vex and tell me, you know, of these vulnerabilities in the application, these are the ones that you actually need to be concerned with that are exploitable, that are reachable, and that pose a risk to you as an organization. Uh, so next up is gonna be C I C D pipelines. You know, we all, we all know C I C D when it comes to DevSecOps, and it's, you know, gain a ton of traction in terms of the way we de develop and deliver software.

It's enabled us to integrate security tooling. We're here at DevOps Connector, I should say, DevSecOps, as they said, it's now DevSecOps. And we all know the infamous, you know, shift security left, uh, bacon Security, not bolted on and so on.

And C I C D has helped, helped do that by integrating tooling, you know, robust capabilities such as SAS and DA and secret scanning and, uh, container vulnerability scanning and so on. SBOs. Uh, and there's a lot of great capabilities you can do when you take the CI cd approach to delivering software.

That said, uh, CI c d pipelines also have some challenges associated with them, just like other entities I discussed previously. Uh, many organizations simply haven't adopted a unified CI platform. So you may have, you know, some, some CI platform, but then you have a lot of disparate tooling that you're trying to integrate, you're trying to use as part of that pipeline.

You have to manage all those in independently. And then also, organizations simply don't consider the pipeline as part of their attack surface. Uh, you know, they don't think about the fact that not only do you wanna secure the software that's coming out of the pipeline, but the pipeline itself, it's infrastructure, it's hosting environment, you know, whether you're thinking of a SaaS provider or you're self-hosting, you know, some kind of CI platform for example, that's a, uh, attack vector for the malicious actors as well.

And a compromise with the pipeline or build activities can lead a massive lead to a massive downstream impact. Uh, we saw Solar Winds on the right there, for example, impacted many organizations. I think it was 18,000 organizations, many of which included federal government agencies, uh, that were impacted downstream due to the Solar Winds incident.

Uh, so they're starting to even strive for different, uh, different compromises and attack vectors too. Not only compromising the pipeline, but also the signing systems. So you may consume a piece of software and it's even signed and may seem trustworthy cuz it's been signed, but if the signing, uh, system itself was compromised, all you're doing is, you know, consuming something that's signed and also poisonous at the same time.

So what do we start to do about the CICD pipeline? How do we address this? Uh, it's enabling a lot of value delivery, as I I talked about, but it's also a threat vector.

Uh, there's some great resources that have come out, you know, organization known as Cider security, uh, who recently was acquired by another company nonetheless. But, uh, they produce something called a C C D risk list. It's a top 10 risk associated with C I C D pipelines, and they now volunteered or contributed that to, to owa.

So to Owas project, you can go check it out and see like some of the common things that are impacting, you know, vulnerabilities or risk associated with ci cd pipelines, things such as insufficient control for flow, inac, inadequate identity and access management, dependency chain issues, and so on. Uh, we've also seen another effort come out of Google, uh, known as salsa supply chain levels for software artifacts. And this framework is essentially focused on preventing or doing three things at a high level, which is preventing tampering, improving the integrity of packages, and also securing the packages that are coming off of pipelines and software delivery platforms.

Next up, Kubernetes and containers. Everyone knows, you know, if you're doing any kind of software in a, in a large enterprise environment, you inevitably have heard of Kubernetes and containers. Uh, everyone is starting to use Kubernetes to develop a, you know, platform as a service environments, uh, you know, orchestrate containers in their, in their enterprise environments, and has seen a ton of adoption across the industry.

You know, it says that 75% of organizations are using, uh, containers and Kubernetes is of, of course, the de facto container orchestration platform tool of choice for most organizations. Uh, and that's for great reason. It reduces deployment timelines.

It has cost, uh, cost optimization, uh, capabilities, improved scalability, unless you move from a traditional kind of click ops model to a GI ops declarative type of infrastructure deployment model. And you can, uh, handle, you know, providing resilient applications, you know, that scale up and scale down as needed. But that said, just like the other things I've talked about, Kubernetes and containers have security challenges as well.

You know, if you look at research from Palo Alto's, unit 42, which is a threat research group, they went and took a look and saw that 99% of Kubernetes helm charts that are out on artifact hub have insecure configurations. So I talked previously about that declarative, you know, approach to provisioning infrastructure and deploying systems. If I have misconfigurations or vulnerable configurations in those, you know, manifests, for example, all I've done now is extrapolate how quickly I can, you know, spread those vulnerabilities at scale across many organizations.

The same thing is occurring with containers. For example, if you look at Docker Hub and Quay and Google Cloud, uh, the container registries, they found that up to 91% of the images in those environments had critical, uh, findings, critical cvs associated with them. So if you're going out and pulling down Kubernetes manifests or containers off these sources, without running security scans or hardening these things in advance, you're essentially just ingesting, you know, malicious and vulnerable, uh, infrastructure that you're gonna now deploy into your enterprise environment.

Uh, so some of the recommendations there, of course include things using like, uh, uh, container and manifest scanning. So scanning the containers to see vulnerabilities, scanning the infrastructure as code to see is there misconfigurations there, whether I'm provisioning infrastructure, you know, things such as AWS and Azure and so on. And also using pre hardened images.

Uh, I come from the space of the Department of Defense and US government. And over there we have efforts like Iron Bank, which is a pre hardened image repository where you can go and download images that have been hardened. You can see what vulnerabilities are associated with them, what risk, you know, what residual risks still exist.

And also those images are signed so you understand, you know, they, where they're coming from, what's been done to 'em, who's touched them, who's used them, et cetera. We've also seen a lot of guidance outta groups like Center for Internet Security, uh, cloud Native Computing Foundation. And of course, department of Defense, as I talked about, have their container hardening guide.

And they also have a, a, a Stig, a Security tech technical implementation guide as well. And you wanna scan these containers throughout their life cycle. Uh, it's one thing to scan the container when it's going through the pipeline, but the thing is, you know, software, as they say, ages like milk and containers are no different.

You have a container that you didn't catch any vulnerabilities with in the pipeline, and now it's get deployed. New vulnerabilities are emerging over time. So you need to continue to scan those things in runtime environments as well.

And you ultimately need to update things like your incident response plans, your playbooks to encount for these technologies. I've seen incidents where, you know, people have these technologies deployed in their environment, but when an incident happens, they don't know how to respond to it. No one knows really, you know, how to handle an incident response activity when it comes to Kubernetes containers and cloud native environments.

Uh, so these insecure configurations as a, as, as I talked about, exists not only in, uh, containers, but also infrastructure as code. Uh, we're seeing people start to use things like, uh, AWS cloud formation, uh, or Terraform if you're looking for a vendor agnostic infrastructure as code template type, uh, approach. And these can have misconfigurations, you know, think about poor network security exposed buckets, uh, you know, poor IM practices, et cetera.

All those things can exist in your infrastructure as code templates. So you need to scan those as well. Uh, this aspect I'm particularly passionate about, it often gets overlooked when it comes to software supply chain security.

Uh, is the SAS software as a service, uh, you know, attack vector, basically, uh, many organizations when they talk about software supply chain, they of course think about open source software proprietary software that they're using in their environments. Uh, but the reality is many organizations are now using SASS as the primary method of consuming and deploying software. Uh, and as that, you know, the, the problem with that is, typically IT and security teams have very little control or visibility around SASS usage.

Uh, studies are showing that only about 20% of SASS usage is, uh, I governed by the IT or security team in environments. And, uh, large enterprise environments are using several hundred SaaS applications, adding up to 10 a month from IT teams or development teams or business units. And the security team has no ability to keep up with this pace.

You know, as we all know, when we think about cloud security, uh, you know, I'm, I've, uh, went deep on AWS and Azure. They have, you know, networking, security, different, uh, credentials you can learn and, and develop and, uh, expertise for their platforms. But think about the SaaS ecosystem.

You know, how many SaaS applications can a single individual be an expert on securing not many because there's just such a diverse ecosystem. Uh, so that ADD adds a lot of challenges. And so I talked about SBO m earlier.

You know, we're starting to see a growth for what's called a SaaS bomb, which is essentially starting to request a SaaS, uh, or an SBO m from your SaaS provider to understand, you know, what software components are in these SaaS applications that we're using. And if you look at the, you know, software supply chain, an example of Twilio, for example, they had an incident that affected 130 other SaaS providers. So it has a massive casing impact across the ecosystem.

You know, all these third party integrations that are inter, uh, interacting between the apps, uh, your enterprise environments, your hybrid cloud environments and so on. And I was involved in, uh, cloud security alliances, SaaS governance, security, best practices, uh, guidance. If you go out and check that out.

Uh, I led that effort, uh, with about, I wanna say 30 other individuals. And it's, uh, the most comprehensive vendor agnostic SaaS security guidance that I'm aware of. Uh, so definitely give that a look.

Uh, I know this isn't a federal event, but I wanna touch base on some federal activities that I think are driving a lot of the discussion around software supply chain security. Uh, obviously we all know the cybersecurity executive order section four was heavily dedicated to software supply chain security. And out of there, we saw a lot of activities from organizations such as nist, uh, office of Management and Budget, cisa, and many others.

And so, among those n held various workshops around cybersecurity, supply chain risk management, uh, they publish a new version of their secure software development framework, or SSD f as you may hear it called. And then they ultimately published that csri guidance on May 5th, 2022. And something else I want to talk about here is they published an OM B office, Mon, uh, office of Management and Budget 2218 memo, which I'll discuss on the next slide.

Uh, so in, as part of the publication from nist, they started, they put out, you know, not only 800, 1 61 that I talked about earlier on in the presentation, but they put out separate entire webpage when it comes to securing open source software, your consumption and use of it. And they, they put out those CAP capabilities, as I talked about in a maturity type model. So, foundational, sustaining, and enhancing.

So if you look at some of these activities, it's gonna be doing things like foundational stuff like using SSD F and the great thing about SSD F I'm not sure about you guys, but, uh, we have a framework problem as an industry, every time there's an incident, there's a new framework. The good thing about SSD F is it, and used existing things like b uh, BBC or owa, sam, other, you know, security and application security frameworks that are out there. Uh, so they recommend using SSD f ensuring that your open source software components are coming from secure channels and a trustworthy repos, for example, uh, using tooling like software composition analysis to understand, you know, what vulnerable components and open source software components we have in our applications.

And as I talked about earlier, you know, establishing those internal repositories of known good libraries and components that developers can use. That way they don't have to go out to the open internet grab anything they want, and you have no visibility of this. I'll say though, doing that at scale in a large, complex, uh, disparate environment is very challenging.

Uh, trying to control that flow of open source software use. Uh, and then last up is enhancing, and this is where I think they talk about things like using secure programming languages. Uh, rust, for example, has gotten a lot of industry attention lately, and NSA has even put out some guidance on adopting memory safe programming languages.

Uh, you've probably heard, you know, folks like Jen, Jen Easterly, or the Office of National Cyber Director advocating for these memory safe programming languages as well. And then ultimately they recommend automating the pipeline of collecting and storing these open source software components, you know, prior to introducing 'em into environment. So you understand what's going out there.

And I talked about previously, uh, OMB memo 2218. Uh, you may think, oh, that's, that's a government thing. But the government has massive, uh, purchasing power in the tens of billions of dollars every year for software.

And they're trying to use that, that massive purchasing power to drive systemic changes in the software ecosystem. Uh, so what they're starting to do is this, this memo here basically says, any federal agency buying software from a third party, you know, uh, third party provider, for example, a third party software supplier, need to start get self need to start getting self attestation, uh, statements from that software provider saying that they're using things like n Secure Software Development Framework, as I talked about previously. They'll also start to look and see, you know, can you self attest to this?

Or do you need a third party to attest to this? So think about the kind of like FedRAMP model or SOC two, uh, third party assessment type activities. Uh, then ultimately they may start requiring, it says they may start requiring software build materials as well from these software suppliers, these third party software suppliers.

And, and they're gonna be in formats as defined by nt I I talked about nt I NT I a earlier. Uh, they put out the minimum elements for an SBO M guidance, uh, that industry is starting to use that provide, you know, what fields are required to make an SBO m actionable and usable. Uh, we've seen a lot of notable industry efforts too.

I talked a lot about NIST and, and, uh, OMB and CISA and so on. Uh, but we've seen a lot of AC activities from industry as well, groups like Linux Foundation, open ssf. Uh, last year, uh, the Open SSF hosted an activity at the White House actually.

And out of that, they published what they call their open source software security mobilization plan. And it lays out these three, uh, overarching goals, which is securing open source software production, improving vulnerability discovery and remediation for open source software, and then also shortening the ecosystem patching response time. As I talked about, we have these projects that are being used by thousands of organizations, millions of individuals, but it may be maintained by just a handful of individuals that aren't, you know, they don't have the time, uh, resources or even maybe the desire to respond to an incident.

They're doing this voluntarily on their own free will. Uh, so Open SSF published this mobilization plan, and it focused on different things like developer education, uh, you know, starting to encourage the digital signatures for open source software components, starting to drive adoption of sbo m They, they've kind of phrased it as sbam everywhere. And then they also provided a risk assessment dashboard.

They went and took a look at the top, you know, 10,000 most used open source software projects and put together a dashboard to look at things like not only cvs, which are leading indicators, or I'm sorry, lagging indicators of risk. You know, if there's a cve, there's been a problem, there's a vulnerability, we already know about it, but there's also leading indicators of risk. How many people are participating in the project?

What's the project's hygiene for the repository? How, what's their meantime, uh, to remediation for vulnerabilities, things of that nature as well. Uh, so we have guidance galore.

You know, I, I have a book I wrote that I'll be talking about here in a moment. Uh, in that book I cover, like, this is just a subset of the guidance that we have around software supply chain security, everything from NSAID to NIST to csa, cncf O osp, uh, they're all putting out all this guidance, all this, uh, information. So we have no shortage, you know, of, of best practices and guidance.

Uh, as I like to say, you know, we're best practices rich, but implementation poor. We are, we are overwhelmed with all these best practices of what we should be doing for software supply chain security. But when you go into an environment and start to assess, you know, what are they actually doing, you see a massive gap between what should be done versus what actually is being done.

And another challenge is many these org, uh, many these best practices that are advocated for in these, you know, publications. Uh, you know, it's very difficult for small and mid-sized businesses to meet these. They have a lack of, you know, we talked about security champions a moment ago.

We all know the, the cybersecurity, uh, talent shortfall, for example. Uh, many organizations don't have enough resources to address these things. Uh, they don't have the time, energy, resources, you know, funding and so on to address a lot of these, uh, software supply chain concerns.

Uh, so we have a real challenge on that front. Uh, we recently saw the 2023 National Cybersecurity strategy come out. I'm not sure if folks have read it, but if you haven't, definitely check it out.

Uh, and it builds on efforts from groups like, uh, the cyber security executive order, nist, uh, omb cisa and others. And it reiterated the role of software build materials and things such as a secure software development framework. Uh, the most notable in, uh, introduction, in my opinion, that got a lot of industry attention is it introduced the concept of software liability.

Uh, they call this, you know, software's third rail, because people don't typically wanna touch this topic. It's very controversial. 3 in that national cybersecurity strategy, it discusses shifting liability for insecure software products and services to the suppliers.

Uh, so if you think about in economic terms, they call this the least cost avoider, shifting the responsibility to the entity best position to do something about it. And this is getting a lot of attention in the industry. And a quote from the strategy actually says, the administration's gonna work with Congress in the private sector to esta to establish software, uh, to establish, I'm missing some language there, to establish some liability for software products and services.

Uh, so this is getting a lot of attention cuz people are concerned, like, you know, what does this look like? What do we need to do to kind of, uh, shield ourselves from liability? And that's where things like safe harbor come into play.

Uh, you'll hear that term. It's kind of how do you, uh, shield yourself from liability, ensure you're doing what you need to do, you're mitigating risk and meeting the requirement. Uh, and you won't be held liable, for example, if something does happen, as we know in security, uh, it's not a matter of, uh, if, but a matter of when it's gonna happen no matter what.

Uh, so how do we get started on this front? You know, I, I talked about a lot of guidance here from NIST and others, you know, and, and some of the overarching themes that keep coming through are establishing those known trusted repositories of software components to use, uh, creating capabilities when it comes to ingesting, enriching, and utilizing SBOs and those standardized formats. I talked about spdx and Cyclone dx.

Uh, and also if you're a software supplier or a vendor, you need to start creating capabilities not only to, uh, ingest and enrich SBOs, but actually to create and provide and share SBOs as well. Uh, because your consumers may be asking for these soon, especially if you're selling to the federal government. Uh, so as a consumer, you know, you wanna start requesting these things like SBOs from software vendors, including your SaaS providers.

You wanna understand like, what software am I consuming? What software am I consuming and, and how am I impacted by vulnerabilities in the software? And then of course, I talked about NS CCRM guidance.

Uh, you wanna interact, uh, integrate, uh, SBO m and CCRM guidance into your vulnerability management programs and start to get some governance around your SaaS security, uh, your, your SaaS con consumption, understanding what SaaS am I consuming, you know, in my environment, who's using it? What data is residing in those environments? You know, where are the compliance artifacts associated with those SaaS vendors and so on.

And, you know, what's the security of those environments? Uh, as I talked about, I have a book that's coming out, software Transparency, supply Chain Security, and an era of a Software Driven Society. Uh, my co-author is named Tony Turner, and I had, uh, the four words written by Dr.

Allen Friedman, who I talked about from sisa, who's leading the ESP BM efforts and our technical editor where Steve Spring it, who leads the Cyclone dx, uh, um, SBO M format for O osp. Uh, so definitely give that a look if you're interested in that, in that book, I go through everything that I talked about here at much greater depth, all the publications around software, supply chain security, all attraction around, uh, SBO m for example, all the, you know, kind of folly of the traditional way we've pro approached software supply chain and application security and how we're addressing these things moving forward. Uh, so that's said.

Any questions? There you go, Chris, thank you. Please say thank you to Chris and please line up for questions.

I'm gonna do a, a little, uh, uh, introduction here, Chris, as you're going a question right there. Go ahead. Yeah, man.

Hey Chris, how was going mate? So one of the challenges around this space is the definition of software supply chain, right? You and I have talked about this a little bit.

Yep. So I think there's that, that leads to unfortunately, uh, an emphasis on open source libraries and people kind of focus on that place. Goodday, Gigi.

Um, the reality is that the software supply chain is a lot broader and a lot more complex, and you touched on that, but things like cloud resources and pulling in things from CDN providers and whatnot, how do we help educate, you know, the people that are here today to help them understand the software supply chain is a lot more than just those open source libraries that seem to be getting a lot of focus right now. Yeah, it's too funny you mentioned that, cause I was chatting with, uh, Matt Rose in the back there, reversing labs, and he, uh, mentioned the same thing. Like if you ask 10 people what software supply chain is, you get 10 different answers.

Uh, and it is, uh, way bigger than open source software. And I don't like how it gets a hyper, you know, hyper focused on open source software, either cuz it gives open source a bad name as if it's, you know, inherently insecure and vulnerable when the reality is many of these open source software projects are more robust and secure than proprietary software that you're using. It really depends, you know, how much the project is maintained and contributed to, or how well crypto, you know, the software vendor is, for example.

Uh, it includes things like open source software, proprietary software, SaaS applications, you know, your, your, uh, your vendors and, uh, manage service providers, cloud service, cloud service providers, et cetera. Uh, when it comes to how do we, uh, uh, educate folks, honestly, I, I'm doing what I think is the right of way, which is get up here and try to have these conversations with folks and, you know, spread the word of what software supply chain is and how can we address it and what some of their challenges are. Yeah.

I've got a question. I'm interested in the, uh, the known trusted repositories. Like how does, how does, how does, I guess, how does that work in practice?

Does it just become like, uh, you know, my, my, uh, uh, architects have have blessed these 50 libraries and no others. I mean, how does that avoid just becoming a bottleneck? Yeah, I mean, Chris, can I jump in there too?

Yeah, yeah, go ahead. Because there is an argument against Golden repository. I, I I, I actually agree with the argument against it.

Okay. Uh, because like if anyone's trying to maintain golden images, for example, for an enterprise, that's a, a pain, right? Try to do that for open source software components, which there's ex exponentially many more of, you know what I mean?

And we talk about trying not to introduce friction and, and, you know, facilitate, develop developer velocity. Like it's gonna be incredibly hard to do that with a process like that. And there are other groups that have advocated for a different approach, a more decentralized approach.

Uh, Microsoft actually has something they call S two C two F I think it is, I forget the exact what it stands for, but it's their software supply chain guidance. As I mentioned, everyone has their own flavor of this, and they advocate for more of a decentralized approach of empowering people with tooling, you know, to run, run scans, et cetera, you know, and get that information closer to developers that can do something with it. Versus centralized governance, you know, rigorous, uh, you know, centralized type model.

Uh, Chris, sorry, Chris, uh, thank you for the session. My, uh, question relates to the SBO that SaaS vendors need to share. As you said, uh, even if I'm a large enterprise and I ask my SaaS vendor to share the sbo, I don't think that that's very likely to happen, right?

I mean, it's not something that they would want to do for fear of all kinds of things. Yeah, Yeah. No, you're spot on.

So I'm working with a federal agency that, uh, has started requesting these from SaaS vendors and it's, we're getting everything in between. Like, some people are like, oh yeah, here you go. Other people are, what the hell's an sbam?

And then others are like, we're not giving you that until it's part of the federal acquisition regulation standard, for example. Or it's written into your policy. Uh, and I think it's gonna be a lot of different things like, you know, there's gotta be incentives there to provide that level of transparency, uh, whether it's an enforcement mechanism, like a contract or so on.

Cuz people aren't just gonna voluntarily provide these things. Uh, it opens them up to additional questions around vulnerability and risk and so on. Uh, so they're not gonna voluntarily provide these things.

I think it, and there's a lot of factors at play, like, you know, what's the purchasing power of the people requesting it? If it's the federal government, you might have a chance of getting it. If you're a small, mid-sized company, eh, probably not.

You know, so like, there's, there's a lot of different factors at play, but I agree. It's, uh, people aren't incentivized to provide transparency if they're not required to. Very, thank you.

Thank you. Middle. Yep.

Uh, thank you for your, uh, presentation. Uh, this is our basic, uh, question. Uh, is there any actionable or actual use case, uh, about, uh, vulnerability management, uh, using sbo?

Yeah, I've been connecting with, uh, a number of the vulnerability management companies. And, uh, you know, and talking to Dr. Ellen Friedman too on this topic, I think rather than another bespoke additional tool to manage SBOs and vulnerabilities, we're gonna start to see large vulnerability management players bring this kind of telemetry, this data into their, into their platform.

Uh, cause you don't, you, you wanna bring this information into your vulnerability management platform and see, you know, what are the vulnerabilities with our assets down to the component level, for example, for applications. Uh, so I think we'll definitely see vulnerability management companies go that direction. It's just gonna take some time, honestly.

Okay. Thank you. Thank you.

Far right? Yeah, just a quick question. I've been told that, uh, some open source projects have zero day notification programs that they give to their vendors.

So if they're something's coming out in two weeks, they tell the supplier, then the supplier has time to patch, which then comes to us as the large enterprise. Is that true? And if so, what is that called?

Because I'd, I'd like to be buying from people that do that. I like that. Yeah.

Is that true? Uh, I don't know that it's true. I haven't seen that.

Uh, I'm not saying it doesn't exist. Uh, if it does, okay, if it does, I imagine it's some of the most matured, you know, uh, open source software projects that have some of the most robust, so You had to pay for, someone told me these other commercial firms have to pay and some of these open source projects to generate revenue, have, uh, you know, more professional Yeah. Level of notification that they pay for.

But I think, I think as we start to see open source adoption continue to grow and thrive and mature, like you are gonna have to introduce financial compensation. If you want some kind of service level agreement, you want some kind of responsiveness, uh, you are gonna have financial incentives at play. And we're starting to see, uh, I don't think I touched on this, but some organizations are starting to take a crowdsourcing model too.

Uh, if you have a lot of, uh, large enterprises using a certain pro uh, project or open source, you know, component, start to try to fund those things and aggregate, you know, contribute some funding to them too. All right. Thank you.

All right. Say thanks to Chris, please. That was amazing.

Hold on, hold on.