
uh thank everybody for showing up here um you guys signed up for a static analysis talk right before lunch so i appreciate that so much uh your brave souls and without further ado let's get started um right before i click that next slide my entire slide deck and everything i'm about to talk about is already live it's hosted at tiny si static or tiny si shock so feel free to look ahead look at the material i've got some recordings of my demos as well embedded in the talk so everything that you need so don't worry about taking screenshots let's enjoy the ride um i've already had an awesome introduction so all i'm going to summarize with that
is i code i teach i hack um this this talk comes from a place of me actually being a developer and trying to implement security best practices in production facing systems and in the real world i am also a red team consultant working with secure ideas we have been um i've only been in the company for three years securities has been in the business for 10 years we specialize in api and web application pen testing and offensive security in general so that's the brief and we're just going to hop right in so the outline of this discussion is going to be ttp and i know that's not the traditional way that we do it in
cyber security but it's it's a nice way to encapsulate all the various components of a static analysis engagement we're going to be focusing in on the tools that we're going to use then for focus on the techniques and the stress and the overarching strategy and then we're going to go about going to talk about the people because it's always been about the people um and i know as engineers we get we might get dissuaded when we're talking about people um ignoring the human element of security uh is going to make your efforts futile so um this part the last part is going to be really important so stay tuned now here's the basic definition of static analysis
for the uninitiated now the whole point of what we're going to be going through right here with static analysis is getting as much information we can glean from the source code without executing it without running it and without um doing that sort of dynamic analysis there so what information can we glean from just examining the structure of the source code itself in a security context we're looking for things that compromise the confidentiality integrity or the availability of a given system now stack analysis is amazing i am passionate about it you can get me running and talking for two hours on this stuff but it isn't perfect um there are some catches and will and there are catches of pitfalls and
we'll go over there but there are many things that can lie to you the source code cannot so this is where the benefits come in anything that gives you insight into into the code is static analysis so some of the tools i'll be talking about here are going to be auditing tools for dependency checking will be some linters traditionally dev only tools but these tools are actually going to be useful for examining the structure of the code base and give us as analysts as uh security security engineers as red team offensive security consultants uh information that we need to actually help our help the second party help our clients our co-workers and our employers achieve
what they want to achieve so the beautiful thing about this day and age the new world order we've got infrastructure as code now and now not only do we have the actual structure of the web application in the code base but we also have things like confirmation templates so the cloud infrastructure that the app relies on is now also embedded in the same place right next to the code it's turtles all the way down and it's all code it always was but now we all of that functionality surface so we can actually do that analysis and right before we going to go into it we're going to do a brief story time and this is about
what we typically go through in a static analysis engagement so here's what we here's how it normally traditionally goes we have a we have security people all call maybe the cso really likes us and brings us in and try to whip the devs into shape um we all commiserate and we go through like oh as the app app does and we may get maybe the project owner in on the call maybe a senior architect on the call um and then we discuss about what the app is we get the source code sent in we start the engagement don't get me wrong we do the i'm usually the one assigned to this and we do our best and you and the
entire focus and the engagement is about improving the security posture of the client but at the end of that process which is usually about a week we get uh we send our report and for some organizations it just sits on the shelf and it maybe is useful for that one time that one and done but it's not really integrated into the appsec program itself and i'm telling you there's a better way there's a better way to use static analysis so that revitalizes and defibrillates your accept program so your first instinct when you're trying to change the world is to try to grab every tool that you can with sac analysis to cover all your use cases hold the
phone wait a second slow down do you even know what like what language some of your apps are written in are you familiar with the tech stack that surrounds it answer those answers to those questions need to drive what tools you reach out for and what tools you get there are many tools on this list every one of them was hand-picked and selected because one of our clients needed it so for example some one of our clients really trusted vera code they're the better they're an industry leader in form static analysis but it can get pretty pricey to scan it um so there are some people with there's some clients of the budget that can
handle it and want to get that analysis done that way for other clients we're just looking for okay what can you give us with open source tooling so for one client we've got a multi-level tech stack some python some java for the python parts we use sonar cube and bandit for the java parts and their mobile app deployments we also use mob sf and sonarqube to examine that code a lot of people commit their bash scripts so let's see if we could use things like shell check on here so that we can take in the time to analyze okay are there instances of the code base where you can get maybe command injection and onto the
system or onto the server that's running this so that's what you need to focus in on you're building your tooling around your needs minimalism is important here and nose reduction is also important so if you've got if you run uh the suite of tools as an analyst and you've got maybe a hundred high level vulnerabilities someone could be wrong it could be the dev team's writing insecure tool or it could be the tool that you're using that's generating a false positive and we'll discuss the communication element and all of that stuff later on in the talk but context is really important here another way that tooling is really effective for is reducing waste and reducing
duplicated effort so the so do not waste your time trying to manually go through vulnerability management and detecting it oh we're talking about basic application security a like oauth top 10 number nine right don't use vulnerable components that sounds easy sounds straightforward it's like a best practice everyone should do it it's not i can tell you from experience is going to be a hassle it's going to be difficult but something that needs to be done i'll give you a brief examples a few rants if you will the request package um for uh that's hosted on npm is going to be deprecated i think february 11th this is a foundational package for handling http requests um pretty much when node was
from the beginning of the npm ecosystem uh requested the request package has a long history if you are running node in your system there's a chance are that you're using request or you're using a dependency somewhere in your chain that also uses request it's going into maintenance mode and then eventually won't receive updates so if you're trying to deploy a web app on using create a web app using node that you need to look at your software supply chain you've got to make the updates and configurations and look in your supply and you're looking into the dependencies you have and we'll cover that in another demo another free another freebie and rant if you are
running python in your java code chances are you're using the json library which runs on python2.x that is end of life it's end of life they actually started enforcing it this year but it's been end of life for about a decade and you're running end of life software there are no patches for this so you've got to really dive into the architecture for some of these projects start from the beginning don't create new soft don't create new software or create new projects from end of life and deprecated a code you got to start that from the beginning now we're going to do a brief demo and this is going to cover the workflow for an analyst this is for security
teams this is for that one security champion that you've got already embedded into your devops for your devops team um or it's consult a third party consultant you call for the job you're going to be standing up at vm we're going to be standing up a vm that's called static analysis ttp that is publicly available and it launched about a couple hours ago um credit huge thank you to alex rodriguez for my co-worker for helping set this up it's made my life so much easier and i'm going to demonstrate how we're going to use it today so tab tab tab we're just going to hop in so before i'm going to assume that you all know how to clone a project
get clone whatever and that you've already got it on the machine one thing that we're going to need to focus on is the main configuration file since this uses vagrant we're going to just name the vagrant file now the one line uh the one line that's going to be really important to be this line in this case i've already got the vm set up to a directory on it to a directory on my system i'm only double escaping these slashes because i'm on a windows box and that's just what we have to do it's going to mount it into this client code folder so we're opening up the host just one folder on the host file system
and make it available to our guest vm and we do handle that with the configuration line by the way everything i'm going to talk about is already embedded in the readme but if tldr you didn't read um you can hop in and listen to the recording with us later so now that we've got the basic configuration and everything set up we just do vagrant up and from there we're going to just give it some time and load and while we're doing that just going to brief a brief introduction for how we're going to do this the next steps we're going to use is we're also going to use vagrant to provision our different tools now this is base now the provisioning
for this vm is going to be using it uh it's going to be using ansible ansible playbooks and so we've got it set up so that for based on the tool so if you want to provision with sonar cube you throw up sonar vagrant provision with sodarq but you can actually work on your workflow and get it automated to the point where if you know a certain project or a certain client you can do vagrant provision and then that client name and then automatically get all run the playbook for all of the tools so a lot of the so shell check mob sf bandit those already come included are already alive in the repo and we're getting about done from there
after we after we provision everything we're going to hop in uh hop into the box via ssh and then just run some analysis and while we're finishing up because this looks like it's going to be about done i'm going to take a sip
mainly because i'm mainly because i'm also out of coffee
and if this crashes and burns rather than sacrificing the chicken to the demo gods i've got also a recorded version of this demo as five minutes embedded in the slide deck so if we have to go to it we can alright that's done um now we're going to provision the script so i'm going to cheat since i've already done this before and just provision it with sonar cube um sonar cube is the open source competitor to uh veracode so there's a lot of general purpose tooling we like to use it for python for java and also a job and do some additional javascript analysis that we can't get with other toolings other tools so the ansible run the
run its playbook and then we'll be ready to start while you're waiting for this um and getting this to set up this honestly takes minutes you can also jump into the source code you can jump into the client jump into the client's code and just start to go through basically doing manual search for things like okay do we have heart do we have hard-coded credentials all right do we use insecure random number generators for the cryptography libraries um so on and so forth so while you're getting things set up you you can just have your hands always moving always doing always doing something and we're done so vagrant ssh we hop into the box and we're going to highlight and keep
track of this ip address as this is really important it's going to we're going to be navigating to the instance of sonar cube on a port that's on that ip address and from our host machine we're running the analysis and we'll be looking at the analysis and the whole dashboard of everything created from there all right when and sometimes it's a playbook you get um it already comes with commands and scripts already included so in this case we've got sonar cube we're going to do sonar cube create and that will create our so our cube instance and we're also going to do sonar cube start now there's also another command called sonar uh s i sonar cube
monitor if you've got a tmux or screen session you can make a new tab you can make a new tab i guess you call it um and have actively monitoring the logs to see how the instance is running this is going to be a brief demo so we don't have to do any of that so alt tab alt tab go to chrome and then and we're just going to hop in and log in via the browser awesome so we're in sonarcube this is going to be a test instance that we do so the password is admin admin again this is a local vm that's running on your machine um and those are temporary credentials but for the sake of argument
i'm going to generate i'm going to publicly generate like 100 character 200 character password it doesn't matter i'm going to be new i'm not going to save this because after this demo i'm going to be nuking the vm anyway so we're going to create a project in this case it's the static demo now you can call the the token that it generates anything in this case i just have a human readable called static demo a starter for it ends this is going to be the initial project for it i'm going to hit generate and then we're going to hit continue the now you've got multiple languages that are available um maven and gret and gradle are for are really
for java apps dot net is for your runnings if you're running c sharp um we're going to do other since we're the project that we're going to be examining is going to be a python blog and of course linux because our guests we're going to be running all of this in their guest vm which is a ubuntu box copy that over tab tab back to the terminal and we're going to change directory to the client code that we configured in the vagrant file that's where all these projects are going to be now these are just open source projects that i pulled from github so i'm looking for and you can run this to test it out as
an example we're just gonna we're just gonna hop into python python blog and then within there just run sonar then runs an argument and like and like we were talking about for a majority of your static analysis a stack analysis is going to be you taking the time not to to either manually look for some things or go through the various findings that you find because these scans are not going to take that long at all and you don't have to worry about exploitation of the vulnerabilities you find unless you're just the type of you got enough information from your client or you were able to stand up a version of the web app um on your machine and then try to pen
test it so if you could squee if you've got extra time on your engagement and you and you want to add some flavor for your client that's power to you and we're done so we're gonna hop we're gonna hop back we're going to hop back to sonar cube and now this is a general purpose tool that will help you with code smell and things like that find areas in which there are bugs but what we're really focusing in on is vulnerabilities and security hotspots so let's see what we got here well we got a we've got hard-coded credentials in the code base and i don't know about you but i call this high vulnerability now you're going to
have to be a proper analyst dive into the dive into the source code make sure that this isn't a unit test make sure that this isn't just test code that isn't being shipped out but from the looks of it it looks like just credentials and plain text especially it's going to be used for the product especially since they're going through the effort of hashing and salting it so i count that as a high
so i'm gonna do brief skip in since the demo went well we don't have to we can skip over the video we don't have to go over it so that brings us to our second point how do we fit this into the organization how do we fit this in the appsec program because the previous demonstration we're not expecting the entire dev team to go manually through static analysis they've got to push out code they've got to meet their deadlines and get to the sprint so how does this fit in to a global appsec program the first part of it is actually it's not on is not only do you have the security team analyzing and looking at at the products
also incentivize the engineers who are working on on the product or the service to look at the code now even the best app second even the best appsec engineers even um secure people in general there there are going to be some missing spots that they're not going to catch if you don't allow your engineers to actually take the time to look at the source code and incentivize to look at the source code and improve the and improve the availability of the system because that's ultimately what all this ties to you're running in functionally blind there are things that the engineers are going to see that we're going to miss and the example from here this awesome meme
is like a designer the spacing between letters is called i think it's called kerneling that's something a designer would see otherwise who cares you know so let the engineers take a look at take a look at the product for security vulnerabilities embed security champions within the dev team because with then it's not going to be a checklist with them they're going to find they're going to have a deep understanding and be able to find things that you're not going to find immediately brief shout out to everyone who's doing the ctf and secure coding challenge godspeed to all of you you are making apsec better now we move on to automation so let the engineers analyze
now we move on to automation and this beautiful skcd describes the story of my life don't add any more automation than what is needed it's okay if so initially some of the stuff is going to be manual is going to be manual at first you have to uh you can only optimize after your workflow is functional and each of the tools that we bring for the automation we have to bring them in back tying back earlier to that need so we use cloud formation to automate to automate standing up cloud infrastructure so we don't have and we don't have people up hopping in to the console or we don't have scripts tied in over our scripts and the sdk
trying to stand up cloud infrastructure the reason why we bring cloud formation in and so we automate and reduce the human error of that process we know the task in which we're automating and it's the same thing with these security checking checks that we are do going to show you i'm going to show you ways that you can do some linting on your cloud formation templates and how to do some initial dependency checking with with code pipeline the whole point of this automation is to actually take the process of automating the real task of of examining your software supply chain as it's called right now and your dependencies for vulnerabilities this is something any organization
should do man should do even if it has to be manually we're just using tools to make this process a lot easier we also need to associate these sort of static analysis and the and these tools with feeding into the uh cicd pipeline within the existing security process as well as the existing development cycles so imagine if you will we're going through the traditional pen test for uh for cyclical methodology where we do some reconnaissance uh before we start the engagement do some reconnaissance see what we can find online maybe find a few engineers and take them out to coffee see what they will spill about the project and then when we are on the engagement the first thing we do
is not trying to break things not trying to hack it but actually go through the happy paths traverse it as a user try to understand the application then from there discover vulnerabilities and move on to uh exploitation of those vulnerabilities instead of imagine how much better the reconnaissance application mapping phase of this would go if you have all informa if pen testers have all information on the table rather than having it a gray box or a black box engagement have a full white boxing a full white box engagement that way it make that way you have an analyst looking in to the source code itself while you've got another team doing dynamic analysis or penta
or a formal penetration test and then you can point out how this fine how findings how the findings correlate to the actual source code and make remediation process a lot easier and quicker so imagine how much smoother and how quickly we can get at real actionable insights from our engagements if we add this this level of complexity if we glean all this useful information and so that brings us to our demo so this is going to be integrating some of these tools in an active ci cd pipeline we're not going to do it live we're going to do a video because i love you all i love b-sides and i love everyone on this call
but i don't trust you having the call pre-recorded gives me a chance an opportunity to scrub confidential information like arn's and things like that this isn't a pre-reduction facing system in any way it's in a staged environment but i am paranoid um as everyone else should be so let's get started so right now we're just in aws encode pipeline i notice that the build cycle has failed let's hop into the logs and see what's going on so from there we've got a build project which is just a container that's already pre-provisioned for that's already pre-provisioned from aws so we're going to run it it's in this case it could be it could be your own docker container it could be
uh amazon linux or it could be a ubuntu box all of that's configurable either through cloud formation or through the console however you want to do it we dive through the law we dive through the logs and we see that we've done a yarn audit now what yarn and npm audit again all they will do is just look at the existing dependency trees found in the package dot json and the package lock and then see if some of those dependencies have previously disclosed vulnerabilities so you're not looking for zero days here you're looking for you know obvious patches that you're missing so we continue on we've got this project is less than a month old um
yeah pretty much i think we started it'll be like 33 days from when we started and we've already got dependencies that do denial service cross-site scripting and maybe some code execution or op prototype object pro object prototype poisoning and it's resulted in too high we get 44 vulnerabilities two of those are highs now i don't know about you but my boss does not let me ship client-side code with vulnerabilities in it so the reason why we're putting in yarn audit into the pipeline is so that we stop the build process maybe throw an alarm and alert so that way we get notified of okay there's some patching that needs to be done now again initially that can be
done manually or you can provisions do some scripting on npm audit fix to see if you can get your supply those dependencies fixed before you launch all right and you also can use a tool called cf nag now this does basic linting of your cloud formation stacks to make sure that they fall amazon um best practices funny thing is we have um our project is being handled by amplify we're doing doing amplify to handle deployments and amazon tooling is generating these cloud formation templates and even then um cfnag has find something to complain about of relatively untouched cloud formation stacks so it's one of those things where it's okay if you're not doing the cloud
right um there's no perfect way there's no perfect way to skin that's got there are better things that improve overall operability but don't be afraid don't be afraid that your completely doing everything and doing everything wrong unless you have an s3 bucket with what credit card data out in the open internet okay there's some standards there but there are many ways to skin a cat and your use case has to be dependent on your organization and what uh sort of what sort of projects that they're the reason why they're using the cloud what was where was i in the tangent all right cf nag these screenshots are just of confirmation templates some of them are warnings
of general things sometimes you'll get some security issues news that'll highlighted some helpful suggestions of how to set up logging and things like that and so although i've had it i we have see ef and nag already in our pipeline we just couldn't get the video ready for the demo today all right almost done this is the third and this is the third point and this is a vision to you and this is going to be a part where i i step on the soapbox and and say some basic truths about human interaction
um and communication and inoperability and that's the true fact that our organizations like communication is deteriorated to the point where every time a thought leader walks age and points out that cooperation leads to better business outcomes we hail them as the innovator error of the 21st century and you may ask well you're on the floor you're you're a speaker now um what are you what what is your response what do you add to the discussion and i'm like dude i'm 25 like i don't have the answers i don't have this figured out but you start making things better by being curious and by being and i asking questions and so before you even start this process of
static analysis before you even go in engagement with a client here are some questions that you need to ask before one what is this app supposed to do why is the business and why is the organization spending time money energy and effort into creating this product or service what are the standard use cases from there and then from there we're not trying to block the threat that is new tech and that and serverless web apps and things like that the goal our goal as security professionals and practitioners is to secure and to maintain the confidentiality integrity and the availability of the system and so it's not a threat that we're trying to eliminate we're trying to
actually see we're actually trying to get this thing launched and do it the right way so start by genuinely asking questions and you're not trying to interview or grill people you're just genuinely curious on what you can add to the process now we'll get this product launched and we'll make it more functional once it's in the public eye you will get security compliance if there's genuine co opera collaboration in your organization if you've got security teams you've got operators and you've got developers and engineers working together then pci is not going to be a problem now there are some check boxes and things that you got to do but if you have genuine cooperation between all of those parties
and from how and from the business standpoint you can get the security compliance now you can get the security compliance if you've got that teamwork there and now i don't bring static analysis as a way to create some holy war within your organization these tools are not omniscient they some of them generate a lot of false positives but it is a starting point and the only way to weed out the false positives and get at the truth and the heart of what is what is to actually begin the discussion with all parties involved this is what um this is what it looks like this is what devops this is what agile and in manager and corp manager or
corporal speak this is what synergy is about it's about genuine collaboration between the teams you don't have to have these devops engineers that are that write sling code and spin up infrastructure unless your organization needs it if you've just got an i if you've got a dev team and an ops team that just communicate better and effectively that equal that equal sign is they both result in a truth they both boil down to something that's true and functional if you hire a bunch of rock stars you're not you're just going to get a bunch of solos you're not going to get a symphony in collaboration so let's change the story that we had before let's flip the script on that and let's
make the stack analysis engagement a better one this case instead of just you know sec people commiserating at the beginning let's have it be a corroborative effort let's invite the engineers let's invite engineers people who are written written code production code into the kickoff meeting and then once the once uh security people all as anal as consultants we the tools we bring to the engagement are minimal and are focused specifically on the organization's needs then after that engagement is done after we've created it after we created a deliverable after we started the process we then let the engineer we then get let the engineers analyze the product and the solution and try to see where that remediation process goes
where we can fit the tips and tricks in because they're ultimately responsible for remediation in the first place then we can work on automation and then once we have figure out of what we can do then we automate it and we associate it in the existing dev cycles and the existing security culture and finally when we're interacting with the people when we're interacting with each other we stay genuinely curious and we stay collaborative because it's not just a one and done report um i i one of one of our clients is just um on a pen test it was a follow-up report and one of the things that i said was okay are we done with security now
security is not just a one and done but it's a journey and it needs to be a journey with all the teams working side working harmoniously with one another that's hopefully that's what i'm presenting to you that's the vision that we can create together thank you for your time and attention sac analysis put a shock to your system all right thank you very much uh is there any questions or anything
it looks like in chat somebody
somebody asked if this vagrant stuff is a project alex set up or is that on github uh both it is a project that alex set up and it is available on github um the links like the link to it is in the slide notes and it's um static analysis ttp it launched today so that is publicly available we accept prs there's there's open bug while i was working on the demo at two in the morning so we accept prs we accept pr's and it's freely available for the use the url to the project let's see if i have it in my clipboard i can drop it in chat static analysis ttp actually i have it and why am i doing
this i have it in one in the window
right there and yep any other questions
yeah i'm sorry i i muted and started talking so i'm i'm a pretty i'm a pretty big sonar cube fan i like it um the uh i get mixed reactions though when i go outside of like my small group of other fans uh people who they they want to downplay at security benefits right and a play is quality benefits and i try to tell people that i like the message that sends the developers um that it's bugs first or however how i phrase it but in in your experience or the people you talk to what's kind of the reaction to that particular tool um i mean i like it i'm a fan i just wanted to sort of commiserate a little
and hear what you had to say there so um the i get which i get i get what you're saying for um when when we're doing an engagement when we're doing the stack analysis equation sorry cube isn't the only tool that we're running we're doing in our process we're running multiple tools we actually spend the time uh i also follow up try to figure out eliminate the false positives and we generate when we work on the reporting and the deliverable we're not slapping the we're not slapping like the results of sonar cube immediately to the client what we're generally doing is we filter is just the aggregate of all of the tools the aggregate of um all of the tooling
so one thing that i for say if we're doing a salsa thing if we're on if we're working with uh dev team more directly is allow that and keep going with that theme keep going with the keep focusing on bugs first because all security vulnerability is is a is a bug that compromises the cia triad of a given app so start as in and start with us keep continuing on with that um don't let then part of that has to be done at the top level um like again static analysis tools aren't perfect they're going to be some configurations um because the they're going to be devs that just write dot og code and then they're going to be tools
that are way too hyper sensitive so that discussion i don't have an easy answer of how yeah yeah yeah how i've got to eliminate the discussion you know i think um i think part of it is our different perspectives right i'm i'm in a place where it's the same group of dev teams right we're building like two or three products and i'm bringing that to them as part of their pipeline i'm not it's like um i could definitely see the benefit of hey i'm doing an engagement and you want to take a look at your code i've got this great tool and that allows you to present it as a part of the whole which
is nice that would make sense that's why it's a little different for me um i get some mixed reactions with it i mean i think it's i think it's fantastic and i like how it uh integrates uh generally integrates with most of your code repository systems right so you do a pull request and you can have the results in the pull request and it's like okay this is tool that runs and here's a pull request and if you want to go forward address this and at least someone's got to recognize it so stuff like that that's pretty cool try um what i would say is i know it has to try to frame it try to work with the product owners
people who have uh the stake in the building the requirements and build that into build that into the requirements of the product because one thing that you will find and this is going to be create a lot of friction um shift left a little further past the dev team because when you get to the point where you're in a position where you're blocking the launch you become an obstacle they try to backflip and they'll try to move around they have to the that's the whole point of being out agile is to try to streamline it and get as fast as possible and i don't know your organization is your organization i don't know how that we
would have to get on a call and do an engage engagements and like do a full art arc review to figure out what's what and where it's going on but actually when the product is made have those like security things that off what does the authorization on authentication look like from the beginning the requirements presented to the engineers and then it's not a security checkbox thing before launch it is hey this is just part of the sprint this is part of the requirements that we're already in the user story the user story is we've got mfa we you you have mfa as a feature right that makes sense yeah thanks for thanks for expanding on that i really
like your perspective like there's uh i'll i'm gonna do some of that thank you yeah um anyone else have any questions go ahead i'm gonna go do this oh yeah i had a quick question that url doesn't seem to work if you go to the professional evil site it's not one of the things listed yeah okay if you lop the static analysis ttp off the end it's not on that page
yeah give me give me a second i thought uh hey it's brand new stuff happens yeah yeah and check it now to see if it's launched it was before we had a private we had a as a private repo yeah so you got it on private we're sweet thank you yeah no uh happy to help thanks for making this stuff available yeah no um i think yeah thank you all for having me any more questions all right well thank you for speaking uh there is that