Continuous Integration: Stalking Vulnerabilities with Puma Scan

welcome so should we kick this thing off this is gonna be a fairly interactive session so you're going to have to do some thinking I know it's late in the day is this the last session or is there one more yeah so let's finish this thing off strong so this is a talk I created it's called secure DevOps we're going to talk about DevOps and maybe some common security mistakes that I see and then I'll also introduce you to a tool that we created that is open source and free to address some security issues we saw in a DevOps deployment so my name contact info is up on the screen I'll show it again at the end but if I have

not met you before I've met many of you in the past my name is Erik Johnson I kind of had two different jobs I know I'm weird I like to just work twice as much as normal people but I have a consultancy called cyber State of Defense where I focus mainly on application security so I do testing of web apps mobile apps IOT apps in some cases some thin and thick clients for the most part over the last year I've done almost all secure development lifecycle consulting which is going into organizations and helping them do security day in and day out from the beginning of an iteration or a cycle versus maybe waiting to the very end and

calling us apps tech folks and saying hey by the way do you think we should worry about security which historically does not work out very well for you when you push things to prod and you have not done any security whatsoever so when I'm not doing that about 30-40 percent of the year teach for the SANS Institute I author two different courses for them one on mobile app security another one on dotnet security I also teach a Java secure coding class and we have a secure DevOps class which is a lot of automation and how security needs to kind of land in code across an organization and rather than our historical network and operations type

of role so that's me in a nutshell I live here in Des Moines so this is like my favorite conference to speak at because I don't have to get on an airplane to go to its which is very nice so here's our agenda for the next 4550 minutes we'll kind of see how we do I'm going to go through a little bit of a case study and introduce you to what I see often in a quote DevOps environment then I'll talk about some static analysis options for this client that we had and walk you through what you should be doing is development engineers or writing code pre-commit and then also what should be happening in your CI

pipelines and then we'll kind of tie things up a little bit so let's talk about the case study first if you've ever seen me do a talk I always lead off with some sort of example of why you should care about what I'm going to mention for the rest of the talks so as I'm going through this just keep in mind this is why we did what we did so I can't really tell you publicly who this customer was or is but I can give you their industry if they're in the travel industry in it might be an airline company with roughly 5,000 employees they have roughly 50 net c-sharp applications many of them are internet

facing so prime attack surface for all of the who's a hacker in the room anybody anybody love to break stuff so there's a few of you and let's see who's on the defense side anybody on the blue team only one blue team doesn't get any of the glory man I'm with you it's easier to break stuff what about what else do you guys do is anybody we've got some managers in the room I assume some that are just interested in maybe high-level this will be good because you'll see kind of what you should be thinking about as you work with your engineering teams students students you guys look like you're you're taking notes and stuff which

tells me you're very collegiate at the moment so they've got roughly 20 software engineers that work for this company they're supporting these 50 apps guess how many apps X folks they had none now everyone knows the ratio if you look at the besom 7 report that is published by Citadel every year their study from 2016 actually the ratio across about 80 different enterprises is about one app spec engineer for 225 development engineers so that's you know 50 we're not quite to that to 20 yet so that's why they have none and they're deploying code once a week so that's the scenario that we walked into and security was never really discussed until we had this slew of travel

industry breaches that have popped up here over the last five years or so Omni resorts lost about fifty thousand credit cards they would see like Marriott / Starwood had that same point-of-sale malware that happened to Target and Home Depot in those folks so we're stealing credit cards there United Airlines they have their own slew of problems that have happened within the last week with deplaning folks but they did actually open a bug bounty program about a year maybe two years ago did anybody do any bug bounty testing against United applications no you should have because you could have gotten a million frequent flyer miles the gentleman his name is Jordan Weiss I think with his name he did testing for

six hours got remote code execution on United server and earned a million frequent flyer miles so that's pretty cool ready that's why this company reached out to us and said we might need to consider application security I mean we should have all along we can kind of all smiling but a lot of big companies don't do this so this is the state that they were in when I found it and to make things worse they're doing DevOps who is working in a DevOps shop I know we talked a little bit earlier we got at least one hand this is this whole notion that we can automate all of the things and engineers can do a git commit and

push code into a repository and then it's auto magically built and pushed straight into a production environment at the click of a button does that sound concerning to anyone yes it should so this is the state they were in when I kind of first started looking at their development lifecycle now this is a hypothetical application called widget town that I we'll walk you through here in a little bit but this is basically it we pull from git we compile the app and if it works we're going to publish that build to a repository that's automatically pushed into the dev testing and production environment so that's what we walked into so what's the state of security there I'll tell you on the next

slide but what are you thinking right now nonexistent and they have zero apps next folks so at least that's adding up there's no ones who help guide them so what's the state of security in this only devops world so if you walk into an organization and they're doing DevOps security is a little slow to the game as anyone kind of run into that in their organization we're seemingly two steps behind all of these software engineers that are using a new JavaScript framework every week a new one comes out and they just start firing that out there and say this is awesome we'll use that sure is secure yet so if the process is secure for

those listening at home then it must be secure right from a from a code perspective yes and we kind of talked about I was at Tom that said it earlier I can't remember where he's like if you break the bills because you changed a line of code and you never actually ran it to see if it works you're buying beer for like six months on Fridays for everybody so that goes along with this so security in this organization they were bringing in external consultants they're doing these standard let's run a fortify or you know I'm not going to call out which two it was but some sort of commercial scanning tool that's going to generate a 500 page PDF with a bunch

of problems in it and they're just going to send that PDF file off to the engineers and say here's all your problems how do you think that goes not well who's going to look at that box check that's a perfect way to describe this so this is kind of how security is set up at this moment with this bleeding-edge devops pipeline automating code pushes production so if you actually do an assessment by the time you get that PDF and you send it to somebody it's probably been more than a week that has passed the code has already been changed the code has already been pushed out to production and now your results are effectively worthless at that point

because you need to go run another scan so this is not going to scale well and I've actually seen in real life and you'll laugh once opera engineer that paid attention to that report and they printed the entire 600 page PDF off so I walked across the office and it's just the stack of paper sitting on his death and he's just flipping one page at a time oh there's the file in the line of code and he'd go over to his machine and he'd change it then he'd flip to the next page like how long is that going to take it'd be here for months doing this so here's the problem this whole DevOps thing is great and

security absolutely can get involved in this but usually we're not really invited to this party is how I like to phrase it so we've got all these nice automation tools but the internal security team maybe doesn't have a development background so they understand how to work with a lot of these tools so 95% of InfoSec comes from an Operations in an infrastructure background so when you sit a typical InfoSec person down and you say you're going to do app sec this week and I need you to go write a bunch of unit tests to test for security requirements how does that usually go not well and in most organizations that security person is sitting up on the ninth floor all the

software engineers are up all you know down on the second floor and they don't even know who each other are so they can't work together to iron this stuff out so it doesn't get you very far we have frequent deployments I already mentioned invalidate your assessments the point I'm making here is that if we use a developer mindset from the app set perspective these pipelines actually offer us a huge opportunity as far as application security is concerned we can do a lot of basic scanning that can live a lot of that low-hanging fruit that always seems to end up being the reason that someone loses ten million records out of their database something of that

nature so we can do better is my point let's take a peek at an HPE survey so here's how application security and DevOps are actually being commingled at the moment so if you can see the chart I'll go through what's what so this was published in October 2016 the release frequency is up thirty times in a DevOps environment so we're pushing code much more often the problem is that these silos between apps second app sex and development still exist so in this survey we've got the red evil piece of the pie chart seventeen percent of these organizations doing devops are doing nothing for security in their DevOps pipelines which is very concerning because we've taken a problem that at

least gave us a chance to catch with a gated release and now we've removed that gate so we're just freely pushing any sort of vulnerability into production without even thinking about it the next part 25% because most of security comes from an infrastructure background 25% of these devops companies are actually just addressing apps tech at a network layer which means what we're turning on a wax maybe and they block everything right has anybody done an audit on lappa rules before to see what they actually do find Tom's nodding anything good or worthwhile depends a lot of the ones that I've gone and looked at yeah we have a laugh and we spent X number of thousands of dollars

on this laugh and we plugged it in and no one knew how to configure it so it's sitting there in passive mode not actually blocking anything that's how I've seen it deployed almost every single time I've gone to look at it so you have a big shiny object that's very expensive and you're not actually using it then we've got the other side of it where let's write a custom rule that blocks ticker one equals one I've actually seen that in a in a whack rule and then I looked at the person and I said well what if I put in ticker two equals two oh we have a problem here so those defenses are not going to make

up for pretty much secure application development is what I'll call it then we've got the 38% which is at least promising that there is at least a gated release so we still have an opportunity to locate problems before we push the production and then there's 20% what you're actually doing security scanning in the pipeline so that's kind of the distribution right now the organization that we're working with that we kind of started we're definitely in the red piece of the pie doing nothing so what we need to do is actually break down these walls that's what this whole DevOps concept is all about so security needs to get involved in several ways now security from the development

perspective needs to understand the tools that software engineers are actually using I'm amazed at how many InfoSec folks I know that cannot commit a change to get it's impressive so you have to learn how to use source control because all security is going to slowly start being baked into code which is great you have to understand the CI tools whether it's Jenkins bamboo teamcity Travis AWS code pipeline I don't really care which one you're using InfoSec and apps tech have to understand how those things work in order to actually wire security into the process how about operations the ops folks need to start learning code from a infrastructure perspective we can start actually writing out chef's recipes or

puppet manifests or whatever it is you can start burning your infrastructure into code and then the line of business can actually get involved as well and they can start understanding with security and maybe we can start actually talking to the business about security so we don't have to say no to everything maybe some things are ok to actually go to production as long as we have some compensating controls in place so that's really the whole goal of everything this next slide is very noisy there these are all of the things there are many of them from a security perspective that should be happening during our four phases of DevOps you kind of boil everything down to

pre-commit which is before we've actually committed code during the commit which is when you're starting your build pipeline acceptance testing which is automated in your build pipeline and then deployment so there's a number of things on here obviously risk assessment threat modeling you've got static analysis in the mix which is what we'll dive into here in a moment during the commit phase there are things like putting automated alerting on high-risk code changes that should trigger security peer reviews that sort of thing absolutely has to be in a DevOps pipeline to call it a secure DevOps pipeline acceptance testing should be automating all sorts of abuse cases and abusers security stories you have to burn those into code and you can

start actually making sure your security requirements are also baked into those same sort of tests after deployment because we are elevating our risk by automating all of these things and maybe not catching everything you need to put in more monitoring your applications have to have little mini intrusion detection systems built into them so if you get a whole bunch of incorrect password attempts in a short period of time on your login page you had better have a graph or HipChat notifications or slack notifications going out to inform the people that need to know about it as the attack is happening so you're putting in some protective measures in your application source code those are the types of things that we could talk

about this for a week we will narrow this down because we've only got about well I don't know what 25 minutes left to IDE static analysis and CI static analysis because that is the first place that I said let's start there with this organization now the days of being able to actually just kick off a commercial tool for example that take 8 hours to run they're not going to work here and you cannot turn on all of the rules and overwhelm folks with a hundred thousand false positives because that is also going to kind of turn the software engineers against you per se is anybody seen that happen where they look at that report and they say I'm not doing this this

isn't in my job title why do I care about it so you have to make them fast they need to be as accurate as possible which most traditional apps tech folks will say well you're neutering the tool if you turn off all of the rules and I'm not saying we're going to throw those scans away I'm telling you they do not belong in a DevOps pipeline blocking up everything those need to happen out-of-band as regularly as you want them to happen and those results can be fed back into the backlog systems we're trying to eliminate the top low-hanging fruit issues like sequel injection and cross-site scripting that should absolutely never ever ever enter a production environment that's what

should be happening at this face so remember this organization is in all dotnet shop so that was the first conversation we had they said we don't have money for commercial tools those are out what do you have available that's free and open source does anybody look for that in the microsoft.net world before the options are pretty crappy they're terrible so I started scanning some things and I knew this ahead of time but I wanted to prove to them did it was actually bad so what I said is here's cat net here's FX cop another analyzer and there's some web config analyzers out there that you can use and I have this vulnerable target called widget town that has a

bunch of vulnerabilities in it and I use it to benchmark scanners so if I'm evaluating a commercial product I scan it against this and I know that there's at least 75 vulnerabilities in it and when it reports 6 back then I know it sucks so you and I know when you woke up this morning that you really wanted to do a code review because everybody wakes up and actually enjoys doing that right so you are going to get to do that here so this is some of the code within this application now we're only going to go through about 6 files so I'll let you tell me what the problem is and if you don't know dotnet that's ok

this is reading an object from a database and this is writing it out to HTML what top 10 the vulnerability is that does anybody know not sequel injection HTML injection or cross-site scripting was the common name for so this is stored cross-site scripting where it's sitting in a database let's take a peek at the next one here this gets fun now this is about as blatantly obvious as it can get id is coming from a REST API parameter and we were just blindly concatenated that into a sequel statement that is pretty much an example that probably still exists in a book in my office somewhere that was written in 2002 when it said here's how you query

information from a database from a webpage that's pretty much what they all used to say and that's how we ended up in the predicament that we're in today that's a different story okay so I there's two this one a dynamic file name and it's concatenated into a file path and download it off the filesystem what do you think on that one all right directory traversal path manipulation whatever you want to call it okay here is a method that signs in a user and this is actually the default template the dotnet creates for you when you say I would like to do authentication and it has the parameter called should lock out set to false what

do you think that does right so that rock you list that I was just running against Tom's encrypted file forever you could run that against the login page and actually get into the system so that's another problem here's one that I see quite a bit the comment kind of gives it away hint hint so we have no certificate validation and I'll show you one more and this one is a little bit trickier so let me zoom in on this a little bit so select star from contest where contest ID equals what does that look like it is so we've got some more sequel injection but let's take a peek at the integer the variable type real quick so that's actually an

integer so the scanner will typically mess up on this because I can't put injection commands into an integer so this is a false positive and I just wanted to show you that this existed because we're going to see how to address this here in a little bit so and there's lots more problems in here I'm not going to give everything away let's take a quick look at how these free and open source scanners did during our assessment of them so Microsoft cat net was created in 2009 and has not been updated since then how good do you think this is not so good so here's the results run it with PowerShell I found two cross-site scripting issues in one

unvalidated redirect issue that's what it came back with so three problems now we just manually walk through six of them together so you know there's a lot more on there than that let's take another quick look at FX cop which was basically more of a style checking tool it does have some security rules built into it but it's not going to find things that a normal security scanner should so that is wrapped around Visual Studio code analysis which is just a menu bar in the IDE or you can say scan this code so they wrapped that up into that functionality and here's what they found - sequel injection instances one of them is a false positive so that's what we're

looking at for the free and open source tool so here a nice little table that summarizes what we found to cross-site scripting one sequel injection one false positive and one unvalidated redirect so if you had to grade this what would you give it based on what I just showed you right not very good so the question is what else can we use and this is where I had an interesting conversation with a colleague named Mark who's like a die-hard Microsoft person he's like the only person I know that that has a Windows Phone so does anybody in here have a Windows Phone there's usually one we talked about this this morning nobody there was one in here at some point

today I remember it so mark tells me hey have you heard of Rosalyn then I go who's Rosalyn no no it's a code name for this open source compiler API that Microsoft released to us and I said no what is it and he said basically you have an API now that lets you query the entire dotnet compiler as code is being parsed in the IDE or during the build and it allows you to actually set a diagnostic which is the underlined squiggles you see on the slide at any location in the source code file I said well that sounds interesting so what's going through your head right now or at least I'm weird I know what was

going through my head when he told me about it was I bet I could write some security rules to actually do better than these other options and flag them in the IDE as engineers or writing code how cool would that be that's as early as you can get in the vulnerability cycle is to stop them from being written in the first place so that's step one step two is that they're also reported during the build compilation so you get a bunch of warnings that reflects what is being squiggled in the code and that information is available to you as you run a build in a build pipeline so that's check box number two now in

Jenkins or whatever your CI server is if we plug these rules in we have scanning going on and we can make informed decisions on the health of the application from a secure perspective based on the warning showing up at compile-time that's when number two so I'm not going to tell you how to build these rules there's actually a talk that I did last fall that I'll give you a link to here in a moment if you're interested in writing these there's an awesome MSDN article where he walks you through Alex Turner sets everything up here's what you need to install and here's how you can write your first rule and he goes in and teaches you how to find invalid

regular expressions in code and you walk through the process if you're interested in the talk that I gave it's out on YouTube it was recorded at app SEC USA and DC last fall the link is on the slide also there's an open source repository on or that's mine the github repo where I've got some sample analyzers that you can play with there if you're interested in learning how to actually write these I'll post these slides somewhere and I'll talk to the b-sides folks and they'll tweet it so they'll tell you where the where they are fast forward six months after I talked to mark and I've got an open source tool it is also in github that

has about 50 different rules that myself and a few other people have been just slowly adding to this to try and fill that gap in the dotnet world to give us what will be a decent open-source tool for scanning source code which is great so you know Java has their own you know they've got fine security bugs our Ruby folks have break man which is also awesome our goal was to try to create something that people in dotnet could use and not have to pay anything for it because security shouldn't really be at the expense of paying for a massively expensive commercial tool in my opinion so what do our results look like same source code that I've scanned with FX

cop and cat net we've got a total of 66 findings which is getting there that's covering most of the things that I know about in the app 56 of them are valid 10 or false positives so we'll never get away with false positives not being there that's just not possible in the world of analysis but I will show you a way to suppress these and then you can move on your way and never see it again at the same time so let's take a look at what the scanner actually is doing here so I've got another instance of Visual Studio open and it's got this new get package installed so all you have to do is go

into your project say install package Puma dot security dot rules it will download it from nougat and it will install it and start running these rules right there in your pipeline pretty cool so the same issues I showed you earlier notice what we've got on that line of code it's basically telling you unencoded label dot sex property and down in our actual warnings we've got the full description there's also each of these link outs to our site let me see my VMs online so you click on it and it takes you straight into the documentation that tells you here's the bad thing that happens and off to the right here's what the insecure code snippet looks like and then here's what

a secure example would look like I'm trying to make this as easy as possible for our software folks to fix things as they pop up so every single issue will link out to the documentation that explains what why and how to fix it I can tell you it takes me longer to write up the documentation that it does to actually write the rule to find the bad thing unfortunately so what we're going to do is commit some code here I'm just going to kick this off let me go in and let's see my changes and let's just say we installed Puma scan and I'm going to commit them and I'll push them out to my repo and I'll kind of show you what's

going on in the background here so as I commit I've got Jenkins listening so there's a get hook here that is now tying in our warnings at least at this compile stage we're generating all of those warnings that you just saw in the development environment which is good so let's take a quick look through our pre commit slides we'll let this run for a second and then we'll come back and fix these problems and actually see our bill warnings the security specific ones showing up in the actual build pipeline for our security folks so let's flip back to you good yeah when you run msbuild if you have this analyzer installed on the project it

automatically runs all of the security analyzers you don't have to do anything except install the nougat package with each project which is huge so it plays nicely with the builds that are already going on I don't have to do anything extra now I am going to add a step here in a minute I'll show you what it's going to do that parses these specific security warnings out of the build results so we can make a more informed decision on the health of the build but in our DevOps world the static analysis checklist will look something like this we need to display the vulnerabilities in the IDE we achieve that so I just showed you how that looks

check we've got the warnings in there we also need to provide documentation to make it easy to fix the issue check we've got the link that does that and the last section is getting rid of false positives I have not showed you how to do that yet so that's what we'll hit next here once I get this build working so let's go back to our VM and let's find that false positive so here's our build let me make sure this is good so it's just finishing its publish phase but if i zoom in on the compile you'll see that we've actually got the 66 new warnings and those are all of the security warnings that were discovered during the MS build

phase so we now have the data in our CI pipeline which is step one if I come in here and let's suppress this false positive so it's a suppress one all you have to do is right-click on one of these warnings and we can say suppress this in a suppression file and what that does is it's going to create this new file that lives with your source code repository so here is the file that it just created called global oppression it's just a class and you can come in here and actually track the false positives now some engineers might just try to suppress everything in order to pass your bill so I mentioned monitoring high-risk code

earlier for a reason this particular file should be considered high-risk code in your build pipeline if this file changes if the hash changes you should be firing off notifications to security folks and they should be coming in here to actually approve that deployment after they verify that yes this is truly a false positive so from a security perspective you have to monitor this closely let's pretend that I looked at this so I'm going to say Eric says this is cool right that actually is a false positive and we'll save this file you'll notice the warnings have already dropped in the IDE from 66 to 65 so it's already gone away so fix that all you do after that

is do your normal commit so let's go ahead and commit some code again and we'll say suppress false positive and I know my typing is terrible right now so commit anyway all I want to show you is that warning dropping off in the bill so we'll let this run again and while that's running we'll flip over to see what else we need to be doing in the pipeline itself so the build is kicking off it's running again let's take a look at that here in a minute so pre commit we've accomplished our goals which is flag things as soon as they're written as soon as you write something bad it shows up we're giving you documentation

and the ability to suppress problems so engineers can handle that let's talk about what's happening in CI here from a static analysis perspective in a perfect world we would not actually need to verify that all of these things were fixed because we could just trust all of the engineers to do the right thing and fix all the issues in anyone's experience do the engineering teams actually do that unfortunately not so the whole premise behind security and DevOps is that you can trust people to do the right thing but when your auditor comes and you have to talk to them about why this is okay in a PCI regulated environment for example you had better be verifying

these in your pipeline and providing that compensating control to the auditor so step one is the pipeline needs to actually execute those scans again you need to capture the results so you can show them exactly what showed up during each bill you can also set thresholds up to monitor the health so maybe you will allow a hundred low-risk issues to go through and that's what your organization says we're okay with this from a risk tolerance perspective we'll let a hundred lows go through in maybe 15 mediums but if any high-risk issue shows up that's absolutely not tolerable we're going to fail to build so you can also enforce those thresholds right there in your pipeline so those things

automatically fail and as Tom put it earlier whoever did it has to go buy beer or bring in doughnuts until somebody else fails it next that's the game we play you also need to notify security teams when issues are suppressed or high-risk things are showing up and that's all very actually easy to automate in any of the CI tools that's where security needs to be focusing in the DevOps world we have a huge opportunity to plug all of these security things in and automate them to tell us when bad things are going on so what we'll do in a moment is actually add a new step into the pipeline we're going to add the Pumas can step to

evaluate all of the security rules that showed up very quick will change to Jenkins jobs and we'll fire that up when you click on the results of that we will actually see all of the security warnings right there within Jenkins so now the operations and InfoSec folks don't need to go download Visual Studio and run all of those rules on their own they can come in to Jenkins as the repository and see them all right here from within the di pipeline if bad things happen we will fail that's why that's red that's what it means when you have to go buy donuts or whatever and then we'll fix those code issues and we'll watch the build

pass again so that's kind of the end of the talk for the next ten minutes or so that's what we'll do before we wrap things up all right so let's go back into this our pipeline is still passing because we're not enforcing the rules so let's take a look at compile again you'll notice it says we've got 66 warnings we fixed one of them so the one fixed warning is the one that we suppress right before we committed this so we're now tracking these changes over time which is very cool from a metrics perspective when the management team comes to you and says how are we doing on fixing security issues you now have a

historical graph of look we're fixing five a week and we're slowly improving and getting better all that data is in the actual pipeline the next step is enforcing this so let me go into Jenkins and I have a rule in here that I pre created called conveniently Puma scan to self-described and let's change this so if you're not familiar with Jenkins what I will tell you is that we have this delivery pipeline project installed or plug in and we're just going to say I want the Puma scan to run in the verification phase which is right before we publish the artifact the task name we'll call it Fuma scan and we'll say enforce some rules or something cool

like that and then we're going to come down and actually say when does this get triggered so after our compilation step is when we actually want this to run so if I come in here and I choose run this after the widget town build has succeeded will now be checking security warnings right after the bill that's where we want to do it so that's all I have to do in this step is to change that and then we have to monitor one more or change one more task so right now this is showing up in that pipeline we've got the security rule in there but we need to tell our published step to not run after compile anymore we now

need to tell it to run after the Pumas can set so that's the second change let's click on this we'll go ahead and edit this task we'll go in to configure and go down to its build trigger and you'll notice right now it's build trigger is set to go after widget town demo build instead we'll change that to Puma scan which will make sure that our published step does not go unless the rule security step is actually passing so those are the two quick changes we'll make to our pipeline so now we've got the step in place right here that's the security step that you should be thinking about from the DevOps perspective as the security person what

can I add to their pipeline to enforce security day in and day out every time there's a commit that happens this is how we can start playing within their rules of engagement we'll call it so let's run this now what we'll do is kind of just kick off the process again so let's just fix one item and then we'll kick it off so we can actually see the build fail so who knows how to fix a cross-site scripting issue I know you didn't think you'd have to do this when you woke up this morning what's that input validation is step one does anybody know the true solution constraining user input is always a good idea in general yeah output encoding or

output in escaping whatever you want to call it what we need to do is actually HTML encode this because it's being rendered in a browser that we need to tell the browser this is data don't execute a script if you see it display a script because that's what the data is so we'll do it in code code or dot HTML in code and put our parentheses around here and voila that little green warning is now gone how cool is that the IDE tells you you did something good today for security pat yourself on the back and let's play this game again let's see we've got 60 more 64 more other things that we need to fix

we won't do them all we just have to get better incrementally that's the goal so if I push this change out let's say we fixed one XSS issue commit and let's push this so if we look back in our pipeline we're running this again and now the Pumas can enforcing step is in place so what should happen here when we've got 64 warnings we probably should fail and I'll tell you what where that setup at these step itself if I go to the configure for this again if you're not a Jenkins expert you don't need to be but I'll just show you what I did so in the advanced scan for compiler warnings phase I came down in here and

just for demo purposes I said okay here's what I want you to do mark the build is unhealthy if there's more than 30 warnings and fail it if there's more than 60 so we've got 64 right now we're going to fail so while this is running let's go fix the rest of those vulnerabilities real quick and we'll come back to this here in a minute so task 1 is done how do you fix sequel injection parameterize the query now this is running against dotnet ORM framework there object relational mapping framework so this automatically parameterize --is things if you don't do something stupid this code is doing something stupid on purpose so if we just get rid of this whole string

concatenation thing and just leave this little curly brace right here that's a parameter and all I have to do is pass the ID in in the second argument and that is now a parameterised query so we've now fixed what is one of the most detrimental web app vulnerabilities that you could possibly push out into production we're down to 63 now folks we're getting there what about a file path manipulation issue any ideas on this one

again constraining user input is a good idea here what I would typically recommend is don't let the user control the file path that's typically a good place to start if you make them indirectly choose a numeric value and then you go look up the Associated path on a secured back-end repository that is also a good way to make sure that that doesn't happen so in this case we'll change this to an integer and I'll just convert it to a string and wallah now I can't put dot dot slash in the integer so that one's gone and we'll play this game a little bit longer this is the easiest one should lockout should probably be set to what true would be a

better value for this so let's pick true oh and that one is now gone look at all the apps set work you're doing today this is even easier than the last one what should we do with this certificate without disabling the certificate validation part comment perhaps or just delete in general never ever ever do that so we'll save that now that one's gone and we're down to sixty on the nose so look in just a very short amount of time we should now pass the bill and I'm not saying 60 is what you should do in real life this is a demo so pick the appropriate number that matches your organization's risk tolerance here's the

results from our scan with just one fifth so we'll click on this notice hey you had 64 issues that's over 60 that's why we failed let's go ahead and commit our changes just one more time we'll say we fixed five or four more issues and we'll commit all of these changes sync them up push them out to the repo and we go back and watch our pipeline do all the heavy lifting and this should actually pass that is what security needs to be doing in a devops world

on the Java side sonar has security rules so fine bugs has a plug-in called fine security bugs that looks for a lot of security specific problems and there is a find bugs plugin for Jenkins specifically yet fine bugs will also run on the IDE and there's a fine bugs plugin for Jenkins so when you go and you run your java your maven build it will execute find bugs also at that point in time and give you access to the same sort of data yet sonar I have not seen sonar security results do you you think they do a pretty good job on there I advocate for using sonar to be your repo for all of the data and then you

could feed the Puma info into sonar and let that be where you send tickets out and do a lot of those things from a kind of a general code health perspective any other questions I'll open it up at this point while we kind of watch this thing actually do work here this is how easy security is in dev ops in a pull request yes and that is a huge compensating control in especially if you're regulated you have to have pull requests that trigger peer reviews and whether it's a like a security you know champion that does like software engineering on a day to day basis that you trust to do those reviews or it's someone on the

dedicated apps tech team it's different everywhere that is a compensating control that you will not get past most compliance without so you know like Etsy for example they're PCI regulated and they you know are on the whole I deploy code a bazillion times a day or whatever but they're PCI pipelined absolutely has that code review step in it pretty common it Twitter also is a full-out you know SEC devops shop and not a single piece of code goes into production there without somebody peer reviewing and looking at it first that's a huge compensating control great question go ahead

so if we modify Oh so if I go in and just completely change that file and it moves around from a line number perspective enough right right so in that so it's been suppressed and verified but let's say we go back and accidentally reintroduce it if the sync and I'll show you the info in that file the way that it tracks that is based on let me find that global suppression file so if you go in here it actually is the class that it's in and it's got the method that it's in and that's where it's going to go locate that so it is feasible that within the same method if you do that we could

potentially kind of skirt around that and reintroduce something it would be it's something I haven't actually tested very yeah it's definitely not here's the line number and file and if I change it it's coming back sure yeah the other option which I didn't show you so if I go get rid of this that's not the button I wanted to push so let's say I delete this line here and now that issue is going to come back because I've deleted that in the suppression file so that was in I want to say here it is right here the other option is you can actually suppress it in line if I say suppress it in the source is the option I'm clicking

on here it will modify the actual file and kind of do what you're describing which is on this individual line will suppress it here so at least you have better visibility into if that changes so maybe if I'm going to actually change something within this segment maybe we get rid of the suppression and make sure that all as well before we re-edit back you could certainly is homage and do your own hashing on the file or something and say if yeah and say if the hash on this line ages let's turn that suppression rule off that would definitely be a good thing to keep in mind absolutely what do they look like so they're all in

github and I'll pull it up if you really want to see it that's what that other talk I referenced the wasp app SEC USA talk I actually went through and taught for an hour people how to write a rule to identify that like a password complexity miss configuration and I thought it was fun but a lot of the room I think when they see lots of slides with code on them I think I overwhelmed some folks so but it's definitely out in YouTube the big absolutely no no you have to do this all manually so we've written about 50 analyzers that go in and this is just here's a dump of all the bad things eric has seen in 15 years

of looking at crappy code jumped into like 50 rules at least to start with so that's where I'm coming up with the rules now a lot of them are very well documented on wasp and things like that on what to look for but this is just me and the other folks doing it saying we see this stuff all the time and it be great if maybe there was something that said we shouldn't do that so now we're passing I'll get out of the VM and I can pull that repo up if you want to take a peek at it so let's just drop through our quick conclusion stuff here and then I'll just open it up we've got about

what five minutes left three minutes left according to our time keeper so again this is open source if you want to see the code it's in get help go look at it I've gotten a lot of emails saying hey I wish this rule did this and I said the whole reason I open-source this was so you could do that yourself I don't have time to babysit all of them that's why it's open source so I'm welcoming contributions if you send me a pull request I'll put it in the repo that's totally cool I'd love to have people write especially if you're working in this framework add them back I've got a couple of things that I haven't got to

yet I need to add a lot of crypto rules kind of identifying bad algorithms and weak key links and stuff like that the secrets manager would be good we have some research going into getting better analysis put into the rules which is where maybe we're tracking if it comes from a static configuration file versus a request parameter in eliminating false positives that way acknowledgments Erik Meade is a local security engineer who is like a he took my very ugly proof of concept code and actually made it look like a real actual source code repository that's got like dependency injection and all this cool crap going on that I would never use without him so he's been a huge help the guys at

Microsoft actually were a huge help as I was trying to figure out how to write these analyzers and figure out what they do it's awesome that they open-source the framework because I looked on github and said here's the last two guys to commit to the Rosslyn repository and I emailed them and asked them a question and they responded within an hour it's amazing and then get er does anyone use git er just for chatting it's basically a chatroom associated with a git project there's Rosslyn engineers on there every day and you can just ask them questions and they'll answer them just right on the spot if they're available so that wraps everything up let's see we've got

one or two minutes left any other questions and I'll stick around for a while too if you want to I can show you the analyzer code maybe offline if you want to take a peek at it that's your crash course so easy right that's all you got to do at least in one framework I'll let you guys go figure the rest of them out

for dynamic analysis that's a tough one especially in in a DevOps pipeline because dynamic scanning can take a while as most of us have no no that was seen those actually saw so in a black hat Asia I was out in Singapore I don't remember when it was a few weeks ago and a set law from in busy immerse with Dave Linder who did a talk this morning he released a little it's like an acceptance testing framework called sputter and his goal is to be fast dynamic scanning so he actually based on the framework auto launches if it's java it'll auto launch a java web server and then do acceptance testing against the java app and it also supports dotnet

Python and three or four other frameworks but he's using very condensed fuzzing lists like so for cross-site scripting he's just doing about seven characters less than greater than an ampersand tick mark double quote and if any of those come back unencoded he knows that they're not encoding output so that might be where I would recommend starting if you're looking for very fast efficient more fuzzing sort of scanning from a more automated point-and-click perspective there's probably nothing really good that's going to sit in a pipeline like that without blocking things up for hours at a time so I think I would definitely recommend leaning on that out-of-band scanning that feeds issues back into the backlog is probably

the best recommendation I could give there but you definitely something some sort of fuzzing says to make sure that at least the top ten sort of issues don't end up in production because that's what the whole goal of this is supposed to achieve is making sure that never happens any other questions you're ready to shut it off okay all right well that that wraps it up