Patch
A pinned container image can still be produced by an unpinned build dependency. That is the kind of supply-chain gap that looks small in YAML and large in production.
CVE-2026-85469 is a useful example: a Red Hat Quay publishing workflow referenced a third-party GitHub Action through `@master`, so the code executed during a release could change upstream without a corresponding change in the Quay repository. Because the Action ran after registry authentication, the trust decision extended directly into the publishing boundary.
The operational problem is bigger than one Action reference. Many teams review Dockerfiles, image digests, and registry permissions carefully while treating CI helpers as implementation detail. In reality, any external code that runs inside a credentialed release job is part of the production security boundary.
**In practical terms, it is a good time to:**
- search workflow files for third-party Actions referenced by branches or movable tags instead of full commit hashes
- identify jobs where external Actions execute after registry login, cloud authentication, or signing-key access
- add explicit GitHub Actions `permissions:` blocks and compare them with the capabilities each job actually requires
- review Quay or other registry push history, image digests, and release timestamps for changes that do not map to approved builds
How many CI dependencies in your environment receive the same scrutiny as the packages they eventually publish?
#LinuxSecurity #SupplyChainSecurity #DevSecOps #ContainerSecurity #OpenSource https://linuxsecurity.com/news/security-vulnerabilities/red-hat-quay-build-workflow-credentials-risk
Post summary
The post explains CVE-2026-85469 as a supply-chain vulnerability in Red Hat Quay caused by unpinned GitHub Actions and provides concrete mitigation recommendations such as pinning Actions, reviewing post-authentication jobs, and tightening permissions.
