Miasma Supply Chain Attack: When Red Hat npm Packages Become Attack Vectors

Traditional SAST tools scan first-party source code for known vulnerability patterns, then stop. That boundary is exactly where Miasma lives. The wiz-research-supplied threat intelligence on the Miasma supply chain attack reveals a campaign that compromised published Red Hat npm packages — artifacts that SAST already considers trusted because they arrive through registry signatures, not developer-authored code. Every enterprise CI/CD pipeline that treats npm install as a boundary rather than a taint surface has a blind spot that this class of attack exploits directly.

The gap between SAST reach and supply chain reality

SAST excels at flagging dangerous function calls, insecure defaults, and injection flaws in code a developer typed. It does not, by default, model what a dependency does at runtime after a supply chain compromise rewrites it between registry publication and install. Miasma demonstrated that a single compromised upstream package propagates through hundreds of transitive dependency trees before any commit hits source control — meaning the malicious payload never appears in a diff, so no commit-time SAST scan can see it.

The operational implication is concrete: a pipeline that passes SAST and produces a clean bill of health can still deploy a dependency that exfiltrates environment variables, injects credential harvesters into build artifacts, or establishes persistence in container images.

Taint analysis as the missing configuration layer

Static taint analysis tracks untrusted data from source to sink — but most enterprise SAST deployments only configure taint on first-party code boundaries (HTTP input, database query, file read). To catch transitive dependency poisoning, the taint model needs expanded sources:

• Registry package metadata and install scripts (preinstall, postinstall hooks) treated as tainted until validated.
• Dependency resolution itself modeled as a taint propagation step, where a child package inherits the trust context of its parent.
• Environment variable reads inside any node_modules dependency flagged as sinks when the writing path is outside the application's own source tree.

Without these configurations, taint analysis treats node_modules as a trust zone rather than an attack surface — precisely the assumption Miasma relies on.

What Security Reviewer covers that SAST alone cannot

Security Reviewer's platform combines SAST, SCA, and DAST into a single pipeline stage, which closes the gap that Miasma exploits. SCA correlates the compromised package version against the wiz threat intel feed in near-real-time, flagging the Red Hat npm packages at build time rather than waiting for an advisory. DAST then verifies that deployed artifacts are not exhibiting the exfiltration behaviors the compromised packages are known to introduce — catching what SAST misses because the vulnerability is in the binary, not the source code. Taint analysis rules are configurable at pipeline level, so teams can expand their taint sources to cover the node_modules boundary without re-architecting their CI/CD configuration.

Recommended actions for enterprise teams

• Reclassify node_modules and postinstall hooks as taint sources in your static analysis pipeline rather than trust zones.
• Verify that SCA coverage in your build process is evaluating threat intelligence feeds, not only CVE databases — Miasma was identified through active research before a CVE existed.
• Ask Security Reviewer for a supply chain risk assessment that models your actual npm dependency tree against current threat intel feeds and validates whether your taint analysis posture covers transitive poisoning scenarios.