Skip to content

Container scan - allowlist usage and logic

Summary

For container scan to use allowlist:

  • When container scan reports vulnerabilities with CVE identifier, adding the CVE to the generalallowlist section of the vulnerability-allowlist.yml file will suppress all vulnerabilities in the MR widget and pipeline security tab after the pipeline has run. However if the CVE identifier is in the description, adding the CVE to the generalallowlist will continue show the vulnerabilities in the MR widget and pipeline security tab.

  • allowlist function is not well understood without documentation and usage sample for vulnerability-allowlist.yml file definition and syntax

Steps to reproduce

  1. when using CVE: cups in the generalallowlist section in the file vulnerability-allowlist.yml (follow instruction in https://docs.gitlab.com/ee/user/application_security/container_scanning/#vulnerability-allowlisting) , all vulnerabilities (ones in the allowlist and also not listed in the allowlist) seem to be suppressed, i.e. not showing, and the vulnerabilities originally reported has CVE in an identifier;

  2. when using CVE: cups but the vulnerabilities have no identifier but CVE was mentioned in the description, they continue to show;

  3. Need documentation on how to use allowlist - this is what I can find so far:

generalwhitelist: #Approve CVE for any image
 CVE-2017-6055: XML
 CVE-2017-5586: OpenText
images:
 ubuntu: #Approve CVE only for ubuntu image, regardles of the version. If it is a private registry with a custom port registry:777/ubuntu:tag this won't work due to a bug.
  CVE-2017-5230: Java
  CVE-2017-5230: XSX
 alpine:
  CVE-2017-3261: SE

https://gitlab.com/gitlab-org/security-products/analyzers/klar/-/raw/master/testdata/vulnerability-allowlist.yml

Example Project

Use autodevops, it can be replicated for the container scan issue described above in 1)

What is the current bug behavior?

  1. when using CVE: cups in the generalallowlist section in the file vulnerability-allowlist.yml (follow instruction in https://docs.gitlab.com/ee/user/application_security/container_scanning/#vulnerability-allowlisting) , all vulnerabilities (ones in the allowlist and also not listed in the allowlist) seem to be suppressed, i.e. not showing, and the vulnerabilities originally reported has CVE in an identifier;

  2. when using CVE: cups but the vulnerabilities have no identifier but CVE was mentioned in the description, they continue to show; See this screen shot: Screen_Shot_2020-10-19_at_11.51.19_AM

  3. don't know how to use allowlist for inclusion and exclusion of vulnerabilities; don't know what are the syntax and evaluation logic sequence, and conditions.

What is the expected correct behavior?

  • When using CVE: cups in the generalallowlist section in the file vulnerability-allowlist.yml, vulnerabilities matched with the CVE id and allowed in the allowlist should be shown in container scan widget on MR and in the pipeline security container scan section.

  • Proper documentation and samples for the entire syntax of 3) this is what I can find so far:

generalwhitelist: #Approve CVE for any image
 CVE-2017-6055: XML
 CVE-2017-5586: OpenText
images:
 ubuntu: #Approve CVE only for ubuntu image, regardless of the version. If it is a private registry with a custom port registry:777/ubuntu:tag this won't work due to a bug.
  CVE-2017-5230: Java
  CVE-2017-5230: XSX
 alpine:
  CVE-2017-3261: SE

Relevant logs and/or screenshots

Output of checks

Results of GitLab environment info

Expand for output related to GitLab environment info GitLab.com but would have same issue with omnibus-gitlab installed version

(For installations with omnibus-gitlab package run and paste the output of: sudo gitlab-rake gitlab:env:info)

(For installations from source run and paste the output of: sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production)

Results of GitLab application Check

Expand for output related to the GitLab application check

(For installations with omnibus-gitlab package run and paste the output of: sudo gitlab-rake gitlab:check SANITIZE=true)

(For installations from source run and paste the output of: sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true)

(we will only investigate if the tests are passing)

Possible fixes

  1. Improve the documentation for the format of the vulnerability-allowlist.yml.
Edited by Alan (Maciej) Paruszewski