Vulnerability Management Workflow: Scan, Prioritize, Fix

Vulnerability management is less about finding flaws and more about making the right flaws visible to the right people at the right time.

Let’s watch a vulnerability scan actually happen. Imagine we’re using Nessus (a common scanner) targeting a simple web server running on 192.168.1.100.

# This is a simplified representation, actual commands vary by tool
nessuscli --scan "My Web Server Scan" --target 192.168.1.100 --plugins "web,apache,ssl" --policy "Full Audit" --output /tmp/webserver_scan.nessus

When this command runs, Nessus doesn’t just "look" for vulnerabilities. It actively probes the 192.168.1.100 machine. For the web and apache plugins, it might:

• Send an HTTP GET request to / and analyze the Server header (e.g., Apache/2.4.41 (Ubuntu)).
• Attempt to access common administrative interfaces like /phpmyadmin or /admin.
• Check for specific Apache configurations that might be insecure (e.g., directory listing enabled).
• For ssl, it will perform a TLS handshake, checking certificate validity, supported cipher suites, and protocol versions (TLS 1.0, 1.1, 1.2, 1.3).

The output /tmp/webserver_scan.nessus is a detailed report, not just a list of CVEs. It contains the IP address, port, service, the specific test that failed, the CVE associated with the failure, and crucially, the evidence found on the target.

The core problem vulnerability management solves is signal-to-noise ratio. In any moderately sized environment, you’ll find thousands, even millions, of potential vulnerabilities. Without a structured process, security teams drown in alerts, and critical issues get lost.

Here’s how it breaks down internally:

1. Discovery: The scanner enumerates assets (IPs, ports, services) within its scope. This is often done via network sweeps (nmap style) and then port scanning.
2. Assessment: For each identified service, the scanner applies a set of plugins. These plugins are essentially scripts that know how to test for specific weaknesses. They might:
   • Send crafted network packets.
   • Attempt to log in with default credentials.
   • Analyze banner information.
   • Query specific API endpoints.
   • Check file permissions.
3. Reporting: Results are aggregated, correlated, and presented. This involves mapping scanner findings to known CVEs in databases like NVD.

The levers you control are primarily within the scanner’s configuration and the subsequent workflow:

• Scope: What IPs, subnets, or assets does the scanner cover? This is your attack surface.
• Scan Policy/Plugins: Which types of checks are enabled? A "basic" scan might only look for known vulnerable software versions, while a "full audit" might attempt credentialed checks, configuration audits, and more.
• Frequency: How often are scans run? Daily, weekly, monthly? This impacts how quickly new vulnerabilities are detected.
• Credentials: For authenticated scans (using SSH, WinRM, SNMP, etc.), providing valid credentials allows the scanner to log in and perform much deeper checks, like examining installed software versions directly from package managers or registry entries. This dramatically reduces false positives and increases detection rates.
• Prioritization Engine: This is where the raw scan data becomes actionable. It typically involves:
  • Exploitability: Is there a known public exploit for this CVE?
  • Threat Intelligence: Are active campaigns targeting this vulnerability right now?
  • Asset Criticality: Is this vulnerability on a public-facing web server or an isolated development machine?
  • CVSS Score: The Common Vulnerability Scoring System provides a baseline severity.

The one thing most people don’t realize is that vulnerability scanners often have a "credentialed scan" mode, and failure to use it is the single biggest reason for both missed vulnerabilities and endless noise. When a scanner logs into a system (say, via SSH to a Linux box or WinRM to a Windows server), it can directly query the installed software inventory, check file permissions, and examine configuration files. This is vastly more accurate than trying to infer software versions from network banners or HTTP headers, which can be easily spoofed or misconfigured, leading to false positives. Without credentials, the scanner is effectively blindfolded, relying on guesswork.

The next hurdle is integrating this raw data into a reactive incident response process.