How do you start vulnerability management from scratch in 30 days?

You can start vulnerability management in 30 days with four moves: list the software you run, scan it for known flaws, rank what you find by real danger, and fix or consciously accept each item with an owner and a date. Week one is the list. Week four is a repeatable routine.

TL;DR

• Week 1: write down what software you run and who owns it.
• Week 2: scan it and look at the results without panic.
• Week 3: rank findings with a few simple questions, then fix the top handful.
• Week 4: set a routine, a few numbers to watch, and a rule for exceptions.
• You will not reach zero. The goal is a steady habit that catches the dangerous items first.

What is vulnerability management, in plain words?

A vulnerability is a flaw in software that someone could use to do something the owner did not intend, such as reading private data or taking over a server. Vulnerability management is the routine of finding those flaws in the software you use, deciding which ones matter, and fixing them in a sensible order.

Think of a landlord who owns twenty apartments. A good landlord keeps a list of the buildings, inspects them on a schedule, repairs the broken front door before the squeaky cabinet, and writes down what was fixed. Vulnerability management is the same habit applied to software. If you want a longer definition first, read what vulnerability management is and the beginner overview.

Most flaws that scanners report are public. They carry a CVE ID, which is a shared name for one known flaw so that everyone can talk about the same thing. If that term is new, see what a CVE is.

Why do small teams get stuck before they start?

Three reasons come up again and again.

1. They think they need a big tool and a security team first. They do not. A list and a scan are enough to begin.
2. They fear the first scan. A first scan often returns hundreds of items. That number feels like failure. It is just a measurement of a backlog that already existed.
3. They try to fix everything. That path ends in burnout. The better path is to fix the dangerous few and track the rest.

So the plan below is small on purpose. It fits around normal work.

What does the 30 day plan look like?

Week 1: how do you list what you run?

Open a spreadsheet. For each application or service, write its name, who owns it, where its code lives, and what it connects to the internet with. Do not aim for perfect. Aim for a list that is 80 percent right by Friday.

Then go one level deeper for the most important items. Software is built from other software. Your web app may use hundreds of open source packages, and each package may use more. A dependency is a package your code relies on. The full list of them is often called a software bill of materials, or SBOM, which works like the ingredient label on food.

Mark each item with a rough importance: high if customers or money depend on it, medium if staff depend on it, low if it is a side tool. Three levels are enough.

Week 2: how do you run the first scan?

A scan compares your list of software and versions against databases of known flaws and reports matches. Run one scan per item on your list, starting with the high importance ones.

When results arrive, resist two reactions. Do not close the tab because the number is big. Do not try to fix things in the order they are shown. Instead, export or copy the results into your sheet with these columns: item, package, flaw ID, severity label, fix version if any, and owner.

If the report columns look confusing, the false positives FAQ explains why some findings turn out to be false alarms, which is normal and not a sign the scanner is broken.

Week 3: how do you decide what to fix first?

Use a short set of questions for each finding.

1. Is it on the CISA Known Exploited Vulnerabilities list? That means CISA has reliable evidence of attackers using it in real attacks.
2. Is the vulnerable code actually used by your program, and is the item reachable from the internet?
3. Is a fixed version available?
4. How important is the item you run, from your week 1 list?

CISA says organizations should use its catalog as an input to their prioritization framework, and that every organization can strengthen its security by prioritizing the listed items. That is a good first filter. For more on scoring signals, see CVSS, EPSS and KEV explained and how to prioritize vulnerabilities.

Pick the top five to ten findings and fix them. Fixing usually means upgrading a package to a version that no longer has the flaw.

Week 4: how do you make it a routine?

Set three habits.

• A schedule. Scan on every code change if you can, and at least weekly for everything else. New flaws are published every day, so a clean scan last month says little about today.
• An exception rule. Some findings cannot be fixed yet. Allow an exception only with a named owner, a reason, and an end date. See accepting an unfixable vulnerability.
• Five numbers. Track open findings by severity, how many are on the Known Exploited list, the age of your oldest high item, how many you fixed this month, and how many new ones arrived.

A worked example with invented numbers

These numbers are invented to show the method. They are not data from a real company.

A four person team runs three apps. Their first scan reports 240 findings. They sort like this.

In week 3 they fix the 2 urgent items and 6 of the 18. By the end of the month, their open count is 232, which looks like little progress. But the two dangerous items are gone, the next twelve have owners and dates, and the other 218 are sorted rather than ignored. The risk dropped far more than the raw count suggests, which is why raw counts alone are a poor score.

What mistakes should you avoid?

• Counting success by the total number of findings. Count dangerous findings and their age instead.
• Letting alerts pile up with no owner. Every item needs a person.
• Fixing in the order of the report. Rank first.
• Skipping the schedule. A one time cleanup decays within weeks.

Try it yourself

Click through it at your own pace, or open it full screen. Watch how findings move from found, to ranked, to fixed, and notice that ranking comes before fixing.

How can Safeguard help?

Safeguard offers SBOM and dependency scanning, so the list from week 1 and the scan from week 2 can come from one place. Reachability analysis helps you see which flaws sit in code your program actually uses, which supports the ranking step. Policies and gates let you set rules, such as blocking a pull request that adds a known exploited flaw. Autonomous remediation can open fix pull requests, but it is off by default and every category starts on Manual, so a person approves changes until you decide otherwise.

The Safeguard CLI can also write code, which is useful when a fix needs more than a version bump. You can start with the free scan at gold.safeguard.sh/scan to see what a first result looks like.

Quick check

Sources

• CISA, Reducing the Significant Risk of Known Exploited Vulnerabilities
• CISA, Known Exploited Vulnerabilities Catalog

Last reviewed: 19 October 2026.