Skip to main content

Dependency Scanning in Python: Vulnerability Detection

Dependency vulnerabilities are security flaws in third-party libraries that your Python application uses. A single vulnerable transitive dependency (a library that your dependency depends on) can compromise your entire application. For example, if your Flask app imports a library that imports an outdated cryptography library with a known vulnerability, your app inherits that risk. Dependency scanning automates the detection of known vulnerabilities in your dependency tree, allowing you to patch or replace vulnerable packages before attackers exploit them. OWASP data shows that ~60% of vulnerability remediation time is spent simply identifying where vulnerabilities exist; automated scanning reduces this to seconds.

Understanding Python Dependency Trees​

When you install a Python package with pip install package-name, pip downloads the package and its direct dependencies. Those dependencies may have their own dependencies (transitive dependencies), creating a tree of packages. For example, installing flask pulls in werkzeug, jinja2, and other libraries:

flask==2.3.0
├── werkzeug>=2.3.0
├── jinja2>=3.0
├── itsdangerous>=2.0
├── click>=8.0
└── ...
  werkzeug==2.3.0
  ├── markupsafe>=2.0
  └── ...

If any package in this tree has a known vulnerability, your application is at risk. Manual auditing is impractical; automated scanning tools crawl your dependency tree and check each package against vulnerability databases like the National Vulnerability Database (NVD).

Using pip-audit for Vulnerability Detection​

pip-audit is a command-line tool maintained by PyPA (the Python Packaging Authority) that scans your environment for known vulnerabilities. It is the recommended tool for local vulnerability scanning:

# Install pip-audit
pip install pip-audit

# Scan current environment
pip-audit

# Scan a specific requirements file
pip-audit --requirements requirements.txt

# Scan and output as JSON for CI/CD pipelines
pip-audit --format json > vulnerabilities.json

# Scan and ignore specific vulnerabilities (use cautiously)
pip-audit --ignore-ids PYSEC-2023-1234

The output shows each vulnerable package, the vulnerability ID, severity, and a link to details:

Found 3 vulnerabilities in your dependencies.

Name: requests
Version: 2.28.0
Vulnerability: PYSEC-2023-56
Fix Version: 2.28.1
Severity: HIGH
URL: https://...

Name: cryptography
Version: 38.0.0
Vulnerability: PYSEC-2022-1234
Fix Version: 39.0.0
Severity: CRITICAL
URL: https://...

Integrate pip-audit into your CI/CD pipeline to block deployments when vulnerabilities are detected:

# Example GitHub Actions workflow
# .github/workflows/security.yml
name: Security Scan
on: [push, pull_request]
jobs:
  pip-audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-python@v4
        with:
          python-version: '3.11'
      - name: Install dependencies
        run: pip install -r requirements.txt
      - name: Run pip-audit
        run: pip-audit --desc

This workflow automatically scans every commit and pull request, preventing merges when vulnerabilities are detected.

Automated Dependency Updates with Dependabot​

Dependabot is a GitHub service that automatically creates pull requests to update outdated dependencies. When a new version of a library is released or a security patch is published, Dependabot detects it and opens a PR for you to review and merge:

# Enable Dependabot in your repository
# .github/dependabot.yml
version: 2
updates:
  # Check for Python package updates
  - package-ecosystem: "pip"
    directory: "/"
    schedule:
      interval: "daily"
    allow:
      - dependency-type: "direct"
      - dependency-type: "indirect"
    pull-request-branch-name:
      separator: "-"
    reviewers:
      - "security-team"
    labels:
      - "dependencies"
      - "python"
    open-pull-requests-limit: 10

Dependabot checks for updates daily, weekly, or monthly depending on your schedule. It creates separate PRs for each update, allowing you to review and test changes individually. For security patches, you should merge quickly; for feature releases, you can test more thoroughly.

Building a Private Vulnerability Database​

For organizations with strict security requirements, you might maintain a private vulnerability database or use a commercial tool like Snyk, Checkmarx, or Black Duck. These tools provide:

  • Real-time vulnerability data (faster than public databases).
  • Integration with artifact repositories (preventing vulnerable libraries from being downloaded).
  • License compliance scanning (detecting GPL or other restricted licenses).
  • SBOM (Software Bill of Materials) generation for supply chain transparency.

For most teams, pip-audit + Dependabot is sufficient. Larger organizations benefit from commercial tools that provide deeper insights and policy enforcement.

Handling Vulnerable Dependencies​

When pip-audit detects a vulnerability, you have several options:

Option 1: Upgrade the vulnerable package. Check if a patched version is available. Update requirements.txt and test thoroughly:

# Before: requests==2.28.0 (vulnerable)
# After: requests==2.28.1 (patched)
pip install --upgrade requests
pip freeze > requirements.txt

Option 2: Replace the vulnerable package. If the maintainer is unresponsive or the vulnerability is unfixable, use a maintained fork or alternative library.

Option 3: Mitigate or isolate. If neither of the above is feasible, mitigate the risk by restricting the vulnerable library's exposure (e.g., running it in a sandbox or restricting network access).

Option 4: Accept and document the risk. In rare cases, you may decide the vulnerability is not exploitable in your context (e.g., a vulnerability in a CLI tool that is never called with untrusted input). Document the decision and the risk assessment.

Creating a Software Bill of Materials (SBOM)​

An SBOM is a detailed inventory of all components in your application. It helps track vulnerabilities across your software portfolio:

# Generate SBOM with pip-audit (experimental)
pip-audit --format cyclonedx > sbom.json

# Or use pip-tools to generate requirements with pinned versions
pip freeze > requirements.lock

SBOMs are increasingly required for government contracts and security compliance frameworks (NIST, SOC 2). Tools like cyclonedx and syft generate SBOMs in standardized formats.

Key Takeaways​

  • Most vulnerabilities come from transitive dependencies, not direct ones; use pip-audit to scan the entire dependency tree.
  • Run pip-audit on every commit and pull request; block merges when high or critical vulnerabilities are detected.
  • Use Dependabot to automatically create PRs for updates and security patches; review and merge quickly.
  • Lock dependency versions in requirements.txt or pyproject.toml to ensure reproducible builds and prevent surprise vulnerabilities from version bumps.
  • Maintain a Software Bill of Materials (SBOM) for compliance and incident response.

Frequently Asked Questions​

Should I pin dependency versions or allow updates?​

Pin major and minor versions (e.g., flask==2.3.*) but allow patch updates (e.g., flask==2.3.1 → flask==2.3.2). This gets security patches automatically while preventing breaking changes. Use a tool like pip-tools to manage version constraints.

What if a vulnerability is in a transitive dependency I do not directly use?​

You are still responsible for patching it. Upgrade the package that depends on the vulnerable library, or submit an issue asking them to upgrade their dependency.

Is it safe to ignore old vulnerabilities?​

No. Old vulnerabilities are still exploitable. Always upgrade unless the vulnerable code path is provably unreachable in your application.

How do I test that an upgrade does not break my application?​

Use automated testing (unit tests, integration tests) and staging deployments. Run your full test suite after every dependency upgrade before deploying to production.

Can I use pip-audit in a CI/CD pipeline that is not GitHub Actions?​

Yes. pip-audit is a standalone CLI tool that runs on any platform. You can use it in GitLab CI, Jenkins, CircleCI, or any other CI/CD system.

Further Reading​