Release workflow uses third-party Action pinned to mutable @master with registry credentials in scope

CWEs: CWE-1357, CWE-494, CWE-829 CVSS: 8.0 (CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H) Component: quay/quay-builder-qemu

Description The build-and-publish job logs in to quay.io with secrets.QUAYUSER / secrets.QUAYTOKEN (lines 32-37) and later invokes Noelware/docker-manifest-action@master (line 91). Pinning a third-party Action to a branch ref means the executed code is whatever the upstream maintainer (or anyone who compromises that repo) pushes next; it is re-resolved on every run. Because docker/login-action has already persisted registry credentials in ~/.docker/config.json, any code injected into the Noelware action can read and exfiltrate the Quay push token or push arbitrary images to quay.io/projectquay/quay-builder-qemu. The workflow also lacks a permissions: block, so the default GITHUBTOKEN is available to the same step.

Affected Locations - .github/workflows/build-and-publish.yaml:90-98 - .github/workflows/build-and-publish.yaml:32-37

Attack Pattern Upstream compromise of Noelware/docker-manifest-action master branch leads to exfiltration of the quay.io push token / publication of a trojaned quay-builder-qemu image consumed by all Quay build executors.

Remediation Pin the third-party Action to a specific commit SHA. Add a top-level permissions: block restricting GITHUBTOKEN to the minimum required scope.

--- Source: Ex-Wing security assessment, finding FIND-001