The Problem: Undetected Malicious Packages
Your dependency scanner missed it. Your code review didn't catch it. A malicious package slipped through your CI/CD pipeline and into production because you were checking for known CVEs but not for packages flagged as malicious in the OpenSSF Malicious Packages repository.
The OpenSSF tracks malicious packages using identifiers starting with 'MAL-' (like MAL-2025-6812) rather than standard CVE numbers. These aren't vulnerabilities in legitimate code—they're hostile packages designed to steal credentials, exfiltrate data, or establish backdoors. The OSV (Open Source Vulnerabilities) API indexes them, but most teams don't query for them because their security tools only scan for CVEs.
The Pattern of Malicious Package Infiltration
This isn't a single incident—it's a recurring pattern across npm and PyPI:
Day 0: An attacker publishes a package with a name similar to a popular library (typosquatting) or creates a legitimate-looking utility package.
Day 1-7: Your developers add the package as a dependency. It appears in package.json. Your scanner runs and finds nothing because it's only checking the NIST NVD for CVEs.
Day 8: The package executes during build or runtime. It reads environment variables, accesses your AWS credentials, or phones home with repository contents.
Day 9-30: You remain unaware. The malicious package may have already been reported to OpenSSF and flagged as MAL-2025-XXXX, but your pipeline never queries the OSV API for malicious package identifiers.
Day 31+: You discover the breach through an unrelated alert, incident response investigation, or external notification.
Identifying Control Failures
Failure 1: No OSV API Integration in CI/CD
Your pipeline scans dependencies against vulnerability databases but doesn't check the OSV API specifically for malicious packages. The OSV schema distinguishes between vulnerabilities (CVE-YYYY-XXXXX) and malicious packages (MAL-YYYY-XXXXX), but standard vulnerability scanners ignore the latter.
Failure 2: Missing Lockfile Enforcement
If your team runs npm install instead of npm ci, you're not enforcing the exact dependency tree captured in package-lock.json. The npm ci command requires a package-lock.json file to function and will fail if the file is missing or inconsistent with package.json. Without this enforcement, developers can inadvertently introduce new packages that bypass your security checks.
Failure 3: No Pre-Commit Dependency Validation
Developers add dependencies locally without any automated check before code reaches the repository. By the time CI runs, the malicious package is already committed and may have executed in multiple development environments.
Failure 4: Reactive Posture
Your security program waits for CVEs to be published. Malicious packages often get flagged in OpenSSF's repository within hours of discovery, but you only learn about them when a scanner vendor adds them to their commercial database weeks later.
Compliance Standards and Requirements
NIST 800-53 Rev 5 - Control SA-10 (Developer Configuration Management)
SA-10(1) requires you to employ automated mechanisms to make security-relevant information available to developers during the design, development, implementation, and modification of the system. Querying the OSV API for malicious packages during CI/CD directly satisfies this control by providing real-time security information to your development pipeline.
NIST CSF v2.0 - ID.RA-01 (Vulnerabilities in Assets Are Identified)
The framework requires you to identify and document vulnerabilities in your assets. Malicious packages are vulnerabilities—they're intentional threats embedded in your dependency tree. If you're only scanning for CVEs, you're not meeting the intent of this function.
PCI DSS v4.0.1 - Requirement 6.3.2
This requirement mandates that you address common coding vulnerabilities during software development. While it doesn't explicitly name malicious dependencies, the principle applies: you must identify and prevent the introduction of hostile code into your payment processing environment. An undetected malicious package in your Node.js payment API violates this requirement.
ISO 27001 - Control 8.31 (Separation of Development, Test, and Production Environments)
If a malicious package executes in development and accesses production credentials (common when developers use shared AWS profiles), you've failed to maintain proper separation. Scanning dependencies before they reach any environment is a foundational control for this requirement.
Actionable Steps for Your Team
Action 1: Add OSV API Checks to Your CI/CD Pipeline
Integrate OSV Scanner or direct API queries into your GitHub Actions, GitLab CI, or Jenkins pipelines. Configure it to fail builds when any dependency matches a MAL-* identifier. This takes 30 minutes to implement and catches threats that your existing scanner misses.
Action 2: Enforce npm ci in All Build Processes
Update your CI/CD configuration to use npm ci instead of npm install. This command requires package-lock.json and installs exactly what's specified in the lockfile, preventing version drift and unauthorized dependency additions. Add a pre-commit hook that verifies package-lock.json is present and consistent with package.json.
Action 3: Scan Lockfiles, Not Just Manifests
Your package.json lists direct dependencies. Your package-lock.json lists the entire transitive dependency tree—including the nested package where malicious code often hides. Point your OSV queries at the lockfile to catch threats three levels deep in your dependency graph.
Action 4: Implement Pre-Commit Dependency Validation
Add a Git pre-commit hook that runs OSV Scanner locally before code leaves a developer's machine. This catches malicious packages before they reach your repository and prevents them from executing in CI/CD environments where they might access secrets.
Action 5: Monitor the OpenSSF Malicious Packages Feed
Subscribe to updates from the OpenSSF repository. When a new MAL-* entry appears for an ecosystem you use, immediately scan your repositories for that package. Don't wait for your next scheduled dependency audit.
The malicious package problem isn't hypothetical—the OpenSSF repository documents thousands of confirmed hostile packages. Your pipeline either checks for them explicitly, or you're relying on luck.
