A new class of npm supply chain attack hides malicious payloads inside binding.gyp — the build configuration file node-gyp uses to compile native addons. Unlike typosquaked packages or hijacked maintainer accounts, this worm propagates by injecting itself into the build pipeline of every package that depends on the compromised module. Traditional SCA tools that scan declared dependencies never see it, because the malicious code lives in a build artifact, not in package.json. For CISOs and compliance teams, this is the gap that turns a single compromised dependency into an enterprise-wide incident.
Why SCA Dependency Scanning Misses Build-Script Worms
SCA tools operate at the dependency graph layer: they match package names and versions against known vulnerability databases. A worm embedded in binding.gyp is invisible at this layer. The package's declared dependencies are clean. The malicious logic executes during npm install when node-gyp invokes the build system, long after the SCA scan has passed. By the time the worm activates, it has already been committed to the build artifact cache and will reproduce in every downstream CI pipeline that compiles the addon.
How SAST Taint Analysis Traces the Propagation Chain
Security Reviewer's SAST engine applies taint analysis across the full build lifecycle, not just application source code. When a package installs, SR tracks data flow from the npm install hook through the node-gyp invocation, into the binding.gyp parsing stage, and out to any filesystem or network operations the build script performs. The taint graph reveals the worm's self-propagation chain: the install hook modifies binding.gyp in sibling packages, which triggers recompilation, which re-executes the hook. SR flags this as a cross-package data-flow violation — a persistence mechanism that no dependency manifest can express.
Detecting the Persistence Mechanism Before Production
The critical detection window is the CI build stage. SR instruments the build environment to monitor file-system mutations during native addon compilation. When a build script writes to binding.gyp in any package outside its own directory, SR classifies this as an unauthorized build-artifact modification and blocks the artifact from promotion. This catches the worm at the exact point where it attempts to propagate — before the poisoned artifact reaches a production registry or a developer's local node_modules.
Compliance Implications for Supply Chain Security
Frameworks like SSDF and SLSA require provenance verification for build artifacts. A worm that modifies build scripts at install time breaks the provenance chain silently. SR's taint analysis provides auditable evidence of the injection point, the propagation path, and the blocked mutation — giving compliance teams a concrete artifact to map against supply chain control requirements rather than a generic "dependency scan passed" result.
What Security Reviewer Customers Should Validate Today
If your CI pipeline compiles native addons, verify that your SAST configuration includes build-script taint tracking — not just application source scanning. SR customers can enable the build-lifecycle analysis module in their pipeline configuration to cover node-gyp, node-pre-gyp, and similar native addon build paths. Run a retrospective scan against your last 90 days of build artifacts; any unauthorized binding.gyp modifications will surface as cross-package taint violations. For teams without SAST coverage at the build layer, this is the highest-value control to add before the next supply chain incident reaches your registry.