Skip to main content

Static Application Security Testing (SAST) & Software Composition Analysis (SCA)

Static Application Security Testing (SAST) is a type of security testing that is used to identify vulnerabilities in the source code of an application. It is a white-box testing method that is used to identify security vulnerabilities in the source code of an application. SAST tools scan the source code of an application to identify security vulnerabilities such as SQL injection, cross-site scripting, buffer overflows, and other security vulnerabilities.

We currently use the following SAST tooling Github CodeQL as well as various linting tools to ensure code quality and security. These are in both pre-commit hooks in our github repositories as well as in our CI/CD pipelines.

Guidelines when dealing with SAST results:

  • Critical & High severity vulnerabilities should be triaged and addressed immediately
  • Addressing a alert involves reading the alert and understanding the impact of the vulnerability, and if we are affected by it
  • If we are affected by the vulnerability, we should fix the vulnerability in the code
  • If we are not affected by the vulnerability, we should document why we are not affected by the vulnerability, and close the issue Software Composition Analysis (SCA) is a type of security testing that is used to identify vulnerabilities in the open source components used in an application. SCA tools scan the open source components used in an application to identify security vulnerabilities such as known vulnerabilities, license compliance issues, and other security vulnerabilities.

We are currently doing this in two places, using dependabot to automatically update dependencies in our github repositories, and using Grype in our CI/CD pipelines to scan for vulnerabilities in our docker images and application SBOMs (go.mod, yarn.lock etc). This ensures that we are continuously scanning for vulnerabilities in our dependencies and open source components.

Guidelines when dealing with SCA results:

  • Critical & High severity vulnerabilities should be triaged and addressed immediately
  • Addressing a vulnerability involves reading the CVE and understanding the impact of the vulnerability, and if we are affected by it
  • If we are affected by the vulnerability, we should upgrade the dependency to a version that is not affected by the vulnerability
  • If we are not affected by the vulnerability, we should document why we are not affected by the vulnerability, and close the issue
  • If we cannot upgrade the dependency, we should document why we cannot upgrade the dependency and work towards a solution to upgrade the dependency at a later date
  • We should aim to have no critical or high severity vulnerabilities in our applications

Examples of a SCA report from grype and ignore reasons can be found:

NAME           INSTALLED  FIXED-IN                      TYPE       VULNERABILITY        SEVERITY     
axios          0.21.4     1.8.2                         npm        GHSA-jr5f-v2jv-69x6  High      
cross-spawn    4.0.2      6.0.6                         npm        GHSA-3xgq-45jj-v275  High      
jsonpath-plus  10.2.0     10.3.0                        npm        GHSA-hw8r-x6gr-5gjp  High      
rexml          3.2.5      3.3.6                         gem        GHSA-vmwr-mc7x-5vc3  High

A .grype.yaml file with ignore rules may look like this:

ignore:
- vulnerability: GHSA-vmwr-mc7x-5vc3
  notes: this is a DoS vulnerability as part of the native build process. we control the input so this is not an issue.
  package:
    name: rexml
    version: 3.2.5 
- vulnerability: GHSA-hw8r-x6gr-5gjp
  notes: this is part of the api-client package and is only executed at build time to generate api libs. We control the input, so this isn't an issue.
  package:
    name: jsonpath-plus
    version: 10.2.0
- vulnerability: GHSA-3xgq-45jj-v275
  notes: Regular Expression Denial of Service, this is a frontend app, not a big deal.
  package:
    name: cross-spawn
    version: 4.0.2

Sometimes you control the input or the code path that the vulnerable code is executed in is not part if your application functionality, and thus you can be confident that the vulnerability cannot be exploited. In this case, you can ignore the alert and document why you are ignoring it. You should always be confident that the vulnerability cannot be exploited before ignoring it.

When writing a grype ignore rule, you also need to do the same in dependabot currently.