Who is accountable when a malicious dependency commits changes back into a victim repository using a forged identity?

Why This Matters for Security Teams

When a malicious dependency can push changes back into a repository while appearing to be a trusted contributor, the problem is no longer limited to package hygiene. It becomes an integrity and accountability issue across the software supply chain, because forged identity can bypass human assumptions about authorship, review, and provenance. Security leaders should treat this as a control failure that touches source control, CI/CD, and identity governance together. NIST SP 800-53 Rev 5 Security and Privacy Controls is a useful baseline for mapping those responsibilities into access control, audit logging, and system integrity expectations.

The practical risk is that a repository may accept code or configuration changes because the commit appears to come from a known maintainer, service account, or automation identity. That is especially dangerous when branch protections are weak, signing is optional, or dependency update workflows are over-privileged. In those conditions, forged identity becomes a delivery mechanism for tampering, not just a social engineering detail. The accountability question matters because each team often assumes another owns the gate, which leaves gaps at the exact point where code trust should be strongest. In practice, many security teams encounter this only after a suspicious commit lands in a protected branch and the trail back to the original dependency has already been obscured.

How It Works in Practice

In real environments, a malicious dependency may exploit automation that is designed to be helpful, such as update bots, build agents, or repository write tokens. If that automation trusts package metadata, commit author fields, or loosely verified identities, the attacker can cause changes to be committed into the victim repository under a forged or abused identity. The key issue is not whether the change was human-written or machine-generated, but whether the repository accepted it without strong provenance and authorization checks.

Security teams usually need to address four layers at once:

• Dependency intake controls that vet packages, maintainers, and update channels before code reaches the build.
• Identity controls that require strong proof of authorship, not just a commit email or display name.
• Repository protections that enforce review, signing, and branch restrictions for any automated write path.
• Detection and response controls that correlate source control events, CI activity, and identity telemetry.

For identity-sensitive workflows, the relevant question is whether the write operation is tied to a real, governed identity or to a token, bot, or service account with excessive privileges. This is where NHI governance intersects with software supply chain security: non-human identities must be inventoried, scoped, rotated, and monitored like any other privileged actor. MITRE ATLAS is more focused on adversarial machine learning, but the same supply-chain logic applies to trust boundaries, while NIST Cybersecurity Framework 2.0 helps teams map the issue into governance, protect, detect, and respond activities. If Git hosting, artifact registries, and CI runners are all loosely coupled, the control story breaks down and forged commits can appear legitimate long enough to be merged and deployed. These controls tend to break down when automated dependency tooling is granted repository write access in organisations that do not centrally govern service accounts, token scope, and commit-signing enforcement.

Common Variations and Edge Cases

Tighter commit governance often increases friction for developers and release automation, requiring organisations to balance delivery speed against provenance assurance. That tradeoff is real, especially in fast-moving engineering environments where dependency updates and patching are frequent.

There is no universal standard for how much trust should be placed in commit author metadata alone. Current guidance suggests that author identity should be treated as weak evidence unless it is reinforced by signed commits, protected branches, controlled tokens, and separate verification of the automation identity that performed the write. In some repositories, the more important issue is not forged identity in the commit itself, but compromised credentials on a bot account that legitimately has write permissions. In others, the critical weakness is an upstream package maintainer account that has been hijacked, allowing malicious update logic to propagate downstream.

Teams should also distinguish between code provenance and human accountability. A developer may approve a pull request, but platform engineering may own the branch protections, while security owns the policy for dependency trust. If the organisation uses service identities for package updates, those identities need the same lifecycle controls as any privileged account, including ownership, revocation, and auditability. For implementation guidance, NIST SP 800-53 Rev 5 Security and Privacy Controls remains a strong reference point for control mapping, while NIST SP 800-207 Zero Trust Architecture is helpful where repository and CI trust should be explicitly revalidated rather than assumed.

Related resources from NHI Mgmt Group

• Who is accountable when malicious identity changes are restored too slowly?
• Who is accountable when a cloud identity can both approve and execute changes?
• Who is accountable when an AI agent exposes credentials or changes identity state?
• Who is accountable when an AI assistant follows malicious repository instructions?