## 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.QUAY_USER` / `secrets.QUAY_TOKEN` (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 GITHUB_TOKEN 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 GITHUB_TOKEN to the minimum required scope.

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