Gemnasium-maven-dependency_scanning fails because of a probable bug in GitLab

How to Use GitLab
,
1

I think I found a bug in GitLab. Here’s repro steps:

  1. Create a new blank project in GitLab with all the default settings, but please check the “Enable SAST” checkbox.

  2. Add files from this project there: GitHub - timtebeek/topology-test-driver-avro

Expected: SAST tests pass.

Actual: gemnasium-maven-dependency_scanning fails. Full job log is at the end.

Versions

Please add an x whether options apply, and add the version information.

  • Self-managed
  • GitLab.com SaaS
  • Dedicated

Versions

Full job log:

Running with gitlab-runner 17.7.0~pre.103.g896916a8 (896916a8)
  on green-1.saas-linux-small-amd64.runners-manager.gitlab.com/default JLgUopmM, system ID: s_deaa2ca09de7
Resolving secrets
Preparing the "docker+machine" executor
00:40
Using Docker executor with image registry.gitlab.com/security-products/gemnasium-maven:5 ...
Authenticating with credentials from job payload (GitLab Registry)
Pulling docker image registry.gitlab.com/security-products/gemnasium-maven:5 ...
Using docker image sha256:79a6ee3479694f9d803011b9359ff5971aff57115a765cede4e2e32980f2df2d for registry.gitlab.com/security-products/gemnasium-maven:5 with digest registry.gitlab.com/security-products/gemnasium-maven@sha256:ccc1b5696922232ae6f499542e048b832deaa365811ca9db941120448e0b3457 ...
Preparing environment
00:05
Running on runner-jlguopmm-project-67510593-concurrent-0 via runner-jlguopmm-s-l-s-amd64-1740606413-4ff1c132...
Getting source from Git repository
00:01
Fetching changes with git depth set to 20...
Initialized empty Git repository in /builds/srs/POC/gemnasium-bug/.git/
Created fresh repository.
Checking out 5b20d94d as detached HEAD (ref is develop)...
Skipping Git submodules setup
$ git remote set-url origin "${CI_REPOSITORY_URL}"
Executing "step_script" stage of the job script
00:00
Using docker image sha256:79a6ee3479694f9d803011b9359ff5971aff57115a765cede4e2e32980f2df2d for registry.gitlab.com/security-products/gemnasium-maven:5 with digest registry.gitlab.com/security-products/gemnasium-maven@sha256:ccc1b5696922232ae6f499542e048b832deaa365811ca9db941120448e0b3457 ...
$ chmod +x gradlew
chmod: cannot access 'gradlew': No such file or directory
Uploading artifacts for failed job
00:01
Uploading artifacts...
WARNING: **/gl-sbom-*.cdx.json: no matching files. Ensure that the artifact path is relative to the working directory (/builds/ses/POC/gemnasium-bug) 
ERROR: No files to upload                          
Uploading artifacts...
WARNING: gl-dependency-scanning-report.json: no matching files. Ensure that the artifact path is relative to the working directory (/builds/ses/POC/gemnasium-bug) 
ERROR: No files to upload                          
Cleaning up project directory and file based variables
00:01
ERROR: Job failed: exit code 1
2

Cannot reproduce this behavior. SAST gets configured and runs semgrep. Michael Friedrich / Sast Dep Maven Test · GitLab

Can you share the full .gitlab-ci.yml configuration? I’d like to see which jobs/images/scripts are run.

SAST is different to Dependency Scanning. The latter will include https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/Dependency-Scanning.latest.gitlab-ci.yml

I don’t see any chmod +x gradlew calls there, so I would assume that this call originates from a custom CI/CD job override or similar.

3

No repro for me if I use a different GitLab account, rather than my company one. Which means my company admins must have customized SAST according to company needs and introduced this bug. I’ll notify my admins about this bug. Thanks for clarifying it!

1 Like
4

Thanks for the insight. If you and your team need further assistance with SAST, you can also open a support ticket.