How CNCF Score Improved Container Security | Docker

Secure, minimal container images for every team, free with enterprise features, if needed.
Score, a CNCF Sandbox project, recently joined the Docker-Sponsored Open Source (DSOS) Program to strengthen the security of its container images and release pipeline. In this post, the Score maintainers share what we adopted (Docker Hub, Docker Scout, Docker Hardened Images, the Docker GitHub Builder, and OIDC connections), the results we measured, and how other open source projects, within the CNCF and beyond, can apply the same practices by default.
In September 2025, the CNCF announced a partnership with Docker to expand infrastructure support for project maintainers through the Docker-Sponsored Open Source (DSOS) Program. The partnership gives CNCF projects access to Docker’s security scanning tools, container registry, and best-practice resources at no cost.
This aligned closely with the discussions held at the Maintainer Summit NA 2025 in Atlanta, which centered on increasing collaboration across CNCF projects and demonstrating security best practices.
The Docker-Sponsored Open Source (DSOS) Program supports non-commercial open source projects with Docker tooling and infrastructure.
Eligible projects receive:
Before: Score publishes different container images: the CLIs of score-compose, score-k8s, score-helm and score-radius; and the sample-score-app used for demos and testing. We previously published them in the GitHub Container Registry here.
After: Through the DSOS Program, we now publish these images on Docker Hub, which increases their visibility and gives the community a verified, trusted source.
All the container images are now available on Docker Hub.
The program also provides usage analytics that show how the community uses these images. Here is an example:
Before: As a CNCF project, Score follows the OpenSSF best practices. In addition, the OpenSSF Scorecard GitHub Action runs continuously. This was a solid foundation, but we had no dedicated security scanning tool in place.
After: The DSOS Program gave us access to Docker Scout, which we now use in our pull requests and on our container registry (Docker Hub). This gives us clear visibility into the CVEs introduced or fixed by each pull request and release.
The following GitHub Actions step uses docker/scout-action on every pull request to compare the image built from the PR branch with the one built from the main branch:
Here is an example of a comment posted by this docker/scout-action step in a recent Pull Request:
The comment details the comparison between the two images (before versus after): size, packages updated, added or removed, CVEs introduced and resolved, and compliance with our policies in place (run as non-root, no critical CVEs, no packages with AGPL v3 licences).
The analysis goes beyond the images themselves: it also covers the Go libraries and binaries they contain.
The Docker Scout console also provides a single view of CVEs, packages, base images, and policies across all of our container images, which makes it easy to see what is used where, and in which version.
When Docker made Hardened Images freely available under Apache 2.0, we saw an opportunity to simplify our security posture while staying compatible with our existing Dockerfiles and workflows, even though we were already using multi-stage builds and distroless base images.
Docker Hardened Images are minimal, security-focused container base images designed to reduce inherited risk in downstream projects. They are built and maintained with security and transparency as defaults, and offer:
The migration was straightforward.
Take the score-radius CLI, which used a golang:alpine and a distroless images and now uses dhi.io/golang and dhi.io/static images. The changes required in the Dockerfile were minimal:
In the associated PR here, image size dropped by 0.3 MB while the number of packages stayed the same and the CVE count remained at 0. We could have stayed with Debian, but chose to move to an Alpine base image (DHI provides the two options):
The same applies to the NodeJS sample-score-app, which used nodejs on top of an alpine image and now uses a dhi.io/node image. The changes required in the Dockerfile were minimal:
In the associated PR here, 22 packages were removed (including the package manager and the shell), along with 2 CVEs:
Note: We were able to present a short walkthrough of our DHI integration during the CNCF webinar held on January 23, 2026, which accompanied the Docker Hardened Images announcement for CNCF projects.
Although not directly part of the DSOS Program, we took the opportunity to adopt the new docker/github-builder GitHub reusable workflow to release our container images.
This model provides a build pipeline maintained in the Docker organization, with a version-controlled BuildKit environment, multi-platform builds distributed across runners where beneficial, and signed SLSA provenance recording both the source commit and the builder identity.
The trade-off is intentional. You retain control over when the build runs and which inputs it uses, while the build implementation itself lives in the Docker-maintained workflow rather than in per-repository job steps.
Before, the GitHub Actions workflow to release our container images was using this sequence of actions:
After, this same workflow is now only using the reusable workflow docker/github-builder/.github/workflows/build.yml:
Docker GitHub Builder gives us a Docker-maintained build pipeline with signed SLSA provenance and SBOM attestations, helping consumers verify the builder identity and trace images back to their source commit. Signing uses GitHub OIDC, so we don’t need to manage long-lived signing keys. With caching enabled in our workflow, cache entries are also signed and verified before reuse, helping protect against cache poisoning. See the Docker GitHub Builder documentation for more information about its security model.
The following command verifies the signature on the a