How a SAST tool may benefit
👋 Hello technical folks ~
As we all know, a software is made up of self-written code and third-party components. Having insecure third-party components and/or badly written code will produce flawed systems.
But, how do we ensure that those self-written codes are secured? Do we wait till we’re fully done with implementing the system, let the security auditors review and audit our system, and pray hard that there’s nothing major found in our system?
Of course not! If we allow that to happen, we’ll look exactly like the image above! A way to avoid this is to have a Static Application Security Testing (SAST) tool in place.
Note: Do not mix up the Open-Source Scan (OSS) and SAST scan; the OSS looks at the third-party components used in the system whilst SAST scan analyses the code written by your team.
“Why need a SAST tool when we are already doing peer code reviews daily?”
Peer code review is tedious and prone to human errors; there are just soooooooo many areas to look at in a code review and here are some of the areas:
Now imagine this:
“You’re in charge of reviewing your peers’ codes and there are 20 pull requests (of small and large-scale) pending for approval. You’re left with just 5 days to project deployment and you still have some features to work on.
What would you do?”
You’d most likely do some basic checks on your peers’ codes (i.e. function accuracy and code smells) and approve them as long as nothing breaks. You won’t have the time and energy to check if there is any deprecated function used, how robust the cryptography library is, or if any secrets, IDs, or credentials are being hardcoded, especially when some pull requests contain more than 10 files with more than 10 lines of changes in each file.
With a SAST scanning tool in place, the peer code review time and effort will be vastly reduced as some of the areas can be covered by the tool (shown below).
This is exceptionally important for Agile teams since we welcome shorter feedback loops!
“When or how early should we have the SAST tool set up?”
Most of the issues shown in the screenshot can be fixed rather easily, but some of the findings would require re-implementation of modules. For instance, the cross-site request forgery problems due to the framework/library used. Thus, our recommendation is to have it set up as early as even if there’s just 1 class/feature being pushed in. The smaller the codebase, the easier the findings can be fixed since there will be fewer code dependencies.
“How often should we run the SAST scan?”
You may choose to run it per commit basis or once daily, depending on how stretched your team is. Our recommendation is to run it once every (bi-) weekly and have the appointed engineer of the week to look through the findings. To have engineers look through the findings every week is important, and the choice of initial few appointed engineers is crucial. With the experiences from the previous peer code reviews, s/he will be able to determine which are the false-positives and the critical flows’ findings to zoom into.
“What should the SAST tool scan?”
Other than the source files, most of the SAST tools also scan for the compiled versions of code, bash scripts, config files, and Dockerfile. You should also scan the test files. Our recommendation is to point the SAST scanner to the root of your repository.
Having a SAST tool helps resolve some peer code review problems such as reducing time and effort to manually look through every single line of code in the codebase(s). Of course, the SAST scan should and can never replace the (manual) peer code review; certain scenarios will still need manual code review such as looking at how the authentication and authorisation are being designed and implemented and whether there’s input validation done (and how they are being validated) anywhere in the server end.
We hope that this article provides some insights to you on how a SAST tool may benefit your project development, especially if you’re in an Agile team.
Lastly, did you notice we mentioned ‘a SAST tool’ instead of “SAST tools” throughout this article? Yes, it is enough to have just 1 SAST tool (don’t kill your dev team by having too many SAST tools 😝).
Team Merlin 💛
Application security is not any individual’s problem but a shared responsibility.
