SAST in plain English
SAST stands for Static Application Security Testing. “Static” means that a tool reads the code but doesn’t start the program. It looks for patterns that experience shows tend to cause security vulnerabilities – such as input that is processed without being validated, dangerous function calls, or passwords hard-coded into the program.
An everyday comparison: SAST is like checking the blueprints before a house is built. Anyone who checks the structural design can tell on paper if a load-bearing wall is missing. What the blueprint won’t tell you is whether the front door will actually be locked later on. For that, you have to rattle the door of the finished house – and that’s the job of DAST, which tests the running application from the outside.
How SAST works
- Read in the code: The tool analyzes the source code – the program text written by humans – and some tools also analyze compiled code such as bytecode or binary code. From this, it builds a model of the application.
- Trace data flows: It traces the path data takes through the program. If user input reaches a database query without being validated, for example, there’s a risk of SQL injection: attackers could slip in database commands of their own.
- Apply rules: Predefined rules detect known error patterns, such as outdated encryption methods or hard-coded credentials.
- Report results: Each finding is listed with the file, line number, severity, and an explanation.
- Assess and fix: The development team reviews the findings, weeds out false positives, and corrects the code.
SAST can be integrated directly into the development environment – the program developers use to write code. It can also run automatically with every code change in what’s known as the CI/CD pipeline, which automatically builds, tests, and delivers software. Experts call this “shift left”: security moves to an earlier point in the development process.
A practical example
Here’s a typical scenario: A mid-sized software company is developing an appointment booking platform and integrates a SAST tool into its pipeline. The very next code change triggers an alert: a new search field passes input to the database unfiltered. The developer fixes the flaw in a few minutes, before the code goes live.
There’s another flaw the tool doesn’t find: by manipulating a booking number, logged-in customers can view other people’s appointments. The code contains no error pattern the tool could look for – an authorization check is simply missing, a typical IDOR vulnerability. This gap only comes to light in a manual code review by security experts.
Why does this matter for businesses?
The later a flaw is discovered, the more effort it takes to fix. What can often be corrected in minutes during development can lead to emergency updates, customer notifications, and, in the worst case, a security incident once the software has shipped.
On top of that come external requirements. The Cyber Resilience Act will require manufacturers to test and review the security of their products effectively and regularly. ISO/IEC 27001:2022 and PCI DSS 4.0.1, the payment card industry’s security standard, also contain requirements for secure development and for reviewing code. SAST is an efficient building block for meeting such requirements in a verifiable way.
However, SAST tools also produce false positives – alerts about problems that aren’t really problems – and miss entire classes of flaws, above all logic errors and missing authorization checks. Relying on the tool alone creates a false sense of security.
What to look out for
- Test early and automatically: Integrate SAST into your development environment and pipeline so that every change is checked.
- Tune the rules: Adapt the rules to your programming languages and frameworks – the software scaffolding your applications are built on – and document known false positives.
- Set clear thresholds: Critical findings should stop a release; less urgent ones should be fixed within a set time frame.
- Don’t forget third-party code: SAST mainly checks your own code. For included libraries, you also need a dependency check (software composition analysis) that compares third-party components against known vulnerabilities, as well as an SBOM.
- Combine people and tools: Have security-critical parts such as login, permissions, and payment functions reviewed manually as well.
- Test the running application: Complement SAST with DAST and a penetration test.
How Rootsektor can help
As part of our Code Review & Reverse Engineering service, we use SAST tools as a starting point, assess every hit manually, and specifically look for the flaws that tools miss. We’re also happy to help you integrate SAST and dependency checks into your development processes in a way that makes sense. After scoping, you’ll receive a fixed-price quote – you can request it via our Pentest Quote page.