An asset inventory comes first because every finding has to attach to something: a repository, a service, an image, or a team. Without that list, an ASPM platform shows problems it cannot place, route or prioritize, and users lose trust quickly.
What counts as an asset here
In application security, an asset is a thing your organization builds, runs or depends on. For ASPM purposes, the useful set is:
- Source repositories
- Deployed services and their environments
- Container images
- Third party dependencies, usually captured in an SBOM
- Pipelines that build and release the above
- The teams that own each of them
Why the order matters
If you connect scanners before building the list, results arrive for repositories nobody remembers. Some are archived. Some belong to a team that no longer exists. The platform dutifully reports them, and the first impression is a wall of orphaned findings.
If you build the list first, you can mark what is live, what is retired, and who is responsible. Findings then land in a structure that already makes sense.
A starting inventory in four steps
- Export repositories from your source control system, with last commit date and primary language.
- Mark the live ones. Anything with no commits and no deployment for a long period is a candidate to archive. Decide, do not guess.
- Map to owners. Use code owners files, a service catalog, or a quick conversation with team leads.
- Note exposure. For each service, record whether it faces the internet, handles customer data, or is internal only.
You will not get this perfect on day one. Aim for 80 percent accuracy and a visible list of unknowns.
Where the inventory gets its data
| Source | Gives you | Caveat |
|---|---|---|
| Source control | Repositories, contributors | Includes dead projects |
| Build systems | What actually ships | Needs access to pipelines |
| Deployment records | What runs where | May be incomplete |
| SBOMs | Components inside each build | Only as good as generation |
| Cloud accounts | Running workloads | Outside many AppSec tools |
CISA describes an SBOM as a nested inventory, a list of ingredients that make up software components, which is why it is a natural part of the inventory. The component list is what lets you answer "are we affected?" when a new advisory is published.
Keeping it current
An inventory that is correct in October is wrong by December. Plan for refresh from the start. Automatic discovery, with a short review of new or changed items each month, is far more reliable than a yearly audit.
Signs your inventory is working
- A new repository appears in the platform within days of creation.
- Every finding has a team name.
- You can answer "which services use this library?" in minutes.
- Retired assets are marked, not deleted, so history remains.
A worked example of a first inventory
Imagine exporting repositories from source control and finding 140 of them. A quick pass produces the following picture. The counts are illustrative.
| Category | Count | Action |
|---|---|---|
| Active and deployed | 55 | Assign owners, connect scanners |
| Active libraries, not deployed | 25 | Assign owners, scan |
| Archived or no activity | 40 | Propose archiving |
| Unknown | 20 | Ask contributors, decide in two weeks |
Before connecting any scanner, the team already knows that only about 80 repositories matter for the pilot. That avoids hundreds of findings on dead code, and it gives the first report a sensible shape.
Step by step: running the inventory sprint
- Day one. Export repositories with last commit date, language and contributors.
- Day two. Sort by last activity. Mark candidates for archiving.
- Day three. Cross check with deployment records to see which repositories ship.
- Day four. Send owner questions to the most recent contributors.
- Day five. Review the unknowns in a thirty minute meeting and decide.
- Following week. Load the result into the platform and mark each asset with a status.
Asset types people forget
Beyond repositories, remember to include:
- Internal tools and scripts that run with real credentials.
- Forks of open source projects kept for patches.
- Infrastructure and pipeline definitions that live in separate repositories.
- Mobile apps and browser extensions, which often have their own repositories and release processes.
- Container base images maintained by one team and used by many.
Each of these can carry vulnerable components, and each is easy to overlook.
Linking the inventory to risk
Once the list exists, add two attributes that change priority: whether the asset is exposed to the internet and whether it handles sensitive data. These two columns are often enough to separate where to focus first. Keep the definitions short and consistent so people fill them in the same way.
Governance of the list
Decide who may add or retire assets, and how often the list is reviewed. A monthly review of newly discovered items, with a short note on each decision, keeps the inventory trustworthy without becoming a chore.
Where Safeguard fits
Safeguard provides asset discovery and SBOM and dependency scanning, so the inventory can be built from what exists rather than from memory. A free scan is available at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a single project expands into its dependencies.
Quick check
Do we need a perfect inventory before starting?
No. A mostly accurate one with a visible list of unknowns is enough to begin.
Who keeps the inventory current?
Automatic discovery does the heavy lifting, and the platform admin reviews changes monthly.
Should archived repositories be deleted from the inventory?
Mark them as archived rather than deleting them. You keep the history, and you can still answer questions about past releases.
Sources
Last reviewed: 19 October 2026.
