T08 · Insecure Dependencies
Note
- Location
- package-lock.json:19
- Finding
- Dependency Resolved Through a Third-Party npm Registry Mirror## Vulnerability Details **File Location**: `package-lock.json`, lines 19-23 **Vulnerability Type**: Supply-chain exposure through an unofficial dependency source **Risk Level**: Low ### Vulnerable Code ```json "node_modules/commander": { "version": "12.1.0", "resolved": "https://registry.npmmirror.com/commander/-/commander-12.1.0.tgz", "integrity": "sha512-Vw8qHK3bZM9y/P10u3Vib8o/DdkvA2OtPtZvD871QKjy74Wj1WSKFILMPRPSdUSx5RFK1arlJzEtA4PkFgnbuA==", "license": "MIT", "engines": { "node": ">=18" } } ``` ### Technical Analysis The lockfile directs package managers to download `commander` from `registry.npmmirror.com`, a third-party npm registry mirror, rather than the official npm registry. This introduces an additional external trust boundary into the installation process. The included SHA-512 integrity value provides meaningful protection: a mirror cannot silently replace the referenced package with different content unless the replacement also matches the pinned hash. Therefore, no direct malicious dependency substitution is demonstrated by the audited files. Exploitation would generally require simultaneous compromise or malicious modification of both the dependency artifact reference and its integrity value, or compromise of the lockfile before installation. The mirror can nevertheless affect dependency availability and artifact delivery. Depending on organizational policy, use of an unapproved registry can also bypass registry-level provenance, monitoring, allowlisting, or retention controls applied to the official or organization-controlled registry. ### Attack Path 1. A user or CI system installs the project using the committed lockfile. 2. The package manager follows the `resolved` URL and contacts the third-party mirror. 3. An attacker compromises the project lockfile, the package publication workflow, or another mechanism capable of changing both the artifact reference and integrity hash ...[truncated 1050 chars]
- Remediation
- ## Remediation Suggestions 1. Regenerate the lockfile using the official npm registry or an organization-controlled, authenticated registry: ```bash npm config set registry https://registry.npmjs.org/ rm -rf node_modules package-lock.json npm install ``` 2. Review the regenerated lockfile and verify that dependency `resolved` URLs point only to approved registries. 3. Continue retaining and enforcing SHA-512 integrity metadata. 4. Enforce the approved registry in CI through a committed `.npmrc` or equivalent build policy: ```ini registry=https://registry.npmjs.org/ ``` 5. Use `npm ci` in automated builds so installation fails when the manifest and lockfile differ. 6. Add dependency provenance, vulnerability, and lockfile-change review checks to CI. 7. Treat changes to registry URLs, dependency versions, and integrity hashes as security-sensitive code-review events.