Possible to register & be aware of pip-compile lock files?

[petemounce]

Sorry, perhaps this is not the correct place to report this.

TL;DR - is there a way to configure snyk so it understands we have both direct-dependencies and transitive-dependencies manifests inside our repository?

Detail

We manage a python service. It has a folder structure like:

/components
  /requirements.txt
  /requirements.linux.lock
  /requirements.macos.lock
/tools
  /requirements.txt
  /requirements.linux.lock
  /requirements.macos.lock

We manage our dependencies with uv, because it's (dramatically) faster than pip. It is drop-in-compatible however (same file formats etc); one can think of it as faster pip for our purposes here.

The requirements.txt files are manifests of our direct dependencies. We exclusively use == to pin; we like build hermeticity.

We use uv pip compile ... to create the requirements.*.lock files; we support development on linux & macos; deployment on linux. We generate these lock files because we want to be aware of, and pin, our transitive dependencies to be aware of our total attack surface and increase our build hermeticity across the team and CI.

We have a CI job to make certain that when we change a requirements.txt file we regenerate the lock files so they are not stale.

We have snyk wired up against our git-based source control; it automatically scans the repository. It picks up the requirements.txt files but not the lock files.

We see false-positive reports from components/requirements.txt - for example, [email protected] is vulnerable via SNYK-PYTHON-REQUESTS-6928867. However, we can see via our lock file that we depend on [email protected].

Is there a way to get snyk to understand our lock-files?

Perhaps it could scan our requirements.txt files as now but then use our lock files to filter those reports with the additional knowledge of what versions are actually in use.

Constraints in play

dependabot is in play within the repository. It understands requirements.in and requirements.txt files. It is directory-configured.

We don't want dependabot to aim at our transitive-dependencies lock files because it would open PRs against them that are not actionable by us until each of our direct-dependencies' upstream upgrades - at which point we'd have a new dependabot PR against that, making the others against the transitive-dependencies just be noise.