 My name is Brandon and thank you for coming to the Global Security Vulnerability Summit. This is the first one that we're doing. We're very excited to be here. So let's talk a little bit about what we're here for. So we're talking about vulnerabilities and you know, if we kind of look back as long as systems have existed in the past, vulnerabilities have to, you know, they may have different names, but we know that security vulnerabilities have been there since the start. And since then, we've had a lot of tools and a lot of specifications, a lot of technologies and groups that have served us well over the years. And in fact, if we take the look back into, you know, we have a lot of us are familiar with the idea of CVEs and this was actually the position paper introducing CVEs and this was back in 1999. So we've come a long way. It's been 20 years since we started talking about this problem as an industry. But with anything over time, you know, things evolve, things change. And we're seeing that the vulnerability landscape has also been continuously evolving. For example, we've seen a lot of interesting hardware attacks, you know, we had back then they had Rohammer, now we have the Spectre meltdown variants and most recently the Hertzbleed vulnerability. But not only in terms of like classes of vulnerabilities that we're seeing, but we're seeing that as you know, the computation paradigm is changing, we handle them a little bit differently. So for example, we talk about moving towards a cloud native infrastructure. In cloud native, we always say, we have to saying that we treat our systems and computation like cattle not pets, where we don't take care of each and every one of them, but we let them roam free and then we try and hurt them together and figure things out. And this is difficult because this makes questions such as incidence, response, inventory a lot more difficult, right? And this brings us back to the iconic question of, you know, am I affected by the next big vulnerability of, for example, the lot 4j question that I'm sure we mentioned a lot of times today and tomorrow. But yeah, a lot of these questions and you know, as we we move forward, also software becoming more and more complex and this does not make our job easier. So with these new developments, we must as a community work together to develop new solutions and also to adapt current ones to work with the evolving landscape. So one thing I want to point out, you know, Emily and myself, when we were thinking about putting this event together, the main purpose of this event was not only about sharing innovations and sharing solutions to problems today, but we really wanted this to be a forum where we can get people together to discuss and tackle the problems. We have a lot of people with a lot of diverse backgrounds here. We have security researchers, vulnerability databases, industry verticals, we have SERTs, source code infrastructure package manager, manager maintainers and many more. So the aim is not only to start these discussions, but also to continue to, you know, bring them to actionable items. And so what we'll be doing today later on is we're going to start with a bunch of the feather discussion. This will be at the end of the talks today. It will be in this room. And if you are virtual, you can also participate. We have the hack MDs, and this is also in the chat entry. And the idea here is that we're going through these three different problems. We're gathering information and ideas and, you know, what are some of the pain points that people are facing? And at the end of this, what we want to do is you want to spin up a working group to kind of create actionable items to move forward and tackle these problems. Emily will talk a little bit more about the working groups, but the both sessions are happening today after the talks and looking forward to the participation there. With that, I'd like to pass on my time to we have two keynotes today. First, we have Anne, who's been a part of the space for a really long time. She's going to talk to you a little bit about, you know, how we've gotten here since the start. And then we have Frederick, who's going to talk about, you know, the perspective from the industry and how industry is using the vulnerability information. Just get this over. This is good. Yeah, that's great. Awesome. Excellent. Thank you. Good morning. Yeah, people are kind of awake. So a lot of you are happy hour last night. There we are. All right. Good morning, good morning. You know, so Brandon and Emily asked me to come here today and they said, you know, can you can you set the stage for this global security vulnerability summit, the first of its kind? And when someone asks you to do that, there's a couple ways you can go about it. I think a common one, an effective one, is to take that historical perspective. So for this group, that would really be a long history of vulnerabilities. And we could, you know, go through all the compromises we've seen in traditional fashion. We would start with Heartbleed and then we would jump forward six years like nothing happened, even though a lot of things happened. And we would get to Sunburst, the suite of attacks against SolarWinds. We'd have to talk about then actually, let me say about SolarWinds. I think what's notable about that is not because it was necessarily specific to open source, but it really changed the conversation around supply chain. It really changed the conversation around open source software. A lot of people who had not been paying attention to a problem that was not new suddenly started paying attention. But CodeCov, that was a little bit more open source specific. We're bashing around everything. Then we get to PiPi, ripping things out. Great job, Dustin. Thank you for ripping all those things out. We'd have to pour one out for all of the registries that have had issues with typosquadding. And then of course we need to talk about Travis leaking secrets and finally log for Shell. But, you know, this audience, all the things you're here for, I don't feel like we need to talk about any of these things. I think the last few days, all the discussions, I could see it in your eyes in happy hour last night that you were part of the remediation for a lot of these. And you were here this morning because you know that there is a problem. We are in this repetitive cycle of vulnerabilities with very significant blast radiuses. And that blast radius, like Eric Brewer was talking about on Tuesday, is because of how critical open source software has become. So in some ways, congratulations to us. People are using these packages at a massive scale, but now we're in this repetitive cycle of very serious issues. So indeed, open source is our technical public infrastructure. You know, I think between works like Nadia Engbal's Roads and Bridges, conversations I've heard this week, we've really accepted this premise, which is fantastic, because it is the common good we are all relying on. We're all dependent on its performance. We're all dependent on its security. And we're here today because we know if we don't change something and how vulnerabilities are managed in open source, if we don't change something in the tooling that's available to users and maintainers, we're just gonna be in this cycle endlessly. Have you were a fan of Twin Peaks? Every time there's an incident, it will be like the Tall Man. It is happening yet again. No giggles, no Twin Peaks fans, all right. Fine, fine, fine. Thank you, Jeff. Cherry pie, this is good coffee. All right, carrying on. So, you know, this is a fantastic schedule. Bravo to the programming committee. We have 48 hours of people proposing ways that we can improve this technical public infrastructure. And we want these ideas and these proposals to have sticking power. You know, we want them to go through the industry with the same blast radius that those pesky vulnerabilities do. We want them to really be effective. So to do that, I actually wanna give you a framework to just some big ideas to think about for the next 48 hours. And I wanna take us outside of software to have that conversation. I wanna go on a cross-disciplinary journey because if we really see open source as public infrastructure, what can we learn from the people who have been doing this at massive scale, changing publicly shared goods for a really long time? What are lessons that how we do public planning and effective change in roads and buses and transit, what can we learn from that? Now, I myself, I'm a public transit and bike lane enthusiast. You know, I took the bus to get here this week if you are going to the airport for $2.50 and 30 minutes of your time, the Austin Cap Metro system will take you to the airport. It's the 20 line, comes every 15 minutes, pick it up on 4th and Lavaca. But at best, I am an armchair enthusiast. So thankfully, I have a friend who is a civil engineer. And not only is she a civil engineer, but this is her specialty. If you've ridden any light rail system, subway line, street car that was built in North America in the last 15 years, there's a really good chance you wrote something that Carla worked on. So I posed this question to her and I had her help me navigate the trends in public infrastructure planning and the research about what makes public infrastructure changes effective. And as we were going through this, there were four lessons that really stood out to me that I think apply to open source software. So for the first one, I wanna take you to Cincinnati, Ohio. Oh, someone's from Cincinnati, all right. Ah, all right. Well, we're gonna talk about your transit system, sir. All right, so Cincinnati, Ohio, they said, you know, we need more transit. And this was a time where light rail street cars were becoming a really popular option. A lot of kind of emerging cities of Cincinnati size were adopting these. So I said, yeah, you know, Cincinnati needs a light rail system. And with that, the project was born. They built out the tracks, they built out the route, like any good public project, it got a little bit of a budget cut. But the residents and businesses of that first route, they're kind of like, I'm not bought into this, I'm not so sure. And so like good project planners, they said, all right, let's push it over here. We're gonna go through an area where people will be more open to our ideas, it will be cheaper to permit and construct. And so they did. And they did successfully build a light rail system for Cincinnati. The problem with this big, flashy infrastructure improvement was that it was not well utilized. The planners and the city got really excited about implementing this more modern solution. They really wanted light rail. And they forgot to listen to the problem that was actually at hand, which was that people wanted a way to get from downtown to the hospital, to the university. That was really the issue. And I think this is, in some ways, it's program management 101, product management 101, but when we have this high peak of funding and momentum and excitement, it's like, yes, that thing, I've idea I've had in the back of my mind, this is my time. And sometimes we lose sight of what the original problem was that we're here to solve. So I think we can probably relate to, right now in open source security, the funding, the momentum, look at the show floor this whole week, like this is our time. Lesson number one is to not lose sight of what that need is. This is the time to try new ideas, to try creative things, but if it's not working, remember what the problem we're trying to solve is. For the second lesson, I wanna talk about big projects. If you've been on, you know, you're driving in your car and you have the sign flipper, there's orange cones everywhere, there's just construction happening like mad, that's what we typically refer to as a mega project. And mega projects are years in the making. There's surveys, there's designs, there's studies of the design, and then finally, there's implementation. And so if our original goal was to get someone from point A to point B, it might be multiple years before the first person makes that journey. And by the time that happens, point B might not be the desirable destination. People might say, hey, I actually really, four years later, I wanna go to point C, or maybe we built a street car and the 90s are back, rollerblading is back in, the rail was, a trail was the right choice, it's no longer the street car. So in planning, there's a movement right now to get away from this mega project implementation style. Because of that risk of that, we roll it out and no longer solves the problem at hand. I think this is really relevant for us because we are looking at essentially mega projects. We're talking about this week, like things like changing vulnerability schemas overhauling CVE, these are significant. So we wanna think about, as we roll these things out, how can they be rolled out in ways that are barring from this new movement to call small risk projects. We wanna roll things out in ways where they can be reversed, if it's not successful, rolled out in ways where our late adopters come along, we realize the majority of adopters aren't served by this. We wanna change the implementation, we get new information. Public infrastructure is moving to the small risk implementation model and I think we have a lot to learn from them. And of course, with all the things we're talking about, we have to talk about scale. So I wanna talk about the US highway system. The US highway system was born in its origins of a good problem. We need to move people and goods quickly between distant points, and thus the highway was born. And then we got more people and more goods and more distant points. And so we said more highway. And then as those highways got full of people and goods, we added more lanes. Well, kind of a funny thing happened. We didn't start measuring the scaling out of this solution for a while, because it worked, where cargo went where it needed to and once we start measuring it about 50 years later, we found out surprise, highways do a really funny thing at scale. We're actually adding lanes and new highways increases congestion. They call it this law of if you build it, they will drive. And it kind of caught the planning and group by surprise that this happened because it worked at a small scale. Why didn't it work at this larger scale? And now we have our highway systems that in some parts of the country of the US, they're very underutilized in more kind of metro areas. It's just very aggressive congestion. So lesson number three with obviously when we're talking about things like, what did GitHub say in their report last, your universe report last year that 60 million repos were created in a single year or something like that, scale is going to be relevant to us. And I'm gonna say that lesson three is to really challenge our assumptions as we're scaling these things out. What worked for 10 projects, 100, 1,000, we're gonna have to keep just adding zeros to reach the scale of open source. At each of these stages, we wanna challenge our assumptions about our solution, reevaluate if it's still working and make sure that when we take a holistic perspective, there aren't unintended consequences of what we're doing. Which brings me to my fourth lesson. We're gonna talk about a German planning proverb, organization before electronic, before concrete. So what this is, is the idea that in organization, relatively speaking, the people parts, it is cheap and malleable to move around to change. Anybody who's been reorg to multiple times in one quarter probably says, yeah, I feel cheap and malleable. But you know, when we compare it to things like installing electronics, slightly more expensive, and then pouring concrete, that is the most expensive and is the least malleable. That's really where we can't change things. And we think about this, you know, in organization, if that operates the transit system, if they're not functional, if the network that connects all these bits and pieces isn't there, then our concrete that we've poured, the technical solution we've implemented, it's not gonna work. For open source, obviously, there's a massive human element here, like how fun has it been to be in the hallways to see each other again. Open source has a huge human element. We have all these different parties of maintainers and users, companies that are building on open source. And we wanna make sure not only are those relationships there, but that there's adequate and effective incentives for all of these parties involved. Kind of like the electronics then, we wanna have connections between all these groups. We need sharing of information, communication. We need that connection there. And then, and only then will all those technical solutions that we're gonna be talking about over the next two days be able to be effective. So I know these are abstract, they're philosophical, they're kind of big and lofty, but my goal was just to give you a framework to think about over the next two days. Building for the need, not the what. Implementing things in small risk ways. Challenging our assumptions when it's time to scale. And making sure that the human elements and connections are there that underlie the technical solutions we wanna bring to open source. So I just want you to kind of have that marinade over you like a Texas barbecue. Just let it sit as you hear all your colleagues talking about their different proposals. And I'm looking forward to these four day hours of discussion. So thank you for having me and thank you for caring about open source. HDMI, so HDMI's right here. All right, so can you all hear me in the back? Excellent. So first, welcome everyone. If you are here, I know many of you already have a deep understanding of some of the material that you'll see here, but we often don't get to see it from the end point of somebody who's working in a end user perspective. And we also will often hyper focus on the things that we're working on. And we often forget to like bring our head above water and to look around and see exactly where we're at. So hopefully this will help with a reset for some of this to see like, hey, where are we and where are we going? So we start, one of the things that I've been promoting recently was a book by Mike Purcell, Trust and Computing Systems. He describes what trust is. And these three concepts, things are time dependent. So there is a time that you trust that something is going to happen. You can see this with S-bombs. How long do you trust the things that the S-bomb describes? They're asymmetrical in that the way that you trust a bank is different from how the bank trusts you. They're also contextual in that you trust them in a specific context. You don't trust them implicitly across everything. So I want to start with this as a definition because you'll be able to weave this into not only this presentation but also future things that you work on that when you're trying to reason about trust. In order to really understand where we're going and how we think of it from a end user perspective though, we have to think about it from an economics perspective. Every action we take has a risk and a reward. From a risk perspective, if you're the defender, you have risk for the operations that you're doing. The reward is a successful business operation that ends up bringing more funding to the company or ends up with your team being successful in whatever action that you need to take. If you are from an attacker's perspective, the risk is we get caught, we get shunted out of the system. Maybe we get caught by the legal system and you get put in prison. The reward could be financial, often it usually is financial, could also be something related towards your reputation that you'll be able to drive that into or the reward could also be we get a foothold that we can use to perform bigger attacks. So there is a risk and reward aspect to each of these and so we should start thinking, if you're in a defensive side, you need to start thinking what does the attacker want? What actually drives, what motivates the attacker? Like what is the reward that they're getting? What is their risk? What is the opportunity cost? If they're focusing on you, that's time to not spending on someone else or vice versa. Even advanced persistent threats that we talk about, we say, oh unlimited money, unlimited resources, well no, they actually have limits on what they can do as well. Granted, their limits tend to be very high. They appear to be unlimited to us from our smaller perspective, but even they have limited resources. So time that they're spending on you or time they're spending on a specific attack means that that is time that they're not able to spend on another one and time is often a factor, especially if it's a geopolitical reason why the attack is occurring. You'll see the attack occur in that context and once that reason is gone, then at that time you may see changes in how the attacks occur. As a defender, we're asking ourselves, what is the value of the thing I'm protecting? What is the likeliness that something will be attacked? What is the value, how much value is lost if the incidents occur? So there's a whole field on this in qualitative analysis on what is the cost of what we're defending and how we're defending and how much should we spend on it in order to move towards this. You often see, I won't spend too much time on these ones because not enough time, but you often see these type of things like single loss expectancy, if an attack occurs and it's successful, how much do we lose? What over a period of time, based on the annual rate of occurrence, how much do we expect to lose over a extended period of time? Usually they measure by a year when you talk about this. Interestingly, you could have a fractional of this, like if you have a flood that occurs once every 10 years, then your annual rate of occurrence is 0.1. The residual value is positive if you're making a profit, is negative if you're spending more money than the value of whatever it is you're doing. So you often see these tied into it and the larger organizations literally have teams of people who they get certified in this type of work and they try to work out these type of numbers so they can help the company make qualitative and quantitative decisions. So you want to use both of them together. Again, you can ask this question, what is the cost of all this in relation to the log for Shell? It was quite immense off of that one bug. So in this scenario, the economic forces matter, so you want to think about it from both the attackers and defender side because any amount of money that you spend or any resources you put on is going to have a different, you're going to affect how the attacker approaches you and you're going to affect how they end up interacting with your system and anything that we can do to shift to the economics where you have a higher risk and a lower reward is going to have an impact on how the attackers end up looking at your system. So in short, do everything that you ethically and morally can to shift the economics equation in your favor. With that, let's talk about this in the context of software build materials. So I'll start with a question. With great power comes great responsibility. How many of you, when I say this, think Spider-Man? So a good portion of you. This phrase actually was initially coined in this framing with by Voltaire and then was brought into popularity in Western culture through Spider-Man. And interestingly, I had a conversation with somebody yesterday who said Spider-Man and when I told him about Voltaire, he said, I knew this, but I still said Spider-Man. So it's really ingrained in us. And well, a similar question. Where did your regex library come from? And how many of you would say Debian or Red Hat or similar would say it comes from the repository that I'm pulling it from? The answer is there's actually an individual here named Phillip Hazel, who's also the creator of the XM mail server. But there's a specific individual, almost 1200 commits. The next number two committer has 21 commits. And this is one of the most downloaded package on the Debian. They're in the top 50, last I checked. Thank you for Santiago for pointing that out to me that this particular individual. I did a little bit more digging. And what about PCR3? So how many of you would prefer to use PCR3 over PCR2? I mean, that's a higher number, number three, right? Turns out that on Debian, so PCR3 has more downloads than PCR2, because everyone is thinking the same way. But it specifically states, if you look at the documentation, new packages to use, newer PCR2 packages, and existing packages should migrate to PCR2 as well. So these type of things, we don't tend to think of them in that particular way, but the way that we frame, the way we version, our developers, our operators, like they have to make decisions very quickly. So anything you can do to frame to automate that particular path is gonna make it a lot easier for them to reason about it. So in short, a software bill of materials is this set of questions. Who built it? Who provided it? What's in a given software package? These are some of the minimum elements that you may see. Ideally, they also include what dependencies recursively are there as well. They don't explain how the package was built, but there are systems there in total that will help with that. So you can describe how something was built out. But there's a modeling gap we have here. The modeling gap is that S-bombs are static, so we produce them at build time usually, where you'll do a post-build scan. The vulnerabilities are dynamic, so we generate the S-bombs. Vulnerabilities come out after the fact, and so we don't wanna conflate the two of them. We have static information for static S-bombs. So CVs definitely help here. We wanna use the S-bombs as the key into CVs, so we can say this S-bombs has these vulnerabilities attached to it. We wanna be able to automate this path because that lowers, again, economics, lowers the cost to us and increases the cost to the attacker because we're able to remediate issues quicker. So with this, are we done? Not quite, because it doesn't say everything about the vulnerability. There's a really great example with lip curl, where if you're using a specific original lip curl, I have numbers on here, you can look it up. If you're using secure TFTP, then you are vulnerable to a significant attack where I believe it causes the loss where the attacker can work out your private key. If and only if you're using TFTP. And so, most people are not using curl for TFTP, they're using it for HTTPS or similar protocols. So most users are not affected by this. In a large organization, when you see this kind of thing pop up on your vulnerability dashboard and all you see is, and I'm not sure what the score of this one is, but it was pretty high, when you see somebody say 9.5, you're like, okay, let's go ahead and hit the stop button, let's get everything rolled out because this needs to get fixed now. But this ends up reducing, because of opportunity costs, we end up spending more time on this than on things that actually would have moved the needle, because from an operational perspective, it's not easy to put the links together to see that these things are all correlating and how they are. There is a system designed to help with this, with, and I'll skip this particular slide because it's not as important, but there's a system designed to help with this called VEX. Tomorrow at noon, I think in this room, Dr. Allen Friedman will talk about it, and so if you're interested in this specific topic, you will see it in depth tomorrow. But VEX is designed specifically to tell not if you're vulnerable to it, because in the case of Curl, yes, you're vulnerable to it, even if you're, the question is, are you affected by it? So you may have vulnerabilities that are there, but you're not affected because they've been cauterized, they've been, you're not using it, you've disabled the feature, and so you still have to patch it at some time, but that might not be a priority. You might prioritize something else that actually is impacting at that time. So the ability to prioritize is a major feature that all of the work we're doing here will help with. Again, it moves the needle economically. So to recap, S-bombs tell you what's in your infrastructure, CVs tell you the vulnerabilities that are in your environment, VEX tell you which vulnerabilities you are affected by. So these three questions is put in a nutshell. So with that, again, why does all this matter? We want to determine the state of the system, we want to be able to determine our actions, we want to be able to prioritize those actions more effectively, and also make predictions of how those actions in the long-term will affect the future state of our infrastructure and repeat it all with automation. Your spider sense should go off when you say with zero trust, because what is zero trust? So what end up, part of what we want to do is we want to say in a workload, we're in a dynamic environment, we're actually shipping things now, we want to say where did this workload come from? Does it meet our company policy? What about the policy? Was the policy approved? Did the policy come from where we think it came from? Is the policy still valid? Again, remember time when we talk about what is trust. We also want to control over it. How do we automate? Did the platform do what we think it did? What state is it in? Can I prove that the platform is in that state? So when we look in the context of S-bombs and CVEs and VEX, there's a couple of areas we can focus on. One of the areas that I think is more effective is to initially start out the identity phase. The workload starts, at that point, there is some form of cryptographic identity that is issued. So if you're using any of the service meshes or if you're using Spitfire or numerous other products, they start with a cryptographic identity for the workload. There is an initial time where you check and you say, is this system meeting the policy we need? You issue out the identity. But it doesn't stop there. Every so often, usually half an hour to an hour, there is a time where you have to reissue the identity out because that identity has kept the very short lived. So when you reissue it that out, you ask the exact same question. Is it running on a system that I trust? Challenged by the TPM? Is it running the Docker image that I think it should be running based upon what the workload is supposed to be doing, et cetera, et cetera? And only if it continues to match your policies, which include looking up the CVEs. You should be comparing that to the VEX statements on a continuous basis. You should be analyzing for anomalies. You should be looking for misconfigurations, which VEX can help you there because it also has a mitigation where, like in the case of log for shell, you might say you have the JNDI disabled as a configuration option. So you have a misconfiguration there if it's enabled. And you make a decision on whether it meets your policy or not, and you make a decision, do you allow it? Do you audit it? So you allow it, but put a report onto the cybersecurity teams dashboard, or do you reject it? And of course, record the rejection. So all of this ties back to the original premise of what is the value of what we're protecting? What is the cost of what we're protecting? A lot of this will increase your initial at CAPEX, but in its mature form should decrease the total OPEX in a meaningful way. While giving us more capabilities. And we can not achieve these goals of actually defending our systems without getting the fundamentals right. SBOM, CV, and VEX provide a basis for automating the vulnerability management of those fundamentals. And there's one last question. How do we do this at scale? Which is not something I'm gonna talk about right now, because right now we're still working on the fundamentals, like the data plane layer of like how do we get things done? This is gonna be one of the big questions that comes up because if you're at a small company and you have like one cluster with a few pods, it's you can do this manually. You don't need a lot of this automation. If you're running a massive multinational organization with thousands of applications, and then at that point, all of this automation becomes the basis for that scale. And there's a lot of work that we have to get done in order to achieve that. So in short, I wanna thank you all and I'll be around if there's any questions.