How Supply Chain Attacks Turn Into Identity Risks
Supply chain attacks are no longer a rare threat. They are becoming a standard tactic for modern attackers. But what does "software supply chain" actually mean?
Modern software is not built from scratch. It is assembled using pre-made building blocks, often referred to as open-source dependencies. For instance, a developer building a data analysis tool in Python will not write every line of code themselves. They will import established libraries like Pandas for data or Requests for web communication. Every time that code runs, those imported libraries run too. When those libraries are updated, the new versions are automatically pulled into the environment.
The Ripple Effect: In a supply chain attack, the developer of the tool is rarely the final target. The real goal is the end user who eventually runs that tool in their environment. In this scenario, the supply chain is the entry, and infostealing is the objective. Think of it like a physical office building that uses external vendors for cleaning, security, and catering. If a threat actor steals a vendor’s keycard, they do not just have access to the vendor’s van; they have a way inside your entire building.
How it Works: A software supply chain attack piggybacks on the trust you place in third-party software to bypass your perimeter. Once inside, the compromise usually delivers a payload: a hidden piece of code designed to scan your network for user credentials, access tokens, API keys, and cloud permissions. By the time the alarm sounds, the attacker may already have the keys to your most sensitive resources.
The Mechanics of the Trivy and LiteLLM Compromises
Late February – The "Pwn Request": A Trivy GitHub Actions workflow was misconfigured to use pull_request_target trigger in combination with a checkout action on the incoming PR branch. This is the known "Pwn Request" pattern. It allowed a threat actor, 'hackerbot-claw', to submit a malicious PR. Because of the misconfiguration, the workflow automatically checked out the untrusted code into a context where it had access to privileged secrets (the PAT) and executed it with repository-level permissions. The attacker successfully exfiltrated a Personal Access Token (PAT), which had write access to over 33 repositories within the Aqua Security GitHub organization. Aqua Security rotated credentials but the attackers retained access.
March 19 – Tag Poisoning: Using retained credentials and the compromised aqua-bot service account, TeamPCP compromised the trivy-action repository by force-pushing 75 version tags to a malicious commit. This commit was configured to execute a compromised Trivy binary before the legitimate scan could run, affecting any pipeline referencing trivy-action via those tags.
The malware searched the memory and filesystem locations for credentials like SSH keys, cloud credentials, and Kubernetes tokens. The attackers exfiltrated it to the typosquatted domain scan.aquasecurtiy[.]org. As a fallback, the malware used the victim's own GitHub PAT to create a public repository and uploaded the stolen data in it. Unlike its behavior in CI environments, the binary established persistence on developer machines by installing a service that contacted a C2 server for instructions.
March 24 – LiteLLM Downstream Compromise: LiteLLM used Trivy as a security scanner in its build process. Its workflow referenced the poisoned tags from the trivy-action repository rather than pinning through full commit SHAs. This allowed the runner to pull the malicious Trivy binary, leading to the exfiltration of the PyPI publishing token. The attacker could then bypass official CI/CD workflows and upload malicious packages directly to PyPI. The data was exfiltrated to checkmarx[.]zone and models.litellm[.]cloud, lookalike domains registered just one day before the packages appeared on PyPI. As a popular LLM router library used by thousands of enterprises, LiteLLM’s compromised PyPI releases allowed attackers to exfiltrate LLM provider API keys directly from the environments of its users.
Exfiltration: Credential Harvesting and Infostealing
In the Trivy compromise, the malware swept over 50 hardcoded filesystem paths and scraped Runner. Worker processed memory to harvest SSH private keys, AWS, GCP, and Azure access tokens, Kubernetes service account tokens and kubeconfig files, Docker registry credentials, GPG keys, cryptocurrency wallet keys, and .env files containing application secrets. All collected data was encrypted before exfiltration. During the LiteLLM compromise, the malicious payloads executed the same infostealer payload, with the added exposure of LLM provider API keys.
Key Learnings
Comprehensive Vetting of Open Source Dependencies
- Establish an open source dependency review process that evaluates and approves components before they enter the trusted software supply chain. The tagged and versioned dependencies should be kept in an internal local repository. Pipelines pull only from it and never directly from public registries like PyPI or npm.
Hardening the CI/CD Pipeline
- Principle of least privileges should be applied to every credential used in a pipeline. Each should carry only the permissions required for its specific operation and nothing broader.
- Segregate credentials based on privileged actions. Credentials needed to pull code should be entirely separate from those needed to push tags, publish packages, or write to registries.
- Secrets must never be hardcoded into build artifacts. They should be fetched dynamically from a dedicated manager at runtime rather than being injected broadly as static environment variables.
- A better solution for organizations is to transition to OpenID Connect (OIDC). OIDC replaces long-lived, static credentials (like PATs or AWS Access Keys) with short-lived, identity-based tokens that expire automatically.
- Pipelines must reference dependencies using full commit hashes rather than version tags. Tags are mutable – an attacker with repository access can silently force-push a tag to point to malicious code. A hash is immutable – it references one specific version of code that can never be changed.
- The use of pull_request_target trigger should be avoided whenever possible (refer to the “Pwn Request” described above). If it must be used, it should be strictly limited to trusted sources.
SBOM Generation and Tracking
- Configure pipelines to generate a software bill of material (SBOM) for every build, capturing the exact version and cryptographic hashes of all direct and transitive dependencies. These SBOMs must be included in the vulnerability management programme. Knowing exactly what is running in every environment aids faster response from security teams.
Balancing Convenience and Security
- Any compromise is usually enabled by "convenience defaults" – choices that prioritize ease over security. The Trivy and LiteLLM compromises, for example, were aided by the following:
- Unpinned dependencies
- Automated pipelines that execute external code without verification
- Broadly scoped credentials
- Credential reuse across workflows
- High-risk operations (publishing a new package version, promoting a release to a production registry) executed without manual gates
How to Address These Threats
The Trivy and LiteLLM compromises demonstrate a hard truth: once an attacker harvests valid credentials or session tokens, they no longer need to break in or bypass a second factor – they simply start using them.
If your organization falls victim to credential harvesting or infostealing malware, the immediate priority is mapping your exposure and limiting the blast radius. Because attackers using valid credentials appear to be legitimate users, stopping them requires a deep understanding of behavioral baselines and total visibility across your ecosystem.
WideField provides this essential layer through Identity Threat Detection and Response (ITDR) across your IdP, SaaS, and IaaS environments by:
- Establishing Behavioral Baselines: Activity baselines considering typical operations, frequency, browser/OS signatures, and geographic locations serves as a reference, allowing for the instant flagging of anomalies that deviate from established behavior.
- Centralizing Identity Visibility: An inventory of identities, credentials, and active sessions in one place. Knowing exactly which identity is logged into which service provides the necessary foundation for rapid incident response and effective credential rotation.
In a world where credentials are the primary target, visibility is your strongest defense.
