Dependency installation security measure already defeated on npm

* Attackers routed around an npm measure adopted in July to close a security gap.
* Version 12 of the package manager stopped running dependency install scripts by default.
* Malware was detected on the malicious indexed-btree package, which mimics the legitimate sorted-btree library.
* The malware trigger was buried inside the library’s prototype method, not in preinstall or postinstall scripts.
* Upon execution, the malware fingerprints hosts and exfiltrates data via Slack and Telegram.
* Command-and-control utilized an Ethereum smart contract channel.
* Some researchers warned that code still needed to run at import time if installation checks were closed.
* The absence of install scripts led reviewers to trust the package because it had a clean package.json.
* Attackers moved from package installation to package use.
* Malware was covered by a fake GitHub repository and commit history.

The incident demonstrates a critical failure in relying on localized, single-stage security controls. The pattern observed is the tactical adaptation of threat actors: when a defensive mechanism closes one vector (installation scripts), adversaries immediately seek an alternative execution path that remains viable within the application's runtime context. This suggests that security efficacy is determined not by blocking specific artifacts (like `postinstall` scripts) but by establishing a holistic trust model for package behavior across its entire lifecycle, from ingestion to execution. The observation that clean installation status can create a false sense of security—a "trust signal"—highlights the risk in heuristic-based defenses that rely on surface-level artifact inspection rather than deep behavioral analysis. The shift observed, from installation concerns to runtime behavior, forces a reevaluation of where control points are most effective and necessitates layered defenses incorporating dynamic analysis, complex binary scrutiny, and continuous monitoring of application execution context.
Bridge Questions:
If security shifts entirely to runtime behavior, what new, observable metrics should organizations prioritize for validating third-party dependencies? How can systems be architected to automatically verify the execution path of imported code rather than just the integrity of installation hooks? What is the collective cost—measured in time, resources, and trust—of relying solely on static analysis versus dynamic behavioral verification in a rapidly evolving software supply chain?