Some might consider finding and fixing vulnerabilities a major part of Application Security. It’s possible they might be right and so I’ve created this post. Normally I would not spend time explaining types of tools, but without explanations, I feel that most people would be lost. Therefore, this post is focused on web application scanning.
DAST Dynamic Application Security Testing is usually the starting point for vulnerability scanning. DAST scanning is good for traditional web apps, okay for some single page apps, and crap for APIs. But that doesn’t necessarily mean that you shouldn’t scan things. Setting up DAST should probably be the first thing that you want to do. Managing credentials is kind of crap and setting up the scanner to actually log into your application is annoying, but that is most of the work you will need to do. At the very least, use a light weight scanner like Mozilla HTTP Observatory to check if your website is keeping up with the latest standards for web security. These are things like proper headers and such. My advice for DAST scanners is to ignore most of the low and informational findings.
SAST SAST or Static Application Security Testing is basically scanning the source code or binaries to find vulnerabilities. There are different approaches to doing it. If you want to know more, I would suggest using Google or Bing (if you are into that type of thing). SAST is really good at scanning for things like SQL Injection and Remote Code Execution. You will spend a lot of your time probably looking through false positives, but if you don’t weed out the false positives then the developer will have to do it and they probably won’t. Focus on high and critical findings, the medium and low findings will just be a lot of noise.
SCA SCA stands for Software Composition Analysis and it is used to find known vulnerabilities in third party libraries. Most of these vulnerabilities are crap and you probably shouldn’t waste your developers time trying to fix them, however SCA is still totally useful though. You can use it to show developers what transitive dependencies are and why they should update their libraries. One thing some SCA tools do is show you licensing issues. The licensing part is really useful, especially if your developers like to pull random 8 star crap off of GitHub.
SCA is also super useful to help you put the fear of god into the developers. Showing the developers an application you scanned that has over 100 vulnerabilities of differing severity really has a positive effect on security until they start reading Nietzche and realize the hopelessness of it all. Again, don’t make them fix everything. Imagine your developers as Sisyphus ever rolling applications up a hill. Unfortunately you have no god-powers and are incapable of saving your developers from the inevitable existential breakdown (however, a short existential crisis never harmed anyone). For impact allow me to state once more that you shouldn’t make your developers fix everything. Have mercy on Sisyphus, the guy just wasn’t ready to go.
Container and Cloud Scanners If you are unlucky enough as an AppSec person to have to deal with these then I am sorry for you. They are okay tools, but container security is a super pain in the ass just like SCA tools. Cloud policy/config scanners are kinda cool but are not really in the realm of Application Security, so you should get paid more! These are neat tools but they also add a bunch of noise, so beware.
Fixing crap in your software Similar to the world of vulnerability management on the legacy security side (basically everything that is not AppSec), coming up with timelines and expectations for fixing vulnerabilities is kinda important. A lot of people say, “Oh no vulnerabilities, let’s fix them right now.'' Well developers have products to deliver because that is how the company pays you. So let’s not fix them all right now, but come up with reasonable timelines for remediation. Sometimes they don’t need to be fixed at all. I’m talking about acceptance here and there are times in life when one must embrace their vulnerabilities. You may still be insecure but at least you know it.
The almighty DevSecOps Scanning things in your pipeline is super cool and useful. Make sure you don’t increase the build time too much, so know how long your scans are going to take! For whatever reason developers don’t like waiting for their builds to finish. It’s okay not to scan in your pipeline. Sometimes daily or weekly scans just make more sense. If you do decide to scan in your pipeline, keep the scans lightweight. Self-service scanners are an option for the developers as well. Let them scan ad-hoc if they want.
Assessments and Penetration Tests If you have the time and skills to do manual business logic assessments and/or penetration tests, do it if you like that sort of thing. If not, there are a million security consultants out there always looking for work. Just make sure you evaluate a few of them to figure out which ones you like the most. You can ask for reports to be completed in a certain way, including reports that are machine readable so you can import them into your other tools to keep track of the vulnerabilities. Remember, red teaming is just fancy pen testing.
Build vs. Buy vs. Open Source Tools (Note: my friend told me to change this paragraph to a bulleted list)
Building linters with custom rules can be helpful if there are very particular things you are looking for.
Buy most of the tools if you have the budget, and the support is nice.
As for open source, there are a decent number of options out there, but remember that it is your money or your time, so if you want to be configuring tools and managing scans, go for it.
Be warned, vendors will hype up their products like none other. Make sure you POC that crap!
Things to consider Most of these tools are somewhat useful, just remember that it takes a lot of work. Don’t just dump them on the developers because they probably won’t use most of them. The biggest pain that you will have to deal with is keeping the scans going and weeding through false positives. Make sure you have really good policies so the developers know what they need to fix and it will be an okay experience.
Conclusion All scanners suck, but you should still use them. They will give you enough visibility into your applications that they will probably make it worth your time. If it stops a few high and critical vulnerabilities from slipping into production, it is for sure worth it. Dealing with false positives as a small team sucks, but if you just drop it on your developers they can easily suffer from alert fatigue. Make sure you have your policies in place so developers know what to fix and swear a lot when things randomly stop working.
Additional Reading and Resources
About the Author
Ray is a Life Coach and Conspiracy Theorist. He does AppSec in his non-spare time for money. Twitter