Summary
The Supply Chain analyzer reports a HIGH "Known Vulnerable Dependency" on the requires-python key of pyproject.toml, matching it to OSV malicious-package advisory MAL-2025-41747 (Malicious code in requires-python (PyPI)).
requires-python is not a dependency — it is the standard PEP 621 [project] metadata field declaring the supported interpreter range (e.g. requires-python = ">=3.12"). It appears in essentially every modern Python project, so this produces a false HIGH finding on almost any pyproject.toml.
Reproduction
Scan any directory containing a pyproject.toml with a [project] table, e.g.:
[project]
name = "example"
requires-python = ">=3.12"
dependencies = ["httpx>=0.28"]
skillspector scan ./example/ --no-llm
Observed finding:
[HIGH] Supply Chain | Known Vulnerable Dependency: requires-python — 1 advisory(ies):
MAL-2025-41747 (Malicious code in requires-python (PyPI))
location: pyproject.toml (line of the `requires-python = ...` field)
Root cause (likely)
The pyproject dependency extractor appears to treat the requires-python key name as a package name and look it up in OSV, which matches the real typosquat/malicious package literally named requires-python. The standard metadata keys (requires-python, name, version, description, readme, license, …) under [project] should be excluded from the dependency set; only dependencies, optional-dependencies, and dependency-groups entries are packages.
Impact
False HIGH on every Python project using pyproject.toml, inflating risk scores (contributes to spurious DO_NOT_INSTALL). Observed 11× across a multi-package repo during evaluation.
Suggested fix
Exclude PEP 621 [project] metadata field names from dependency extraction; parse package names only from the dependencies / optional-dependencies / dependency-groups arrays (and PEP 508 requirement strings), not from arbitrary table keys.
Environment: SkillSpector v2.0.0, static analysis (--no-llm), Python 3.12.
Summary
The Supply Chain analyzer reports a HIGH "Known Vulnerable Dependency" on the
requires-pythonkey ofpyproject.toml, matching it to OSV malicious-package advisory MAL-2025-41747 (Malicious code inrequires-python(PyPI)).requires-pythonis not a dependency — it is the standard PEP 621[project]metadata field declaring the supported interpreter range (e.g.requires-python = ">=3.12"). It appears in essentially every modern Python project, so this produces a false HIGH finding on almost anypyproject.toml.Reproduction
Scan any directory containing a
pyproject.tomlwith a[project]table, e.g.:Observed finding:
Root cause (likely)
The pyproject dependency extractor appears to treat the
requires-pythonkey name as a package name and look it up in OSV, which matches the real typosquat/malicious package literally namedrequires-python. The standard metadata keys (requires-python,name,version,description,readme,license, …) under[project]should be excluded from the dependency set; onlydependencies,optional-dependencies, anddependency-groupsentries are packages.Impact
False HIGH on every Python project using
pyproject.toml, inflating risk scores (contributes to spuriousDO_NOT_INSTALL). Observed 11× across a multi-package repo during evaluation.Suggested fix
Exclude PEP 621
[project]metadata field names from dependency extraction; parse package names only from thedependencies/optional-dependencies/dependency-groupsarrays (and PEP 508 requirement strings), not from arbitrary table keys.Environment: SkillSpector v2.0.0, static analysis (
--no-llm), Python 3.12.