Released images break downstream supply-chain safeguards: no registry publish date (breaks cooldown) + pre-releases tagged as stable

[Denny-g6labs]

Summary

We pin marble's container images in our infrastructure and guard upgrades with Dependabot's docker ecosystem, relying on a 7-day cooldown as a supply-chain safeguard (most compromised releases are caught and revoked within hours/days). A pre-release v1.2.0 was proposed for merge the same day it published, fully bypassing the cooldown. Investigating surfaced two distinct problems with how images are released from this repo — both break downstream tooling, neither is lower priority.

Affected images, verified on europe-west1-docker.pkg.dev/marble-infra/marble/:

• marble-backend:v1.2.0
• marble-frontend:v1.2.0

Problem 1 — Registry images carry no usable publish date, which breaks time-based safeguards

HEAD on the image manifest returns no Last-Modified header, and the GAR tag list reports timeCreatedMs: 0 for every tag. The OCI config created field is correct, but registries and Dependabot don't read the config blob to date a version — they rely on registry-provided timestamps.

The consequence: Dependabot (and similar tooling) cannot determine when a version was published, so a cooldown window can't be evaluated at all and is silently skipped. Any consumer trying to enforce a "wait N days before adopting" policy on these images is unprotected. This is the issue that actually broke our safeguard.

If the release pipeline can set/propagate a creation timestamp the registry will surface (or if there's a recommended GAR configuration that exposes one), that would restore time-based protection for all downstream consumers.

Problem 2 — Pre-releases are published under a plain, stable-looking registry tag

When a version is marked pre-release on GitHub (e.g. v1.2.0), the images are still pushed under a clean v1.2.0 tag with no pre-release suffix. The pre-release status lives only on the GitHub Releases page and never reaches the registry, so semver-aware tooling treats a pre-release as a stable upgrade.

Please publish pre-release builds with a semver pre-release suffix (e.g. v1.2.0-rc.1, v1.2.0-beta.1) instead of a clean v1.2.0. Standard tooling (Dependabot included) then excludes pre-releases by default unless a consumer explicitly opts in. Promoting the same artifact to the clean v1.2.0 tag on the real release keeps stable consumers correct.

Note on the release process

Since releases here merge backend + frontend and tag/publish both images, a fix in this pipeline would cover both marble-backend and marble-frontend consistently.

[Pascal-Delange]

Hi,
Thanks, I'll have a look at this.

[Pascal-Delange]

Hi @Denny-g6labs ,
We will be testing the rollout of a "-rc1" style release flow in the upcoming release cycle.

Regarding problem 1 however, GAR not returning a usable timeCreatedMs seems to be a known issue of GAR, for which we do not have a short term solution. timeUploadedMs should be present, which some tools are able to use.