[SizzleUnrlsd]

Refs #210 (parts 2 and 3; the line positions of part 1 are left for a separate change, together with #207).

In package-lock.json, the keys of a dependency map are package names and its values version ranges. config-secrets read them as name = value pairs, so "js-tokens": "^4.0.0" was a high hardcoded credential named js-tokens. On mitmproxy this gave F086 and F087 (web/package-lock.json).

Change

All in plugins/secrets.py:

• Name maps of npm lock files bind no name. In package-lock.json and npm-shrinkwrap.json, a string value directly under dependencies, devDependencies, peerDependencies, optionalDependencies, requires (package names to version ranges) or bin (command names to paths, added after review: "secretlint": "bin/secretlint.js") is passed to the detector with no bound name. Only the credential-name rule depends on that name; provider patterns and the high-entropy check still judge the value.
• The lock file is still scanned. As the revised issue requires, nothing is excluded: resolved URLs (970 in mitmproxy's lock file), integrity hashes and any other field are judged as before, so a private-registry credential in a resolved URL is still reported.
• Only string leaves of a map are affected. In lockfile v1, dependencies maps package names to objects; the fields of those objects (version, resolved, requires, ...) keep their names.
• Scope. Other JSON files, package.json included, and every TOML file are judged as before. poetry.lock and composer.lock have the same shape but a .lock suffix, which the configuration scan does not read today, so they are not concerned.
• Documentation. The module docstring no longer says that configuration files are not scanned.

Validation

• New tests/test_lock_dependency_maps.py (no existing test changed): lockfile v3 and v1 maps of both file names, including a bin map, are not reported (the 4 cases failed before the change); a credential in a resolved URL, a credential-named key outside a dependency map in a lock file, and a dependencies map in another JSON file are still reported.

• Full suite: 1650 passed, 1 failed. The failure, test_packaging::test_the_version_has_one_source_of_truth, comes from a stale local editable install (metadata 0.8.0 vs 0.21.0) and fails identically on main.

• ruff check, ruff format --check on the new file and mypy pass; secrets.py already differs from ruff format on main, not on the changed lines.

• mitmproxy at be75825, enterprise plugins at ac35460, [email protected], no baseline, compared with the 87 results of the 2026-10-02 reference: exactly F086 and F087 disappear, nothing else changes. 87 → 85 results, high 18 → 16. Plugin digests are identical.

• Regression snapshots: unchanged (read-only diff of every repository).

Open points

The issue scopes the change to npm lock files, so these are not extended here:

• package.json has the same dependency maps, and the false positive is more frequent there: "jsonwebtoken": "^9.0.2" in dependencies is reported as a credential.
• pnpm-lock.yaml is read by the line-based scan and would show the same problem.