Build a Complete Software Asset Inventory in a Week with Safeguard

You can build a working software asset inventory in Safeguard in one working week by connecting one asset source per day, in a fixed order: source control on day one, container registries and runtime on day two, packages and supplier SBOMs on day three, AI models and AI coding agents on day four, and ownership, shadow assets and the first gates on day five. Asset Discovery (GA) does the enumeration continuously once each source is connected, so the week is spent on access, scope and owners rather than on spreadsheets. By Friday you have a graph of every repository, image, package, SBOM, AI model, vendor and workload Safeguard can see, an owner on each, a list of ungoverned assets, and coverage numbers you can track from then on.

This post is the rollout plan. If you want the reference view of what Asset Discovery catalogs and how enforcement applies to discovered assets, read the companion post on what Safeguard Assets catalogs and who owns it. Here we go day by day, with the exit check for each day and the mistakes that push a one week rollout into a quarter.

Key takeaways

• Asset Discovery (GA) covers seven asset classes in Safeguard's docs: source repositories, container images, packages, AI models, SBOMs, vendors and runtime workloads. Connect them in that rough order, one per day.
• SCA and SBOM generation (GA) fill in what is inside each repository and image, including transitive dependencies, so the inventory is more than a list of names.
• The Safeguard CLI and local runner (GA) cover repositories you cannot or will not give a cloud service OAuth access to. The runner uploads the SBOM and findings, never source code.
• Portal (GA) takes supplier SBOMs by drag and drop upload in CycloneDX or SPDX. The /v1 REST endpoints in the asset docs are not available yet, so plan on upload, not API.
• TPRM (GA) holds vendors, so the inventory can answer "which supplier gave us this".
• AI-BOM discovery (GA) and AI agent discovery (GA) bring models, coding agents, their MCP servers and skills into the same inventory. AI agent discovery is switched on per organisation and each person agrees on their own computer.
• Policies and gates (GA) turn the finished inventory into enforcement. The docs checked on 25 October 2026 list three policy actions, Block, Warn and Notify, with approvals handled through time boxed exceptions.
• Autonomous remediation (GA) can open fix pull requests once the inventory exists, but it ships switched off, with every category set to Manual.

Why a week, and what "complete" means here

A week is long enough to get access approved and connect every source, and short enough that nobody starts a parallel spreadsheet "until the tool is ready". Inventory projects usually stall by modelling the estate before connecting anything. This plan connects first and models what it finds. For this plan, an inventory is complete when:

1. Every asset class Safeguard discovers has at least one connected source, or a written reason why it does not apply to you.
2. Every asset Safeguard found has an owner, either inferred or assigned.
3. You have the list of ungoverned (shadow) assets, each with a decision: onboard it, retire it, or accept it with an expiry date.
4. You have a baseline for SBOM coverage, vendor coverage and ownership coverage, and you know what moves each number.

That definition is deliberately about software. Laptops, network gear and IP ranges are a different inventory (see what Safeguard does not do).

The problem: inventories that are wrong the day they are signed off

Most inventories are a snapshot that decays the moment someone exports it. A team creates a repository and never tells security. An image lands in a registry nobody scans. A model moves from a public hub into a notebook and then into a service. A coding agent on a laptop gets connected to an MCP server that can write to production tickets. None of it shows up in a quarterly review until something goes wrong.

The standards are blunt about this.

CIS Critical Security Control 2 is titled "Inventory and Control of Software Assets". Its overview asks organisations to actively manage all software on the network "so that only authorized software is installed and can execute" (CIS). The phrase that matters for this plan is "actively manage (inventory, track, and correct)". A list is the first verb of three.

The NIST Cybersecurity Framework 2.0 puts inventory at the front of the Identify function. In the Asset Management category, ID.AM-02 reads "Inventories of software, services, and systems managed by the organization are maintained". ID.AM-04 covers inventories of services provided by suppliers. ID.AM-05 asks that assets be prioritised by classification, criticality, resources and impact on the mission. ID.AM-08 asks that systems, hardware, software, services and data be managed throughout their life cycles (NIST CSWP 29). Those map onto this plan: software on days one to three, suppliers on day three, prioritisation and life cycle on day five. We have a longer walk through ID.AM-02 in NIST CSF 2.0 ID.AM-02 explained.

CISA Binding Operational Directive 23-01, as published, required US federal civilian agencies to "perform automated asset discovery every 7 days", at minimum across the agency's whole IPv4 space (CISA). It covers networks and binds federal agencies only, but the cadence is a useful bar: an inventory refreshed less than weekly is a report.

The NTIA minimum elements for an SBOM, published at the direction of Executive Order 14028, define an SBOM as a formal record of the components used in building software and their supply chain relationships (NTIA). An inventory that stops at "we run service X" cannot answer "do we ship component Y". SBOMs are how the inventory goes one level down, and the two formats Safeguard reads and writes, CycloneDX and SPDX, are the two the industry has settled on.

OWASP API Security Top 10 2023, API9 Improper Inventory Management, describes the same failure from the attacker's side: a lack of asset inventory and retirement strategy "leads to running unpatched systems" (OWASP).

European rules point the same way in general terms; see supplier software risk under DORA, NIS2 and M-22-18 and SBOM generation and analysis in Safeguard. The common thread: an inventory has to be continuous, go below the service level, and have owners. That is what the week builds.

What Safeguard discovers, and how

Before the day by day plan, here is the model you are building, taken from Safeguard's Asset Discovery docs.

The seven asset classes

The three connection modes

The docs describe three ways assets reach the inventory:

• Agentless integrations. You connect your Git provider, container registries, cloud accounts and model registries with OAuth or IAM roles. Safeguard then enumerates new repositories, images and models, polls for pushes, tags, releases and deletions, and cross references CI/CD logs to spot builds that happen outside your known pipelines.
• Lightweight agents. A runtime collector observes image pulls, workload manifests and admission events on Kubernetes, captures package inventories and running containers on Linux hosts and VMs, and captures build time manifests on CI/CD runners. The docs say agents send telemetry over mTLS and do not ship source code or binaries off the host.
• SBOM ingestion. For vendor software and imported artifacts, you upload CycloneDX or SPDX SBOMs through Portal. Ingested SBOMs are normalised, de-duplicated, enriched with vulnerability data and joined into the asset graph.

Graph, owners and coverage, in one paragraph

Every discovered asset becomes a node in a typed graph (a repository builds an image, an image runs in a workload, a vendor provides an SBOM), which is what lets the Search page answer questions such as "which production workloads contain this component". Each asset carries an owner, business unit, environment and sensitivity, and anything that exists but is not governed is flagged UNGOVERNED. The dashboard reports SBOM, vendor and ownership coverage as time series. Day five uses all of this; the companion reference post explains each piece in more depth.

Before day one: a half day of preparation

A one week rollout fails most often on access, not on technology. Spend half a day the week before getting four things settled.

1. Name the people. You need one person who can approve an organisation wide app install on each Git provider, one person per cloud account who can create a read only IAM role or service principal, someone who owns the model registries, someone who owns the vendor list, and one security lead who makes the calls on shadow assets.

2. Decide the scope boundary in writing. Which Git organisations, which registries, which cloud accounts, which Kubernetes clusters. Write down the exceptions now, for example a subsidiary's separate Git organisation, so day five does not become an argument.

3. Agree read only first. The Integrations docs say write scopes are never enabled without explicit per repository consent. Nothing this week needs write access; fix pull requests are a later, separate decision.

4. Pick your connection route for private code. Some teams cannot give a cloud service OAuth access to their source. For those repositories, the local runner built into the Safeguard CLI runs the scan on your own machine and uploads only the resulting SBOM and findings. Decide now which repositories go which way. Our post on choosing between a repo connection, the CLI and the local runner walks through the trade offs.

Day 1: source repositories

Source control is the backbone of the graph. Repositories build images, contain packages and carry CODEOWNERS, which is where most owners will come from on day five. Start here.

Steps

1. Connect each Git provider at the organisation level. In the Safeguard app, open Integrations and add your source control provider. The Integrations docs list GitHub (cloud and Enterprise Server) through a GitHub App with an organisation wide install and per repository enablement, Bitbucket (cloud and Data Center) with a workspace wide install, and GitLab and Azure DevOps through their own setup guides. An organisation level install matters because it is what lets Safeguard see repositories created after today.
2. Enable repositories in bulk, not one at a time. A repository you enable and later archive is a cleaner record than one never seen.
3. Let the first scans run. Each connected repository gets an SBOM and an SCA pass. SCA (GA) builds the full transitive dependency inventory across npm, PyPI, Maven and Gradle, Go, Cargo, NuGet, Composer and Bundler, which is what turns "repository" into "repository plus everything it pulls in". If you want to check the exact manifests and lockfiles per ecosystem before you start, the CLI support matrix is the reference.
4. Read the Integrations status for errors. Repositories that fail to scan are usually missing a lockfile, use a build system the scanner does not read, or need a private registry credential. Write them down for day three rather than fixing them now.
5. Note the repositories you did not connect on purpose. These go to the CLI and local runner on day three.

What you should see by the end of the day

The Assets view lists your repositories, filterable by asset type. Each scanned repository has a project with its dependency tree, vulnerabilities, suppliers and licenses. You will also see how many repositories exist that nobody listed, usually the first useful finding of the week.

Exit check for day 1

• Every Git organisation in scope is connected at the organisation level.
• At least the repositories that ship to production have a completed scan.
• You have a short list of repositories that failed to scan and a list of repositories that will go through the CLI.

Day 2: container images, cloud accounts and runtime workloads

Repositories tell you what you build. Registries and runtime tell you what you actually run, and the two rarely match. Day two closes that gap.

Steps

1. Connect every container registry in scope. The Integrations docs have setup guides for Amazon ECR, Docker Hub, any OCI registry, Azure Container Registry, Oracle Container Registry and Google Artifact Registry, and list GitHub Container Registry, GitLab Container Registry, Red Hat OpenShift's internal registry and custom OCI distribution compatible registries. Read only pull access, with the auth the docs list per registry, is enough.
2. Connect cloud accounts for workload inventory. The Integrations page lists cloud providers by what they contribute. For example, the Google Cloud connection covers asset inventory across GKE, Cloud Run, Cloud Functions, Artifact Registry and Cloud Build. Connect each account in your scope boundary with the read only identity your platform owner created.
3. Deploy the runtime collector where you need runtime truth. The Asset Discovery docs describe a DaemonSet on Kubernetes clusters that observes image pulls, workload manifests and admission events, and a collector for Linux hosts and VMs that captures package inventories, running containers and loaded shared libraries. Start with one production cluster. You do not need every cluster on day two; you need one that proves the "running image that is not in any SBOM" check works for you.
4. Scan the images you cannot reach through a registry connection. For an image on a host with no registry integration, the CLI scans it directly. The CLI usage docs show the form:

safeguard scan --image myregistry.azurecr.io/myapp:v1

On a Podman host, the CLI can list running containers grouped by image digest and scan the images behind them, without Docker:

safeguard podman inventory
safeguard podman scan --running

5. Tag environments as you go. If production images live in one registry and staging in another, record that now; it saves an afternoon on day five.

What you should see by the end of the day

Images appear as assets with their own SBOMs, including operating system packages in the image layers. The graph now has "repository builds image" edges where Safeguard can match them, and "container runs in workload" edges for the cluster with the collector. For more on per environment image tracking and fail thresholds, see tracking container images per environment in Safeguard.

Exit check for day 2

• Every registry in scope is connected or has a written reason it is not.
• At least one production cluster reports runtime workloads.
• You can open one production image and see which repository built it. If you cannot for most images, note it: that is a build labelling problem, and day five will surface it again as missing owners.

Day 3: packages, private code and supplier SBOMs

By now you have most of what your own pipelines build. Day three fills in the rest: the repositories you kept off cloud connections, the ones that failed to scan, and the software you buy.

Steps

1. Install the CLI on a build machine or a developer workstation. The local runner docs give the one line installer:

# macOS and Linux
curl -fsSL https://cli.safeguard.sh/install | bash

Then run safeguard, type /login, approve the browser session, and the machine starts polling the platform for work. All traffic is outbound HTTPS the runner opens; nothing connects to it.

2. Scan the repositories that stay local. For a checkout on disk, the CLI usage docs show:

safeguard scan --dir .

For a private remote you can pass a token instead of cloning by hand:

safeguard scan --repo https://github.com/org/private-repo --git-token "$GIT_TOKEN"

The runner uploads the SBOM and findings, never the source. Note that safeguard scan does not fail on findings; it exits 0 when the scan ran. That is what you want during an inventory week.

3. Keep private repositories fresh. The docs show safeguard runner start --workspace ./path/to/repo to run headless on a shared build machine, and safeguard runner status to check it.

4. Retry the day one failures. Most fall into three groups: no lockfile committed (generate and commit one, or scan the build output instead), a private package registry the scan could not reach, or an ecosystem the scanner does not read. Check the last group against the support matrix before spending time on it.

5. Load the vendor list into TPRM. TPRM (GA) is where vendors live in Safeguard. Bring in at least the suppliers whose software you run in production. Vendor coverage on day five is measured against third party components, so start with the vendors whose components already appear in your SBOMs.

6. Upload supplier SBOMs through Portal. Portal (GA) takes CycloneDX or SPDX by drag and drop. Each ingested SBOM is normalised, de-duplicated, enriched with vulnerability data and joined to the graph as "vendor provides SBOM". The asset docs also show an SBOM upload API path, but it sits under the /v1 banner and is not available yet, so use the upload. Our post on SCA from a supplier SBOM in Safeguard covers what happens after the upload in detail.

What you should see by the end of the day

Packages are now visible across first party and supplier software in one place, so a question like "where do we run this library" returns both your services and the vendor products that bundle it. Vendors in TPRM link to the SBOMs they supplied.

Exit check for day 3

• Every repository in scope has at least one SBOM, whether from a connection, the CLI or the runner.
• The day one failure list is either fixed or explained.
• Your top production suppliers are in TPRM, and any SBOMs they have given you are uploaded.

Day 4: AI models and AI coding agents

Most inventories built before 2025 have no row for models, and almost none have a row for the coding agents developers run on their laptops. Day four adds both, and they need different approaches.

Models in registries and in code

1. Connect model registries. The Asset Discovery docs list Hugging Face, MLflow, Vertex AI Model Registry and SageMaker as model sources, and the Integrations docs have setup guides for Hugging Face and for the Anthropic Claude Compliance connection, with further AI model integrations listed in the docs sidebar. Connect the registries your ML teams actually use.
2. Let AI-BOM discovery (GA) find models referenced from code. The offering describes AI-BOM discovery as inventorying AI assets across code (SDK imports), cloud model services, SaaS and vector databases, with ML-BOM output in CycloneDX and the SPDX AI profile. In practice, this is what finds the service that calls a hosted model API without anyone having registered it. Our post on finding every AI model and SDK you ship covers it in depth.

Coding agents on people's computers

AI agent discovery (GA) runs inside the Safeguard CLI and the Safeguard Desktop app (GA) on the computers your people work on. The AI agent discovery docs say it reports, per device and per person: the supported coding agents installed and running and what each is allowed to do (shell commands, file edits, network access, auto approved tools, permission mode); the MCP servers each agent connects to; the skills, plugins, rules and sub-agent definitions installed into each agent; local model files; and session activity from the agents' own local files.

The rollout has three switches, in order:

1. Safeguard enables the feature for your organisation. It is off by default. Ask your Safeguard contact to turn it on.
2. An administrator turns it on and sets the policy. The docs list the choices: how file paths are shown, whether command lines and web search queries are collected, extra model folders, how often devices report, retention, whether each person is asked or everyone is enrolled with a notice, and whether people may opt out.
3. Each person allows it on their own computer. In Safeguard Desktop, the setting is Settings › Privacy › AI agent discovery › Allow AI agent discovery. In the CLI:

safeguard aidr collect status
safeguard aidr collect show
safeguard aidr collect on

status shows the organisation's setting and the person's choice; show prints exactly what the next run would send without sending anything; on displays the notice and records consent. From then on it runs in the background while the runner or Desktop is running, every interval the organisation sets (the docs give 15 minutes as the default).

Two details matter for the rollout conversation with staff. First, the docs say prompts, responses, full tool inputs, tool output and file contents are not collected by default, and paths are shortened so a home folder becomes a tilde. Second, turning it off on a computer with safeguard aidr collect off deletes what that computer sent and records the choice. Lead with both in the announcement.

Where to see it

The results appear in Assets › Inventory › Asset discovery, with tabs for Agents, Models, Skills and plugins, MCP servers and Devices, filterable by device, person and agent.

Exit check for day 4

• Every model registry your teams use is connected.
• AI agent discovery is on for at least one pilot team, with consent recorded.
• You can answer "which MCP servers are our coding agents connected to" for that team.

Day 5: owners, shadow assets, coverage and the first gates

Days one to four were about seeing. Day five is about making the inventory something people can act on.

Morning: owners and tags

1. Review inferred owners. Safeguard infers owners from CODEOWNERS and container labels. Sort assets by "no owner" and work through them with engineering managers. The fastest fix for a cluster of ownerless repositories is usually a CODEOWNERS file, because it fixes every future asset in that repository too.
2. Set environment and sensitivity on the assets that matter most. Start with production. A production workload holding customer or regulated data should be tagged that way today, because the docs say those fields drive who is paged when a finding lands.
3. Map business units from repository topics, cloud accounts and namespaces, the docs' named sources.

Midday: the shadow asset review

Open the Asset Discovery dashboard and filter to UNGOVERNED. Expect four kinds of entries, matching the docs:

• A repository that is not connected, usually in an organisation connected per repository or outside your scope list.
• An image in a registry with no SBOM, often an old tag, a mirrored base image or a hand push.
• A running image that is not in any SBOM, the most important one: something runs in production that your pipeline did not produce or record.
• A vendor API called from production that is not in TPRM, a supplier relationship that bypassed procurement.

For each one, record one of three decisions: onboard (connect it, scan it, assign an owner), retire (archive the repository, delete the tag, decommission the workload) or accept with an expiry (a written reason and a date to look again). The docs note that shadow findings can drive automation, such as opening a Jira ticket or blocking deployments until the asset is onboarded. Use the ticket route this week. Blocking comes after people have seen the list.

Afternoon: baseline coverage

Record SBOM, vendor and ownership coverage from the dashboard, and next to each the two or three things that would move it most. That list is your week two plan.

Late afternoon: the first gates, in Warn and Notify

An inventory you do not enforce against drifts back to where it started. The Policies and Gates docs separate the two ideas: policies are rules that evaluate your SBOMs and generate findings; gates are checkpoints that enforce policies. Policies are created under Settings › Policies with Create Policy, using the visual builder or YAML, then saved and enabled.

The docs checked on 25 October 2026 list three policy actions, and the policy outcomes docs say exactly what each does when a policy fails:

Approval is not a fourth action in the current docs. It runs through exceptions: a developer requests one against a specific policy and finding with a business justification and an expiry date, approvers are notified, and the decision is recorded in the audit trail. The guardrails docs add that blocking guardrails support time boxed exceptions that expire automatically, and that emergency break glass exceptions need two person approval.

For the first gates on an inventory week, set everything to Warn or Notify. Good first policies from the docs' condition list are "no critical vulnerabilities" on production assets and an approved license policy. Notify suits a first week because, per the docs, it fires when a policy starts failing and again only when new matching issues appear, not on every evaluation.

If you want a pipeline to fail on a gate, the policy outcomes docs show:

safeguard ci scan --wait --fail-on-gate <gate name or id>

It waits for the scan and for the gate's policies to be evaluated, exits 0 on Passed or Warning, and exits non zero on Failed, Error or Not evaluated. Policy outcomes are turned on per workspace by Safeguard; if your Gates and Policies tables have no Outcome column yet, ask your Safeguard contact. Keep --fail-on-gate out of required checks until owners have had a week of Warn results. For the full path from a plain English rule to a release gate, see plain English security policies to release gates in Safeguard.

Exit check for day 5

• Ownership coverage is recorded, and every production asset has an owner.
• Every UNGOVERNED entry has a decision.
• SBOM, vendor and ownership coverage are written down with a date.
• At least one gate exists, set to Warn or Notify, on production assets.

The week at a glance

What a finished week looks like

Here is what you can do on the Monday after that you could not do the Monday before.

Answer exposure questions from one place. When a new advisory lands, the Search page answers "which production workloads contain this component", across your own builds and the supplier SBOMs you uploaded, because the graph joins vendor, SBOM, image, workload and repository.

Route findings to the right person. Because each production asset has an owner, environment and sensitivity, a finding in a production workload with regulated data reaches its owner rather than a shared queue.

See new assets the day they appear. Organisation level connections mean a repository created on Tuesday shows up without anyone filing a request, and coverage becomes a trend line rather than a quarterly survey.

Ask the inventory from an assistant. In Claude or ChatGPT, install Safeguard from the connector directory rather than a custom MCP setup, then ask about projects, vulnerabilities and findings in plain language. See Safeguard in your IDE and in the Claude and ChatGPT connector directories.

Week two and after

The inventory week is a start, not a project with an end date. Three habits keep it accurate.

Weekly shadow review. Fifteen minutes, same owner, same dashboard filter. New UNGOVERNED entries get the same three way decision. If it grows every week, fix the process that creates assets outside your connected sources.

Coverage targets with dates. Pick one metric per month to move. SBOM coverage usually moves fastest as the runtime collector reaches more clusters.

Promote gates on a schedule. After a couple of weeks of Warn results without surprises, move a policy to Block for production, with time boxed exceptions.

Once the inventory is in place, autonomous remediation (GA) can open fix pull requests against the repositories you connected, singly or in bulk. It ships switched off, with every category set to Manual, so turning it on is a separate decision with its own approvals, not a side effect of this week.

What Safeguard does not do

An honest inventory plan says where the tool stops. These are the limits that matter for this rollout, from the docs as of 25 October 2026.

1. It does not inventory hardware or sweep IP ranges. Safeguard's asset classes are software things. Laptops, servers as physical assets, network devices and an agency's IPv4 space, which is what CISA's BOD 23-01 asks federal agencies to sweep, need an endpoint or network discovery tool. The docs list endpoint security and external attack surface management as roadmap areas, not shipping ones.
2. There is no CLI command for listing assets or querying the asset graph yet. The Asset Discovery docs say so directly. Use the Assets view and the Search page in the app.
3. The /v1 REST endpoints on the asset page are not available. The docs carry a banner that every path under /v1 returns 404 today and describes intended shape only.
4. The Kubernetes admission controller is not published. The guardrails docs say there is nothing to install yet, and warn against installing any chart that claims to be it. Enforcement at deploy time this week means gates on scans and pipeline checks, not admission control.
5. Ownership inference is only as good as your metadata. Owners come from CODEOWNERS, container labels or manual assignment. If repositories have no CODEOWNERS and images carry no labels, ownership coverage will be low until people add them. Safeguard cannot guess an owner your organisation never recorded.
6. Supplier SBOMs are only as complete as the supplier made them. Safeguard normalises, de-duplicates and enriches what you upload. It cannot add components a vendor left out. A thin vendor SBOM gives you a thin row in the graph.
7. AI agent discovery covers listed agents only, and activity for some. The docs list the supported coding agents; agents not on the list are not detected, and session activity is read for some agents and marked "not supported yet" for others. Each report says which, so a gap is never shown as nothing happening.
8. Policy outcomes need to be on for your workspace. The Outcome column and --fail-on-gate depend on a per workspace setting that Safeguard turns on. Check before you promise anyone a failing pipeline.
9. It does not decide what to retire. Safeguard surfaces shadow assets. Whether a forgotten repository is archived or a stale image deleted is your call, and the deletion happens in your systems.

Common mistakes

Connecting repositories one by one. A per repository connection sees today's repositories and none of next week's. Connect at the organisation or workspace level and enable repositories in bulk, so the shadow check has something to compare against.

Starting with the vendor list. Procurement lists are tidy, so teams start there. But vendor coverage is measured against third party components in your SBOMs, which you do not have until days one to three are done. Load vendors on day three, after the graph shows which suppliers' components you actually run.

Trying to fix findings during the inventory week. The first scans produce a lot of vulnerabilities. Triage them on Tuesday and Wednesday's connections do not happen. Record, do not fix. Prioritisation with reachability, EPSS and KEV is a week two job, covered in prioritising vulnerabilities with reachability, EPSS and KEV.

Setting the first gates to Block. A gate that blocks a release on day five, before owners have seen their findings, teaches the organisation to route around Safeguard. Warn and Notify first; Block once owners have had time to act.

Skipping the runtime collector because the registries are connected. Registries tell you what was pushed. Only runtime tells you what is running, and the "running image not in any SBOM" check is the one most likely to find something that matters. One production cluster is enough for week one.

Rolling out AI agent discovery without telling people what it collects. Show them safeguard aidr collect show before you ask them to run on.

Treating "complete" as a percentage. A 100 percent ownership coverage number with half the owners set to a shared team alias is worse than 80 percent with real people. Check a sample of owners by hand on day five.

Building automation on the /v1 API. It looks complete in the docs and returns 404 today.

FAQ

How long does it take to build a software asset inventory with Safeguard?

The plan in this post takes five working days plus half a day of preparation. The longest waits are usually access approvals, not scanning.

What asset types does Safeguard discover?

Safeguard's Asset Discovery docs list seven classes: source repositories, container images, packages, AI models, SBOMs, vendors and runtime workloads. AI agent discovery adds coding agents on people's computers, with their MCP servers, skills and plugins, shown under Assets › Inventory › Asset discovery.

Does Safeguard need write access to my repositories to build an inventory?

No. The Integrations docs say write scopes are never enabled without explicit per repository consent. Everything in the inventory week works with read access. Write access only matters later if you turn on fix pull requests, which ship switched off.

Can I inventory private repositories without giving Safeguard OAuth access?

Yes. The local runner, built into the Safeguard CLI, scans on your own machine and uploads only the resulting SBOM and findings. Source code stays on the machine, and all traffic is outbound HTTPS that the runner opens.

How does Safeguard find shadow IT or ungoverned software?

It compares what it can see against what is governed: unconnected repositories, registry images with no SBOM, running images in no SBOM, and vendor APIs called from production but missing from TPRM. Each shows as UNGOVERNED.

How does Safeguard assign owners to assets?

Owners are inferred from Git CODEOWNERS and container labels, or assigned manually. Business unit comes from repository topics, cloud accounts or namespaces, and these fields decide who gets routed a finding.

Can I import vendor SBOMs into my asset inventory?

Yes, through Portal upload in CycloneDX or SPDX. Safeguard normalises, de-duplicates and enriches each SBOM with vulnerability data and links it to the vendor in TPRM. The SBOM upload API shown in the asset docs is not available yet, so use the upload for now.

Does Safeguard inventory AI models and AI agents?

Yes. Model registries are discovery sources, AI-BOM discovery finds models referenced from code, and AI agent discovery, run through the CLI and Desktop app with each person's consent, reports coding agents with their MCP servers, skills and local models.

How often does Safeguard refresh the inventory?

Continuously once sources are connected: integrations poll for pushes, tags, releases and deletions, and AI agent discovery reports from devices at the interval the organisation sets (15 minutes by default, per the docs).

Can Safeguard block deployments of assets that are not in the inventory?

The docs say shadow findings can drive automation, including opening a ticket or blocking deployments until the asset is onboarded, and gates with a Block action fail when a policy fails. The Kubernetes admission controller is not published yet, so deploy time blocking today runs through gates on scans and pipeline checks.

Get started

Install the Safeguard CLI and apps from safeguard.sh/download, and keep the Safeguard docs open next to this plan while you connect each source.

An inventory tells you where a vulnerable component lives; it does not remove it. Once the week is done and the first findings are routed to owners, the section below is the standard way Safeguard closes the gap between knowing and fixing, for the open source components your newly inventoried repositories and images carry.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real Safeguard CLI session. It installs the CLI, opens the interactive terminal, and asks the assistant to fix a lodash CVE in a repository: it reads the finding and advisory, asks before any command that changes something, edits package.json to the fixed version, runs the install and tests, prints a summary and pushes nothing. It is the same CLI you install on day three, and the same flow your owners will use once the inventory routes findings to them.

Click through it at your own pace, or open it full screen.

The second demo sets up the local runner on your own machine, approves it with its device code, and then scans from the terminal. That is the day three route for repositories you keep off cloud connections: the scan runs on your hardware and only the SBOM and findings reach the inventory.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to Safeguard with OAuth and shows choosing which tools Claude can use. Once your inventory exists, this is how people ask about projects, vulnerabilities and findings from inside the assistant. In Claude or ChatGPT, start from the connector directory rather than a custom server setup.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• CIS Critical Security Control 2: Inventory and Control of Software Assets
• NIST Cybersecurity Framework 2.0 (NIST CSWP 29)
• CISA BOD 23-01: Improving Asset Visibility and Vulnerability Detection on Federal Networks
• NTIA: The Minimum Elements for a Software Bill of Materials
• NIST SP 800-218, Secure Software Development Framework
• CycloneDX specification overview
• SPDX overview
• OWASP API Security Top 10 2023, API9 Improper Inventory Management
• Safeguard docs: Asset Discovery
• Safeguard docs: AI agent discovery
• Safeguard docs: Integrations
• Safeguard docs: Local Runner
• Safeguard docs: CLI usage
• Safeguard docs: CLI support matrix
• Safeguard docs: Policies and Gates
• Safeguard docs: Policy outcomes and actions
• Safeguard docs: Guardrails and Enforcement
• Safeguard: Asset Discovery use case
• Gold Open Source

Last reviewed: 24 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.