A lockfile counts as supporting evidence, not complete evidence. It proves which exact dependency versions a build used and, through git history, who changed them and when. It does not prove that someone reviewed the change. Pair it with pull request approvals to show a controlled change.
What a lockfile actually records
A lockfile pins the resolved version of every direct and transitive package. For npm, the documentation says npm ci installs from the lockfile, exits with an error if package.json and the lock disagree, and never writes to either file, so installs are essentially frozen. That behavior is what makes a lockfile useful to an auditor: the build on Tuesday used the same tree you reviewed on Monday.
In git, each lockfile edit is a commit with an author and timestamp. That is a change log you did not have to build.
What it does not prove
A lockfile is a record of state, not of approval. Three gaps matter:
- A commit can go straight to the default branch if branch rules allow it.
- A lockfile can change as a side effect of an unrelated install, with no one noticing the transitive swap.
- A lockfile in the repo says nothing about what is running in production unless your build uses it.
SOC 2 change management is about authorizing, testing and approving changes before release. Your auditor will ask for a sample of changes and want to see the approval for each. A lockfile diff with no reviewer does not answer that.
Make the lockfile carry its weight
- Commit lockfiles for every deployable application.
- Use the frozen install command in CI (npm ci, or the equivalent in your package manager) so a mismatch fails the build.
- Protect the default branch. GitHub documents settings such as requiring pull request reviews and requiring status checks before merging.
- Treat a lockfile diff as reviewable. Reviewers should look at which packages changed, not only that tests pass.
- Keep the pull request link in the release record, so the sample trail runs from deploy to PR to commit.
Libraries differ from applications. A published library often ships without consumers using its lockfile, so the lockfile mostly protects your own CI. Say that plainly if an auditor asks.
A quick evidence packet
When the auditor requests a sample, give them a table like this for each sampled change:
| Item | Where it lives |
|---|---|
| What changed | Lockfile diff in the PR |
| Who approved | Review record on the PR |
| What tested it | Required status check results |
| When it shipped | Deploy log or release tag |
If any cell is blank for a sampled change, fix the process, not the paperwork.
Try it yourself
Open the demo and watch how a manifest turns into a dependency inventory. Notice how much the pinned versions drive what gets listed and checked.
Click through it at your own pace, or open it full screen.
Where Safeguard fits
Safeguard reads manifests and lockfiles to build an SBOM and scan dependencies, and its policies and gates can block a pull request that adds a package breaking your rules. That gives you a reviewable record beside the diff. A free scan is at https://gold.safeguard.sh/scan.
Quick check
Is a lockfile enough for a SOC 2 change sample?
No. The auditor also needs to see authorization, such as a review approval, and test results. The lockfile shows what changed, not who agreed to it.
Should I commit a lockfile for a library?
Usually yes for your own CI reproducibility, but remember consumers may resolve their own versions. Do not claim the lockfile protects your users.
Sources
Last reviewed: 19 October 2026.
