Both, but the governance model has to come first. Code signing lives inside the release pipeline, yet the authority to sign, approve, and revoke is an identity and access question. When those controls are split, the organisation gets automation without accountability and cryptographic trust without operational control.
Where Code Signing Belongs in the Operating Model
Code signing is not just a build-step control or a developer convenience. It is a trust decision about who may bind an organisation’s name to executable code, release artifacts, drivers, or updates. That means the signing authority, approval path, key custody, and revocation rights need governance as identities and entitlements first, then DevOps implementation on top.
In practice, the governance layer defines who can sign, under what conditions, with what approvals, and how that authority is reviewed or removed. The delivery pipeline then enforces those rules consistently, so signing becomes repeatable and auditable rather than dependent on a few trusted engineers or a shared release account.
That split matters because code signing is both an access problem and a release integrity problem. Identity governance answers who is trusted to exercise signing authority, while DevOps answers how the signing action is embedded into build, test, and release automation without weakening control.
A useful way to think about it is that governance owns the right to sign, and DevOps owns the mechanics of signing. If those are treated as the same thing, organisations often drift into either manual bottlenecks or fully automated signing with no meaningful review of privilege, ownership, or revocation.
Why Release Pipelines Still Need Identity and Access Control
Release automation does not remove the need for authority controls, it increases the blast radius of any mistake. Once a signing key or signing workflow can approve software for deployment, compromise of that pathway can turn a single stolen secret or misused credential into organisation-wide trust failure. Lifecycle management for non-human identities is relevant here because signing services, CI/CD runners, and release bots still need ownership, rotation, offboarding, and review.
Governance also has to cover separation of duties. The person who writes code should not automatically be the same person who can approve, sign, and publish it, especially where signing keys or release tokens can independently create trust for downstream users. The pipeline can enforce that separation, but the policy decision has to exist before the automation is built. IAM and IGA Basics is the clearest foundation for that model because it distinguishes authentication, authorization, entitlement governance, and lifecycle control.
Operationally, code signing should be treated like a privileged release entitlement, not like ordinary developer access. That means approval workflows, role design, and revocation logic need to be reviewable, and exceptions should be short-lived and explicitly owned. When organisations skip that step, they often discover that the pipeline is efficient but the trust model is undocumented.
How to Divide Governance from DevOps Without Breaking Trust
Use identity governance to define the signing policy set, then let DevOps implement the execution path. The governance side should determine which identities may sign, which artifacts qualify for signing, what evidence is required before approval, and who can revoke trust if a key or process is compromised. The DevOps side should make that policy enforceable through automation, logging, and constrained release tooling.
The cleanest operating model is usually: policy, approval, signing, verification, and revocation are all explicit stages. That keeps the signing authority visible to auditors and reduces the chance that a build engineer, platform engineer, or service account accumulates implicit power over the release channel. Where the organisation already runs identity reviews, the signing authority should be included in the same review cadence as other high-impact entitlements. Access Reviews and Certification Guide supports that pattern because signing rights are exactly the kind of access that should be recertified, not assumed permanent.
At the same time, DevOps teams should avoid turning code signing into a special manual exception that only one person understands. Good practice is to make the signing path reproducible, instrumented, and narrowly scoped, so the control survives personnel changes and scale. For many organisations, the right answer is a governed signing service or HSM-backed workflow with tightly managed roles, not ad hoc local signing on engineer laptops.
Risk and Threat Considerations
When code signing authority is embedded only in DevOps tooling, the main risk is control failure at scale: a compromised pipeline, overprivileged service account, or stolen signing secret can create trusted malware or tampered releases that downstream systems will accept. When the control is treated only as governance, the risk shifts to weak operational enforcement, where policy exists but signing happens through shared credentials, informal exceptions, or unmanaged keys.
Failure mechanism: The trust decision and the technical signing path diverge, so attackers or insiders can abuse the gap through credential theft, pipeline compromise, key misuse, or uncontrolled revocation delay.
Impact: Signed malicious code can look legitimate to users, endpoints, package managers, or update channels, which makes containment harder and increases the chance of broad downstream compromise.
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 NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Code signing keys and signing services need removal when owners or processes change. |
| NHI-07 — Long-Lived Secrets | Signing secrets and certificates create release trust when they persist too long. | |
| NHI-05 — Overprivileged NHI | Signing identities should not have broader release or infrastructure powers than needed. | |
| Recommendation — Remove signing access and revoke trust immediately when the signing role or owner changes. Rotate signing secrets on a short cryptoperiod and eliminate unnecessary long-lived credentials. Constrain signing identities to the minimum permissions needed to sign and attest artifacts. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Code-signing credentials and certificates need lifecycle management and rotation. |
| AC-6 — Least Privilege | Signing authority should be narrowly scoped and separated from unrelated release powers. | |
| AU-2 — Event Logging | Signing approvals and signing actions need auditable records for accountability. | |
| Recommendation — Manage signing authenticators through issuance, rotation, storage, and revocation controls. Limit signing privileges to the smallest role set that can safely sign releases. Log signing approvals, executions, and revocations with attributable records. | ||
Practitioner Guidance
What to prioritise: Treat signing authority as a governed entitlement first, then decide how the pipeline will execute it. If you cannot clearly name the owner, approver, reviewer, and revoker for the signing path, the model is too weak to trust.
What to verify: Check that signing keys, tokens, or certificate-backed workflows are tied to named roles with formal review and removal paths, not shared across teams or embedded in long-lived automation without oversight. Machine Identity, PKI and Certificate Lifecycle Guide is useful where certificate lifecycle and signing trust are connected.
Practitioner takeaway: The safest model is not “governance or DevOps”, it is governance setting the trust boundaries and DevOps enforcing them in the release path, with no signing authority that cannot be reviewed, revoked, or explained.
Related resources from NHI Mgmt Group
- Should organisations treat application authentication code as part of identity governance?
- When should organisations review external data shares as part of identity governance?
- How should organisations manage identity governance inside GRC software?
- Why do low-code workflow platforms increase identity governance risk around signing?