 There's so much exciting change and evolution happening in DevOps and in the application security industry. Most of recognize the need to shift left to empower developers to find and fix vulnerabilities earlier in the software development life cycle. Doing this has been labeled DevSecOps, integrating security into DevOps. We're blessed to have been an influential catalyst for this change, but scanning your code through automation really isn't enough. Creating that vulnerability information to the developer while they're still iterating on the code is certainly more efficient, yet the industry still needs to improve more. We need to better prevent the vulnerabilities in the first place, to remediate them faster, and to more consistently and easily automate policies for developing, deploying, and running applications securely. Hillary Benson is going to share GitLab's product strategy for helping you tackle all of these new challenges. She's rather new to GitLab and brings a wealth of experience. For those of you who haven't met David DeSanto, David was promoted last year to apply his skills even more broadly to not only security but now to compliance and project planning within GitLab. So Hillary is essentially the new David and part of his new larger team. So be sure to get to know her. I'm so excited to have the skills and the experience of both on board. I'm sure you want to chat during the session and be sure to connect with Hillary afterwards and give her a warm welcome. Hi, and welcome to GitLab Commit 2021. My name is Hillary Benson. I'm director of product management at GitLab. My team is responsible for GitLab security offerings, which you know as the secure and protect stages. This talk is going to be all about DevSecOps, what it is, what you need in order to develop your own DevSecOps program, and how GitLab can help you bring your DevSecOps goals to life. But before we get into it, I have to make an obligatory announcement regarding some of today's content. Part of what I'll be discussing is GitLab's future plans for our security offerings. We plan ambitiously at GitLab, and you'll see that in some of the features and functionality that I'll talk about. But anything on our roadmap is subject to change without notice, and anything I talk about in this session should not be used for the purpose of any material purchase decisions, nor is it any kind of promise. So let's get started. What is DevSecOps? If you look into the topic at all, you'll find that DevSecOps means different things to different people. There's often a lot of confusion over what it is, even down to heated debates over what to call it. SecDevOps, DevSecOps, DevOpSec, DevOpSecurity, there's been a lot of debate about the name. Any discussion about the topic also usually starts with a definition. And so in a sense, I'll honor that tradition today. But first I want to get into why it's so confusing to begin with. DevSecOps is a very loaded term in the sense that it's doing a lot of work on its own to explain a series of interrelated things. For some, DevSecOps is about the organizations within your company that are included in a given process. It's about development, security, and IT operations teams working together. For others, it's less about the people involved and more about the series of tools that you use across your software development lifecycle. Some folks see DevSecOps as a conglomeration of specific tooling. That tooling often includes continuous integration and continuous delivery tools, application monitoring tools, application security testing tools, and so on. For those folks, all of these tools pieced together sort of equal DevSecOps. And then still others view this from the perspective of the characteristics that you're looking to build into your applications. For them, DevSecOps stands in for the idea that you manage to get your people and your tooling to work together in a way that produces applications that meet some set of criteria that you've deemed important. Some of those characteristics might be that an application is highly available or secure or performant or any number of other characteristics. This last way of looking at it I think is particularly interesting because this view of DevSecOps may include teams and tools across your org that aren't necessarily directly included in the typical DevSecOps lens but are certainly responsible for things that need to be considered and accounted for as you're building out your applications. Your compliance team might be a good example of this. Typical definitions of DevSecOps don't really deal specifically with needs around regulatory compliance, even though that's very directly related to security and certainly needs to be part of your process. Looking at DevSecOps as a sort of umbrella term that relates in some way to this idea of producing applications with certain characteristics, I think lends itself well to a pretty clear and still flexible way of defining DevSecOps. So in the definition that we'll come up with today, which we'll get to in a couple of slides, we'll leverage this idea of optimizing for characteristics. Before we get there, though, I want to touch on one other aspect. Now, a little bit ironically, even if the definition of DevSecOps is often murky and debated, people are generally on the same page about the principles behind it. So it's important to understand what those principles are exactly. You'll find some variation in these principles as well but generally speaking, DevSecOps espouses the following ideas. First, security should be directly integrated into your tools and workflows as close to the point of introducing security issues as possible. So instead of scanning for vulnerabilities after an application is fully built, you scan for vulnerabilities as soon as the developer introduces a small block of code that they've just committed. Second, automate everything. Instead of performing manual checks that require human attention and time, just codify your security expertise into automated tooling and testing. Third, improve security posture over time by making small, frequent changes and iterating to a better place rather than biting off huge projects in large chunks. Fourth, in everything that you do, build a program that allows you to make decisions from a risk-driven perspective. Don't just toss a list of vulnerabilities over to your developers and say fix everything on the list, rather figure out how to apply some risk-based rationale to the findings that you actually plan to remediate. And then lastly, focus on fixing the security issues that matter the most. Try to understand the impact that a given finding has to you and to your business and then stack rank that security finding and its impact against all of the other priorities that your team is balancing, security and otherwise, in order to decide what's most important. So with the previous two slides in mind, we have this shared set of principles that most people more or less agree on. And then we have this idea that DevSecOps relates somehow to optimizing for certain application characteristics. Where does that leave us and how do we put those things together in a way that helps to understand how to make use of these ideas in practice. For the purposes of this conversation, we're gonna say DevSecOps is an approach that you adopt that draws on DevOps principles of automation, workflow integration, continuous delivery and risk-driven decision-making to produce applications that meet a defined set of desired characteristics, usually with a heavy bent toward security. It's a long definition, but this is the definition to have in mind and refer back to you throughout the rest of this presentation. After all that trouble to understand what DevSecOps is, why should you care? Well, there are a number of ways in which implementing DevSecOps can actually really benefit your organization. Top among them is the ability of DevSecOps to reduce costs and deliver software faster. The next couple of slides will dig into both of those points in some detail. So I'll skip to number three. DevSecOps is also valuable in that it helps you to prevent damaging but avoidable breaches. So standard practices around automation and shifting security testing left in the development process help to weed out a lot of low-hanging fruit that even though it's low-hanging fruit, it can end up being a big problem in production. Think of things like OWAS top 10 issues that are easy to remediate or preventing admin consoles from being deployed with default credentials. Codifying security knowledge into your tools and automation is key to reducing these types of problems. DevSecOps also helps you to continuously maintain a strong security posture. Frequent iterative improvements embedded into the software development lifecycle help you to stay on top of things as the code is changing rather than always being in a reactive state. The fifth benefit here is that DevSecOps can help to produce the data that you need to make educated decisions about risk acceptance. Whether you realize it or not, you design every day which security issues you're gonna tolerate running in production. You may explicitly know what those issues are or you may not, but the process that you adopt to manage your security program is part of what defines your awareness and what you're accepting on a daily basis. Integrating security into the development process and leveraging the information about the code and configuration of an application that you can derive from each step of the process enables you to build a robust picture of where security risk lies across your attack surface. And finally, if done well, DevSecOps over time fosters a culture of transparency and understanding of your organization's goals and priorities. So going back to the points of cost and time to market, DevSecOps plays a huge role in reducing the cost in terms of time and dollars to remediate vulnerabilities. The earlier in the development process that you can identify a finding, the earlier you can inform a developer and the earlier that person can fix the problem. If you identify an issue at the time of commit and give the developer all the information they need to understand that issue in context and then apply a fix, you can eliminate vulnerabilities in minutes. If you wait to identify that vulnerability until your QA process has begun, then you're probably looking at weeks. And if the issue makes its way to production, it may take months for you to pinpoint that issue, prioritize it and get a fix shipped. In terms of how that time translates into dollars, the National Institute of Standards and Technology published a report on the economic impact of inadequate software testing. Some of their findings are summarized here. Top among them, software bugs are expensive. They cost $60 billion annually. And you can see the economics of this very greatly based on when exactly you identify an issue. It takes roughly 5.5 times the number of hours and that's roughly 5.5 times the dollars to fix an issue that you discover in production versus at the time of coding. So there's a clear and obvious business incentive to do whatever you can to remediate security findings as early as possible. Assuming you're sold on the idea of DevSecOps, the natural next question then is how to go about adopting it? We're gonna say pretty high level on this today because there's a lot to get into, way too much for 25 minutes, but at a basic level to apply a DevSecOps approach to building software, you need at least the following things. First off, you need goals. Believe it or not, most of the time people skip goals all together and just dive right in, but this is an absolutely key ingredient to success. You need to be really clear about the problems you're trying to solve and have a firm sense of those application characteristics that you're optimizing for. There will absolutely be trade-offs either by necessity or by choice, but there will be trade-offs. If you're a very small startup, shipping your first product, things you care about might be that you ship as fast as possible. With a product that technically works and doesn't have any glaring high severity security issues, but if you're a large government agency or a Fortune 500 company, you likely have priorities around regulatory compliance, high availability, resilience, performance, risk metrics that you need to meet and so on. So very clearly defining your situation and what you're hoping to achieve by implementing DevSecOps is stop number one. Next, you need a clearly defined process. I'd argue that this is really the heart of DevSecOps. After all, it is an approach. So it's all about the steps you take and how you take them. There's a lot of material out there on what these specific steps might look like. And then a few slides will cover what types of security testing GitLab suggests you integrate and at what point in the software development lifecycle you should do that. But your playbook needs to be customized to your individual needs. So no one source is likely to produce a fully baked recipe for how to do this. GitLab can get you started and we'll see how a little bit later on. And finally tooling. Selecting platforms and tools that are purpose-built for DevSecOps and philosophically aligned with what you're trying to do isn't strictly required but it'll make your path a lot easier, faster and cheaper. Next, I think it's important to call out some of the likely challenges that you're gonna face in developing and implementing a DevSecOps process. So for each of the components that I outlined on the last slide these are some of the most common challenges that you're gonna run into. With respect to setting goals the biggest challenges come in driving alignment planning and tracking progress. Anytime you define and try to get to consensus on what your org will and won't do you're likely to push through multiple iterations and revisions of those goals. Planning across stakeholders is always messy and by definition DevSecOps rules a lot of different players into the process. And then tracking progress can be difficult if you aren't very intentional about how and where you're gonna document your goals and plans. With respect to process first cultural change is hands down the biggest challenge that you're gonna face. People are usually accustomed to doing things in a certain way and whether that's intentional or by accident can certainly have some influence on how easy it is to get by in but actually shifting behavior is just really hard especially without the right tools to help. Second knowing what steps you should take and what you can sort of leave on the shelf can also be really difficult especially if you didn't do a thorough job of setting goals. There's so many methods and tools out there that it can be overwhelming just to decide what you need to do. Third understanding where your teams have knowledge gaps and how to fill those gaps in with just enough information to build bridges but not overwhelm or frustrate people can be really difficult as well. Fourth on process is flexibility. Designing a process that is specific enough to get the job done but flexible enough to adapt to changes and new technologies is always a balancing act. And finally with respect to tooling most organizations out there are trying to cobble together a disjointed mess of tools to enable DevSecOps and that often introduces cost, friction, brittleness and so that's likely something you're gonna encounter. A big part of why your tool chain is so disjointed comes down to a mismatch in development philosophies especially with respect to security tools. If they're not purpose built for a DevOps inspired process munging them into your workflow is likely to be bumpy. And last because you're likely cobbling together many disparate tools the job of putting security findings into contexts assigning some sense of global priority and then taking action on those issues is almost always just on you to figure out which generally doesn't go very well. But here's the good news, help is on the way GitLab can serve as a foundation for your DevSecOps practice and we have the ability to address or eliminate all of those challenges that we just discussed. So how do we do that? On driving alignment, planning and tracking progress GitLab's plan and manage capabilities enable you to establish and iterate on all of your goals in a single place that's transparent to everybody. You can define and coordinate deliverables with issues and upticks. You can track completion and delivery velocity with value stream analytics. There's a lot here to sort of help with these issues. On cultural change, DevSecOps philosophy is embedded across GitLab and that reflects our intended direction going forward as well. And since cultural change is about driving new behaviors if your team is using a platform that embeds the behaviors you're looking to see you sort of drive change within your organization through use of the product. On steps to take GitLab to product as well as our thought leadership and partnership can provide a process and platform that is tailored to your specific needs. On knowledge and expertise, for instance, GitLab Secure specifically embeds context relevant security information into developer workflows. That's also a major future focus area with things like embedded developer training coming down the bike. On flexibility, GitLab's capabilities are vast and always tracking in the direction of supporting new technologies. So you don't have to worry about something new popping up and throwing your DevSecOps program into disarray. The product is always gonna support you and your teams in your program as it evolves. And then of course on tooling, GitLab plays a major part. We are the single platform purpose built for DevSecOps that you can use to resolve your tooling challenges and you can do that by leveraging our native capabilities. You can integrate the tools that you're already using and that you love and you can take advantage of the unique context we have by managing your entire software development lifecycle to put priority findings and context at sort of all the key control points throughout your process. Because GitLab is optimized for DevSecOps, we have security offerings that you can leverage at every stage of the lifecycle. Your developers commit new code, we analyze new commits for security findings and report them to the developer. They address those vulnerabilities, commit their fixes, and then we continue to protect the application as it moves to production by detecting attacks in cloud native environments. To sort of put this in context, make it a little bit more concrete. Here is what your typical feature branch experience might look like if you were leveraging GitLab secure features. So you would have a developer who creates a merge request, they commit their changes, the CI pipeline runs and as part of that CI pipeline, you run security scans, they're checking that code for vulnerabilities. That feedback in the pipeline happens immediately and is fed back to the developer who has an opportunity to fix high severity issues or whatever your organization has established as the policy for fixing these problems. Then that code will move on for code and security reviews, the changes are approved, merge request is merged, and then the CD pipeline runs. And at this point, security scans will run again and they will catch any remaining security issues in that code and provide visibility into those issues in our security dashboards as that code and the application moves into production. We offer a full suite of security services that helps you to implement DevSecOps best practices, including all the things that you see here, static and dynamic analysis tooling, dependency scanning, vulnerability management, security orchestration, container scanning, host of other things here. So wherever you are in your DevSecOps adoption journey, we have tooling that you can just pull off the shelf and leverage to get started. And of course, GitLab will continue to extend our DevOps platform in the future to provide new and improved experiences that support your DevSecOps program. In terms of where we're going, you can expect to see us continuously working to help you capitalize on the fact that GitLab is your single DevOps platform. It's your single source of truth for the life of your application. And so we wanna improve your experience and help you take your DevSecOps program to the next level. With respect to security functionality, you'll see that our focus rests in a few specific areas. Those are context control, workflow optimization and production security. To put those focus areas into context to make some of these ideas concrete, I'll touch on some specific functionality in each of these areas that we're working toward. The first example here is vulnerability management. As you can see, we have many planned improvements for our vulnerability management capabilities, much of which focuses on providing and leveraging context. So for instance, providing richer vulnerability information with issue linking and commenting or tuning our security dashboards to present the right level of information to serve as jumping off points for your role management workflows, SLA tracking, assigning asset criticality for risk profiles. There are many other things here. Much of our plan focus on role management is precisely about helping you to put your security findings into context. The second example demonstrates functionality to improve your control over security findings. We're working on enabling flexible alerting rules and actions to manage your security posture with scan policies and security approvals. The idea here is to help you make sure that certain security scans are always taking place or that findings that meet certain criteria trigger specific alerts or actions. For example, you could surface an alert for vulnerability that has a CVSS score over a certain threshold but still allow the pipeline to pass. Or if a bit of code has two or more critical vulnerabilities that are found, then fail the pipeline and raise an alert. There's a lot of flexibility that we intend to build into these policies. And then security approvals will help you to make sure that only certain people can grant exceptions to any of these defined security policies, including the ability to flexibly to find who those people are. The third example, which speaks to workflow optimization is some very cool functionality that we have planned around fingerprinting vulnerabilities. And this capability is actually very unique to GitLab in the sense that you can't replicate it anywhere else outside of GitLab. It leverages the fact that we're not only your security tooling but also your source code management tool. And the idea here is to track vulnerabilities in source code without relying on the line of code that they're found in. Typically tracking does rely on the line of code, which is one way that you can end up with false positives as a result of new code commits shifting the vulnerabilities location around in the code. So in order to address that, we'll give a vulnerability a unique fingerprint and then track it accurately across the code base. Making improvements like this help to reduce false positives and make workflows more efficient by eliminating all of the noise. And then finally, and here's an example of our focus on production security is around production scanning. Two areas where we're focused on providing this functionality are dynamic analysis testing capabilities and container scanning. This capability will allow you to scan for DAS or container vulnerability issues after an application has already been promoted and is running in a production environment. Our beta offering of the DAS on-demand scanning is actually already available today support for production scanning, production container scanning is in the works as well. All these examples speak to the fact that from philosophy to practice, GitLab provides the platform capabilities, reference material and partnership that can help shine the light and smooth the path toward building out your DevSecOps program. And with that, hopefully this has been a helpful if speedy introduction to DevSecOps and GitLab's enabling capabilities. Thank you so much for tuning in and enjoy the rest of your commit.