Is your requirements.txt actually reproducible?

Paste your requirements.txt and get every line that lets two installs differ: bare names, >= ranges, missing --hash, --extra-index-url (dependency confusion), plain-http sources and git or URL dependencies that are not pinned to a commit or hash. It is the part of a supply-chain review you can do in thirty seconds, and a one-file CLI keeps it from regressing in CI.

Nothing is uploaded. The text you paste is read in this browser and never leaves your device, and this tool makes no network calls of its own. It scans the file only; it does not look up vulnerabilities and is not security advice.

Paste your requirements.txt

require hashes (flag exact pins with no --hash)

Paste a requirements.txt above and click Check requirements.

Want it as a CI gate?

Same logic, zero dependencies, one file plus the shared module. It reads one local file and nothing else:

node requirements-check.mjs                          # audit ./requirements.txt
node requirements-check.mjs --fail-on high           # exit 1 on index/source/VCS risks
node requirements-check.mjs --fail-on medium         # ...and unpinned versions
node requirements-check.mjs --require-hashes --fail-on any
node requirements-check.mjs --json                   # machine-readable

Get requirements-check.mjs and classify.mjs from the repo. Node 18+, nothing to install, no network calls.

Common questions

Why does an unpinned requirements.txt matter?

pip resolves ranges and bare names to the newest matching release at install time, so two installs a week apart can produce different environments. A bad release, a yanked version or a hijacked package then reaches production without any change to your repository. An exact pin (==) plus hashes makes the install repeatable.

What is the difference between a pin and a hash?

A pin (==1.2.3) names a version. A hash (--hash=sha256:...) names the exact file. Without hashes, a file re-uploaded or replaced under the same version number installs silently. pip-compile --generate-hashes and uv pip compile --generate-hashes write both, and pip install --require-hashes enforces them.

Why is --extra-index-url flagged?

With two indexes pip considers candidates from both and picks the highest version, so a public package with the same name as your private one can win. That is the dependency-confusion attack. Prefer a single --index-url that proxies both, or pin with hashes.

Does this tool upload my requirements.txt?

No. The text is read in this page and never leaves your device. The page makes no network calls, and the CLI reads one local file.

Is this a security audit?

No. It is a line scan of the file, not pip's resolver and not a vulnerability database lookup. It tells you how reproducible and tamper-resistant the install is, not whether a pinned version has known CVEs. It is not security or legal advice.

More: how to pin and hash Python dependencies with pip-tools or uv