Who should be accountable when a supply chain finding is introduced through shared repositories?

Why This Matters for Security Teams

Shared repositories blur the line between code ownership and change accountability, especially when multiple contributors, bots, and automation pipelines can write to the same branch. That matters because supply chain findings are rarely just a code-quality issue; they affect provenance, approval integrity, and the ability to prove who introduced a risky dependency, build step, or configuration change. The question is not only “what broke?” but “whose action created the exposure?”

Current guidance suggests treating repository identity, commit metadata, CI logs, and workflow approvals as a single evidence set rather than relying on team labels. That is especially important when non-human actors participate in the delivery path. The OWASP Non-Human Identity Top 10 is useful here because it highlights how machine identities, tokens, and automation paths can create gaps in accountability if they are not governed with the same discipline as human access. In practice, many security teams encounter accountability failures only after a dependency poisoning event or release rollback has already forced a retrospective.

How It Works in Practice

Accountability should be assigned to the actor who introduced the change, but that only works when the organisation can reliably attribute each repository event to a human identity, service account, or automated workflow. In practice, this means correlating source control events with identity provider logs, signed commits, pull request reviews, CI/CD pipeline records, and secrets usage. The goal is not to blame a team by default, but to preserve a traceable chain of custody from contribution to release.

For shared repositories, strong attribution usually depends on four controls working together:

• Unique identities for contributors and automation, with no shared developer accounts.
• Protected branches and mandatory reviews so no change bypasses approval paths.
• Signed commits or equivalent integrity controls to reduce spoofing and impersonation.
• Centralised logging that links repository events to IAM, PAM, and CI/CD telemetry.

The control intent is consistent with NIST SP 800-53 Rev 5 Security and Privacy Controls, especially around auditability, least privilege, and configuration control. Security teams should also distinguish between direct contributors and the operators of automation. If a bot opened the pull request, that does not remove human accountability; it shifts it to the owner of the workflow, the token, and the release governance process. Where agentic tooling is allowed to make code changes, the organisation should record which identity initiated the agent, what scope it had, and which approval gates applied before merge.

That approach also supports incident response. When a supply chain issue is found, defenders can identify whether the exposure came from an intern, a contractor, a build service, or a compromised secret. These controls tend to break down in large monorepos with loosely governed bots and overlapping branch permissions because provenance becomes too fragmented to reconstruct quickly.

Common Variations and Edge Cases

Tighter attribution often increases operational overhead, requiring organisations to balance faster delivery against stronger evidence of responsibility. That tradeoff becomes visible in fast-moving DevOps environments, where release velocity can suffer if review gates, identity checks, and workflow attestations are added without automation.

There is no universal standard for this yet when autonomous tools or shared service accounts participate in code generation, so current guidance suggests a layered accountability model. The developer or operator who authorises the workflow remains accountable for the action, while the repository and pipeline must retain enough telemetry to show what the automation actually changed. This is where identity governance intersects with supply chain security: if a token, bot, or agent can write to a shared repository, it needs explicit ownership, scope limits, and revocation paths.

Edge cases often appear in fork-based contributions, outsourced development, and emergency hotfixes. In those environments, a single “owner team” label is usually too coarse for audit because it hides who approved, who merged, and which machine identity executed the change. The safest pattern is to preserve individual accountability without losing operational context, then map that evidence back to governance duties. For shared repositories that contain regulated code or sensitive release paths, the audit trail should be treated as a security control, not just a developer convenience.

Related resources from NHI Mgmt Group

• Who is accountable when a supply chain compromise spreads through trusted credentials?
• Who is accountable when a supply chain worm spreads through developer and CI environments?
• Who is accountable when a supply chain finding is linked to a bot or workflow identity?
• Who is accountable when a supply-chain breach persists because an NHI credential survived rotation?