Skip to content

fix(supply-chain): exclude pyproject metadata keys from dependency extraction#28

Open
CharmingGroot wants to merge 1 commit into
NVIDIA:mainfrom
CharmingGroot:fix/pyproject-metadata-deps
Open

fix(supply-chain): exclude pyproject metadata keys from dependency extraction#28
CharmingGroot wants to merge 1 commit into
NVIDIA:mainfrom
CharmingGroot:fix/pyproject-metadata-deps

Conversation

@CharmingGroot

Copy link
Copy Markdown

Fixes #2.

What this fixes

The Supply Chain analyzer (SC4) reported a HIGH "Known Vulnerable Dependency" on the requires-python key of pyproject.toml, matching it to the malicious PyPI advisory MAL-2025-41747 (a real malicious package literally named requires-python).

Root cause: pyproject.toml was parsed with _extract_packages_from_requirements, the requirements.txt line parser. It treats any line beginning with a name as a package, so PEP 621 [project] metadata keys (requires-python, name, version, …) were extracted as package names and looked up in OSV. requires-python appears in essentially every modern Python project, so this produced a false HIGH (and inflated risk scores toward DO_NOT_INSTALL) on almost any pyproject.toml.

Reproduced on v2.1.3 with a vanilla project:

[project]
name = "example"
requires-python = ">=3.12"
dependencies = ["httpx>=0.28"]
[HIGH] Supply Chain | Known Vulnerable Dependency: requires-python — MAL-2025-41747

The fix

Add _extract_packages_from_pyproject (using stdlib tomllib, no new dependency — the project already targets 3.12+) that collects package names only from PEP 621 dependencies / optional-dependencies and PEP 735 dependency-groups, parsing PEP 508 requirement strings. _analyze_dependencies routes pyproject.toml to it; requirements.txt, setup.py, and Pipfile keep the existing extractor, so this change is scoped to the false positive in the issue.

After the fix, requires-python (and other metadata keys) are no longer treated as packages, while real dependencies are still extracted and evaluated.

Testing

  • ruff check src/ tests/ and ruff format --check src/ tests/ pass.
  • pytest -m 'not integration' passes (607 passed, 11 skipped). The integration suite needs an LLM endpoint and is unaffected.
  • Added tests: metadata-key exclusion, optional/group dependency extraction, malformed TOML, no-[project] tables, non-PEP 508 / include-group entries, and that a real vulnerable dependency in pyproject is still flagged (SC4 via static fallback).

…traction

SC4 reported a HIGH "Known Vulnerable Dependency" on the `requires-python`
key of pyproject.toml, matching it to the malicious PyPI package literally
named `requires-python` (MAL-2025-41747). pyproject.toml was parsed with the
requirements.txt line extractor, which treats any `key = value` line as a
package, so PEP 621 metadata keys (`requires-python`, `name`, `version`, ...)
were looked up as packages — a false HIGH on essentially every Python project.

Add `_extract_packages_from_pyproject` (using stdlib `tomllib`) that pulls
package names only from PEP 621 `dependencies` / `optional-dependencies` and
PEP 735 `dependency-groups`, and route pyproject.toml to it. requirements.txt,
setup.py, and Pipfile keep the existing extractor.

Add tests for metadata-key exclusion, optional/group dependency extraction,
malformed TOML, and that real vulnerable deps in pyproject are still flagged.

Signed-off-by: CharmingGroot <ohyes9711@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

False positive: 'requires-python' pyproject field flagged as malicious PyPI package (MAL-2025-41747)

1 participant