Export every merged change that touched a dependency manifest or lockfile in the audit period, join it to its pull request, ticket and deployment, and give the auditor that list as the population. Explain how you built it, because completeness is the question they will ask first.
Why the population matters
Sampling only works if the list the sample comes from is complete. If your list omits emergency changes or automated updates, the sample says little about the real process. Our post on how auditors sample evidence, population and sample covers the principle. This post covers building the list for dependency changes specifically.
Sources for the list
Use at least two independent sources and reconcile them:
- Version control. Commits merged to production branches that modified manifest or lockfile paths, in the audit window.
- Pull request system. The matching pull requests, with approvers and checks.
- Change tickets. Tickets categorised as dependency or library changes.
- Deployment records. Releases that shipped each commit.
If a commit exists in version control with no ticket, that is a finding to explain, not hide. Automated update bots and direct pushes by administrators are the usual culprits.
Fields to include
| Field | Why it helps |
|---|---|
| Commit hash and date | Anchors the change in time |
| Repository and path | Shows scope |
| Package, old version, new version | Shows what actually changed |
| Pull request ID and approver | Shows review |
| Change ticket ID and category | Shows classification |
| Gate or scan result | Shows security check |
| Deployment time | Shows when it reached production |
| Path taken | Standard, normal or emergency |
Build it reproducibly
Write a small script that produces the list from the sources and keep the script and its output date. If an auditor asks you to rerun it for a different window, you can. Avoid building the list by hand in a spreadsheet, which is hard to defend.
Check completeness two ways. First, compare the count of production deployments that included a manifest change against the number of rows. Second, pick a few known changes from memory and confirm they appear.
Common holes
- Bot commits. Include them, labelled as bot authored, with the human approver.
- Squashed or rebased history. Use the merge event, not just commit messages.
- Monorepos. Filter by path, and include nested manifests.
- Direct hotfixes. Include them and show the emergency path record.
- Container base image bumps. Decide whether they are in scope and say so.
What to hand over
Give the auditor the list, the method note, the extraction date and a point of contact. Offer to provide any row's linked evidence quickly. A short README beats a long email.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how an inventory can be filtered to see what changed.
Quick check
Do we include changes made by a bot?
Yes. Label them clearly and show the human review of the merge, if there was one.
What if a change has no ticket?
List it anyway, explain why, and record the corrective action. Hiding it is the riskier choice.
Safeguard can produce an SBOM and dependency inventory for each build to help reconcile what shipped, and you can run a free scan at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
