PRP: Extractor for Pipfile dependencies

[Abhinav-143x]

• Software distribution method or binary type: Python Pipfile files used by Pipenv to declare top-level project dependencies in TOML format.

• Popularity of distribution method: Pipenv is a maintained Python packaging tool and Pipfile is its primary source manifest for declaring project dependencies and constraints. Pipenv documents Pipfile as the human-readable TOML file containing production dependencies under [packages] and development dependencies under [dev-packages].

• Any critical, emergent vulnerability associated with software from the distribution method: Dependencies declared in Pipfile map to the PyPI ecosystem, which is supported by OSV.dev. There are no vulnerabilities in the Pipfile format itself; the value is extracting PyPI package inventory declared in Pipfile so OSV-SCALIBR can match vulnerable packages.

  Recent OSV.dev PyPI examples include:

  • pkg:pypi/urllib3 affected by GHSA-2xpw-w6gg-jr37 / CVE-2025-66471
  • pkg:pypi/urllib3 affected by GHSA-34jh-p97f-mpxf / CVE-2024-37891

• Resources:

  • https://pipenv.pypa.io/en/latest/pipfile.html
  • https://github.com/google/osv-scalibr/blob/main/docs/supported_inventory_types.md
  • https://github.com/google/osv-scalibr/blob/main/extractor/filesystem/list/list.go
  • feat: Add python extractors to list and documentation #189
  • feat(guidedremediation): Add manifest reader and writer for Pipfile #1407
  • feat: Add relax strategy support for Pipfile #1478
  • https://osv.dev/vulnerability/GHSA-2xpw-w6gg-jr37
  • https://osv.dev/vulnerability/GHSA-34jh-p97f-mpxf

Gap confirmation

SCALIBR currently supports Pipfile.lock through python/pipfilelock, but does not appear to register an inventory extractor for plain Pipfile.

This leaves a source-manifest gap for Python projects where a Pipfile is present but a Pipfile.lock is absent, unavailable, stale, or intentionally omitted from the scanned artifact.

This proposal is for source inventory extraction only. It does not replace python/pipfilelock, which remains the better source for resolved dependency inventory when available.

Rationale

Pipenv already uses Pipfile as the source manifest for declaring project dependencies. SCALIBR already supports several Python inventory sources, including requirements.txt, setup.py, Pipfile.lock, pdm.lock, poetry.lock, uv.lock, Conda metadata, and installed wheel/egg metadata.

A Pipfile extractor would cover the source manifest case where dependency names and constraints are present in a structured TOML file, but no resolved lockfile is available to scan.

There is also prior project precedent for this being a distinct inventory artifact: PR #189 renamed the existing lockfile extractor to python/pipfilelock because a future plain python/Pipfile extractor may be useful. Later PRs #1407 and #1478 added Pipfile support to guided remediation, but not filesystem inventory extraction.

Proposed scope

• Match only files whose basename is exactly Pipfile.
• Parse only TOML dependency sections:
  • [packages]
  • [dev-packages]
• Emit PyPI package inventory for entries where a package name is explicit.
• Support simple string specs, for example:
  • requests = "*"
  • flask = "==2.0.1"
  • numpy = ">=1.20.0,<2.0.0"
• Support table entries when a version field is present, for example:
  • django = { version = ">=3.2" }
  • sentry-sdk = { version = ">=1.0.0", extras = ["flask"] }
• Preserve version/comparator metadata only for exact pins and simple single-comparator constraints.
• For wildcard or compound constraints such as numpy = ">=1.20.0,<2.0.0", emit package identity only without a concrete version, because the source manifest does not identify an installed version.
• Record file and line locations for emitted packages.
• Skip invalid, empty, or unsupported entries.

Out of scope

• Pipfile.lock
• Dependency resolution
• Lockfile generation
• Installing packages
• Reading package indexes
• Evaluating environment markers
• Resolving extras into dependency graphs
• Custom Pipenv package categories beyond [packages] and [dev-packages]
• Local path dependencies
• VCS dependencies
• Remote file dependencies
• Editable installs
• Private index/source resolution

Suggested plugin name

python/pipfile

PURL output format

pkg:pypi/{package}@{version}

Examples:

pkg:pypi/flask@2.0.1
pkg:pypi/requests
pkg:pypi/numpy

[github-actions]

Welcome to the OSV-SCALIBR patch reward program!
Your issue has been added to our triage queue and will reviewed
shortly. The panel usually takes a decision once every other week,
so it can take up to two weeks before you hear back from us,
sometimes longer depending on available capacity.
Please, do not start the work until the panel has reached a
decision. Although we always welcome contributions, unapproved
work is not eligible for a reward.
For more details, please see the rules page.
~The OSV-SCALIBR PRP team

[another-rex]

Thank you for the proposal. We are happy to accept this PRP! Please feel free to start working on it.

Note: Ideally we can support transitive package resolution as well with enrichers after the initial extraction. I believe we can just reuse the requirements.txt transitive resolving.

[github-actions]

Congratulations, your request has been approved! 🎉
This means that you can start working on this contribution.
❗ Please take a moment to fill the participation form
If you are unsure where to start, we have compiled a set of
useful guides in our documentation:

• Writing a new vulnerability detector plugin
• Writing a new inventory extraction plugin
• Writing a new secret detector plugin
• General style guide

~The OSV-SCALIBR PRP team

[Abhinav-143x]

@another-rex Thank you for the acceptance and the note on transitive resolution.

The implementation is now ready: #2296

What was done:

• Added extractor/filesystem/language/python/pipfile/pipfile.go — implements python/pipfile as a filesystem.Extractor that parses [packages] and [dev-packages] TOML sections from Pipfile, emitting pkg:pypi/ inventory with DepGroupMetadata for dev group tagging
• Added pipfile_test.go and testdata/ covering valid, empty, and invalid files; FileRequired edge cases; and registry lookup
• Registered python/pipfile in extractor/filesystem/list/list.go under PythonSource
• Updated docs/supported_inventory_types.md to list Pipfile → python/pipfile

On the transitive resolution note: Noted. The current transitivedependency/requirements enricher hard-casts package metadata to requirements.Metadata (which carries the raw requirement string for pypi.ParseDependency). Extending it to also cover python/pipfile packages would require either a shared metadata interface or a dedicated transitivedependency/pipfile enricher. Left as a follow-up — happy to look at it after this is reviewed if that would help.