IBM and Red Hat announced Project Lightwell in May 2026: $5 billion, 20,000 engineers, an investment in open source security at a scale the industry has not seen before. Two months earlier, an attacker had compromised the npm account of the primary axios maintainer and published trojanised versions of one of the most downloaded JavaScript libraries ever.
The timing tells you everything. The crisis Lightwell was built to address had already arrived at precisely the ecosystem and through precisely the attack vector that the clearinghouse model is designed to defend against. A single maintainer account takeover, a single compromised package, and suddenly 100 million weekly downloads became a malware delivery channel for a North Korean remote access trojan.
The problem is structural, not a matter of better detection. By 2026, institutional intervention had stopped being optional — a conclusion that anchors the broader Project Lightwell landscape.
What is the current state of open source software supply chain security in 2026?
The numbers are not getting better.
ReversingLabs’ 2026 Software Supply Chain Security Report found a 73 percent year-over-year increase in malicious open source packages detected across registries in 2025. npm accounted for nearly 90 percent of that malware, attributed to JavaScript’s ubiquity and the sheer scale of the registry. Sonatype’s 2026 State of the Software Supply Chain report documented 9.8 trillion component downloads in 2025, with open source malware surpassing 1.2 million packages. At the same time, actively maintained open source projects declined by 18 percent over the same year. The codebase is growing while the people maintaining it are shrinking.
This is not just a volume problem. The post-xz-utils world, which began in 2024 when a single burned-out maintainer nearly handed a backdoor to millions of downstream systems, revealed how fragile the human layer of open source security actually is. The Linux Foundation’s Census of Open Source Software found that 74 percent of the 500 most critical open source projects have fewer than three active maintainers, and 23 percent are maintained by a single individual. The Shai-Hulud worm in September 2025, the first registry-native self-replicating malware on npm, demonstrated that automation, which had always worked for defenders, was now working against them.
The OWASP Top 10 2025 introduced “Software Supply Chain Failures” as the number three most critical web application security risk, with the highest average exploit and impact scores among all categories despite having the fewest recorded occurrences. The attacks that do succeed hit hard.
And through all of this, the maintainers are drowning. cURL founder Daniel Stenberg publicly stated that AI-generated vulnerability reports are flooding his inbox at four to five times the rate of 2024. “I work more than I’ve done before, but the flood keeps coming,” he said. The infrastructure the Fortune 500 depends on is maintained by people who cannot scale to meet the threat, and Stenberg’s experience is not an outlier. It is what the census data predicts.
That human fragility is not theoretical. It is the root cause behind the attack that follows.
What happened in the Miasma/UNC1069 axios npm supply chain attack?
On March 31, 2026, between 00:21 and 03:20 UTC, an attacker published two malicious versions of axios: 1.14.1, tagged latest, and 0.30.4, tagged legacy. A default npm install axios pulled a backdoored package.
Elastic Security Labs detailed the attack chain: the attacker had compromised the npm account of jasonsaayman, the primary axios maintainer. The compromised versions introduced a single new dependency called plain-crypto-js. Its postinstall hook silently downloaded and executed platform-specific malware implants from a command-and-control server at sfrclak.com.
The maintainer email changed from [email protected] to [email protected] on the malicious versions. The publishing method shifted from GitHub Actions OIDC, which carried SLSA provenance attestations, to direct CLI publish. These were clear indicators of unauthorised access, but by the time anyone noticed, the packages were live.
Google Threat Intelligence Group and Mandiant attributed the attack to UNC1069, a financially motivated North Korea-nexus threat actor active since at least 2018. The social engineering was sophisticated: UNC1069 operators spent approximately two weeks building rapport with the maintainer using deepfake-enhanced video calls and AI-generated communications before stealing a long-lived npm access token.
Axios has roughly 100 million weekly downloads and is present in about 80 percent of cloud and enterprise development environments. Wiz CTO Ami Luttwak noted the compromised package was detected in approximately 3 percent of environments examined, with the real concern being the transitive dependency chain: “hundreds of packages depend on axios.”
StepSecurity’s automated monitoring detected the anomalous publish within two hours, and npm removed the tainted versions by 03:20 UTC according to npm’s security advisory. But the dropper performed anti-forensic cleanup, deleting its own setup script and swapping its package.json with a clean copy. Only the lockfile and npm audit logs retained evidence of what had happened.
How does the WAVESHAPER.V2 malware operate across different platforms?
The payload delivered through axios was WAVESHAPER.V2, a cross-platform Remote Access Trojan with native implementations in PowerShell for Windows, compiled C++ for macOS, and Python for Linux. All three variants share an identical C2 protocol, command set, message format, and operational behaviour, as Elastic Security Labs documented in their analysis.
Every variant communicates with sfrclak.com (142.11.206.73) over port 8000, using HTTP POST transport with Base64-encoded JSON. They all spoof an IE8/Windows XP User-Agent string, an anachronism on any platform that Elastic Security Labs identified as a detection indicator. The beacon interval is 60 seconds across all variants.
The RAT supports a full command set: kill to terminate processes, peinject for process injection on Windows, runscript to execute arbitrary scripts, and rundir to execute files from specified directories. On Windows, persistence is established through a registry Run key entry named MicrosoftUpdate that survives reboots. On macOS, the payload disguises itself as an Apple system daemon at /Library/Caches/com.apple.act.mond.
The dropper checks the operating system at install time and branches into three delivery routines, each sending an HTTP POST with platform-specific paths like packages.npm.org/product0 for macOS. The npm-like path prefix is a deliberate attempt to make C2 traffic appear as benign registry communication.
The upgrade from WAVESHAPER V1 to V2 shifted the C2 protocol from a raw binary format to structured JSON-based command and response. This is not experimental malware. It is professionally engineered, iteratively refined, and designed to survive in enterprise environments where developer workstations and CI/CD runners are the target.
How are North Korean state-sponsored groups evolving their supply chain attack tactics?
UNC1069 has been tracked by Google Threat Intelligence Group since 2018. The group’s evolution tells a story of accelerating sophistication: early spear-phishing of cryptocurrency exchange developers gave way to creating malicious npm packages impersonating legitimate libraries in 2023. The axios compromise represents the group’s first successful takeover of a genuine, widely used package.
This is not an isolated campaign. The Shai-Hulud worm in September 2025 tested registry-native automation at scale, compromising over 1,000 packages and exposing an estimated 25,000 GitHub repositories. The Miasma attack in March 2026 applied those lessons to precision targeting: instead of compromising many packages indiscriminately, UNC1069 targeted a single high-value maintainer account. Maximum impact, minimum detection surface. The tactical leap took less than eight months.
UNC1069 operates under North Korea’s Reconnaissance General Bureau, alongside the more well-known Lazarus Group. The motivation is consistent across campaigns: cryptocurrency theft. The United Nations Security Council reported that North Korean state-sponsored hackers stole an estimated $1.7 billion in cryptocurrency in 2024, a significant share of all cryptocurrency theft globally. Supply chain attacks provide access to developer environments where financial system credentials and cryptocurrency keys reside.
In the same period as the axios compromise, a separate North Korean-linked group tracked as UNC6780 conducted attacks targeting the Trivy vulnerability scanner and Checkmarx security tools. The simultaneity suggests coordinated escalation rather than coincidence. And the separate Microsoft-discovered compromise in the same campaign window indicates UNC1069 may be running parallel operations across multiple npm entry points.
The defenders are losing the iteration race. Platform defences are consistently one step behind attacker adaptation, and the gap is not closing.
If platform defences cannot close that gap, what can? IBM and Red Hat’s answer is structural, not incremental — and it arrives alongside the regulatory forces reshaping the space that make structural responses a compliance necessity.
What is IBM’s Project Lightwell and why did IBM and Red Hat launch it?
Project Lightwell is not a scanner, not a bug bounty programme, and not a registry. It is a $5 billion institutional commitment backed by 20,000 engineers to build an enterprise clearinghouse that discovers vulnerabilities at AI scale, validates fixes through human-in-the-loop engineering, and delivers backported patches into enterprise dependency graphs.
Announced May 28, 2026, Lightwell is a joint IBM and Red Hat initiative. The 20,000-engineer figure deserves context: it is larger than the entire employee count of many software companies. IBM already uses more than 62,000 open source packages across its enterprise footprint and maintains expertise in over 10,000 of them. The company is not starting from scratch.
The strategic logic is straightforward. IBM’s December 2025 Confluent acquisition signalled ambitions to own the end-to-end commercial open source infrastructure layer, from Kafka to Flink to data streaming. Lightwell extends that ambition to the security layer, positioning IBM as the trusted intermediary between upstream open source communities and enterprise consumers — a role made urgent by the systemic maintainer crisis that makes initiatives like Lightwell necessary.
Red Hat’s upstream-first development philosophy shapes how Lightwell operates. Fixes discovered and validated by the clearinghouse get contributed back to original projects via a “secure map,” ensuring communities benefit rather than creating a parallel patched ecosystem. When upstream maintainers disagree with a fix, Lightwell can still carry hardened backports for its customers. The community retains ownership. The enterprise gets protection.
Eleven financial services organisations, including Bank of America, JPMorganChase, Goldman Sachs, Visa, and Mastercard, are trialling Lightwell. These are the most risk-sensitive enterprises betting that the clearinghouse model is the right answer. The initial focus is on the Maven/Java ecosystem, with plans to expand to PyPI, npm, and Go.
How does the Project Lightwell enterprise clearinghouse actually work?
The operational model is a pipeline, not a product.
Enterprises submit dependency manifests, initially pom.xml files. Lightwell’s AI systems scan the full dependency graph, including transitive dependencies, against vulnerability databases, AI-discovered patterns, and threat intelligence feeds. The scale of this scanning is something no human team can replicate. Anthropic’s Mythos Preview model identified approximately 3,900 previously undiscovered high and critical severity vulnerabilities in open source software within weeks, demonstrating that AI-powered vulnerability discovery at scale is viable. Lightwell applies the same principle within its own pipeline.
Then the human layer engages. AI surfaces patterns and generates candidate patches, but Red Hat and IBM engineers validate safety, correctness, and production suitability before anything ships. AI-assisted remediation with a mandatory human quality gate means every candidate patch is validated before it reaches an enterprise pipeline. The AI discovers; humans decide. As the Lightwell team frames it, coupling machine-scale discovery with human-scale judgement produces better security outcomes than either could achieve independently.
The delivery mechanism is backporting. Instead of forcing enterprises to upgrade to patched versions, which introduces regression risk and requires recertification, Lightwell delivers fixes that neutralise vulnerabilities in the exact dependency versions enterprises already use. In practice, this means the clearinghouse produces a modified configuration manifest that points to a Lightwell-vetted artifact containing the patched code at the same version number. The code stays in controlled environments while vulnerabilities are neutralised, no disruptive upgrade required.
Transitive dependency tracking is the differentiator that matters. Most SCA tools alert on direct dependencies but miss exploitable transitive chains. Lightwell maps the full dependency graph and applies fixes to deep transitive vulnerabilities that enterprises often cannot see. Every validated patch carries cryptographic provenance, plugging into enterprise SBOM requirements and regulatory compliance frameworks.
The clearinghouse also functions as a secure intermediary: enterprises can share sensitive vulnerability intelligence under embargo, receive validated patches, and coordinate disclosure timing. This addresses the confidentiality gap in existing vulnerability disclosure processes that has long frustrated security teams.
What should organisations do right now to defend against npm supply chain attacks?
Lightwell will not reach npm coverage immediately. While it matures, the most effective defences are concrete and actionable.
Implement phishing-resistant authentication. Filipo Valsorda’s compromise survey identified this as a professional responsibility for open source maintainers: passkeys or WebAuthn on all accounts with publish access. The survey is unambiguous: the number one root cause of supply chain compromises is maintainer account takeover, and the predominant initial access vector is phishing. The Miasma attack succeeded because TOTP-based 2FA did not stop a phished credential.
Adopt Trusted Publishing with OIDC. Replace long-lived npm tokens with short-lived OIDC-based tokens that cannot be exfiltrated and reused. The Miasma attacker switched from OIDC to direct CLI publish, demonstrating why eliminating long-lived credential paths matters. But note the caveat from the Bitwarden CLI attack: OIDC Trusted Publishing can itself be weaponised if branch-level restrictions are absent.
Enforce dependency pinning and lockfile auditing. Freeze dependency versions to known-good releases and audit lockfiles for unexpected changes. This is the most actionable step for development teams. It prevents automatic pull of compromised versions and creates an audit trail that survives the anti-forensic cleanup techniques WAVESHAPER.V2 employed.
Implement CI/CD pipeline isolation. The pull_request_target trigger is tied with maintainer account takeover as a top root cause of supply chain compromises. Isolate build pipelines, eliminate mutable GitHub Actions tag references, and audit workflow permissions. StepSecurity’s npm cool-down check prevents usage of recently released package versions during the window when compromised packages are most likely to be caught and removed.
Run npm install in isolated environments where postinstall script execution is monitored. WAVESHAPER.V2 relied on lifecycle hooks for delivery. Developer workstation EDR configured to detect npm lifecycle script anomalies, particularly outbound connections to unknown domains on port 8000, can identify compromise before lateral movement occurs.
What this means
The Miasma attack validated Lightwell’s thesis. The crisis the clearinghouse model was built to address had already demonstrated, two months before Lightwell’s announcement, that maintainer account takeover remains the dominant attack vector and that npm’s postinstall hooks remain the most efficient malware delivery mechanism in the supply chain.
The open source supply chain crisis has passed the point where individual maintainers, registry rules, or SCA scanners can hold the line. The Shai-Hulud to Miasma evolution, compressed into less than eight months, shows nation-state actors iterating faster than platform defences can deploy. Lightwell’s clearinghouse model represents the architectural shift the crisis demands: AI-powered discovery, human-in-the-loop validation, transitive dependency mapping, and backported remediation provided as a service rather than a tool. This shift forms one pillar of the full picture of enterprise open source security, where competing models and regulatory pressure are converging.
Phishing-resistant authentication, dependency pinning, CI/CD isolation, and curation-first intake are the bridge between today’s exposure and tomorrow’s defences. The competition between models — Lightwell’s engineer-heavy clearinghouse versus Anthropic’s Glasswing AI-credits approach (explored in how AI-driven approaches compare to Lightwell’s engineer-heavy model) versus Socket.dev’s curation-first platform — is itself evidence that the market has recognised the old model is broken. Even the organisation building the solution remains vulnerable. That is the point.
Frequently Asked Questions
How is Project Lightwell different from existing tools like Snyk or Dependabot?
Existing tools detect vulnerabilities and alert you; Lightwell fixes them. Snyk and Dependabot are scanners that tell you something is wrong and suggest version upgrades, but they do not validate patches, backport fixes into your exact dependency versions, or provide human engineering review. Lightwell is a remediation service with an institutional quality gate, not a detection-and-alert product. The clearinghouse delivers a security coordination layer that scanners, by design, cannot.
What does Project Lightwell mean for individual open source maintainers?
It means critical infrastructure stops resting entirely on unpaid shoulders. Lightwell’s upstream-first model ensures fixes discovered through the clearinghouse flow back to original projects, not into a proprietary fork. For burned-out maintainers, this provides institutional backup: IBM and Red Hat engineers can triage and patch vulnerabilities that a single maintainer cannot handle alone, while the project retains community ownership and credit for the fix.
When will Lightwell support ecosystems beyond Maven, like PyPI or npm?
IBM has confirmed plans to expand beyond the initial Maven/Java focus to PyPI, npm, and Go, but has not published a timeline. The Maven-first strategy reflects enterprise Java dominance and the highest concentration of unmaintained but critical dependencies in that ecosystem. The Miasma attack on npm two months before launch may accelerate npm coverage, but organisations running npm-heavy stacks should not wait: implement curation-first practices like dependency pinning and lockfile auditing today.
Is Lightwell available to small and medium businesses, or only enterprise customers?
Lightwell’s subscription pricing scales by package count, which means smaller organisations with fewer dependencies pay less. However, the current early adopter cohort is exclusively large financial institutions, and IBM has not announced a dedicated SMB tier. The practical reality is that Lightwell is optimised for organisations with complex, regulated dependency graphs. Smaller teams can achieve meaningful protection today through dependency pinning, lockfile auditing, and curation-first intake models using platforms like Socket.dev.
Does using Lightwell mean our organisation no longer needs an application security team?
No, and IBM is not positioning it that way. Lightwell addresses one part of the security stack: open source dependency risk. It does not replace application security testing for proprietary code, runtime defence, identity and access management, or incident response. The better way to think about it is outsourcing dependency triage and remediation to a trusted institutional partner, which frees your internal security team to focus on proprietary risks and architecture-level decisions.
How does the Lightwell clearinghouse handle zero-day vulnerabilities with no known fix?
This is where the human-in-the-loop model proves essential. When AI discovers a novel vulnerability with no existing patch, Red Hat engineers develop a validated fix through the clearinghouse, applying the same upstream-first engineering practices Red Hat has used for decades with the Linux kernel. The fix is then backported into enterprise dependency graphs and contributed upstream to the original project. This is remediation at the speed of institutional engineering, not at the speed of a CVE publication cycle.
What happens if Lightwell’s AI incorrectly identifies a safe dependency as vulnerable?
The human validation gate is the safeguard. AI surfaces patterns and flags potential vulnerabilities at scale, but every candidate patch passes through Red Hat and IBM engineers who verify safety and correctness before shipping. The cleared fix never reaches an enterprise CI/CD pipeline without human review. This is why Lightwell commits 20,000 engineers rather than relying on AI alone: the combination of machine-scale discovery with human-scale judgement produces better security outcomes than either could achieve independently.
How would an organisation know if they were affected by the Miasma axios compromise?
Check whether your projects depend on axios versions 1.14.1 or 0.30.4, and audit your lockfiles for the plain-crypto-js dependency published during the March 31 attack window. Elastic Security Labs published a detection signature based on WAVESHAPER.V2’s distinctive IE8/Windows XP User-Agent string communicating with sfrclak.com (142.11.206.73). If you cannot confirm clean dependency state, rotate all credentials exposed in affected environments as a precaution.
Is backporting patches safe, or does it create a parallel ecosystem of unofficial package versions?
Backporting is a well-established practice in enterprise Linux distributions, where Red Hat has safely backported kernel fixes for decades. Lightwell applies the same engineering discipline: patches are validated by human engineers, applied to specific dependency versions, and contributed upstream so the original project can incorporate them into future releases. This is not forking; it is a temporary bridge that neutralises risk without forcing disruptive upgrades, and the upstream contribution closes the loop.
Do other registries like PyPI and Maven Central share npm’s postinstall script risk?
The specific mechanism differs, but the structural risk is universal. PyPI packages can execute arbitrary code during installation through setup.py, and Maven plugins run during the build lifecycle. No major package registry has eliminated the fundamental problem: installing a dependency means executing code from an external source. npm’s postinstall hooks are the most straightforward exploitation vector, which is why supply chain attackers overwhelmingly target npm, but every registry has an equivalent attack surface that demands equivalent defensive rigour.
