"How to Audit Your Open Source Dependencies"

You can't secure what you can't see. Most developers have no idea how many open source dependencies their project actually uses. The number is always higher than expected.

This guide shows you how to audit your dependencies — find out what you're using, check for vulnerabilities, assess license risks, and create a compliance-ready report.

Why Audit Your Dependencies?

Three reasons:

1. Security — Find known CVEs before attackers do

2. Compliance — EU CRA, FDA, and NIST require dependency inventories

3. Risk management — Know what you're exposed to before it becomes a problem

Step 1: Generate an SBOM

An SBOM (Software Bill of Materials) is a structured list of every component in your project. It's the foundation of any audit.

pip install vulnledger
vulnledger scan . --json --output sbom.json

This generates a CycloneDX SBOM with:

- Every direct dependency

- Every transitive dependency

- Version numbers

- Package URLs (PURLs)

- License information

- Known vulnerabilities

Step 2: Check for Vulnerabilities

The SBOM scan automatically checks every dependency against OSV.dev. But for a deeper audit:

# Full scan with detailed output
vulnledger scan . --json --output audit-report.json

# Check specific package
vulnledger scan . | grep "requests"

What to look for:

- Critical CVEs (fix immediately)

- High CVEs (fix soon)

- Dependencies with no known CVEs (but check for abandoned packages)

Step 3: Assess License Risks

Open source licenses have different requirements:

# VulnLedger detects licenses automatically
vulnledger scan . --json --output sbom.json

Check for GPL in proprietary software — this is the most common license compliance issue.

Step 4: Check for Abandoned Packages

A package with no updates in 2+ years is a risk:

- No security patches when CVEs are found

- No compatibility updates for new language versions

- Potential maintainer abandonment

How to check:

- Visit the package's GitHub/PyPI page

- Check the last release date

- Look at open issues and PRs

- Check if the maintainer is active

If abandoned:

- Fork and maintain it yourself

- Find an actively maintained alternative

- Accept the risk and document it

Step 5: Check for Supply Chain Risks

Modern supply chain attacks target:

- Typosquatting — packages with names similar to popular ones

- Dependency confusion — private package names that conflict with public ones

- Compromised maintainer accounts — legitimate packages updated with malware

- Malicious packages — packages designed to steal credentials

How to check:

- Verify package publishers are trusted

- Check package download counts (low = suspicious)

- Review package code before first use

- Use lock files to pin exact versions

Step 6: Create a Compliance Report

For EU CRA, FDA, or other compliance frameworks, you need:

1. SBOM — Complete dependency inventory

2. Vulnerability assessment — CVE status for every component

3. License analysis — License for every component

4. Risk assessment — Overall risk rating

5. Remediation plan — What to fix and when

# Generate the full report
vulnledger scan . --json --output compliance-report.json

VulnLedger's dashboard generates compliance-ready PDF reports for SOC2, HIPAA, PCI-DSS, and GDPR.

Step 7: Set Up Ongoing Monitoring

An audit is a snapshot. You need continuous monitoring:

# Daily scan
vulnledger scan . --json --output daily.json

# Weekly comparison with previous scan
# (VulnLedger dashboard handles this automatically)

Audit Checklist

For every project:

- [ ] SBOM generated with all dependencies listed

- [ ] Vulnerability scan completed (critical/high/medium/low)

- [ ] License analysis completed (no GPL in proprietary code)

- [ ] Abandoned packages identified and alternatives found

- [ ] Supply chain risks assessed (typosquatting, dependency confusion)

- [ ] Compliance report generated

- [ ] Continuous monitoring set up

- [ ] Process documented for future audits

How VulnLedger Helps

VulnLedger automates most of this audit:

1. SBOM generation — one command

2. Vulnerability scanning — against OSV.dev database

3. License detection — automatic from package metadata

4. Risk scoring — weighted score based on severity and license

5. Compliance reports — PDF reports for SOC2, HIPAA, PCI-DSS, GDPR

6. Continuous monitoring — daily scans with alerts

pip install vulnledger
vulnledger scan . --json --output audit.json

Conclusion

Auditing open source dependencies is not optional — it's a business requirement. The EU CRA requires it by 2027. Insurance companies are starting to require it. Customers are asking for it in RFPs.

The good news: the audit process is straightforward. Generate an SBOM, scan for vulnerabilities, check licenses, assess risks, and set up monitoring. The tools are free. The process takes 30 minutes for your first audit.

Frequently Asked Questions

Q: How often should I audit?

A: For active projects, audit on every release. For maintenance-mode projects, audit quarterly. For all projects, set up daily vulnerability monitoring to catch new CVEs automatically.

Q: What if I find a GPL dependency in my proprietary project?

A: This is a serious compliance issue. Options: (1) Replace it with a permissive alternative, (2) Contact the maintainer about a commercial license, (3) Open-source your project, (4) Add it to your compliance risk register and document the decision. Don't ignore it.

Q: Can I automate the entire audit?

A: Most of it, yes. VulnLedger automates SBOM generation, vulnerability scanning, and license detection. Risk assessment and remediation planning require some manual judgment. The audit itself can be run in CI/CD on every build.

Q: What's the difference between an audit and a scan?

A: A scan checks for known CVEs. An audit is broader — it includes license analysis, abandoned package assessment, supply chain risk evaluation, and compliance reporting. Think of a scan as one part of a complete audit.

Q: Do I need to audit my development dependencies too?

A: Yes. Development dependencies (test frameworks, linters, build tools) can have CVEs too. A compromised test dependency can inject malicious code during the build process. Don't skip them.

Q: How do I handle transitive dependencies in my audit?

A: Use VulnLedger — it automatically scans transitive dependencies. Don't try to manually track the 500+ transitive dependencies in a typical project. That's what tools are for. The CLI does it in 5 seconds. Set it up in CI/CD and forget about it.

Q: What about container images?

A: Container images have their own dependency trees — base OS packages plus your application dependencies. VulnLedger scans Docker images with vulnledger scan docker://myapp:latest. This catches vulnerabilities in both layers.

Previous: Why Open Source Security Is Everyone's Problem

Next: SBOM: The Document Every Open Source Project Needs

See also: Dependency Security: How to Scan and Fix Vulnerable Packages