Commit a lockfile for every deployable application

Description

Every application, service or other deployable artifact commits the lockfile produced by its package manager, listing the exact version of every direct and transitive dependency.

Libraries published for others to consume may leave the lockfile out of the published package, but should still commit it for their own tests and builds.

Rationale

Without a lockfile, the dependency tree is decided at build time by whatever the registry serves that minute. Two builds of the same commit can differ, and a new malicious release is picked up automatically.

Impact

Lockfile changes must be reviewed like code. Merge conflicts in lockfiles are more frequent.

Audit

1. List deployable projects.
2. Check each one has a committed, up-to-date lockfile for every ecosystem it uses.

Automated: every check must pass. Scanners report each check by its id.

postmortem

every manifest has its lockfile, committed

command: postmortem harden --json
control: CB-DEP-LOCK-001
coverage: auto

Remediation

1. Generate the lockfile with the package manager and commit it.
2. Remove lockfiles from ignore rules.

References

• Package Manager Best Practices OpenSSF, guide, accessed 2026-10-16
• SLSA specification v1.0 OpenSSF, standard, accessed 2026-10-16

Mappings

How this control relates to the other framework's: equivalent, stricter, looser, partial or related.

Threats mitigated

Related controls

• related CB-DEP-LOCK-002 Install from the lockfile without modifying it in builds

People and lifecycle