 Thank you very much. It's so exciting to be here. There's so much gratitude and really depth that we owe to the cloud native community at the Open Source Security Foundation. And just really happy to be talking with you about a little bit about what we're doing. But I actually wanted to start out a bit with the kinds of things that we want to be thinking about next. Because so often, we're fixing security holes today that reflect attacks that have been kind of pervasive on the internet since time immemorial. But I want to try to set a context for how do we prepare for things that are coming up. And so pardon me if this seems like a little bit of a late night brainstorm using chat GPT and Google Image Search, but hopefully you'll forgive me. So in the early days, and you can tell this is a slide about the past because there's a CRT on the counter there. Does anyone remember Telnet? I don't think anyone born after 1980 has ever typed the letters Telnet unless you were doing something really weird. But I wrote a whole chat system of it where Telnet was the client. It was awesome, right? And you could go from one machine to another. You could pretend to be a mail server, that kind of thing. But we kind of just took for granted that the systems administrators and the network admins and others weren't going to be sniffing our packets. Because why bother? Well, there's nothing interesting going over this traffic anyways. SMTP was not secure by default when it first came out, right? All these different protocols, we kind of took for granted that we could trust a certain layer of the internet or the people that ran certain layers below us so that we could move more quickly, so that we could build the kinds of things we wanted to build. But those kinds of decisions left to future generations kind of patching up those assumptions and defaults and biases. It was great that we were able to move quickly, but the internet was kind of like, didn't have security by default for a long time. I mean, arguably it still doesn't either, right? But it took us a while. Now, in our defense, one of the things that kept us from pervasively adding public key cryptography to all of our network connections and the like was the fact that public key cryptography was considered a munition by the US government. It was considered a weapon, a dual use technology that was regulated. And the only way that you could transport, that you could send a software package that talked public key cryptography protocols that used more than 40 bits of entropy was to do that, was to limit it to 40 bits or 128 if you got special prims or whatever. That meant that you couldn't ship source code. You could not, because source code meant you could use arbitrary length keys. Now in 99, there was a court case that was decided called the Bernstein case that the Apache Software Foundation submitted an amicus brief to that actually stipulated that software development is a function of speech rather than a function of commerce. And that researchers at the very least needed the ability to talk about cryptography publicly. It also helped that people took RSA and reduced it to like four lines of pearl and printed it on the back of t-shirts and wore them as they crossed borders. That was kind of fun. But we made this case and we won. And we won the argument that basically public key cryptography should be widely available to help us bootstrap and get moved beyond this default bias that we couldn't have cryptography on the lower levels of the internet. And that was pretty useful. That was a pretty nice thing to be able to assume. But that only stripped away one layer of the onion and we realized there were a whole lot more places where we had some default assumptions that would later come to bite us in the ass. Now this is Dan Kaminsky who passed away sadly a few years ago. Dan is probably the only person that I would ever credit with having saved the internet just like unquestionably. Dan discovered a bug in Bind. Now it was more of a protocol bug in the DNS protocols, frankly, that allowed for something called DNS cache poisoning which meant preemptively an attacker could tell a DNS server, Google.com doesn't actually go to one IP address, it goes to another. And that meant that even with all the other work we did, if you could corrupt all these DNS caches out there, you could direct traffic wherever you wanted and use that to steal credentials, use that to steal other kinds of traffic. And the problem was it was such a trivially easy bug to exploit that if now I'm a big believer in security through transparency and trying to be public about flaws and that kind of thing, so that as a means to get them fixed faster. But he kind of realized as a bunch of people did when he started to talk with them that the more this would be known before it was fixed, the more likely that the entire internet would really come down. I mean, if you bring down DNS, where else do you bootstrap from? I mean, we would have had to use Etsy host files with IP addresses shared over billboards or something like that in order to bootstrap back up and get to a usable internet again. And so he worked very stealthily but very determinately with a whole set of the main DNS admins, the upstream kind of a root DNS server, sorry, and others to get patches to software to get protocol changes where necessary to basically get to the point where DNS responses were verifiable and eliminated that bug and it had to be quiet, but it got out there and it got updated. And so, you know, transport layer security, you know, DNS layer security, there's all these places where there's this technical debt that we accumulate as developers and as protocol designers and as people out there in the world building upon it. Now, let's give ourselves a little bit of credit here. Every project bootstraps by taking a few things for granted. Otherwise, I mean, you can't boil the ocean, you can't solve the world's problems, you have to start somewhere, you have to decide who you're going to trust, right? You have to decide how you're going to get to rough consensus and running code quickly enough before your boss cancels your project or your grant money runs out or other things before you're able to prove, hey, we've got something. But those decisions, those biases create technical debt. And often those assumptions and biases are never well documented, they're not issues in an issue tracker, they're not left as things to do, they're left as things for people to take up and try to fix after the fact. An example of this is there's a company called Trellix that announced last week, two weeks ago, it was January 23rd, that they had automatically submitted pull requests against 61,000 vulnerable open source projects that had adopted a CPython actually module called tarfile that had a CVE from 2007 in it that was not fixed because the tarfile maintainers, actually the CPython maintainers contend that to fix it in a way that solve this problem would break POSIX compliance. Okay, so this debate from like 2007, but because it was unresolved because the issue on it, comments go back 10 years, it's hilarious. Because these weren't 15 years, sorry, because this wasn't fixed, thousands of projects picked this up and have used it in an unsafe way without validating inputs to make sure that expanding a tarfile didn't override Etsy password. And because of that, it was easy to scan, easy to find these projects that were using it in an unsafe way, easy even to come up with fixes for that and submit pull requests that fix it. Now, Trellix, I think has done those 61,000 projects a favor, but I think they're gonna be lucky if 15% of those projects even respond based on the work that folks like Jonathan Leachu, who gave a talk about automated pull requests and fixing bugs at scale at DEFCON last year, his experiences in doing the same kinds of things, identifying patterns, identifying old bugs that need to go back and be fixed. It is extraordinarily hard and frankly, for good reason, maintainers hate it when you show up and say, my scanning tool found a bunch of worrisome things in your code, right? So we've gotta figure out how to get better at doing this and how to go back and fix some of these low-level assumptions that are being made. Now, thank you, Priyanko, for mentioning Sigstore. Thanks to all of you who are using Sigstore, who are helping develop it, who are pushing it forward and helping establish it as a standard for assigning artifacts in the software supply chain. But frankly, signatures on objects as they flow through the chain and in our dependencies should have been a problem we solved in 2005, 2007, and we solved it somewhat. Most people solved it at the last mile with signatures and apt-get and that kind of thing. But further up the chain, we kind of took for granted that if something was on an HTTPS website, a module there claiming to be a build of source code over here at this repo, then we could trust it, right? And that again, that default assumption, that default trust is really dangerous to have. Now, what are some of the bad patterns we're still persisting today? Well, I know some of you just wanna see the world burn, but when you tell your users, you know, curl, URL, pipe to sudo sh, you're kind of doing the same thing. I mean, your argument might be, well, apt-get is just the same thing. You can run a post-install script that compromises systems and everything should be in containers anyways, right? But that cynicism about being able to build better, more resilient systems is kind of out there. I mean, even a dark pattern, like choosing which package to use based on the number of stars on GitHub is worrisome, right? Like there should be other data you use to figure out which packages to use and which to build because there's this thing called time that works against us in so many ways. And these are just some general principles, again, two in the morning grain storm. Apologize for that. But there is really no such thing as true zero trust architecture. There's defaults, assumptions, biases, and things we build on top of for better and for worse that we have to take for granted, right? You can take for granted that, if you took the subway here or a taxi here, that it's, the wheels don't come off at the wrong time. And it might once in a billion times, but you're able to take for granted that that system works, right? So it's not a flaw that we take things for granted, but we just have to continually interrogate the attack surface on the trust decisions that we make, right? Attacks we think are hard to exploit but also get easier over time. This is kind of the chat GPT thing as well, right? This is the, hey, it used to be hard to write a lot of meaningless texts that looked good, kind of mansplaining as a service is the term I like to use. But now it's actually trivially easy to do that and even just script that into processes. My other favorite example of this is side channel attacks, like the fact that you could try to divine a private key based on the timing of a CPU that's generating that, like what the fuck, that's magic. But a second principle and the second way the time works against us is that things that we think are, or norms, things that we think people would be embarrassed by, like who would possibly tell that to port 25 and send mail from president at whitehouse.gov while I did that as a college freshman. Somebody will eventually do that. And if your theory of stability rests upon social norms, that's fragile. That's super fragile when you get to the number of users beyond Dunbar's number and personalities stop being a useful check on security. And then finally, software deserves to have, should have an expiration date. It really, you know, there should, we should assume software falls apart, that software suffers from bit rot in unusual ways. That, you know how depreciation works, you get to write off a computer asset over three years or five years, whatever. Well, I think you should write off software that's been written and pass three or five years, take it from like a positive asset to a liability, right? That you try to get off your books because we have no other great way to measure technical debt except, hey, this stuff is really old and I don't care if it still works, it's still a risk. So putting these things together, and I swear chat GPT did not require me to put this slide in here. I came up with this all on my own. But let's think about ways that new tools like chat GPT and AI tools in general might generate new kinds of attacks on these things that we take for granted. I mean, first off, automating spear phishing attacks on open source projects themselves, using AI generated pull requests or comments and threads or that kind of thing has gone a lot from being like, that's sci-fi, that's Corey Dockrow territory too. No, no, this is going to happen this year, I'm sure, absolutely. Along similar lines, I'll come back to the corrupted AI models in a bit, AI generated pull requests that are just right and just wrong enough to DDoS teams, upstream teams to slow or stop the reaction when a real zero day is reported would be a really big risk. AI generated contributors who make automated like dock cleanups and things like that and then build up a reputation in your project. Maybe you didn't give them admin proofs, right? That is a risk as well. And then we know that AI models can be corrupted. This is a picture of a stop sign that some researchers were able to convince an AI to recognize as a speed limit 30 sign, which is a very different thing than intended. And think about ways that you might corrupt things like a co-pilot to make its recommendations lead to insecure software. A second attack service that I think is emerging is an identity and centrality. We've not solved the internet identity problem. This, by the way, is the other Brian Bellendorf. He's a maintainer on Open's DFS. He gets our name in the Linux kernel change logs. He's pretty cool, we've met, we've had pizza. He's a much better programmer than I ever have been or will be. But if you see my name, Brian Bellendorf, I know because I get a lot of support queries for Open's DFS that I forward on to the other Brian Bellendorf and it kind of freaks people out. But this kind of thing is real. The prospect of somebody showing up, pretending to be somebody else and being very convincing at it, I think would be a real big factor. There's a bunch of others, but the one I want to focus that's related to this is there's often these things that we take for granted like the accessibility of an NPM package repository or Apache.org when resolving DTBs. These kinds of things that we have to assume in this world, one in a couple of orders of magnitude times, those systems will be gone. We won't be able to access it. Your DNS will fail. And do you really want to limit your production, push to production, because some non-profit's website is down? I kind of don't think so. The third one I'd worry about are free writers and regulation. And this is kind of more nuanced and I think I can get out in the 20 seconds I have left. But as maintainers, we kind of take for granted that users are on their own and can be self-sufficient. And often we try to think about them. The better ones of us do think about how to pull people in and cross that bridge. But users also free ride on the assumption that as maintainers, we take security issues for granted. And the number of reported security vulnerabilities that don't get responded to might have maintainers in a reasonable amount of time. I mean, nobody's formally tracking this and frankly we probably should. And I think in between the two lies some risk. And that's risk that can be exploited by grifters and scammers and the like that I'm not quite sure exactly what those attacks are gonna be, but they're going to happen. The second category of this that I really wanna highlight is there are moves afoot at a regulatory level to respond to some of the free rider problems, some of these issues by putting more liability upon all of you as developers. The European Union's Cyber Resiliency Act has a whole bunch of worrisome kind of requirements that might fall on you if your software happens to be unlucky enough to be used in a European nuclear plant or by a transportation agency. This is worrisome and it could get us back to the bad old days of having to remember what country you're in to depend on whether I can ship code to you or not. The second wrong answer is to make developers personally liable for the use of their software for illegal purposes. Read up more on the tornado cash developer and what's happening there. These are not ways to solve the cybersecurity problem, but some of the tools will make the problems inherent in this so much more severe. So at OpenSSF, we've got a lot of activities going on, we're kind of a circus, it's really great, lots of different ways to tackle this, but we've organized ourselves around working groups in a thematic way that we think will prepare us to think holistically about many of these challenges, to think about vulnerability disclosure in a long-term way, like how do we write a tool to solve one problem or come up with a spec to solve another, but think holistically about the whole supply chain challenges? How do we think about digital identity and supply chain integrity? How do we think about all these different kinds of new forms of attack? We don't have a working group on AI yet, maybe ChatGPT will start one for us, but I think we're in a position to be well-prepared to be thinking about this next wave of attacks. And I just want to thank all of you again. OpenSSF happened because the cloud native community said, hey, there's a bunch of tools we should be building and brought those to the party and shipped code and shipping code is really all that matters. And for that, we have a debt of gratitude to many of you in this room and frankly to all of you who are using these tools now to validate your work. So thank you very much and have a great conference. Thank you. Thank you.