No wildcard or excessively loose version ranges
Why it matters
Wildcard and unbounded version specifiers like *, latest, and >=1.0.0 mean that every npm install across your team and CI pipeline can resolve to a different package version — potentially including versions published hours ago by a compromised maintainer. SLSA L2 requires that the build be reproducible from a pinned artifact; "package": "latest" makes that impossible. CWE-1357 covers reliance on components that cannot be verified to a fixed state. SSDF PS.1 (Protect All Code from Unauthorized Access and Tampering) implicitly requires that the software composition be deterministic. AI tools in particular have a habit of generating "latest" as a version specifier — it seems convenient but it converts every npm install into a potential silent update from the registry.
Severity rationale
Medium because wildcard versions allow any future npm publish — including a malicious one from a compromised maintainer — to silently become your production code on next install.
Remediation
Replace all wildcard specifiers with pinned caret ranges. To find the currently-installed version for any dependency:
npm list package-name
Then update package.json:
// Before (dangerous):
"some-package": "*",
"another-package": "latest"
// After (safe):
"some-package": "^2.3.1",
"another-package": "^4.0.0"
Commit the resulting lock file change alongside this fix to ensure the pins are fully recorded.
Detection
-
ID:
no-wildcard-versions -
Severity:
medium -
What to look for: Inspect
dependenciesanddevDependenciesinpackage.jsonfor version specifiers that allow unbounded version resolution:*(any version),x(same as*),latest(resolves to whatever is latest at install time), or ranges like>=1.0.0without an upper bound. The^caret (e.g.,^1.2.3) is acceptable because it allows minor/patch updates within the same major. The~tilde (e.g.,~1.2.3) is acceptable.>=1.0.0without a<2.0.0upper bound is not acceptable. Count all instances found and enumerate each. -
Detector snippet (shell-capable tools only): If
rgis available, scanpackage.jsonfor literal"*"or"latest"version specifiers. Exit 0 with output means at least one wildcard exists — fail with count. Exit 1 with no output means no wildcards — pass. Exit >=2 — fall back to prose reasoning.rg '"(\*|latest)"' package.json -
Pass criteria: All version specifiers use specific versions (
1.2.3), caret ranges (^1.2.3), tilde ranges (~1.2.3), or other bounded ranges. No*,latest,x, or unbounded>=ranges. At least 1 implementation must be confirmed. -
Fail criteria: Any entry in
dependenciesordevDependenciesuses*,latest,x, or an unbounded>=range. -
Skip (N/A) when: No
package.jsondetected. -
Detail on fail:
"package.json has wildcard version specifiers: some-package: '*', another-package: 'latest' — these resolve to unpredictable versions at install time"List up to 5 affected packages. -
Remediation: Wildcard version specifiers mean your project installs whatever version is current at the time of
npm install. This can silently introduce breaking changes or malicious updates.Replace wildcards with specific pinned versions or caret ranges:
// Before (dangerous): "some-package": "*", "another-package": "latest" // After (safe): "some-package": "^2.3.1", "another-package": "^4.0.0"To see the currently installed version and use that as your pin:
npm list some-package
External references
- cwe · CWE-1357 — Reliance on Insufficiently Trustworthy Component
- owasp:2021 · A08 — Software and Data Integrity Failures
- slsa:1.0 · L2 — Hosted build platform with signed provenance
- ssdf:800-218 · PS.1 — Protect All Forms of Code from Unauthorized Access and Tampering
Taxons
History
- 2026-04-18·v1.0.0·Initial import from dependency-supply-chain·automated
- 2026-04-20·v1.1.0·Add Phase 6.0 detect-rg snippet for package.json wildcard-version detection·by cakleinman