DEV Community: Chainguard

Deep Dive 🤿: Where Does Grype Data Come From?

Patrick Smyth — Tue, 12 Nov 2024 16:16:18 +0000

Grype is a vulnerability scanner for container images and filesystems. It's developed by Anchore and written in Golang. When you point Grype at a container image, it will scan the files and folders on that image, compare what it finds to a database of CVEs (known vulnerabilities), and spit out a report telling you what CVEs have been detected.

We like Grype at Chainguard because it's open source, customizable, and reliable enough to integrate into our CI and CVE remediation workflows. (You can read more about why we like Grype in this post.)

I know, my photoshop skills scare even me sometimes.

In this article, we'll answer a question that comes up frequently: where does Grype's vulnerability data come from? In the process, we'll take a look at Grype's open data pipe line and do some light analysis of the vulnerability data that Grype uses to scan containers.

How Grype Works

If you haven't used Grype before, here's a brief overview of how it works.

You point Grype at a container image (or filesystem).
Grype downloads a fresh instance of its vulnerability.db database, then scans the image for specific packages, files, configurations, and so on, building a manifest in the form of a Software Bill of Materials (SBOM) itemizing the software contained in the image. (Under the hood, Grype uses a sister tool, Syft, for this step.)
Grype then compares the specific versions of each package against the vulnerability data in its database.
Finally, a list of CVEs detected in the image is returned to the user.

For a comprehensive overview of Grype's functionality, check out Using Grype to Scan Container Images for Vulnerabilities on Chainguard Academy.

Grype's Data Sources

Grype relies on a set of upstream providers for its vulnerability data. As of November 2024, the list of providers includes:

Note that the above links are to endpoints where data is provided. Chainguard is one of the upstream providers, and updating scanners like Grype on the fixed status of packages in our upstream OS, Wolfi, is a key element in maintaining the low-to-no CVE status of Chainguard Images).

Grype's vulnerability.db gets rebuilt daily from data sourced from these upstream providers. To build this database, Grype uses two open source tools, vunnel and grype-db. The vunnel tool downloads, standardizes, and stores vulnerability data from the above upstream providers. Basically, it accesses the various provider endpoints and stores a local vulnerability database and metadata for each provider locally. The grype-db utility collates this vulnerability data, building a much smaller vulnerability.db usable by Grype.

Building the Grype Database with `vunnel` and `grype-db`

In this section, we'll try out the vunnel and grype-db utilities, building a local vulnerability cache and database.

Since a built-daily vulnerability.db file gets downloaded every time you run a Grype scan, why would you want to build Grype's vulnerability.db manually? Building manually is useful if:

You want to use a subset of upstream sources
You'd like to integrate other sources to create a custom vulnerability.db
You require older Grype schemas
You'd like to contribute to Grype
You want to understand more about Grype's upstream providers and data structure

`vunnel`

Thegrype-db utility uses vunnel under the hood, but let's first try out vunnel explicitly to see how it works. You'll need Python 3 installed for this section, and I'll assume it's accessible on your system using the python command. (vunnel is written in Python.)

First, let's create a project folder:

mkdir -p ~/vulnerability-data && cd $_

Next, create a virtual environment and activate it:

python -m venv venv && source venv/bin/activate

Now install vunnel to the activated virtual environment:

pip install vunnel

Once vunnel is installed, we can use the vunnel list command to show the current list of providers:

vunnel list

alpine
amazon
chainguard
...
sles
ubuntu
wolfi

You can download a local cache of provider data for any of these providers with the following (using chainguard as an example provider):

vunnel run chainguard

This creates a data folder where all provider data used as input and the standardized output database are contained:

data
└── chainguard
    ├── checksums
    ├── input
    │   └── secdb
    │       └── security.json
    ├── metadata.json
    └── results
        └── results.db

`grype-db`

The grype-db utility can pull provider data with vunnel under the hood, and can also collect and package up this data into the vulnerability.db file used by Grype.

In the following, we'll use grype-db to download all provider data using vunnel under the hood, then build the vulnerability.db file. The process of downloading all provider data can take some time and uses about 8 GB of disk space.

First, download the grype-db script to the project folder we created previously:

curl -sSfL https://raw.githubusercontent.com/anchore/grype-db/main/install.sh | sh -s -- -b .

If you'd like to build from all available data, you'll need a GitHub token capable of authenticating as a user. This is because GitHub rate limits API access for non-authenticated users. You can follow these instructions provided by GitHub, but in short head to this token settings page on GitHub. Remember to safeguard your token as you would a password, and I recommend creating a scoped and short-lived (i.e. 7 days) token.

Once you have your token, create a configuration file for grype-db in our ~/vulnerability-data project folder. First, set your generated GitHub token to an environment variable:

GITHUB_TOKEN=ghp_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Next, generate the config in our ~/vulnerability-data project folder:

cat << EOF > ~/vulnerability-data/.grype-db.yaml
provider:
  vunnel:
    executor: local
    generate-configs: true
    env:
      GITHUB_TOKEN: $GITHUB_TOKEN
EOF

Now we have the grype-db script and the .grype-db.yaml configuration file in our project folder. Let's run a command that will pull all provider data, create a database file, and package it up for inclusion in a CI or other workflow. (For this step, you'll need vunnel available, so the virtual environment created in the previous section on vunnel will need to still be activated, and you should run this command from the project folder where we downloaded the grype-db script.)

./grype-db -g

Downloading and processing all provider data can take a long time, possibly hours, so go watch Master of the Flying Guillotine or get some work done, I guess. ☕

Once the process completes, a build folder will have been created in our ~/vulnerability-data/ project folder:

build
├── listing.json
├── metadata.json
├── provider-metadata.json
├── vulnerability.db
└── vulnerability-db_v5_2024-11-05T19:09:08Z_1730848219.tar.gz

The vulnerability.db database should be the same as the database built daily for use by Grype.

Grype's `vulnerability.db`

I plan on following up this post with an analysis of the data in Grype's vulnerability.db database, but here are some quick notes on the structure of this SQLite3 file:

When Grype runs, it checks against the last time the database was updated. If it's been longer than a day (Grype rebuilds the database daily) a new vulnerability.db is downloaded to a cache. - On Linux, it's stored in ~/.cache/grype/db/5/vulnerability.db, where the numbered folder (5) corresponds to the current Grype schema version number.) On Mac OS, it's stored in ~/Library/Caches/grype/db by default.

The vulnerability.db database has five tables, but only two have significant data. The vulnerability_metadata table stores information on CVEs as they apply on a per-platform basis. The entities in the vulnerability table represent vulnerabilities as they apply to specific package versions.

The platforms with the most vulnerability metadata entries are Ubuntu, NVD (NIST's National Vulnerability Database,, and Susa.

While these results are somewhat interesting when considering where Grype data comes from, the number here reflects many factors, mainly the date the provider started recording vulnerabilities and, for platform-specific providers, the attack surface of the platform. Other details such as duplication of distros lower the signal here and would require more analysis to parse out.

We can also check the number of vulnerability metadata entries by year:

This chart mainly shows a movement toward maturity in the ecosystem, leading to some stability after 2016-2017. (The early twenty-teens were a time of rapid development in cloud technologies in particular.)

Digging into the data in Grype's vulnerability.db can also help to answer much more specific questions about how CVE affect different platforms. For example, imagine we host a mailserver and we wish to know the fixed status of CVE-2024-37383, a known-exploited vulnerability which allows cross-site scripting in RoundCube, a webmail client. We can narrow the data in the vulnerability table to answer this question:

fix_state	namespace
fixed	nvd:cpe
fixed	debian:distro:debian:11
fixed	debian:distro:debian:12
fixed	debian:distro:debian:13
fixed	debian:distro:debian:unstable
not-fixed	ubuntu:distro:ubuntu:20.04
not-fixed	ubuntu:distro:ubuntu:22.04
fixed	ubuntu:distro:ubuntu:23.10

In a follow-up post, I'll show you how to load Grype's vulnerability.db database into Pandas to get a better sense of Grype's data schema and how it can be used to answer specific questions in platform security and broader CVE trends.

Conclusion

One of the most remarkable aspects of the Grype image scanner is the openness of its data pipeline. This is great for transparency and makes Grype's vulnerability.db into a more flexible and useful tool. If you've found this post useful, let us know and maybe you'll see more security deep dives like this. 🛡️🤿 You can follow Chainguard on dev.to or LinkedIn or sign up for our newsletter to keep in touch.

Resources

On the Supply Chain Security Trail with Docker Scout

Adrian Mouat — Tue, 18 Jun 2024 10:23:19 +0000

I believe Docker Scout is one of the best supply-chain security and scanning tools available for the container ecosystem. Before we get into details, I want to make clear that I'm a Docker Captain, so I'm not entirely unbiased here! And Scout itself has a free tier, but if you want to monitor multiple repositories, then you'll need to purchase a subscription. Now that that's clear, please read on to understand why I like Scout and what separates it from other solutions.

The first thing to be aware of is that Scout isn't just a vulnerability scanner, and Docker's marketing materials tend to avoid that term. Scout takes a holistic approach to supply chain security. It starts by analysing containers and extracting or creating a complete Software Bill of Materials (SBOM) for images. With the Hub integration, these can be monitored over time for compliance to policies. Policies include – predictably – flagging images with high or critical vulnerabilities, but there are also policies such as "avoiding copy-left licences" and verifying "supply chain attestations".

Other features that go beyond simple vulnerability scanning include the ability to provide recommendations for mitigations and improvements and an already impressive list of integrations (not just with the Docker Hub, but also other registries, code editors, CI/CD platforms and build tooling).

There are two main parts to Scout: a web application that you can see in the below image, and a CLI tool that I will use throughout the rest of this article.

To dig a bit deeper, let's try analysing a few images. We said already that the starting point for everything is the SBOM, so let's try generating one. Interestingly, Scout has its own sbom command, separate from docker sbom which is powered by syft. I assume the Scout version will eventually replace docker sbom. Here's the SBOM for the official Redis image:

docker scout sbom --format list redis
{"level":"info","msg":"SBOM of image already cached, 133 packages indexed\n","time":"2024-06-12T14:50:48+01:00"}

           Name                  Version          Type
────────────────────────────────────────────────────────────
  acl                     2.3.1-3                deb
  …
  gosu                    (devel)                golang
  …
  redis                   7.2.5                  generic
  stdlib                  go1.18.2               golang
  stdlib                  1.18.2                 golang
  sys                     0.13.0                 golang
  sys                     0.1.0                  golang
  …

The majority of the output is deb packages, most of which I've clipped to reduce the size of the output. Scout has found these packages by reading the package manager database. This is as far as some other tooling goes, but we can see it's also picked up a few more things. Scout has found the binaries for two more applications – redis and gosu – that were downloaded directly from a website rather than being installed via the package manager. It's also analysed the gosu binary and found the libraries it links against. The effectiveness of supply chain tooling is strongly tied to its performance in identifying contents – if Scout had failed to find these binaries, it would not be able to scan them for vulnerabilities or ensure they match any policies.

In the equivalent Chainguard Image we can see everything is installed via the apk package manager:

$ docker scout sbom --format list cgr.dev/chainguard/redis
{"level":"info","msg":"SBOM of image already cached, 18 packages indexed\n","time":"2024-06-12T15:05:03+01:00"}

           Name               Version       Type
────────────────────────────────────────────────────
  bash                    5.2.21-r4         apk
  busybox                 1.36.1-r10        apk
  ca-certificates         20240315-r3       apk
  ca-certificates-bundle  20240315-r3       apk
  glibc                   2.39-r6           apk
  glibc-locale-posix      2.39-r6           apk
  ld-linux                2.39-r6           apk
  libcrypt1               2.39-r6           apk
  libcrypto3              3.3.0-r9          apk
  libssl3                 3.3.0-r9          apk
  libxcrypt               4.4.36-r7         apk
  ncurses                 6.4_p20231125-r3  apk
  ncurses-terminfo-base   6.4_p20231125-r3  apk
  openssl                 3.3.0-r9          apk
  posix-libc-utils        2.39-r6           apk
  redis-7.2               7.2.5-r2          apk
  redis-cli-7.2           7.2.5-r2          apk
  wolfi-baselayout        20230201-r11      apk

This is the full output – clearly demonstrating how much leaner Chainguard Images are.

An interesting question is what happens to containers you build yourself with a multi-stage process – will it pick everything up? As a test, I used an example Go application with a multi-stage build:

$ docker scout sbom test --format=list
{"level":"info","msg":"SBOM of image already cached, 7 packages indexed\n","time":"2024-06-12T15:46:18+01:00"}

           Name             Version      Type
──────────────────────────────────────────────────
  ca-certificates         20240315-r3   apk
  ca-certificates-bundle  20240315-r3   apk
  learninglabsstatic      (devel)       golang
  stdlib                  1.22.4        golang
  stdlib                  go1.22.4      golang
  tzdata                  2024a-r2      apk
  wolfi-baselayout        20230201-r11  apk

This looks pretty good! It has found the binary, the libraries it links against and the handful of packages that are in the Chainguard static image. If you regularly use another scanner, I'd recommend running a test like this to make sure it's aware of everything in your image. I'd also recommend running against a few different builds using different ecosystems to check that it properly identifies your Rust binaries or Java jars.

One of the best features in Scout is vulnerability scanning output. I often find it a struggle to get accurate high-level info from scanners, but it's easy with Scout. The simple tweak of displaying summary output at the end, instead of before a huge list of issues that you have to scroll backwards through, is much appreciated. Here's the output from scanning the current nginx:alpine image:

$ docker scout cves nginx:alpine
    ✓ SBOM of image already cached, 82 packages indexed
    ✗ Detected 2 vulnerable packages with a total of 5 vulnerabilities


## Overview

                    │       Analyzed Image
────────────────────┼──────────────────────────────
  Target            │  nginx:alpine
    digest          │  4f49228258b6
    platform        │ linux/arm64
    vulnerabilities │    0C     0H     5M     0L
    size            │ 22 MB
    packages        │ 82


## Packages and Vulnerabilities

   0C     0H     4M     0L  busybox 1.36.1-r15
pkg:apk/alpine/busybox@1.36.1-r15?os_name=alpine&os_version=3.19

    ✗ MEDIUM CVE-2023-42366
      https://scout.docker.com/v/CVE-2023-42366
      Affected range : <1.36.1-r16
      Fixed version  : 1.36.1-r16

    ✗ MEDIUM CVE-2023-42365
      https://scout.docker.com/v/CVE-2023-42365
      Affected range : <1.36.1-r19
      Fixed version  : 1.36.1-r19

    ✗ MEDIUM CVE-2023-42364
      https://scout.docker.com/v/CVE-2023-42364
      Affected range : <1.36.1-r19
      Fixed version  : 1.36.1-r19

    ✗ MEDIUM CVE-2023-42363
      https://scout.docker.com/v/CVE-2023-42363
      Affected range : <1.36.1-r17
      Fixed version  : 1.36.1-r17


   0C     0H     1M     0L  curl 8.5.0-r0
pkg:apk/alpine/curl@8.5.0-r0?os_name=alpine&os_version=3.19

    ✗ MEDIUM CVE-2024-0853
      https://scout.docker.com/v/CVE-2024-0853
      Affected range : <8.6.0-r0
      Fixed version  : not fixed

5 vulnerabilities found in 2 packages
  LOW       0
  MEDIUM    5
  HIGH      0
  CRITICAL  0


What's next:
    View base image update recommendations → docker scout recommendations nginx:alpine

It's also possible to only get the initial summary output by calling the quickview command.

In my testing, I've noticed that – compared to some other scanner tooling – Scout will report less CVEs. Docker claims this is because they are less vulnerable to false positives (where a CVE is wrongly attributed to an image). The primary reason they give for this is that Scout uses Package URLs or PURLs to match software, rather than CPEs.

On the other hand, Scout will report more matches than some tooling (I realise this is confusing, but I don't want to name names without providing a full breakdown and analysis). This is because Scout uses a wide range of sources to build its vulnerability database – as well as the security data from Linux distributions, it includes NVD, GitHub and other advisory data. The more data sources that are used, the more likely you are to find matches.

The last sentence in the command output hints at another feature in Scout – the ability to recommend fixes. One of the biggest flaws with current scanning tools is that they often flag issues that you can do nothing about – vulnerabilities for which there is no newer package or fix available. Scout helps you both filter out issues that you can't deal with and fix the ones you can.

Here's the recommendations output for the Debian-based nginx:latest image, which suggests changing to a different tag to reduce CVEs, and gives details of the potential impact:

docker scout recommendations nginx
    ✓ SBOM of image already cached, 231 packages indexed

    i Base image was auto-detected. To get more accurate recommendations, build images with max-mode provenance attestations.
      Review docs.docker.com ↗ for more information.
      Alternatively, use  docker scout recommendations --tag <base image tag>  to pass a specific base image tag.

  Target   │  nginx:latest
    digest │  705b7f60fea5

## Recommended fixes

  Base image is  debian:12-slim

  Name            │  12-slim
  Digest          │  sha256:6dc38501802c1554f0fd858d1153a6f0e18c71006c6d0b31cf19fa778900e658
  Vulnerabilities │    0C     0H     0M    23L
  Pushed          │ 1 month ago
  Size            │ 29 MB
  Packages        │ 125
  Flavor          │ debian
  OS              │ 12
  Slim            │ ✓


  │ The base image is also available under the supported tag(s)  12.5-slim ,  bookworm-slim . If you want to display recommendations specifically
  │ for a different tag, please re-run the command using the  --tag  flag.



Refresh base image
  Rebuild the image using a newer base image version. Updating this may result in breaking changes.


            Tag            │                  Details                   │    Pushed    │       Vulnerabilities
───────────────────────────┼────────────────────────────────────────────┼──────────────┼──────────────────────────────
   12-slim                 │ Benefits:                                  │ 11 hours ago │    0C     0H     0M    23L
  Newer image for same tag │ • Same OS detected                         │              │
  Also known as:           │ • Newer image for same tag                 │              │
  • 12.5-slim              │ • Tag was pushed more recently             │              │
  • bookworm-slim          │ • Image has similar size                   │              │
  • bookworm-20240612-slim │ • Image has same number of vulnerabilities │              │
                           │ • Image contains equal number of packages  │              │
                           │ • Tag is using slim variant                │              │
                           │                                            │              │
                           │ Image details:                             │              │
                           │ • Size: 29 MB                              │              │
                           │ • Flavor: debian                           │              │
                           │ • OS: 12                                   │              │
                           │ • Slim: ✓                                  │              │
                           │                                            │              │
                           │                                            │              │
                           │                                            │              │


Change base image
  The list displays new recommended tags in descending order, where the top results are rated as most suitable.


           Tag           │                    Details                    │    Pushed    │       Vulnerabilities
─────────────────────────┼───────────────────────────────────────────────┼──────────────┼──────────────────────────────
   stable-slim           │ Benefits:                                     │ 11 hours ago │    0C     0H     0M    23L
  Tag is preferred tag   │ • Same OS detected                            │              │
  Also known as:         │ • Tag is preferred tag                        │              │
  • stable-20240612-slim │ • Tag was pushed more recently                │              │
                         │ • Image has similar size                      │              │
                         │ • Image has same number of vulnerabilities    │              │
                         │ • Image contains equal number of packages     │              │
                         │ • Tag is using slim variant                   │              │
                         │ • stable-slim was pulled 46K times last month │              │
                         │                                               │              │
                         │ Image details:                                │              │
                         │ • Size: 29 MB                                 │              │
                         │ • Flavor: debian                              │              │
                         │ • OS: 12                                      │              │
                         │ • Slim: ✓                                     │              │
                         │                                               │              │
                         │                                               │              │
                         │                                               │              │
   12                    │ Benefits:                                     │ 11 hours ago │    0C     0H     0M    23L
  Tag is latest          │ • Same OS detected                            │              │
  Also known as:         │ • Tag was pushed more recently                │              │
  • 12.5                 │ • Tag is latest                               │              │
  • bookworm             │ • Image has same number of vulnerabilities    │              │
  • bookworm-20240612    │ • Image contains equal number of packages     │              │
  • latest               │                                               │              │
                         │ Image details:                                │              │
                         │ • Size: 50 MB                                 │              │
                         │ • Flavor: debian                              │              │
                         │ • OS: 12                                      │              │
                         │                                               │              │
                         │                                               │              │
                         │                                               │              │

Finally, let's take a look at the Chainguard nginx image.

docker scout cves chainguard/nginx
    ✓ SBOM obtained from attestation, packages found
    ✓ No vulnerable package detected


## Overview

                    │       Analyzed Image
────────────────────┼──────────────────────────────
  Target            │  chainguard/nginx:latest
    digest          │  1ffdf2c788d4
    platform        │ linux/arm64
    vulnerabilities │    0C     0H     0M     0L
    size            │ 20 MB
    packages        │ 55


## Packages and Vulnerabilities

  No vulnerable packages detected

As expected, there are no vulnerabilities, but also note the text at the start – "SBOM obtained from attestation, packages found". Scout has used the SBOM that Chainguard provided for the image and used that to enumerate the software in the image. This level of integration and support for external tooling is essential for creating a holistic supply chain security solution – every organisation uses a different set of tools and software from various vendors and it's imperative that we figure out how to get supply chain information from everyone in a verifiable and trustable manner.

Hopefully I've shown you why I like Docker Scout. It does a good job of finding all the packages in an image but also does a great job of reporting vulnerabilities. Vulnerabilities are less likely to be false positives through the use of PURLs and the summary output is easy to grab (which is great for videos!). Docker will tell you the real strengths lie in continuously monitoring repositories and reporting on progress towards supply chain policies, and I plan to create some further content on this in the future.

Please give Docker Scout a whirl (compare some Chainguard Images!) and let me know what you think.

Cover photo by Maël BALLAND on Unsplash

Debugging Distroless Images with kubectl and cdebug

Adrian Mouat — Fri, 31 May 2024 14:37:01 +0000

Ivan Velichko recently made me aware of issues with debugging distroless containers in Kubernetes with kubectl debug. This blog will take a look at the problem and show you can get access to the filesystem of a distroless pod for debugging purposes.

The problem Ivan found was a lack of permissions to access the filesystem of the container being debugged. This is best explained with some examples. With a regular (non-distroless) container, you can do the following to start an ephemeral debug container that shares various namespaces with the target container:

$ kubectl run nginx-pod --image nginx
pod/nginx-pod created
$ kubectl debug -it nginx-pod --image alpine --target nginx-pod
Targeting container "nginx-pod". If you don't see processes from this container it may be because the container runtime doesn't support this feature.
Defaulting debug container name to debugger-h4fzv.
If you don't see a command prompt, try pressing enter.
/ # ps
PID   USER     TIME  COMMAND
    1 root      0:00 nginx: master process nginx -g daemon off;
   32 101       0:00 nginx: worker process
   33 101       0:00 nginx: worker process
   34 101       0:00 nginx: worker process
   35 101       0:00 nginx: worker process
   36 101       0:00 nginx: worker process
   37 101       0:00 nginx: worker process
   38 101       0:00 nginx: worker process
   39 101       0:00 nginx: worker process
   40 101       0:00 nginx: worker process
   41 101       0:00 nginx: worker process
  308 root      0:00 /bin/sh
  317 root      0:00 ps

(You could also just use kubectl exec -it nginx-pod -- /bin/sh, but of course that's not possible in a distroless container)

Note that the filesystem is the filesystem of the Alpine debug container, not the nginx container:

/ # cat /etc/os-release
NAME="Alpine Linux"
ID=alpine
VERSION_ID=3.19.1
PRETTY_NAME="Alpine Linux v3.19"
HOME_URL="https://alpinelinux.org/"
BUG_REPORT_URL="https://gitlab.alpinelinux.org/alpine/aports/-/issues"

But we can get to the nginx container filesystem via the /proc/1/root filesystem. To break this down:

/proc is a virtual filesystem created by the kernel that contains various metadata
1 refers to the process id, in this case our running nginx master process; and
root is a link to the root of the filesystem the process is running in.

So we can access the index.html file inside the nginx container like this:

/ # cat /proc/1/root/usr/share/nginx/html/index.html
<!DOCTYPE html>
<html>
…
/ #

Now let's try that with the cgr.dev/chainguard/nginx image, which is one of Chainguard's distroless images:

$ kubectl run nginx-distroless --image cgr.dev/chainguard/nginx
pod/nginx-distroless created
$ kubectl debug -it nginx-distroless --image alpine --target nginx-distroless
Targeting container "nginx-distroless". If you don't see processes from this container it may be because the container runtime doesn't support this feature.
Defaulting debug container name to debugger-bcr26.
If you don't see a command prompt, try pressing enter.
/ # cat /proc/1/root/usr/share/nginx/html/index.html
cat: can't open '/proc/1/root/usr/share/nginx/html/index.html': Permission denied
/ # whoami
root

We get Permission denied.

It turns out that the problem is that the nginx container is running as the user nonroot with UID 65532, which we don't have permission to access despite being root (using --profile to set a different security profile didn't help either, but I suspect it might in the future). To fix this, we need our debug container to run as the same user as the nginx container. Unfortunately there's no --user flag for kubectl, so we need to have an image that runs as this user by default. We could create one e.g with a Dockerfile such as:

FROM alpine
USER 65532

But in the case of Chainguard Images there's a much easier solution. Most of our images come with -dev variants that run as the same user but also include a shell and can be used for debugging, so we can do:

$ kubectl debug -it nginx-distroless --image cgr.dev/chainguard/nginx:latest-dev --target nginx-distroless -- /bin/sh
Targeting container "nginx-distroless". If you don't see processes from this container it may be because the container runtime doesn't support this feature.
Defaulting debug container name to debugger-nbvjt.
If you don't see a command prompt, try pressing enter.
/ $
/ $ cat /proc/1/root/usr/share/nginx/html/index.html
<!DOCTYPE html>
<html>
…

And everything works as expected.

There's actually a second wrinkle that is also solved by setting the user – if your pod is running with the runAsNonRoot policy, you won't be able to start a debug container that runs as root with the default profile.

This does point to some ways in which kubectl debug could be improved:

Add a --user option to set the user in the debug container
Add a formal way to access the target container filesystem. Going via /proc/1/root seems a little hacky and non-intuitive
Add some more docs to explain all of this (which is somewhere I plan to help).

(I do see there are some proposed enhancements related to profiles that might help here)

I should also point out that Ivan addresses these problems directly with his cdebug tool. You can use cdebug to directly debug a pod:

$ cdebug exec -it --privileged pod/nginx-distroless/nginx-distroless
Debugger container name: cdebug-20ba5985
Starting debugger container...
Waiting for debugger container...
Attaching to debugger container...
If you don't see a command prompt, try pressing enter.
/ # cat /proc/1/root/usr/share/nginx/html/index.html
<!DOCTYPE html>
<html>
…

cdebug also supports a --user flag if you have the runAsNonRoot policy e.g:

cdebug exec -it --user 65532 pod/nginx-distroless/nginx-distroless
…

That's about it. Running production workloads in distroless containers is a big improvement in terms of security. With a little bit of knowledge these containers can still be straightforward to debug.

Securely Containerize a Python Application with Chainguard Images

Patrick Smyth — Fri, 12 Apr 2024 19:09:57 +0000

Overview

Containerization technologies such as Docker have revolutionized the development to production pipeline, making it easier than ever to reproduce environments and set up and maintain infrastructure. Unfortunately, containers come with their own risks and overhead. While standard images can be convenient for development, putting large images into production increases the attack surface and can demand additional and unnecessary resources in deployment.

In this tutorial, we'll build on a Chainguard Image to containerize a Python application in a multi-stage build process. By using a Chainguard Image, our containerized application benefits from a minimalist design that reduces attack surface and from a set of features focused on security and ease of development. In addition, the use of a multistage build process will allow us to develop our application with access to tools such as package managers while removing these potential vulnerabilities later in the build process.

Creating the Application

The Python application we will containerize in this tutorial, Chainguard Timeteller, will provide the user with the local time in ten randomly chosen international timezones. It also displays the time in UTC and in the user's local timezone. The application depends on pytz, allowing us to draw from the Olson tz database in selecting our random timezones.

Let's start by creating our main application script.
First, open your terminal and run the below line to create a new folder called timeteller in your home directory:

mkdir ~/timeteller && cd ~/timeteller

Open a new file called main.py in your preferred text editor. We'll use the widely available Nano editor in this tutorial.

nano main.py

Copy the following Python code into main.py:

from datetime import datetime
from time import tzname
from random import sample
from pytz import timezone, common_timezones


def tz_aware_now(tz=timezone("utc")):
    """Create a timezone-aware datetime for the current time and a provided timezone. Defaults to UTC."""
    now = datetime.now(tz)

    return now


def pretty_print_time(t):
    """Given a datetime object, return a human-readable and nicely-formatted time string.."""

    # Generate an ordinal suffix, i.e. "th" or "st" based on the day
    day = t.day
    day_ordinal_suffix = str(day) + (
        "th"
        if 4 <= day % 100 <= 20
        else {1: "st", 2: "dayd", 3: "rd"}.get(day % 10, "th")
    )

    date_pretty = " ".join([t.strftime("%-I:%M %p on %B"), day_ordinal_suffix])

    return date_pretty


def generate_timezone_message():
    """Create the message to display to a user. The message includes a greeting, the current time in UTC, the user's local timezone and time, and ten local times from randomly selected timezones."""

    local_time = tz_aware_now(tz_aware_now().astimezone().tzinfo)

    random_timezones = sample(common_timezones, 10)

    timezones_map = {
        zone: pretty_print_time(tz_aware_now(timezone(zone)))
        for zone in random_timezones
    }

    printable_timezones = [
        " ".join(["    ", "➤", zone, timezones_map[zone]]) for zone in timezones_map
    ]

    message = "\n".join(
        [
            "\nWelcome to Chainguard Timeteller! \n",
            f"🌎 The current time in UTC is {pretty_print_time(tz_aware_now())}.",
            f"❓ Your current timezone is {tzname[0]}.",
            f"⏰ Your local time is {pretty_print_time(local_time)}.\n",
            "Local times from ten randomly chosen timezones around the world:\n",
            *printable_timezones,
        ]
    )

    return message


if __name__ == "__main__":
    print(generate_timezone_message())

If you're using Nano, you can save the file by pressing Control-x, y, and Enter in sequence.

In this script, we define functions to return the current time in a specific timezone, generate nicely-formatted lines for each region, and pull together a message to the user. When run directly, the script prints the generated message, including the time in ten randomly selected timezones, to the console. The code depends on a library, pytz, not in the standard library, and we'll have to install it during our build process.

Because our code depends on pytz, a package not in Python's standard library, we'll also need to specify our dependencies. Open a requirements.txt file using your text editor:

nano requirements.txt

Copy the below into the file.

pytz==2024.1

Here, we specify the version of pytz we want to use. Once you're done, save the file.

Before we build our container, let's test that our script works. First, install our dependency using the pip package manager:

pip install -r requirements.txt

Depending on your system, you may need to use the pip3 command instead of the pip command.

Once pytz has installed, run the script with the below command:

python main.py

Depending on your system, you may need to use the python3 command instead of the python command. You should receive output similar to the following:


Welcome to Chainguard Timeteller! 

🌎 The current time in UTC is 6:07 PM on February 18th.
❓ Your current timezone is EST.
⏰ Your local time is 1:07 PM on February 18th.

Local times from ten randomly chosen timezones around the world:

     ➤ Europe/Dublin 6:07 PM on February 18th
     ➤ Africa/Lagos 7:07 PM on February 18th
     ➤ America/Tortola 2:07 PM on February 18th
     [...]

When you see the above output with local times in ten randomly-selected timezones, you'll know the application is working. You're ready to containerize Timeteller using a base image from Chainguard Images.

Multi-Stage Build Using Chainguard Images

Now that we have our application in place, we're ready to containerize it using a multi-stage build process. This build process works as follows:

We begin the build by pulling a development version of the python-latest Chainguard Image as our base image.
We copy the requirements.txt file to the image, activate our virtual environment, and install our dependency using pip.
We now pull the minimal runtime version of the python-latest image. This image does not contain pip or an interactive shell.
We copy our virtual environment (now with access to our dependency) from the dev image to the minimal runtime image.
We activate our virtual environment on the minimal runtime image and run the application.

Create a file named Dockerfile in your timeteller folder:

nano Dockerfile

Copy the following build instructions to the Dockerfile:

FROM cgr.dev/chainguard/python:latest-dev as builder

ENV LANG=C.UTF-8
ENV PYTHONDONTWRITEBYTECODE=1
ENV PYTHONUNBUFFERED=1
ENV PATH="/timeteller/venv/bin:$PATH"

WORKDIR /timeteller

RUN python -m venv /timeteller/venv
COPY requirements.txt .

RUN pip install --no-cache-dir -r requirements.txt

FROM cgr.dev/chainguard/python:latest

ENV TZ="America/Chicago"

WORKDIR /timeteller

ENV PYTHONUNBUFFERED=1
ENV PATH="/venv/bin:$PATH"


COPY main.py ./
COPY --from=builder /timeteller/venv /venv

ENTRYPOINT [ "python", "/timeteller/main.py" ]

Change the timezone in the line ENV TZ="America/Chicago"to your own local timezone. (Without providing this information, the detected timezone in the container would be UTC.)

Save the file. We should now be ready to perform the build. Run the following:

docker build . -t timeteller

This will build the image from the instructions in our Dockerfile and tag it with the name timeteller.

If the image build is successful, you're ready to run it with the following:

docker run --rm timeteller

You should see the output from our application as above, including the ten randomly selected local times. Congratulations! You've successfully containerized and run an application using Chainguard Images in a multi-stage build process.

The final image based on python:latest does not contain either pip or interactive shells such as sh or bash. Since package managers and shells are common vectors for attackers, having neither as part of our runtime image decreases the attack surface of our application in production. The multi-stage build process allows us to use tools such as shells and package managers during development while allowing us to keep our production image securely minimal.

Advantages of Chainguard Images

Chainguard Images provide a happy medium between superminimal images such as scratch and more complex distribution-based images such as Alpine or Debian. Chainguard Images aim specifically to reduce complexity, intentionally including only those software components necessary for runtime. Further, Chainguard Images are based on a distroless philosophy, meaning that they strip out additional software components traditionally associated with a distribution. Typically, a Chainguard Image contains only an application runtime, root certificates, a minimal file structure, and a small number of core system libraries.

Each Chainguard Image comes with a comprehensive SBOM (Software Bill of Materials). This allows users of Chainguard Images to check against known vulnerabilities, adhere to the legal terms of software licenses, and ensure software integrity.

Finally, the focus on minimal builds results in significantly fewer CVEs on your runtime images. Before we end this tutorial, let's scan for CVEs in our Timeteller image using an industry-standard tool, Docker Scout.

To use Docker Scout, you'll first have to have a Docker Hub account. Follow the installation instructions for Docker Scout on GitHub. Once Docker Scout is installed, you can sign in to Docker Hub on the command line with the docker login command.

Once we have Docker Scout installed, we can use it to scan for vulnerabilities with the following command:

docker scout cves timeteller

Running Docker Scout on our Timeteller image (built from a Chainguard Image) on February 18th, 2024 produced the following report:

    ✓ Image stored for indexing
    ✓ Indexed 32 packages
    ✓ No vulnerable package detected


## Overview

                    │       Analyzed Image         
────────────────────┼──────────────────────────────
  Target            │  timeteller:latest           
    digest          │  0cca410be7e4                
    platform        │ linux/amd64                  
    vulnerabilities │    0C     0H     0M     0L   
    size            │ 28 MB                        
    packages        │ 32                           


## Packages and Vulnerabilities

  No vulnerable packages detected

As you can see, no CVEs were detected in the Timeteller image at time of writing, a relatively rare outcome in the fast-paced world of container vulnerabilities and exposures. While your results with Chainguard Images won't always be this free of vulnerabilities, using Chainguard Images as your base will reduce your CVE incidence rate by 80% compared to comparable industry alternatives.

In this tutorial, you containerized a Python application with Chainguard Images in a multi-stage build process. This resulted in a runtime image with only the software components required to run our application. This focus on reducing software complexity resulted in a runtime image with a demonstrably low number of CVEs—zero in this case. Now that you understand the advantages of building your production infrastructure on Chainguard Images, you're ready to go forth and secure your own production environment.

Level up your vulnerability management skills . . . painlessly

erin glass — Wed, 14 Feb 2024 19:46:39 +0000

Turns out, vulnerabilities don't disappear if you ignore them, and regulation is catching up. If you're working in software in 2024, it's imperative to know how to manage vulnerabilities quickly and effectively. Unfortunately, according to a shocking statistic from CISA, 23 of the top 24 computer science programs don't require courses in cybersecurity.

To help the industry sharpen its vulnerability management skills, we're launching our action-packed, over-the-top course Painless Vulnerability Management with Chainguard. Free for a limited time, this course will help developers understand the landscape, tools, and practices of vulnerability management, and learn how to use Chainguard Images to make the process a breeze.

If you want to learn why vulnerability management is so critical, impress your boss or prospective employer, or simply avoid enabling the next software supply chain attack, this course is for you! We promise to equip you with all the skills you need to painlessly manage vulnerabilities, and just as many memes!

Learning Labs: How to build on Chainguard's Hardened and Minimal Images

Adrian Mouat — Mon, 29 Jan 2024 16:31:53 +0000

At Chainguard we've just launched the first in a series of hands-on Learning Labs. This series will help engineers get started on the path to low-CVE, minimal images using Chainguard base images. We're planning to run labs for various stacks, starting with images for compiled languages such as Go, Rust and C on Feb 13.

What you will learn:
💜 Why reducing the size and CVE count of images is important
💜 How to migrate a Dockerfile build using a compiled language to use Chainguard Images
💜 Advanced techniques for producing truly minimal images and debugging

📆 Tuesday, Feb 13, 2024 @ 10 am ET (click through for your TZ)
📝 Register: https://www.crowdcast.io/c/learninglabs-feb24

Get Involved with Chainguard Projects for Hacktoberfest 2023

Erika Heidi — Wed, 18 Oct 2023 15:58:33 +0000

Open source has always been at the core of what Chainguard does, which is evidenced by projects such as Sigstore and Wolfi. From image building to automated documentation, the majority of the code we write is open source, from the very beginning.

In this month of October, the Developer Enablement team at Chainguard would like to invite Hacktoberfest participants to get involved with our open source projects. We have good first issues and a welcoming team ready to help with any questions you may have.

If you're interested in containers and Linux, you may be interested in Wolfi, our community Linux undistro built for containers. We appreciate your help in keeping Wolfi-bot accountable - it doesn't always get things right 😅

If you'd like to help with documentation, we welcome your help with READMEs in the Chainguard Images repository.

Contributing to Wolfi

The Wolfi Linux undistro is an open source project primarily maintained by Chainguard, but with community contributors from all over the world. Wolfi packages live in the github.com/wolfi-dev/os repository, where we have established a thorough automation process to validate new package builds, check for available package updates, and automatically send PRs when new versions are available. In fact, the Wolfi-bot is a top contributor to the project, but it doesn't always get things right at first.

This year we invite Hacktoberfest participants to help with broken automated PRs from the Wolfi-bot.

Identifying Broken PRs

The broken Wolfi-bot PRs are easy to spot — they are tagged as automated-pr and request-update and have an red X icon next to it, indicating that one or more CI checks didn't pass. This is typically due to a build issue that needs to be manually debugged and fixed - maybe a new package version introduces a new dependency that is not met at build time, or something has changed in the make / build process for that package.

We have created a number of issues to fix these broken PRs. You can find them in the repo by searching for issues tagged as hacktoberfest.

What we expect from contributions

Choose an issue tagged as hacktoberfest from the list. Make sure to leave a comment on the issue so that others know you are working on it.
Create a new PR with your changes, so that we can tag it with the hacktoberfest-accepted label and make it a valid PR for Hacktoberfest.

Check also the Wolfi contributing guide for more information on how to get started.

Contributing to Chainguard Images

The public https://github.com/chainguard-images/images repository is an open source repository containing the configurations for all public Chainguard Images. With the number of images growing every day, it is hard to keep up with documentation needs. This year we invite Hacktoberfest participants to test our images and help update their READMEs, which are used for images documentation living in Chainguard Academy.

What we expect from contributions:

Choose one of the listed issues.
Test the image on your local environment.
Update the image README with instructions on how to use it and any other important information that you think users should know. You should follow the README template for keeping READMEs consistent.
Optionally, write a test for the image. Check the "Tests" section of our Best Practices doc for more details on how to go about that.

When you're finished, create a PR to the Chainguard Images repository with your updated README, so that we can tag it with the hacktoberfest-accepted label and make it a valid PR for Hacktoberfest.

Contributing to Chainguard Academy

You are also welcome to send documentation PRs to Chainguard Academy. Maybe you found a typo or an outdated instruction in one of our tutorials? Send a PR. Just be aware that some of those docs are automated and shouldn't be manually altered. When in doubt, create an issue first so that we can discuss.

Sending PRs to Chainguard Projects

In order to get your PRs passing CI scripts to Chainguard repositories, your commits must be signed with either Gitsign or with regular gpg signing.

Don't forget to mention the issue ID you're fixing with your PR. For Wolfi PRs, a good title could be something like "Fixing wolfi-bot update: package-name #1234" where 1234 is the number of your assigned issue. For Chainguard Images PRs, we recommend using a [Docs] prefix so that the documentation team can be assigned more quickly to review your PR.

Wolfi Swag

We value all contributors and to show our gratitude, we’ll be giving away a limited number of Wolfi swag packs. If your PR gets accepted, you may be eligible to receive one! Reviewers will leave instructions for you in the eligible PR.

If you still have any questions, don't hesitate to open an issue on the relevant repository or reach out directly on social: https://twitter.com/chainguard_dev .

Happy hacking!

Software Supply Chain Security Leadership Series: Measuring SBOM Quality

Samson Goddy — Tue, 20 Dec 2022 15:09:05 +0000

How should we think about the things that make a “software bill of materials” (SBOMs) good? In this talk, we look at the results of a recent study on SBOM quality and dig deeper into new tools that can be used to measure SBOM quality.

Join us and save your spot!

From Build to Prod: Getting Started with Software Signing and Policy Enforcement

Samson Goddy — Fri, 09 Dec 2022 15:45:26 +0000

Want to know how to get started on signing your images and commits? Secure your software from build to production and join James Strong to walk through signing images with Sigstore via Tekton chains and commits with Gitsign, all with policy enforced by Chainguard!

Be sure to register and save your spot for free!!

3 ways to improve your OSS project's resilience for Hacktoberfest

Erika Heidi — Fri, 30 Sep 2022 17:51:10 +0000

With October just around the corner, Hacktoberfest is about to start. While many developers around the world are getting ready to participate and claim their rewards, open source maintainers who opt in their projects are also busy preparing for the event. Maintainers play a very important role in Hacktoberfest each year, enabling participants to contribute by creating adequate issues, reviewing PRs, and helping out newcomers getting started into their projects.

Apart from the usual preparation tasks that focus on enabling contributors to find relevant issues they can work on, as a maintainer you can also work on a few improvements to make your project more resilient and better prepared to accept contributions from the wider community.

In this article, we'll share 3 things you can do today in order to improve your project's reliability and facilitate long-term maintenance, keeping software supply chain security in mind.

1. Set up Automated Quality Checks with GitHub Actions

GitHub Actions is a powerful feature from GitHub that allows you to set up unlimited automated workflows, given your project is open source. Actions that automatically run the application's test suite and check the code style used are ideal to be integrated into your pull request workflow, facilitating reviews and enabling contributors to get unblocked faster.

The GitHub Marketplace has a large offering of community-contributed actions for all kinds of stacks.

For instance, searching for "php" will give you quite a few different actions that can be combined in a workflow to be executed whenever a new pull request is open.

Check the documentation included with each action for more information on how to implement it on a workflow for your project.

2. Sign your Commits (and ask contributors to do the same)

Signing your commits is an important step to improve the reliability of your codebase, since it allows users to confirm that the code committed to the repository actually comes from a legitimate source. It is not very hard to forge commit authorship, especially considering typosquat attacks, where bad actors will create an account with a very similar name to your own account and set up git to use similar credentials.

So why isn't everyone signing their commits already? It has a lot to do with the difficulty in creating and maintaining GPG keypairs, which are used to generate commit signatures. Luckily for us, keyless signing (which in fact still uses GPG keys but make them invisible and ephemeral, only valid at the time of signing) is an alternative that doesn't require dealing with GPG keys.That makes commit signing a lot easier to adopt in the context of open source projects that expect contributions from the wider community.

Gitsign offers a keyless commit signing implementation based on OIDC, which is an identity layer built on top of the OAuth 2.0 framework. Gitsign supports verifying your identity either through GitHub, Microsoft, or a Google account.

For more information on commit signing and detailed instructions on how to install and set up Gitsign, check the following article:

Enable Gitsign Today and Start Signing your Commits

Erika Heidi ・ Aug 25 '22

#git #security #opensource

Don't forget to update your CONTRIBUTING docs to include information about signing commits, with links to relevant articles to help users set their local git configuration for signing. Here is an example text in markdown that you can copy and paste to your CONTRIBUTING.md page:

### Commit Signing

Please sign all your commits using either GPG keys or a keyless mechanism such as [Gitsign](https://docs.sigstore.dev/gitsign/overview/). This is important to make sure all code comes from trusted sources, which will improve the overall security and quality of our project. For more information on how to set up your local Git environment to user commit signing by default, please refer to one of the following guides:
- [Gitsign Documentation](https://docs.sigstore.dev/gitsign/installation)
- [GitHub Documentation on signing commits with GPG keys](https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits)

3. Include a Software Bill of Materials (SBOM) within your Releases

A Software Bill of Materials is a document that contains a list of all software dependencies that are incorporated into your application or container image. There are a few different formats you can use, but SPDX is generally a good choice since it is a standard maintained by the Linux Foundation.

Having an SBOM allows end-users and project leads to track all software included in the application as well as its versions. It facilitates detecting vulnerabilities within your software supply chain.

Syft is a popular open source tool that generates SBOMs for software applications and also containers. You can execute it manually and include the generated artifacts into your release, but you can also automate the process using a GitHub Action that will be triggered whenever you have a new release on your repository.

For instance, you can use the following workflow to set up Syft to automatically generate SBOM files for Composer-based projects (PHP) whenever a new release is published in your repository:

name: Generate Release SBOM
on:
  release:
    types:
      - published

  workflow_dispatch:

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v3
      - name: Install Composer dependencies
        run: composer instal --prefer-dist --no-progress
      - name: Generate SBOM
        uses: anchore/sbom-action@v0
        with:
          path: ${{ github.workspace }}

Final Considerations

The steps listed in this article may often be seen as an afterthought and not a priority for an open source project, but they certainly pay dividends in the long run. In addition to setting up a strong foundation for contributors to do their work, you'll also seize the benefits of having automated processes to help with the project's long term maintenance. By implementing these steps within your open source project, you will also be gathering valuable data that you can use later on to compare and keep track of your project's evolution, how the dependencies changed over time (via SBOMs), who are the legitimate authors of commits (via commit signing), and whether or not new contributions adhere to code standards (via CI Actions).

Container Images for the Cloud Native Era

Erika Heidi — Thu, 22 Sep 2022 13:09:07 +0000

Today is a very special day for Chainguard, as we release to the public a few projects that will lay the foundation for important improvements in the cloud-native and container ecosystems. The following announcement (video) provides an overview of these projects and how they fit together to enable safer build and runtime environments, with a focus on securing the software supply chain:

During the past few months, I have been working closely with the team that built Wolfi and Chainguard Images, testing and documenting these projects as they evolved into the version that is being released today. Some of this work is already available at Chainguard Academy, our educational hub for software supply chain resources. More to come, for sure!

In this post I'll talk a bit about these projects, how they came to be, and what they represent in the context of container images for the cloud native era.

How Wolfi was Born

A long time ago, in a galaxy far far away, some folks realized that the most popular base container images were bloated with stuff that could make sense in bare metal servers, but were totally superfluous in containerized environments. The first distroless images were developed at Google, and Chainguard's founders Matt Moore and Dan Lorenc were directly involved with the initiative.

Fast-forward to May 2022, when the Chainguard Images project was still in its first iterations. It didn't take long for the team to realize that the Linux distributions commonly used as bases for container images were not really designed for what we wanted to build. Some of the main challenges included the lag behind upstream updates, lack of provenance information, and an unnecessary increased attack surface caused by software that didn't need to be there.

The only way to solve these problems was to build a distribution designed for container/cloud native environments. So, we built Wolfi. You can read more about the design principles and decisions behind Wolfi in this blog post. The Wolfi documentation at Chainguard Academy has more context on why we call it an undistro and how it is different from other Linux distributions. In a nutshell, Wolfi is a tiny distribution that doesn't have a kernel of its own, it's designed to support both glibc and musl, and includes high-quality SBOMs (software bill of materials) covering all packages in the distro.

A Brief Look at the New Chainguard Images

Powered by Wolfi, Chainguard Images are a suite of distroless images that consolidate the base features of the Wolfi undistro into end-user container images that can be integrated into existing workflows. Chainguard Images are fully declarative and reproducible, and include SBOMs that cover all image dependencies. In addition, Chainguard Images are signed via Sigstore, which attests the provenance of all artifacts. All images and corresponding signatures, as well as their SBOMs, are hosted in Chainguard's OCI registry cgr.dev.

The easiest way to see the advantages of using a Chainguard Image instead of their traditional (or even official) counterpart is by comparing the results of security scanners analyzing those images. Here's an overview of Nginx, as an example:

On the left, you have an overview of CVEs detected by Trivy on the nginx:latest container image, from August to September. This includes low, medium, high, and critical CVEs (classified by color). On the right side, you can see the results from a Trivy run on our distroless Nginx image: zero CVEs.

But don't take my word for it; install Trivy and run the scan on your own terminal, you will be surprised with the results.

To learn more about how to get started using Chainguard Images, please visit the official documentation at Chainguard Academy.

Chainguard Academy: the one-stop resource for software supply chain security

Last but not least, Chainguard Academy comes as a one-stop educational resource to close gaps in knowledge and elevate our collective understanding about software supply chain security, approaching conceptual subjects and industry frameworks as well as technical guides and tutorials on how to get things done in practice.

It's worth noting that our knowledge base is open source and we are committed to keep iterating on it in order to provide the best documentation around the software supply chain, and the wider community is invited to propose improvements and new topics. We are still working on contributing guidelines, but they should be available soon (and in time for Hacktoberfest, dare I say!). Yay! You can find us on GitHub.

Finally, if you have any questions, feel free to join us today in a Twitter Spaces where we'll discuss all things software supply chain!