This tool vs. checking pip/npm configs by hand
Names no specific company or product — this compares against the manual habit most developers already have: grepping requirements.txt or pip.conf for --extra-index-url, and skimming package.json for a dependency name that looks like it should be internal.
What checking by hand actually does
Grepping your own config is free and needs no tool, which is exactly why
it is the default. You search requirements.txt or
pip.conf for the string --extra-index-url, and
you scan package.json's dependency names for anything that
looks like it should be an internal package rather than a public one.
That method has failure modes specific to this domain that this tool
exists to close. First, knowing to search for
--extra-index-url at all requires already knowing it is a
substitution risk — that fact comes from Alex Birsan's 2021
research and pip's own documentation, not from anything in
requirements.txt itself, so a grep only helps someone who
already learned the risk before opening the file. Second, a grep of
package.json alone cannot see the interaction that actually
matters: an unscoped dependency name is only exposed when
.npmrc separately sets a private default registry, and
reading one file tells you nothing about the other, so a list of
unscoped names by itself does not say which ones, if any, are at risk.
Third, there is no single command a developer already runs that checks
both ecosystems' configuration shapes together — npm
audit and pip's own tooling check known vulnerabilities in
packages you depend on, not the shape of your own index and registry
configuration. Fourth, a by-hand grep proves nothing afterward: there is
no file, line number, or fix to paste into a PR description or an audit
trail, only a recollection that someone looked.
| Question | Where to answer it |
|---|---|
| I want to search my own requirements.txt for --extra-index-url, and I already know that string is worth searching for. | Checking by hand — free, and works once you already know what to search for. |
| I want every --extra-index-url use across requirements*.txt, constraints*.txt, pip.conf/pip.ini, and my CI workflows found automatically, without knowing in advance which files to check. | This tool — scans the standard locations for both, in the browser or the CLI. |
| I want to know whether an unscoped npm dependency name is actually exposed, which depends on what .npmrc sets. | This tool — reads package.json and .npmrc together and only flags a name once a private default registry is in effect. |
| I want one command that checks both the pip and the npm configuration shape at once, instead of two separate manual searches. | This tool's CLI — python3 check.py scans a whole checkout for both patterns in one pass. |
| I want a report I can paste into a PR description or an audit trail: a file, a line number, the exact match, and the fix. | This tool — every finding carries all four; --format json for a machine-readable version. |
Checking by hand is not wrong so much as unverifiable: a developer who already knows both patterns, and remembers to check both files together every time either one changes, would eventually catch most of what this tool catches. What it structurally cannot do is teach itself the 2021 research, cross-reference two files it was not told to compare, or leave behind a record that the check happened at all — and this tool's whole design, on both the browser page and the CLI, is built around closing exactly those gaps for free.
This tool needs no account and makes no network calls of its own: the browser page runs entirely client-side and nothing you paste ever leaves your device, and the CLI is a single stdlib-only script that reads files already on disk.
Common questions
What does grepping for --extra-index-url or an unscoped npm name actually catch?
It catches exactly what you already knew to look for. If you already know pip's --extra-index-url can let a second index outbid your private one on version number, a grep for the literal string finds every use in requirements.txt, pip.conf, or a workflow's pip install step. The gap is upstream of the grep: most requirements.txt files that use it were written before dependency confusion was a known risk, so nobody flagged the line as worth searching for in the first place.
Why doesn't grepping package.json for unscoped names tell you anything on its own?
Because an unscoped dependency name is only a dependency-confusion risk in combination with .npmrc setting a private default registry — that is the exact interaction that makes the public registry a fallback for the same name. Reading package.json alone cannot see whether that condition holds, so a list of unscoped names by itself does not tell you which ones, if any, are actually exposed. You would have to check both files together and reason about the interaction yourself, every time either one changes.
Is there a command a developer already runs that checks both patterns together?
No. npm audit and pip's own tooling check known-vulnerability databases against packages you already depend on; neither reads your own .npmrc or requirements.txt for these two configuration shapes, and neither ecosystem's default tooling looks at the other's files at all. A developer who wants both checked has to know to look for both, in both files, and do it by hand — there is no single existing command that already covers this.
Can I put a by-hand grep in a PR description as evidence I checked?
Only as a note that you looked and did not personally notice anything — it names no specific line, no specific finding, and no fix, and there is nothing to attach to a ticket or audit trail besides your own recollection. A structured report with a file, a line number, the exact pattern matched, and the remediation for it is stronger evidence than "I grepped and it looked fine."
Open Dependency Confusion Check to scan your own config, or read what is dependency confusion? for the full mechanism.