You. I am Tanya Jenka and I am at Conf 42, devsecops. And I am here to talk to you about how devsecops, in my opinion, is more than just pipelines. I want to talk about the three ways of DevOps and how we weave security through them. And try not to be super annoying like a person that's petting a cat backwards just all day long. So let's not be that guy. And so, yeah, let's go. So what are we going to talk about today? The fact that DevOps is not just pipeline. There's so much more than just a pipeline. So it's basically like an industry word now, almost like a swear word. Like we say devsecops and we just assume a lot of things. Like, we're like, oh, I'm going to just buy a whole bunch of security tools, put them in the pipeline, and my apps will magically be secure. And so I think that Devsecops is not. That tools are awesome. They help us do our jobs. But it's more. To me, Devsecops is Appsec plus DevOps. And quite frankly, it's DevOps too. So we have to secure the ops and we have to secure the apps. So we're also going to talk about Appsec program goals that work with DevOps, but wait for it, that are outside the pipelines. What? I know. Okay, so let's go. So you're like, who is Tanya? So let's do the mandatory about me slide where we try to convince you that we are qualified to give the talk we're giving. So I founded a small little company called Wehack Purple that did security training in Canada, and we got acquired by Semgrap this summer. And so I'm now head of community and education at Semgrap and I'm really excited to be there. I'm known as Shex Purple. And yes, my hair is just like blending into this shirt because it's the exact same color. But just pretend that's not happening. I wrote a book called Ellison Bob, learn Application Security. I am on year 27 of my journey in tech. I'm an advisor of a bunch of companies, including cloud, defense, IEA, NordVPN. I am like a blogger. I had a podcast. I just ended, like, I do live streaming, also time. I'm a nerd at large on the Internet. And I hope you're like, yeah, she seems all right. I'm willing to sit through 30 minutes of her talking about her ideas of securing DevOps. So let's go. Okay, so what is DevOps? So you're at a Devsecops conference and you might be thinking, oh my gosh, is she really backing up that far? Please forgive me. Give me like 1 minute to explain to bring everyone that's junior up to the same level as you so that we're all speaking the same language. So a CI CD stands for continuous integration, continuous delivery, and sometimes continuous deployment. Continuous integration is us taking all the different pieces, smooshing them together and making sure they work. Integration testing manually is really complicated and terrifically painful. And so that's awesome. So then continuous delivery means using an automated system, often called a DevOps pipeline or a release pipeline or a CI CDE. And what it does is it puts all the pieces together and automates it. So it's a lot less painful. It's sort of, if you think about like an assembly line when they made cars, it just made it a thousand times easier. That's what CI CDs do for us. It's so wonderful. Continuous deployment is where we have so many lets and so many assurances and so many things that we feel no manual intervention is needed. And we just push code, it automatically kicks it off, it does all the tests, and if everything passes, it just goes out onto the Internet, into production, into the world, without any manual intervention. Not everyone does that. And by not everyone, I mean like, most companies don't do continuous deployment, they just do continuous integration and delivery. And that's cool. But these tools help us do our jobs better. So why didn't we continue to do waterfall or water fail, as I affectionately refer to it as? So if we do trunk based development, so we're constantly checking things into the main branch and making sure that everything works properly, right. We can do just like a way better job. There's less risk by doing tons of tiny changes that we check and check and check versus doing one giant, huge, mega big change. How do I say this nicely? We used to do huge change as a waterfall, and then it would just crash at the bottom. We wouldn't get feedback for a really long time. And so trunk based development involves a lot of feedback automation. So if we can automate things instead of doing it manually, it goes faster, it's less boring, which I don't have on there, and we have higher accuracy. Computers are really good at repeating what we tell them to do. They're not so great at thinking for themselves yet, but they're really good at repeating what we tell them to do. They're great at following instructions the other thing is, if we're testing integrations over and over and over again, we have less errors. Our apps can work better. And rather than having one person go off and do all these changes, then they're trying to smash them into my changes. If we're constantly checking, it's easy. And so this is why CI CD, because it's awesome. That's it. Send tweets. Okay, so what is application security besides my fave thing? It's every and anything that you do to make sure your software is secure. So that's my definition. So it's a subfield within computer science. So you have computer science, then you have information security, then you have app. So this is kind of like my passion. I'm really excited about it. I try to help people a lot with this. I talk about it all the time. So then you're like, okay, so what is devsecops? And so my friend Imran said this, he's super cool. He teaches great. When he explained this to me, he said, tanya, it's what we've always wanted. It's what us appsecs folks do. But we're in a DevOps environment and we need to change so that we can work the way that they work. We still want the same things we've always wanted, though. So it's appsec, but adjusted to work nicely in an appsec environment or a DevOps environment. And so this brings us to the three ways of DevOps. And like, you might know these. You might have read the DevOps Handbook and the Phoenix project and all those awesome books. There's a new one, investments Unlimited. There's another one coming out that I pre bought on audible because I was like, I can't wait. But the three ways emphasize the efficiency of the entire system, not just your part. Fast feedback. So we want to get feedback that's as fast as possible, but to the right person. And the feedback needs to be accurate. And I add that part because security gets that part confused a lot. And then continuous learning. Sometimes this is called risk taking or experimentation. Sometimes it's called taking time to improve our daily work. And so all of those sorts of concepts go into the third way. And so whatever you want to call the third way, it's basically learning, experimenting, and then doing better and taking time, investing time to always do better, especially at one and two. And so what about pipelines, Sonya? So pipelines are part, they are part of the ways of DevOps number one and number two. So definitely efficiency by automating all the things and then by testing all the time, we're giving lots of feedback very quickly. Awesome. And if we're doing part three, we're probably trying to improve how we use the pipeline some of the time. And so pipelines weave all throughout this and enable us to do this. And that's great. But if you put every single thing into the pipeline, your developers will not want to be friends with you anymore. Yeah. And you're going to not do well at appsec. I found this out the hard way. My first time doing DevOps, I was part of an open source project and I was like, I'm going to run 100 tools. It's going to be amazing. And I remember my teammate Abel being like, Tanya, can I write code, please? Can you stop monopolizing everything? And I had to learn to do better and compromise, and I learned a lot by this process. And so I want us to look at, oh my gosh, terrible. So I want us to look at an application security program and some of the goals that we might set and how we can accomplish these, not just with putting a bunch of things in a pipeline. So we can do like, we can obey the three ways of DevOps. We can be totally nice and work with the DevOps folks instead of against them without messing with the pipeline every single time. So I do want to put tools in the pipeline. I'm not pretending I don't want to. I'm saying that we can do a whole bunch of other things than just that. And we should be doing a variety of activities, not just putting five pipeline tools and calling it a day. There's so much more to appsec than that. And so I want to talk about that. Oh my gosh, my automation is so bad. Okay, so the first goal of lots and lots of appsec programs is inventory, because you can't protect the APIs, the apps, the SaaS, all of these software products if you don't know you have them. And if you work at an enterprise, I assure you there are all sorts of things you don't know about unless you've done inventory. And so this is a thing that we do all the time in Appsec, like that we work on. That's very hard. And we don't need a pipeline to do inventory. So we can do domain scraping. We can put network agents on like on our servers that track our assets. We can Nmap, all the things we can scan for open ports, port four four three for SSL, TLS ideally, or port 80 if you don't use port 80 anymore. Anyway, you can look at your cloud to look at platform as a service, infrastructure as a service, like IEC running, et cetera. You can scrape your code repository. There's also just like tools out there. Now since I wrote this talk that you can buy that will just, it'll go on prem and in the cloud and find all your apps for you. And so if you don't know about it, it's not likely to be in a pipeline in the first place. Right. And so this is an activity we can do that does not need to interrupt pipelines at all. But that's super high priority for every appsec team finding bugs. So I want to find bugs in written code, in running code and third party code. And this is a goal of a lot of appsec teams to look from those three angles. So the code we wrote, the code we didn't write like libraries and frameworks and stuff, but that's in our app and we have to accept those risks that they might cause. But then also I want to interact with the app and test how it works. And so there's all these different ways to find bugs. Well, there used to be an old way that we did it. So we would do manual code review and we would do manual stack. So we would use a stack analysis tool, but run it manually outside of pipeline. We would run dynamic scanning tools manually outside of pipeline. We do a manual review of third party components and then we'd have a pen tester at the end that would be like, I messed up your app, what's up? But there's newer ways we can do this that are more DevOps friendly. So we can test in real time as apps are used. So that's a new type of tool called if does not need a pipeline. We can scan third party components in the pipelines, or we could scan it the moment we check our code in and give faster feedback. Right? And we could do it in our ide and we can schedule it to run every single week. We don't have to use the pipeline, we don't have to wait that long. We could do it way before then. We could do automated dynamic scanning that are scheduled scans that maybe run overnight so that we're not monopolizing resources when everyone else wants to work. There's all sorts of different ways that we can find bugs, and it does not mean that we have to put every single scanning tool in the pipeline. Do I want some there? Yes, let's be honest, I do. But I don't need them all to be there. There's better ways. And I want to be as far left, and by that I mean earlier in the system development lifecycle as I can. And so that means the ide for some things. Okay, so knowledge, I want my teams to have the knowledge to fix the bugs that we found. So that's nice. I found a bunch of bugs. What if you read it and you're like, could you please give me this report in English? When really it's just written in security nerd. So knowledge, this is the third way of DevOps, through and through. So think about this. We're talking about continuous learning, we're talking about risk taking. We're talking about taking time to improve your daily work. And we need to learn and educate ourselves to do that. And so there's just so many different ways that we can try to get knowledge and none of these things need. You could take a class, you can job shadow. There's just so many ways that you can get knowledge to learn. So this might sound weird, like education is like taking training and honing your skills where knowledge could be having a whole bunch of books that, you know, you can look it up in, having access to, let's say, LinkedIn learning. So the actual act of educating yourself is one thing, but just having access to a knowledge base where you can go look up things, having someone that is smart, that can help you find the answer, having brainstorming sessions is where you can find the knowledge you need to do the thing where education, or developer education, as I like to call it, this is also the third way. And so we could get reference materials and set everyone else up for success. We could do an advocacy program where we change the culture of the place that we work by advocating for secure software as a cause or as a policy. We could do a security champions program where we have one person per dev team that kind of champions the cause of security. And they make sure the security work gets done. And they share messages from the security team, and they share messages from your team back to the security team, like getting help, getting assistance, getting licenses, getting whatever they need. This could be lunch and learns. This could be time reserved every week for learning in their calendars so that you actually get it done. So between forming knowledge and having access to knowledge versus doing formal education, all of these things are totally in line with DevOps, and none of them require a pipeline for you to do. The next one is giving developers security tools. So you could give them a dynamic scanner, a static analysis scanner. You could have them create unit tests and then help them create security unit tests, you could create like buy tools that are able to just scan over your repo and find bugs. You could help them research different types of idE plugins that are super helpful. There's so many cool security plugins now. Compared to when I was a dev, there was like, nothing makes me feel old. Software composition analysis. Talk about shifting security left, right. So if you give these tools to software developers and they're using them during the coding phase, that's even before we're trying to release anywhere. You don't even need compilable code for a lot of these things. For dynamic scanning you do, but not for stack analysis or secret scanning or linting. And so give them the tools, let them take control. Right? Again, no pipelines needed. Okay, so a secure system development lifecycle. So this is the thing that frustrates me. Lots of appsec teams that I work with, they're like, we're doing devsecops. And I'm like, awesome, what are you doing? And they're like, we bought $100,000 worth of tools. And I'm like, wow, that's a lot of money. And we have put them all in the pipeline. I'm like, cool. And they're like, that's it. But what about the other phases? So what about during, like, what about having a set of standardized security requirements for software projects? So you're building an API. Awesome. Here are my security requirements for you for building any API where we work, a web app, same, serverless, same like, here's a list of requirements of what I expect from you on how to build this safely. Having a secure coding guideline and then teaching your software developers that guideline again, supporting them with reference materials or code samples if possible, review and respect secure design principles when in the design phase. Or do threat modeling in the design phase or doing a pen test in the testing phase. There's so many different security activities that you can add to your system development lifecycle. And devsecops does not mean putting some tools in the pipeline and it's failing it. Good. I secured all the things right. We need to fix bugs that we find. They also are usually like tools. Automated tools are notoriously bad for finding business logic issues. There's more. So we could assign an Appsec resource to the project team and do the partnership model. So have an Appsec person that's sort of like on demand for your team. Pen testers like penetration testing that happens outside your pipeline for sure. There's no way that they should be touching your pipeline chaos engineering happens a lot less often, but like a red teaming exercise, again would happen outside your pipeline. Monitoring, logging and alerting are so essential to ensuring that the applications you have created continue to be secure. And those have nothing to do with the pipeline, right? When you're responding to a security incident, if your app has been attacked, again, no pipeline doing security work as part of a sprint. So having a sprint in your project dedicated only to security, like where you fix all the bugs or you do threat modeling all day long, or whatever the thing is the security team has decided is the most important. Again, you don't need to access the pipelines, but we're totally compliant with the three ways of DevOps. We are being supportive, we are helping them create more secure apps, so tools that work outside the pipeline. So a big goal for a lot of Appsec teams is to implement useful and effective tooling. And that means we need, oh wait, that means we need accurate results, we need good coverage, we need valuable feedback that goes to the correct person. And so not all the tools that we have. There's still tools that are awesome, but that shouldn't go in a pipeline. So if there's false positives, that shouldn't go into a pipelines. If it's going to take like 6 hours to run, or even 16 minutes, it shouldn't go in the pipeline. Sometimes continuous scanning can be way more accurate, like scanning over and over and over again, like every 24 hours or every week or whatever. Maybe you're not going to run your pipelines for a few weeks because you're going on a european vacation and you're like touring all the hostels of Europe and you're not going to run your CI CD that whole time. Problems still could have happened, right? So you could do DNS based scanning, agent based scanning code, repo scanning. There are a lot and a lot of options of things you can do with tools that can be done outside the pipelines very effectively. Incident response so what do I want? I want a trained incident response team that understands appsac. Oh God, I want one so bad. Everywhere I work I get dragged in to the incidents because I am the nerd that understands software, right? And it's like, Tanya, there's this, an incident response team, they should never be touching your pipeline unless that's what's been attacked. You should not involve your pipelines. And so there's so many things you can do to enable an incident response team, like creating a process, circulating it widely, giving access to your inventory. So showing them the inventory that we made on the first goal so that they know when an incident happens, who to talk to, where the app is, et cetera, giving them read only access to your repos, access to tools, having a post mortem, doing training, et cetera. As a bonus, you could implement tools that help prevent and detect application security incidents. There's so much you can do with an incident response team that's really important for any information security program. None of it has to do with a pipelines. Another thing, metrics. So I am a huge fan of basing our programs at work and at home based on data, and so we can continually improve our program based on metric experimentation and feedback from any and all stakeholders. Because all feedback is important. And I kid you, not, all feedback can really be important, even if you receive feedback and you disagree with it. And then you need to teach that person the thing because their feedback is I don't want to change, ever. I'm sure you've all run into this, but you can use a pipeline to gather some metrics, but you can also gather a lot of things and use these metrics outside the pipeline. So for instance, every three months review all your tool output and then do a post mortem or ask for information from stakeholders. You could experiment to find better ways to reach your goals and measure to see how you do it. You can do proof of concepts of new tools and approaches on one project instead of all projects, and see if you want to proliferate that to all your other teams. You could visit other appsec shops and learn from them. If it's possible, you could follow industry leaders in this area so that you can learn more. You could attend conference and sit in on talks like this conference. Yes, you can form relationships with other areas of it in efforts to work better together. And all of that is part of the third way of DevOps. That's you being also really an awesome team player, just in general. And I'm going to take a brute deep breath and I'm going to do a summary. So we talked about program goals for our application security program and how we can reach lots of our goals without even touching the pipeline and bothering anyone. I'm not saying we should never put things in the pipelines, we totally should. But we should think outside the box and think outside the pipeline and do appsec in many ways, not just one way. Appsec is not a tool that you can buy. It's not a button you can press. There's no check you can write. Unfortunately. If you could, I would accept checks though. If you want sense, and DevOps is more than just pipelines. There's so much more than this. And so I hope that I've given you some ideas of how we can do awesome security in a DevOps environment without just throwing every single thing at the pipeline and potentially slowing everyone else down or tripping them up. We want to be careful and diligent and respectful when we are adding things to the pipelines because we're affecting every single person on the team when we do that. And with that, I want to give you some resources. So first of all, awesome books, the DevOps Handbook, the Phoenix Project, accelerate the Unicorn project. There's now investments unlimited as well, which I need to add to this slide. And then there's, spoiler alert, super biased. Alice and Bob learn application security. Me and my mom agree it's pretty good. The Sumgrap newsletter so I used to have a Wehack Purple newsletter, but Wehack Purple got acquired by Sumgrap and so now I'm helping to write their newsletter and it is chock full of so much content. But unlike before, where it was just content, I built, you now get content from Lee, Clint, Peter, Kyle, Milan. There's so many people creating content that goes in there now and it's pretty freaking good. You can join the Wehack Purple community. So it is still live and kick in with like over 8000 people in there, learning, hanging out, having events. We had an event yesterday, we have another event next week. All our events are free. The community is free. All the courses inside are free. Every single thing about it is free. There's no upsell. We're just like, please make more secure software. Every Monday on Twitter, on Blue sky, and on Mastodon, on the infosec exchange server. Every single Monday I run a mentoring matching program. So I am a terrible matchmaker. I'm sorry. I've tried so many times and every single match I've made has been a disaster. So I have learned instead to allow people to match with each other. And so if you want to give back and take someone under your wing, respond to someone who's on this thread, you'll make their entire year. And the reverse is true. If you want to get into cybersecurity, if you want to perhaps change from one subfield to another subfield, or you want to perfect your skills, or try to just have a mentor to help take your career to the next level, use this hashtag. On Mondays, tag me and I'll retweet you to the whole world. I have quite a few followers now and please connect. Let me help you find a mentor. Resources me, I am a nerd. I am on the Internet quite a bit. I'm at Shehex Purple pretty much everywhere. I have my own website now that I threw together in WordPress. That is average at best, but I have a lot of resources there that are all free. I have a YouTube channel, I have a newsletter, and I just post lots of things. So if you liked this, you might like other work that I do. I have something like 22 or 23 different conference blocks now and a lot more stuff like hundreds of videos. I'm that person. And with that, I want to say thank you so much. Thank you to comp 42 for having me for the third or fourth or fifth time now. Thank you for letting me be a part of this community. Thank you, person that's watching this because you decided to watch this instead of the trillions of other cool things on the Internet. There are so many cat videos that you probably haven't seen yet that are pretty funny. There's probably XKCD comics you haven't read yet, but you chose this. So thank you. I appreciate you. And with that, I'm Tanya Jenka, also known as she hacks purple. And I hope that you secure all the things.