Reputation: 6029
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?
Upvotes: 8
Views: 8131
Reputation: 1325387
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
ortest/**/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’ existingsemgrepignore
comments.See the
semgrep
CHANGELOG andsast-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.
Upvotes: 2
Reputation: 116
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
Upvotes: 10