Scope
This guide outlines the technical controls and verification steps your team needs when using packages from NuGet, npm, and similar public repositories. It includes detection methods, repository-level security requirements, and a workflow for evaluating new dependencies before they enter your codebase.
This applies to:
- ASP.NET applications using NuGet packages
- JavaScript/Node.js projects using npm
- Any development environment pulling from public package repositories
- CI/CD pipelines that automatically fetch dependencies
This does NOT cover:
- Private package repository management
- Container image security
- Source code review of existing dependencies
Key Concepts and Definitions
Typosquatting: Malicious packages named to resemble legitimate ones (e.g., "Systen.Drawing" vs "System.Drawing"). Attackers exploit developer typos during package installation.
Package exfiltration payload: Code embedded in a package that extracts sensitive data and transmits it to attacker-controlled infrastructure.
Backdoor establishment: Malicious code that creates persistent remote access, often by modifying application startup routines or injecting web shells into ASP.NET applications.
Download count manipulation: Artificially inflating package download statistics to create false legitimacy. Note that the malicious NuGet packages were downloaded more than 4,500 times before removal, while the npm package ambar-src amassed over 50,000 downloads before being taken down.
Requirements Breakdown
Relevant Compliance Controls
PCI DSS v4.0.1 Requirement 6.3.2: Maintain an inventory of bespoke and custom software, and third-party software components to facilitate vulnerability and patch management.
Your dependency manifest (package.json, .csproj) satisfies the inventory requirement, but you need additional documentation showing verification status.
PCI DSS v4.0.1 Requirement 6.2.4: Protect public-facing web applications against attacks through application security testing or assessment.
This extends to dependencies. If a malicious package introduces a backdoor, your application becomes vulnerable regardless of your own code quality.
OWASP Top 10 2021 - A06:2021 Vulnerable and Outdated Components: Addresses the risk of using components with known vulnerabilities, but equally applies to components with unknown malicious intent.
ISO/IEC 27001:2022 Control 8.31: Separation of development, test, and production environments. Your testing environment should catch malicious package behavior before production deployment.
Implementation Guidance
Pre-Installation Verification
Before adding any package, complete these checks:
1. Publisher verification
- Examine the package owner's profile and publication history.
- Cross-reference the publisher against the official project repository.
- For NuGet: Check if the package ID matches the official namespace pattern (e.g., Microsoft., System.).
2. Repository metadata analysis
- Review the linked source code repository (GitHub, GitLab).
- Verify the repository has a legitimate commit history, not just a shell created for the package.
- Check if the repository URL in the package manifest matches the actual project.
3. Download pattern assessment
- Compare download counts against package age.
- Sudden spikes in downloads on newly published packages warrant investigation.
- Extremely low downloads on packages claiming to be "official" or "enterprise-grade" is a red flag.
4. Dependency tree inspection
Run npm ls --all or dotnet list package --include-transitive to see what your new dependency pulls in. A simple utility package shouldn't require 15 transitive dependencies.
Runtime Monitoring
Deploy these controls in your development and staging environments:
Network egress monitoring Configure your development environment to log all outbound connections. Malicious packages typically exfiltrate data immediately upon installation or first execution. Block outbound traffic to:
- Newly registered domains (< 30 days old)
- Non-standard ports
- Geographic regions your application doesn't serve
File system access auditing Monitor package installation scripts for unusual file access patterns:
- Reading SSH keys from ~/.ssh/
- Accessing browser credential stores
- Scanning for .env files outside the project directory
Process execution tracking Package installation should not spawn:
- PowerShell or bash shells with network operations
- Encoding/decoding utilities (base64, certutil)
- Archive extraction tools targeting system directories
Repository-Level Controls
If you manage an internal package repository or mirror:
Implement package signing requirements
- NuGet: Enforce author and repository signatures.
- npm: Use
npm audit signaturesto verify package provenance. - Reject unsigned packages or those with signature mismatches.
Deploy automated scanning Run static analysis on packages before mirroring:
- Scan for obfuscated code (base64 strings, hex-encoded payloads).
- Detect suspicious API calls (System.Net.WebClient, child_process.exec).
- Flag packages with install scripts that require elevated privileges.
Establish approval workflows New packages (never used in your organization before) should require security review before developers can install them. This doesn't mean reviewing every update to React—it means reviewing the first time someone wants to use a package called "fast-json-parser-ultra".
Common Pitfalls
Trusting download counts as legitimacy signals: Attackers can artificially inflate these numbers. The npm package ambar-src accumulated over 50,000 downloads, creating false legitimacy.
Skipping verification for "small" packages: Attackers often target utility packages because developers assume less code means less risk. A 50-line package can still exfiltrate your entire .env file.
Installing packages in production environments: Always install in isolated development or CI environments first. If a package attempts data exfiltration, you'll catch it before it reaches production secrets.
Ignoring transitive dependencies: You might carefully vet package A, but package A depends on package B, which was compromised last week. Always inspect the full dependency tree.
Disabling security warnings to "fix" CI builds: When npm audit or dotnet list package --vulnerable shows warnings, the solution is to address the vulnerability, not to add --audit=false to your pipeline.
Quick Reference Table
| Check Type | Tool/Method | Red Flag Threshold | Action |
|---|---|---|---|
| Publisher history | Manual review of registry profile | < 3 months old, < 5 packages published | Require senior approval |
| Repository verification | Compare package manifest to claimed repo | No repository link or non-matching URL | Reject package |
| Download analysis | Registry API or web interface | < 100 downloads OR sudden 10x spike | Extended testing period |
| Dependency depth | npm ls --all or dotnet list package --include-transitive |
> 5 levels deep for utility package | Investigate each transitive dep |
| Network behavior | Egress firewall logs during install | Any outbound connection during install | Block and report |
| File access | Process Monitor (Windows) or fs audit (Linux) | Reads outside project directory | Quarantine environment |
| Code obfuscation | Manual inspection of package source | Base64 strings > 100 chars, eval() usage | Security review required |
| Signature status | npm audit signatures or NuGet Package Explorer |
Missing or invalid signature | Reject if policy enforced |
Your dependency verification protocol should become as routine as code review. The 54,500 combined downloads of these malicious packages represent 54,500 potential breach points. Each package you install is code you're trusting with your application's security perimeter—verify that trust before you grant it.
