The Urgent Question
A supply chain attack is exploiting exposed GitHub tokens, harvesting credentials and sensitive data from thousands of developer repositories. This isn't just another breach story. It's forcing your team to confront a structural question: should token and secrets management be centralized under security control, or remain federated across development teams?
Both approaches carry operational risks. Centralizing too much can slow development to a crawl. Federating too loosely can create the very exposure this attack exploits. Many organizations find themselves in a messy middle without a deliberate choice.
The Case for Centralized Control
Centralized token management places all secrets under your security team's governance. You can use a dedicated secrets vault like HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault, enforcing rotation policies from a single control plane.
The security argument is clear. Scattered tokens in repositories and developer workstations can't be audited, rotated systematically, or revoked quickly during an incident. A supply chain attack compromising one repository can harvest tokens that grant access to production environments, customer databases, and third-party services. Centralization gives you visibility and control.
Standards like ISO/IEC 27017 and NIST SP 800-53 expect organizations to maintain an inventory of cryptographic materials and enforce lifecycle management. Centralized systems simplify compliance audits by providing a single source of truth for token issuance, rotation schedules, and access logs.
From a risk perspective, centralization reduces your attack surface. You're defending one hardened vault instead of hundreds of repositories. You can enforce technical controls like short-lived tokens, automatic rotation, and just-in-time access grants. When a developer leaves or a service is decommissioned, you revoke access from one place.
The Case for Federated Ownership
Federated token management keeps secrets close to the teams that use them. Developers generate, store, and rotate tokens within their own environments. Security provides guardrails like scanning tools and policy templates but doesn't control day-to-day mechanics.
Operationally, developers need tokens to build, test, and deploy code. Centralizing token management can create bottlenecks. Every new service integration requires a ticket to security, causing delays and overhead. In fast-moving cultures, this friction drives shadow IT, where teams create their own tokens and hide them from security oversight.
Federated models distribute responsibility, potentially improving security outcomes. When development teams own their tokens, they understand the impact of a compromise and can respond faster without involving a central team unfamiliar with the architecture.
Some argue that federation aligns with DevOps principles, where teams own their full stack, including security. Centralization reintroduces silos that DevOps aims to eliminate. If you trust teams to deploy to production, you should trust them to manage their deployment credentials.
Where Practitioners Actually Land
Most security leaders adopt hybrid models. They centralize high-value secrets like production database credentials and federate lower-risk tokens like read-only API keys for development environments.
The dividing line is usually the blast radius and rotation feasibility. If a token's compromise could expose customer data or incur significant costs, it goes in the vault. If it grants access to a staging environment, teams manage it with scanning tools monitoring for exposure.
This hybrid approach requires clear policy boundaries. Define what "high-value" means, document which token types require central management, and provide teams self-service vault access for approved use cases. Without these boundaries, you risk bottlenecks and exposure.
The current attack pattern suggests centralizing GitHub tokens specifically. These tokens grant broad access to source code and deployment credentials, making them high-value secrets that need security control, automatic rotation, and strict access logging.
Our Take
Centralize tokens that can access production systems or sensitive data. Federate everything else, but ensure continuous scanning and clear escalation triggers.
Centralization does create friction, but it's manageable with self-service workflows and treating the vault as infrastructure that development teams can access programmatically. The real risk is scattered tokens in repositories. The current attack shows that exposed tokens are actively being harvested.
Your policy should specify token types requiring central management, rotation intervals, and the technical controls enforcing these policies. NIST SP 800-53 control IA-5 provides a useful baseline: protect authenticators from unauthorized disclosure and change them when compromised or at regular intervals.
The practical test is this: if a token were exposed in a public repository tomorrow, how quickly could you detect it, understand its access, and revoke it? If you'd have to ask around, you need more centralization. If you could check the vault logs and revoke it in under an hour, your model is working.
