Why is GitLab CI SAST not exluding directories that I ask it to exclude?

Question

I have enabled SAST scanning in GitLab CI (GitLab Community Edition) 14.5.2. The SAST runs tools like semgrep and ESLint run over the source code and scan for vulnerabilities. This works... except it's not excluding paths and files from the results that I tell it to so my reports are filled with junk from 3rd party libs.

Since I don't want test code or 3rd party stuff in the report I use the GitLab provided variable for this purpose called SAST_EXCLUDED_PATHS that I use to exclude some dirs. My value is like this:

    variables:
        SAST_EXCLUDED_PATHS: spec, test, tests, tmp, server/libs, assets, vendor, *.min.js

So basically in addition to the default paths I've told it not to scan server/libs, assets, vendor or *.min.js.

So the simplified .gitlab-ci.yml that adds the step, adds the exclusions and also sets SECURE_LOG_LEVEL to "debug". The latter so I can see the debug output of stages such as sast-semgrep.

include:
    - template: Security/SAST.gitlab-ci.yml

stages:
    - test

# Run a SAST scan & report on the sources
sast:
    stage: test
    variables:
        SAST_EXCLUDED_PATHS: spec, test, tests, tmp, server/libs, assets, vendor, *.min.js
        SECURE_LOG_LEVEL: "debug"

I can see from the debug that sast-semgrep is taking my exclusions and turning them into --exclude arguments. But it just scans the paths anyway. I have even tried appending glob rules onto the paths, e.g. "server/libs/**". I have even tried using absolute paths e.g. "$CI_PROJECT_DIR/server/libs" but that doesn't work either.

I have enabled debug console output and I can even see tools like semgrep are correctly expanding out the exclusions. But it doesn't work! This example includes a $CI_PROJECT_DIR expansion that doesn't make any difference.

[DEBU] [Semgrep] [2022-01-26T20:59:40Z] ▶ /usr/local/bin/semgrep -f /rules -o /builds/myprj/myprj/semgrep.sarif --sarif --no-rewrite-rule-ids --strict --disable-version-check --no-git-ignore --exclude spec --exclude  test --exclude  tests --exclude  tmp --exclude  "/builds/myprj/myprj/server/libs" --exclude  assets --exclude  vendor --exclude  *.min.js --enable-metrics /builds/myprj/myprj
[DEBU] [Semgrep] [2022-01-26T21:01:34Z] ▶ METRICS: Using configs from the Registry (like --config=p/ci) reports pseudonymous rule metrics to semgrep.dev.
To disable Registry rule metrics, use "--metrics=off".
Using configs only from local files (like --config=xyz.yml) does not enable metrics.
More information: https://semgrep.dev/docs/metrics
excluding files:
- spec
-  test
-  tests
-  tmp
-  "/builds/myprj/myprj/server/libs"
-  assets
-  vendor
-  *.min.js

As far as I can tell I'm using the latest GitLab and docker images that Gitlab invokes. Does anyone know why exclusion isn't working? Am I missing something obvious. FYI I have also tried the same CI/CD script in GitLab Ultimate evaluation copy and its the same deal. So it's not to do with the less powerful SAST functionality in the Community Edition which should still produce a JSON report. Any ideas?

Derwood

Answer 1

Hope I'm not too late. I've encountered the same problem and what resolved it for me was to delete the space between the excluded paths. Your SAST_EXCLUDED_PATHS variable should look like this:

  variables:
        SAST_EXCLUDED_PATHS: spec,test,tests,tmp,server/libs,assets,vendor,*.min.js

Unwieldy

I think this is probably it! I'm waiting for our devops to enable an image but I suspect it just wasn't trimming paths the way I expected. – Derwood

@Derwood are you still experiencing this issue? I'm investigating gitlab.com/gitlab-org/gitlab/-/issues/332187 and can't seem to replicate the bug with your configuration. Semgrep appears to ignore paths correctly, even with leading whitespace. – Theosophy

Okay I was able to replicate this issue -- looks like Semgrep ignores exclusion patterns with leading whitespace, but the analyser wrapper will retroactively remove matched vulns from the report (not ideal for performance). I've opened an MR here to address this: gitlab.com/gitlab-org/security-products/analyzers/semgrep/-/… – Theosophy

Answer 2

The merge request 123 ("Trim whitespace from excluded paths") reported by disposedtrolley in the comments has been merged in GitLab 15.2 (July 2022)

Plus, GitLab 15.3 (August 2022) comes with:

Exclude paths from Secure scanning with double-star globs

We’ve improved the way you can ignore paths in GitLab Secure scanners. Ignoring paths can help you focus on the right findings by ignoring test files, example code, or other code you don’t want to scan.

You can now use double-star glob patterns like **/*_test.go or test/**/fixture* to exclude paths in:

• Dependency Scanning, by using the DS_EXCLUDED_PATHS variable.
• SAST, by using the SAST_EXCLUDED_PATHS variable.
• Secret Detection, by using the SECRET_DETECTION_EXCLUDED_PATHS CI/CD variable.

See Documentation and Issue.

---

To be noted, withGitLab 15.10 (March 2023):

Automatically resolve SAST findings when rules are disabled

GitLab SAST now automatically resolves vulnerabilities from the Semgrep- and KICS-based analyzers when either:

• You disable a predefined rule.
• We remove a rule from the default ruleset.

This change helps you focus on the vulnerabilities that are still relevant after the rule update.

Previously, when a rule was no longer scanned, its findings would be marked “No longer detected” but you still had to take action to resolve them. Now, the Vulnerability Management system automatically resolves those findings and leaves a comment explaining that the rule was removed, so you still have a historical record of the vulnerability.

This change will automatically resolve findings from a small number of rules that we’ve replaced or removed in recent releases. In this release, we’ve also removed a JavaScript SAST rule that created too many false-positive results.

This feature is enabled by default on GitLab.com and in GitLab 15.10.

• On GitLab.com, contact Support if you need to disable the flag for your project.
• On GitLab self-managed, you can disable the project-level feature flag named sec_mark_dropped_findings_as_resolved.

See Documentation and Issue.

---

GitLab 16.2 (July 2023) also improve semgrep:

SAST analyzer updates

GitLab SAST includes many security analyzers that the GitLab Static Analysis team actively maintains, updates, and supports.

During the 16.2 release milestone, our changes focused on the Semgrep-based analyzer and the GitLab-maintained rules it uses for scanning. We released the following changes:

• Clarified the explanation and guidance for JavaScript rules, building on improvements for other languages released in GitLab 16.1
• Updated rules to find additional vulnerabilities in Java and JavaScript.
• Changed the default configuration for which files are ignored in scans by:
  • Removing .gitignore exclusion. Thanks to @SimonGurney for this community contribution.
  • Respecting locally-defined .semgrepignore files. Thanks to @hmrc.colinameigh for this community contribution.
• Improved a rule related to Go memory aliasing. Thanks to @tyage for this community contribution.
• Removed a -1 suffix added to the Semgrep rule IDs for JavaScript rules. This was added in GitLab 16.0 as a side-effect of an unrelated change, but interfered with customers’ existing semgrepignore comments.

See the semgrep CHANGELOG and sast-rules CHANGELOG for further details. We’re tracking further improvements to GitLab-managed rulesets in epic 10907.

If you include the GitLab-managed SAST template (SAST.gitlab-ci.yml) and run GitLab 16.0 or higher, you automatically receive these updates. To remain on a specific version of any analyzer and prevent automatic updates, you can pin its version.

For previous changes, see last month’s updates.

See Documentation and Issue.

Eight