Why Not To Automate Security in SDLC with SAST?
A refreshed version of this article is available at my personal blog:
In today’s landscape, automation plays a crucial role in various development activities, ranging from ensuring code quality and performing unit testing to managing deployments. I often find myself pondering why security has not yet become an automated process in numerous companies. This might be particularly noticeable in smaller businesses and among individual developers. In this post, I aim to delve into the reasons behind this and highlight the advantages of incorporating automated security measures within the Software Development Life Cycle (SDLC).
Why not to automate security in SDLC?
To begin with, let’s delve into the reasons why security tools haven’t gained as much widespread adoption as code quality tools. Drawing from my personal insights and discussions with various developers, I’d like to outline the following concerns:
- Security solutions could potentially slow down the pace of development processes;
- Security solutions are expensive;
- Implementing security processes requires time which could be spent on development, generating greater business value
- Automated security measures might yield a substantial number of false positives;
- The deployment of security solutions often necessitates the involvement of experienced security professionals.
I’m sure you’ve encountered at least one of these issues at some point. ;)
However, I’m determined to counter these arguments and demonstrate that integrating a straightforward automated security process into your environment might be far less daunting than you anticipate!
Security solutions could potentially slow down the pace of development processes
In fact, similarly to code quality checks security tools need an extra effort from developers to adjust the code based on their output. It’s true. However, there are many tools that can be easily configured to raise only findings with a high confidence. That will let you ignore issues that are not relevant but still will increase the security posture of your projects. Furthermore, more and more tools offer auto-fixing for the identified issues which will speed up vulnerability fixing.
Last but not least, identifying security vulnerabilities at an early development stage might be much cheaper than identifying them during penetration testing peformed by external company or worse… by threat actors!
Security solutions are expensive
Yes, there are tools on the market which are highly expensive, especially for startups and smaller companies. On the other hand, there are a number of open source solutions that can help in reducing the costs or costs being adjusted to smaller teams:
- Semgrep — Static Application Security Testing (SAST) tool with free and commercial license available;
- OWASP ZAP — open source Dynamic Application Security Testing (DAST) tool;
- OWASP Dependency-Check — open source Software Composition Analysis (SCA) tool that detects publicly disclosed vulnerabilities contained within a project’s dependencies;
- Checkov — provides ability to scan Infrastructure as a Code with free and commercial license.
Implementing security processes requires time which could be spent on development, generating greater business value
It’s true that implementation of an effective security processes takes time. Especially, implementing an advanced SSDLC process with vulnerability management might be challenging for small teams. However, still it’s possible to increase the security posture by implementing some of the tools with a very low amount of effort which will not affect development negatively. Particularly, SAST tools can be implemented in a similar way that your favourite linter is configured!
Automated security measures might yield a substantial number of false positives
It's also true when the tool is not properly configured for your needs. However, simultaneously, the level of effort required to customize the tool isn’t as extensive as you might anticipate. I will demonstrate this in the upcoming sections.
The deployment of security solutions often necessitates the involvement of experienced security professionals
If you’re an experienced developer who can adeptly configure your favorite linter using well-written documentation, you’ll be equally capable of doing the same with SAST!
Let’s implement simple security automation in SDLC!
As you were able to get to this part of the article, it means that you are interested how exactly it can be achieved. And I'm more than happy to show you the way how to enable your first security tool. :)
The first solution that is worth implementing to increase the security posture of your projects in my opinion is a Static Application Security Testing. It scans the code to identify potential vulnerabilities. It can be placed in various places such as CI/CD or local developer machine where you test for code quality. As an example tool I will take my personal favourite SAST tool — Semgrep. Semgrep is a fast, open source static analysis tool for finding bugs and enforcing code standards. It supports Python, Java, C#, C, C++, JavaScript, Ruby and many other languages. In a free version Semgrep uses public rules registry. Furthermore, it’s possible to create your own custom rules.
Semgrep can be installed with Python pip in the following way:
pip3 install semgrep
# if you're installing tools with pip on Ubuntu/Debian they might be installed
# in ~/.local/bin and you may need to set PATH env variable properly via:
# export PATH="$HOME/.local/bin:$PATH"Other installation alternatives are covered in the documentation. Semgrep can be easily used to scan your code with the command shown below:
semgrep --config "p/security-audit" --metrics off --errorIt will scan the code locally without sending any code or metrics to external third party services. The command returns non zero exit code when there are high severity issues. Issues identified by rules marked as INFO or WARNING will result in 0 exit code. This behaviour can be used to block CI/CD jobs if any highly severe issue is identified. In the example p/security-audit ruleset was used but it’s possible to use other publicly available rulesets.
Now, let’s take a look at three different quick approaches that could be used to implement such security testing effectively in SDLC process.
Semgrep plugin in your favourite IDE
This is a developer-side approach that will allow developers to identify security issues at the stage of writing the code which may save a lot of time comparing to other methods.
Semgrep has several official and community-contributed plugins. As I’m personally using Visual Studio Code, I will use this IDE as an example. The plugin can be installed from official VS Code marketplace. It can be easily configured with chosen set of rules by entering Semgrep settings as presented below:
Furthermore, plugin allows to auto-fix vulnerabilities at the time of writing the code. The screenshot shown below presents how such fix can be applied:
Pre-commit hooks approach
For developer-side checks pre-commit hook can also be used. It’s a framework for managing and maintaining multi-language pre-commit hooks. It can be installed with Python via:
pip3 install pre-commitTo configure Semgrep the following YAML file named .pre-commit-config.yaml should be placed inside the git repository:
repos:
- repo: https://github.com/returntocorp/semgrep
rev: 'v1.36.0'
hooks:
- id: semgrep
args: ['--config', 'p/security-audit', '--metrics', 'off', '--error']and applied with the following command:
pre-commit installNow, every time a git commit command is run Semgrep will perform a security scan locally.
I configured the pre-commit using the Vulnerable Flask App as a testing repository. Next, I made a minor change in the vulnerable file and ran git commit to validate my configuration. After a few seconds, an output with 7 findings was presented to me, one of which was associated with potential Remote Code Execution (RCE) vulnerability!
Placing SAST inside CI/CD
The most recommended approach would be to place SAST solution inside CI/CD where you may already have placed unit testing or code quality checks. In this way, any code with identified security vulnerabilities will be blocked from merging to the main branch or from being deployed to the hosting environment.
Placing Semgrep SAST inside CI/CD job is as simple as placing a step with the following CLI calls:
python3 -m pip install semgrep
semgrep scan --metrics off --configNow, improve it with secret scanning!
Another great SAST tool is Gitleaks which is dedicated for secret scanning and can be also easily added as a companion for Semgrep. Gitleaks provides two operation modes:
gitleak detect— detects secrets already tracked in git, recommended for CI/CD environments;gitleak protect— detects secrets not yet tracked in git, useful for local checks before commiting the code.
Secret scanning will prevent from leaking hardcoded credentials within the repositories by detecting them before commiting the code or deploying to the hosting environment. Storing secrets in repositories is often underestimated vulnerability as organisations keep their repositories private which lowers the risk of exposing them. However, there are many cases where secrets leaked through repository code such as this one:
Using Gitleaks is also rather easy as the only commands that you need to install and run it are presented below:
wget -qO- https://github.com/gitleaks/gitleaks/releases/download/v8.18.0/gitleaks_8.18.0_linux_x64.tar.gz | tar xvz
# the above commands pulls binary for Linux amd64 architecture
chmod +x gitleaks
gitleaks detect . -vMore installation and running options are presented in Gitleaks documentation on GitHub.
Gitleaks also has pre-commit hook which is fairly easy to implement by adding following lines to previously created .pre-commit-config.yaml config:
- repo: https://github.com/gitleaks/gitleaks
rev: v8.16.1
hooks:
- id: gitleaksAn example output from Gitleaks checks performed while commiting changes is presented below. In the presented example it detects hardcoded AWS access key:
Summary
In this rather short article I was able to present that it’s possible to start security testing in SDLC fairly easy:
- without slowing down your development process drastically;
- without spending single penny on expensive tooling;
- in a short amount of time spent on implementation;
- without any need for having advanced cyber security skills;
- with rather low false positive rate;
Remember, that your chosen tools don’t have to be the same as presented here. There is a number of other valuable tools for SAST such as:
and tools dedicated for secret scanning:
- TruffleHog — provides ability to validate secrets via dynamic API calls
- GitGuardian ggshield
- GitHound
- detect-secrets
Each of this tool will have its own strengths and their usage will depend on your codebase, environment and chosen approach. In next articles I would like to present other open source tools that can be implemented in early stage of SDLC to increase the security posture of your projects. Let me know in comments if you’re interested about any specific tool that I could present!
If you’re looking for more Application Security, DevSecOps and related technical articles, just let me know what type of content you’re interested in and Follow me to get notified about new articles as soon as they’re released! 🚀🚀🚀
You can also visit my LinkedIn or Twitter profiles, if you’re keen on speaking about technical stuff! 💬
