CVE Vulnerability Management: A Practical Process for Small Teams
Tens of thousands of CVEs are published each year. No team can patch them all immediately, and most do not affect you. Good vulnerability management is about quickly finding the few that matter.
What a CVE is
A CVE (Common Vulnerabilities and Exposures) identifier is a unique ID for a publicly disclosed vulnerability, such as CVE-2026-33867. It describes the affected product and versions. A CVE says a vulnerability exists; it does not tell you whether you are affected or how urgent it is for you.
Step 1: Know what you run
You cannot match CVEs without an inventory:
- Application dependencies, from lockfiles.
- Container base images and system packages.
- Internet-facing services and their versions.
- Third-party software and appliances, such as VPNs and CMSs.
- Cloud managed services, which are usually patched by the provider.
A software bill of materials (SBOM) for each service makes this repeatable.
Step 2: Match CVEs automatically
Use dependency scanners in your code host and CI, container image scanners, and external scanning for exposed services. Manual tracking does not scale.
Step 3: Prioritise by real risk
CVSS severity alone is a poor prioritiser. Combine:
- Exposure: is the vulnerable component internet-facing or reachable by users?
- Exploitability: is there a public exploit or active exploitation? Check the CISA Known Exploited Vulnerabilities (KEV) catalogue.
- Likelihood: the EPSS score estimates the probability of exploitation in the near term.
- Reachability: does your code actually call the vulnerable function?
- Impact: what data or systems would be affected?
A medium-severity CVE on your internet-facing VPN that is actively exploited outranks a critical CVE in a development-only library.
Step 4: Patch within defined timelines
| Priority | Example | Target |
|---|---|---|
| Emergency | Known exploited, internet-facing | Within 24 to 72 hours |
| High | Critical or high, reachable | Within 7 to 14 days |
| Medium | Lower exposure | Within 30 to 60 days |
| Low | Not reachable or low impact | Next maintenance cycle |
Write these into policy. Auditors will check you follow them.
Step 5: Handle what you cannot patch
When no patch exists or upgrading is not possible yet, apply mitigations: disable the vulnerable feature, add WAF rules, restrict network access or isolate the system. Document the exception and set a review date.
Step 6: Verify
Confirm the fix is deployed everywhere, including old environments and forgotten hosts. External rescanning catches servers that were missed.
From the other side: CVE research
SecurityInfinity's team discovers and reports vulnerabilities too. We have been credited with several CVEs, including a critical RCE in AVideo, CVE-2026-33867. That research feeds our CVE database and our network agent's version-to-CVE matching, which flags vulnerable services on your attack surface and verifies findings. Start free.
Frequently asked questions
What is the difference between a CVE and a vulnerability?
A CVE is an identifier for a publicly disclosed vulnerability. Many vulnerabilities, such as bugs in your own code, never receive CVEs.
What is the KEV catalogue?
CISA's Known Exploited Vulnerabilities catalogue lists CVEs with evidence of active exploitation, making it a strong prioritisation signal.
Should every critical CVE be patched immediately?
Prioritise by exposure and exploitation. A critical CVE in an unreachable component may be less urgent than an exploited medium on an internet-facing system.