Allow dependency findings in container scanning analyzer
Release notes
Problem to solve
- Users are forced to run multiple security analyzer jobs when one job could have produced the same results
- Users are forced to build their own base images
In order to avoid duplication of findings, the container-scanning analyzer disables (Trivy) or ignores (Grype) any vulnerability findings that are not associated with an OS package.
If users want to monitor for vulnerabilities in dependencies, they need to configure Dependency Scanning in their project.
This works reasonable well for container images whose build process looks like:
- Use a base image (i.e.:
FROM x
) - Install OS dependencies for build and/or runtime
- Build and install application
- Publish resulting image
The Dependency Scanning analyzer would act on step 3 above, while the Container Scanning analyzer acts on step 4.
However, there's a common situation where a vulnerability is already present in step 1. The base image already contains a package with a known vulnerability but it's not identified in step 3 because the dependencies were not detected and it's not identified in step 4 because it's not an OS package.
The user is then forced to build the base image themselves, so that they have a chance to run the dependency scanning job on it. Even then, the user might need to adjust the build process for the base image, so that the required dependency inventory is available to the dependency scanning tool.
Example
This is an excerpt of the Dockerfile for python-3.9:alpine3.13:
RUN set -ex; \
\
wget -O get-pip.py "$PYTHON_GET_PIP_URL"; \
echo "$PYTHON_GET_PIP_SHA256 *get-pip.py" | sha256sum -c -; \
\
python get-pip.py \
--disable-pip-version-check \
--no-cache-dir \
"pip==$PYTHON_PIP_VERSION" \
; \
The code above is downloading get-pip.py
an running it. The pip
package is installed by get-pip.py
which uses pip
itself to install pip
.
The resulting action is the installation of the pip
package in the site_packages
directory of the Python interpreter utilised.
Grype scans the site_packages
and identifies the following finding:
NAME INSTALLED FIXED-IN VULNERABILITY SEVERITY
pip 21.1.3 CVE-2018-20225 High
This doesn't produce any of the required files to scan python dependencies: setup.py, requirements.txt, requirements.pip, requires.txt, Pipfile, Pipfile.lock, poetry.lock
.
Not using get-pip.py
would leave us in the same situation since packages installed directly with pip
would have the same effect without producing required dependency lists.
Long story short:
- any Python packages pre-installed in a base image are excluded from container scanning results.
- the dependency scanning analyzer requires a lock file, which is not available in this situation.
This is the same situation for any images that don't provide a "SBOM" or list of dependencyes. E.g.: a base image that installs one or more vulnerable gems without providing the Gemfile.lock
file.
Proposal
- Create a toggle that informs whether the analyzer should create security reports of different types.
- Investigate what the default for the toggle should be for each analyzer. For example, if more than half of projects using container scanning do not run any other analyzers, the default should be to allow.
- Update GitLab to ingest multiple security reports (it currently can only ingest a single report)
- Uploading and ingesting multiple security reports in the same job depends on something like Use case 2: Allowing multiple scans of different types in the same job by writing results in multiple files.
This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.