Security¶

Risks¶

CI/CD is the automation of most (if not all) process in your software lifecycle going from building to running the application in production. With so many things happening, attackers have a wide range of capabilities in case of a compromise:

introduce dubious components (i.e. backdoor) in the application,
leak (to the Internet) credentials granting access to internal services or infrastructures,
access said services or infrastructures,
impersonate an employee,
leak intellectual property,
...

Every CI/CD job is executed inside a container image which contains various tools required by the job. When you are executing the job, you are trusting the people building the image and the tools.

In some cases, the image may have been corrupted by an attacker. This is what we call a supply chain attack. There are famous cases like the Codecov incident in which hackers managed to leak credentials from several services and cloud platforms.

Mitigations¶

Variables scoping¶

To prevent leakage, CI/CD variables has to be present only in jobs that need them. By example in the Maven template, only the mvn-sonar job actually needs the SONAR_TOKEN environment variable so others jobs (mvn-build, mvn-release...) should not access this secret.

You can find more info about how to protect your CI/CD variables in the official GitLab documentation.

Image selection¶

As much as we can, we try to select either official images (ex: Maven, Python), or at least images maintained by an active community. Each of those images can be freely overridden with the appropriate configuration variable to select fixed versions (more info here) or any alternative that would suit you more.

By default, to be continuous templates mostly use the latest tag from upstream images since it is a maintenance-less default that works for nearly everyone. However latest images are prone to supply chain attacks and are also likely to introduce breaking changes.

to be continuous is not responsible of any possible security issue from a default container image.

To mitigate the risks of using latest images, you should always use a fixed version tag (maven:3.9.1 instead of maven:latest) or build your own image.

Additional dependencies¶

However, the direct counterpart of using official images is that many default image do not ship all the required tools used by the template (think about git and curl utilities). For this reason, many templates check the presence of these additional dependencies and install them on the fly (see maybe_install_pkg function).

This is a good practice to avoid bloating the image with unnecessary tools, but it also means that you are trusting the upstream repositories of your distribution (i.e. Debian, Alpine, etc.) to not be compromised and requiring network access to download packages.

Every project is encouraged to maintain his own Docker image in order to fit to their needs, avoid extraneous downloading for additional dependencies and simplify the work of security team (it's easy to scan a Docker image). While doing so, we recommend to use a minimal distribution and root-less images to prevent some container escalation vulnerabilities against your runner provider.

Tip

Whenever building your own image or using an upstream image, you can use Renovate to watch updates for your tools, test the new version and integrate them seamlessly.

Vulnerability Reports (Trivy)¶

Important

When reviewing vulnerabilities from containers, you have to consider the following principes :

containers are usually very short-lived in a CI/CD environment
no direct user access is possible
most job does not expose any exteral services (i.e. HTTP server) making attacks reliant on user interaction very hard if not impossible to exploit

In short, risks are often low in the CI/CD context but carefully reviewing vulnerabilities are an essential step to secure your pipeline.

Here are vulnerability reports for each default image used by to be continuous templates (generated every day):

Template	Image Variable	Default Image	Vulnerabilities