The Risk Rancher Field Manual, Ch. 2: You Can't Brand a Ghost

August 21, 2026 · 6 min read · #security, #vulnerability-management, #risk-rancher, #asset-inventory

Part of The Risk Rancher Field Manual, a hands-on guide to starting, scaling, and running a vulnerability management program.

You cannot protect what you do not know you have. Every program that falls apart falls apart right here, at the very start, because somebody bought a scanner and pointed it at “the network” without first asking what was actually on it. The scanner found three thousand things. Nobody could say which of them mattered, who owned them, or whether half of them even still existed. The program drowned on day one, in a lake of its own output.

So before the scanner, the inventory. Before you can hunt, you have to know the herd.

The thing that gets you is the thing you forgot

The vulnerability that ends up in the breach report is almost never the one you were watching. It is the dev box somebody spun up in 2019 to test something, left running, and forgot, with a copy of the production database still on it. It is the marketing microsite nobody has logged into in two years. It is the storage bucket a contractor made public “just for a second.”

Attackers do not care about your org chart or your intentions. They care about what is reachable and soft. And what is reachable and soft is, nine times out of ten, the thing that fell off your map. You can run the most disciplined patching program in the world on the servers you know about and still get owned through the one you forgot. That is the ghost problem, and inventory is the only exorcism.

Do not try to count every cow

Here is where people overcorrect and die the other way. They hear “you need an inventory” and they launch a Configuration Management Database project, a two-year, cross-departmental march to catalog every laptop, printer, and VM in the company. These projects are a graveyard. They are never done, they are wrong the day they ship, and they burn the goodwill you needed for the actual security work.

You do not need to count every cow. You need to find the ones worth rustling.

Start with one brutal question: what would genuinely end us if it got popped? Not “what is a risk.” What would be a very bad day. The customer database. The public-facing application. The box that holds the domain admin credentials. The source-code repository. The payment system. For most companies that is a list of ten to thirty things, and you can write it down in an afternoon. Get those named, and you have mapped most of your real risk for a fraction of the effort a full inventory would cost. The rest is cleanup, and cleanup can wait its turn.

How to actually find it

The good news in a cloud world is that your estate is programmable, so you can ask it directly instead of guessing. A few hours with the right queries beats a year of spreadsheets:

• Ask the cloud. The list and describe APIs in AWS, GCP, and Azure will enumerate your compute, storage, databases, and functions faster than any human survey. Export them. That is your raw herd.
• Sweep your own perimeter. Walk your DNS and your public IP ranges to find what is actually exposed to the internet, because that is where the attention is.
• Follow the identity. Your identity provider knows who can touch what. Access is an asset too.

As you go, tag each thing with two fields that matter more than any other: how bad is it if this is compromised (criticality), and who can fix it (owner). Everything else is detail. The output is not a five-hundred-tab spreadsheet. It is a short, ranked list of crown jewels, each with a human’s name beside it. Here is the one the rest of this book runs on, sample-assets.csv, eight rows:

Straight talk. Risk Rancher does not discover your assets. It is not a scanner, and it will not crawl your network and magically find the ghost box. Discovery is still your job, or your cloud provider’s API’s job. What Risk Rancher does is take the scanner output you already have and group it by asset, so the list you build here is the list its tickets land on. The criticality and exposure you set are what you will use, by hand, to adjust the severity on each ticket; the tool keeps that adjusted severity and sets the clock from it. Anyone selling you “fully automatic asset discovery” is selling you a scanner with a markup and a nicer logo.

The most important column is a name

When people build an asset list, they obsess over the IP, the hostname, the operating system version. Those matter. But the single most important column is the one most inventories leave blank: the owner. The name of the human who can actually make the change.

An asset without an owner is a vulnerability you will never close. You will find the hole, you will write the ticket, and it will sit in a void because it is addressed to nobody. Half the reason vulnerability programs stall is not technical at all. It is that the finding has no home. So when you build your short list of crown jewels, do not stop at “prod-db-01.” Stop at “prod-db-01, owned by the payments team, Dana is the lead.” Now you have something you can actually act on.

Try it. Download sample-assets.csv: eight assets, each with a criticality, an exposure, and an owner. That is the shape you want, not a CMDB, a short ranked list with a name in every row. Now build your own. Open a sheet with the same columns (asset, criticality, exposure, owner, notes) and fill it with the ten to thirty things that would genuinely end you. Mark each one crown-jewel, standard, or dev, and internet, internal, or isolated. Do not stop until every row has an owner’s name. You will use these exact two fields, criticality and exposure, to score real findings in chapter six, so the list you build here is the engine’s fuel, not paperwork.

Once you know what you have, and who owns it, you have earned the right to turn on a scanner and point it somewhere that matters. But a scanner is only as good as the relationship that turns its findings into fixes, and that relationship is with the people who hold the wrenches. Before we cast the net, we need to talk about not being hated by IT.

← Back to the blog