Who is accountable when a signed release contains malicious code?

Accountability sits with the organisation that issued and governed the signing authority, not just the developer who pushed the code. If keys, approvals, or audit trails were weak, the release process itself failed. That is why PKI, IAM, and DevSecOps ownership must be coordinated before incidents occur.

Why This Matters for Security Teams

A signed release is not a trust signal by itself. It proves something was signed, not that the signer was entitled to ship it, that the build environment was clean, or that the release process enforced meaningful separation of duties. When malicious code makes it into a signed package, the failure is usually organisational: compromised keys, weak approval workflows, poor provenance, or missing release governance.

That distinction matters because incident response will quickly shift from “who wrote the code” to “who controlled the signing authority.” Security teams should treat code signing as part of a broader trust chain spanning identity, build integrity, and release approval. The NIST Cybersecurity Framework 2.0 stresses governance and protective controls across the lifecycle, not just at the point of deployment, and NHIMG research on the State of Secrets in AppSec shows how weak secrets hygiene and fragmented control can erode that chain before release.

That same pattern appears in the Reviewdog GitHub Action supply chain attack, where trust in automation did not prevent exposure once the surrounding controls failed. In practice, many security teams encounter accountability breakdowns only after a signed artifact has already been distributed to customers.

How It Works in Practice

Accountability for a maliciously signed release should be assigned to the organisation that operated the signing system, not treated as a narrow developer defect. The practical question is whether the release pipeline enforced identity, authorization, provenance, and auditability at each step. If a release was signed by a compromised key, by an overly broad service account, or through a process that lacked required approvals, the control failure sits with the operator of that system.

Practitioners usually need to examine four layers:

• Who controlled the signing key or certificate, and how it was protected.
• Whether the signer had just enough authority for that specific release.
• Whether build provenance, attestation, and review records match the signed artifact.
• Whether logs show who approved, who signed, and what changed immediately before publication.

This is where NIST guidance and supply chain controls converge. The NIST Cybersecurity Framework 2.0 supports governance, access control, and recovery planning, while the DeepSeek breach illustrates how exposed credentials and unmanaged release paths can turn trusted systems into distribution channels for malicious content. The release process should therefore use tightly scoped identities, protected signing hardware or managed key stores, immutable logs, and dual approval for high-risk artifacts. Where possible, signatures should be paired with provenance records so downstream consumers can verify both origin and integrity, not just authenticity.

These controls tend to break down when signing is automated through shared CI credentials with no human approval boundary, because the same identity can build, approve, and publish without meaningful separation of duties.

Common Variations and Edge Cases

Tighter release control often increases operational overhead, requiring organisations to balance shipping speed against the assurance needed for signed software. That tradeoff becomes sharper in fast-moving DevOps environments, where teams may rely on short-lived keys, ephemeral runners, and automated approvals.

There is no universal standard for this yet, but current guidance suggests treating the following cases differently:

• If a private signing key was stolen, accountability extends to key custody, rotation, and detection failures.
• If an approved maintainer knowingly introduced malicious code, accountability may be shared between the individual and the organisation’s governance model.
• If a third-party build or signing service was used, contractual and technical responsibility still remains with the releasing organisation.
• If a software update was repackaged downstream, consumers may need to distinguish between original compromise and local redistribution risk.

Security leaders should also remember that signed does not always mean safe. Signatures can be replayed, keys can be abused, and release pipelines can be subverted after legitimate code review has ended. The safest operating model pairs code signing with strong identity governance, secrets protection, and release attestation, rather than assuming the signature alone settles trust. This is especially important in ecosystems where downstream distributors rely on upstream trust without independently validating the release chain.

Related resources from NHI Mgmt Group

• Who is accountable when a shared device is lost or left signed in?
• Who is accountable when malicious code enters through a package registry?
• Who is accountable when a GitHub Actions workflow exposes secrets or pushes malicious code?
• Who is accountable when a signed release is later found to be untrusted?