Background
Reported by a Discord engineer after testing CVE Lite CLI against a pnpm codebase with first-party GitHub-hosted dependencies. Three packages resolved from codeload.github.com and github.com URLs were flagged as malicious when they are legitimate Discord packages installed from source control.
While #616 / PR #617 fixed the immediate bug (private registry detection not firing for pnpm), a fuller solution would handle git/URL dependencies more intelligently.
Feature request (from the reporter)
1. Parse the resolution target, not just the package name.
Before classifying a dependency, distinguish registry specifiers (name@version) from git/URL/tarball specifiers (github:org/repo#sha, https://.../archive/<sha>.tar.gz). Name-based reputation and typosquat heuristics should not be applied to git-URL deps — the dependency-confusion threat model those heuristics target does not apply when the registry namespace is never consulted.
2. Trust-rank by the actual host and org.
For git deps, the security boundary is the source host and organization plus the pinned ref. Support an allowlist of trusted source orgs so first-party repositories are not treated as untrusted public packages.
3. Recognize commit-SHA pinning as a positive signal.
A full 40-char commit hash cannot be silently re-pointed the way a tag or branch can. Specifiers pinned to a SHA should be scored as lower mutation risk than floating refs.
4. Calibrate severity and wording to the evidence.
"Remove it from your dependencies immediately" is appropriate for a confirmed compromise, not a heuristic that has not inspected the resolution target. For git deps that resolve to a non-allowlisted org, prefer a graded advisory (e.g., "unverified source — confirm ownership") and state which signal fired.
5. Surface a verifiable rationale.
Include the resolved URL, org, and ref in the finding. The current message names only the package, forcing manual investigation to determine whether the route is internal/trusted or genuinely suspect.
Impact
Items 1-3 would suppress false positives on legitimate first-party git dependencies outright. Items 4-5 would make any residual advisory actionable instead of alarming.
Background
Reported by a Discord engineer after testing CVE Lite CLI against a pnpm codebase with first-party GitHub-hosted dependencies. Three packages resolved from
codeload.github.comandgithub.comURLs were flagged as malicious when they are legitimate Discord packages installed from source control.While #616 / PR #617 fixed the immediate bug (private registry detection not firing for pnpm), a fuller solution would handle git/URL dependencies more intelligently.
Feature request (from the reporter)
1. Parse the resolution target, not just the package name.
Before classifying a dependency, distinguish registry specifiers (
name@version) from git/URL/tarball specifiers (github:org/repo#sha,https://.../archive/<sha>.tar.gz). Name-based reputation and typosquat heuristics should not be applied to git-URL deps — the dependency-confusion threat model those heuristics target does not apply when the registry namespace is never consulted.2. Trust-rank by the actual host and org.
For git deps, the security boundary is the source host and organization plus the pinned ref. Support an allowlist of trusted source orgs so first-party repositories are not treated as untrusted public packages.
3. Recognize commit-SHA pinning as a positive signal.
A full 40-char commit hash cannot be silently re-pointed the way a tag or branch can. Specifiers pinned to a SHA should be scored as lower mutation risk than floating refs.
4. Calibrate severity and wording to the evidence.
"Remove it from your dependencies immediately" is appropriate for a confirmed compromise, not a heuristic that has not inspected the resolution target. For git deps that resolve to a non-allowlisted org, prefer a graded advisory (e.g., "unverified source — confirm ownership") and state which signal fired.
5. Surface a verifiable rationale.
Include the resolved URL, org, and ref in the finding. The current message names only the package, forcing manual investigation to determine whether the route is internal/trusted or genuinely suspect.
Impact
Items 1-3 would suppress false positives on legitimate first-party git dependencies outright. Items 4-5 would make any residual advisory actionable instead of alarming.