Published Feb 4, 2020
WRITTEN BY JD BURKE
JD Burke is a technical renaissance man of sorts – a dragonslayer – with decades of experience ranging from software development to operations management, leadership to front-line technician… and all the battles that lay inbetween. He can be reached at email@example.com or @jdburke2k on LinkedIn.
With the variety of application security testing (AST) tools out there, you might be wondering which one should you use to secure your code — or whether you need all of them.
Application testing has changed a bit from the days of waterfall development and slower development cycles. In the world of DevOps, developers and testers are moving at such a rapid (CI/CD) pace that automated testing has come to the forefront as a critical component of any modern-day testing program. Somewhere along that journey, teams started to realize that test tools could be modified to help test for quality and security issues. Common security testing paradigms seen today include SAST, DAST, IAST, and SCA.
So what are the strength and weaknesses of each of these tools? And how can I choose which one(s) suits my needs? Read on to learn more details about them.
Static Application Security Testing (SAST)
SAST tools are cousins of LINT-ers and are used to crawl through source code (typically but it can include byte code and binaries… code at rest), searching for coding patterns that match known weak coding practices. In short, they are code scanners. Those coding patterns are generally defined by organizations and standards that we care about – ISO, NIST, OWASP, PCI-DSS, etc. and are looking for coding weaknesses such as OWASP Top 10 type vulnerabilities, duplicate code, hardcoded credentials, efficiency, portability, etc.
SAST is one of the left-most testing tools in a DevOps pipeline, allowing for the discovery of issues very early in the development lifecycle (which means at a time when it is cheaper to remediate). They tend to live so far to the left that they can be used by the developer prior to contributing code to a baseline or repo, all the way to the repo or just after – helping to enforce quality prior to code being pushed to a build or test phase. This exposure to source code is why SAST is frequently likened to White Box Testing.
SAST tools can be very good and helpful with a few points in mind:
- They tend to be language-dependent. However, there are many polyglot tools (tools that can analyze multiple languages) with a wide variety of features at a range of price points. You may end up running multiple tools because of the specific mix of languages, features and scan quality.
- They can be “noisy” and generate a lot of matches that may or may not be action items. This is because they look at source code, typically out of context – so none of the compensating controls you may already have in your code or your network/environment.
- They will tend to yield the highest value if developers focus on fixing classes of issues rather than playing whack-a-mole and chasing individual point problems.
- Some of them are slow and may work better in selected positions in your pipeline.
Dynamic Application Security Testing (DAST)
DAST tools tend to live farther to the right of SAST in the CI/CD pipeline and work with code that is a release candidate or runnable. These qualities earn DAST the Black Box Testing label and look a lot like cousins of the regular unit and regression testing efforts.
The Test Team will test the application looking for bugs along a happy path of a user story. Maybe you have a good test team and they look for bugs that live just off of the happy path, or maybe from experience from previous bug hunts. DAST is similar in that it looks for bugs (or defects or vulnerabilities) from experiences from the pen-testers, hackers, and tools like Metasploit and Burpsuite. The application is actually run and now is in a network and environmental context, which allows the tester to probe for weaknesses with communications, architecture and run-time configurations.
DAST are valuable in their own right but will not be able to do everything. They will work best when paired with SAST (at a minimum) to the left and controls to the right.
Because DAST is looking at a running app, they will be less language-specific than SAST, but anything they find will be more expensive to fix (because non-developers found the issue and will kick the code all the way back to the beginning of the pipeline typically).
Interactive Application Security Testing (IAST)
There is a variant of DAST called IAST. IAST is DAST with an instrumented app/environment. If SAST is “white box” testing and DAST is “black box” testing, then IAST can be described as “grey box“ testing. There is instrumentation or agents in the app that watches the DAST like external actions and tries to map those to expected signatures or patterns and to source code areas. Mapping external stimulus via the IAST agents allows testers to tease out more sophisticated bugs and build connections to DAST and SAST tests.
As with DAST, IAST will work best with other testing tools (DAST and SAST) and will have some cost because issues are being uncovered towards the right side of the pipeline.
Software Composition Analysis (SCA)
The “-AST’s” (SAST, DAST, IAST) are all good and valid testing tools, but another tool in the toolbox is Software Composition Analysis (SCA). SCA is a code scanner tool that is used to look at third-party and open source components used to build your applications. SCA is a very valuable tool and stands to become more and more valuable as the speed of the software development lifecycle becomes faster and developers use more and more packages and components (whether internally or externally created). SCA tools step through your source code to create a package bill of materials, i.e. a list of the packages used to help create your applications. Typically, those SCA tools will list out the packages found, perhaps with comments on their age/freshness, their license encumbrances and possibly an analysis of their security posture.
SCA tends to be very much to the left end of the pipeline and pairs well with SAST (because they both tend to be on the left and looking at source code). Because of the growing importance of OSS (Open Source Software) in codebases of today and tomorrow, SCA is probably a MUST have, so much so, that many repositories are starting to include SCA functionality and integrations with external SCA tools.
So, what should you do?
Well, it depends. If you have third-party/open-source components in your application, you need SCA. If you are following (or working toward) a DevOps approach, a SAST solution can help you build in security while reducing the chance that security testing becomes a bottleneck in the release process. Preferably you want the SCA and SAST integrated together and for them to take directions well from your CI. You might want multiple SAST solutions so you can triangulate on issues — and possibly for language coverage.
Focus on classes of vulnerabilities, teachable moments, wrappers, and modules that you built that you know are good and safe. You might be able to do something like DAST with your current test team and leverage the spirit and power of DevOps. As the pipeline speed picks up and the easy issues are retired, start to roll in DAST and IAST tooling.
Don’t be shy about asking your peers and the communities for advice and help – including us! We are standing by to help!
If you want to try out first-hand a SAST and an SCA tool, contact our sales team today to request a trial of Kiuwan.