 Hi, I'm Cindy Blake with GitLab. I've been with GitLab since the inception of our security capabilities, and I've worked with a lot of customers and prospects, and I've learned about best practices and their key challenges. I'm full disclosure. I also worked for four to five for many years, so I also understand the more traditional application security testing methods, as well as the DevSecOps methods that GitLab enables. I've also worked for SolarWinds and the MSP division briefly, and while I wasn't part of Orion, my heart really goes out to those folks there. Let's talk about securing next generation IT, or now better known as cloud native applications. DevOps delivers business value sooner in smaller increments and creates faster velocity. Cloud native is about taking advantage of the unique properties of cloud to deliver that software faster and more flexibly. It empowers developers to get started on coding right away, making setup repeatable and using automated templates. DevOps, microservices, and containers take advantage of the flexibility, scalability, and power of cloud infrastructure to support your application workload. Coding in the cloud gives teams much greater control over their costs and their environments. They can dynamically scale up or scale down as demanded by the market, and they can rapidly provision and deploy test environments or production. So what's different? Well, code changes faster and faster. There's more open source elements, there's more APIs, and there's more microservices or smaller applications. Traditional application security testing tools were built 10, 15 years ago, maybe more, and when today's modern methods like DevOps didn't exist. And so you need to rethink about your tools because traditional tools just are no longer enough. DevOps doesn't scale or DevSecOps, I should say, doesn't scale without developer enablement, without automation, and exception-based security or policy-based security. There's new attack surfaces that must be considered, and all of this really makes the tools that have been around for a long time insufficient, as well as the methods. Cloud-native apps include more than just business logic software. It's also additional code that surrounds the application to deliver resources, communicate with third-party subroutines, and apply guardrails. In addition, things move faster, so manual intervention really isn't possible. Now, there's lots of definitions of cloud-native, but this one I think from the new stack is a pretty good one. There's several elements that it includes, and we'll get into that in a bit, but think of an example would be a policy, which is also code, by the way, that limits resource usage. So its intent is to prevent runaway processes from churning through your cloud minutes, whether they're legitimate accidents or malicious crypto mining. But the code that provides those limits is now an attack surface itself. It could be disabled, or it could be ratcheted down to cripple legitimate consumption. There are so many new elements in the cloud-native world, and all of them bring some element of risk. I kind of simplify cloud-native into three main areas of risk that impact security, containers, orchestrators like Kubernetes, and microservices. These break apps into smaller parts. So you take a monolithic application and now you chunk it down into pieces. So there are more parts, which now mean there are more connections to those parts via APIs. Do you know how many APIs you have? Do you know if they're secure? If you test them, they are analyzed as an example of one of the many challenges, knowing all of the things that you now must secure. All of these parts also require configuration, and with configuration comes the risk for misconfiguration. Containers, Kubernetes, your cloud service, even your software development platform all have levers to pull. Knowing which settings are best and how they interact is challenging and getting worse. There are not really any great solutions out there to help manage this risk right now. In addition, the software factory itself is becoming an attack surface. The SolarWinds attack was not due to software vulnerability like cross-site scripting or any of the OWASP top 10 that we typically stand for. That's where most people focus their application security energies. And it wasn't even on a misconfiguration error. It was a combination of poor security hygiene and exploit of the build process itself. So even the most damaging attacks tend to rely on complacency toward basic security hygiene. Think patches and passwords. And they tend to use tried and true exploits that have been around for a long time. From what I've read in the news, SolarWinds admin relied on a simple password and didn't change it. Basic hygiene seems simple, but these mundane tasks are often overlooked. This is where automation can help. Things like automated key rotations and secrets detection can ensure that policies are applied consistently. For the SolarWinds Orion app, code was injected during the build process that created a back door for SolarWinds clients. The way it was done required months of careful planning and execution. The attackers also included safeguards to prevent the back door lines of code from appearing in Orion build logs. And checks to ensure that tampering wouldn't cause build errors. It's almost impossible to prevent this kind of persistent premeditated attack. But it certainly raises awareness of the need to treat your software factory like any other factory. Just like a materials good factory would prevent random people from adding random things to their product. The software factory must carefully scrutinize access and permissions, pay attention to components that are used and improve transparency of any changes along the way. Today's era of cloud native applications requires so much more than simple scanning of the code for vulnerabilities. I love this quote and it's been around for a while but I still find it so very relevant. The CISO of VMware said this at an RSA two years ago, maybe more. Your most important security product won't be a security product. And that rings true even more today. Application security testing is not enough. Applications are a prime target of attack. Lack of hygiene allows proven exploits to be used repeatedly. And most application security testing focuses on known vulnerabilities. But as DevOps tool chains grow in complexity, there are even more avenues that are open for exploit both in the factory itself, if you will, and in the components that are used. I think this is some pragmatic advice. You always need basic security hygiene, but you need to add to that automation to keep up with DevOps and the infrastructure is code that's created by cloud native applications. You can't do it in a manual or waterfall environment. You really have to fully automate your application security. This automation should be built on a foundation of standardization. Standardize your CI pipeline, things like application security testing and configurations. Make the configurations, the pipeline reusable. And then measure and improve your processes. Automation, by the way, can reduce the scope of your security compliance. So if things are automated, you just have to show that the automation works rather than looking through a host of examples to prove it. Common controls need to be front and center, particularly in a cloud native environment. And these can help with security and compliance. Security testing is a fundamental element. I don't want to downplay it, but there are additional things here that can protect the integrity of your cloud native software. I'll give a few more examples here. For each control, you must consider when and how it's applied to your entire portfolio or to just high risk projects. For instance, does every application get scanned for security flaws? When exceptions are triggered, so maybe a vulnerability is found or a misconfiguration identified, how are policies enforced? Do they require approval? Must they all be resolved before moving forward? What are the thresholds? For instance, when using merge request approvals, who can approve pushing code with security flaws? What level of severity must the flaws be to stop a build? These are just some of the examples of features that can facilitate these policies. Things like protected branches and credentials. You need to have role-based access controls. All of these things are really important. If a nation-state attacker puts you in their crosshairs, it's quite likely that they're going to find a way in no matter how much defense in depth you use. If a breach does occur, though, auditability can make the difference for rapid detection and remediation. Can you see who changed what, where, and when in your software supply chain? Can you see all of the changes to the code and any environments that were coded? It's hard to tell if you're using a bunch of tools that are bolded together. You lose transparency across those silos. I would encourage you to take a fresh look at how you govern the security of your software supply chain. If you think about your software as a factory, you need that visibility and control end-to-end, how we plan, develop, deploy, and monitor software. Historically, AppSets has been very focused on building secure software, free of security flaws. But modern software development requires that we also protect the integrity of the factory itself, the third-party components that are used, and the configuration of the software's infrastructure. A DevOps platform can help you unite the data, the user interface, the governance, and the collaboration across all of the stages that are part of your software development and delivery. In talking with customers, I found that the most successful organizations focus on these three things, on simplicity, visibility, and control. Simplicity by using a DevOps platform that embeds security and compliance seamlessly. This enables greater visibility into who changed what, where, when. Control ensure that policies are applied consistently across applications and environments. When you think about Cloud Native, you need to think about the software factory, how you plan, create, package, deploy, monitor your software. It's complicated, and it gets more complicated with Cloud Native. It requires more than just application security testing. Automating that is a critical foundational step, but it also requires automation of your policies, setting up guardrails. Guardrails allow people to run fast, but also secure, and basically codify your organization's appetite for risk. So your automation needs to be expanded beyond the code itself to ensure that policies protect Cloud Native elements like Docker, Kubernetes, and ensure that consistent configurations are used. The very nature of the DevOps tools can either add to or reduce risk. The more tools you have, the more difficult it is to manage and access and permissions and to detect and prevent nefarious interventions. So if you can simplify your DevOps tool chain, consolidating into a platform with fewer interfaces, it's far easier to see who changed what, where, when, and to control your options up front. Remember, you need to protect the development platform itself as well as the code. So the less complicated it is, the easier that will be. With that, I thank you, I'm open for questions, and please feel free to reach out to me. My contact information is here for LinkedIn. Thank you so much.