Are you ready to leverage DevSecOps? Get ready and use it for good.

In that same vein, you should make sure somebody understands the quality team and how they can do proper tests. And most importantly, later we're gonna be talking about agile advocates. You need to have at least one person on each one of the dev teams that has a familiarity with what really is security and can ask you intelligent questions and point out things to you. So you're not asking, when we say subject matter experts, we don't really mean expert, we mean has better knowledge than the average person. Alright, someone read a Medium article and this is super trendy, so we're obviously gonna do this in our organization, right? You can, but please don't just implement it without training everyone involved. And don't just rely on

articles on the internet. Like, there are good books written on this. And they're not long books. You can even have them as audio books if you don't actually like reading. So get everyone on the team to do that book together over the course of a month or two and then discuss it. One thing I used to say when I was an Agile advocate was you don't have to do Agile the same way everyone else does, but there are certain principles that you have to obtain that principle. So the way you get to that principle can vary, but you all have to agree on that principle. So as a team, you all need to decide what

is the first thing you're gonna do in order to achieve that goal and then try it. And if it doesn't work, iterate on it and improve. And this applies for them applying security practices. So if you want them all to do a particular thing, say like, okay, let's try this little piece first, everyone give it a go, and then let's have some feedback around it. So trendy is not always bad, but yes, I 100% agree with all of you. If they're just throwing some buzzwords in there so they can get some more money, it's probably gonna be crap and the cat's gonna murder you at that point for putting glasses on. All right, so shift

left, except my left is your right, so it would be shift left. why are we shifting things left? What are we shifting left? What is it going left of? Well, the simple answer is we're trying to move things in the SDLC as far to the start of the process as you can get it reasonably so that later on in the process you're not doing a scramble. I'll get into that in a little bit more detail next. So first step is requirements gathering. This is probably the part that everyone's been involved in. Somebody comes around and asks you, like, what is it we want the thing to do? Well, as the security team, or the security advocate, put in there, before we actually do anything, I want

the bottom line of the requirements to be that we've done a threat model for this, and security gets to do a sign-off before it's done. Get in there as early as you can. wait for them to get somewhere down the process and be like, yeah, let's plan for a security review. Make it like, no, I want the developers to work with me to learn how to do threat modeling. They do it and have me review it. You don't have to do all of the work. You can teach people how to start some of that for you and then you can review it. So start of the requirements phase, get all your project managers to put

a security line in there. If you're doing DevSecOps, You are an important part of that process, meaning you get to put some requirements in there and you can say, I require that we're gonna run security scans and I require that we have a threat model. All right, so next comes design. This is great, everybody is doing the design, they've done the threat model for you, but I mean, we're all about agile, we wanna be reusing things, right? You have how many dev teams and they're all probably doing stuff that's somewhat similar? Why don't you have a repository that any senior developer has access to that they have clear tags and labels on? So somebody can see like, oh, somebody did a mobile app over there that's similar to

the one we're doing and security already signed off on that. Why don't I use that and just make a couple iterations to that? It'll make it a lot easier for me to go forward and maybe I can reuse their GCP or AWS configs. Wouldn't that be great? Less work for me and security already signed off on it. make these things as easily available and findable as possible. And when you're going through it with someone and you're like, hey, over here you said TLS, we have a policy for that. Note, please have policies. Please make them easy to read. If you have technical writers, have a technical writer review it. Because if you have a policy

that makes me wanna stab myself at the spork, I'm not gonna read it, and then I'm not gonna do it. But if you have someone go through and make it easy to read, or you point at things like, just go follow the Mozilla standards, if there's one out there that's already well written, You can be like, remember when you're implementing this, I'm gonna link you to this policy. As long as you follow that policy, I'm gonna permit that. But if you don't follow that policy, you're done. All right, so now you're doing coding. This is where you get into having the automated quality tests and automated security tests. Wait, again, testing. And I'm just gonna go to the next one. This is the most

important one. You don't actually get to fire anyone. So if there's any managers in the room, just because you've automated the test, doesn't mean you don't need quality people. The quality people, well, quality engineers, sorry, are going to be able to go through and find specific things. Automated tests are going to look for, well, did this respond with what I was expecting? I'm going to give an example from my favorite quality tester that I ever had, named Arthi, she was amazing. She went back and forth, back and forth, back and forth, back and forth eight times and then entered in the thing and then it exploded. And I'm like, why eight times? She's like, well, and I did it. times one through six, nothing happened. I'm like, well

what were you gonna do if the eighth time didn't do anything? She's like, do it a couple more times. I'm like, why? She's like, have you ever seen someone who's frustrated with an app go back and forth? I'm like, yes. She's like, users are gonna do that. And I'm like, you are correct. So it is unlikely that your developers are gonna automate it to do back and forth, back and forth with the back and forth buttons. This is why you need security people. They're gonna be like, well, This API is secure in its own and this API is secure in its own, but when they're passing it through and it's going through that point there,

I bet if I sat something there, I could get that data. Yes, yes you can. So automated tests are gonna find the low hanging fruit. You still need your people to find those complicated items. All right, so deployment and maintenance. I bet a lot of you kind of get annoyed because once something goes out to prod, everyone's like, we don't need to worry about it anymore, but that's sort of where it's the worst because if you don't patch then, dun, dun, dun. especially if you don't put passwords in the S3 bucket. So make sure everyone is planning in the development and maintenance stages that there are occasional scans that are happening and occasional checkups. Nothing

is ever gonna be 100% secure, but if you have each one of these security check-ins and all the steps of the SDLC that we talked about, you've got security in depth and hopefully you are less likely to get breached or at least you'll be harder and someone will have to work for it. So security is code. I mentioned this a little bit earlier. Right now, a lot of your deployments are happening through config files. Do you know what those config files do? You should probably have someone on your security team actually understand the 50 bajillion settings in AWS that are related to security. And the nice thing is, once you figure out those settings and

come up with your recommended config file and pass it out to your devs, you can say, this is our standard. If you wanna deviate from it, you have to talk to us. But all the devs will be like, wait, does that work? Ah, okay, done. Why are they gonna reinvent the wheel? If you give them a thing that works and you have made secure, everybody wins, everybody's happy. So that's security as code. All right, now here's the other thing. Trust but verify. We've now gotten into the world and Zero Trust gets tossed around a lot and it is important, but you're kinda outsourcing a lot of stuff. You've got cloud providers, you've got maybe third-party

software companies that are SaaS, So even if your dev team is running security scans and doing everything that they say they are, are your vendors actually doing that? You don't have to constantly double check their work, but do random spot checks. Literally, grab a D20, roll it. If it comes up on a three, today we're gonna check if this vendor that said they were gonna do X actually did it. Read the report, verify one of the things in it. So what you don't know can hurt you. This applies to engineering, it applies to anybody else. So don't let them say, oh well, we don't wanna look there, it's not necessarily important. If you don't go look at showdown to see what you've exposed on the internet, doesn't

mean that nobody else is going to. So show them videos from conferences, show them articles that say look, Just because you don't wanna scan our entire IP space, look at what these people do. It's called Showdown Safari on Twitter. Look at the nonsense they find. Do you want us to end up there and get breached because we just didn't look? So hopefully that helps them kind of realize you can't just hide. The most important thing is you don't scale. I mean, if you have infinite money, please hire me. I mean, I like my job, but infinite money, can't argue with that. So since you don't scale, you have to rely on automation. And in order to get effective automation, because you can automate anything,

and whatever you automate could be wrong. This is where we get into, you need to take a couple devs and explain to them how you're thinking and what you want, and here's why I'm automating this. So they can help you do the automation, because you may not have that skill set, but they at least know what outcome you want. DevSecOps, you're one of the important things, so you should be able to get prioritized. If you're not getting prioritized and they say they're doing DevSecOps, kick up a fit, because you are literally a KPI. All right, so what is this whole secure bit in the middle here? Everyone's actually starting to notice security is everyone's responsibility and it's not a differentiator anymore. Before, if you were amazingly secure,

you were differentiated. Now that's a cost of entry into the business. You don't wanna be the company that got breached and everyone had to get the replaced credit cards and then you become a joke. So you need to get the engineers to understand how it relates to them. So a lot of times they're like, oh, that's, you know, Target, that's not gonna happen to us. Well, it's like, well, there was actually a particular vendor who went in and did a config issue and we use vendors and that could happen and this is why we do this kind of scan. So you're trying to get everyone to understand how all of this nonsense in the news relates to them. Maybe you wanna do a

lunch and learn or a weekly email and just make it relatable. Here's why we care, here's what of that actually matters. Because a lot of it's fun. You all know a ton of those articles are like, this guy is falling. And it's not actually falling, but you can take the chance to explain that to everyone. And you probably have a bajillion tools in your ecosystem. Every single one of them is a touch point. So you wanna make sure everyone understands, hey, every single time you have a different login, any of those are breachable. Every time we have connections and data paths between any of our systems, that's breachable. So the more tools that you chain

together, the more work you have. Here's the plug for me. GitLab integrates everything so you have less logins to worry about. But regardless of with you, use me or a variety of tools. Just make sure maybe there's a password manager deployed to all of your developers. and there's a two factor authentication turned on for everything. If you do that, you've just reduced how much risk of somebody introducing something into your pipeline? An amazing amount. Because a lot of the breaches that happen are because someone had a token that they checked in. But if that token has a two factor on it, it's gonna be useless. So, let's see if my little thingy works. Yay, okay, perfect. So where do we really want the secure

part of the DevSecOps to be? We want it to be right here. As I am writing the code as a developer, I want instant feedback on the work that I personally did right now. I don't wanna know about something I did last month. I don't wanna know what my teammate did last month, so right here. So ideally what you're trying to do is as I'm writing that merge request, go run the scans there, your automated quality scans, your automated security scans, your regression scans, and tell me right away that there's a problem. And give me as much information as possible on how to remediate that so I don't have to go to the security team.

Then, if I do find a problem and I don't know how to fix it, if you have grown those security advocates internally, they can escalate to that person first and say, well, there's this whole thing about a cross-site scripting and I'm not really sure what to do about it. And they can be like, oh, this is how you remedy that. And then that's not somebody constantly coming up to you. Now, if both the security advocate and that developer don't understand how to fix it, they obviously wanna be able to escalate to you. So make it easy that there is someone on your team who is always available. Even if they don't have the answer, make

it so they can reach out and get you and you are like, I will get you an answer by X or at least I will give you an update by X. Because if they feel not heard, they're probably just gonna ignore scan results and that's not what you want. Which actually we're gonna get into ignoring low scan results later, but that's a whole different thing. But if it's a critical or a high, you want them to escalate to you and say we will find the answer and we will work with you. And then where you really wanna be spending your time that makes it valuable is on prod. Because that's where the good data is

and that's where the most risk is. So if you can spend the majority of your time scanning and verifying all the different 50 bajillion prod environments you have scattered all over the place, that's where the most value is gonna be. All right, so there's a lot of different types of scanners. I'm gonna go through it quickly because I know some people do and some people don't know about how they work. And just so you know, we've got most of these all built into our different stages.

runs against the code and it is specific to pattern matching. So think of it like your spell checker in Microsoft Word. And it's gonna find API keys, or sorry, secret section. It's gonna find your API keys, your tokens, it's gonna find particular hash types. And so this is really good for just checking did somebody accidentally put some tokens in there. And now we get into SAST, which is the same thing, except instead of looking for tokens, it's looking for fingerprints on a specific language. And so it can say, well, this could be a cross-site scripting. This could be a SQL injection. The one downfall of SAST is it is not actually going to tell you if it is exploitable. So there could be a mitigation a couple

lines above or a couple lines below. And so you're gonna have a lot of false positives with this. But it is a good place to start. All right, so with dependency scanning, also known as third-party libraries, depending on how you wanna term it, I'm sure everyone's heard that patch, patch, patch. This is kind of the same thing. Third-party libraries, if you use one that's outdated, may have a CVE or another vuln against it. And if you are reliant on that, you are now possibly going to be able to be breached by that. Even though you didn't write insecure code, somebody you're relying on. So there's a lot of scanners out there and they will tell you, hey, this thing that you're using has a CVE,

so you need to upgrade that. And upgrading it can be painful, but you should be able to run it hopefully in your test environment and see how many things you need to update in order to make that work. So container scanning, if you're using containers in your environment, there's things like Claire and that will actually scan the container to see are any of the layers of this containing things with CVEs. And it's not checking for live breachable things, it's just do any of the pieces that contain this config have things that are known to be just insecure. But that's a great place to start, especially if you aren't doing any of that right now. So license compliance is a little bit security, a little bit not. Some licenses

will make you open source your code. If you have secret sauce in your code, you don't want to open source that. So you may wanna look into the different types of licenses if you're unaware of that, and as a company, prohibit certain ones. It's gonna be classes of them. All right, DAST is smarter. So before we were talking about all the things that are gonna run just on the code itself. Now here's things that are gonna run against running code. So DAST has the downfall that although it's language agnostic and it's running against the environment, you have to have fully working code. So if the code isn't compiling, or you don't have enough bandwidth to

have the environment be robust and handle a lot of traffic, it's not gonna be able to run. But once it is running, it's sorta like SAST in that it's looking for certain types of vulnerabilities, but then it tells if it is breached. So I was saying before, is this SQL injection usable? Well, no, I tried to do a SQL injection and it rejected me because there's actually a WAF in place. Oh, okay, we can ignore that, not a big deal. All right, I asked is DAST got smarter and has agents inside and looks for logs? So if you can do, I asked to do it, but it is more expensive, so I'll just kinda put

that caveat on there. Alright, fuzzing is a lot of fun, and baby ducks are fuzzy, but it's very noisy, and it is not realistic, because it's just throwing random stuff as much as a cat. And that is going to find some problems, but it's not necessarily going to find realistic problems. So I would leave this off until the end, But if you can occasionally on a weekend or a long holiday weekend let a fuzzer run wild, it can find things like buffer overflow. So I believe that was actually how Heartbleat got identified was somebody ended up doing some fuzzing in there. So if you do have time to set it aside and run it, but I would not rely on this constantly. All right,

so tons of scanner choices. Where do you start? Well you probably have some security bugs that you have in your backlog right now, right? Can you try and look at your threat models, look at the bugs you found, and pick a theme. Does that theme match one of the particular types of scanners? Start with that scanner, and then start with the highest risk projects, and go from there. You can't turn on all of the scanners, you will drown in results. And also, don't look for everything. Start with just critical, and then maybe just hide everything high and below. you need to put in the effort where it matters the most. Some people are like, we need to kill all of them. It's like, no, you need to

kill the most dangerous one. So if you can identify this piece of software over here has access to credit card data or social security data, start there before you get to the PII data. Okay, PII data totally next. After that, it's like, okay, well over here, people could make us look goofy by messing with our website or web forms or whatever. Like, okay, fine, that's third. Like, you do wanna prevent that. But that is definitely third in the list of priorities. So, specifically, I was talking about targeting different things. Exclude your test directories. Exclude any directories that are static. Like when you look through your code or have your developer look through the code with you, there are probably areas that you're like, that is super low

priority and or that's static and or that has access to nothing important. Exclude them. Why even scan them to start? Like eventually, yes, you would love to scan everything, don't start there, because if people have 100 page reports, they're gonna die and ignore you. So then the next thing is, you're gonna go with the criticals and work your way down, and as you're working your way down and people are putting exceptions, don't allow the exceptions to be a one-off. Don't have everybody just stick it into the software and then wander off. Have a centralized list somewhere, secured, not open publicly, that says, okay, well, we can ignore anything that says LDAP because we're not using LDAP here. We can ignore anything that says this particular thing because we're not

using that. So if I research that and confirm for project X we are not using Y, I should be able to share that information with everyone else who's gonna be able to also dismiss those. And if you can actually have something parse the JSON results and go through and automatically reject those going forward for you, maybe have the devs help you write that, that's gonna save you a bunch of time because you know anything where the vuln is specifically around this, we're not using that part of the library. or we are not using this particular thing in our environment, so we don't need to worry about it. And instead of having everybody research that individually,

centralize it, make it easier. And you can do that as low key or as high tech as you want. It can literally be a shared list between the team that they automate in, or it could be actually in some particular software where you're actually able to configure it to smartly do that. All right, so dev training. So we said that we needed to have security advocates and we needed to have the developers aware how to write secure code. And they're not coming out of school with this knowledge. How do you give them that knowledge? Well there's computer-based training classes and there's also customizable classes. I've listed a couple here. There's obviously a ton more. And the key here is it needs to be language specific. So if part of

your organization, which is usually what we see, is part of the organization's this language, part of this and part of this, usually people are not unified across their entire organization if it's a larger organization. So you have to get different language training for different groups of people. It is going to cost you more money, but it's going to save you in potential fines, breaches, and shenanigans later. So just invest in that. And if you want to start with the CBT-based stuff, which has all sorts of meanings, alternate, meaning computer-based training in this one, please start there. It's not as great as live training, but it is a place to start. So the next thing is, have any of you done lock picking? Did you have

that moment of, oh shit, that's on my front door? Give the developers that moment. Show them Burp Suite, Zap, all sorts of other things, like, oh, when you talk about doing that, that's what you mean. Shit, that was easy. That's exactly the moment you wanna give them. They will then actually think about security more, because at the top of your head, when you're doing things, you're not thinking about, So if you're thinking about, I need to make this software do this thing so the project manager is happy and signs off. Oh, and I remember how easy it was to pop a web form. Let me pop in a couple things here. All right, so if you do have security advocates, please make it volunteer based. If

you make it assignee based, people are going to not be excited to learn. They're not going to be passionate about it. They're not gonna wanna share what they learn with other people. They will do just enough to check it off on their review for the annual whatever and move on. But if you make it volunteers, you're gonna find people who actually are like, hey, this is kinda cool. You might even find people that eventually come over to work on the security team. All right, so.

How do I summarize this? I'm trying to summarize all of the things because I talk a lot. So a security advocate is a developer on the development team who has an interest in security They're now going to be your subject matter expert, but again, expert just means better than the rest of the team. So depending on the maturity level of the team and how much they know about security, it could be that much more. And then the team moves up here and then that person has to move up there. So it's a moving target, but they just need to know more than the other devs. And they're gonna be your eyes and ears. If none of you have ever brought in snackies for a developer or a project manager

and had them complain about their project, and accidentally find out about security issues that nobody raised to you before during that session, you should try it. And this is basically what you're institutionalizing. You're institutionalizing people who hang out with you and chat with you and you're gonna get a heads up on things that you otherwise would not have had the opportunity to find out about. Give them stickers, give them coffee, give them veggies and ranch dressing. Whatever it is that makes them happy people and wanna hang out with you, Give that to them. Alright, so how do we keep getting them to be up a little bit, right? Because I said they have to keep being slightly ahead. Well, can you have like your own

little mini CTF team? Like wouldn't it be cool to be a security advocate? Like once a month we get to do a CTF in the afternoons on Friday and they feed us. I mean, it's probably not very expensive for you to run. There's a ton of free CTF stuff, right? And they learn a bunch of stuff. Especially if you made me CTF your own software A copy of your own software in a protected dev environment. Also, what about lunch and learns? I mean, you probably are gonna learn lots of things here. Can you go back and do a lunch and learn where you all watch one of these presentations and munch on your lunch? Can somebody who goes to Defcon come back and give a report to everybody

else about the cool stuff they did and learned? Or maybe somebody did a CTF on their weekend. Can they go through, like, I did this hack the box level. Let me tell you about it. Also, have a repo. whether it's Slack or whatever, or you're sharing good findings and then tagging them. This was a good talk on cross-site scripting. This was a good talk on Ruby and preventing bad OAuth stuff. Whatever it is, tag it, have it, so that somebody else who comes into the program later can benefit from all the prior knowledge, because otherwise, it's just, you're gonna have to repeat it all or find it all again. All right, so you're trying to grow these people, and The end goal of this growth is one per team.

And with Agile teams, they have the pizza rule, right? So it's supposed to be about eight people, because you're all supposed to be able to eat a pizza together. Which I mean, like, some people don't like pizza anymore, but whatever. Like, approximately that number. So you wanna have one per, that's a lot, depending on the size of your organization. Which is why I'm saying start somewhere. Start with just having like two or three security people throughout the organization. Maybe you have one in product, Maybe you have one that's a principal engineer. Maybe you have one in infrastructure. Just start with a couple. And then remember, we're going to make it fun. There's going to be

CTFs. There's going to be stickers and all sorts of things. Then it's going to start to grow. And these people are volunteering in. Don't make it a huge time commitment. Just make it a learning thing, that we're going to learn one thing a month. And you're going to be slightly more knowledgeable than everybody else. We're just going to keep growing it. And it's going to grow itself over time. This is not a speedy process. All right, so here we go. This is the most controversial slide that I have for some reason. Don't say no. Literally, take the word no, remove it from your vocabulary. You can say, how about we do this? That method's vulnerable. Let's look for an alternate method.

I don't think that's a good idea. We have to do this another way. There's a million ways to say no without saying no. As soon as you say no, People stop listening to you. They don't give a shit. They will go find a way to do the thing that they want. Oh, I can't transfer files? Well, I'm just gonna go start Dropbox and move things around and then suddenly you're shitting Dropbox that you really didn't want there, right? Shadow IT, that's terrible. So do not be the grumpy cat. Like plaster on the smile and be like, okay, you need to transfer really large files to whom, how often, where internally, externally, let's find a solution and we're not gonna use Dropbox.

All right, so how do we know we got there? I mean, nothing really matters unless you can say like we got there. So the business is gonna be like, all right, we're not in a breach? Does that mean we're there, we can stop? Well, no. We're gonna turn on the scanner, And I'm gonna warn you, there's gonna be a bajillion results. Our graph's gonna go nothing, and everyone's gonna scream. But that's okay, because then the graph's gonna change over time. So that's where we're gonna start. So just say, for the baseline, numbers are high, because now we know about the risks that we have. And every time you add a new scan, you have to re-have this conversation. I know it seems like I just had this conversation with

everyone. I don't care, go have the conversation with every single manager in C-level again. Hey, we're about to turn on a new scan again. We're gonna have a lot more vulnerabilities coming in. We expect that and that's perfectly okay because then we now know about the risks that we have instead of having things that we don't know about come in and cause us to be in the news. Have that conversation, have it calmly be able to answer their questions. If you have somebody who really is good at that type of presentation, go send them around and then reward them with like a Starbucks gift card or something for going through that effort. All right, every

time you hit some kind of awesome place, celebrate it. There is way too often that on security teams and on developer teams you just keep pushing out code and pushing out fixes and it's one thing after another and like, oh, this is exhausting and everything's terrible and everyone's trying to breach us. Yes, that's true. But how much stuff did you stop in the past month? How many things did you improve in the past month? did you educate in the past month? That all counts, that is all amazing work and you should get credit and kudos for that. And so you need to make sure on the security team and the dev team that you are

saying, hey, we did this training and we stopped having as many new high and criticals come into our environment. It dropped by 15%, that is amazing. And send out an email to everybody and let them know you appreciate that. Okay, we implemented a scan, everything jumped up, but the number of new production vulnerabilities decreased. Our pre-prod ones increased, but then you all fixed them within one iteration, and they did not make it to prod. We found 200 things last month which we prevented from going into production. Take all of that stuff and make sure you are thanking everyone. I know it seems hollow, but Like when you see a message on Slack or in your email saying like, so-and-so

was on this call and really rocked it or so-and-so like prevented this bug in prod, doesn't it kind of make you feel warm and fuzzy? Lots of people get that feeling. Send that email, it seems goofy, just do it. All right, use your data wisely. I'm sure we all know like AI, you can do all sorts of crazy things and statistics, it's all a lie. Well, it's true, so use it as transparently and honestly as you can Also, call out specific things. Are there certain types of issues that are being found most frequently? Okay, well, we're seeing a whole bunch of tokens being checked in, and we really don't understand why this is happening. Luckily, our scanner's catching it, but how do we prevent that?

Maybe we need to do training around that. Are some teams doing better than others? Can that team do a lunch and learn for all of the other groups? Or is there one team that seems to really be struggling? Maybe you should be spending some quality time with them in bed yourself. So just use the data, don't punish anyone for it. If anyone's heard about like phishing things and like some people are terrified, I clicked the phishing link, I'm not gonna report it because now I'm gonna get fired. That should not be something in your organization. If somebody reports a phishing thing, even whether it's a real phishing thing or they just were overly cautious, be like, thank you for reporting it. Can you tell me if you clicked

it? Okay, you clicked it, that's okay. Let me go check on some things. Okay, well we're just gonna have to run these scans on your computer now, but we really appreciate you coming to us to make sure that it would be found before anything bad happens. Be calm, work with them, don't punish them, otherwise no one is gonna tell you when the bad shit happens. You wanna know when it happens. All right, so in summary, get the engineers to set aside time for automation and scripting. This means the project managers or product owners You need to remind them, DevSecOps, I need some time there. And also, if they're not setting aside time for tech debt, also be like, by the way, tech debt, because otherwise that's gonna slow us

down and bite us later, because tech debt will lead to security problems. Also, get everyone to get security training. There's already a training budget somewhere, because you've got the OWASP thing you have to do, so talk to your compliance department. How much does the compliance department have? Can you find a dev-centric language specific training that also includes the craft that compliance needs, yahtzee, no more money spent and you're winning. And also trust with verify, remember roll a D20 occasionally and be like, I'm auditing that. Because if you don't check it, you never know if anyone's actually doing it. All right, so in summary, target your high risk areas, look at your tools and processes and decide like, how do I get security involved and part of this

like as an integral part. So people don't even have to think about it. Because if they have to think about it, it's not happening. And developer advocates. You need them, you wanna grow them. There's a feedback link, yay! Any questions? Yes?

So the question was, at an initial engagement, what do we do and why? well I write tools for developers to write more secure stuff so it's less of an engagement, more like how are we gonna integrate these scanners into your software so that the red team finds less? And so that first thing is, hey, have you done a threat model? Can I see which databases contain your most sensitive data? Or can I see on your web interfaces which things have the most customer access? And it'll start with, let's turn on the scanners there. Especially do you have a prior report from a prior or anything, can I look at that and see what types of

things they were finding? Oh, the majority of things they're finding is this, that's the type of scanner that we need. And so maybe a WAF is like the first thing we need to do out of the box and we will turn that on. So it's really using historical data for where is the sensitive data and where have you messed up before, because you're probably gonna continue to mess up there until there's training.

end-to-end tests with like Jenkins or Selenium to mimic those same kind of scanners because essentially on a web form, what if I toss in parentheses, what if I toss in single parens, whatever, unfortunately that means you're kind of having to write it yourself. So target the OS top 10 and have at least one test for each one of those types of things and have the developers be integrating those and like have a checklist. Like can I write a test for X because it's a form or can I, and so that is unfortunate but

Aggressively agile organizations, how do you get the scanners in there, especially if they're not mature?

How do you find the false ones? So to settle a dispute around is this a true finding or a false finding? The best thing to do is the same thing that would happen if a quality scan came back and failed. If you can write me a unit test that proves that it's not working and show the results to me in either a recording or whatever and then dismiss it with that result. Because if you know what a SQL injection is and you can write a unit test that does some SQL injections and proves it's not actually impactful because we've got a WAF or because there's this other mitigation or if they can point you at that specific mitigation line, that

can do it. You can say you are allowed to push it as long as you've hit this and entered in this field and then later you can go back and verify that video. So you're gonna be at a slight lag to them but at least they put in that test with that video or screen cap.