I've been sharing ideas on how to build security into your development process.
An important step in the development process is testing. There are many techniques used in security testing. It's useful to understand the different approaches, and their advantages and disadvantages. So for the next few weeks we'll look at the ways to test the security of your application.
If you missed any of the previous articles, here are the links:
- Building Better Security - Part 1.
- Building Better Security - Part 2: Secure Analysis.
- Building Better Security - Part 3: Secure Design.
- Building Better Security - Part 4: Secure Coding Standards.
What is Static Application Security Testing?
Static Application Security Testing (SAST) is also known as “white-box testing”. It tests the internal structures of the code, not the functionality of the application.
SAST tools scan and analyse the source code to look for vulnerabilities. After the scan, the tool produces a report on the vulnerabilities, and the specific lines of code to change.
SAST scans work on a set of predetermined rules. These are designed to identify the most common security vulnerabilities, like SQL injection, input validation and stack buffer overflows.
Most SAST tools support the all major web languages: PHP, Java, and .Net, and some form of C, C++, or C#.
Advantages of SAST
- Early detection:
SAST tools discover vulnerabilities in the early stages of development. (This is often described as “shifting security left”.) Early detection makes it easier to resolve the issue. - Easy automation:
SAST tools can be automated. Scans can also be incremental. You can run a complete scan once, and then scan only the code that has changed. So it takes very little effort to run a SAST scan, especially compared to hours of manual checking. - Good coverage:
Most SAST software is updated often to identify the latest security vulnerabilities. - Secure coding:
SAST helps to develop secure coding practices among the developers. As the development team investigates the SAST reports, they will improve the security of their coding.
Disadvantages of SAST
- Limitations:
SAST has limitations. It can’t test the application in the real environment. This means it does not detect vulnerabilities in application logic or configuration. You cannot rely exclusively on your SAST tool. - False positives and negatives:
SAST tools often produce false positives and negatives. Developers may become reluctant to use it if they have to deal with too many false results. - Time consuming:
While SAST is less effort than manual checking, the scan can still take time to complete. And then the results need to be checked. SAST highlights potential vulnerabilities, but the developers still need to analyse them. - Scalability:
Because of the false results and time to scan, SAST tools don't always scale well.
Choosing a SAST tool
There are many SAST tools available. Here are some factors to consider when you choose a SAST tool:
- Make sure it supports the programming languages you use. Dynamically-typed languages can be a challenge.
- Check that it covers at least all the OWASP's top ten vulnerabilities.
- Check the general level of accuracy of the results. There will always be some false positives and false negatives, but too many reduce the value of the tool.
- Think about how the tool will scale to support more developers and projects, and what the cost will be.
- Consider integration with your existing tools. Integration will save time.
Have a look at the OWASP page on Source Code Analysis Tools.
Conclusion
SAST can be a valuable tool in your development toolbox. But you must combine it with human expertise and other testing approaches. In the next few weeks I'll tell you about DAST, IAST and RASP.
Have you had any experience using a SAST tool? Please share your views and comments.
Join me next week for Building Better Security - Part 6: DAST.