 Hello, my name is David A. Wheeler, and I'm here to talk about securing open source. I hope to convince you about four key points, attacks, weakness, hope, change. Attacks, weakness, hope, change. What do I mean by that? Well, the first part, I hope you already are convinced of. Attackers are attacking systems. They're attacking those systems via the vulnerabilities that they have when they are deployed and also through their supply chains. Weakness. Sadly, those attackers are often succeeding. And this is primarily because current development and supply chain processes really often don't adequately counter-attacks. And even when they're fixed, they often don't get deployed in a timely way. But I don't want you to leave without hope. There is hope. There are counter-measures to attacks, and there's ongoing work to ease their deployment. For change. We need to change how we develop software, how we select it, how we deploy it. Things like making sure that things are secure by default, and we're going to need to continuously learn from adversaries and anticipate adversaries. I think that first point about softwares under attack is pretty obvious. These are just some logos and some indications of examples of software under attack. The top left symbol there is Heartbleed. But in fact, there's a whole bunch of different attacks and vulnerabilities. But of course, repositories have been under attack. The more recent SolarWinds Orion subversion was caused through a subverted build environment. It didn't matter what the software developers wrote because the code they wrote wasn't what was going to be used for shipping. There's an interesting paper called the Backstabbers Knife Collection that reviewed over 174 supply chain attacks, found a dominance of type of squatting attacks, for example. And a good part of this problem is that most projects and organizations simply cannot accurately summarize what software is within their system. And some of you may say, oh, hey, we use cloud, therefore somehow we're immune to all this. And of course, that's ridiculous. Dan Lawrence has this interesting article where he notes that today's cloud infrastructure is still being built out of duct tape and kite strings. So he played around with Helm 3. He looked at a particular Helm chart and tried to answer what you think would be simple questions. So what software was installed, where did it come from, how was it built, and he could not answer those questions. And as a result, he made some interesting observations. One of course is if you think your container scanning setup is catching everything, think again, he found 25 vulnerabilities in just that one package. And he noted that, hey, package managers add convenience, but every layer adds trust and I would also add adds time. It can take a long time for a vulnerability that's been fixed to get through all those layers. So I think it's helpful to think about how is software developed? So this is a simple model of software supply chain called a supply chain integrity map. You can see it's a simple map, what goes on. Developers work within their local environments, then send their changes and so on off to source and data repositories. Then that software gets built and verified. Eventually it's approved for release to be sent out to various package repositories and distribution platforms. Hopefully that's assessed in various ways, both the builds and the eventual packages. Finally, people select and acquire them and then bring them into their environments to go through the cycle all again. And eventually things get deployed out to operations and of course there are cycles here because smaller components get brought into larger components, which get into larger components. But of course, if you look at this from the point of view of an attacker, that's a system. And systems can be attacked and a great way to learn how to attack them is to look at those parts and see how those various parts of the system can be attacked. And these red squares are just sample kinds of attacks and there's a lot of them. Typosquadding, which is basically confusing to acquirers and developers into thinking they're installing one package when they're installing another. Dependency confusion where they think the software is coming from one repository but it's actually coming from another. There's malicious software, there's all sorts of vulnerabilities that go in as part of developments and there's a whole host of problems. But I don't want you to leave with, oh my gosh, there's so many problems. Because in fact, there are countermeasures. And these are again just a sample of countermeasures, various approaches where you can do various things to counter some of those attacks. I certainly can't talk about all of them. But a trivial one I'll note, for example, is one of the big problems right now is developers often don't understand a lot of things. Nobody teaches them in classes. And so a little education and training can go a long way. And of course, that's not enough. There's various tools you can add to say the build verification processes and so on to really help. There's no silver bullet. There is no one thing. If you do the one thing, congratulations, you have solved all problems. That's not how it works. Instead, you need to bring a variety of approaches to bear to counter the different kinds of attacks that attackers can do. So what can open source software developers and users do? Well, if you're not already doing these already, here's some first starting steps. You'll learn how to develop and acquire secure software. If nothing else, take a look at the secure software development fundamentals course. It's free. So on edX, go take it. There's others. Take those. But learn how to do this stuff. Make the software secure by default. Make it easy to use securely. Harden it up against attacks. If you're doing open source software development, work to earn an open source, I'm sorry, a CIFS practices batch. There's the URL. Use many tools to find vulnerabilities in your build and verification environment. No, tools will not find everything, but they're helpful as part of a solution. Of course, monitor for known vulnerabilities in whatever you depend on so that you can immediately respond and immediately update. Of course, in order to do that rapid update, you need to use package managers and automated tools so that you can rapidly respond when a vulnerability is found. And I mentioned these tests, those need to include negative tests. In other words, there are some things that should not be allowed. Test for that. Make sure they stay not allowed. This is something that people often forget, particularly if they're using TDD. Finally, evaluate software before you select it. Look for typosquadding. Is that really the right name? Is that software malicious? Do you have reason to believe it's secure? And when you're evaluating, here are some sample things to consider. Is it easy to use securely? Is there evidence that developers work to make it secure? Is it maintained? Has significant use? What's the license? If it has not an open source license? Shockingly, it's not going to be collaboratively developed like an open source project. If it's important, what is your own evaluation of it? And the good news is lots of folks are working to make things better. The OpenSSF, for example, Open Source Security Foundation, is working on this. There's a number of other projects here. In fact, this is a short list. There's many more projects and foundations and organizations working to make things better. So, if you are an open source software developer user, you need to do all those things I mentioned earlier, but you also need to prep for the future. Here's some things that I see coming down the pike. You need to start being prepared to generate and request software build materials. There's a lot of pressure in even high levels of government and so on, to start saying, we need to know what's in our software, and we need to be prepared to answer that question. It's a reasonable question. Look for more information about the software before you select it. There's organizations like those within the OpenSSF that are working to improve information about the software, that you're to improve information about the software, so you can have better information when you select it. I think verified reproducible builds are important. That's particularly useful for countering subverted builds. Improve cryptographic signature verification. We've had this for a long time, but it's challenging to do verification. I think Sigstore has a lot of promise, but we'll see. But no matter what, I think this is something we need to see more of. More generally, integrity attestation approaches like in Toto, and increasing use of memory safe and more generally safe languages. More broadly, working with others to help make things better. There's a lot of opportunity, and frankly, there are folks who could really use your help to speed these up. So let me do a quick recap. I came and said there are four key points I wanted to talk about. Attacks, weakness, hope, change. I hope that you'll see that it's, yes, there are attacks, and yes, there's weakness, but there is hope, but we'll need to change to take advantage of that hope. A quick parting thought, developing and deploying secure software is a journey of learning and improving. It's not a single event, but that's okay. We just need to get started. Thank you very much for your time.