Vulnerability management is the process of determining whether your organization detects a vulnerability before or after it becomes a problem. The ColCERT report IN-20260325-029 documented what happens in Colombia when this process is lacking. This article explains how to build one.
Why is reactive patching not enough?
Vulnerability management isn't about applying patches when an incident occurs or when someone remembers it. That's putting out fires.
A vulnerability management program, known as a VMP, is a continuous and systematic cycle that answers three questions on an ongoing basis:
What assets do you have exposed?
Which ones have known vulnerabilities?
Which ones will you address first and within what timeframe?
Without actively answering those three questions, your team is operating blindly. The ColCERT report documented that the 96% of the affected entities lacked this process, and all the exploited vulnerabilities had patches available before the compromise.
Phase 1. Asset inventory: the starting point of all vulnerability management
The most common mistake when starting a vulnerability management program is to begin with the scanning tools. Before scanning, you need to know what you're going to scan.
Build your asset inventory. It doesn't have to be perfect from day one, it just needs to exist.
Document at least:
System or application name
Production version
Operating system and version
Manufacturer support status (active, EOL, upcoming end of support)
Technical Manager
A spreadsheet works to get you started. The important thing is that the inventory is maintained, not that it looks fancy.
Why is it a prerequisite for everything else? Because you can't prioritize system vulnerabilities you don't know exist. The ColCERT report identified SharePoint 2013 instances and systems with active Log4Shell years after its publication. Those systems weren't on anyone's radar.
Phase 2. Continuous scanning: the difference between a photograph and real visibility
With the inventory in hand, the next step is to identify active vulnerabilities. You have two complementary approaches, and both should be continuous, not one-off.
Passive scanning
Before you touch your own systems, do what an attacker would do: reconnaissance from public sources. Using specialized search engines, public certificate registries, and your domains' HTTP headers, you can reveal software versions, exposed subdomains, and publicly visible configurations. If an attacker can see it, you need to see it first, and continuously.
Active scanning
There are active scanning solutions, both commercial and open source, that directly identify CVEs in your systems. The key isn't the solution you choose, but that the scanning is continuous. A one-off scan gives you a snapshot. Continuous scanning gives you real visibility. The difference between the two is the difference between knowing what you had six months ago and knowing what you have today.
Each identified vulnerability comes with a CVSS score. Use this as a starting point for prioritization, not as the absolute criterion. A CVSS 9.0 vulnerability on an internal system with no internet exposure may be less urgent than a CVSS 7.0 vulnerability on a public endpoint with sensitive data.
What to do with the results
Context matters as much as CVSS score.
Phase 3. How to prioritize vulnerabilities with realistic criteria
Your team can't fix everything at once. A vulnerability management program needs a clear and reproducible criterion for deciding the order:
Critical priority, remedy within 24 to 72 hours
CVEs with CVSS greater than or equal to 9.0 in systems exposed to the internet or with sensitive data.
High priority, remedy within 7 days
CVEs with CVSS between 7.0 and 8.9 in production systems with user access or external integrations.
Medium priority, remedy within 30 days
CVEs with CVSS between 4.0 and 6.9 in internal systems without direct exposure.
Rule of thumb: If the CVE has a publicly available exploit and your system is exposed, treat it as critical regardless of the CVSS score.
Phase 4. Remediation and follow-up: where most programs fail
Identifying and prioritizing vulnerabilities is useless if remediation doesn't happen. This is where most vulnerability management programs fail, not due to a lack of technical expertise, but due to the absence of a formal process.
Define internal SLAs and meet them: the same deadlines you demand from suppliers apply internally.
Register each vulnerability as a ticket: with responsible party, deadline, and visible status in your usual system.
Manage exceptions formally: with a review date and documented compensatory measure
An undocumented exception is an ignored vulnerability.
Phase 5. Vulnerability management in external providers
One of the most significant findings of the ColCERT report was the reliance of multiple entities through a common external provider. When the provider failed, the impact spread simultaneously to all the organizations that depended on it.
Your vulnerability management program must extend to your entire technology supply chain. At a minimum, contracts should include:
- Explicit patching SLA: critical in 24-72h, high in 7 days, medium in 30 days
- Incident notification within a maximum of 24 hours from detection
- Right to a security audit at least once a year
- Contractual liability for breaches resulting from negligence in patching
- Prohibition of shared credentials between different customers of the provider
Phase 6. Metrics for communicating the program to management
A vulnerability management program without executive visibility won't survive. Three metrics any CEO can understand:
Mean time to remediation (MTTR): how long it takes on average to close a vulnerability. It should decrease over time.
Open critical vulnerabilities: how many with a CVSS score greater than or equal to 9.0 do you have active today. The goal is a sustained trend towards zero.
Inventory coverage: what percentage of your systems are being actively scanned.
Report these three numbers monthly. Not as an alarm, but as evidence that the program is progressing.
Where to start today with your vulnerability management program
If your organization doesn't have an active VMP, the entry point isn't the most comprehensive framework or the most sophisticated solution. It's in this order:
- Take inventory of production assets: software, version, support status
- Identify which systems have direct internet exposure
- It performs passive reconnaissance on these systems: certificate registries, specialized engines, and HTTP headers
- Prioritize CVEs with a CVSS score greater than or equal to 9.0 and apply available patches
- Document the process and assign a responsible person.
That's the minimum viable cycle. It's not perfect, but it's enough to be in a significantly better position than the 96% of the entities documented in the ColCERT report.
Conclusion: vulnerability management turns risk into something manageable
The difference between an exposed and a resilient organization isn't always about budget. In many cases, it's simply about having an active vulnerability management cycle: with an up-to-date inventory, continuous scanning, clear prioritization, and designated individuals responsible for closing vulnerabilities.
A VMP doesn't eliminate risk. It makes it manageable. And that difference, in practice, changes everything.
References and resources
ColCERT Report IN-20260325-029: colcert.gov.co/800/w3-article-428924.html
NIST Cybersecurity Framework 2.0: nist.gov/cyberframework
CIS Controls v8: cisecurity.org/controls
NVD database - CVE: nvd.nist.gov
Main source: ColCERT IN-20260325-029, Information Exfiltration Campaign Report. January-March 2026
0 Comments