Who is accountable when malware is introduced through a repository or CI/CD pipeline?

Why This Matters for Security Teams

Repository compromise and CI/CD tampering are accountability problems before they are malware problems. If source control, dependency intake, build runners, and release gates are not clearly owned, an attacker can move from a single poisoned commit to a signed or automated deployment with very little friction. Current guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls and CIS Controls v8 both point to the same practical requirement: establish control ownership, enforce change integrity, and verify software provenance before release.

The hard part is not discovering that a malicious package or build step exists. The hard part is proving who had authority to approve the dependency, who could modify the pipeline, and who was responsible for stopping promotion when integrity checks failed. In practice, many security teams encounter this only after a poisoned dependency or compromised runner has already been used in a release, rather than through intentional chain-of-custody design.

How It Works in Practice

Accountability should follow the control plane, not just the application team name on a ticket. In a healthy software supply chain, source control owners govern branch protections and merge approvals, DevSecOps owns pipeline hardening and secret handling, and security or risk leadership defines the minimum release criteria. That division matters because malware can enter at several points: a compromised maintainer account, a malicious pull request, a dependency substitution, a build agent compromise, or a release artifact swap.

Practitioners should separate three questions: who can make the change, who can approve it, and who can deploy it. That distinction is especially important when the pipeline is automated, because the person who merged the code may not be the person who owns the build system or release promotion policy. A useful control pattern is to require signed commits or protected branches, dependency validation, isolated build runners, and attestations for build outputs. Provenance checks and artifact integrity verification are now common best practice, but guidance is still evolving on the exact depth of attestation required across different environments.

• Assign repository ownership to a named team with documented approval authority.
• Require review for pipeline changes, not just application code changes.
• Protect build secrets and tokens as high-value credentials.
• Block release promotion when integrity, provenance, or scanning checks fail.
• Log and retain evidence that shows who approved what and when.

Where software supply chain risk intersects with identity, privileged access becomes the control boundary. Compromised CI/CD service accounts, over-permissioned maintainers, and reused API keys can turn a routine code change into an enterprise-wide compromise, which is why identity governance and privileged access review are part of the answer, not an adjacent concern. These controls tend to break down when build systems share credentials across environments because the blast radius expands faster than approval workflows can constrain it.

Common Variations and Edge Cases

Tighter release governance often increases delivery friction, requiring organisations to balance speed against assurance. That tradeoff is real, especially for small engineering teams that rely on a single maintainer or for high-velocity product groups that ship multiple times per day. The right answer is not to remove controls, but to right-size them so that ownership is still clear and evidence is still preserved.

There is no universal standard for this yet across every build architecture. In regulated environments, the accountable party may include the product owner, platform engineering, and a formal security approver. In open-source or shared-maintainer ecosystems, accountability can be distributed, but operational responsibility for the affected deployment still sits with the organisation consuming the software. Special caution is needed when third-party actions, ephemeral runners, or containerised build environments are involved, because the attacker may only need brief control to inject malicious logic. For stronger guidance on control families and implementation expectations, NIST control baselines and CIS safeguards remain the most practical reference points.

Identity-heavy pipelines deserve extra scrutiny when non-human identities are used to sign code, fetch packages, or publish artifacts. If those identities are not governed like privileged accounts, the organisation may believe it has a secure pipeline while actually relying on unmanaged secrets and opaque automation.

Related resources from NHI Mgmt Group

• Who is accountable when a CI/CD pipeline publishes privileged changes?
• Who is accountable when a vulnerable path reaches production through CI/CD?
• How do I implement secrets scanning in a CI/CD pipeline?
• When does a CI/CD pipeline become a security risk?