A cardinal sin in cyber. Inexcusable. Born out of mediocrity.

Executive Summary

In March 2026, a supply chain attack on LiteLLM, a popular AI development library downloaded millions of times daily, turned developer machines into systematic credential-harvesting operations. The malware only needed access to plaintext secrets already in the open. Over 1,700 other packages were caught in the blast radius.

The noise and panic which I explored recently, surrounding the Claude Code leak and Claude Mythos, must not diminish the systemic failures that made this LiteLLM attack possible, as evidenced by GitGuardian ‘s analysis [The Team PCP Snowball Effect: A Quantitative Analysis]. Very few have stopped to ask why it succeeded. That question matters far more than the headlines.

This is not a new problem. Cyber practitioners know better. Most just do not act on it. Credentials are still scattered across developer machines, build pipelines, configuration files, and AI agent directories. Unaudited, unrotated, and unprotected.

A Personal Note: I have been in the mud fixing exactly this: pushing through bureaucracies, making the case to leadership, resolving under pressure, addressing the core failures, striving for regulatory compliance one hard-fought step at a time.

The solutions have existed for years and the tools are commercially available. Examples: HashiCorp Vault, CyberArk, Amazon Web Services (AWS) Secrets Manager, Microsoft Azure Key Vault, Google Cloud Secret Manager, GitGuardian, Gitleaks, GitHub Advanced Security, OIDC federation.

The technology is ready. What is almost absent is the management priority and the governance mandate to enforce change.

This article reflects my first-hand experience. Root cause, real exposure, and a practical path forward, for both leadership and engineering teams. And it makes the case for a board-and-management mandate on credential security management even more urgent.

The Problem: A Master Key, Left on the Table

Every organisation that builds or runs software has a master key problem. The passwords, cloud access tokens, and digital keys that unlock its sensitive systems are scattered across dozens of locations. Most have never been catalogued. Almost none are properly secured.

How they get there is predictable. Credentials dropped into .env files for convenience. API keys pasted into terminal commands and left in shell history. Secrets committed to version control because the deadline was tomorrow. Build pipelines carrying stored credentials set up years ago, never rotated, never questioned. AI agent tools adding their own credential stores in predictable locations. None of it is malicious, yet alarming.

Credential harvesting malware does not need to be sophisticated. It just needs a list of file paths to read: ~/.aws/credentials, ~/.docker/config.json, .env files, shell history, IDE directories, CI/CD variable stores, agent memory files. All well known. All consistently populated.

Why Nobody Has Fixed It Yet

The solutions are mature, commercially available, and widely deployed at leading organisations. For most others, there is no board-level attention, no management priority, inadequate governance, and possibly an inability to grasp the problem itself. Security teams flag the risk. Leadership acknowledges it. It gets logged and deprioritised. Nobody is held accountable.

The hand-washing analogy fits in nicely here. Hospitals knew hand-washing prevented patient deaths. The solution cost almost nothing. People died anyway because there was no mandate. Credential security is at exactly that inflection point. The knowledge exists. The tools exist. What is missing is the will to enforce it.

What Is At Stake

A single stolen cloud access key can generate hundreds of thousands of dollars in fraudulent infrastructure charges within 24 hours. That is before any data is touched. A credential used to access and encrypt production systems can trigger recovery costs running into millions.

A credential breach triggers mandatory GDPR notification within 72 hours and fines of up to 4% of global annual revenue. Regulators and courts increasingly examine whether boards were informed and took reasonable action. Personal liability for executives and directors is a real consideration. Organisations that have disclosed credential breaches have seen customer churn, extended sales cycles, and significant insurance premium increases.

The Most Uncomfortable Truth: Once a credential is in the wrong hands, every other security investment becomes irrelevant. Firewalls, intrusion detection, zero-trust architecture. All of it becomes background noise the moment an attackers authenticate with valid credentials. They do not break anything. They simply log in.

What Leadership Must Do

This problem cannot be solved from within an engineering team. It requires a mandate, a budget, and accountability from people who set priorities and allocate resources.

  1. Acknowledge this as a material risk. Not a low-level technical issue. A board-level governance matter with direct financial, regulatory, and reputational exposure.
  2. Mandate a programme with a named owner, a budget, and quarterly reporting. Without this, it will be deprioritised again.
  3. Demand a credential audit within 30 days. You cannot manage what you have not measured. Most organisations have never inventoried where their credentials live.
  4. Make compliance non-negotiable. Technology controls must be paired with accountability.

Investment

Size it from the inside out. Start with your application count, developer headcount, and existing tooling maturity. Factor in AI-assisted detection and automated pipeline tooling, which can materially accelerate remediation. Factor in your team’s prior experience with vault technology. Build the estimate from those inputs and compare it to what one significant breach would cost you. The investment case makes itself.

How Credentials End Up Everywhere

The problem is structural, not behavioural. You cannot fix this by asking developers to be more careful. The lifecycle is predictable: a credential created for a legitimate reason, committed to version control, spread across pipelines and scripts, rotated in production but not cleaned up elsewhere. Months later, nobody knows it exists. No inventory. No owner. No expiry. An attacker finds it and uses it.

Three Master Keystrokes: An Architecture That Washes Away the Cardinal Sin

There is no single product that solves this. There is an architecture built on three complementary controls.

Master Keystroke 1: A Centralised Secrets Vault

A vault replaces distributed plaintext credential storage with a centralised, encrypted, access-controlled system. Applications request credentials from the vault at runtime rather than holding them locally. Every access is logged. Rotation is automated. A stolen credential that has already expired is worthless. Investigate these tools.

Master Keystroke 2: Continuous Credential Scanning

Even with a vault in place, credentials will occasionally end up in the wrong place. Continuous scanning catches them before attackers do. Detection without a remediation workflow is just noise. Investigate these tools.

Master Keystroke 3: Short-Lived Credentials and Keyless Authentication

The most effective long-term control is eliminating the value of stolen credentials by making them expire in minutes. Investigate these tools.

Optional Extra: Honeytokens

Honeytokens are decoy credentials planted where attackers expect to find real secrets. They look authentic but provide no access. When an attacker uses one, an alert fires immediately, compressing detection time from weeks to minutes. National Institute of Standards and Technology (NIST) recognises it under SP 800-53 Rev 5, SC-26 (Decoys).

Boosting Control Maturity with Proper Governance

Technology without governance fails. Every credential needs a named owner. Every employee departure must trigger immediate credential revocation. Pre-commit hooks should block secrets from entering repositories as an enforced control, not a suggestion.

Most developers know that storing passwords in plain text is wrong. They do it because the proper approach takes longer and currently carries no consequence. Remove those conditions. Behaviour follows.

Conclusion

We are past the point where this can be attributed to ignorance. The LiteLLM supply chain attack is not a wake-up call. It is the latest in a long series of incidents making the same argument with increasing force.

What is missing is the willingness to treat this as the governance priority it is, rather than a technical backlog item that perpetually loses to feature delivery.

The organisations that survive the next supply chain attack will be the ones that stopped waiting for a reason to act. They had the reasons. They acted on them.

Sources and Further Reading

The Trigger

Research and Evidence

Vault and Secrets Management

Credential Scanning

Keyless Authentication

Honeytokens

About the author

Viren Mantri is a cybersecurity advisor and former senior technology leader across Standard Chartered, UBS, McAfee, and KPMG. With 30 years of navigating the intersection of technology, risk, and regulations, he now helps organisations cut through complexity and make better security decisions.

CC-BY Viren Mantri, 2026, licensed under a Creative Commons Attribution 4.0 International License.

Disclaimer: All views expressed here are entirely mine.