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 thevulnerability-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 thegeneralallowlist
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
-
when using
CVE: cups
in thegeneralallowlist
section in the filevulnerability-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; -
when using CVE: cups but the vulnerabilities have no identifier but CVE was mentioned in the description, they continue to show;
-
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
Example Project
Use autodevops, it can be replicated for the container scan issue described above in 1)
What is the current bug behavior?
-
when using
CVE: cups
in thegeneralallowlist
section in the filevulnerability-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; -
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: -
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 thegeneralallowlist
section in the filevulnerability-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)