The Problem
A malicious npm package called 'indexed-btree' managed to reach 2 million weekly downloads by hiding its loader inside a normal runtime method, evading most supply chain defenses. GitHub's npm security measures, introduced in June 2026 to block lifecycle scripts like 'preinstall' and 'postinstall' unless explicitly approved, failed to detect it. The malware remained dormant until the application invoked BTree.prototype.set() with a specific key value.
This incident raises a critical question for procurement security teams vetting open-source dependencies: should you shift focus from install-time scanning to runtime behavioral analysis, or is a balanced approach more effective?
The Case for Runtime-First Detection
Runtime analysis can catch what static tools miss. When malware embeds itself in a library's core function, static scanners see only legitimate code. The indexed-btree loader activated only when developers called the package's main method during normal use. No installation script ran, and no suspicious dependency was pulled from a remote URL. The package bypassed every gate that install-time defenses guard.
Runtime behavioral analysis observes what code actually does: system calls, network connections, file access patterns, and cryptographic operations. When the indexed-btree malware collected system details and exfiltrated them through hardcoded Slack and Telegram channels, those behaviors would have been flagged in a runtime environment. Its actions, like polling an Ethereum smart contract for command-and-control information and using X25519 key exchange to decrypt a payload, create observable patterns that static analysis can't predict.
Checkmarx researchers identified nine additional malicious packages in the same operation, collectively downloaded millions of times. Traditional install-time scanning flagged none of them because the threat actors understood which gates to avoid. Runtime analysis doesn't care about evasion techniques; it monitors what executes.
For teams managing software supply chain risk under frameworks like ISO 27036, runtime monitoring aligns with the principle that supplier relationships require continuous oversight, not just point-in-time checks. The malware's ability to delete its files and remove its trigger code when operators ended the attack shows why one-time assessments fall short.
The Case for Keeping Install-Time Primacy
While runtime analysis sounds comprehensive, it comes with operational costs. Running behavioral monitoring across every dependency in a production environment creates performance overhead, generates alerts that security teams must triage, and requires infrastructure most organizations don't have. Install-time scanning occurs once per package version in a controlled CI/CD pipeline, while runtime analysis is continuous across every deployment.
Install-time defenses also catch the majority of threats that don't use sophisticated evasion. GitHub's npm security measures exist because lifecycle script abuse remains a dominant attack vector. The fact that indexed-btree bypassed these controls doesn't invalidate them; it means attackers adapted. Security evolves. When install-time defenses improve, some attackers move to runtime. When runtime monitoring becomes standard, they'll find the next gap.
There's also a timing issue. Install-time scanning blocks malicious packages before they enter your environment. Runtime analysis detects them after they're already executing in production. For organizations that downloaded indexed-btree, runtime analysis would have flagged the exfiltration, but system details had already left the network. Secrets might already be compromised. The response plan isn't just "remove the package," it's "rotate credentials, audit access logs, restore from safe backups."
From a risk governance perspective, install-time controls are easier to audit and demonstrate. When regulators or customers ask how you vet dependencies, "we scan every package before installation and block unapproved lifecycle scripts" is clearer than "we monitor runtime behavior and investigate anomalies." The latter requires explaining detection thresholds, false positive rates, and response times.
Where Teams Actually Land
Most teams aren't choosing one or the other; they're layering defenses based on criticality. High-risk dependencies (those with broad system access, handling sensitive data, or running in production) get both install-time scanning and runtime monitoring. Lower-risk packages get install-time checks only.
The indexed-btree campaign highlights a gap in that model: popularity doesn't equal scrutiny. The package's 2 million weekly downloads came from developers who saw a legitimate-looking GitHub repository and assumed it was safe. Threat intelligence feeds that track suspicious package patterns, like typosquatting and sudden popularity spikes, would have flagged it before widespread adoption.
Practitioners also integrate runtime analysis selectively. Instead of monitoring every dependency, they focus on code paths handling authentication, data access, network calls, and cryptographic operations. When a B-tree library starts polling an Ethereum smart contract, that's not normal behavior for its function. Context matters more than comprehensive coverage.
Our Take
Install-time scanning should remain your first line of defense. It's cost-effective, catches most threats, and prevents malicious code from entering your environment. But the indexed-btree campaign proves it's not enough for dependencies classified as critical under your risk scoring framework.
Add runtime behavioral analysis for packages that meet criteria such as handling authentication or authorization, processing customer data, making network calls, or running with elevated privileges. You don't need to monitor every npm package; focus on those where hidden malware poses a significant risk.
Integrate threat intelligence into your vendor intake workflow. Tools that flag packages with fabricated commit histories, suspicious maintainer patterns, or typosquatting attempts would have caught indexed-btree before it hit 2 million downloads. That's cheaper than incident response.
The real lesson isn't "runtime beats install-time." It's that sophisticated attackers study your defenses and find ways around them. Your supply chain security architecture needs multiple layers that fail independently, not a single gate that threat actors can learn to bypass.
