"Dependency Security: How to Scan and Fix Vulnerable Packages"
Every Python, JavaScript, and Go project has vulnerable dependencies. Here's how to find them, fix them, and prevent them from coming back. Practical guide with real examples.
Your code might be secure. But your dependencies? Almost certainly not.
67% of software breaches involve known vulnerabilities in open-source components. That means the security of your application depends on packages you didn't write, maintained by people you've never met, updated on schedules you don't control.
This guide shows you how to take control: scan your dependencies, fix what's found, and automate the process so it never happens again.
Why Dependencies Are the Weak Link
When you install a package, you're trusting:
- The package maintainer (do they patch vulnerabilities?)
- The dependency tree (what does YOUR dependency depend on?)
- The package registry (is the package what it claims to be?)
Most developers only think about direct dependencies. But a typical project has 10-50x more transitive dependencies (dependencies of dependencies). A vulnerability in any one of them affects your project.
Real example: In 2024, log4j had a critical vulnerability (Log4Shell). Thousands of Java projects were affected — not because they used log4j directly, but because their dependencies depended on it.
How to Find Vulnerable Dependencies
Method 1: CLI Scan (Fastest)
pip install vulnledger
vulnledger scan .
This scans every dependency — direct and transitive — against the OSV.dev database. Takes 5 seconds.
Method 2: CI/CD Integration
Add scanning to your pipeline so it runs on every commit:
# .github/workflows/security.yml
name: Security Scan
on: [push, pull_request]
jobs:
scan:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: pip install vulnledger
- run: vulnledger scan . --ci
Method 3: Scheduled Monitoring
Set up daily scans to catch new CVEs:
# Daily scan
vulnledger scan . --json --output daily-scan.json
Or use VulnLedger's scheduled scans in the dashboard.
How to Fix Vulnerable Dependencies
Step 1: Prioritize
Not all CVEs are equal. Fix in this order:
1. Critical — known exploited vulnerabilities
2. High — exploitable with moderate effort
3. Medium — requires specific conditions
4. Low — theoretical risk
Step 2: Check for Breaking Changes
Before upgrading, check if the new version breaks your code:
# Check changelog
pip install --dry-run requests==2.31.0
# Check for breaking changes
pip install requests==2.31.0 --upgrade --dry-run
Step 3: Upgrade
# Python
pip install requests==2.31.0
# JavaScript
npm install [email protected]
# Go
go get github.com/gin-gonic/[email protected]
Step 4: Test
After upgrading, run your test suite to verify nothing broke:
pytest # Python
npm test # JavaScript
go test ./... # Go
Step 5: Commit and Push
git add requirements.txt package.json go.mod
git commit -m "fix: upgrade requests to 2.31.0 (CVE-2024-35195)"
git push
Preventing Future Vulnerabilities
Add CI/CD Security Gate
The most important step: automate scanning so vulnerable code can never reach production.
# .github/workflows/security.yml
name: Security Gate
on: [pull_request]
jobs:
scan:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: pip install vulnledger
- run: vulnledger scan . --ci # Fails build on critical/high CVEs
Monitor for New CVEs
New vulnerabilities are published daily. Set up monitoring:
# Daily scan
vulnledger scan . --json --output daily.json
Or use VulnLedger's continuous monitoring in the dashboard.
Generate SBOMs for Compliance
Attach SBOMs to your releases for audit trails:
vulnledger scan . --json --output sbom-release.json
Common Mistakes
Mistake 1: Only scanning direct dependencies
Your requirements.txt lists 10 packages. But those packages have 200+ transitive dependencies. Scan them all.
Mistake 2: Scanning manually
Manual scanning gets forgotten. Automate it in CI/CD.
Mistake 3: Ignoring "low" severity CVEs
Low-severity CVEs can be combined with other vulnerabilities to create high-severity attacks. Fix them when convenient.
Mistake 4: Not testing after upgrades
Upgrading a dependency can break your code. Always run tests after upgrading.
Mistake 5: Using outdated scanning tools
Some tools only check direct dependencies. Use VulnLedger for full transitive dependency scanning.
How VulnLedger Fits In
VulnLedger provides the complete dependency security pipeline:
1. Scan — One command checks all dependencies against OSV.dev
2. Report — SBOM with CVE status for every component
3. Monitor — Continuous scanning catches new CVEs
4. Fix — Fix Agent generates upgrade plans for open-source agents
5. Automate — CI/CD gate prevents vulnerable code from shipping
pip install vulnledger
vulnledger scan .
Conclusion
Dependency security is the most impactful thing you can do for your application's security. One scan catches dozens of vulnerabilities. One CI/CD gate prevents them from coming back. The tools are free, the process takes minutes, and the improvement is massive.
Next in this series: Secrets Management: Stop Hardcoding API Keys
Previous: Input Validation: The #1 Thing AI-Generated Code Gets Wrong