A gap register is a table with one row per hole in the inventory: what is missing, how you know, how big it is, who owns the fix, what the fix is and by when. It turns vague unease about the inventory into a list a team can close.
Why keep one
Reviews find gaps in conversation and forget them in the report. The NTIA minimum elements report says that where a dependency graph is incomplete, the author must state known unknowns explicitly, and that the default reading of the data should be that it is incomplete. A register is the working version of that principle.
The template
| Field | Content |
|---|---|
| ID | GAP-001 |
| Area | Repository, product or layer affected |
| Gap type | Missing lockfile, unidentified binary, vendored code, no inventory for repo, stale file, unknown license |
| Evidence | How it was found, with a file or command reference |
| Size | Number of repositories or components affected, if known |
| Risk note | What could go wrong because of it |
| Owner | A named person |
| Fix | One concrete action |
| Due | Date |
| Status | Open, in progress, closed, accepted |
Two example rows
| ID | Area | Gap type | Evidence | Size | Owner | Fix | Due |
|---|---|---|---|---|---|---|---|
| GAP-001 | Billing service | No lockfile | Repository has manifest only | 1 repo | Service lead | Commit lockfile, enable locked installs | Day 14 |
| GAP-002 | Admin portal | Vendored library, upstream unknown | Folder with no version file | 1 library | Portal lead | Identify upstream and version, add to inventory | Day 21 |
Gap types and typical fixes
| Gap type | Typical fix |
|---|---|
| No inventory for a repository | Generate one in CI and store per release |
| Stale inventory | Regenerate on every build |
| Unidentified binary | Find the build recipe or replace the file |
| Vendored copy | Identify upstream, record the version, or switch to a package |
| Unknown license | Look up the project, record the identifier, ask counsel to interpret |
| Missing hash | Add hashes to the generated file |
Rules that keep it honest
- Every row has one owner, not a team.
- Accepted gaps need a reason and a review date.
- Close rows with evidence, such as a new inventory file, not a message saying done.
- Count open rows at each checkpoint so progress shows up as a number.
Using it in an audit
An auditor or reviewer is more likely to trust a documented gap with a plan than an inventory that claims to be complete. Share the register alongside the inventory and update it on a regular schedule.
Safeguard's SBOM and dependency scanning and compliance and evidence automation can help keep the evidence attached to each closed row. A free scan is at gold.safeguard.sh/scan.
Quick check
How many gaps are acceptable?
There is no fixed number. What matters is that each is visible, sized and owned.
Who should hold the register?
The person accountable for the inventory, often a security or platform lead, with owners per row.
Sources
Last reviewed: 19 October 2026.
