Topic starter
20/08/2026 5:57 pm
TL;DR: Git dependency .npmrc injection left npm with a documented bypass, Pixee reports, so install-time controls can fail even when teams think --ignore-scripts is in force. Package-manager behavior now determines whether dependency policy is enforceable or only assumed.
Editorial analysis by NHI Mgmt Group, based on content published by Pixee: “Six Zero-Days, One Refusal: How npm Created Two-Tier JavaScript Security”.
Key questions
Q: Why do git dependencies create supply-chain risk that registry scanning misses?
A: Because the dangerous content can live outside the registry and enter the build during dependency resolution, not package publication.
Q: How should teams govern package-manager choice in CI/CD pipelines?
A: Treat package-manager choice as part of the security architecture, not just developer ergonomics.
Q: What breaks when a package manager leaves a documented bypass unpatched?
A: The control assumption breaks, not just the tool.
Practitioner guidance
- Audit git dependency paths for installer-side bypasses Identify repositories and build pipelines that pull dependencies from git URLs, then test whether install-time controls such as --ignore-scripts are actually enforced in those paths.
- Separate registry scanning from source provenance checks Add controls that inspect dependency source locations, commit references, and repository content so malicious behavior hidden outside package metadata is still evaluated.
- Reclassify package-manager selection as a security decision Document which package managers in your estate patch known install-path flaws and which may leave documented behavior unpatched, then route high-risk projects accordingly.
Bottom line: PackageGate shows that package-manager policy can be as important as package content when install-time controls are bypassable.
Glossary terms: Install-time Bypass, Dependency Provenance, Script Execution Control, Supply chain assurance
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 1 day ago by NHI Mgmt Group
20/08/2026 6:37 pm
Package-manager policy is now part of supply-chain security posture. The article shows that the same class of weakness can be treated as a patchable flaw in one ecosystem and as expected behavior in another. That changes the governance burden for engineering leaders because the tool choice now determines where accountability sits when a control fails. Practitioners should treat package-manager selection as a security control decision, not a build preference.
A few things that frame the scale:
- CrowdStrike's 2026 Global Threat Report said zero-days exploited before public disclosure rose 42% year over year.
A question worth separating out:
Q: When should organisations move beyond dependency metadata checks?
A: When they rely on git dependencies, script-disabling settings, or other install-time safeguards that can be bypassed through source-controlled content. Metadata checks are still useful, but they are not enough when the attacker path is resolved during installation rather than publication. At that point, provenance, install behavior, and execution controls all need to be part of the review.
👉 Read our full editorial: PackageGate exposes the security cost of unpatched npm behavior