Hi everyone, I'm Stefania Chaplin, a solutions architect at GitLab and I'm going to talk about implementing true devsecops with people, processes and technology a little bit. About me I'm Stefania Chaplin, I'm a solutions architect. I've been in the devsecops space for a very long time. You can find me on my different handles or email. I used to be a python developer. I'm part of OWAsp dev silos. When I'm not doing tech stuff, I quite like yoga, tropical plants, and I'm a big advocate for diversity in technology. But enough about me. So people, processes and technology, if you think of it as overlapping Venn diagram. So when we have people and process, what we end up with is we can scale. So if you think about manufacturing and services, they have a fairly standardized process. For example, if you're going to get a McDonald's, you're probably going to receive a similar service depending on where you are in the world, maybe different products, but that's a different story. When we have people and technology, that means we can innovate. So if we think about the World Wide Web and what it looked like in 1994 to 2004 to 2014, it was very, very different. And it was a great combination of people, technology and innovation. The final one, when we have the bottom two, process and technology, this is where we can automate. So if we look at all the AI, machine learning, how we take our technology and we give it a process, all of a sudden we can get things done a lot faster. So what happens when you're missing certain elements? So for example, maybe you're not fast enough, maybe you've got a good process, good people, but maybe you're not using processes and technology efficient enough and you're not automating. If you're not efficient enough, then this probably means that you haven't quite standardized your people and process. So maybe you haven't found a way to scale yet. And okay, you're scaling, you're automating, but maybe you're not creating value. So this is where the people in technology is missing, and maybe you're lacking the innovation. So these are all things to think about as you think about your people, process and technology in terms of business impact. There's some great books I'd recommend. So Jean Kim, first the Phoenix project, then the recent sequel, the Unicorn project. And what we can see is improved information flow. We also have an increase in other areas. For example, culture. I talk about culture a lot because in terms of DevOps devsecops. It's not about a tool changing. You could buy all the tools and all the platforms in the world. If you haven't changed your culture and you're still operating in silos, you're going to have a little bit of a problem, similar with job satisfaction, identity of users, well, of employees, because ultimately you want to reduce the team burnout. Because if you're lacking scale, innovation or automation, people are probably potentially getting burnt out. There's going to be frustration. And once you start to fix this, you're going to get lower levels of deployment. And I say pain because it can be a bit painful sometimes, getting from code to production and also unplanned work. So when I mean this, I mean the red alerts, the firefighting, the problems that can arise when you have a very segregated tool chain and a lack of unison with people, processes and technology. So what we're looking for is software delivery performance and also organizational performance as well. I think the Unicorn project is a really good example of this. If you haven't read it, I would recommend it, because in the example, the protagonist, she joins a new team which is struggling. She's just trying to do a build, and that's a significant portion of the book. Just the process of her, like chasing support tickets, trying to find what scripts to run, the mix of languages, scripts, executables, et cetera. So if you have a culture or a process similar to that, you're going to end up with potentially a lot of frustration and lower software delivery and organizational performance than you would hope for. So Devsecops is transforming how companies deliver software. So when I say that, what I'm really talking about, security, changing vulnerabilities, everybody's favorite job, right? I used to be developer. I've worked in security a long time. I'm going to present to you two examples. So number one, what happens when you find 10,000 vulnerabilities at the end of your software development lifecycle? So maybe going into production, maybe it's in production, maybe it's just as you're about to hit deploy, when you're already behind schedule, behind budget, behind. Maybe there's a bit of tension in the room that's not when you want to discover these vulnerabilities, because especially if you've got any higher criticals, that could definitely be a showstopper. So I'm going to present to you another opportunity. What about if you empower each developer to deal with each one at the point where it's introduced, be proactive give developers the opportunity to play around, maybe in their own feature branch. Maybe they discover they're introducing a vulnerable library and then maybe they just upgrade. Maybe they use a different library, but having it as shifted left as possible, empowering your developers, a lot better I would say, than dealing with all of your problems right at the very end. So why do this? It's not just about the culture burnout, the happy fuzzy feelings that we as developer and security operations want to feel when we deploy. It's also about the cost. This comes from NIST, which is the very popular framework for security, and what we can see the cost to remediate. So say if we find a problem in requirements, maybe we're doing some threat modeling. That's going to be fairly easy. Well, easy, quick or easy to fix, because maybe we haven't quite started with still, we're still requirements gathering. Similarly, as you're coding, it's fairly easy to make code changes before you've started the development process. Once you start getting into testing, which is normally when we find vulnerabilities, that's going to still fixable. But what you can see in this chart with production, it's very expensive to fix in production. And also if you're fixing stuff in production, it means it's already out there. So your application and your business is vulnerable. So it's definitely worth taking a shift left approach to security. So what it doesn't mean because you don't want to look like this poor woman here, hand in your eyes, which I'm sure everyone has those days, but hopefully not with dead suck ups. So there's a lot of misconceptions and a couple of myths. So what we are not asking for, we do not want to disrupt workflow. So if you're asking developers to run scans outside of their existing workflow, that's going to cause a problem because you want to make it as seamless and transitional as possible. Similarly, expecting developers to understand what tools to run, when and how to interpret the results. This is a big knowledge gap we see because the way that developers DevOps talk and the way that they prioritize versus security and the lexicon that they use, there can be miscommunication sometimes. So when we think about security, this is kind of the old school approach and you can kind of see a loop. If we start at the top left at the repository, we commit, do CI merge, CD deploy, maybe you have a test environment, do some dynamic application security testing or maybe on the infrastructure, then the security team come along and then they're like right, here's your list of problems you can dismiss or create. The issue goes into the ticketing system and back to the development team. But you can see here, security is an afterthought and security as an afterthought is never a good idea because we really want to be releasing secure applications. So a more modern workflow, similar, same component, slightly different order. We have our repository on the top left, we commit our code, then it goes into the CI system. We have something called a review app. This is an ephemeral instance, which means you can do, a developer can do dynamic application security testing as part of their feature branch, what this also means, so they can do well, not only das a lot of other security that I'm going to talk about, but this gives the developer the chance to dismiss or create the issue, but they have a lot more control. If you think about as well the number of developers to security, you've got a lot more developers. If we could make every developer 1% better in security all of a sudden that would be a massive improvement. So now once you've got your CI and you have your merge request, so maybe you're merging back to your feature branch, CD will come along security team and at that point you have significantly lowered the number of potential vulnerabilities being released and you're able to deploy in a much safer manner. So advantages for the developer. So a couple of contextual, what do I mean by this? So within CI CD, everyone's accountable. For example, you could have a merge request pipeline for each developer. So this means that you've got your sandbox, you have the ability to play around, but you're not necessarily, I'm going to say polluting the main branch congruent with DevOps processes, so it gives you the chance to iterate. DevOps is very much about iterating. So if you can test with every code change, you can immediately see the cause and effect. So instead of on the first diagram where I might not know there's problems for a while, if we do take a more devsecops approach, we can integrated a lot faster. Similarly, having it integrated with DevOps tools, whether you're creating issues, autoremediation, you can get production feedback and efficient and automated. So what you're trying to do is eliminate work wherever possible, reduce context switching because no one wants context switching no matter who you are. And finally, less tracking and triaging because you've got more value added security and you have it at the right time. So really simplicity and integration win advantages for security. So there's some automation, it's consistent. They've also got earlier visibility into risks and remediation. If you could have a imagine this, you could have a development pipeline, you could get security results into there. You could then have a security dashboard where you could see all that might be going on in the pipelines, but mainly in the main branch. And then when you do create issues, you can see who's working on what. So it's really about visibility with this. When you get visibility, you can also potentially have predictable costs, because even if you have more testing, more testing, you're going to uncover your problem. You want to shift that left and that makes it a lot cheaper. So there's also reduced friction with development because you are empowering them and you can also give competitive feedback to the development. Maybe you want to give them a bit of security training as part of that ticket, for example. So what we have here is an example pipeline. So this could be as part of, for example, a merge request. A developer has an idea, they're going to write some code, they then create a feature branch, and then what they can do is as part of that, have all of these different scans. So I mentioned dynamic application security testing earlier. You can have static code analysis, looking at the written code, software, competitive analysis, looking at all the open source license scanning of that open source, looking for secret detection unit tests, et cetera. You can have all of that within a pipeline before a developer has even committed the code. And security as well can have visibility of this if they choose to. So what you end up with, here's my example, you are moving your security testing as close as possible to the developer. So as mentioned, developer creates an issue, create a merge request, so then they have the feature branch, which you can see along the top, commit the changes, run the pipeline, have some security scans, and the developer can get the results and then act on them. And this is all happening within the feature branch. So once you've done that, you can review, you can approve the changing and then close the merge request. And all of a sudden all of your amazing code is back in the default branch as secure as possible. So when your CD pipeline runs, you get some more security scans and then this all goes to the security dashboard. So when shift left is done, well, you can celebrate, as you can see here. So what does it mean? You can scan all code every time. A lot of tools out there, especially historically, maybe they charged per scan, maybe they charged per app. The reality is, if you are pricing per scan for example or per app, it's going to mean less scans. Whilst if you could can all your code every time with the incremental changes you could then see if you're introducing vulnerabilities. You want to make it seamlessly for devs. I used to be one. We like our tools, we like our idE, we like the tools that we need to use. Maybe we use handful issue tracking for CI CD, but we really want to use fewer tools. If a dev could live in their idE, I promise you we would. So what you really want to do is you want to combine, you want to have development, security and operations on the same page, maybe even using the same interface to have your CI CD, to have your security result, to have all your permissions hierarchy, just having one interface for all this and also happy compliance auditors which I will talk about in a moment. So compliance, this can be very important for a number of companies. So we try and make it as easy as possible. So one define and manage. So you're probably going to have specific settings. You're probably going to want to meet specific compliance controls. Depending on the industry you're in and depending on what compliance is necessary, you might want to do audit reports so you can export them very easily. It's a little right click. I can't remember off the top of my head if it's CSV or I think it's CSV, but it's very easily done, especially when it comes to compliance. I'm sure a lot of people have spent a lot of time and effort collating different results from different tools to produce audit reports. GitLab have it all in one place and traceability audit events. So you want to log everything? I hopefully don't need to tell people the importance of logging, but especially when it comes to instant response. If there is a malactor within your estate, you kind of want to know what they're doing. So logging and monitoring is an excellent way of doing this. So what you want to do, you want to have the traceability audit events and then you can identify adherence sorry eventify incidents and also adherence to compliance rules. So in terms of desired outcomes. So where are we looking to get to so greater efficiencies for both security and dev? We have to remember we are all on the same team. Sometimes it can feel with development, security and also operations that we have different language, different priorities. It can definitely be a case of pointing the finger and we really want to kind of reduce that. So efficiencies is a great way to start and then we can start on the digital and especially cultural transformation. We also have consistent compliance to policy. As mentioned in the previous slide, compliance and policy are important, so being able to adhere to a consistent guideline can only be good. Thanks. Reduced security exposure. So back to one of my earlier slides. Would you rather have ten k of problems at the end, or maybe one or two problems on each commit that can then easily be fixed pre commit, allowing developers to be proactive. What's also worth noting is with the reduced security exposure, what are you scanning? How are you changing it? Are you changing everything? There's a lot of different types of application security. GitLab. We have something called DevOps. It's a YamL file for our CI CD, and you can literally plug and play and you can decide what you want. So maybe we want SAS and gast and SCA software competitive analysis for this app, or maybe this one. We want all of them, and we want secrets protection. So with this security exposure, it's not only when we're doing the security, but also what type of security, and most importantly, what are we doing with the results? Because I've worked in a few organizations, you might have security, they produce a big list of reports. Back in the day, it was probably even on paper, and then give it to developers. They might look through, okay, the first five or four positives, and then that pile of paper goes into the bin. That's not what we're looking to do. We want to empower developers, we want to lower our overall security exposure, and we want to give visibility so that developers and security can interact within the same interface to see what each other are doing, to make sure the bugs are being fixed and given opportunity to communicate and collaborate. And what happens with this? You end up with predictable costs. So as I mentioned earlier, you don't want to have a cost per scan or cost per app. You want to be able to have your whole devsecops interface in one platform. Predictable costs with all your security scanning within the pipeline and also integrated within as well, which can lead to much more predictable costs. And when I say this, I also mean cost of tool chain, cost of scan, but also if you've taken all the steps I've described and you've reduced your security exposure, guess what? Your costs if touching all the woods, if something bad does happen, that can also have a massive cost in terms of brand impact, et cetera. So how do we get there? Scan results, allow developers give them their security information and do it when they're committing code. So really take that shift left approach, you also want to have a robust set of application security testing capabilities. So I spoke about that a few minutes ago. In terms of, I should know the number. I think I know GitLab would do about seven or eight different types of security scanning, all just within a pipeline as we're producing an application. And this could be whether you're producing a Java app, a swift app, or even provisioning terraform as well. With this, you want to have your security policies automatically applied and exceptions documented. So what this means is when you're looking at your apps, for example, you might have a hierarchy, you might have your tier one apps, you might be a little bit stricter with what you allows out in production versus potentially lower tier apps or internal. If you are using incumbent scanners, you want to have those integrated. And as I've mentioned, just one cost, regardless of number of scans and apps scanned. So coming back to my people, process and technology, when you have people and process you can scale when you have people, technology you can innovate and process, and technology you can automate. When you have all three, that's when you can drive true business value. And what I mean by that, you can improve your operational efficiencies, you can reduce your security and compliance risk and fundamentally deliver better software faster. And what this means is, if you have an idea, maybe you speak to a customer, someone in your product team, you have an idea, okay, how quickly can we deliver that idea for our customer and outperform our competitors? How quickly can we improve our software based on feedback? How quickly can we iterate? How can we drive true business value? So thank you so much for listening. My name is Stefania, I work at Git. You can find me on these different handles. Please feel free to connect with me. This is also part of QCon. So thank you so much for hosting and whether this is live or watching the recording. Thank you everyone for listening and look forward to catching up in the future.