The latest wave of npm, PyPI, TanStack, and OIDC incidents is easy to describe as a software supply chain story. That description is accurate, but incomplete. The deeper story is that modern developer infrastructure has become one of the richest identity environments inside the enterprise.
A compromised dependency is dangerous because of where it runs. It may execute on a developer laptop, inside a GitHub Actions workflow, on a CI/CD runner, in a cloud-connected build environment, or inside a release process that is trusted to publish packages and deploy software. The package is the delivery mechanism. The real target is access.
That is why the TanStack npm supply-chain compromise matters beyond TanStack. According to TanStack’s postmortem, attackers published 84 malicious versions across 42 @tanstack/* npm packages by chaining a pull_request_target workflow issue, GitHub Actions cache poisoning, and runtime extraction of an OIDC token from the runner process. TanStack also emphasized that no npm tokens were stolen. The attackers did not need them. They abused the trusted publishing pipeline itself.
The Shift From Code Risk to Identity Risk
For years, third-party risk was mostly discussed in terms of vulnerable code. Did we import a package with a known CVE? Did our software composition analysis tool catch the vulnerable dependency? Did we patch fast enough?
Those questions still matter. But the recent npm and PyPI incidents show a different class of risk. The most damaging third-party breaches are not limited to vulnerable code that gets exploited later. They are trusted artifacts that execute immediately inside environments full of secrets.
In the TanStack case, the malicious payload targeted sensitive materials commonly found in developer and cloud environments, including GitHub tokens, cloud credentials, Kubernetes service-account tokens, Vault tokens, npm configuration, and SSH private keys. GitHub’s advisory for the incident describes the malware as exfiltrating cloud credentials, GitHub tokens, and SSH keys from systems where affected packages were installed.
This is the critical insight: the dependency is not just part of the application. Once it runs in a trusted environment, it can become a temporary identity with access to everything around it.
Trusted Publishing Did Not Fail. Trust Boundaries Did.
The TanStack incident is especially important because it challenges a comforting assumption. Trusted publishing and OIDC are often positioned as safer alternatives to long-lived publishing tokens, and they are. Removing static npm tokens is good security. Short-lived identity is usually better than a secret sitting in a vault or CI variable for months.
But trusted publishing does not magically make a build environment trustworthy. It only proves that a package was published by an authorized workflow. If an attacker gets code execution inside that workflow, the workflow’s identity becomes the target.
That is the lesson from the TanStack postmortem. The attacker did not steal a classic npm token and publish from the outside. The attacker created a path where malicious code could run inside a legitimate release context, obtain an OIDC token, and use the trusted publishing path to publish directly to npm.
This is why the industry needs to stop treating provenance as a binary signal. Provenance can tell us where a package came from. It cannot prove that the environment was clean, that the workflow was not abused, or that no secrets were exposed during the build.
PyPI Shows the Same Pattern in a Different Ecosystem
The PyPI side of the story reinforces the same point. Researchers reported a compromised version of the mistralai package on PyPI, where malicious code executed on import in Linux environments, downloaded a secondary file named transformers.pyz, and launched a credential-stealing payload. The filename appeared designed to blend into AI and machine-learning environments by resembling Hugging Face’s widely used Transformers library.
Again, the package is the delivery vehicle. The target is the environment around it. AI developers, data teams, and backend engineers often work in cloud-connected environments with API keys, notebook credentials, model infrastructure access, private repositories, and deployment secrets. A malicious import in that context is not only a code execution event. It is an identity exposure event.
This is where npm, PyPI, GitHub Actions, OIDC, and Lunar naturally connect.
The Lunar Angle: External Visibility Into Exposed Access
Lunar should not position itself as a replacement for software composition analysis, package scanning, CI/CD hardening, or GitHub security. Those tools answer one question: what code and workflows are we running?
Lunar answers the next question: what identities, credentials, sessions, secrets, and access paths connected to our organization may already be exposed outside our perimeter?
That distinction matters. A compromised package that runs inside a CI/CD workflow may leak GitHub tokens, cloud keys, SSH credentials, Kubernetes tokens, package publishing access, or SaaS credentials. Once that access leaves the environment, the problem moves from internal pipeline security to external exposure intelligence.
Security teams then need to know whether any of that access has appeared in stealer logs, Telegram channels, dark web marketplaces, paste sites, private forums, credential dumps, or other criminal distribution channels. That is where Lunar’s core value becomes part of the third-party breach conversation.
The Visibility Gap Is the Real Breach Surface
Most organizations already know that stolen credentials are dangerous. The problem is not awareness. The problem is operational visibility.
A company may have strong endpoint controls, mature SIEM coverage, enforced MFA, and a modern identity provider. Yet it may still miss early external signals that an employee, contractor, developer, maintainer, build system, or vendor-related identity is already circulating in the underground ecosystem.
That gap is especially painful in third-party incidents. By the time a malicious package is publicly disclosed, the first question should not only be “did we install it?” The next question should be “what did it have access to, and has any of that access escaped?”
That is the difference between traditional breach response and identity exposure response. Traditional response focuses on the affected package, endpoint, or workflow. Identity exposure response follows the access after it leaves the environment.
Third-Party Breaches Are Becoming Criminal Supply Chains
The supply chain metaphor is no longer only about software. It now describes the criminal economy itself.
A compromised open-source package creates execution. Execution creates access. Access becomes inventory. That inventory can be sold, traded, enriched, and routed into initial access broker markets, ransomware affiliate programs, targeted intrusions, and cloud abuse campaigns.
This is why campaigns such as Shai-Hulud matter strategically. JFrog’s research describes the campaign as affecting both npm and PyPI, with payloads designed to steal secrets from developer environments and spread through package ecosystems.
That is the real evolution. Attackers are not simply looking for vulnerable dependencies. They are looking for trusted distribution paths that place their code inside environments where credentials live. Once they harvest those credentials, they no longer need the original package compromise to continue. The stolen access can live on in a different market, under a different actor, and in a different attack.
What Security Teams Should Do Differently
The practical lesson is that third-party breach response must become identity-centric.
When a package compromise is disclosed, teams should still identify affected versions, block indicators, rebuild systems, and patch workflows. But that is only the first layer. They also need to map the identity blast radius. Which developer machines installed the package? Which CI runners executed it? Which workflows had id-token: write permissions? Which cloud credentials were reachable? Which GitHub, npm, PyPI, SSH, Kubernetes, Vault, or SaaS secrets could have been read? Which contractors or third-party environments may have been exposed?
After that, the response must move from cleanup to exposure monitoring. Rotate credentials, revoke sessions, invalidate tokens, audit recent publish events, review OAuth grants, check for suspicious repository access, and monitor external sources for leaked credentials and secrets tied to the organization.
This is the bridge between supply chain security and Lunar. The first half of the problem is internal: prevent malicious code from running in trusted environments. The second half is external: detect when the identities and secrets from those environments have already entered the attacker ecosystem.
The Future: Identity Exposure Management for Humans and Machines
The next phase of this market will not be limited to employee passwords. That category is already too narrow.
The relevant identity perimeter now includes employees, contractors, maintainers, service accounts, CI/CD jobs, OAuth grants, API keys, session cookies, cloud credentials, package publishing identities, and workload identities.
Attackers do not care whether the initial access came from a password, a browser cookie, a GitHub token, an OIDC flow, a cloud key, or a compromised package. They care whether it gets them closer to a valuable system.
Defenders need to adopt the same model. The question is no longer “was this a supply chain attack, a credential leak, or a cloud security issue?” The better question is “what trusted identity was exposed, what could it access, and how quickly can we shut it down?”
The Dependency Is the Door, But Identity Is the Prize
The npm, PyPI, TanStack, and OIDC incidents are not just warnings about open-source security. They are warnings about the way trust is delegated across modern engineering environments.
Every dependency runs somewhere. Every build runs as something. Every workflow has permissions. Every token represents trust. When attackers compromise the software supply chain, they are often trying to harvest that trust and convert it into reusable access.
That is why the Lunar story fits naturally into this moment. Lunar is not trying to scan packages or replace CI/CD security. Its role is to help organizations see the access that has escaped their control: leaked credentials, exposed sessions, compromised identities, and the broader set of human and machine secrets that define the modern identity perimeter.
The new third-party breach is not only about someone else’s code entering your environment. It is about your identities leaving it.
Previous post