A supply chain platform should cover five zones: source repositories, the build process, the artifacts you produce, the registries where they sit, and what actually runs. Map each zone to a tool and an owner. The empty cells on the map are your blind spots, whatever the vendor brochure says.
Why a map beats a feature list
Feature lists describe what a tool can do. A coverage map shows what it does in your environment today. Many programs have a good scanner pointed at half of their repositories and nothing at the container images built from them.
The five zones
| Zone | What lives there | Typical risk | Question to ask |
|---|---|---|---|
| Source | Repos, manifests, lockfiles | Vulnerable or malicious dependency | Are all repos connected, including archived ones still deployed? |
| Build | CI configuration, actions, plugins | Tampered build, leaked credentials | Are build dependencies inventoried like app dependencies? |
| Artifacts | Packages, images, binaries | Wrong content shipped | Is an SBOM produced per release? |
| Registries | Internal and public package stores | Unvetted or stale artifacts | Who can publish, and are policies applied at pull time? |
| Runtime | Deployed workloads | Drift from what was scanned | Can you match what runs to a scanned build? |
SLSA's build track describes this concern in levels. Build L1 requires provenance showing how a package was built, L2 requires signed provenance generated by a hosted build platform, and L3 requires a hardened build platform. Provenance is one more artifact a platform may collect or verify. Check which level your needs and your tools support.
Language and ecosystem coverage
List every ecosystem you ship: for example JavaScript, Python, Java, Go, Rust, .NET, container base images, and system packages. For each, record whether the platform reads the manifest, the lockfile, and the built artifact. Gaps often appear in less common ecosystems and in vendored code copied into a repo with no package record.
Fill in your own map
- Draw the table above with your real systems in each row.
- Write the tool in each cell, or write none.
- Mark who owns that tool.
- Color each cell: covered, partly covered, not covered.
- Rank the red cells by business impact and pick the top two to close this quarter.
Common blind spots
- Repositories created after the platform was connected, never added.
- Forks and internal mirrors.
- Build plugins and CI actions pulled from public sources.
- Images built outside the main pipeline.
- Third party code delivered as a zip and committed.
Asset discovery, which finds repositories and services you did not list, helps with the first three.
Keep the map alive
Review it every quarter, and whenever you adopt a new language, registry, or deployment target. Treat a new red cell like a new risk.
A worked example
Take a hypothetical company that thinks it has good coverage. Its platform scans all sixty source repositories. The platform owner draws the five zone map and discovers the following.
Source is covered, except for two repositories created last month. Build has no coverage: CI actions and build plugins are not inventoried, even though they run with access to secrets. Artifacts are partly covered: SBOMs are made for four of nine services. Registries have no policy: any developer can pull any public package into a build. Runtime has an inventory of deployed images but no link back to the scanned builds.
The map is mostly red outside source. The team picks two actions for the quarter. First, add build tooling to the inventory so the pipeline's own dependencies are visible. Second, generate SBOMs for the remaining five services and tag each image with the SBOM reference. Registry policy and runtime linkage go on the next quarter's list. Because they wrote it down, nobody argues about priorities.
Mapping template
| Zone | Tool today | Owner | Coverage | Next action |
|---|---|---|---|---|
| Source | Scanner on 58 of 60 repos | Platform | Partial | Add two repos |
| Build | None | Platform | None | Inventory CI actions |
| Artifacts | SBOM for 4 of 9 services | Service teams | Partial | Generate for rest |
| Registries | None | Security | None | Define approved sources |
| Runtime | Image list | Operations | Partial | Link to builds |
How containers change the picture
Container images bundle operating system packages, language packages, and sometimes binaries copied in by hand. A source scan sees only the declared dependencies. An image scan sees what was actually assembled. Scan images at build time and again on a schedule, since new advisories appear after the build. The two views differ, and both are needed.
Questions about build coverage
- Which third party actions or plugins run in our pipelines, and are they pinned to a specific version or digest?
- Which secrets can a build step read?
- Does our build produce provenance, and who can check it?
- Can a developer run a release build on a laptop?
SLSA describes provenance as a record of what entity built an artifact, what process they used, and what the inputs were, and its build levels grow from provenance existing, to signed provenance from a hosted build platform, to a hardened build platform. Use those levels as a vocabulary for your own goals.
Reviewing the map
Put the map on a single page and review it quarterly. Share it with engineering leadership so gaps get budget and attention. Add a column for the date of last verification so a stale map is obvious.
Try it yourself
Click through it at your own pace, or open it full screen. Open the demo to see what an image scan reveals that a source scan does not, such as operating system packages in base layers.
Safeguard offers asset discovery, SBOM and dependency scanning, and policies and gates to help fill several zones. Run the free scan at gold.safeguard.sh/scan to see what an inventory of one project looks like.
Quick check
Is source scanning enough?
No. Images, build tooling, and registries add components that never appear in a repo manifest.
How do I find unconnected repositories?
Compare a list from your source host against the connected list, or use asset discovery.
How often should I redraw the coverage map?
Each quarter, and when you adopt a new language, registry, or deployment target.
Sources
Last reviewed: 19 October 2026.
