Who is accountable when a compromised token or service account enables software supply chain abuse?

Why This Matters for Security Teams

When a compromised token or service account is used to abuse the software supply chain, the incident is rarely just a malware problem. It is usually a control failure across creation, approval, storage, and revocation. The practical question is who owned the access, who approved the scope, and who was supposed to remove it when the integration changed. Current guidance from the OWASP Non-Human Identity Top 10 treats over-privileged and poorly governed NHI as a direct risk to software delivery.

NHIMG research shows how quickly these failures become operational: the State of Secrets in AppSec found the average time to remediate a leaked secret is 27 days, even while 75% of organisations report strong confidence in their secrets management. That gap matters because the attacker does not need long access if the token already has CI/CD, package registry, or source control reach. In practice, many security teams discover the ownership gap only after the token has already been used to alter builds or move laterally through trusted automation.

How It Works in Practice

Accountability should be mapped to the control points that made the compromise exploitable. The team that created or requested the integration owns the business purpose. The platform or DevOps team usually owns the service account or token mechanics. Security owns policy, minimum standards, and review requirements. If a token is used by a build runner, package publisher, or deployment bot, the relevant identity is the workload identity, not the human who last touched the config.

That is why static IAM models fail here. A service account with standing privileges can be reused in ways the original approver never anticipated, especially when the token is embedded in pipelines or scripts. Better practice is moving toward workload identity, short-lived credentials, and runtime authorization. Standards work from the OWASP Non-Human Identity Top 10 and NHI breach analysis in 52 NHI Breaches Analysis both show that standing secrets and weak revocation are recurring root causes.

• Assign an explicit owner for each token, service account, and CI/CD identity.
• Use short TTLs and just-in-time issuance where possible, rather than long-lived static secrets.
• Require approval for privilege expansion and document the business justification.
• Log issuance, use, and revocation so ownership can be reconstructed after an incident.
• Revoke access automatically when the integration is retired, rotated, or repurposed.

For implementation detail, NIST control guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls supports least privilege, account management, and auditability, while the Salesloft OAuth token breach shows how an integration token can become a supply chain bridge into downstream SaaS. These controls tend to break down when secrets are copied into build scripts, cached in runners, or shared across environments because revocation then becomes partial instead of immediate.

Common Variations and Edge Cases

Tighter token governance often increases delivery overhead, so organisations have to balance release speed against blast-radius reduction. That tradeoff is real, especially in complex ecosystems with many vendors, ephemeral pipelines, and shared automation.

There is no universal standard for assigning accountability in every supply chain scenario. When a token is issued by a third-party platform, the vendor may control the mechanics, but the integrating team still owns the decision to grant access. When a service account is reused across multiple repositories or environments, accountability becomes shared and harder to prove, which is why current guidance suggests separating identities by purpose and environment wherever feasible.

Edge cases appear in multi-team platforms, delegated admin models, and agentic automation. If an AI agent or workflow can request secrets on demand, the question shifts from who held the token to who approved the policy that allowed runtime access. The State of Secrets Sprawl 2026 highlights that secrets now leak outside code repositories as well, including through collaboration tools and AI infrastructure, so ownership must extend beyond source control. Best practice is evolving toward continuous attestation, explicit revocation duties, and incident-ready records of who approved what, when, and why.

Related resources from NHI Mgmt Group

• Who is accountable when exposed secrets are found in public workflow logs after a supply chain compromise?
• When does a service account become a compliance problem?
• Why do service account and maintainer tokens increase supply-chain risk?
• Who is accountable when a package token is abused in a supply-chain attack?