Eric Brewer and the Future of Open Source Security  ## Metadata - Author: [[What's in the SOSS? An OpenSSF Podcast]] - Full Title: Eric Brewer and the Future of Open Source Security - Category: #podcasts - URL: https://share.snipd.com/episode/6de2bf26-5424-4b8d-b165-a0417394144c ## Document Notes ## Highlights - **Kubernetes Supply Chain Wake-Up** - Eric Brewer noticed Kubernetes depended on many untrustworthy dependencies in 2018. - He realized the issue was broader, identifying it as a supply chain problem, prompting internal talks on security. Transcript: Speaker 1 Came to realize in around 2018 that this was obviously a successful project. There's also a very complicated time. It had like 1200 dependencies, so it touched a whole bunch of code and that you just look around. It wasn't hard to find things that we depended on, but realistically, it weren't all that trustworthy. And people were not very careful at the time about what kinds of things got included or how they would get used. And so that was a bit of a wake up call for me. Then I started to look at a whole bunch of other things. I'm like, well, this is not just a dependency problem. It's actually a supply chain problem more broadly. I started giving internal talks on supply chain security, which by the way, that term didn't exist at the time either. We didn't really call it that. It's the right term. But how do we build our software? Why do we know it's built correctly? And especially the time, lots of times people would include packages directly off the internet. You don't even know what's in there. Friend Kelsey Hightower often said it's kind of like picking up a USB drive off the street, sticking at your laptop. It's like, everyone knows not to do that, but we don't know not to take a random package off the internet, even though it's a very apt analogy. I started thinking about that 2018. Started thinking about what Google could do, but at the end of the day, this is not a Google problem. ([Time 0:01:18](https://share.snipd.com/snip/e62b6091-3dec-4e45-87bb-20e108cb5b65)) - **Security: Corporate vs Open Source** - Corporate environments can control code and use private copies for security. - Open source maintainers face challenges using direct internet dependencies and paying for secure builds. Transcript: Speaker 2 Can you speak to the differences in how you would improve security in a corporate environment, like when you're shipping code at Google, versus what's possible in an open source project? Speaker 1 They are pretty different, which is something I hope to change eventually. I give lots of talks at Google Cloud customers on this kind of topic for the corporate view at least, which is roughly half-controlled code you're using, which often means private copies Of things. The private copies give you two advantages. One is you're not taking it except directly off the internet, even if it became indirectly from the internet. Second, when you have some kind of problem, you actually know exactly what code you used, because another problem points to the internet is that code changes and you may not know which Version you have or when it was pulled. And so you may not even know exactly what you're running. So there's some basic things like know the code you're using, and then of course the next big one after that is use a build service, right? You're not allowed to build production code on your laptop because that device is probably, in most cases, not trustworthy for its supply chain attributes. And so those are two basic examples of things that corporations can easily do and should be expected to do. Open source maintainers don't have it so easy. For example, clearly they're going to use dependencies off the internet. They're not going to have a private copy of all the dependencies that kind of misses the point. And they typically have to build and test packages at their own expense using whatever means they have. So to ask them to pay for a build service to do that is pretty unreasonable. And in fact, one of the things I'm looking at is how we could maybe build or re-build packages in a secure, signed way for free for open source maintainers. Maybe not all the time, but when you want to do a major release or something like that. So unclear where that will go. But there is plenty we could do to make it easier to be a maintainer for open source package, especially when this critical to the rest of the world. ([Time 0:03:04](https://share.snipd.com/snip/285e78df-f1d3-4078-b52f-7a4282b443ed)) - **Know Critical Projects' Role** - Improve software repositories by knowing which projects are critical infrastructure. - Distinguish projects that commit to security in critical infrastructure from those meant for fun or exploration. Transcript: Speaker 2 That sounds like some great accomplishments that we've had and completely agree with you. Let's move now to talk a little bit about the watering holes of our community, the software repositories, the package repose. Can you talk a little bit about how improving the security around those software repositories can help improve the security of open source software in general? Speaker 1 Those are critical, critical components. Now, source code, these cases mostly in GitHub and that does help in the sense that GitHub is at least a group that cares about improve the security issues. I thank them for that. Package managers are more complicated because there's many of them and each ecosystem has its own culture and philosophy around these things. We're not going to have some universal agreement on exactly how to do supply chain security. I think we can agree in some basic things. You would like to know which of your critical projects and which are not. We're not trying to improve or maybe raise the security ([Time 0:06:56](https://share.snipd.com/snip/1845ed60-b239-4141-b991-f4ff7ac4ff4c)) - **Build Services and Testing Challenge** - The next hurdle is funding build services and automated testing for open source. - Without these, it's hard to quickly fix security bugs and know if changes break users. Transcript: Speaker 2 That dependency graph can be very interesting. Look at ahead. What do you see as the next big hurdle in open source security and what can we do about it? It's a great question. Speaker 1 We've done a lot of focus recently on package managers and S-bomb generation. We're still planning to do there. I do think we need to start tackling build services and automated testing. And the reason these are harder is because they cost money. Even if you're willing to volunteer time to work on open source, you may not be willing to pay for extensive building and testing. How that gets paid for is, I think, one of the great open questions that we need to sort out the next several years. The point, though, is that we can't really quickly fix security bugs today in part because we don't know when you make a change to an open source package, if it's going to break users of That package or not. Right. So there's some uncertainty about even pure security changes about what impact they might have on the rest of the ecosystem. Now, the good news is most of the time these changes are small and most of the time they don't break the ecosystem. But we don't really know because we don't have that many test cases. And in general, we don't have test cases for all the dependents either. All the things that use log4j, they may not have test cases that can tell if the new version of log4j is going to break them or not. So we have to kind of put forward changes, hopefully they don't break stuff and cross our fingers. And that's not a great place to be. If we had more automated testing, more test cases, controlled builds, all those would improve our chance to deploy security patches quickly and effectively when the time came. So that is an important medium-term agenda, for sure. And this is a place where machine learning may be a great benefit because it looks like we've had some successful ready with generating test harnesses for fuzzing, improving test coverage. I think we can generate test cases or probably do more on the front of actually making simple patches easy for a maintainer to accept. So if I kept this patch to do a version bump to get the new log4j, these are mundane things. And if we can do mundane things automatically, that will save ([Time 0:08:49](https://share.snipd.com/snip/7563f12a-b01f-424a-874e-3482a319ba7f)) - **Boost Career with Open Source** - Use open source contributions to build and demonstrate your technical skills. - Engage with multiple projects to understand diverse cultures and improve your adaptability. Transcript: Speaker 2 You're very well regarded and have accomplished a number of things. What advice do you have for somebody that's entering our field today? Speaker 1 Well, the good news is I think open source is a great way to boost a career in computer science or tech more broadly. And it's amazing how often I've wanted hired people because of what I saw the right in open source. And I'm not saying that's an easy path, but boy, it is a good path because it's very clear to tell what you care about by what you choose to work on and how you can do it. And I can see the code you write, how you feel about lots of different topics, for example, tabs versus spaces, which not criteria I would use for hiring, but I might notice. So there's that role of open source, which is as a proving ground or a way to increase visibility. And by the way, if you're helping those projects, that's a great thing to do regardless of even if you're doing for reasons to get exposure to learn about a project or space. The second thing I would say is that, you know, it's worth learning how to interact with many different projects. The easy thing to do is pick a project and work on it. And that's certainly value in that. But I also feel like I've learned more when I'm working on five or 10 different things at a time. They have slightly different cultures or different rules about what you do to submit code or readability, things like that. And those choices are worth understanding. And I'm not even saying that they're good or bad. The point is they are diverse and the communities are diverse. And it's much more important, I think, to be able to contribute to someone else's project than to your own project. Most of what the world needs is interconnections or projects and glue. And that is itself a scale that's worth a goire. Speaker 2 Completely agree. And the old adage, I suppose, holds up, which is ([Time 0:12:34](https://share.snipd.com/snip/4e2c3ee4-81f5-4828-8f5f-9deee40fc0f0)) - **Enhance Security in Communities** - Join language-based communities like Python or Rust to enhance security support. - Help with two-factor authentication, automation, or artifact verification to strengthen community security. Transcript: Speaker 2 What's your call to action for our listeners? It's a great question. I'm going to hand a little bit on the listeners. Speaker 1 But I think I would start with all the communities, typically based around languages, like Python or Rust. And what can you do to make your community have better support for security? And that can be all kinds of things. It can be two-factor authentication. It can be help with automation for S-bombs or for signing things correctly or being able to know for sure which source goes with a built artifact. There's so many things that communities can do and kind of need to do that that's an area of great need right now where they aren't hard things to do. They just need people to think about for their community, how do they want to solve it and then go do it. ([Time 0:14:43](https://share.snipd.com/snip/60fc72b4-4f3b-49cb-9572-6c3f1e6d4343))