Basic buildpack has a health score of E on Docker Scout

[nickhammond]

I'm using Heroku buildpacks via the Pack CLI and noticed that the health score on Docker's Scout is at an E right now. I'm currently testing with a vanilla Rails(8.0.2) app(rails new).

Here's the pack command:

pack build nickhammond/eight --platform linux/amd64 --creation-time now --builder heroku/builder:24 --buildpack heroku/ruby --buildpack heroku/procfile --buildpack paketo-buildpacks/image-labels -t nickhammond/eight:81a3fa0add3ad8da67241d4be6bb679bf53da678 -t nickhammond/eight:latest --env BP_IMAGE_LABELS=service=eight --path . && docker push nickhammond/eight:81a3fa0add3ad8da67241d4be6bb679bf53da678 && docker push nickhammond/eight:latest

Fixable critical or high vulnerabilities found

Looking at the fixable CVEs, most of them are within the last two weeks and then there's one that's two months old so fairly normal.

AGPL v3 licenses found

Is this a Heroku license?

Missing supply chain attestation(s)

Is this something that can be enabled when packing the image? Or what's the best practice here?

---

Just wanted to see if this is all expected or if there are any additional steps that can be done to improve the health score. Is this the same score that Heroku would see internally as well then?

[edmorley]

Hi! We previously had Docker Scout disabled, since we didn't find it hugely reliable or helpful (results are too noisy).

We update our base-images every two weeks, and pull in all upstream Ubuntu LTS updates (and make a point of not patching the images/including custom things) - so in general if there are any CVEs then it's an Ubuntu issue, not something we have any control over.

The builder images are then built upon these base-images and also include the upstream CNB lifecycle / launcher components per the CNB spec:
https://github.com/buildpacks/lifecycle

Looking at the CVEs reported by Docker Scout now, I see the highest level one (CVE-2025-22874) is from the upstream CNB lifecycle. Sadly Golang being Golang, it quite often has minor CVEs that end up causing its statically compiled binaries to be flagged by scanners even if that particular CVE has little impact on the project in question.

We're on the latest lifecycle release, they haven't fixed it upstream yet:
buildpacks/lifecycle#1507

AGPL v3 licenses found

According to Scout this appears to be from the inclusion of Ghostscript in the images. We intentionally include those packages since some customers rely upon them, so this is operating as designed at the moment.

Missing supply chain attestation(s)

This isn't something we've looked into before. I don't know whether this is something Pack CLI supports (maybe worth checking with upstream?).

[nickhammond]

Hey @edmorley!

Thanks for the details and agreed on Scout being a little noisy for this stuff. Good to know about the lifecycle of the base image too, I figured it was all upstream and the CVE's weren't that old either.

After looking into supply chain attestations a little more, I think that will probably be outside of the pack CLI and leverage the existing SBOM commands that exist within pack CLI https://buildpacks.io/docs/for-platform-operators/how-to/integrate-ci/pack/cli/pack_sbom/.