Adding DAST to CI/CD Without Losing Friends

hi everyone i really really appreciate snea and the entire besides team having me here and thank you for letting me present virtually because sometimes you just can't make it to the place you really want to be at so this talk is called adding dats to ci cd so adding dash as in like a dynamic application security testing tool sometimes people say oh yeah web app scanner and i sort of mean that yes but i started writing this out and then i remembered when people first started adding vasts to pipelines where i worked and i was the person adding them and it didn't happen exactly like this but it felt a bit like this so i was like i've added the scanner to

your pipeline and the software developers were like it is too slow this is taking forever and then we went through the results and there was a false positive in the tool because i was using a free tool it was perhaps like it i thought it was amazing at the time right and i i'm like but i found eight real bugs automatically um but they're like it's too slow and it felt like one false positive breaking the build is not acceptable so then i was like i should change the name of this talk from just adding dast to ci cd without losing any friends because if you don't have a good relationship with the software developers and if you're

doing devops with the ops team you're just so not only are you not going to be able to have coffee with the cool kids but on top of that it's like really really hard to get your job done without i'm taking off my sweater because when i talk i like move around a lot and i get really warm um but it's it's really hard to get the things you want done without taking everyone off if you're not careful and so we're going to talk about different ways that you can do that so you can put this tool in a pipeline and get really good results but also all the places not in a pipeline that you can put it

but still automate it and still get good results and a whole bunch of just other tests you can do etc so like who's this person that's friends with sneha so i am a giant nerd and i'm the director of developer relations and community at bright security um i founded the wehack purple community where you can take a bunch of training courses for free about software security my obsession i'm on the internet i wrote a book called allison bob learn appsec i did basically so the main gist of this slide is that i'm a nerd on the internet i've been a nerd for a really long time and i'm hoping that you will sit through my

presentation and give me a chance because you're like she seems pretty competent so that is me where i have slightly longer hair okay so what problem are we trying to solve because all of these talks that you saw we're trying to solve a problem and what we one of my main things i want to solve just in my career is insecure software um it's causing data breaches around the world it's the number one cause of data breaches it's not the number one cause of software security it's not the number one cause of security incidents it's not the number one cause of people having their money stolen it's people stealing all of your data which is the most

damaging type of security incident you can have i would like us to not win this occasion every year so every year verizon which is an american company makes this breach report and they've been doing it since 2008 and pretty much every year insecure software wins the worst title of being the number one cause of data breaches and i want us to do better um another problem we're trying to solve is if we're going to work in a devops shop and we're going to try to make their software more secure we need our tools to be accurate need them to go really fast and whatever we can do we need to automate so there's going to be

way more devops people than security people it's just a fact there's way way way more software developers than appsec people github released a report in uh january that said so it used to be one to one hundreds there'd be one abstract per person for every dev now it's 500 to one those are not great odds so we need to do we need to be accurate but we need to also be fast and try to automate and so if we want to do devsecops so us security folks doing security in a devops environment we need to test from multiple angles so we can't just do one test and be like i'm sure it's fine that's not good enough

we need to have good relationships between security dev and ops and i don't mean that like you have to give them hugs or you go grocery shopping with them but i mean that we have to be able to work with them and have a good relationship so i can say things like hey did you see those test results and the person answers you know something like yeah i did or i got the email i haven't had a chance to read it yet or yeah i've been meaning to talk to you i need them to not answer with go to hell tanya you broke our pipeline again i need to maintain a good relationship so i can get my job done

i have worked at places where the security team and the software developers were like that's just er all the time and i spent like half of every week just trying to put out angry emotional fires of people that didn't trust each other that didn't like working together etc and so if you have a good relationship you get twice as much done and then the last thing is i want bugs fixed as soon as possible and i don't mean i want them fixed on monday instead of friday i mean if we're following the system development life cycle so if you're doing waterfalls like this it's like requirements design coding testing release if you're doing agile you do that same thing but you do

it in a circle and you release a whole bunch of times if you're doing devops you do the eternity symbol where you're like yep got it got it releasing it got it releasing it got it release it and you just continue to release over and over again even more often than agile and so automation is our only way that we can keep up with those people and i want them fixing those bugs as soon as we find them or as soon as they have time i don't want things waiting until later i don't want the software developers or the operations folks thinking like is tonya ever gonna tell me what's wrong she ever gonna do a test

like where is that lady i want to be there for them and know i want them to know that i can help and so fixing books as soon as possible in the system development life cycle the reason i want that is because it's way cheaper it's way way cheaper that way so what are so today we're going to zero in specifically on das so right security bought my company a few weeks ago and they make a desk and so when they're like oh or you know you're gonna start applying to companies what you want to talk about i won't talk about that and how people can do it right because i see a lot of people buy

tools and they don't do it right and they don't get good results i want people to get better results so what the heck is fast so it stands for dynamic application security testing what it means is that your app needs to be running so it could be localhost it could be a web server it could be a container a platform as a service it doesn't matter but your app is running like you can see the software in a browser and then it sends requests at your app to try to find security vulnerabilities your app responds and it goes back and forth like this it can also do apis where it sends requests to your apis it receives the response it

goes back and forth and the idea is it's sort of a computer conversation and it just keeps trying to find all your vulnerabilities and it does this in an automated way so it's like hey how's it going oh it's not going so well oh is it going like this okay yeah and then from that conversation it starts crafting better and better tests it automates this for you so you could just like sit back and be like oh okay this is happening that's good it's different than static testing or software composition analysis that requires a copy of your code so i used to be a pen tester and they wouldn't give me a copy of the code

so i had to do all my tests in a dynamic manner where i was trying to talk to the app either manually or with a das tool but the idea is it interacts with your app to try to find out what's wrong and so why did i decide to zero in on that so when so i was a software developer for around 17 years i briefly took a a break as a system and then came back to software my true love and basically i started when i moved into security with a dynamic scanner i found it way easier than static analysis or software composition analysis i found it easier than trying to figure out because this

is a secret it's just a secret i thought it was the easiest one and i find a lot of people who are first getting into these things they find it easy too i also so maybe i'm not supposed to admit this but like the first time i ran a dash and i found vulnerabilities i'm like i'm a hacker and it felt very exciting and i know that might sound silly because i'm like you know in my mid 40s and i've been doing this a long time but i don't know how to explain whenever i find stuff i'm like yeah that's right i'm awesome but the last one which is probably the most important one is that your app is

out there sitting on the internet your api unless it has a gateway in front of it or a bunch of firewalls in front of it is out there sitting on the internet and on the internet anyone can point a dash data and scan it if you have a waff or you have other defenses you could probably shoot away but most the internet doesn't have a web application firewall or a runtime application security protection tool so like a shield for your app most of the internet doesn't have that and so that means basically anyone with very little skill can just point a dynamic scanner at you and find vulnerabilities there are usually exploitable and so it's the most obvious

place to start because that's where bad guys start unless you're open source they don't have a copy of your code unless they're an insider threat they can't test from the inside so a desk can just test from anywhere on the planet and it doesn't take very long to find problems and so i want us to fix those problems first because they are the most evident to people that might be malicious and so what is devops so this is a very short and small summary so devops is spoiler alert it's not paying one person to two jobs that's not what it is so basically devops is a newer way to create software it's a methodology and it's a culture so you

follow certain processes people act and feel certain ways and you often use certain tools to reinforce it so we're going to talk about it a bit more so sometimes people will say it's people products and processes i don't really like that i like the idea of us following the three ways of devops but i digress next slide so as so first of all if you're doing devops you usually have a ci cd so it's continuous integration continuous delivery or continuous deployment depending upon how you're using it but it's automated software that tests and releases your software and your infrastructure to different environments so it takes a copy of your code and builds it and tests it and then it's

like oh i'm going to put it on a dev server i'm going to test it again oh i'm going to build it like i'm going to take that artifact i'm going to copy it to the qa server i'm going to run even more tests and it does this with your infrastructure as well it can actually build the infrastructure and then plop your app on it and test them together and it's i think it's quite nifty so then if we want to do devops there are the three ways of devops so sort of like the three rules you need to kind of do these things if you want to get all the value that you can of devops and so the

first one is efficiency for the entire system and so when i see that i'm like not just your part tanya you have to like share with everyone and so that's important fast feedback and so then i added to that that is accurate and gets to the right to people it's nice if there's fast feedback that gets the right people but if there's fast feedback but it's totally inaccurate or like you can't actually see it or you have to attend 20 meetings to get a copy that's not and then the third way is continuous learning and improvement of your daily work sometimes people call this risk taking but the idea is is that you step back from your daily activities and

exert effort to making your daily activities even better on a regular basis usually every month the last thing i want to say about devops is that not all security testing needs to be done in the pipeline for you to be doing devops so you can do brief checks in the pipeline and then do like slow checks overnight like there's a lot of different options and so we're going to talk about that so let's talk strategy for putting a dynamic scanner in your ci cd so the first one that i see the most often when i i did at the beginning that made all the other dads pretty ticked off at me was to run my desk on full

blast and then lose all your friends so what i mean by this is turning it on saying do every test you know catalog all my different links test every single part of my whole app as thoroughly as you possibly can and then it might run like six hours or something and no one's impressed by that if the pipeline previously ran 18 minutes and now it runs 6 hours and 18 minutes no one's gonna be very cool with that so this is not the one you want to do in the release pipeline so the release pipeline is the one that everyone's using to release all their code so what you could do instead of this is that you

could take a copy of the release pipeline put it underneath in your ci cicd software and then make it so it doesn't release or it just releases to one safe place where you can do security testing and you put it there and you run the security test and then that's it and then the results go to the software developers or it goes to the security person so that they can see it and take action so that would be a better way to do it so you're not blocking production you can still get a very thorough test done so sometimes this is called a parallel pipeline or an asynchronous pipeline and you can run it nice and long and slow

and you can run it like every night or every friday and have those results get sent somewhere for someone to manually look through that so the next thing you could do is you could refine your scope by using a horror file so r h a r stands for html archive file so if your software developer or sorry your qa team are doing something using something like selenium to do automated tests of your app you can get a copy of that file that's a har file that they're recording when they do all of that cool automation you can feed that into your dynamic scanner and then it will just do that test you can basically make your your test 30 of the

time like instead it's like 70 faster or even faster than that because you're just testing whatever new feature you're releasing or you're just testing the new code or you're just testing what the qa person thinks is important and is this complete coverage no but this would be part of the coverage you do so it's like we're just gonna test this in the pipeline very quickly it's gonna take six minutes and if you break like if you do get a high or critical illness we're gonna break the build but for all the other testing we're gonna do it outside the pipeline and we still might come to you and need fixes but this is what we think is an

emergency and so it goes in the pipeline another thing you can do so when i first showed this app this um slide to people they're like you can't just test only what you want to test tanya i'm like sometimes you can so quite often um when i work places we'll have specific vulnerabilities we're targeting or types of bugs that we're targeting that are really important to us that we feel are particularly dangerous or we see a lot of and so in the pipeline i might just test for those like just injection or just cross-site scripting and that's it or maybe we have like a new um security policy and we just want to target in on security headers and like

no one's using security headers so we just test for that it's like you know what you're breaking the policy you know we're all looking for this so you can't go to prod but then i do my other extensive testing outside of prod and so that way what you could do is slowly eliminate a certain type of bug and then in a few weeks you change to a new vulnerability that you're looking for and that would be really really fast another thing you can do that i think everyone should do every single time is only do technology specific tests so let's say you have a wordpress application or website you would only do the like you you would

do the wordpress sites but you wouldn't do an mssql test because you would be running postgresql because that is what wordpress runs on you wouldn't do a ruby on rails test right because you're using wordpress and so on and so you just do the technology tests that are specific to what you're doing and so i always want to do this so if i'm scanning an app that's made in node.js and it's using mongodb i definitely want to do all the specific tests for those and i'll do other tests that apply to every type of website but i'm like oh no ms sql no wordpress tests know this know that and i just throw them in the

garbage because i know they just don't apply like if you're in azure you don't need to do aws tests right and so this is something that i generally do all the time because our time is valuable we're busy people um i wanted to say a quick note on testing apis if you want to test an api with a dynamic scanner in a pipeline or not in a pipeline it's very very important that your schema file or your definition file your open api file your swagger file whatever you want to call the thing that defines your api it needs to be complete and you can complete it using a linter and so some dynamic scanners have a

linter built into them like bright does there's a few that do that and so you just open up your api or there's separate like software things that just lint your api and they're very very thorough and so basically you use one of those and you open up your definition file and it will tell you things that are missing and so i used to be a dev and i did all of the mistakes that i tell people not to do now because i went to college in the 90s for software development and so i never learned that had to learn it on my own and so it will do things like so like let's say you've declared a vulnerable

you've declared a variable and the variable is date of birth so usually people will be like date of birth type date and that's it but the scanner needs to know what's the maximum date what's the minimum date does it can it only be in the past um like can a person be 5000 years old what is the format of the date etc so if you don't fill those out the dynamic scanner can't test that for you and so usually if you just take an open api file or swagger file and you plug it in most dash scanners like kind of barf they don't know what to do and they're like yeah it looks good to me i guess

because your file is not complete so you need to use a linter on it to make sure it is complete and when you make it complete like when you add the maximums and minimums and the file type the formats etc you're making your app more secure so your api will be able to defend itself because it has input validation available to it now because you just defined that but without that that means someone like me could go in and say okay so um yeah i'm 4 000 years old how's that for you okay cool and that might break your application eventually and so it is important to do linting on your api definition files okay so the other thing is you don't

have to put everything in the dash so what you could do let's say you've decided to record a horror file and you're only going to do technology specific tasks and then you're going to do other things so what are other ways that you can use a das that's automated that goes with ci cd so we talked briefly about how you can make a copy of the pipeline and not release it anywhere just put it somewhere that you can do security testing you can even like create a container load it up add your app to it do all your testing then release those resources out back into the cloud and finish and just have your test

results so you can do that without blocking releases but what other things we could do so first of all you can have scheduled automated regular scanning so i like to do this at least once a month for all my apps that are currently in production and all the apis so have scans like a scan runs every night of the month and that report comes in and someone looks at it and decides if it thinks those are real vulnerabilities or maybe some of them are false positives depending upon the type of tool you're using and then put those things in the backlog and then go talk to teams about it so if you have 30 apps you could run one every

night and you just have to look at one report per day except on mondays you have to look at three reports but the point is is that then you would be able to make sure every app is having thorough testing and it's still automated it's happening while you're not at work no one's waiting for those resources so this is the thing i see a lot at a lot of companies another thing you can do is want to offer manual scans so last year i helped some companies do m a some mergers and acquisitions and they're like we're gonna buy you know these companies and so i went and i just used the dash camera on all the

different apps and i was like okay so this one's going to cost like tons of money to fix i found like 100 vulnerabilities this one i only found six i think we could fix this very quickly i don't think it will cost that much etc and so i used a whole bunch of different types of scanning tools to do an assessment for them of the state of security at that company and then they renegotiated the price and whenever i get a tool the first thing i do is play with it manually because i want to know like how it works and how i can make it go faster and how i can make it find more things

and so usually whenever you get a tool the first thing you do is manual testing so there's still space for that in our industry there is still people doing that every day another thing you can do so every pentester ever basically they use a das tool and they do manual testing so they'll use a scanner that's usually what we call it like oh yeah i'm still doing quick scans to like check and see if there's anything that i might have missed with my eyes but sometimes a dash scanner will find something that manual testing doesn't and vice versa so you get a much better more complete result when you have a person who's a security

expert doing manual testing as well but it's expensive and it takes weeks and so you have to choose where you do that like most companies can't afford to do a pen test everywhere so you use a lot of dynamic scanning quite regularly and then you do like spot pen tests or just the ones that have to be pci compliant or whatever the case is where you were i want to remind you that you still have to do other types of testing we can't only do sa uh dynamic testing so there's static testing where it just looks at the code that your team wrote which is called sas there's software composition analysis where it just looks

at your dependencies your libraries your frameworks any code you your team didn't write but that is part of your app to see if it's known to be vulnerable there's is which is interactive application security testing where basically it's a binary and you put it inside your app and it tests as you use your app there's oops wrong button there's secret scanning where it just looks through your entire code base and it tries to find secrets so this could be an api key an api secret a password a connection string etc anything like that that shouldn't be kept in your code it should be in a secret management tool and so that is really cool we want to do these tests as or some of

these tests as well so these are places where you can do dynamic scanning so you could do security regression testing with unit tests because the unit test basically your ide creates a little baby mini web server and you can do security tests there for the first time then you can do dynamic scanning against your dat like your dev server or your local host then in the testing phase you can do you know full blast test i didn't mean that for it to rhyme but it just does um and you could also do a manual penetration test in a pipeline so release the release phase and maintenance phase is where you use pipelines so that's where you want

to tune your das and just do certain types of tests and then you could do scheduled weekly tests after it's released into production um i was talking about like how the first time i ran and asked how i felt so i felt kind of like this a little like that i really was like i am a hacker now this is awesome and so uh i feel like it's really fun and i know that i'm silly and that is okay but when i first ran one it was just so fun and i felt so amazing that i found security vulnerabilities that as a dev i never found before and so then as a dev i started doing scans and

i started teaching other devs to do scanning and you could find a lot of stuff so with a quick conclusion because we only have two minutes left we need to do dynamic scanning because any person on the internet can do a dynamic scan of our app and we need to keep ahead of those people automation is our friend but if you are at these sites you already know that dynamics testing in a pipeline it has to be fast and it has to be accurate or no one's going to want to hang out with you at lunch all the devops people are going to be like no there's tanya she broke our pipeline nope this seat's taken

missy we can do dynamics testing outside of the pipeline but still be devops friendly that is okay we're not breaking any rules other types of testing are still needed so we can find as many vulnerabilities as possible and make our app as safe as we can and basically i'm pretty silly um that's a thing you probably have picked up on already anyway i have a couple free resources i want to give you uh some some are free the books are not free but everything else is free so first of all i have a podcast that we had purple podcast where this season we're learning little tiny security lessons so you could subscribe on any platform or watch it on

youtube um these are all books about devops except mine which is about security and i have a chapter about devops um i think we can't do it right i mean i think we can't do security right unless we're doing it right and i think devops is the most efficient and effective and quite frankly fun way to make software the we hack purple community is free there's like no upsell or anything it is just free we have little meetups on the internet sometimes we meet up in person we have articles we have blogs we have lots of conversations and problem solving and we have a ton of free courses in there and so everyone is invited to that

every monday this is what snea was talking about on twitter is cyber mentoring monday where basically we use this hashtag and we respond to so i always do a tweet to try to start off a thread but basically people reach out and say i need a professional mentor and other people from within the industry swoop in and help them and sometimes they become their mentors sometimes they become their friend sometimes they have a virtual coffee with them and suggest a bunch of books that really change their career and maybe it could help you resource is bright so bright has a highly technical blog with a lot of information about like every type of vulnerability and how to fix it so

that's pretty handy and resource is me i am she hacks purple basically on all the platforms you can think of i have a newsletter a website or youtube blah blah blah blah blah mostly i hang out on twitter and with this i'd like to say thank you so much thank you to the entire b-sides organizing crew because without them this conference would not happen thank you to all of you for attending being in person is an important way to do community building and thank you to the entire international b-sides community that encourages different cities around the world to do this i'm tonya jenka and thank you so much for having me thank you so much tanya that was

fantastic i guess she deserves a louder round of applause can we have a louder round of applause please for tania that's fantastic [Applause]

thank you so much tanya is still with us do you have questions for her if yes please do come forward any questions for tanya yes please so uh thank you for the nice presentation it was really enlightened i would say uh just one point when you mentioned that uh someone needs to write the test for the apis like i'd uh describe them usually who is doing that i'm trying to imagine it like uh is a security person that's doing that to some from the keyway team so who is actually describing the api so that when we run the dust we know that it's complete ideally the software developers would do that part ideally so every organization is different but

where i've worked is generally the software developers that are responsible for adding those parts but quite frankly usually it's the security team that notices they're missing because when i was at dev or a software developer i say dev a lot i like i didn't know to do that i was like it works it does all the things my client asked for it's perfect and it wasn't until i became friends with an ethical hacker and he's like actually it does do all the things you need it to do but it does a lot of stuff it's not supposed to do i'm like really and so um usually it's the security team that starts asking for linting it it

really depends because there's a lot of software developers that are very security obsessed and so they might start doing it themselves but if you want everyone in your entire organization to be doing it you usually have to provide a tool for all the software developers give them a lesson on what you expect from them because otherwise what you receive will be very different depending upon what type of experience each step has does that answer your question yes so just to confirm do we understand it i would need to enroll the developers or to sell this idea to them say hey as part of the development process we also need to think about to writing tests

that the dust can use or tool that would be it oh so they don't have to write a test the das writes the test what they need to do is lint their definition file so you open it up in something like 42 crunch or bright or something else like that and then it tells you this api definition is incomplete and it'll actually give you code you can copy and paste and it'll say stuff like okay so this is a string cool what's the maximum length of this string what's the minimum length of this string are there any uh like which character should be allowed in this string and so you'll say let's say like lowercase a through to z uppercase

a through to z and then zero through to nine then it won't let any other characters in there does that make sense okay now it's clear thank you okay thank you that was a great question hi tanya uh i love cats though thank you a lot um question about about trying to scale and trying to roll out um dynamic software testing is awesome and i want to offer that to my dev teams so i go to the people that prioritize stuff like that into the backlog and then i have five pos sitting in front of me of which i need one volunteer and all of them think if i go and volunteer for this i can throw away

all my roadmap for my products and features how do i how do you get over that first step of them being scared of you um i so when the first time i was on a security team i had been on the software development team at that same company so they all already knew me by name like i already would eat lunch with them or or hang out with them so they all already knew me so it wasn't as intimidating for them but then when i went on to the next company none of the software developers knew me and so what i did was is i started giving little presentations about the things i wanted and so the presentation

would always start with like this is a big problem that i see and i wouldn't say like at our company i'd be like on the internet it'd be like there's you know like injection vulnerabilities on the internet this is how it works and this is how scary it is and like let's do one together and then i'd be like but we could stop it from happening here and then i'd show them what they could do to help stop it like i can test for it and find it you could prevent it in the first place and i would kind of just try to show it to them and make them as excited as i was if that makes sense and like show

them my passion about it and right now you're like oh she seems like a really good presenter yeah i sucked i was really not good when i started i've been doing this for like eight or nine years now and so when i present i'm really comfortable and i'm not like super nervous where i feel like i can't breathe and my heart's beating super fast but even when i was like not very good at presenting they could tell i really really cared about it and that's why i was showing them and so the first couple times i presented i really thought i was gonna die but i didn't clearly because i'm still alive um and and it turned out like they

wanted to know if that makes sense and they're like yeah you seem really like worried about this i am and so that's what's worked for me is just showing them the thing sometimes people like i've worked at places where the security team says we do this now and you have to do that and they don't explain it and i find it doesn't go very well so i always try to explain why we want to do it how to do it and i will help you and then if someone gets stuck i just like run over to their desk and help them and i keep doing that until they're like i don't need you tanya go away stop being like hovering

over me i got this and then eventually the software developers are better at it than i am and they don't need me anymore for that thing but for me i've had a lot of luck with presenting the problem and like this is what i think can help and i need all of your help to get this done does that help you hopefully yeah we'll see but thank you okay good luck i actually have two presentations that i open sourced in my github so if you go to github.com then she hacks purple i have a a project there of presentations where i teach you how to give my presentation to your depths and so i have two so far there and a lot

of people have told me like yeah i wanted to get the devs interested and so it's like my slides it's a video of me doing it then it's a video of me saying what to say for each slide and what you're trying to accomplish and then i have a description of the whole thing and so you could try one of those if you don't know what to present because i didn't know what to present when i started yeah are there any any other questions if there are no further questions or pane is still here does anybody have any other question all right great tanya thank you so much for explaining us because when it comes

to product security dust scanning the entire ci cd pipeline is super critical for everyone not just the engineers or the developers but even for the security professionals or the security engineers call call it like that sometimes um there's one quick question for you with the dust scanning involving in the entire pipeline how do we basically handle these vulnerabilities in a way that we are still friends with the developers and not just bombard them because sometimes it might happen that we say oh that vulnerability is super critical it's it's got like the cbs score the ni like say for example 9.6 you need to fix it in two days or one day so how do we still try to deliver this

how do we rely exactly on dust scan whereas and how do we convince our developers that you know even though it's a high vulnerability the tool says it's super critical but based on this can you explain how do we maintain the relationship still happy and nice so i usually try to give the developers a license for the tool i'm using so that if they want to they can test it earlier so if they want to when they put it on their dev server or their local host they can run the test themselves so when they get to the ci cd pipeline it's like a double check if that makes sense um i've had a lot of developers say they

feel it's embarrassing if they break the build and so they would rather have access to look at it themselves first so if i can afford it i get them all tools or licenses and then another thing is is i usually start with not breaking the build i work up to it so first we're just running scans manually and i'm showing them results and asking them to fix things then i start testing a little bit just like a couple of things in the pipeline and then when they and i just alert i'm like alert this is a hi alert this is this and i try to have um sort of two different service level agreements once we start having one so

at first it's like anything that was already there you know you have months to fix but any new vulnerabilities that are higher critical you're not allowed those so i will break the build if a new critical vulnerability comes into it so at first no breaking and then at first i'm only breaking on new things that are very high then new things that are just high and then new things maybe that are medium depending upon what level that you need and then the stuff that's in the backlog the stuff that was there before we had a scanner i give them more time and we talk about those over time because they're already out there and prod and us not letting them

go to prod with those old vulnerabilities they're already out there doesn't really make a lot of sense like i want them to fix all of it now but i know that they can't especially if they're currently doing a project and no project time has been allocated to do security bug fixing another thing i do is i go talk to all the project managers and i tell them i want to be at all your project kickoff meetings and i want to have a two-week sprint at least one that is just to fix bugs and so maybe like four months in or something we have a sprint where for two straight weeks or three weeks however long your sprints are all you do is fix

bugs that i found and so i get ready in advance so they have lots of work to do during that time and then they just fix lots of bugs so by the time they go out to production with everything it's like pretty good do you know what i mean and so i try to get there earlier and be there and talk to them the whole way through the project and i don't mean every single day but like check-ins quite regularly and then by the time they get to the end it's usually really good with legacy software it's different so software that's already existed i try to be a lot more patient because usually fixing like a dependency

it could mean you know if the dependency is really old like we saw during log4j in december it could be a really like it could be like a complete re-architecting of the whole app to update that and so sometimes i negotiate if it's really really really bad i'll say okay well i need five thousand dollars from your project team so that i can put a like a web app firewall or a rasp or something in front of your app because it's so dangerous having it on the internet and then you have you know this long to fix things but if you won't let me put a waft in front of it then you only have

this long to fix things and then they're usually like we found five thousand dollars tanya um so i try to like negotiate with them and realize that they have other priorities and i'm just one of those priorities and then things usually go better and there's some teams where they're just like no go away you're wasting my time i want to talk to you and those are the most difficult ones and that's where i have to be like mean tanya and i like first start off really nice but then eventually i'm like i'm here to bother you because you still haven't fixed those things and like five separate times i've visited you and eventually i'm gonna visit your boss

right like like you're forcing me to do this because you're not holding up your end of the bargain like is that what you want because that's not what i want that sucks we'll never be friends if i just talk to your boss every time and sometimes they'll give in and then sometimes i have to talk to their boss and if their boss says like well i'm fine with it i'll talk to the bigger boss and eventually i'll try to get them to sign off on that risk so i'll say you don't want to fix these things you know you feel times more important than that cool but you need to sign off that you are accepting the risk on behalf of the

organization because for me this is completely unacceptable and i do not accept this risk and when we're in the newspaper someday with a giant breach it's cool your name's gonna be in there it's cool and then usually someone gives in and i work places where they don't and there's one place where i resigned in protest because i just wouldn't fix anything ever and i just didn't want to change and i didn't want to do any security and i was like i won't work here and that's it so that's the grateful lesson that we still are learning and i guess we are still going to learn the same lesson for next couple of years till the time each

and every company decides to shift left and consider security as an integral part and not an external part of the entire ssdlc process itself but that said um thank you so much tanya for sharing your insights and such amazing guidance and advice and we are so happy and honored to have you here and we wish that next year maybe we can have you physically present at the event we wish you all the good luck thank you thank you [Applause]