Security teams should build scanning and signing into the same pipeline stage that produces the image. That keeps checks close to the artifact, reduces drift between build and security controls, and makes approval faster. Use workflow permissions deliberately, generate signatures from a trusted CI identity, and verify the signed image before deployment to preserve container integrity.
What changes when signing happens inside the build pipeline?
The main shift is that signing stops being a detached approval step and becomes part of the build artifact’s own chain of custody. That matters in GitHub Actions because the same workflow that compiles, scans, and packages the image can also create the signature, so the trust decision is tied to the exact output that will be deployed.
When teams keep signing inside the pipeline, they reduce the chance that an image is promoted before it is verified, or that a later manual process signs the wrong digest. It also makes workflow permissions, runner trust, and artifact provenance part of one control surface instead of separate handoffs.
How do workflow permissions and CI identity make this safer?
Security teams should treat GitHub Actions permissions as part of the build control, not as an implementation detail. Minimal permissions, pinned actions, and a trusted CI identity reduce the chance that a compromised workflow can mint a valid signature or publish an image under false trust. The relevant pattern is the same one used to secure CI/CD trust boundaries in general, as described in the CI/CD Pipeline Identity Security Guide.
For teams moving from static credentials to a more bounded build identity, Cloud Workload Identity Guide explains why federated, short-lived credentials are preferable to long-lived secrets. In practice, the goal is to ensure the build job can sign only the artifact it just produced, not act as a reusable publishing principal across unrelated systems.
That same trust-boundary thinking also applies to the signing material itself. The NHI Authentication Guide is useful here because CI identities are still identities, and the strongest patterns are the ones that avoid exposing reusable secrets in the workflow at all.
What should teams verify before deployment?
The important verification point is not just that an image exists, but that the exact image digest being deployed is the one that was scanned and signed in the same workflow path. That requires preserving the digest through build, scan, sign, and release, rather than allowing the release stage to resolve a mutable tag and assume it still points to the same artifact.
Teams should also verify that the signature is bound to the expected build identity and that policy rejects unsigned or mismatched artifacts automatically. This is the difference between a meaningful integrity control and a purely ceremonial signing step. The practical value of this approach is clearer when you look at the supply-chain failure patterns in GitHub Action tj-actions Supply Chain Attack and Reviewdog GitHub Action supply chain attack, both of which show how quickly trust breaks when workflow dependencies are compromised.
For container-specific hardening, NIST SP 800-190 Container Security is a strong reference because it frames image, registry, orchestrator, and runtime risk as one lifecycle. That is the right lens when build-time signing is meant to protect runtime deployment decisions.
Risk and Threat Considerations
When signing is separated from the build, attackers gain a wider window to tamper with artifacts, swap digests, or abuse a compromised workflow before trust is attached. The bigger the gap between build and sign, the easier it is for an unsafe artifact to look legitimate downstream.
Failure mechanism: Mutable tags, overbroad workflow permissions, leaked secrets, or compromised third-party actions can let an attacker alter the build path or produce a signature that no longer matches the intended image digest.
Impact: A deployment pipeline may accept an image that was never reviewed, was built from altered inputs, or was signed by a trust identity that no longer reflects the actual build conditions.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5, NIST SP 800-190 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Build and signing credentials need lifecycle control and rotation in CI workflows. |
| IA-2 — Identification and Authentication (Organizational Users) | GitHub Actions build identities must be strongly authenticated before they can sign artifacts. | |
| Recommendation — Use IA-5 to issue, rotate, and revoke signing credentials with tight lifecycle control. Use IA-2 to require strong authentication for the CI identity that performs signing. | ||
| NIST SP 800-190 | Application Container Security Guide | Container build, image, registry, and runtime integrity are the core subject here. |
| Recommendation — Apply the guide’s image and registry integrity controls to the build-sign-deploy path. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication and Access Control | Workflow access and signing authority depend on controlled CI identity and permissions. |
| Recommendation — Enforce PR.AA-05 to constrain CI access and signing authority. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | CI signing and publishing secrets are identity-bearing material that must not leak in workflows. |
| NHI-04 — Insecure Authentication | Federated CI identities and signing trust rely on secure authentication to avoid forged build authority. | |
| NHI-07 — Long-Lived Secrets | Static signing keys in CI create persistent compromise risk for artifact trust. | |
| Recommendation — Prevent secret leakage from GitHub Actions and rotate any exposed signing material immediately. Use secure, short-lived authentication for the CI identity that signs the image. Replace long-lived signing secrets with federated or ephemeral credentials. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | The build-to-sign trust chain fails if the CI identity is not authenticated correctly. |
| API5 — Broken Function Level Authorization | Workflow steps must be authorized to sign only the intended artifact and not broader release functions. | |
| API9 — Improper Inventory Management | Keeping track of which image digest was built, signed, and deployed is essential to release integrity. | |
| Recommendation — Harden authentication for the build identity that creates signatures. Authorize signing as a narrowly scoped function inside the pipeline. Maintain accurate artifact inventory so only the verified image is deployed. | ||
Practitioner Guidance
What to prioritise: Bind scan, sign, and publish to the same immutable digest, and make the deploy gate verify that digest rather than a mutable tag. If the workflow cannot prove that the signature was created by the expected CI identity for the exact artifact, treat the release as incomplete.
What to verify: Check that job permissions are minimal, signing credentials are short-lived or federated, and the runner environment cannot be reused to sign unrelated artifacts. The strongest control is one where a compromise of the build job does not automatically become a compromise of the signing authority.
Practitioner takeaway: The point is not to eliminate signing friction, it is to make signing an inseparable property of the trusted build path so integrity is enforced before an image ever reaches deployment.
Related resources from NHI Mgmt Group
- How should security teams reduce container vulnerability remediation time without adding more manual triage?
- How should security teams secure GitHub Actions runners without exposing internal services to the public internet?
- How should security teams replace risky third-party GitHub Actions at scale without creating a manual maintenance burden?
- How should security teams secure self-hosted GitHub Actions runners in Kubernetes without losing delivery speed?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
