 Welcome. I'm Yvonne. I'm the CEO of Puppet, and it is such a privilege to be here today. Puppet has long been a huge believer in open source. In fact, the founder of Puppet, Lou Kniece, he wrote the first code of the Puppet open source project back in 2005, four years before we were actually founded as a company. And it has continued to grow and scale over time. We have over 4,000 organizations that have benefited from Puppet technology. We have an amazing content repository called The Forge, with over 6,000 open source modules created by many folks, likely out here in the audience and beyonds. We have over 160,000 unique visitors to that. We've also started a lot of other interesting open source projects, like Boltz, Lyra, Wash. We contribute upstream now to Tecton in terms of some of our cloud-native offerings. So it's been really important to us to be part of this community and thrilled to see it continue to thrive. From a, what do we do perspective? There were a lot of hands, but a brief description. I like to say we eliminate soul-crushing work. And we do that through infrastructure automation and integrating into environments to take away the toil of having to do everything manually. But also to make your environments more scalable and more secure. To that end, we also created something called the State of the DevOps Report. We've been doing that for over nine years. Thanks to many of you who've contributed to that. We have over 30,000 individuals who participate, send in their feedback. And what I want to do today is share with you some of the highlights from the most recent survey and really call to your attention that each and every one of you and all of us collectively have a role to play in security. Talk about why that's important. And talk about what you can practically, tactically do. And to kind of re-emphasize why it's important, there was a stat earlier, I think it was 99% of software contains open source. And we just heard from IBM. There's a lot of places where we can be vulnerable. So let's talk about that. Hopefully many of you recognize the headlines up on the screen. These are, initially, we saw these as, you know, wow, I feel really bad for the folks at Target. But don't be fooled. Some Forrester research showed that 58% of companies have had a date of breach. And 41% of those come from software vulnerabilities. So we're not as safe as we think that we would be. There's British Airways, T-Mobile, Facebook. You can go on and on and on. But at the end of the day, there's many, many folks who have now been impacted. And the reality is this cost folks a lot of money. So in Target's case, it was $18.5 million. In Equifax, it was $650 million. And the list goes on and on. And that doesn't even start to account for the brand's impact, the customer loyalty, all of those other challenges. But even just the average ransomware attack, $5 million. So the reason why people are starting to get concerned about this is this could cost a lot of money. But it gets worse. If you think about it, there's more types of data. Most of the breaches today have been about personal information, about security numbers and things like that. But if you think about it, all different types of data are being stored in all different types of places. And they're controlling more things. They're driving your cars. They're managing your money. They're potentially dispensing the medicines to your parents. All of those things. Imagine if a bad actor got in. And again, we heard about all the places AI is going to play a role. So there's more at risk. So not only is there more technology, more surface area for bad actors, but there's more impact that they can have. The other thing that's changed is how software is developed. And I believe all of these things are good. It's more democratized. It's more decentralized. And it's increasingly open source. And all of that is fabulous. But it does mess with security because in the old days we cared about the perimeter. We kind of thought it was like our house. Like you put a lock on the door, you shut the windows, and you're safe. We used to keep all of our software in these data centers and we protected the perimeter. But we now realize that that is insufficient. And it's causing us to think about how do we actually keep the world safe. And I want to share with you some stats on open source, because I think this is particularly relevant. This comes from our friends at Sneak, an open source security startup. Look at these stats. 88% growth and application vulnerabilities in over two years. 78% of those vulnerabilities were found in indirect dependencies. So we don't always think about when we include a call to an open source package what that might be introducing into our ecosystem. 37% of open source developers, I'm sure that's not any of you. But 37% don't include any type of security testing during the CI process. And 54% don't do any Docker image security screens. It's a median of two years from when a vulnerability is found or added in an open source package until it's fixed. That's a long time to be vulnerable and companies all over the globe. It was said earlier, 99% of software includes open source. This is scary. Now, coming from Puppet, I'm going to tell you I believe automation and declarative models are foundation to security, but they're not sufficient. I did want to point out that they are important. I was talking to a bank and they had a huge amount of stability issues. They did a retrospective and they said, don't write this down. So I didn't write it down, but I did remember it. They said 80% of the issues they had were human error. It was fat fingering. It was failure to adhere to policy. It was not getting work done in a critical amount of time. And so what they realized is they needed to automate the environment to actually create a base level of foundation of not just standardization and reliability, but also security. But that's far from sufficient in terms of what we need to do. And this is where the whole concept of DevOps has started to shift to DevSecOps. So if we think about it, waterfall broke down because it was this serial process. It took too long. There were too many handoffs. It was not gratifying to have to wait months and months and months to see and get feedback on what you'd written. And that was all great. But we moved to DevOps and we moved to containers and we moved to microservices to actually further improve and increase the ability that we can deliver feature functionality to the marketplace. But what we didn't account for necessarily was security. Now, this shouldn't surprise anybody, but this comes from IBM. And if you look at the cost of fixing defects, if you wait until implementation to find the defect, it's six and a half times as expensive. Testing 15, if it's found after the fact, it's 100 times more expensive. So it starts to raise the question if security really is this important and it's this costly to fix after the fact, should we blend it in sooner? So last year when we did the state of the DevOps report, we came up with the five stages of evolution. Normalized, standardized, expansion, automated delivery, and then ultimately self-service. If you look at it in the final stages, is when you start to see companies integrating in security, when they start looking at security policy configurations being automated, when you look at incident response being automated, and when you look at security teams being involved in the process. What we found not surprisingly this year is that in terms of the ability to have high levels of security integration, it is in level four and five. It is those most sophisticated companies and organizations out there. And here are some of the things that they're doing across the life cycle. From a requirement standpoint, actually thinking about compliance and security in the beginning during requirements, doing threat modeling as you work through the design, lots of areas in the build process that you can do things, from a testing standpoint, from a deployment. So there's many different areas where you can start to build security in as part of the process and break down those barriers. Now, what we found when we went out and we talked to folks is that when you increase the level of collaboration, you actually increase the confidence in the security posture of a company. Now, what does that look like? Well, if we look at how mature companies are, companies that are level four or five in terms of the maturity of DevOps have a two-X time higher level of confidence than level one on the security posture in the company. What are some of the things that they're doing? First and foremost, they're actually collaborating on threat models. That's key. They're integrating security tools in the integration pipeline. They're prioritizing security requirements in the backlog. They're understanding the infrastructure-related security policies before deployment, and they're actually involving the security experts in the automated tests. So these are the things that they're doing. Now, that doesn't necessarily mean they're more secure, but it is a mindset shift. It is a breaking down of the walls and the silos, just like we did between development and operations. We're now doing that with security teams. And unfortunately, what we found is just like when you go on the DevOps journey itself, security integration is messy. Whenever you try something new and you're trying to change behaviors, we talk about going through what we like to say a J curve. You get some quick early wins, then it starts to get more complex, and then you get the real benefit. And we see that in the data. We went out and we talked to security teams and developers around the level of friction. And what you'll see is, not surprisingly, people who don't integrate at all don't see very much friction. They're also probably not very secure. If you go to the far end, level five, there's actually the lowest amount of friction perceived, and it's in the middle section where you see the greatest amount of friction, because that's where you're just learning how to work together. You're learning how to integrate these processes. Now, why is there friction? Let's go back to why we did DevOps. It was to get feature functionality out quicker. And if we talk to respondents, does security slow you down? And I think that's been the big challenge all along, does security slow you down? And if you look at the chart, if you're not really focused on it, you don't really think about it, security's not slowing you down because you're not doing it. And if you go to the fully integrated side, you don't really figure it out, but in the middle it's somewhat messy. I'm here to tell you as a CEO of a company that sells to Fortune 1,000 companies around the globe, security matters. My phone rings if there's any issue. And so when I talk to my engineering teams, yes, I care about feature functionality, but I also care about the security and the ability that we can bring to our customers to ensure that they're not at risk, particularly in this increasingly challenging world when it comes to cybersecurity. So how are people doing? Well, if we look at it in terms of a measure of remediation of critical vulnerabilities, we're doing okay. If you look at the dark blue bar, I know the numbers are a little bit small. What you'll see is that level five DevOps companies can actually remediate most critical vulnerabilities in less than a day. It's a little, actually I should say, about half of the vulnerabilities. And then it kind of trails off over time. So this is not where we need it to be, but it definitely improves the ability to remediate the vulnerabilities, and hopefully there's fewer of them getting in to begin with. So in terms of integrating security, it does leave to positive outcomes. It is an important responsibility for all of us to have and to take to heart, but it's not going to come easily. And so it's a responsibility that we need to bring to the table and bring forward in terms of the work that we're doing. So how do you improve your security profile overall? We break it up into three key buckets. This is mostly at the infrastructure layer in terms of how do you ensure you're creating an automated environment that ideally provides self-service from a developer perspective? How do you mature your DevOps practices and move to DevSecOps? And how do you remediate the vulnerabilities faster? And on this last point, this isn't one simple answer in today's world. This typically is the integration of your tool set and your activities with other things in the environment. It can be anything from integration with the security scanners that you have to drive automated remediation. It can be integration into workflow tools like ServiceNow or Splunk or other tools like that. But how do you reduce that time? Because right now, the time to remediate vulnerabilities, if you already know there's a vulnerability, that's the last thing you want to get hit on in terms of a security breach. So with that, I invite all of you to download our most recent State of the DevOps report. You can find it for free on the Puppet website, along with all the past reports. And if you have any questions, I'll be around for the rest of the conference and look forward to seeing you. Thank you so much.