Security Supply Chain 101

container images

Ways of introducing container images into a organization

Is pretty easy to introduce vulnerabilities in your organization, from my experience, the flow of introducing new OCI images is one of these two:

• Either as a base image of your Dockerfile:

# Dockerfile from Directive
FROM [--platform=<platform>] <image> [AS <name>]

• Either pulling from dockerhub and retagging the image for your organization's private registry:

docker tag SOURCE_IMAGE[:TAG] TARGET_IMAGE[:TAG]

Low hanging fruits

First and foremost, when searching for an image in Dockerhub, check if the image is a Docker Official Image:

docker search --format "{{.Name}}: {{.StarCount}}: {{.IsOfficial}}" <image>

TL;DR: The Docker Official Images are a curated set of Docker repositories hosted on Docker Hub, that provide essential base repositories that serve as the starting point for the majority of users.

Search for alpine image

Next, let’s take some images from the host machine:

# get no of images
docker system info --format '{{ .Images}}'

# get images
docker images

Scaning images

There are many tools, and solutions that address this problem:

• Clair — analysis engine that inspects containers layer-by-layer for known security flaws
• Trivy — Aqua Security open source project that can scan container images
• Grype — Ancore’s vulnerability scanner

I’ll not install the binaries but instead, go for a containerized approach for each scanning tool.

Let’s take Trivy an open source project that can scan container images. For scanning container images simply spin up a Trivy container, and mount docker.sock from the host into the container (it’s advisable to mount a consistent cache dir on the host)

docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -v $HOME/Library/Caches:/root/.cache/ aquasec/trivy:0.44.1 image <IMAGE_NAME>

prom/prometheus image scan result

Also, you can opt for Grype having the same approach:

docker run --rm  -v /var/run/docker.sock:/var/run/docker.sock anchore/grype:latest <image>

One of the biggest differences between Trivy and Grype is the vulnerability database.

Vulnerability DBs

Last but not least, Docker can be an alternative. Docker Desktop 4.17 introduced Docker Scout, a tool that provides visibility into image vulnerabilities and recommendations for quick remediation.

docker scout

What is an SBOM and why should I care?

Having performed a brief introspection on how to quickly scan images, the subsequent action involves creating SBOMs (Software Bill of Materials).

Basically, the Software Bill Of Materials is a list of all packages and libraries included in an application. SBOMs are an emerging first step in the journey of achieving proper supply chain security. As a main concern, SBOM addresses the dependency graff of your project but also provides transparency concerning the risk that your project might be using components that have been EOL or have no support.

xkcd.com/2347/

Currently, there are 2 main SBOM standards CycloneDX (backed by the OWASP Foundation) and SPDX( Linux Foundation project).

One of the many tools that can generate SBOMs is Syft (exceptional for vulnerability detection when used with a scanner like Grype). The usage is rather straightforward, just install the Syft CLI and run:

syft -o cyclone-dx-json dejanualex/dockersay:1.0 | tee sbom.json

Simple scan

️ As a closing note, one should be aware that the landscape is highly dynamic, as new vulnerabilities are discovered over time, and tools potentially become outdated (e.g. Anchore Engine) therefore vulnerability assessment should be an ongoing process.

Last but not least try as much as possible to “Shift left” meaning move the security aspect at the earliest stages in the development lifecycle.