Gosec-sast job failing for no reason

, ,

gosec-sast fails with exit code 2 without providing any reason for the failure.

This is probably more of a bug report, although I could not find anywhere to report it on security-products · GitLab.

This is running on gitlab.com on a standard docker runner provided by the free plan.

I expect it to not fail or at least to inform the reason for the failure so I can address it.

Here the relevant snippets from .gitlab-ci.yml (the entire file can be found at https://gitlab.com/lightmeter/controlcenter/-/blob/feature/parse_postfix_logs_with_ragel/.gitlab-ci.yml):

include:
  - template: Dependency-Scanning.gitlab-ci.yml
  - template: License-Scanning.gitlab-ci.yml
  - template: SAST.gitlab-ci.yml
  - template: Code-Quality.gitlab-ci.yml

variables:
  SAST_DEFAULT_ANALYZERS: "gosec,secrets"
  GO111MODULE: "on"

...

.on-non-tag:
  rules:
    - if: '$CI_MERGE_REQUEST_EVENT_TYPE == "detached"'
      when: never
    - if: '$CI_COMMIT_TAG == null'
      when: always
    - if: '$CI_MERGE_REQUEST_EVENT_TYPE != null && $CI_MERGE_REQUEST_EVENT_TYPE != "detached"'
      when: always

sast:
  extends: .on-non-tag
  stage: test
  needs: []
  artifacts:
    paths:
      - gl-sast-report.json
    expire_in: 7 days

The issue is reproducible and this is an example of job with the failure.

Running with gitlab-runner 13.6.0-rc1 (d83ac56c)
  on docker-auto-scale fa6cab46
Resolving secrets
00:00
Preparing the "docker+machine" executor
00:20
Using Docker executor with image registry.gitlab.com/gitlab-org/security-products/analyzers/gosec:2 ...
Authenticating with credentials from job payload (GitLab Registry)
Pulling docker image registry.gitlab.com/gitlab-org/security-products/analyzers/gosec:2 ...
Using docker image sha256:ed2c56ca2451e56dabeadfd40130cec861d85963d6f9dabbf0b8f0880f4a27d3 for registry.gitlab.com/gitlab-org/security-products/analyzers/gosec:2 with digest registry.gitlab.com/gitlab-org/security-products/analyzers/gosec@sha256:378fa157f4e586755ddfc609c2ad4e751a304ed37102e7677bc484bc2b2a55f9 ...
Preparing environment
00:03
Running on runner-fa6cab46-project-17017123-concurrent-0 via runner-fa6cab46-srm-1605710353-a61314a1...
Getting source from Git repository
00:04
$ eval "$CI_PRE_CLONE_SCRIPT"
Fetching changes with git depth set to 50...
Initialized empty Git repository in /builds/lightmeter/controlcenter/.git/
Created fresh repository.
Checking out b4d8246a as feature/parse_postfix_logs_with_ragel...
Skipping Git submodules setup
Executing "step_script" stage of the job script
01:07
$ /analyzer run
[INFO] [Gosec] [2020-11-18T14:40:27Z] ▶ GitLab Gosec analyzer v2.13.2
[INFO] [Gosec] [2020-11-18T14:40:27Z] ▶ Detecting project
[INFO] [Gosec] [2020-11-18T14:40:27Z] ▶ Found project in /builds/lightmeter/controlcenter
[INFO] [Gosec] [2020-11-18T14:40:27Z] ▶ Running analyzer
[INFO] [Gosec] [2020-11-18T14:40:27Z] ▶ Copying modules into path...
[INFO] [Gosec] [2020-11-18T14:40:27Z] ▶ Fetching dependencies...
exit status 2
Uploading artifacts for failed job
00:01
Uploading artifacts...
WARNING: gl-sast-report.json: no matching files    
ERROR: No files to upload                          
Cleaning up file based variables
00:00
ERROR: Job failed: exit code 2

In this project, gosec-sast has been running well on master, but a new branch, which does not change any gosec related configuration, introduces the issue, although I haven’t been able to track it.

This is an example of this job being executed without error (latest job on master):

Running with gitlab-runner 13.6.0-rc1 (d83ac56c)
  on docker-auto-scale ed2dce3a
Resolving secrets
00:00
Preparing the "docker+machine" executor
00:17
Using Docker executor with image registry.gitlab.com/gitlab-org/security-products/analyzers/gosec:2 ...
Authenticating with credentials from job payload (GitLab Registry)
Pulling docker image registry.gitlab.com/gitlab-org/security-products/analyzers/gosec:2 ...
Using docker image sha256:ed2c56ca2451e56dabeadfd40130cec861d85963d6f9dabbf0b8f0880f4a27d3 for registry.gitlab.com/gitlab-org/security-products/analyzers/gosec:2 with digest registry.gitlab.com/gitlab-org/security-products/analyzers/gosec@sha256:378fa157f4e586755ddfc609c2ad4e751a304ed37102e7677bc484bc2b2a55f9 ...
Preparing environment
00:03
Running on runner-ed2dce3a-project-17017123-concurrent-0 via runner-ed2dce3a-srm-1605707859-6ffede92...
Getting source from Git repository
00:03
$ eval "$CI_PRE_CLONE_SCRIPT"
Fetching changes with git depth set to 50...
Initialized empty Git repository in /builds/lightmeter/controlcenter/.git/
Created fresh repository.
Checking out 224a120c as master...
Skipping Git submodules setup
Executing "step_script" stage of the job script
02:32
$ /analyzer run
[INFO] [Gosec] [2020-11-18T14:00:58Z] ▶ GitLab Gosec analyzer v2.13.2
[INFO] [Gosec] [2020-11-18T14:00:58Z] ▶ Detecting project
[INFO] [Gosec] [2020-11-18T14:00:58Z] ▶ Found project in /builds/lightmeter/controlcenter
[INFO] [Gosec] [2020-11-18T14:00:58Z] ▶ Running analyzer
[INFO] [Gosec] [2020-11-18T14:00:58Z] ▶ Copying modules into path...
[INFO] [Gosec] [2020-11-18T14:00:58Z] ▶ Fetching dependencies...
[INFO] [Gosec] [2020-11-18T14:02:09Z] ▶ Running gosec...
[INFO] [Gosec] [2020-11-18T14:03:28Z] ▶ Creating report
Uploading artifacts for successful job
00:02
Uploading artifacts...
gl-sast-report.json: found 1 matching files and directories 
Uploading artifacts as "archive" to coordinator... ok  id=857617179 responseStatus=201 Created token=2rwSkB_k
Uploading artifacts...
gl-sast-report.json: found 1 matching files and directories 
Uploading artifacts as "sast" to coordinator... ok  id=857617179 responseStatus=201 Created token=2rwSkB_k
Cleaning up file based variables
00:01
Job succeeded

Does anyone know how to fix or workaround this issue?

Thank you in advance.

Answering myself:

The issue was caused because the project repository was not “go-getable”. There is some source code generation at build time, and on debugging analyse.go (from gosec-sast), it calls go get ./..., as below:


	// Gosec needs the dependency to be fetched.
	log.Info("Fetching dependencies...")
	cmd = setupCmd(exec.Command("go", "get", "./..."))

Which fails as some code is missing, making go get fail.

Such project does has all its dependencies in the vendor directory, making fetching dependencies unnecessary.

I fixed it by committing the generated code to the repository, making it “go-getable”, although I really dislike the idea of committing machine generated code to a repository…