 Hello. Thank you. Thank you, fan club. My name's Jessica Mars, and I lead the open source program office at Intel. And I'm here today to talk to you about the role the open source program office, or OSPO, can play in helping to secure the software supply chain. The open source software supply chain is like nothing else in the world. It's distributed. It's decentralized. You've got individuals and organizations from all over the world collaborating. You may not even know the real identities of the people that you're working with. And those conditions can make it complex and challenging for organizations to assess the risk or to understand the security or the quality levels of the software that they're consuming. But there's a solution, I think, the open source program office, or the OSPO. The OSPO is a centralized unit within an organization, typically tasked with managing the policies related to the consumption and production of open source software, governance, compliance, community engagement. There are four main tasks. As I mentioned, the first is related to the policies, policies for the consumption or production of open source software. But they also facilitate upstream contributions. And there's a third thing that I'm forgetting. Oh, right, advocating for the use of open source software within the organization. That includes training and educating people on why open source software is so great. And last but not least, forgetting that fourth thing. Sorry, going to my notes. Managing legal risk. So how can an OSPO with these four main topics or four main subject areas that it's responsible for help to secure the supply chain? Well, you can slot security in to each one of those areas. The first one is in policy development. Policy development is the bread and butter of the OSPO. It's what we do day in and day out. It's coming up with rules about how we use software, what kind of software we want to use. And so to extend it to security, you can place requirements and policies around perhaps what sort of open SSF score a project has or what a good dependency is. And we can establish policies regarding the production of the open source software. So what we're putting out, making sure that it's secure, making sure that we perhaps have certain open OSSF score card scores. And what do we do or how do we get the policies out in front of people? Well, one of the key things that an open source program office does is vulnerability management. Or actually, it's keeping track of what's being used and where. And once you know where things are being used and what's being used, you can perform risk assessments on those. I think one of the most important things that the open source program office can do is to identify the key projects. The most important projects are components that are in use across the organization and then come up with strategies for securing those. They can track CVEs for those. They can set schedules for upgrades. And how do they manage vulnerabilities? And how do they communicate across the organization? Well, they educate. Most open source program offices are already education providers. We've been teaching people about licenses forever. So now we can teach people about security-related matters, things like choosing good dependencies, dependency management, secure coding practices. All of these things are well within the wheelhouse of an OSPO to produce and to share. And how do we get those out into the organization through our existing networks? So most OSPOs already have very robust networks in the engineering, legal, and security communities within the corporation or organization. Leveraging those networks, taking advantage of the infrastructure that already exists, is a no-brainer. And one of the most important networks is, of course, the community. The OSPOs should be taking steps to make sure that the organization is working with communities to help contribute to open source projects, those projects that I mentioned that are so important to the organization. We should be contributing on a regular basis. We should be monitoring the CVEs for those projects. And we should actually be facilitating getting those CVEs fixed, not just reaching out to the maintainers and saying, hey, please hurry up, which is something that happened with log4j, but actually providing resources, whether that's coding or expertise or dollars, rewards, incentives for fixing CVEs in a timely fashion. Last but not least, cooperation. Internally cooperating with our partners in engineering and in legal and in security externally with industry working groups, foundations, because security is too big and too important for us to be working in a siloed fashion. We need to work together so that the whole is greater than some of its parts. Thank you.