Artifact signing reduces tampering risk, but it does not solve compromised release authority. Teams need both signed artefacts and tightly governed machine identities that create them. If the publishing credential is weak, the attacker can still sign or distribute malicious content through a trusted process.
Why artifact signing is necessary but not sufficient
artifact signing answers one question well: was this artifact produced by something that held a trusted signing key at the time of release? It does not answer whether the signing path itself was trustworthy, whether the release identity was compromised, or whether the publisher had excessive standing privilege. In supply chains, those are separate controls with different failure modes.
Teams should treat signing as integrity evidence on the output, not as proof that the build, release, or publish process was clean. A malicious actor who reaches the publishing credential can still create a valid signature on harmful content, and a compromised automation path can distribute it through normal channels.
That is why the control boundary matters: CI/CD Pipeline Identity Security Guide focuses on the identities, tokens, and trust policies that make signed releases possible without turning every pipeline credential into a standing release authority.
What credential governance adds to the control stack
credential governance limits who or what can create, use, or rotate the identities behind signing. In practice, that means short-lived credentials where possible, narrow permissions, explicit ownership, and clean separation between build, test, and release authorities. The aim is to reduce the blast radius if a pipeline secret, bot token, or service account is stolen.
This is especially important because supply chains are often compromised through the control plane, not the artifact itself. Miasma and Hades Supply Chain Worms show how stolen or exposed credentials can be reused to spread through package and cloud ecosystems, while reviewdog Action compromise 2025 shows how one poisoned automation path can leak the next credential in the chain.
Good governance also means knowing which identities are allowed to sign at all. If every maintainer token can publish, or if a long-lived bot credential can both build and release, signing becomes a branding exercise rather than a trust control.
How to design the balance in practice
Use signing to make tampering detectable, and use credential governance to make release authority scarce, attributable, and revocable. Those controls should be designed together. If the signer is also the deployer, compromise of one credential can collapse the entire trust model; if signing is detached from the release path, teams can limit the damage from one stolen secret without giving up provenance.
A useful operating model is to separate build identity from publish identity, then require explicit trust policy for when a build output can be signed or promoted. SLSA is relevant here because it frames provenance as part of the supply-chain assurance story, not as a substitute for access control. OpenSSF is also useful for teams that need broader supply-chain guidance around artifact integrity and operational hardening.
When teams say they “have signing,” the key question is whether a stolen release credential could still sign or publish malicious content through a trusted pipeline. If yes, the control is incomplete even if every artifact appears properly signed.
Risk and Threat Considerations
Signed artifacts can create a false sense of safety when the release authority is weakly governed. The main risk is not just tampering with the artifact, but abuse of the trusted path that produces or publishes it. An attacker who steals a bot token, service account, or maintainer credential can use legitimate signing or release mechanisms to push malicious content that downstream systems will accept.
Failure mechanism: The signing key or publishing credential is overprivileged, long-lived, reused across environments, or reachable from a compromised build or developer context. Once stolen, it can authenticate a malicious publish or sign a poisoned release without triggering obvious integrity alarms.
Impact: Teams may distribute malware, backdoored dependencies, or altered releases under a trusted signature, extending compromise from one account or pipeline into many consuming systems. Rotation after the fact may limit persistence, but it does not undo trust damage already inherited by downstream consumers.
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 addresses the attack and risk surface, while SLSA, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | Supply-chain Levels for Software Artifacts | Artifact provenance and integrity are central to signed supply-chain releases. |
| Recommendation — Adopt provenance checks and require trusted build attestations before promotion. | ||
| CIS Controls v8 | CIS-5 — Account Management | Release and publishing credentials need tight ownership, lifecycle control, and least privilege. |
| Recommendation — Restrict, review, and revoke publishing accounts and service credentials on a regular cadence. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Governance of tokens and signing credentials depends on secure issuance, rotation, and revocation. |
| IA-9 — Service Identification and Authentication | Pipeline and automation identities are the actors that sign or publish artifacts. | |
| Recommendation — Manage release credentials with controlled issuance, rotation, and revocation procedures. Authenticate automation identities explicitly before allowing them to sign or publish releases. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Publishing bots and service accounts often hold excessive authority in release chains. |
| Recommendation — Reduce signing and publishing accounts to the minimum permissions needed for release. | ||
Practitioner Guidance
What to prioritise: Protect the release identity first, because artifact signing cannot compensate for a signer that is too easy to steal or too powerful to misuse. If you can not explain who owns the publishing credential, how it is issued, and how quickly it can be revoked, the signing program is not operationally complete.
What to verify: Confirm that signing and publishing are not performed by the same broadly scoped credential unless there is a deliberate, reviewed reason. Check for long-lived tokens, shared bot accounts, and credentials that can be used across multiple repositories or environments.
Practitioner takeaway: Treat signing as the proof of artifact integrity, but treat credential governance as the proof that release authority is bounded; both are required if you want provenance to mean more than “a compromised identity signed it.”
Related resources from NHI Mgmt Group
- How should teams separate credential hygiene from identity governance in cloud supply chains?
- How should security teams use IAST and RASP in NHI governance?
- Should organisations prioritise external exposure or internal credential governance first?
- How should security teams defend npm supply chains against credential-harvesting worms that spread through compromised maintainer access?