Understanding Vulnerability Management: Beyond Vulnerability Scanning

Building a security mindset around vulnerability identification, risk assessment, validation, remediation.

In today's evolving cybersecurity landscape, organizations face an increasing number of vulnerability across their IT infrastructure, applications, operating systems, and network devices.

Identifying vulnerabilities is important, but discovering security weakness is only one part of protecting an organization.

This is Vulnerability Management plays a critical role.

Vulnerability Management is a continous and systematic process of identifying, assessing, prioritizing, remediating, and monitoring security weaknesses within an organization's technology environment.

From a Security Engineer's perspective, the real challenge is not simply finding vulnerabilities. It is understanding their technical impact, determining their actual risk, and ensuring that approriate remediation actions are taken.

1. What is Vulnerability Management?

Vulnerability Management is an ongoing cybersecurity practice designed to reduce an organization's exposure to known security weaknesses.

These weaknesses may exist in:

• Operating systems such as Windows and Linux
• Network devices, including routers, switches, and firewalls
• Web applications and APIs
• Databases and application servers
• Virtualization platforms and cloud infrastructure
• Third-party software and dependencies

The primary objective is not necessarily to eliminate every vulnerability immediately, which is often impractical, but to reduce security risk through effective prioritization and remediation.

Vulnerability Assessment vs. Vulnerability Management

Although these terms are closely related, they have different scopes:

1. Vulnerability Assessment (VA): focuses on identifying and evaluating vulnerabilities within a defined scope.
2. Vulnerability Management (VM): extends beyond assessment by incorporating remediation tracking, risk management, verification, and continuous monitoring.

For example, a vulnerability scanner may identify an outdated software version on a server. A Vulnerability Assessment determines whether the reported weakness is relevant and assesses its severity. Vulnerability Management ensures that the responsible team evaluates the issue, implements appropriate remediation, verifies the result, and tracks the remaining exposure.

In simple terms:

Vulnerability Assessment identifies the problem. Vulnerability Management ensures the problem is addressed.

2. Understanding the Vulnerability Management Lifecycle

An effective Vulnerability Management program follows a continuous lifecycle.

Phase 1: Asset Discovery and Inventory

Before identifying vulnerabilities, organizations must understand which assets exist within their environment. Asset discovery involves identifying systems, applications, services, and devices that may introduce security exposure.

Common asset information includes:

• IP addresses and hostnames
• Operating system versions
• Installed applications and services
• Open network ports
• Asset owners and business functions
• Internet-facing or internal exposure
• Asset criticality

Without an accurate asset inventory, even a sophisticated vulnerability scanner may fail to provide complete security visibility.

Key principle: You cannot effectively protect assets you do not know exist.

Phase 2: Vulnerability Identification

Once the assessment scope is established, security engineers can perform vulnerability scanning using appropriate tools.

Common solutions include:

• Tenable Nessus and Tenable Vulnerability Management
• Qualys VMDR
• Rapid7 InsightVM
• Greenbone/OpenVAS
• Specialized web application security scanners

Depending on the environment, scanning may involve authenticated scans, unauthenticated scans, agent-based assessments, or web application testing. Each approach has advantages and limitations.

Authenticated scanning generally provides better visibility into installed packages, configuration settings, and missing security updates, while unauthenticated scanning provides a network-accessible perspective.

However, scanning results should not automatically be considered confirmed vulnerabilities. They are findings that may require further analysis.

Phase 3: Vulnerability Analysis and Validation

One of the most important responsibilities in Vulnerability Management is determining whether a detected finding accurately represents a security weakness.

A vulnerability scanner may report a finding based on:

• Software version detection
• Service banners
• Configuration analysis
• Missing patches
• Network protocol behavior
• Authenticated package inspection

However, detection accuracy depends on the scan method and the available evidence.

For example, an application may report an outdated software version even though a vendor has backported relevant security patches. In this scenario, version information alone may not be sufficient to establish vulnerability status. A security engineer should investigate available evidence before classifying the finding.

Example: Validating a Detected Service

A basic network scan can help identify exposed ports and services.

nmap -sT -sV -Pn -p 22,80,443 <target-ip>

This command performs a TCP connect scan and attempts to identify services running on selected ports.

To inspect supported TLS cipher suites:

nmap -sT -Pn -p 443 --script ssl-enum-ciphers <target-ip>

To inspect an SSH service:

nmap -sT -Pn -p 22 --script ssh2-enum-algos <target-ip>

These commands can provide useful technical evidence, but their output must be interpreted carefully.

An open port does not automatically indicate a vulnerability. Similarly, a service banner alone does not always prove that a specific CVE is exploitable. All validation activities should be performed only against systems within an authorized assessment scope.

Phase 4: Risk assessment and Prioritization

Not all vulnerability carry the same level of risk. Security engineers must evaluate both technical severity and the environment in which a vulnerability exist. One widely adopted scoring framework is the Common Vulnerability Scoring System (CVSS). CVSS provides a standardizd approach to describing vulnerability characteristics and severity.

For example, a CVSS v3.1 vector might look like:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

This vector describes:

This particular vector corresponds to a CVSS v3.1 Base Score of 9.8 (Critical). However, CVSS alone should not determine remediation priority.

Other factors should be considered:

• Internet-facing versus internal exposure
• Asset criticality
• Availability of known exploits
• Evidence of active exploitation
• Compensating security controls
• Business impact
• Known Exploited Vulnerabilities (KEV) status
• Likelihood of exploitation

A vulnerability rated Medium may require urgent remediation when it affects a critical business asset under particular threat conditions. Conversely, a technically Critical vulnerability may have lower immediate exposure when effective compensating controls significantly restrict potential attack paths.

Severity represent technical characteristics; organizational risk depends on additional context.

Phase 5: Remediation and Mitigation

After vulnerabilities have been validated and prioritized, the next step is to coordinate remediation.

Common remediation activities include:

1. Security Patching: Appliying vendor-provided updates to address known vulnerabilities
2. Configuration Hardening: Disabling insecure protocols, removing unnecessary services, and strengthening authentication or security configurations.
3. Software Upgrades: Upgrading unsupported or outdated applications to maintained versions.
4. Network Segmentation: Restricting unnecessary communication paths between systems.
5. Compensating Controls: Implementing temporary or alternative protections when immediate remediation is not feasible.

For example, an organization may be unable to immediately upgrade a legacy application because of operational dependencies. In this situation, compensating controls such as restricting network access, implementing additional monitoring, and documenting risk acceptance may reduce exposure until a permanent solution become available.

Importantly, risk acceptance should follow an authorized organizational process rather than becoming an informal method of closing vulnerabilities.

Phase 6: Remediation Verification

Applying a patch does not automatically mean a vulnerability has been successfully resolved. Security engineers should verify the remediation outcome.

Verification may include:

• Performing authenticated rescans
• Checking installed software versions and patch levels
• Reviewing vendor advisories
• Repeating relevant configuration checks
• Comparing previous and current assessment evidence

Consider an example where a vulnerability was detected because an outdated TLS protocol was enabled. After the infrastructure team updates the TLS configuration, the security engineer should verify that the insecure protocol is no longer accepted.

The finding should only be marked as remediated when sufficient evidence supports that conclusion. A vulnerability that remains detected after patching may indicate an incomplete update, another affected component, stale scanner data, detection limitations, or unsuccesful deployment.

This is why verification is a necessary part of the remediation lifecycle.

Phase 7: Continous Monitoring and Reporting

Vulnerability Management is not a one-time activity. New Vulnerabilities are continously discovered, applications are updated, infrastructure changes, and new assets are introduced.

A mature Vulnerability Management program should therefore include:

• Scheduled vulnerability assessments
• New vulnerability intelligence monitoring
• Remediation progress tracking
• Recurring finding analysis
• Risk-based reporting
• Verification of previously remediated issues

Useful performance indicators include:

1. Mean time to Remediate (MTTR): The average time required to remediate vulnerabilities within the defined measurement population.
2. Remediation SLA Compliance: The percentage of findings resolved within established remediation deadlines.
3. Vulnerability Aging: The length of time vulnerabilities remain unresolved.
4. Recurring Vulnerabilities: Findings that reappear after previous remediation.

These metric help organizations evaluate whether their Vulnerability Management processes are effective over time.

3. Understanding CVE, CVSS, and Scanner Plugin IDs

Three concepts frequently appear in vulnerability assessment reports: CVE, CVSS and scanner plugin identifiers.

They serve different purposes:

CVE - Common Vulnerabilities and Exposures

A CVE identifier provides a standardized reference for a publicly known security vulnerability.

Example:

CVE-2021-44228

This identifier refers to the Log4Shell vulnerability affecting Apache Log4j.

CVSS - Common Vulnerability Scoring System

CVSS describes the technical characteristics and severity of a vulnerability through standardized metrics. A CVE may have an associated CVSS score, but the score is not itself the vulnerability identifier.

Scanner Plugin ID

A scanner plugin ID identifies a specific detection check implemented by a vulnerability scanning solution. A single plugin may report multiple CVEs, and one CVE may be detected through multiple plugins. This distinction matters when tracking remediation.

For example, upgrading one vulnerable software component may address multiple related CVEs or scanner findings. However, remediation closure should be supported by verification rather than assuming that every related finding has automatically been resolved.

4. Common Challenges in Vulnerability Management

Despite the availability of automated tools, Vulnerability Management still requires analytical judgment and coordination.

False Positive

Automated tools may report vulnerabilities that are not applicable to a specific environment. Validation helps distinguish confirmed weakness from inaccurate detections.

Limited System Visibility

Network-based scans may be unable to identify certain vulnerabilities because of firewalls, authentication restrictions, or inaccessible services.

Remediation Dependencies

Some vulnerabilities cannot be immediately resolved because remediation requires application testing, system downtime, vendor support, or compatibility assessment.

Duplicate Findings

A single underlying issue may appear across multiple CVEs, scanner plugins, or assessment reports. Proper correlation helps avoid unnecessary duplicate remediation work while maintaining traceability.

Communication Between Teams

Security teams identify and communicate vulnerabilities, but remediation may depend on infrastructure, application, database, and network teams. Clear technical evidence, realistic remediation recommendation, and agreed ownership are essential.

5. A Practical Mindset for Security Engineers

An effective Security Engineer should approach vulnerability findings with critical thinking rather than relying exclusively on automated severity ratings.

When reviewing a vulnerability, I believe several questions are especially important:

1. What exactly did the scanner detect?
2. What evidence supports the finding?
3. Is the affected system actually vulnerable?
4. Can the vulnerability be reached under the existing network conditions?
5. What is the potential impact on confidentiality, integrity, and availability?
6. Is there evidence of active exploitation or a publicly available exploit?
7. What remediation action is appropriate?
8. How will succesful remediation be verified?

These questions help transform vulnerability scanning results into actionable security information. The objective is not to generate the largest possible number of findings. It is to provide accurate, meaningful, and prioritized information that helps reduce organizational risk.

6. Key Takeaways

Vulnerability Management is an essential part of maintaining an organization's cybersecurity posture. An effective program involves more than running scheduled vulnerability scans.

It requires an integrated process of asset discovery, vulnerability identification, technical validation, risk-based prioritization, remediation coordination, and continous verification.

For security professionals, developing strong Vulnerability Management skills also requires an understanding of network protocols, operating systems, application behavior, vulnerability intelligence, and risk assessment methodologies.

Most importantly, successful Vulnerability Management should be measured by meaningful risk reduction, not simply the number of vulnerabilities discovered or reported.

Conclusion

Vulnerability Management is both a technical discipline and a continuous risk management process. Automated scanners provide valuable visibility, but human analysis remains essential for interpreting findings, understanding real-world exposure, and recommending appropriate remediation.

As I continue developing my knowledge in cybersecurity and security engineering, Vulnerability Management remains an important area of professional learning and technical exploration.

I plan to explore additional topics in future articles, including CVSS analysis, vulnerability validation, scanner findings, remediation verification, and practical infrastructure security assessments.

Security is not only about finding weaknesses. It is about understanding, prioritizing, and reducing them.

Reference

• FIRST - Common Vulnerability Scoring System
• NIST - Guide for Conducting Risk Assessments (SP 800-30)
• MITRE - Common Vulnerabilities and Exposures
• CISA - Known Exploited Vulnerabilities Catalog
• NIST - Guide to Enterprise Patch Management Planning (SP 800-40 Rev. 4)

Dimasqi Ramadhani · Security Engineer