Fix DSOSP blog

content/blog/docker-sponsored-open-source-program/index.md

@@ -6,7 +6,7 @@ description: In this article, we share the learnings and outcomes of the Docker
 image: score-dsosp.jpg
 author: mathieu-benoit
 ---
-As CNCF Maintainers of the Score project (CNCF Sandbox), we recently embarked on a journey to strengthen our security posture by participating in the Docker Sponsored Open Source Program. This post shares our experience, learnings, and the tangible security improvements we achieved. Our goal is to inspire others to take inspirations of these security best practices by default for their own open source projects, under the CNCF umbrella and not only.
+As CNCF Maintainers of the Score project (CNCF Sandbox), we recently embarked on a journey to strengthen our security posture by participating in the Docker Sponsored Open Source Program. This post shares our experience, learnings, and the tangible security improvements we achieved. Our goal is to inspire others to take advantages of these security best practices by default for their own open source projects, under the CNCF umbrella and not only.
 
 ## The Opportunity
 
@@ -40,13 +40,13 @@ What's interesting from here is to get more insights about the actual usage by o
 
 ## Docker Scout
 
-**Before:** Score as a CNCF project has been following the [OpenSSF best practices](https://www.bestpractices.dev/en). We also have the [OpenSSF Scorebard GitHub Action](https://securityscorecards.dev/) running continuously. That's a good start, but Score didn't have any security scanning tool per se in place before.
+**Before:** Score as a CNCF project has been following the [OpenSSF best practices](https://www.bestpractices.dev/en). We also have the [OpenSSF Scorebard GitHub Action](https://securityscorecards.dev/) running continuously. That's a good start, but Score didn't have any security scanning tool in place before.
 
 **After:** Being part of the DSOS Program gave us the opportunity to use Docker Scout in our Pull Requests and in our container registry (Docker Hub). This is a huge win for us, getting more insights about CVEs introduced or fixed by a specific Pull Request or a specific Release.
 
 The following snippet shows how we use the `docker/scout-action` step for any Pull Request, by comparing the container image from the `main` branch and the current PR's branch:
 
-```yaml
+{{< highlight yaml >}}
 - name: Docker Scout Comparison between main branch and current PR branch
   uses: docker/scout-action@v1
   with:
@@ -56,23 +56,23 @@ The following snippet shows how we use the `docker/scout-action` step for any Pu
     write-comment: true
     github-token: ${{ secrets.GITHUB_TOKEN }}
     organization: ${{ secrets.DOCKER_HUB_ORG }}
-```
+{{</ highlight >}}
 
 Here is an example of the resulting comment of this `docker/scout-action` step:
 
 ![](docker-scout-compare.jpg)
 
-We can have the details of the comparison between the two images (before versus after): size, packages updated, added or deleted, CVEs added and removed and also the compliance with our policies defined at our Docker Organization (run as non-root, no critical CVEs, no packages with AGPL v3 licences).
+We can have the details of the comparison between the two images (before versus after): size, packages updated, added or deleted, CVEs added and removed and also the compliance with our [policies defined at our Docker Organization](https://docs.docker.com/scout/policy/) (run as non-root, no critical CVEs, no packages with AGPL v3 licences).
 
-And this is not just about the container images themselves, that's also about the Go librairies used and binaries published. So insightful!
+And this is not just about the container images themselves, that's also about the Go librairies used and binaries published in these container images. So insightful!
 
-Furthermore, in the Docker Scout admin console, we are also able to get an entire holistic view of the CVEs, the packages, the base images and the policies across all our container images. It has never been so easy to find who is using what and in which version!
+Furthermore, in the Docker Scout admin console, we are also able to get an entire holistic view of the CVEs, the packages, the base images and the policies across all our container images. It has never been that easy to find who is using what and in which version!
 
 ![](scout-dashboard.jpg)
 
 ## Docker Hardened Images
 
-When [Docker made Hardened Images freely available under Apache 2.0](https://www.docker.com/press-release/docker-makes-hardened-images-free-open-and-transparent-for-everyone/), we saw an opportunity to simplify our security posture while maintaining compatibility with our existing `Dockerfiles` (we were already doing multi-stage builds and were using `distroless` base images) and workflows.
+When [Docker made Hardened Images freely available under Apache 2.0](https://www.docker.com/press-release/docker-makes-hardened-images-free-open-and-transparent-for-everyone/), we saw an opportunity to simplify our security posture while maintaining compatibility with our existing `Dockerfiles` and workflows. Even if we were already doing multi-stage builds and were using `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, featuring:
 - Minimal attack surface: Only required components are included.
@@ -87,15 +87,15 @@ For example for the `score-radius` CLI (using [dhi.io/golang](https://dhi.io/cat
 
 ![](score-radius-dhi-diff.jpg)
 
-In the associated PR [here](https://github.com/score-spec/score-radius/pull/28), we can see that 22 packages were removed (package manager and shell included) and that 2 CVEs were removed.
+In the associated PR [here](https://github.com/score-spec/score-radius/pull/28), we can see that 22 packages were removed (package manager and shell included) and that 2 CVEs were removed:
 
 ![](score-radius-dhi-scout-compare.jpg)
 
 Another example with the `sample-score-app` (using [dhi.io/node](https://dhi.io/catalog/node)), here are the updates needed on the `Dockerfile`:
 
 ![](score-sample-app-dhi-diff.jpg)
 
-In the associated PR [here](https://github.com/score-spec/sample-score-app/pull/58), we can see that 0.3MB was saved for the size while keeping the same number of packages and still have 0 CVEs. We could have stayed with `debian` but we decided to move to an `alpine` base image (DHI provides the [two options](https://docs.docker.com/dhi/core-concepts/glibc-musl/)).
+In the associated PR [here](https://github.com/score-spec/sample-score-app/pull/58), we can see that 0.3MB was saved for the size while keeping the same number of packages and still having 0 CVEs. We could have stayed with `debian` but we decided to move to an `alpine` base image (DHI provides the [two options](https://docs.docker.com/dhi/core-concepts/glibc-musl/)):
 
 ![](score-sample-app-dhi-scout-compare.jpg)
 
@@ -110,7 +110,7 @@ Not directly related to the DSOS Program, but we took the opportunity to use the
 
 **Before:** we were doing:
 
-```yaml
+{{< highlight yaml >}}
   release-container-image:
     runs-on: ubuntu-latest
     permissions:
@@ -151,11 +151,11 @@ Not directly related to the DSOS Program, but we took the opportunity to use the
         run: |
           cosign sign --yes ghcr.io/score-spec/score-compose@${{ steps.build-push-container.outputs.digest }}
           cosign sign --yes scorespec/score-compose@${{ steps.build-push-container.outputs.digest }}
-```
+{{</ highlight >}}
 
 **After:** that's what we are doing now:
 
-```yaml
+{{< highlight yaml >}}
   release-container-image:
     uses: docker/github-builder/.github/workflows/build.yml@v1
     permissions:
@@ -185,23 +185,24 @@ Not directly related to the DSOS Program, but we took the opportunity to use the
           password: ${{ secrets.GITHUB_TOKEN }}
         - username: ${{ secrets.DOCKER_HUB_USERNAME }}
           password: ${{ secrets.DOCKER_HUB_RELEASE_TOKEN }}
-```
+{{</ highlight >}}
 
 This workflow provides a trusted BuildKit instance and generates signed SLSA-compliant provenance attestations, guaranteeing the build happened from the source commit and all build steps ran in isolated sandboxed environments from immutable sources. This enables GitHub projects to follow a seamless path toward higher levels of security and trust.
 
 We still get our container images signed by `cosign`. Anyone can verify the trusted signature like this:
-```bash
+
+{{< highlight shell >}}
 cosign verify \
     --experimental-oci11 \
     --new-bundle-format \
     --certificate-oidc-issuer https://token.actions.githubusercontent.com \
     --certificate-identity-regexp ^https://github.com/docker/github-builder/.github/workflows/build.yml.*$ \
     ghcr.io/score-spec/score-compose@sha256:8dc5be472c7b71d55284451fd37d95710b10b742a6d06b79a34d70131eaaa4b4
-```
+{{</ highlight >}}
 
 ## That's a wrap!
 
-Being part of the Docker Sponsored Open Source (DSOS) Program has been so rewarding and has helped adopt a security by default foundation for the Score project. Using Docker Scout, Docker Hardened Images and the `docker/github-builder` has reinforced the security posture of our container images as well as demostrated broader benefits for the Score projects and repositories.
+Being part of the Docker Sponsored Open Source (DSOS) Program has been so rewarding and has helped adopt a security by default foundation for the Score project. Using Docker Scout, Docker Hardened Images and the `docker/github-builder` has reinforced the security posture of our container images as well as demonstrated broader benefits for the Score projects and repositories.
 
 If you maintain a CNCF project or any open source project, we highly encourage you to explore the Docker Sponsored Open Source (DSOS) Program. The security improvements we achieved were significant, and the process was straightforward.
 
@@ -211,4 +212,4 @@ Attending KubeCon EU 2026 in Amsterdam? Feel free to connect with us, [we'll be
 
 _Note: While this work was completed after I personally joined Docker, this was an initiative we wanted to pursue as CNCF project Maintainers as soon as it was [announced back in September 2025](https://www.cncf.io/announcements/2025/09/18/cncf-expands-infrastructure-support-for-project-maintainers-through-partnership-with-docker/), to improve our security posture and share best practices and learnings with the broader community._
 
-Hoping that you will be able to take inspiration of one or two tips for your own projects, cheers!
+Hoping that you will be able to take inspiration of some tools and tips shared throughout this blog post for your own projects, cheers!