MAL-DEPINT Lockfile and Manifest Integrity

npm ci and its yarn and pnpm equivalents fetch exactly what the lockfile says. One edited resolved URL or stripped integrity hash can redirect an install to an attacker's tarball on every developer and CI machine, before any application code runs.

What Vulkro detects

Three shapes, all Medium, fully offline:

• MAL-DEPINT-001: a resolved tarball URL whose host is a raw IPv4 address, or whose scheme is http://. Other HTTPS hosts are not flagged, because private registries and corporate mirrors are common.
• MAL-DEPINT-002: a registry tarball entry (resolved ending in .tgz or .tar.gz) with no integrity field while other entries have one, the mark of a hand-edited lockfile.
• MAL-DEPINT-003: a package.json dependency specified as a git+ / git:// repository, a raw http(s):// tarball, or a file: path, all of which bypass registry resolution, hashes and provenance. Semver specifiers, workspace:, npm: aliases and catalog: are not flagged.

None of these prove a dependency is malicious, and the rule never certifies a lockfile clean.

How to fix

• Regenerate the lockfile from the manifest against your real registry and diff it to expose hand-edits.
• Require HTTPS named-host resolved URLs and an integrity hash on every registry tarball.
• Replace git and URL specifiers with published, versioned packages.

References

• OWASP A08:2021

See also: Confidence model.

---

This page is generated by vulkro rules export <out-dir> from Vulkro's built-in detector catalogue. Edits made by hand are overwritten on the next regeneration.