CVE Scanning for Linux: Finding and Fixing Vulnerabilities

In January 2024, a critical vulnerability in glibc (CVE-2023-6246) gave local attackers root access on most major Linux distributions. The vulnerability had existed in the codebase since 2022. Organizations that scanned their servers regularly knew within hours of disclosure. Organizations that did not scan discovered the vulnerability only when someone read the news, or worse, when an attacker exploited it.

CVE scanning is the systematic process of checking your Linux servers against the database of publicly known security vulnerabilities. It is the foundation of any serious security program and the first step toward understanding your actual risk exposure. This guide explains how CVE scanning works, how to make sense of the results, and how to build a remediation workflow that keeps your infrastructure secure without consuming all of your engineering time.

What Are CVEs and Why They Matter

CVE stands for Common Vulnerabilities and Exposures. It is a standardized system for identifying and cataloging publicly known security vulnerabilities. Each CVE entry has a unique identifier (like CVE-2024-6387), a description of the vulnerability, and references to advisories and patches.

The CVE system is maintained by MITRE Corporation and funded by the U.S. Department of Homeland Security. When a security researcher discovers a vulnerability, they work with a CVE Numbering Authority (CNA) to assign a CVE ID before or at the time of public disclosure.

Why CVEs matter for Linux operations:

• Shared language. CVE IDs give your team, vendors, and auditors a common reference for specific vulnerabilities. When someone says “have we patched CVE-2024-6387,” everyone knows exactly what they are talking about.
• Tracking. CVEs let you track which vulnerabilities affect your infrastructure, which have been remediated, and which remain open.
• Compliance. Regulatory frameworks reference CVEs when defining vulnerability management requirements. PCI-DSS, HIPAA, SOC 2, and FedRAMP all expect organizations to identify and remediate known CVEs.
• Prioritization. CVE metadata (CVSS scores, exploit availability, affected versions) provides the data you need to decide what to fix first.

The National Vulnerability Database (NVD) enriches CVE entries with severity scores, affected software versions, and other metadata. As of 2025, the NVD contains over 230,000 entries, and new CVEs are published at a rate of roughly 70 per day.

If you manage Linux servers, SysWard’s free tier continuously scans your fleet against CVE databases and shows you exactly which vulnerabilities affect your installed packages, so you can focus on remediation instead of research.

How CVE Scanning Works on Linux

CVE scanning for Linux servers compares your installed software against databases of known vulnerabilities. The process involves three steps: inventory, matching, and reporting.

Step 1: Software Inventory

The scanner inventories every package installed on the server. On Debian and Ubuntu systems, this means querying the dpkg database. On RHEL, CentOS, and Rocky Linux, it queries the RPM database. The result is a list of package names and versions:

openssl 3.0.13-0ubuntu3.1
openssh-server 1:9.6p1-3ubuntu13.4
linux-image-6.8.0-45-generic 6.8.0-45.45
curl 8.5.0-2ubuntu10.3

Some scanners also detect non-packaged software: binaries compiled from source, container images, language-specific dependencies (Python pip, Node npm, Ruby gems), and Java JARs.

Step 2: Vulnerability Matching

The scanner matches each package and version against one or more vulnerability data sources:

• NVD (National Vulnerability Database): the primary source, enriched CVE data from MITRE
• Distribution security advisories: Ubuntu USNs, Debian DSAs, Red Hat RHSAs provide distribution-specific fix information
• CISA KEV catalog: tracks vulnerabilities with confirmed active exploitation
• Vendor advisories: software vendors publish their own vulnerability notices

Matching is version-aware. A CVE that affects OpenSSL 3.0.0 through 3.0.12 will match servers running OpenSSL 3.0.10 but not servers running 3.0.13 (which contains the fix). Distribution backporting complicates this: distributions often patch vulnerabilities without bumping the upstream version number. A scanner that only checks upstream versions will produce false positives. Good scanners use distribution-specific advisory data to account for backported patches.

Step 3: Reporting

The scanner produces a report listing every CVE that matches installed software on each server. Each finding typically includes:

• CVE ID and description
• Affected package and installed version
• Fixed version (if a patch is available)
• CVSS score and severity rating
• Whether the vulnerability is in the CISA KEV catalog
• References to advisories and patches

Understanding CVSS Scores

The Common Vulnerability Scoring System (CVSS) assigns a numerical score from 0 to 10 to each vulnerability based on its technical characteristics. CVSS is the most widely used severity metric, but understanding what it measures (and what it does not) is critical for effective prioritization.

CVSS Score Ranges

Score	Severity	Typical Response
9.0 - 10.0	Critical	Immediate remediation
7.0 - 8.9	High	Remediate within days
4.0 - 6.9	Medium	Remediate within weeks
0.1 - 3.9	Low	Remediate at next opportunity

CVSS Base Score Components

The CVSS base score is calculated from eight metrics grouped into two categories:

Exploitability metrics describe how the vulnerability is exploited: - Attack Vector (AV): Network, adjacent, local, or physical access required - Attack Complexity (AC): Whether exploitation requires special conditions - Privileges Required (PR): Level of access the attacker needs before exploiting - User Interaction (UI): Whether a user must take action for the exploit to work

Impact metrics describe the consequences of exploitation: - Confidentiality Impact ©: Whether data can be read - Integrity Impact (I): Whether data can be modified - Availability Impact (A): Whether the system can be disrupted

A network-exploitable vulnerability with no privileges required and high impact across all three dimensions scores 9.8 or higher. A locally-exploitable vulnerability requiring high privileges and affecting only availability might score 4.0.

Why CVSS Alone Is Not Enough

CVSS measures technical severity in a vacuum. It does not consider:

• Your specific environment. A CVSS 9.8 vulnerability in a package running on an isolated internal server is less urgent than a CVSS 7.0 vulnerability on an internet-facing production system.
• Active exploitation. CVSS does not distinguish between theoretical vulnerabilities and those being actively exploited in the wild. A CVSS 6.5 vulnerability in the CISA KEV catalog is more dangerous than a CVSS 9.0 vulnerability with no known exploit.
• Business context. CVSS does not know whether the affected server hosts your customer database or a developer sandbox.

Use CVSS as one input to your prioritization process, not the only input. Combine it with exploit intelligence, asset criticality, and exposure data for risk-based prioritization.

Building a CVE Scanning Program

Choose Your Scanning Approach

Agent-based scanning installs a lightweight agent on each server that continuously monitors installed packages and reports to a central console. This is the most common approach for Linux fleet management and provides real-time visibility.

Agentless scanning connects to servers remotely (usually via SSH) to inventory packages and check for vulnerabilities. This avoids installing software on target systems but requires network access and credentials.

Registry-based scanning checks container images in registries before they are deployed. This catches vulnerabilities before they reach production but does not cover the host operating system.

For comprehensive coverage, most organizations combine agent-based scanning for hosts with registry scanning for containers. SysWard uses an agent-based approach that provides continuous visibility with minimal overhead.

Define Scanning Cadence

How often you scan determines how quickly you detect new vulnerabilities:

• Continuous (real-time): the agent detects new packages and checks them immediately. Best for production environments.
• Daily: sufficient for most environments. Catches new CVEs within 24 hours of database updates.
• Weekly: the minimum acceptable frequency. Leaves a seven-day detection gap.
• On-demand: useful for pre-deployment checks and incident response, but not a substitute for scheduled scanning.

Handle False Positives

Every scanning program produces false positives. Common causes:

• Backported patches: the scanner flags an upstream CVE, but your distribution has backported the fix to your installed version
• Unused features: the vulnerable code path exists in the package but is not enabled in your configuration
• Mitigating controls: network segmentation or application-level controls prevent exploitation

Document your false positive handling process. Suppress confirmed false positives with notes explaining why, and review suppressions periodically to ensure they remain valid.

Prioritizing CVE Findings

A typical scan of a moderate-sized fleet produces hundreds or thousands of findings. Prioritization turns that overwhelming list into an actionable remediation plan.

The Prioritization Framework

Score each finding across four dimensions, then combine them into a priority tier:

1. Exploit availability and activity - Actively exploited (CISA KEV): highest priority - Public exploit code available: high priority - Proof of concept exists: medium priority - No known exploit: lower priority

2. Exposure - Internet-facing server: higher priority - Internal server with broad access: medium priority - Isolated development environment: lower priority

3. Asset criticality - Handles sensitive data (PII, financial, health): higher priority - Production revenue-generating: higher priority - Staging or testing: lower priority - Development sandbox: lowest priority

4. CVSS base score - Use as a tiebreaker within the above categories

Practical Prioritization Example

Consider two vulnerabilities discovered during a scan:

CVE-A: CVSS 9.8, affects OpenSSL, no known exploit, running on an internal build server with no sensitive data.

CVE-B: CVSS 7.5, affects sudo, listed in CISA KEV (actively exploited), running on an internet-facing production server handling customer data.

By CVSS alone, CVE-A is more severe. By risk-based prioritization, CVE-B demands immediate attention. It has confirmed active exploitation, it runs on an exposed production system, and it handles sensitive data. CVE-A should still be remediated, but it can wait for the regular patch cycle.

This is why scanning tools that provide context beyond CVSS scores deliver better security outcomes. SysWard maps CVEs to your actual infrastructure topology, so you see which vulnerabilities matter most for your specific environment.

The Remediation Workflow

Finding vulnerabilities is the easy part. Fixing them systematically at scale is where most organizations struggle. A structured remediation workflow prevents findings from languishing in dashboards.

Step 1: Triage

Review new scan findings daily. Classify each as: - Remediate: apply the available patch - Mitigate: reduce risk through configuration or network controls - Accept: document the risk and rationale for not remediating - False positive: suppress with documentation

Step 2: Plan

Group remediation actions into batches. Prioritize based on the framework above. Assign ownership: who is responsible for patching which servers? Define the timeline based on your SLA for each priority tier.

Step 3: Test

Before deploying patches to production, test them in a non-production environment. Verify that the patch resolves the vulnerability without breaking application functionality. This is especially important for kernel updates, library updates, and packages that your application depends on directly.

Step 4: Deploy

Apply patches through your automation pipeline. Use staged rollouts to limit blast radius: deploy to a canary group first, validate, then expand to the broader fleet. For distribution-specific guidance:

• Ubuntu patching workflows
• Debian patching workflows
• RHEL patching workflows
• CentOS and Rocky patching workflows

Step 5: Verify

After deployment, rescan the remediated servers to confirm the vulnerability is resolved. Check that the fixed package version is installed and that the CVE no longer appears in scan results. Update your tracking system to mark the finding as remediated.

Step 6: Report

Generate remediation reports showing what was fixed, when, and by whom. Track metrics over time:

• Vulnerability density: average CVEs per server
• Remediation rate: percentage of findings remediated within SLA
• Mean time to remediate (MTTR): by severity tier
• Aging findings: vulnerabilities open longer than SLA

CVE Scanning for Specific Linux Distributions

Each Linux distribution maintains its own security advisory system alongside the upstream CVE database.

Ubuntu

Ubuntu Security Notices (USNs) provide Ubuntu-specific vulnerability information, including which Ubuntu releases are affected and which package versions contain fixes. Canonical maintains a CVE tracker at ubuntu.com/security/cves that maps upstream CVEs to Ubuntu packages. SysWard’s Ubuntu patching integration consumes USN data to provide accurate, Ubuntu-aware vulnerability scanning.

Debian

Debian Security Advisories (DSAs) cover the stable release. The Debian Security Tracker maps CVEs to Debian packages across all supported releases. Debian’s conservative approach to updates means backported patches are common, and scanners must account for this to avoid false positives. SysWard’s Debian support handles this automatically.

RHEL and CentOS

Red Hat Security Advisories (RHSAs) are the gold standard for enterprise Linux vulnerability data. Each RHSA includes severity ratings, affected packages, and fix versions. Red Hat also provides OVAL data for automated compliance checking. CentOS and Rocky Linux follow RHEL advisories closely.

Automation and Integration

Manual CVE scanning and remediation works for small environments but breaks down quickly at scale. Automation at each stage of the workflow multiplies your team’s effectiveness.

Scan Automation

Configure your scanning tool to run continuously or on a daily schedule. New CVE database updates should trigger rescans automatically so you detect newly published vulnerabilities without manual intervention.

Alert Automation

Route findings based on priority. Critical findings with active exploits should page the on-call engineer. High-severity findings should create tickets in your issue tracker. Medium and low findings should appear in weekly reports.

Remediation Automation

For well-tested patches on non-critical packages, fully automated remediation is appropriate. Security patches for standard system packages (openssl, curl, gzip) can often be applied automatically with staged rollouts. Reserve manual intervention for kernel updates, major version changes, and packages your application depends on directly.

Reporting Automation

Generate compliance reports on a schedule. Executive summaries monthly, detailed operational reports weekly, and real-time dashboards for the security team. Automated reporting eliminates the manual effort of pulling data for audits and keeps stakeholders informed.

SysWard automates scanning, alerting, remediation, and reporting across your entire Linux fleet, from a single dashboard to a fleet of thousands.

Frequently Asked Questions

How is CVE scanning different from penetration testing?

CVE scanning checks known vulnerabilities by comparing installed software versions against vulnerability databases. It is automated, fast, and comprehensive for known issues. Penetration testing simulates real attacks to find weaknesses that automated scanning might miss, including logic flaws, chained vulnerabilities, and novel attack paths. CVE scanning handles breadth; penetration testing provides depth. You need both.

Do I need to fix every CVE that scanning finds?

No. Not every CVE poses the same risk to your environment. Use risk-based prioritization to focus on vulnerabilities that are exploitable, exposed, and affect critical assets. Low-severity CVEs on isolated development systems may be acceptable risks. However, document your rationale for accepted risks, and review them periodically.

How quickly should I remediate critical CVEs?

For critical CVEs with active exploitation (listed in CISA KEV), aim for 24 hours. For critical CVEs without known exploits, 72 hours is a reasonable target. Adjust these SLAs based on your industry, regulatory requirements, and risk tolerance. The key metric is consistency: define your SLAs and track compliance.

Can CVE scanning detect zero-day vulnerabilities?

No. CVE scanning detects known vulnerabilities that have been assigned CVE IDs and added to vulnerability databases. Zero-day vulnerabilities are unknown or undisclosed and will not appear in scan results until after they are published. For zero-day protection, you need defense-in-depth: network segmentation, runtime application security, endpoint detection, and rapid patching once the CVE is published.

What is the difference between CVSS v3.1 and CVSS v4.0?

CVSS v4.0, released in November 2023, adds granularity to scoring by introducing supplemental metrics for automatable exploitation, recovery, and value density. It also provides separate scoring for base, threat, and environmental contexts rather than combining them. In practice, many vulnerability databases still use CVSS v3.1 scores, and you may see both for the same CVE. The key improvement in v4.0 is better context-awareness, which aligns with risk-based prioritization approaches.

How do I handle CVEs in end-of-life (EOL) distributions?

End-of-life distributions (like CentOS 7 or Ubuntu 18.04) no longer receive security updates. CVE scanning will continue to find vulnerabilities, but no patches will be available. Your options are: migrate to a supported distribution (the correct long-term answer), purchase extended support from the vendor (Ubuntu Pro, Red Hat ELS), apply mitigating controls (network isolation, hardened configurations), or accept the risk with documentation. EOL systems should be a top priority for migration planning.