Spend the first 30 days getting an inventory for every repository and image, the next 30 fixing unknowns such as vendored code, forks and licenses, and the last 30 automating generation so the inventory stays current. Coverage first, quality second, automation third.
Days 0 to 30: coverage
Goal: every product and repository has a dated inventory, even a rough one.
- Enumerate repositories from the source host, CI, registries and workloads, and mark which have an inventory.
- Generate inventories from deployed images first, since they describe what runs.
- Open a gap register with owners.
- Record scope labels: runtime, development, build.
- Name one accountable person.
Exit test: no product without a file, and the count of repositories without inventory is known.
Days 31 to 60: quality
Goal: unknowns shrink.
| Work item | Output |
|---|---|
| Commit lockfiles for applications | Exact versions recorded |
| Identify vendored and copied code | Upstream and version per item |
| Record forks | Fork records with upstream base |
| Close unknown license fields | Identifier per component, open items flagged for counsel |
| Triage vulnerabilities by reachability | Short list with owners |
| Retire or archive dead repositories | Smaller estate |
The NTIA minimum elements report lists the baseline fields to check each record against: supplier, component name, version, other unique identifiers, dependency relationship, author and timestamp.
Days 61 to 90: automation
Goal: the inventory updates itself.
- Generate an inventory in CI on every build and store it per release.
- Add a pull request check that flags new dependencies and license changes.
- Schedule rescans, since new vulnerabilities appear against unchanged code.
- Set a freshness rule, for example no inventory older than the last release.
- Move the gap register review to a monthly meeting.
Exit test: a new release produces a new inventory without anyone asking.
What to measure
- Percent of repositories with a current inventory.
- Open gap register rows by age.
- Count of unidentified components.
- Days from release to inventory.
Pitfalls
- Starting with vulnerability triage before coverage. You will fix findings in repositories you can see and miss the ones you cannot.
- Treating the first inventory as final.
- Leaving integration to the acquired team alone without a named counterpart on the buyer side.
A realistic expectation
Smaller estates can finish in this window. Larger ones may need extra cycles for the quality step. If you slip, slip on quality, never on coverage.
Safeguard supports the automation step with SBOM and dependency scanning, policies and gates for pull requests, and continuous monitoring. Start with a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
See how a pull request check catches a new dependency before merge.
Quick check
Should the plan wait for integration to finish?
No. Inventory work does not depend on merging systems. Start with read access.
Sources
Last reviewed: 19 October 2026.
