How attackers turned NPM’s trust system against it

npm’s sigstore verification process was bypassed

Automation in security is powerful, but it’s not infallible. On May 19, attackers penetrated npm’s trust system by using a compromised maintainer account to generate valid signing certificates. The system verified everything, the code build, the signing certificate, the provenance record. Unfortunately, it couldn’t verify intent. In total, 633 malicious package versions passed verification and entered the supply chain, fully trusted by developers and systems that rely on Sigstore’s green badge.

This was not a software bug; it was a design failure. Sigstore did its job but lacked what we might call situational awareness—it verified the package but not the identity behind it. The trust model assumed that a valid certificate equals a legitimate author, which is no longer enough in an era of credential theft.

Executives need to absorb the real takeaway here: automation cannot replace human-level verification without deeper identity safeguards. Systems must evolve to verify authorization—not just cryptography. It’s no longer about proving a signature; it’s about proving that the right person actually approved the action. In the modern developer supply chain, where attackers can generate legitimate credentials from stolen tokens, verification must move from static checks to behavioral and contextual validation.

According to Endor Labs and Socket, this campaign eventually involved more than 1,055 malicious versions across 502 packages distributed across npm, PyPI, and Composer. The problem spans ecosystems, not just one platform. If your business depends on open-source components, it depends on a fragile trust model that needs urgent reinforcement.

Stolen credentials in developer tools enabled widespread supply chain compromise

Credential theft is becoming the fastest route into the software supply chain. StepSecurity reported that attackers published a malicious update to the Nx Console Extension for Visual Studio Code, used by millions of developers worldwide. The compromised version harvested sensitive information, including GitHub tokens, AWS keys, and even 1Password vault data. It was active for less than an hour but still reached nearly 6,000 installations because of its auto-update feature.

It’s a sharp reminder that real-world attacks no longer need prolonged exposure. The speed and automation of developer tools amplify everything, successes and failures alike. Once an update goes live, auto-update mechanisms can distribute compromised code before any human detection. The Mini Shai-Hulud campaign pushed this further by reviving long-dormant npm packages that appeared to be normal updates. Many detection systems missed these changes simply because they weren’t designed to question why a package that was silent for years suddenly came alive.

For leaders, the takeaway is strategic. You can no longer rely solely on vendor-provided security guarantees or marketplace validation processes. The attack surface begins long before a product hits production, it begins in the developer’s environment, in the CI/CD pipeline, and in every automatic handshake that verifies software without human review.

StepSecurity’s analysis shows how attackers are exploiting automation itself. Speed, once the competitive advantage of software development, has become a weapon in their toolkit. To stay ahead, organizations must balance rapid development with strong credential controls, strict extension policies, and immediate response mechanisms. Speed still matters, but controlled speed matters more.

Systemic failures in developer tool verification exposed by multiple research teams

The recent investigations across the software ecosystem made one thing clear: verification frameworks are failing at scale. Research from Endor Labs, Socket, StepSecurity, Adversa AI, Johns Hopkins University, Microsoft MSRC, and LayerX exposed weaknesses across seven distinct layers of the developer tool chain. Their findings revealed failures in provenance verification, extension credential safeguards, CI/CD pipeline integrity, agent frameworks, and even integrated development environment (IDE) storage practices.

Each discovery came independently, yet all pointed to the same weakness, trust systems that operate in isolation. Tools verify what they are built to see, but none have visibility across all failure points. This fragmented design leads to false confidence. A developer or enterprise may assume that seeing a “verified” badge or passing a vulnerability scan means a system is secure. In reality, no single framework has the full picture, and attackers exploit this lack of cohesion.

Executives should consider this a wake-up call for governance and internal verification strategy. The traditional practice of relying entirely on vendor assurances or discrete audits is insufficient. Security performance must be measured across every layer of the build and deployment process. Organizations need continuous and holistic auditing, with accountability distributed across vendors and internal security teams alike.

Johns Hopkins researchers Aonan Guan, Zhengyu Liu, and Gavin Zhong showed how a small but overlooked process flaw in automated workflows could expose API keys through AI tool interactions. Their work, alongside that of commercial research teams, demonstrates how academia and industry can uncover systemic risk, but also how fragmented verification leaves enterprises vulnerable to multi-surface exploitation.

The underlying message is direct: technical compliance is not the same as operational security. For enterprise leaders, strengthening verification models means investing in integrations that expose blind spots between vendor systems. This is not about acquiring new security tools; it’s about building cross-system visibility and eliminating the assumption that a single layer of defense is enough.

Developer AI coding tools contain critical trust and execution vulnerabilities

AI-based coding tools have revolutionized software creation, but they have also introduced new classes of vulnerabilities. Research from Adversa AI, Johns Hopkins University, Microsoft MSRC, and LayerX revealed that these tools, while intelligent, often run on insecure trust architectures. Adversa AI’s TrustFall report showed that popular developer assistants such as Claude Code, Gemini CLI, Cursor CLI, and Copilot CLI automatically execute project-defined MCP servers once a developer accepts a folder trust prompt. In nearly all cases, these prompts default to “Trust,” silently giving full system privileges to unvetted code.

On top of this, Johns Hopkins researchers uncovered that a single malicious instruction embedded in a GitHub pull request title could trigger an AI code review agent to leak its API key publicly, an exposure scored 9.4 Critical on the CVSS scale by Anthropic’s HackerOne program. Microsoft’s MSRC disclosures added more urgency by confirming two critical flaws in the Semantic Kernel framework: one that allowed arbitrary code execution from manipulated data inputs, and another that exposed file download functions on the host machine. These findings were not theoretical, they proved that vulnerabilities in AI development tools can directly compromise enterprise infrastructure.

For executive leaders, this means the productivity benefits of AI automation must be weighed against the operational risks of automation without oversight. AI systems execute commands without human context. If trust prompts default to approval, or if data ingestion is not tightly sandboxed, the same systems designed to accelerate code delivery can execute hostile commands instantaneously.

Leaders should push their organizations to adopt explicit consent and minimum-privilege models across all AI-assisted tools. behavioral monitoring must become standard, understanding what these systems execute, not just what they generate. Every level of the AI coding tool stack, from SDKs to CI/CD integrations, needs granular governance that ensures no process can act beyond its authorization scope.

The fast-moving adoption of AI tools in coding will continue. The key priority is to re-engineer their trust defaults and verification layers before attackers industrialize their exploitation. Modern AI coding tools are no longer passive assistants; they are active agents with execution rights. The security model must evolve to match that power.

Credential-targeting operations are accelerating amid AI exposure trends

The global increase in credential theft is not incidental, it is systematic. Threat groups are adapting quickly to how organizations use AI tools and cloud platforms, turning those same tools into new entry points. According to the Verizon 2026 Data Breach Investigations Report, 67% of employees access AI services from personal, non-corporate accounts while using corporate devices. This practice, often called shadow AI, reflects how AI adoption has outpaced governance. Developers share confidential data and source code with AI models operating outside enterprise control frameworks. Those credentials and repositories are now prime targets for attackers.

CrowdStrike’s 2026 Financial Services Threat Landscape Report adds more context. The group STAR­DUST CHOLLIMA tripled its operational pace against financial organizations in late 2025. It used AI-generated recruiter profiles, fake interviews, and malicious coding challenges to harvest tokens and access keys. These campaigns were not random; they were calculated attacks focused on developer environments, where secrets like GitHub PATs, npm tokens, AWS access keys, and CI/CD credentials are stored.

For executives, this marks a clear shift in how credential theft is executed and scaled. Attackers are no longer only breaching corporate infrastructure, they are targeting individual developers and engineers who hold trusted keys to production systems. Responsibility for credential protection must therefore expand beyond IT security to include governance of employee behavior, AI tool usage, and data sharing policies.

Preventing exposure requires technology-driven visibility and workforce discipline. Businesses must monitor where and how employees connect AI services, enforce strict data handling controls, and ensure credentials never leave secure, corporate-managed environments. Shadow AI can no longer be dismissed as harmless experimentation. It is now one of the primary vectors for high-level identity compromise and indirect supply chain infiltration. Enterprise resilience depends on addressing it systematically and immediately.

Governance and procurement teams must reassess trust frameworks in developer environments

In response to these failures, organizations need to redesign how they evaluate and contract with technology vendors. The breaches across npm, VS Code, and AI coding tools reveal a fundamental weakness in the trust models that underlie procurement decisions. Most organizations assume that a vendor’s certification or signature is sufficient proof of security. The recent string of compromised releases shows that trust signals, such as signed attestations or vendor automation badges, can be forged or misused when credentials are stolen.

Security leaders should revisit vendor management with new criteria centered on “stolen-identity resistance.” A reliable vendor should be able to demonstrate not only that their software packages are cryptographically valid, but that their publishing identity cannot be impersonated through compromised tokens or CI/CD accounts. Procurement and audit teams must therefore request evidence of authorization controls, build provenance tracking, and recovery protocols for compromised maintainers before renewing or purchasing new tools.

The Developer Tool Stolen-Identity Audit Grid outlined in recent research provides a framework for this. It explains how each vendor’s stack failed, what verification methods broke, and where enterprise visibility ends. The most effective risk mitigation comes not from a new list of tools, but from structured, transparent conversations between enterprise security teams and vendors during contract renewals. Each non-answer about coverage or responsibility in these discussions defines your organization’s weakest security boundary.

Executives should instruct their teams to integrate these discussions into procurement cycles now, not after another breach. Any system or vendor that cannot prove identity integrity should be treated as a temporary solution until more robust verification methods are implemented. The future of enterprise software security will depend on building contractual and operational partnerships that make identity verification and intent validation non-negotiable.

Trust in automation must evolve into measurable assurance. Governance and procurement are the organizational levers that can make that evolution real.

Recommended mitigations emphasize layered verification, behavioral monitoring, and policy hardening

Securing the software supply chain now requires layered, coordinated action. The research consensus shows that no single control or verification system can fully guard against identity misuse or automated credential theft. The priority for leaders is to build a structure where multiple layers of verification overlap, technical, procedural, and behavioral. This ensures that no single line of defense operates in isolation.

The Developer Tool Stolen-Identity Audit Grid presents practical steps that executives can implement today. High-impact npm packages should require two-party approval before publishing, especially for those exceeding 10,000 weekly downloads. Critical developer tools, such as VS Code extensions, need version pinning and minimum-age policies that reduce exposure to compromised updates. In AI-based development tools, automatic execution privileges, such as auto-trusting MCP servers, must be disabled unless explicitly authorized in advance.

For environments already exposed, CI/CD pipelines must be updated to the latest secure SDKs. Microsoft’s MSRC, for example, recommends upgrading Semantic Kernel Python SDK to version 1.39.4 and .NET SDK to 1.71.0 to close recent execution vulnerabilities. Development workstations also require stronger credential storage discipline, implementing encryption and OS-level keychains to protect access tokens, API keys, and session credentials at rest. On the corporate network, implementing browser-layer AI governance will allow organizations to monitor and restrict non-corporate AI usage that may leak proprietary data.

Executives should see these measures as essential controls, not optional upgrades. Each step adds a verifiable checkpoint, whether that’s human approval, sandboxed automation, or environmental inspection. In practical terms, layered verification is about reducing the number of paths an attacker can exploit with a single set of stolen credentials. The operational cost of implementing these policies is significantly lower than the cost of rebuilding trust or recovering source integrity after a supply chain compromise.

Behavioral monitoring must become a standard practice, not just an alert filed away in a dashboard. Security teams need to track how tools behave, not just whether they pass scans. If a process interacts with systems outside its defined scope, it should trigger immediate investigation. Combined with stronger policy enforcement, this establishes a living security environment that adapts in real time to identity misuse and automation-based threats.

The business advantage of layered and behavior-aware security is long-term stability. By moving beyond static compliance and embedding dynamic oversight into daily operations, organizations move toward predictable defense performance. The goal is not to slow innovation, it is to make progress sustainable. Security only has value when it scales with the speed and ambition of the enterprise. With these layered measures, leaders can maintain both.

The bottom line

The trust systems running today’s software economy are reaching their limits. Digital signatures, certificates, and automation once guaranteed integrity. Now, they’re being manipulated with precision. Every breach described here, from npm’s forged provenance to AI tool credential leaks, points to one universal truth: identity verification alone is no longer enough.

For business leaders, this isn’t a question of technical proficiency; it’s about operational continuity and brand trust. The attackers have learned to operate inside legitimate processes, using stolen credentials and automated workflows to appear indistinguishable from real developers. That means every enterprise relying on digital supply chains, cloud services, or AI integrations is exposed unless identity, authorization, and behavior are validated together.

This is the moment to upgrade from conventional compliance to proactive verification. Lean on multi-party approvals, continuous behavioral auditing, and vendor accountability that extends beyond a passing scan or a signed certificate. Security is not a static investment, it’s a continuous capability.

Enterprises that act now will define the next standard for digital integrity. Those that delay will inherit the risk of trust systems built for an earlier, simpler era. The technology is ready for change; leadership needs to be as well.