 Our next speaker is going to talk about maybe not cool, but immediately urgent and concerning topic, and that is the area of cybersecurity. Vincent Dananda is the vice president of product security at Red Hat. He's been involved with open source and software security for over 20 years, leading security teams, participating in open source communities, and more. He's also a member of the open source security foundation's governing board. And today he's going to discuss approach to managing risk and vulnerabilities in open source software, and how Red Hat works to ensure safer consumption of open source software for all. Please welcome Vincent. Good morning. It's great to be here with you today. I want to start off by telling you that it's my job to think about risk all the time. So that's where this presentation is coming from, ensuring that Red Hat and the communities that we work in are able to balance the risk of not stifling technology innovation. Now, it's no surprise to anyone here that security is top of mind across a number of industries, such as telco, financial, automotive, and even government. Now, with the increasing rise of supply chain attacks, some of them making huge headlines, it's also not a surprise that a lot of eyes are on open source. Now, all of those eyes are, to me, one of the greatest benefits of open source. Now, I do tend to get a little riled up when the level of suspicion or skepticism leads to people labeling open sources insecure. Those eyes include the US Executive Order in 2021, the European Cyber Resiliency Act, and even Canada highlights security considerations with open source. But let me make one thing extremely clear. Security problems in software are not uniquely open source. All software has security risks and vulnerabilities. But what is uniquely open source is transparency. Now, all of us in this room know that you can't force anyone to do anything, kind of like my daughter at this age. Now, maintainers of open source are not beholden to any company or government, perhaps with the exception of those who are employed to work on open source. But maintainers are not always paid. And even when they are, unless a particular project has a company backing it, a paid maintainer may not have any more weight than a community contributor. So while there are unique methods of creating and consuming open source, security isn't strictly an open source concern. Now, everyone knows that Red Hat creates, maintains, and sells open source software. Security is very much a focus because we wanna offer customers trustworthy and resilient software. We're aware of the unique differences between open and proprietary software and our risk-based approach accounts for that. So transparency then is a key principle when it comes to our software. Not just in the source code itself, but also in the security data around it. For example, unlike proprietary software, we can't pretend that a vulnerability doesn't exist and we can't hide it from you. Now that's important because we don't want to, excuse me, we never would. You deserve to know what risk your use of our software poses even when we feel that it's insignificant. So that means that when we don't fix something that we feel isn't risky, you know about it and can compensate accordingly if you want to. Now, the larger point is this. If no one tells you about it, you have unknown risk. And as you can imagine, I don't like unknown risk and neither do our customers. So we go further than that. Red Hat rates vulnerabilities based on their expected use in our products. So when we work to get all critical and important vulnerabilities fixed as quickly as possible. We also monitor known exploit databases so if there's something that we didn't fix that starts to be exploited in the wild, we're going to treat it like a critical vulnerability and get a fix out. Now our goal is to make sure that everyone can see all of our security data whether they're a customer or not. And unlike proprietary vendors and many open source vendors, we let you know when something affects our stuff even if we're not going to fix it. Now that's all pretty specific to Red Hat and the way that we handle the open source that we carry and provide our customers. What isn't specific to us is the exploitability. Now I hear from a lot of customers who want every vulnerability fixed every single time. Now that's a lot of overhead for no good purpose. And now for the last two years, we've tracked the known exploited vulnerabilities list from CISA and it's been really insightful. First, we recognize that it's not exhaustive but we do believe that it's representative. Second, the vast majority of exploited vulnerabilities on that list affect proprietary software. And finally, the exploitation rates when it's compared with what we ship, it's extremely low. Now these numbers tell us a few important things. Now while I don't believe that you can ever call any software totally secure, I believe this demonstrates that open source software is trustworthy, which is amazing. It also highlights that while there might be a lot of CVs in open source, most of them do not get actively exploited. So in our world, it doesn't make sense to patch everything. As one example, last year we had almost 1,100 CVs that we rated moderate and only two of them had known exploitation. Now it's easy to focus on the technology and look for fixes in technology but the real things to think about are pretty clear. When you look at the source of data breaches. So Verizon puts out a pretty good report paper and it showed that breaches through software exploitation are single digit events. Now exploitation through people and process are the source of vast majority of breaches, phishing, spoofing, and the like. And I also put the lack of patching for when patches are available, squarely in that people in process bucket. Now at the end of the day, I focus on risk. That's my job. And I honestly think that open source manages risk quite well. I also believe the most open source maintainers do too. But there's a careful balance between focusing exclusively on things like CVs and working on things that make open source so valuable. Innovation, transformation of how entire industries create value, accelerated development, these are all the wonderful benefits of open source. Now to stifle or cut off that innovation for the sake of fixing things that in the end are no more impactful than any other bug, it really takes away from the true beauty of open source. Now that's an area where I've been focused a lot, trying to get both customers and regulators to understand, and these days even governments. Now I'm not arguing that managing the risk of any software isn't important, but I do argue with the notion that open source is worse or that it needs to be regulated in some way. Taking away our freedom to innovate so that all of the boxes are checked isn't the way to keep communities and projects thriving and growing. We can manage that risk and receive tremendous value from open source if we look at all of these things in balance. In other words, we manage the risk appropriately and transparently. Thank you and I hope you enjoy the rest of the conference.