fix(lfp): don't flag npm aliased deps as lockfile poisoning (#713)

* fix(lfp): don't flag npm aliased deps as lockfile poisoning

npm aliased dependencies ("foo": "npm:bar@1.2.3") install `bar` under
node_modules/foo and record the real package name in the lockfile's
`name` field. The analyzer was comparing the resolved URL against the
path-derived name, so legitimate aliased entries — e.g. @openai/codex
installed as @openai/codex-darwin-arm64 — were reported as poisoning.

Parse `name` and use it for the URL convention check when present;
fall back to the path-derived name otherwise.

* docs(lfp): add lockfile poisoning doc with npm alias limitation

Revert the insecure Name field fix and document npm aliased
dependencies as a known limitation with a workaround using
--lockfile-poisoning-trusted-urls.

* update flag

* fix: Disable on-demand malicious package scanning e2e tests

---------

Co-authored-by: Abhisek Datta <abhisek.datta@gmail.com>

Author: Sahilb315

docs/lockfile-poisoning.md

@@ -0,0 +1,75 @@
+# Lockfile Poisoning Detection
+
+## What is Lockfile Poisoning?
+
+Lockfile poisoning is a supply chain attack where an attacker modifies a package manager's lockfile (e.g., `package-lock.json`) to redirect dependency resolution to malicious packages. Since lockfiles are auto-generated and often rubber-stamped in code review, subtle changes to resolved URLs or integrity hashes can go unnoticed.
+
+For example, an attacker might change:
+
+```json
+"node_modules/lodash": {
+  "resolved": "https://registry.npmjs.org/lodash/-/lodash-4.17.21.tgz"
+}
+```
+
+to:
+
+```json
+"node_modules/lodash": {
+  "resolved": "https://registry.npmjs.org/evil-pkg/-/evil-pkg-1.0.0.tgz"
+}
+```
+
+When `npm install` runs, `evil-pkg` is downloaded and placed at `node_modules/lodash/`. Application code importing `lodash` now executes attacker-controlled code.
+
+## How vet Detects It
+
+vet applies two checks to every package in a `package-lock.json` (lockfile version 2+):
+
+### 1. Trusted Source Check
+
+Verifies that the `resolved` URL points to a known, trusted registry host. By default, only `https://registry.npmjs.org` is trusted. Additional trusted registries (e.g., private registries) can be configured.
+
+This catches attacks where the URL points to an attacker-controlled server.
+
+### 2. Path Convention Check
+
+Verifies that the package name derived from the `node_modules/...` key matches the package name in the resolved URL path. For example, `node_modules/lodash` should resolve to a URL containing `lodash/-/`.
+
+This catches attacks where the URL points to a different package on the same trusted registry.
+
+## Usage
+
+```bash
+# Scan a project for lockfile poisoning
+vet scan -D /path/to/project 
+
+# With a private registry trusted
+vet scan -D /path/to/project --trusted-registry="https://registry.internal.example.com"
+```
+
+## Known Limitations
+
+### npm Aliased Dependencies
+
+npm supports [dependency aliases](https://docs.npmjs.com/cli/v10/configuring-npm/package-json#dependencies) using the `npm:` prefix syntax:
+
+```json
+{
+  "dependencies": {
+    "codex": "npm:@openai/codex@^0.77.0"
+  }
+}
+```
+
+This installs `@openai/codex` under `node_modules/codex`. The resulting lockfile has a path/URL mismatch that is indistinguishable from a poisoning attack, causing a false positive.
+
+**Workaround:** Add the aliased package's registry URL to the trusted URLs list:
+
+```bash
+vet scan -D /path/to/project --trusted-registry="https://registry.npmjs.org/@openai/codex"
+```
+
+### Lockfile Version Support
+
+Only npm lockfile version 2+ is supported. Older lockfile formats (version 1) use a different structure and are not analyzed.

test/scenarios/scenario-9-malware-analysis.sh

@@ -10,6 +10,15 @@ if [ "$E2E_VET_INSIGHTS_V2" != "true" ]; then
   exit 0
 fi
 
+# We have a separate E2E for on-demand malicious package scanning which requires
+# a SafeDep Pro subscription, hence we skip those tests here unless explicitly
+# enabled via VET_E2E_ON_DEMAND_MALICIOUS_PACKAGE_SCANNING.
+if [ -z "$VET_E2E_ON_DEMAND_MALICIOUS_PACKAGE_SCANNING" ]; then
+  echo "Skipping scenario-9-malware-analysis.sh as VET_E2E_ON_DEMAND_MALICIOUS_PACKAGE_SCANNING is not set"
+
+  exit 0
+fi
+
 # Not a malicious package
 $E2E_VET_SCAN_CMD scan --purl pkg:/npm/@clerk/nextjs@6.9.6 \
   --malware --malware-analysis-timeout 60s --fail-fast