Dependency lockfile committed + reviewed
Demonstrate that dependency lockfiles are present in all applicable repositories, committed to version control, and reviewed through the standard pull request or merge request process before changes are accepted.
Description
What this control does
This control requires that dependency lockfiles (such as package-lock.json, Gemfile.lock, poetry.lock, or go.sum) be committed to version control repositories and subjected to code review processes before merging. Lockfiles pin exact versions and cryptographic hashes of all direct and transitive dependencies, preventing unintended or malicious package substitution during build or deployment. By treating lockfile changes as code changes requiring review, organizations gain visibility into supply chain modifications and can detect suspicious dependency updates before they reach production environments.
Control objective
What auditing this proves
Demonstrate that dependency lockfiles are present in all applicable repositories, committed to version control, and reviewed through the standard pull request or merge request process before changes are accepted.
Associated risks
Risks this control addresses
- Attackers inject malicious code through dependency confusion or typosquatting attacks that replace legitimate packages with compromised versions during installation
- Compromised upstream package maintainer accounts publish malicious updates that are automatically pulled without human oversight
- Non-deterministic builds produce inconsistent artifacts across environments due to floating version ranges resolving to different package versions
- Transitive dependency vulnerabilities are introduced silently when indirect dependencies are upgraded without explicit review
- Build infrastructure is poisoned through man-in-the-middle attacks that serve malicious packages during dependency resolution
- Developers bypass security scanning by manually installing packages without updating lockfiles, creating runtime-production discrepancies
- Rollback and incident response efforts are hampered by inability to reproduce exact historical dependency states
Testing procedure
How an auditor verifies this control
- Obtain a complete inventory of application repositories containing dependency management files (package.json, requirements.txt, pom.xml, Cargo.toml, etc.) from the organization's source code management system
- Select a representative sample of at least 10 repositories spanning different technology stacks and development teams for detailed review
- For each sampled repository, verify the presence of corresponding lockfiles (package-lock.json, Pipfile.lock, etc.) in the main or master branch using repository browsing or clone operations
- Extract the commit history for lockfiles in each sampled repository covering the past 90 days, identifying all commits that modified these files
- Review pull request or merge request records associated with each lockfile modification to confirm they underwent code review by at least one team member other than the author
- Examine code review comments and approval records to verify reviewers actively assessed the dependency changes rather than automatically approving
- Verify branch protection rules or equivalent policies are configured to prevent direct commits to protected branches, enforcing the review workflow for all changes including lockfiles
- Interview at least three developers or engineering managers to confirm awareness of lockfile review requirements and their rationale within the secure software development lifecycle
Where this control is tested