Vulnerability management with no security team: where to start

A startup with no security team can run vulnerability management by keeping an inventory, fixing anything on CISA's Known Exploited Vulnerabilities list first, using EPSS and reachability to rank the rest, and giving one engineer a fixed weekly hour. Start small, write the rules down, and measure time to fix.

What does vulnerability management mean at your size?

It is a loop: know what you run, learn what is wrong with it, decide what to fix first, fix it and check. Large companies have teams for each step. You have a few engineers who also ship product. The goal is a loop that costs about an hour a week and never silently stops.

What should you do first?

1. Inventory. List your services, the repositories behind them, the cloud accounts, and the main third party software. A spreadsheet is fine. If you cannot list it, you cannot patch it.
2. Turn on automatic detection. Use dependency alerts from your code host, a software composition scan in CI, and the cloud provider's findings. Start with the free ones, then judge the gaps.
3. Name an owner. One engineer, with a backup. Rotate every quarter.
4. Pick the weekly hour. Same slot every week. Triage, assign, close.
5. Write the rules in one page. What gets fixed, in what time.

How do you decide what to fix first?

You will always have more findings than time. Rank them with signals that are public and cheap.

• Known exploited. CISA says organizations should use its KEV catalog as an input to vulnerability management prioritization. If a vulnerability in your stack is on it, it goes to the top.
• Likely to be exploited. EPSS, from FIRST, estimates the probability that a published CVE will be exploited in the wild in the next 30 days, with a score from 0 to 1 published daily. It is free and open.
• Reachable. Whether your code actually calls the vulnerable function. A reachable finding in production beats an unreachable one in a test tool.
• Exposed. Internet facing beats internal.
• Sensitive. Systems with customer data beat a prototype.

CVSS severity still has a role, but alone it ranks too many things as critical.

A starter policy you can copy

• Known exploited and exposed: fix or mitigate within days.
• Reachable and high severity: fix in the next sprint.
• High EPSS, not reachable: schedule, and recheck monthly.
• Everything else: batch with normal dependency upgrades.

Adjust the timings to your reality, but write them down and track them. Missing a target is information. Having no target is not.

What should the weekly hour contain?

1. Review new KEV entries against your inventory.
2. Review new findings from the scanners.
3. Assign each to an owner with a due date.
4. Check last week's fixes landed.
5. Record exceptions with a reason and an expiry date.
6. Note one thing to automate next.

What are the honest limits?

You will not catch everything. Scanners know about published vulnerabilities, not undiscovered ones. Automated alerts need someone to read them. Free tools often cover only one ecosystem or layer, so check what they skip. And a spreadsheet inventory goes stale.

If customers or auditors ask for evidence, keep the weekly record. A dated log of triage decisions is evidence that the process exists and runs.

Where does Safeguard fit?

Safeguard is built to reduce the manual work in this loop. It scans dependencies and code, applies reachability analysis that classes findings as reachable, conditionally reachable, unreachable or unknown, and combines reachability with signals like CVSS, EPSS and KEV into a priority score. Its CLI and IDE extensions can bring this to developers, and the free scan at gold.safeguard.sh/scan checks up to 100 dependencies in the browser. You can run it without sending code to a model using Zero AI mode.

Quick check

Sources

• CISA Known Exploited Vulnerabilities Catalog
• FIRST: Exploit Prediction Scoring System
• Safeguard docs: reachability analysis

Last reviewed: 18 October 2026.