Vulnerability Management: From Scanning to Remediation at Scale

Most organisations can scan for vulnerabilities. Very few can actually remediate them systematically. The average enterprise has thousands of open vulnerabilities at any given time, and without a structured programme, critical issues sit unresolved for months while low-priority findings get the most attention simply because someone noticed them.

A vulnerability management programme closes this gap: it creates a repeatable process for discovering vulnerabilities, prioritising them rationally, assigning them to the right owners, and tracking them to closure — with metrics that prove the programme is working. Our managed vulnerability management service and continuous vulnerability scanning run this programme for you.

Why Vulnerability Management Fails

Before building a programme, understand why most fail:

Too many findings, no prioritisation: Running a scanner and presenting 10,000 findings to an engineering team is not vulnerability management — it’s noise. Teams shut down when faced with unmanageable volumes.

CVSS alone is a bad prioritiser: CVSS scores the theoretical severity of a vulnerability. A CVSS 9.8 vulnerability in a system that’s not internet-facing, has no sensitive data, and is isolated from your production network is less urgent than a CVSS 7.2 vulnerability on your public-facing payment gateway. Context matters.

Ownership is unclear: “Security found a vulnerability” → security reports it → nobody owns fixing it → it lives in a spreadsheet forever.

No SLAs: Without agreed remediation timelines, everything is urgent and nothing gets fixed.

Scanning without follow-through: Monthly scans that produce reports nobody reads are a waste of money.

Phase 1: Asset Inventory

You cannot manage vulnerabilities in assets you don’t know about.

Building Your Asset Register

Every asset in your environment needs to be known:

• IP ranges (internal, cloud, VPN)
• Public-facing assets (web apps, APIs, DNS entries)
• Cloud resources (EC2 instances, RDS databases, Kubernetes nodes)
• Endpoints (workstations, laptops, servers)
• Network devices (firewalls, switches, routers)

Tools for discovery:

• Nmap — network scanning to discover live hosts and services
• Shodan — find internet-exposed assets belonging to your IP space/domain
• AWS/Azure/GCP asset inventory — cloud provider APIs to enumerate all resources
• CMDB / asset management systems — Servicenow, Jira, Snipe-IT

Classify your assets:

Phase 2: Scanning Strategy

Scanning Tools

Credentialed vs. Uncredentialed Scanning

Uncredentialed (external/unauthenticated):

• Simulates an external attacker or an insider with no privileges
• Finds exposed services, missing security headers, outdated banners
• Lower coverage — can’t see what’s installed, what patches are missing
• Good for: external attack surface, initial discovery

Credentialed (authenticated):

• Uses local credentials (SSH, WMI, SNMP) to perform deep inspection
• Finds missing patches, outdated software versions, local configuration issues
• 3–5x more findings than uncredentialed
• Good for: internal systems, compliance, comprehensive coverage

Recommendation: Always use credentialed scanning for internal systems. Use uncredentialed scanning for external attack surface monitoring (supplement with continuous attack surface management tools).

Scan Types and Frequency

Avoiding Scan Disruptions

Vulnerability scanners can be intrusive. Reduce risk:

• Schedule intensive scans during maintenance windows for production systems
• Use agent-based scanning for the most sensitive systems (avoids network overhead)
• Exclude systems that can’t tolerate scanning (medical devices, ICS/SCADA, legacy systems with poor error handling)
• Always have an emergency stop procedure communicated to the team before scans run

Phase 3: Risk-Based Prioritisation

Don’t prioritise by CVSS alone. Use a risk-based approach that considers:

Prioritisation Factors

1. Base Severity (CVSS)

• Critical (9.0–10.0)
• High (7.0–8.9)
• Medium (4.0–6.9)
• Low (0.1–3.9)

2. Exploitability in the Wild

• CISA KEV (Known Exploited Vulnerabilities Catalog): If CISA has added a CVE to their KEV list, it’s being actively exploited. Treat these as P1 regardless of CVSS.
• Exploit available: Check if a public PoC exists (ExploitDB, Metasploit modules, GitHub)
• EPSS score: Exploit Prediction Scoring System — machine learning-derived probability that a CVE will be exploited in the next 30 days

3. Asset Context

• Is the system internet-facing?
• Is it in a payment card or health data processing scope?
• What’s the blast radius if this system is compromised?

4. Compensating Controls

• Is a WAF blocking the attack vector?
• Is the vulnerable service behind a firewall with limited access?
• Is network segmentation limiting the impact?

Risk Score Formula

A simple operational risk score:

Risk Score = CVSS × Exploitability Factor × Asset Criticality Factor × Exposure Factor

Where:
  Exploitability: CISA KEV = 1.5, Public exploit = 1.3, No public exploit = 1.0
  Asset Criticality: Critical = 1.5, High = 1.2, Medium = 1.0, Low = 0.7
  Exposure: Internet-facing = 1.5, Internal = 1.0, Isolated = 0.5

This ranks a CVSS 7.5 vulnerability on an internet-facing critical system with a public exploit higher than a CVSS 9.0 on an isolated development box with no public exploit.

Modern tools (Tenable, Rapid7, Qualys) implement similar scoring automatically.

Phase 4: Remediation Workflow

Remediation SLAs

Define and publish SLAs for each severity tier:

Get written agreement from engineering leadership and executives on these SLAs. Without buy-in, you can define SLAs all you want — they won’t be met.

Ownership Assignment

Every vulnerability needs an owner who is accountable for remediation:

Ownership should match who has the ability to fix the issue — not who found it. Security teams find vulnerabilities; engineering teams fix them. Security tracks, escalates, and reports.

Integration with Development Workflow

Vulnerabilities need to enter the teams’ workflow — not a security team spreadsheet:

For engineering teams using JIRA/Linear:

• Create vulnerability tickets automatically via your scanner’s integration
• Tag with severity, SLA, and asset owner
• Security team reviews and triages before assigning
• Ticket closure requires validation (re-scan showing vulnerability resolved)

For cloud teams:

• CSPM findings routed to infrastructure team Slack/Jira
• IaC PR comments from Checkov/tfsec for code-introduced issues

Escalation process:

1. Ticket assigned to team
2. SLA approaching (80%) → automated reminder to assignee
3. SLA missed → escalation to team lead
4. SLA missed by 50% → escalation to security team lead + management
5. SLA missed by 100% → risk acceptance process (CISO sign-off required)

Remediation Options

Not every vulnerability must be patched:

Phase 5: Validation

Closing a ticket without validation is how vulnerabilities linger. Every remediation must be validated:

Re-scan validation:

• Run a targeted scan against the specific asset after remediation
• Confirm the specific CVE no longer appears
• This proves the fix worked, not just that something was done

Manual validation (for complex findings):

• Authenticated credential verification (password change confirmed)
• Service version check (software actually upgraded)
• Configuration validation (firewall rule actually in place)

Regression testing:

• After patching, run your regression test suite to confirm no functionality broken
• Security team validates patch didn’t introduce new issues (version upgrades can include new vulnerabilities)

Phase 6: Metrics and Reporting

Metrics demonstrate programme effectiveness and drive accountability.

Key Metrics

Vulnerability posture metrics:

• Mean Time to Remediate (MTTR) — average days from detection to closure, by severity
• SLA compliance rate — % of vulnerabilities remediated within SLA
• Vulnerability backlog — open critical/high vulnerabilities by team and age
• Vulnerability introduction rate — new vulnerabilities found per scan cycle

Programme effectiveness metrics:

• Coverage — % of assets being actively scanned
• Scan frequency compliance — are all tiers being scanned at required frequency?
• Re-open rate — vulnerabilities closed and then reopened (indicates inadequate validation)

Risk metrics:

• Risk score trend — aggregate risk score over time (should trend down)
• Critical days open — days critical vulnerabilities have been open (zero is the target)
• CISA KEV coverage — are all CISA KEV CVEs patched within 24 hours?

Executive Dashboard

Show executives a simple risk trend, not a list of CVEs:

Overall Vulnerability Risk Score: 342 → 287 (↓16% this quarter)

Critical open: 0 (SLA: 100%)
High open: 23 (SLA: 91%)
Mean time to remediate (High): 18 days (target: 14 days)

CISA KEV: 4 detected this quarter, 4 remediated within 24 hours (100%)

Top 3 teams by outstanding risk:
1. Platform engineering: 12 open High
2. Mobile team: 8 open High
3. Data team: 6 open High

Toolchain for Mature Programmes

Vulnerability Management Platforms

For mid-enterprise and above, a dedicated VM platform significantly reduces operational overhead:

• Tenable.io — comprehensive, strong agent support, integrates with SIEM/SOAR
• Qualys VMDR — robust cloud scanning, built-in risk scoring
• Rapid7 InsightVM — excellent dashboards, good integration with InsightIDR SIEM

These platforms handle: scheduling, credentialed scanning, CMDB integration, ticket creation, SLA tracking, and compliance reporting.

Automation

Automate the boring parts:

• Auto-ticket creation via scanner → Jira integration
• SLA escalation via automated alerts at 80% SLA
• Auto-validation via triggered re-scans after ticket closure
• CISA KEV alerting via CISA RSS feed or API → immediate Slack alert to security team

# Simple CISA KEV monitor
import requests, json

def check_new_kev():
    url = "https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json"
    kev_list = requests.get(url).json()

    # Compare against your known CVE inventory
    # Alert on any KEV CVEs that match your environment
    for vuln in kev_list['vulnerabilities']:
        cve_id = vuln['cveID']
        if cve_id in your_open_vulnerabilities:
            alert_security_team(cve_id, vuln['shortDescription'])

Common Programme Pitfalls

Running scans but not reviewing results: Automation doesn’t replace thinking. Someone must review each scan cycle’s new findings.

Treating all assets equally: A vulnerability management programme that doesn’t differentiate by asset criticality will fail — you’ll always be chasing the wrong things.

No false positive process: Scanners produce false positives. Without a formal process to mark false positives (with justification), your backlog becomes meaningless.

Monthly reporting that nobody reads: Regular reporting should trigger action, not just inform. If your reports don’t drive remediation, they’re not working.

Skipping validation: The most common failure mode — vulnerabilities marked closed that aren’t actually fixed.

CyberneticsPlus builds and matures vulnerability management programmes for organisations across financial services, SaaS, and enterprise. We deploy scanning infrastructure, integrate with development workflows, and deliver risk-based reporting. Contact us to assess your current vulnerability management capability.