Every organization which treads security as a top priority needs a Static Application Security Testing (SAST) tool. Run this tool against every software application before you push out new versions to production. It’s very important to use a tool that matches your budget and situation. Besides this, the tool should also work very well for your technology stacks. But there are more considerations to take into account. In this article you will find more about SAST tool selection – tips to pick the right one for you.
A short note on SAST
In short, a SAST tool analyses your static source code in one of the earliest stages of the Software Development Life-cycle. It analyses sourced code, (third party) binaries, and other scripts for security issues and vulnerabilities. Besides detecting the before-mentioned objects, it also provides advice on how to remediate the findings. The criteria to choose the best tool are very diverse. Since there are so many things to consider, it’s important to pay careful attention to all of them.
Commercial or closed source
One of the first decisions you need to take is to think about the licensing model. If your organization requires full openness and self-control you might choose an open source-based tool. This gives you the needed insights into how exactly the tool works and what and how it scans your source code. If you host the tool yourself, you can also control how and where the data goes. With a commercial, SaaS-based tool, you don’t know much about how it operates and what happens with your data. Consider you scan your critical applications and the results reveal a high number of critical vulnerabilities, would you be so happy if these are stored beyond your control?
Costs
A commercial tool costs money. Licensing models vary per tool. Sometimes you need to pay based on the number of lines of your source code. And sometimes you pay per user, which can include nonpersonal accounts and personal accounts. Before you jump to conclusions stating that an open-source tool is much cheaper, you need to create a business case. In this document, you would at least outline the licensing costs based on the current and potential future scenarios. In addition to that, estimate how much resources you need to figure things out yourself when it comes to open-source tools and which level of support you require. Sometimes, open-source tools are backed by commercial vendors which provide professional support. Another factor to take into account is to estimate the costs of delayed implementation. Furthermore, try to estimate how much time and effort it would cost to operate the tool on a daily basis. Careful comparison of multiple tools can reveal very different results.
Shift left as much as you can
It’s crucial for a SAST tool to work as closely to the origin of source code as possible. In practice, this means your SAST tool should be integrated into the IDE of the developer. This is the first and most effective place to discover any security issue. Since the source code is not committed to the Git repository yet, valuable time is saved. Not only from a local perspective but also from a CI/CD pipeline’s perspective. There is no need to run a pipeline, eat away resources and add up the build queue if you could already detect a critical vulnerability in a third-party library. You win a lot of time if you fix it on the spot. Besides this, not committing insecure source code saves you from reverting in (also from history) and keeps your code base clean.
Scan your repositories
You also require a tool to scan your existing repositories. Since software might have been packaged and stored well before you have chosen your SAST tool it’s wise to have your SAST tool scan the entire repository. After the first scan, be sure to constantly monitor your repositories since you also want to filter out any issues which might have slipped through. A developer might skip a security step in the pipeline or overwrite a package in the repository.
Role of CI/CD pipelines
Intelligent feedback is important to give the right advice to teams. Sometimes your CI/CD pipeline should break when it encounters critical issues. A warning can be sufficient to notify a developer of a medium-level risk. But what if a security scan fails? Should you then break the CI/CD pipeline or continue? Careful feedback (for example by utilizing the exit code of your scanning command) is important so everyone can interpret it correctly and take the necessary action.
When integrating the security tool in the (standard) CI/CD pipelines also help to reduce the likelihood of an insider building back-doors in. The risks for these nasty and damaging security issues decrease if scanning is enforced and if only nonpersonal accounts are used which are also heavily audited.
Speed matters
Speed is a killer feature. Caching of scanning results (based on binary identical dependencies?) can also help here. You can’t take this lightly. If a SAST tool produces slow results every time you scan your (local) changes and the third-party dependencies, you would lose a lot of money. The loss increases once your teams move faster and frequent code commits trigger another scanning cycle.
Slow scanning also poses a bigger risk in terms of reduced attention to security issues. Developers will seek bypasses to meet their deadlines, security gurus will vote against the solution and a new tool battle can emerge. Without putting enough weight on the speed aspect even the most efficient working enterprises slow down.
Suppose you do want to run the SAST tool in the CI/CD pipeline, you need to be able to run multiple tests in parallel. No one wants to wait for scans to take long, everyone wants fast feedback to continue the development work. So the SAST tool needs to be able to execute multiple threads at once and feedback the results quickly and without data corruption (prevent overwritten scan results).
Since speed is important for scanning in the build phase, also consider speed as an important factor when it comes to scanning an artifact repository. The initial scan might take long, but subsequent scans must be fast. Cached scanning results should not yield false results. The SAST tool should scan every new and changed artifact again and present updated results.
Rules and false positives
SAST rules determine the outcome of scanning results. It is very important that the rules are created by someone who understands security-related aspects very well. Furthermore, access to create and update the rules should be bound to specific roles. Use RBAC as much as possible and apply the least privilege principle. It’s really important that developers or anyone else cannot change or disable the rules. It would yield to insecure code. Don’t suppress warnings and other errors. They are an indication something goes wrong.
Compliance
Every SAST tool provider should at least conform to SOC2 compliance. If you use a SaaS-based solution, make sure your source code and/or security-related data will be uploaded to the location of tour preference. In European countries, that sometimes means your data has to stay in the country where your organization is registered. Furthermore, remember the GDPR which also plays a role here. Don’t scan applications that hold sensitive privacy-related information about actual customers. What if the SaaS provider is hacked and your results are in the open?
False positives and how to detect them
False positives are a true plague for every security-minded team. Judging a false positive eats away precious time to examine and it also results to alert fatigue. Besides this, it also drags away the attention to true security issues which are indeed valid.
One of the only ways to detect false positives is to use a sample application of which you exactly know where the false positives are. And on top of it, scan the sample application by multiple tools. Compare the results and filter out the false positives of the SAST tool of your choice. This helps to judge how well the tool performs and to set up the rules and policies later on. Be sure to create a knowledge base of common false positives and communicate this to the DevOps teams. Only doing so helps to increase the collective knowledge.
Help the developers
A good SAST tool eases out the learning path for developers as much as possible. When security risks are displayed to developers, they should provide suggestion on code fixes, library updates (best with a compatibility check in it), guide developers to additional resources which provide deeper knowledge and let them connect with security communities to seek for help. One option I really like is what Sonatype Nexus Lifecycle offers: a timeline of versions of every third-party dependency that is scanned. You can see exactly which version has problems and which version is secure. This can be seen in respect to the version of the dependency you are using so you get a wider view of the context.
Besides the information in the tool itself, a SAST tool should also integrate with other tools. Not only from a permissions perspective (for example to connect to Active Directory) but to support the internal processes as well.
Suppose your development team requires the view of a security expert elsewhere in the organization. It would be very time-consuming to (manually) contact that expert and explain the details. A better option would be to establish a webhook with a tool like Jira to automatically create a ticket (or “ping” the security expert in the existing ticket). This way, collaboration on a higher level and an automated way is possible. A truly IT-driven mindset when it comes to tackling security issues.
Every security-related process in every stage of the SDLC needs to be monitored and audited. Therefore it is vital to have the SAST tool integrate with modern SIEM-related tools. Traceability is king here also in terms of external audits.
Existing SAST tools
At this time of writing, there are a large number of SAST tools on the market. A shortlist here to help you start your evaluation:
- SonarQube: one of the most well-known tools to scan source code with an open source version as well.
- Checkmarx: a commercial tool that gains popularity for its scanning results.
- HP Fortify: a very well-known tool that has great support for the Java programming language.
- Veracode: another tool that scans a high variety of languages and source code.
- Gitlab: since version 13.0, Gitlab boosts security to a higher standard. Closely integrated with your source code Git repositories.
- Snyk: one of the newcomers which really pushed the market to higher standards.
Conclusion
This article gave an overview of the key selection criteria of SAST tools. There are many aspects to take into account before you can select the best tool that fits your purpose. Not every aspect has the same weight. However, carefully consider the pros and cons of every tool which makes it to your shortlist. Security is not an afterthought anymore but an absolute necessity. I hope this inspired you to make your life a bit easier.
