How do you list all your software before scanning for vulnerabilities?

To list your software before a vulnerability scan, start with your applications and services, then list what each one is built from, then note who owns each. Sources include code repositories, build files, container images and cloud accounts. A rough list today beats a perfect list never.

TL;DR

• A scan can only report on software it knows about.
• Build the list in three layers: applications, the packages inside them, and the places they run.
• Look in repositories, build files, container images and cloud accounts.
• Give every entry an owner and a rough importance.
• Refresh the list automatically if you can, and monthly by hand if you cannot.

Why does the list come first?

Imagine checking smoke alarms in a building without knowing how many rooms it has. You would test the alarms you happen to remember and assume the rest are fine. A scanner is the same. It checks what it is pointed at. If an old service nobody remembers still runs, nobody scans it, and it quietly collects flaws.

Some vocabulary. A vulnerability is a flaw in software that someone could misuse. A software inventory is the list of what you run. A dependency is a package your code uses that someone else wrote. A software bill of materials, or SBOM, is a detailed list of the ingredients inside one piece of software, like the label on a food package.

Most real world code is mostly other people's code. A small web app may include hundreds of packages. That is why the list needs layers.

What are the three layers of the list?

You do not need all three layers on day one. Start with layer 1, add layer 2 for your most important items, then layer 3.

Where do you look for the entries?

Code repositories

List every repository in your source hosting account, including old ones. Mark each as active, maintenance or retired. Retired repositories whose code still runs somewhere are a classic blind spot.

Build files and lock files

Each application keeps a file that names its packages, and often a second file that records the exact versions. Reading these gives you layer 2 without guesswork. A tool can read them for you and produce an SBOM.

Container images and registries

A container image is a packaged copy of an application and everything it needs. List the images in your registry and note which ones are actually deployed. Unused images are not harmless, because someone may deploy them later.

Cloud accounts and hosting panels

Check your cloud accounts, hosting dashboards and any website platforms for services you forgot. Marketing sites, test environments and one off experiments often live here.

People

Ask each team a short question: what do you run that is not in this list? People remember the side tool that has been quietly running for three years.

What should each entry record?

Keep columns few so people actually fill them in.

1. Name
2. Owner (one person or team)
3. Where the code lives
4. Where it runs
5. Faces the internet? (yes or no)
6. Importance: high, medium or low
7. Last scanned date

The internet facing column and the importance column are what you use later to rank findings. See how to rank hundreds of vulnerabilities for how those fields get used.

A worked example with invented numbers

These numbers are invented to show the process. They are not from a real organization.

A ten person company believes it runs 4 applications. In one afternoon the owner does the following.

The list now holds 8 items, double what they believed. Next they run a scan across all 8. Three of the four newly found items show flaws that had been open for a long time, including a public site with an outdated component. None of these would have been scanned without the inventory.

The lesson: the surprise is the point. Discovery often finds more risk than the scan of known items does.

How do you keep the list current?

A list that is accurate once decays quickly. People add services and forget to tell anyone.

• Automate where possible. Connect your source hosting and cloud accounts to a tool that discovers new repositories and builds SBOMs on its own.
• Make it part of launch. A new service is not live until it has a row in the list and an owner.
• Review monthly. A fifteen minute check of new, changed and retired entries is enough.
• Mark retired items. When a service shuts down, record the date and confirm that it really stopped.

You can also give entries a simple status such as active, deprecated or retired. That keeps old items visible instead of silently deleted.

What mistakes should you avoid?

• Listing only the big applications. Small tools and scripts often have the oldest packages.
• Skipping the packages layer. Most flaws live in dependencies, not in code you wrote.
• Leaving owners blank. A finding with no owner has nobody to fix it. Read how to start vulnerability management in 30 days for a full routine.
• Treating the list as a one time project. Schedule the refresh.

For the wider definition and the loop that this list supports, see what is vulnerability management and the software composition analysis FAQ.

Try it yourself

Click through it at your own pace, or open it full screen. Look at how a project expands into a full list of packages, including ones you never chose directly.

How can Safeguard help?

Safeguard offers asset discovery and SBOM and dependency scanning, so you can build and refresh the inventory without hand maintaining a spreadsheet. Each project shows the packages it contains, including indirect ones, and findings attach to the right project and owner. You can try the free scan at gold.safeguard.sh/scan to see what a package list looks like for a project.

Quick check

Last reviewed: 19 October 2026.