Edition 11: AppSec Primer - SAST - Part 1
First in a four part primer on Static Application Security Testing (SAST). This edition talks about what SAST is and why it's needed.
Before we get to SAST, I want to lay out a few AppSec facts. Most of these are obvious, but they provide a useful base when we ponder the central question for this edition:
Let’s say your system has a hundred defects. Hackers need to find only a few of them to launch a successful attack. As a defender, you have to find and fix all of them. This inherently puts us (the defenders) at a disadvantage.
All defects can be discovered through penetration tests (defined as: activity that simulates attackers). But PenTests scale poorly. You need highly skilled professionals to pull this off and it adds a lot of drama to your software development lifecycle.
Defenders know how the application they are protecting works under the hood. This is one weapon you have, that attackers don’t. Successful security teams use this advantage to find defects in a faster, more efficient way. Relying only on PenTests to discover defects is a bad idea as it puts you at the same disadvantage as the hackers.
Your security posture does not improve when you find a defect. It improves when you fix it.
OK, now, onto the main program for the day :)
What is SAST?
SAST is automated review of source code, with the goal of identifying missing or incorrectly implemented security controls and providing timely feedback on remediation to developers.
Let’s break this down.
Automated review of source code
SAST has to be automated. While manual code review can find security defects, it does not scale. SAST also only reviews code. This include the logic (classes, routines, functions), settings (config files) and dependencies (libraries, binaries). It does not inspect anything during the run-time.
A key feature of SAST is that it can review all of your code, which means, you can get excellent coverage, which is tough to measure in other forms of security assessments.
Identify missing or incorrectly implemented security controls
Broadly, here are the category of security controls that SAST cares about:
Secure handling of all data sent to and received from outside the trust zone*
Secure implementation of cryptographic routines (encryption, hashing, random number generation)
Secure logging and error handling
Secure handling of sensitive data
Secure authentication
Secure authorization
Controls against brute force (Anti-automation)
These categories can further be broken down into hundreds of specific controls (e.g.: Using a CSPRNG to generate random numbers). The first goal of SAST is to make a master list of these security controls and evaluate if these controls are implemented correctly.
*trust zone: Put simply, any entity your code should trust is part of its trust zone. Everything else is outside the trust zone. For e.g.: The end user of a web application is outside the code’s trust zone, given the user can be an adversary.
Provide timely feedback
SAST can tell you exactly where the defect is and often point to where it can be fixed. This is a super power which must be used well. Here are some features of good timely feedback:
Location of defect: Exact line numbers are helpful. In cases where taint analysis is performed (more on this in the next edition), locations of the entire call chain can be helpful
Remediation guidance: Easy to understand description of what the remediation should be. Bonus points for custom remediation guidance which maps to your orgs secure coding guidelines
Known-good code sample: In addition to guidance, its useful to have a relevant, secure snippet of code. The goal is not to ask the developer to copy paste this code (that may work in some cases), but to give them a practical example of a fix.
Timing of feedback: Faster the feedback, the better.
SAST programs should aim to provide feedback as early as possible As you will see in future editions, feedback does not have to occur only once. Reinforcement is good too.
Why SAST?
We would be foolish not to leverage the knowledge of how our applications work to find security defects. Source code tells you more about a system than any other single piece of artifact. Naturally, analyzing this artifact will also tell you more about the security posture of the system.
Source code can be reviewed early and often. You can use SAST in your IDE, in your CI pipeline and asynchronously on your repositories to understand the security posture of your application. This gives us flexibility in terms of how you want to run your SAST tool. For instance doing all of the below is a reasonable SAST program
Look for usage of dangerous functions while you type in your IDE (e.g.: are you using math.random())
Look for secrets in code on git commit
Do an in-depth taint analysis during pull-request (PR) review
SAST is an excellent way to provide educate developers. You can use the tools they use (IDEs, CI pipelines etc) to teach them about security. In addition, SAST also does a good job at providing timely feedback, which helps retention.
Measuring efficacy of security assessments is hard. ( e.g.: measuring application coverage in a PenTest is tricky. How do you know all workflows were tested?). In contrast, SAST can give you a variety of useful metrics, such as:
Coverage
Defect density
Mean time to detect (MTTD)
That’s it for today! In future editions, we will talk about How SAST works under the hood, understand the SAST product landscape and how to build a SAST program. Are there other aspects of SAST I should talk about? Do you think Boring AppSec should do more primers? Let me know! You can drop me a line on twitter, LinkedIn or email. If you find this newsletter useful, do share it with a friend, colleague or on your social media feed.