 All right, thank you so very much for joining us today. We're so glad to have you here at the Building Cyber Security into Supply Chain Town Hall. I'm just going to go ahead and get started. My name is David E. Wheeler. I am gonna talk a little bit about Supply Chain Security and then we've got a lot of really interesting presentations to get going. Jillian, did you want to do a quick logistics intro? Yep, that is being posted. And attendees can add questions into the Q&A and there's also an attendee chat that will be monitoring as well. Thank you so much, everyone. Yeah, thank you so much. All right, so in the interest, we've got a lot of interesting things and very little time. So don't mind, I'm just going to get started. Let's see here. Give me a moment to share my screen. Okay, so very good. So as I said, my name is David E. Wheeler. I'm actually the director of Open Source Supply Chain Security at the Linux Foundation. I'm gonna try to give a quick introduction. We've got a lot of interesting panels coming up, presentations coming up. So first of all, what's our focus here today? We're gonna talk about cybersecurity. We're gonna talk about Supply Chain. I just copied up a definition here about cybersecurity. It's basically from the phrase. It's security of cyber devices, cyber things. So what security, confidentiality, integrity, availability, no one authorized read, no one authorized change and that authorized access is actually work of what? Networks, devices, data. I think today we tend to de-emphasize networks because it's kind of hopeless in many, many cases to try to keep malicious devices off networks. Even if it wasn't originally malicious, if a device gets subverted, it becomes malicious. And so we're much more interested today in many circumstances, focusing on protection of devices and data. Supply Chain. I looked up in a dictionary. It said it was the sequence of processes involved in the production and distribution of, well, something, a commodity. In this case, we're gonna talk about software and hardware. And the real world, that's many, many tiers, not just suppliers, but the connections between them. Supply Chain attack is, well, an attack on that supply chain, instead of the software that's actually deployed. Understanding software supply chains requires understanding open-source software for reasons I'll explain in a second. So what's open-source software? Hopefully most people here already know this, but if you don't, it's software licensed so that you can run it, study, modify it, freely redistribute more details in the open-source definition. Some people will use the term free software to emphasize user freedom and motivations. If you're not talking about open-source software, closed software or close-source software or proprietary software are common ways to describe something that's not open-source software. Important to understand, open-source software is a kind of commercial software, right? There's, it's licensed to the general public and they're at least under US law that makes it automatically commercial software and these enable collaborative development of software. And it's critical, open-source is critical part of the software supply chain. 98% of the code bases out there include open-source and in fact, the majority of their codes on average 70% of code bases are actually open-source software. You can see from the chart, just a few years ago in 2016, the average number of open-source software components per application was 84 by 2020 and raised to 528. All software is under attack. Open-source proprietary doesn't matter and it's under attack directly via vulnerabilities being attacked where it's deployed and also it's being attacked through their supply chains, how they're developed, how they're distributed. I can still get asked this question, is open-source or proprietary software always more secure? And of course, as with most such questions, the key is always, always is hard. The reality is neither is always more secure. Now there is a principle that gives open-source a potential advantage. The basics of how to develop secure software were identified back in the 1870s, they're still true. And one of those was the open design principle. The protection mechanism must not depend on attack or ignorance. Open-source better fulfills this principle, therefore it has a potential advantage but potentials are not always realized and the software is perfect anyway so vulnerabilities can be found in even well-run programs. A common problem is known vulnerabilities inside reused software. Now this is actually a problem for both open-source and closed-source software. If a developer brings a component, reuses it and then two years later, vulnerability is found, if that component's not updated, it's still vulnerable. But there's so much more open-source software that while this is not specific to open-source, it's especially a problem if you don't update your open-source software because typically there's so much of it. And there's a huge number of measures. I don't have time to go through this but this is a long list of measures that show that this is indeed a real problem that developers are not updating the reused software within their systems and that can create vulnerabilities in the systems they release to end users. The most common kind of supply chain attack for open-source software, something called type of squatting, basically a name with a maliciously crafted similar name to what the person probably intended. The Backstabber's Knife Collection article looked at various kinds of various attacks and found it was the most common. I'll make a quick note, if you're using open-source software, really any software, double check the name, double check where you're getting it from. It doesn't take long to do the double check. Let me talk real quickly about how software is developed because in fact, it's the overall software supply chain. This is a quick little model of how software is developed from the idea in someone's head all the way out to deployment. We start with developers, it gets developed typically in a local environment, gets shared in some sort of repository forge, build, verify, approve, release, gets distributed and then it may end up directly within users or it may be pulled into a larger software component and go through the cycle again and it may go through tier after tier after tier. And of course, once you notice, oh, there's a process, attackers can attack it, right. Attackers can attack any of this, any of these things. However, the good news is that there are many countermeasures that can be applied and once you start thinking, oh, wait a minute, attackers are attacking. I as a developer, I as a potential user need to take steps to counter the attackers. The attackers will suddenly have a much harder time of it. If you're an open source developer, if you're an open source software, please take steps. Here's some things that you should be doing, things like, number one, learn how to develop and acquire secure software. If you can't remember anything else, remember that because the vast majority of software developers have never learned how to develop secure software. It's not that they're stupid, it's that they were never told. A lot of universities don't require it and so that's just a common problem across the industry. You know, help projects. If you're an open source software projects are into CI best practices by edge, use lots of tools to find vulnerabilities to squeeze them out during inside your CI pipeline so you can detect those problems before they get released. Supply chain issues, monitor for known vulnerabilities, enable rapid dependency update, evaluate before selecting dependencies to use. If you're looking at open source software, consider these for evaluation. Is there evidence that the developers work to make it secure, for example? Here's some others. The good news is that there's a lot of ongoing work to make things better. We're gonna talk a lot about software build materials. It's basically an ingredients list, what's in the software and there's increasing use and adoption and requiring your software build materials. This finally puts some sunshine into the whole, well, wait a minute. I see you gave me the latest version of X but what's inside X, what are the components? Are they all up to date or do they have known vulnerabilities? Maybe they're not the correct ones. Maybe those are known typosquadding components and so Sbombs or software build materials make it much easier for customers to find out these kinds of things which puts a ray of sunshine onto that. More help in evaluating open source software and so on. Help us understand where the gaps are. We'd love for people here participating to take the LF Sbombs Readiness Survey. There's a link there. Later on we'll present this and some preliminary results and frankly a world premiere. Here's the rest of the town hall agenda. We've got lots of interesting stuff that's going to be going on here. So please stick around and I'd like to first start off with generating Sbombs for IoT Internet of Things at build time with Steve Winslow. So I'm actually slightly ahead. So Steve are you ready?