1. Introduction: After vulnerability detection, how to determine “which one to fix first”?
In the previous article, we used vulnerability scanning tools to identify “security risks” in the system, similar to discovering multiple issues during a thorough cleaning at home: aging window seals, slight water leaks in pipes, and poor contact in outlets. If we blindly start repairs, we might spend a lot of time fixing the seals (low-risk vulnerabilities) while neglecting the potential for water leaks to cause floor mold (high-risk vulnerabilities). In Linux systems, vulnerability detection tools often output dozens or even hundreds of vulnerability results—some are remotely exploitable remote code execution vulnerabilities, some are local privilege escalation vulnerabilities, and some are “historical vulnerabilities” that no longer pose a real threat. If we repair without assessment, it not only wastes operational resources but may also miss the opportunity to block high-risk attacks by prioritizing the repair of low-risk vulnerabilities.
In real life, emergency rooms in hospitals use a “triage system” to determine patient priority: heart attack patients (high-risk vulnerabilities) are treated first, fracture patients (medium-risk vulnerabilities) next, and cold patients (low-risk vulnerabilities) are treated last. Linux vulnerability assessment serves as the system’s “triage mechanism”: by using standardized risk classification (such as CVSS scores), impact analysis (whether it affects core business), and exploitability assessment (whether there are publicly available exploit tools), we determine the priority of vulnerability remediation, allowing operational resources to be accurately directed to the most critical security risks. This article will connect the vulnerability detection system, detailing vulnerability risk classification methods, impact assessment techniques, and remediation priority decision logic, while also introducing practical assessment tools in real-world applications, helping operational personnel move from “discovering vulnerabilities” to “precise decision-making”.
2. Tool Matrix: Professional Tools for Risk Quantification and Impact Analysis
Vulnerability assessment must consider “risk quantification”, “impact analysis”, and “data processing”—cvss-score implements standardized scoring for vulnerability risks, vulners-cli queries the current state of vulnerability exploitation, and jq assists in parsing scan reports. All tools are well-known open-source solutions that are continuously updated, and the commands can be executed directly as tested.
1. Core Tool Explanation (including precise installation and configuration)
Note: This is just a brief introduction to scoring tools; I have not used them. My personal understanding of scoring should consider the impact range, where weak passwords can be classified as low or high risk. A simple mnemonic: Remote / Core / Unauthorized = High Risk, Conditional / Low Impact = Medium Risk, No Impact = Low Risk.
Tool Coordination Example (Vulnerability Assessment Process):
Export scan report using OpenVAS: omp -u admin -w password –get-report 123 –format json > /tmp/openvas_report.json;
Extract basic vulnerability data using jq: jq ‘.results[] | .name, .cve, .cvss_base_score, .host’ /tmp/openvas_report.json > /tmp/vuln_raw.txt;
Verify CVSS score using cvss-score: cvss score –vector “CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H” (corresponding to the score vector for CVE-2021-44228);
Query exploitation status using vulners-cli: vulners search CVE-2021-44228 –type exploit, confirm the existence of publicly available exploit tools;
Determine priority using riskcalc: ./riskcalc.sh –cvss 9.8 –business-impact high, output “Priority: P0 (Emergency Fix)”.
2. Tool Selection Logic
Risk Quantification: Prioritize cvss-score, calculating scores through standardized CVSS vectors to avoid subjective judgment bias;
Intelligence Supplement: Use vulners-cli to obtain real-time information on vulnerability exploitation and patch information, assessing the “actual harm level” of vulnerabilities;
Report Processing: Use jq to quickly parse scan reports, extracting key data in bulk, suitable for multi-vulnerability batch assessment scenarios;
Comprehensive Decision-Making: Combine riskcalc, integrating CVSS scores with business impact (e.g., core database vs. test server), to determine the final remediation priority.
3. Scenario-Based Practice: Three Core Scenarios for Accurate Vulnerability Assessment
The core of vulnerability assessment is “quantifying risk + combining business + determining priority”. The following three scenarios cover the entire process from data extraction to decision output, each scenario combines real-life logic with actionable command steps.
1. Scenario One: Vulnerability Risk Classification—Scoring Vulnerabilities with CVSS
CVSS (Common Vulnerability Scoring System) is the “universal language” for vulnerability risk classification, similar to how schools use a “percentage system” to evaluate student performance. CVSS quantifies vulnerability risk on a scale of 0-10, avoiding subjective judgments like “this vulnerability seems dangerous”.
(1) Core Operational Steps
Obtain the CVSS vector for the vulnerability:
Extract the CVSS vector (core input data) from the vulnerability scan report or CVE database:
# Method 1: Extract CVSS vector from OpenVAS report (using jq for parsing)jq '.results[] | select(.cve == "CVE-2021-44228") | .cvss_vector' /tmp/openvas_report.json# Method 2: Query from CVE database (using vulners-cli)vulners search CVE-2021-44228 --format json | jq '.data[0].cvss3'# Output example: "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H"Calculate the CVSS score and determine the level:
Calculate the score using cvss-score and classify the risk level according to standards (High: 7.0-10.0, Medium: 4.0-6.9, Low: 0.1-3.9, No Risk: 0.0):
# Calculate CVSS3.1 score for CVE-2021-44228cvss score --vector "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H"# Output: 9.8 (High Risk)# Parse scoring dimensions (understand the reasons for high risk)cvss explain --vector "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H"# Output dimension explanation: Attack Vector(N)=Network Accessible, Attack Complexity(L)=Exploitation Simple, etc.Batch scoring for multiple vulnerabilities:
Score all vulnerabilities in the scan report in bulk, generating a risk classification list:
# 1. Extract all CVEs and CVSS vectors from OpenVAS report, save to filejq -r '.results[] | "
(.cve)
(.cvss_vector)"' /tmp/openvas_report.json > /tmp/vuln_vectors.txt# 2. Batch calculate scores and add risk levelswhile read -r cve vector; do score=$(cvss score --vector "$vector" 2>/dev/null) # Determine risk level if (( $(echo "$score >= 7.0" | bc -l) )); then level="High Risk" elif (( $(echo "$score >= 4.0" | bc -l) )); then level="Medium Risk" elif (( $(echo "$score > 0.0" | bc -l) )); then level="Low Risk" else level="No Risk" fi echo "$cve $score $level"done < /tmp/vuln_vectors.txt > /tmp/vuln_risk_level.txtAnalogy:
This is similar to restaurant hygiene inspection scoring—health departments use “quantitative standards” (e.g., ingredient freshness 20 points, utensil disinfection 30 points, environmental hygiene 50 points) to score restaurants, with scores above 80 being “excellent”, 60-80 being “qualified”, and below 60 being “unqualified”. CVSS scoring works similarly, scoring vulnerabilities based on “attack vector, complexity, permission requirements”, making risk levels clear at a glance.
2. Scenario Two: Vulnerability Impact Analysis—Determining “Which Business Will Be Affected by the Vulnerability”
The harm of a vulnerability depends not only on the CVSS score but also on the business importance of the affected assets. A “remote code execution vulnerability” present on a web server (core business) is far more harmful than one on a test server (non-core).
(1) Core Operational Steps
Extract affected asset information:
Obtain the IP, hostname, and running services corresponding to the vulnerability from the scan report, clarifying the affected assets:
# Extract "High Risk Vulnerabilities + Affected IP + Running Services" from OpenVAS reportjq -r '.results[] | select(.severity == "High") | "
(.host)
(.port)
(.service)
(.cve)"' /tmp/openvas_report.json > /tmp/high_risk_assets.txt# Example output:192.168.1.100 80 http CVE-2021-44228Associate business importance:
Combine with an asset list (which needs to be maintained in advance) to mark the business roles of affected assets (e.g., core database, web server, test machine):
# Assume the asset list is asset_list.csv (format: IP, business role, person in charge)# Associate high-risk vulnerabilities with business rolesjoin -t ' ' -1 1 -2 1 <(sort /tmp/high_risk_assets.txt) <(sort -t ',' -k1,1 asset_list.csv | tr ',' ' ') > /tmp/high_risk_business.txt# Example output:192.168.1.100 80 http CVE-2021-44228 Web Server Zhang SanAnalyze the potential for impact spread:
Determine whether the vulnerability can spread across assets (e.g., worm vulnerabilities) or affect associated businesses (e.g., database vulnerabilities affecting APP services):
# Use vulners-cli to check if the vulnerability has spreading capabilities (e.g., worm characteristics)vulners search CVE-2021-44228 --format json | jq '.data[0].tags | any(. == "wormable")'# Output true (has worm characteristics) or false (no spreading capability)# Mark spreading risksed -i 's/$/ Spreading Risk: Yes/' /tmp/high_risk_business.txt # Add a mark for worm vulnerabilitiesAnalogy:
This is similar to community epidemic prevention—after discovering a COVID case, it is necessary to assess not only the patient’s condition (corresponding to CVSS score) but also to track their activity history (affected assets): if the patient visited a vegetable market (core business asset), urgent containment is required; if they only visited their own community (non-core asset), the control scope can be reduced. Vulnerability impact analysis works similarly, requiring assessment of the harm range based on asset business roles.
3. Scenario Three: Determining Repair Priority—Clarifying “Which Vulnerability to Fix First”
Repair priority must comprehensively consider “CVSS score, business impact, exploitability” to avoid extreme situations of “only fixing high-scoring vulnerabilities while ignoring core business” or “only looking at business while ignoring high-risk vulnerabilities”.
(1) Core Operational Steps
Collect key decision data:
Integrate CVSS scores, business impact, and exploitability (whether there are public exploits):
# 1. Extract CVE, score, and business role from previous filescut -d' ' -f1,2,5 /tmp/high_risk_business.txt > /tmp/priority_raw.txt# 2. Batch query the exploitability of each vulnerability (whether there are public exploits)while read -r cve score business; do exp_count=$(vulners search "$cve" --type exploit | grep -c "Exploit") if [ $exp_count -gt 0 ]; then exploit="Has Public EXP" else exploit="No Public EXP" fi echo "$cve $score $business $exploit"done < /tmp/priority_raw.txt > /tmp/priority_data.txtEstablish priority rules and sort:
Set priority rules (e.g., P0 = High Score + Core Business + Has EXP; P1 = High Score + Non-Core / Medium Score + Core; P2 = Low Score + Core / Medium Score + Non-Core), and sort in bulk:
# Write priority determination script (priority.sh)cat > /tmp/priority.sh << 'EOF'#!/bin/bashwhile read -r cve score business exploit; do if (( $(echo "$score >= 7.0" | bc -l) )) && [ "$business" = "Web Server" ] && [ "$exploit" = "Has Public EXP" ]; then priority="P0 (Emergency Fix, within 24 hours)" elif (( $(echo "$score >= 7.0" | bc -l) )) || ([ "$business" = "Web Server" ] && $(echo "$score >= 4.0" | bc -l)); then priority="P1 (Priority Fix, within 72 hours)" else priority="P2 (Regular Fix, within 1 week)" fi echo "$cve $score $business $exploit $priority"done < /tmp/priority_data.txtEOF# Execute script and sort (by priority from high to low)bash /tmp/priority.sh | sort -k5,5 > /tmp/vuln_priority.txtGenerate priority report:
Organize the results into an easily readable report, clarifying repair deadlines and responsible persons:
# Combine with asset responsible person information to generate final reportjoin -t ' ' -1 1 -2 1 <(sort /tmp/vuln_priority.txt) <(sort -t ',' -k1,1 asset_list.csv | tr ',' ' ' | awk '{print $1 " " $3}') > /tmp/final_priority_report.txt# Example report content:# CVE-2021-44228 9.8 Web Server Has Public EXP P0 (Emergency Fix, within 24 hours) Zhang SanAnalogy:
This is similar to prioritizing home repairs—if multiple issues arise at home, such as “water pipe leaks (high risk, affecting the floor), light bulb failure (low risk, not affecting use), wardrobe door looseness (medium risk, affecting storage)”, the repair priority should be: water pipe leak (P0, fix within 24 hours) → wardrobe door looseness (P1, fix on the weekend) → light bulb failure (P2, replace when free). Vulnerability repair priority works similarly, determining the order of handling based on risk and impact.
Conclusion: Vulnerability Assessment is the “Core Basis” for Repair Decisions, Connecting Vulnerability Remediation Strategies
Vulnerability assessment is not a simple “scoring and ranking” process, but a comprehensive decision-making process that combines technical risks (CVSS scores), business value (asset importance), and attack status (exploitability). By using cvss-score for risk standardization, vulners-cli for real-time intelligence supplementation, and jq for efficient report data processing, we ultimately output actionable remediation priorities, allowing operational resources to be precisely matched to the most critical security needs—this addresses the common pain points of “too many vulnerabilities to fix” and “fixing irrelevant vulnerabilities while missing high-risk ones”.
The value of vulnerability assessment lies in “guiding action”: vulnerability detection is about “discovering problems”, vulnerability assessment is about “clarifying how to solve problems”, and subsequent vulnerability remediation requires “specific execution plans”—including patch installation, configuration hardening, and temporary mitigation measures. Different types of vulnerabilities (such as kernel vulnerabilities, application vulnerabilities, configuration vulnerabilities) require different remediation strategies. The next article, “Linux System Vulnerability Remediation Strategies”, will focus on practical methods for vulnerability remediation, detailing safe operations for patch installation, key steps for configuration hardening, and the logic for formulating temporary mitigation measures, while also introducing verification methods post-remediation, forming a complete security loop of “vulnerability detection – risk assessment – vulnerability remediation – effect verification”, providing a full-process solution for Linux system vulnerability protection.
