Skip to content

Re-enable semgrep-sast for Golang SAST scanning

Greg Myers requested to merge reenable-semgrep-for-golang-sast-scanning into master

What is the problem?

SAST scans of Golang code are not currently running on the gitaly codebase.

Technically one sast job is currently running in gitaly pipelines - bandit-sast, which scans Ruby on Rails code. However gitaly is 99%+ Golang, and only ~0.1% Ruby, which means our SAST scanners are not analyzing any of the Go code that actually comprises the entire gitaly codebase.

This is the result of a custom rules: override: https://gitlab.com/gitlab-org/gitaly/-/blob/master/.gitlab-ci.yml?ref_type=heads#L448-455

semgrep-sast:
  needs: []
  stage: analyze
  cache:
    - *cache_go_configuration
  rules:
    - if: $SAST_DISABLED
      when: never

The use of this custom rules: block here overrides and ignores all default rules:, which are used to determine when the semgrep-sast job executes. In the current configuraiton, semgrep-sast (the SAST scanner which analyzes Go code) will never execute because there are no rules: conditions to actually trigger this sast job.

The default semgrep-sast CI job rules: are:

  rules:
    - if: $SAST_DISABLED == 'true' || $SAST_DISABLED == '1'
      when: never
    - if: $SAST_EXCLUDED_ANALYZERS =~ /semgrep/
      when: never
    - if: $CI_COMMIT_BRANCH
      exists:
        - '**/*.py'
        - '**/*.js'
        - '**/*.jsx'
        - '**/*.ts'
        - '**/*.tsx'
        - '**/*.c'
        - '**/*.go'
        - '**/*.java'
        - '**/*.cs'
        - '**/*.html'
        - '**/*.scala'
        - '**/*.sc'
        - '**/*.php'

As the if: exists: - '**/*.go" rule has been overridden by a custom rules: block (which does not cascade, or add to/build upon these defaults), the semgrep-sast job is never being triggered.

As a result, the last SAST results for the gitlab-org/gitaly codebase are from the last successful execution of the semgrep-sast job in a pipeline on 2023-07-26 https://gitlab.com/gitlab-org/gitaly/-/jobs/4747743177, at a time when the custom rules: for this job were set up to always trigger the semgrep-sast job.

The line of code that successfully triggered the semgrep-sast job to perform SAST scanning on the Golang code was removed here: gitlab-org/gitaly!6135 (diffs)

Why is this a problem?

Without SAST scans running on the go code, we will not be made aware of or alerted about potential newly introduced vulnerabilities in the code base. This also blocks our ability to configure merge request approval policies that would benefit from additional security review for any newly detected and newly introduced potential vulnerabilities.

As AppSec is expected to review, validate, and triage vulnerabilities, the lack of insight into potential vulnerabilities detected by SAST scanning is impacting our ability to perform this job duty.

What does this MR do?

This MR removes the rules: block override which is preventing the semgrep-sast job from being triggered. Without the custom rules: block, CI pipelines will use the default semgrep-sast CI job rules:, allowing SAST scans to be run against the go code as we previously were doing.

Edited by Greg Myers

Merge request reports