SAST and Dependency Scanning with DinD fails with strconv.ParseUint: parsing "0.0": invalid syntax
Summary
Running SAST OR Dependency Scanning using Docker in Docker fails with strconv.ParseUint: parsing "0.0": invalid syntax
after common v2.21.4
..
This primarily impacts versions of GitLab that require Docker in Docker for SAST and Dependency Scanning scans. (GitLab v12.2 and older)
Option to disable DIND for SAST/DS scans is available in 12.3+.
DIND for SAST/DS is disabled by default in 13.0+ and unsupported after 13.4.
Steps to reproduce
- Install old version of self-managed GitLab where SAST used DIND by default (I used gitlab-ee
11.10
) - Connect privileged docker/kubernetes gitlab-runner executor to the instance/project.
- Trigger SAST job with
include: SAST.gitlab-ci.yml
in a repo with code to be scanned. - SAST job fails with following error:
[INFO] [analyzer-name] [2020-12-04T15:54:41Z] ▶ Detecting project
[INFO] [analyzer-name] [2020-12-04T15:54:41Z] ▶ Found project in /tmp/app
[INFO] [analyzer-name] [2020-12-04T15:54:41Z] ▶ Running analyzer
[INFO] [analyzer-name] [2020-12-04T15:57:24Z] ▶ Creating report
2020/12/04 15:57:27 strconv.ParseUint: parsing "0.0": invalid syntax
Uploading artifacts for failed job
Uploading artifacts...
WARNING: gl-sast-report.json: no matching files
ERROR: No files to upload
ERROR: Job failed: command terminated with exit code 1
Example Project
Problem:
Workaround:
What is the current bug behavior?
The first analyzer that runs will fail with strconv.ParseUint: parsing "0.0": invalid syntax
What is the expected correct behavior?
SAST with Docker in Docker successfully completes without strconv.ParseUint: parsing "0.0": invalid syntax
error.
Relevant logs and/or screenshots
Problem job trace: http://34.105.72.248/root/sast-dind-11-10/-/jobs/7
Workaround job trace: http://34.105.72.248/root/sast/-/jobs/5
Output of checks
Results of GitLab environment info
This only affects versions of GitLab that need Docker in Docker for SAST (12.2 and older).
Tested and reproduced on GitLab 11.10.4.
Expand for output related to GitLab environment info
System information System: Ubuntu 18.04 Proxy: no Current User: git Using RVM: no Ruby Version: 2.5.3p105 Gem Version: 2.7.6 Bundler Version:1.17.3 Rake Version: 12.3.2 Redis Version: 3.2.12 Git Version: 2.18.1 Sidekiq Version:5.2.5 Go Version: unknown GitLab information Version: 11.10.4-ee Revision: 88a3c791734 Directory: /opt/gitlab/embedded/service/gitlab-rails DB Adapter: PostgreSQL DB Version: 9.6.11 URL: http://34.105.72.248 HTTP Clone URL: http://34.105.72.248/some-group/some-project.git SSH Clone URL: git@34.105.72.248:some-group/some-project.git Elasticsearch: no Geo: no Using LDAP: no Using Omniauth: yes Omniauth Providers: GitLab Shell Version: 9.0.0 Repository storage paths: - default: /var/opt/gitlab/git-data/repositories GitLab Shell path: /opt/gitlab/embedded/service/gitlab-shell Git: /opt/gitlab/embedded/bin/git
Results of GitLab application Check
Expand for output related to the GitLab application check
Checking GitLab subtasks ...Checking GitLab Shell ...
GitLab Shell: ... GitLab Shell version >= 9.0.0 ? ... OK (9.0.0) Running /opt/gitlab/embedded/service/gitlab-shell/bin/check Check GitLab API access: OK Redis available via internal API: OK
Access to /var/opt/gitlab/.ssh/authorized_keys: OK gitlab-shell self-check successful
Checking GitLab Shell ... Finished
Checking Gitaly ...
Gitaly: ... default ... OK
Checking Gitaly ... Finished
Checking Sidekiq ...
Sidekiq: ... Running? ... yes Number of Sidekiq processes ... 1
Checking Sidekiq ... Finished
Checking Incoming Email ...
Incoming Email: ... Reply by email is disabled in config/gitlab.yml
Checking Incoming Email ... Finished
Checking LDAP ...
LDAP: ... LDAP is disabled in config/gitlab.yml
Checking LDAP ... Finished
Checking GitLab App ...
Git configured correctly? ... yes Database config exists? ... yes All migrations up? ... yes Database contains orphaned GroupMembers? ... no GitLab config exists? ... yes GitLab config up to date? ... yes Log directory writable? ... yes Tmp directory writable? ... yes Uploads directory exists? ... yes Uploads directory has correct permissions? ... yes Uploads directory tmp has correct permissions? ... yes Init script exists? ... skipped (omnibus-gitlab has no init script) Init script up-to-date? ... skipped (omnibus-gitlab has no init script) Projects have namespace: ... 1/1 ... yes 1/2 ... yes Redis version >= 2.8.0? ... yes Ruby version >= 2.5.3 ? ... yes (2.5.3) Git version >= 2.18.0 ? ... yes (2.18.1) Git user has default SSH configuration? ... yes Active users: ... 1 Elasticsearch version 5.6 - 6.x? ... skipped (elasticsearch is disabled)
Checking GitLab App ... Finished
Checking GitLab subtasks ... Finished
Possible fixes
Workaround I (GitLab <= v12.2)
Set the following variables for the sast
job. This will "pin" the analyzer versions to the last known working version and allow SAST with DIND to complete as it did previously.
sast:
variables:
SAST_DEFAULT_ANALYZERS: ""
SAST_ANALYZER_IMAGES: "registry.gitlab.com/gitlab-org/security-products/analyzers/bandit:2.9.6, registry.gitlab.com/gitlab-org/security-products/analyzers/brakeman:2.11.0, registry.gitlab.com/gitlab-org/security-products/analyzers/eslint:2.10.0, registry.gitlab.com/gitlab-org/security-products/analyzers/flawfinder:2.11.1, registry.gitlab.com/gitlab-org/security-products/analyzers/gosec:2.14.0, registry.gitlab.com/gitlab-org/security-products/analyzers/nodejs-scan:2.11.0, registry.gitlab.com/gitlab-org/security-products/analyzers/phpcs-security-audit:2.9.1, registry.gitlab.com/gitlab-org/security-products/analyzers/pmd-apex:2.9.0, registry.gitlab.com/gitlab-org/security-products/analyzers/secrets:3.12.0, registry.gitlab.com/gitlab-org/security-products/analyzers/security-code-scan:2.13.0, registry.gitlab.com/gitlab-org/security-products/analyzers/sobelow:2.8.0, registry.gitlab.com/gitlab-org/security-products/analyzers/spotbugs:2.13.6, registry.gitlab.com/gitlab-org/security-products/analyzers/tslint:2.4.0"
Feel free to remove any analyzers that you know you do not need from the SAST_ANALYZER_IMAGES
, but keep SAST_DEFAULT_ANALYZERS
set to an empty string ""
.
Workaround II (GitLab >= 12.3)
Disable docker in Docker for SAST and Dependency Scanning
include:
- template: SAST.gitlab-ci.yml
variables:
DS_DISABLE_DIND: "true"
SAST_DISABLE_DIND: "true"
Workaround III: Upgrade to 13.x and use the defaults
This is the permanent, future-proof solution.
As of 13.0, SAST defaults to not using Docker in Docker. In 13.4 and up, SAST using Docker in Docker is no longer supported. #220540 (closed)
If you're having this problem on 13.x or newer, you have customized your SAST job to specifically use Docker in Docker.
To remedy this, comment out any customizations you've made to your SAST CI job definition and follow the documentation here to configure atop the new and improved defaults job definition.
include:
- template: Security/SAST.gitlab-ci.yml
@plafoucriere @theoretick @rossfuhrman @gonzoyumo @twoodham Thanks for your help with this!