Skip to content

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

  1. Install old version of self-managed GitLab where SAST used DIND by default (I used gitlab-ee 11.10 )
  2. Connect privileged docker/kubernetes gitlab-runner executor to the instance/project.
  3. Trigger SAST job with include: SAST.gitlab-ci.yml in a repo with code to be scanned.
  4. 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! 🤝

Edited by Lucas Charles