2.3. Secure Images

A lot of the container images contain security issues. If you want to use images from public registries you should be able to scan them to verify the image is clean.

There are some tools on the market which can help you to check these images.

In this lab you will learn how to scan an image with the tool Trivy .

Scan image for vulnerabilities and secrets

Trivy is as simple as it sounds! Just point it to your image and it will do the rest.

When Trivy runs for the very first time, it will download the latest vulnerability database from the internet. Without this, Trivy is not able to scan anything.

Let us try it out with our multi-stage image we built in the previous lab, in case you did not use the tag v0.1 you can add it with docker tag simple-java-hello-world:YOURTAG simple-java-hello-world:v0.1:

trivy image simple-java-hello-world:v0.1

Sometimes the trivy API gets overwhelmed with requests and reports an Error, just try again after a minute if that happens. A workaround is to use an image with a db from another registry:

trivy image --db-repository public.ecr.aws/aquasecurity/trivy-db:2 --java-db-repository "ghcr.io/aquasecurity/trivy-java-db:1" example-spring-boot-helloworld:v0.1

As you can see, we obtain the library name, CVE vulnerability number, severity level (HIGH, MEDIUM, LOW), vulnerability status (fixed, not fixed, or will not fix), and if fixed, the version with the fix, along with detailed information about the vulnerability.

With this data, we can upgrade libraries with fixes, assess the risk level of unfixed vulnerabilities, and remove unnecessary vulnerable libraries. Additionally, we have the opportunity to explore alternative libraries that are more secure.

In our case there were only vulnerabilites with Medium and Low.

In SSLDC scanning tools like this, are mostly part of a mandatory step in a CI/CD Pipeline before uploading the image to a registry. Generally, CVE’s with a score up to a certain threshold are accepted and the rest are blocked.

SLSA

Knowing what’s in our software through SBOMs is important, but we also need to ensure that our build process itself is secure. This is where SLSA (Supply chain Levels for Software Artifacts) comes in. It’s a framework from the Open Source Security Foundation that helps prevent tampering in the software supply chain.

Think of SLSA as a way to answer questions like:

• How do we know this image was actually built from our source code?
• Can we prove nobody modified it during the build?

SLSA tackles this through provenance (documenting where artifacts come from), build integrity (making builds reproducible and verifiable), and attestations (cryptographically signed metadata that proves authenticity).

The framework has four levels that progressively increase security. Level 1 just requires basic provenance documentation. Level 2 adds version control and authenticated provenance. Level 3 requires builds to run on isolated, hardened infrastructure. Level 4 is the highest level, requiring two-party review and hermetic builds.

Many CI/CD platforms like GitHub Actions, Google Cloud Build, and GitLab are starting to support SLSA compliance out of the box. You can verify SLSA attestations using tools like SLSA Verifier . While implementing higher SLSA levels takes effort, even starting at level 1 or 2 significantly reduces risks from compromised build systems or tampered dependencies.