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

[CharmingGroot]

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).

[A-KumarSharma]

this is a correct one

[rng1995]

This is a clean, well-targeted fix for a real and embarrassing false positive (flagging the requires-python metadata key as the malicious PyPI package of the same name). I checked it against the existing analyzer and it holds up.

Correctness — verified

• The root cause is addressed properly: instead of line-parsing pyproject.toml with the requirements.txt parser, dependencies are now read only from PEP 621 [project].dependencies / optional-dependencies and PEP 735 [dependency-groups]. Metadata keys (requires-python, name, version, …) are structurally never considered, so the false HIGH disappears.
• The PEP 508 parsing regex and the version = … if op in ("==", "<=") logic are identical to _extract_packages_from_requirements, so extraction semantics stay consistent with the rest of the analyzer and no new behavior is introduced for the name/version handling. Reusing the established convention is the right call here.
• Routing ("pyproject.toml" in lower_path → new extractor, everything else → existing one) keeps the change scoped to the reported case; requirements.txt, setup.py, and Pipfile are untouched.
• Using stdlib tomllib adds no dependency (project targets 3.12+), and TOMLDecodeError → [] is the fail-safe direction for a false-positive fix.
• The isinstance(..., str) guards correctly skip PEP 735 {include-group = ...} table entries and any non-string list items.

Tests
Genuinely thorough for the size of the change: metadata-key exclusion, optional + dependency-group extraction, malformed TOML, no-[project] table, include-group / non-PEP 508 skipping, the vanilla-project regression for the original issue, and confirmation that a real vulnerable dependency in pyproject.toml is still flagged via SC4. That last test is the important one and it's present.

Minor / optional (non-blocking)

• Malformed TOML is silently swallowed to []. That's the right default for avoiding false positives, but a logger.debug (or warning) noting that a pyproject.toml failed to parse would help operators notice a genuinely broken/obfuscated manifest rather than have it silently contribute zero dependencies.
• Inherited from the shared regex (not introduced here, so just noting): package names beginning with a digit won't match, and only ==/<= pins record a version. Fine for name-based OSV/advisory lookups; if version-range precision is ever tightened for >=/~= deps, both extractors would want to evolve together.

Nice work — approving.

[rng1995]

@CharmingGroot - Please resolve the conflicts, minor issues and merge the PR.

[CharmingGroot]

Conflicts resolved and force-pushed. Ready to merge.