Your build pulls in 847 dependencies. One of them just downloaded your AWS credentials.
Researchers have identified dozens of malicious GlassWorm extensions in the wild, each iteration more sophisticated than the last. These aren't simple typosquatting attacks—they're carefully engineered to evade detection while sitting in your dependency tree. If your current security posture assumes package repositories are trustworthy by default, you're exposed.
This checklist provides a verifiable path to harden your dependency management against supply chain attacks. Each item maps to specific controls in ISO 27001 (A.8.31 on separation of development, testing, and production) and NIST Cybersecurity Framework v2.0 (ID.SC-4 on suppliers and third-party partners).
What This Checklist Covers
You'll establish controls for dependency intake, monitoring, and response. This isn't about blocking all third-party code—that's impractical. It's about creating verification layers that catch malicious packages before they reach production. The checklist assumes you're using modern package managers (npm, pip, Maven, NuGet) and have CI/CD pipelines in place.
Prerequisites
Before starting, ensure you have:
- Inventory of all package managers in use across teams
- Access to your CI/CD configuration files
- Authority to enforce pre-commit hooks and pipeline gates
- Budget for at least one dependency scanning tool (open source options available)
Dependency Security Checklist
1. Enable dependency lock files across all projects
Every repository must use lock files (package-lock.json, Pipfile.lock, go.sum). These pin exact versions and their checksums.
✓ Good looks like: git grep -l "package-lock.json" returns every Node.js project. Your CI fails if lock files are missing or out of sync with manifests.
2. Implement automated dependency scanning in CI/CD
Configure tools like OWASP Dependency-Check, Snyk, or GitHub's Dependabot to run on every pull request. Set failure thresholds for critical/high vulnerabilities.
✓ Good looks like: Your pipeline blocks merges when dependencies with CVSS scores ≥7.0 are detected. You have documented exceptions with expiration dates.
3. Verify package signatures and checksums
Configure your package managers to validate cryptographic signatures where available (npm, Python wheels, Maven Central signatures).
✓ Good looks like: Your .npmrc includes audit-level=moderate and fails on unsigned packages. Maven's settings.xml requires GPG signature verification for releases.
4. Restrict package sources to approved registries
Whitelist specific package repositories. Block installation from arbitrary URLs or Git repos without review.
✓ Good looks like: Your .npmrc and pip.conf explicitly define allowed registries. Attempts to install from github.com/random-user/sketchy-lib fail at the package manager level.
5. Monitor for new dependencies in pull requests
Implement automated alerts when PRs add or update dependencies. Require security team review for new direct dependencies.
✓ Good looks like: Your GitHub Actions workflow comments on PRs with dependency changes, tagging @security-team. New dependencies require two approvals instead of one.
6. Establish a dependency review process
Before approving new dependencies, check: maintainer history, update frequency, download counts, known vulnerabilities, and licensing.
✓ Good looks like: You have a documented 5-point checklist. Dependencies under 6 months old or with <1000 weekly downloads trigger additional scrutiny. This satisfies ISO/IEC 27001:2022 A.5.19 on information security in supplier relationships.
7. Configure runtime monitoring for unexpected network activity
Deploy egress monitoring to detect dependencies making unauthorized network calls, especially to unfamiliar domains or IP addresses.
✓ Good looks like: Your runtime application self-protection (RASP) or network monitoring flags when application code contacts domains not in your allowlist. Alerts trigger within 60 seconds.
8. Implement Software Bill of Materials (SBOM) generation
Generate SBOMs in CycloneDX or SPDX format for every build. Store them with version metadata for incident response.
✓ Good looks like: Your CI pipeline outputs an SBOM artifact. You can answer "which services use lodash 4.17.19?" in under 5 minutes.
9. Set up vulnerability database subscriptions
Subscribe to security advisories for your language ecosystems (npm advisories, PyPI security, RubySec, etc.). Configure alerts for dependencies you use.
✓ Good looks like: You receive notifications within 4 hours of disclosed vulnerabilities affecting your dependencies. Your team has a defined SLA for patching based on CVSS scores.
10. Create dependency update policies with testing requirements
Define maximum age thresholds for dependencies. Require automated test passage before updating production dependencies.
✓ Good looks like: Dependencies over 90 days old trigger automated PRs. Updates only merge after passing your full test suite plus manual security review for major version bumps.
11. Isolate build environments from production secrets
Never store production credentials in locations accessible to build processes. Use separate service accounts with minimal permissions for CI/CD.
✓ Good looks like: Your CI service account can read code and write artifacts but cannot access production AWS credentials, database passwords, or API keys. This aligns with PCI DSS v4.0.1 Requirement 6.4.3 on script security.
12. Enable dependency confusion protection
Configure package managers to prioritize internal registries over public ones. Use scoped packages or namespaces.
✓ Good looks like: Your npm packages use @yourcompany scope. Your .npmrc explicitly lists registry URLs in priority order, with internal registry first.
Common Mistakes
Treating all dependencies equally: Not all dependencies carry the same risk. Direct dependencies with broad permissions need stricter controls than transitive dependencies with limited scope.
Scanning only at deployment: Malicious code can exfiltrate data during build time. Scan before code enters your CI environment.
Ignoring deprecated packages: Unmaintained dependencies won't receive security patches. Consider GlassWorm's evolution—static defenses fail against actively developed threats.
Manual-only review processes: You cannot manually review every transitive dependency update. Automate the scanning; reserve human review for new direct dependencies and major version changes.
Next Steps
- Run a dependency audit this week:
npm audit,pip-audit, or equivalent for your stack - Implement items 1-4 within 30 days—these provide immediate risk reduction
- Schedule quarterly reviews of your approved package sources and update policies
- Document your dependency security requirements in your secure development lifecycle (SDL) documentation
The GlassWorm discoveries prove that malware authors are investing in evasion techniques specifically designed to hide in dependency chains. Your response must be systematic, automated, and continuous. Start with this checklist, measure your coverage, and iterate as threats evolve.
