Build reproducibility verified
Why it matters
Using npm install in CI instead of npm ci means the lockfile is advisory rather than enforced — if package.json and the lockfile diverge (a common accident after a manual install), CI installs different versions than the lockfile specifies, silently breaking reproducibility. SLSA L2 and SSDF SP 800-218 PW.4.1 both require that the build process is deterministic and traceable. A non-reproducible build makes security audits meaningless: you cannot verify what code shipped without knowing exactly which dependency versions were installed.
Severity rationale
Info because non-frozen CI installs are a build hygiene defect that undermines reproducibility guarantees, but they rarely cause immediate functional failures unless a transitive dependency changes in a breaking way.
Remediation
Replace npm install with npm ci in all CI configuration. npm ci errors if the lockfile and package.json are out of sync, enforcing that the lockfile is the authoritative source.
# .github/workflows/ci.yml
- name: Install dependencies
run: npm ci
For Docker builds, copy the lockfile before installing:
COPY package.json package-lock.json ./
RUN npm ci --only=production
For Yarn: yarn install --frozen-lockfile. For pnpm: pnpm install --frozen-lockfile.
DetectionPro
The detection method for this pattern is part of AuditBuffet Pro.
The full method (what to look for, pass and fail conditions, and how results get reported) ships inside the Code Quality Essentials Audit. The pattern definition, severity rationale, and remediation remain openly licensed under CC-BY-4.0.
External references
- slsa:1.0 · L2 — SLSA Level 2 — Hosted build platform with tamper resistance
- ssdf:800-218 · PW.4.1 — Reuse existing, well-secured software where feasible
Taxons
History
- 2026-04-18·v1.0.0·Initial import from code-quality-essentials·automated