Introduction to Security in SDLC with SAST for Developers and Security Engineers

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 would like to present advantages and examples of incorporating automated security measures such as Static Application Security Testing (SAST) within the Software Development Life Cycle (SDLC).

SAST is a type of security testing that analyzes source code, byte code, or binary code for security vulnerabilities without requiring the code to be executed.

Reasons to Automate Security in SDLC

To begin with, let’s start with outlining reasons behind automating security in SDLC with SAST:

1. Development can be accelerated by automated security checks implemented at the early development stage
2. Available cost-effective security solutions
3. Security checks can increase business value with minimal effort
4. Teams can be provided with self-service security (shifting-left security)

In the following paragraphs, I’m providing more details behind each reason.

Development can be accelerated by automated security checks implemented at the early development stage

Automated security checks, similar to code quality checks can identify security vulnerabilities at the very early development stage. In this way, developers are able to fix the vulnerability when code is developed or during code review. SAST security tools can be configured in a similar way that linters and code quality checks are implemented. Furthermore, leading SAST solutions allows to ignore false-positive findings to focus only on valid security issues. Moreover, 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!

Available cost-effective security solutions

There are security solutions on the market which are highly expensive, especially for startups and smaller companies. However, there are also 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;
• SonarQube — open-source platform for continuous code inspection, including SAST capabilities;
• CodeQL — SAST solution developed by GitHub, free for open-source and research projects;

There are also various SAST tools specifically designed for certain programming languages, such as Find Security Bugs for Java or bandit for Python.

Security checks can increase business value with minimal effort

Implementing security processes is often viewed as a time-consuming adventure that diverts resources from development. However, the reality is that the integration of certain automated security tools requires minimal effort to increase the security posture significantly. For example, SAST tools can be configured as effortlessly as a linter, making them a low-effort, high-impact addition to any development process. This means that teams can enhance their security measures without detracting from their ability to deliver business value.

Teams can be provided with self-service security (shifting-left security)

Finally, the deployment of security solutions does not always necessitate the involvement of specialized security professionals. Much like configuring a linter, developers can leverage well-documented tools to integrate security into their workflow, empowering them to take ownership of their code’s security. This self-service model fosters a culture of security within the development team, making security a collective responsibility rather than a siloed function.

Implementing SAST 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 to enable SAST solution into your SDLC process.

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 --error

It 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-commit

To 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 install

Now, 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 --config

Improving SAST capabilities by adding 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:

• Toyota Suffered a Data Breach by Accidentally Exposing A Secret Key Publicly On GitHub (gitguardian.com)

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 . -v

More 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: gitleaks

An 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:

• SonarQube
• CodeQL

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!