🔍 Vulnerability Management
End-to-end vulnerability lifecycle — scanning, assessment, risk-based prioritization, patching, and continuous monitoring across infrastructure and applications.
Vulnerability Management is the ongoing process of identifying, evaluating, remediating, and reporting on security vulnerabilities across an organization's systems and software. A mature program uses risk-based prioritization (CVSS, EPSS, asset criticality) to focus resources on the most impactful vulnerabilities. Key tools include Qualys, Nessus, Rapid7, and Tenable.
Key Concepts
CVSS Scoring
Common Vulnerability Scoring System — industry-standard for rating vulnerability severity (Base, Temporal, Environmental scores from 0.0 to 10.0).
EPSS (Exploit Prediction)
Exploit Prediction Scoring System — probabilistic model predicting the likelihood a vulnerability will be exploited in the wild within 30 days.
Patch Management
Systematic processes for testing, approving, and deploying security patches. Includes emergency patching procedures for critical zero-days.
Risk-Based Prioritization
Combining CVSS, EPSS, asset criticality, exploit availability, and business context to prioritize remediation efforts effectively.
SBOM
Software Bill of Materials — inventory of all components in software. Critical for identifying affected systems when new CVEs are disclosed.
Vulnerability Scanning
Automated discovery of known vulnerabilities using authenticated and unauthenticated scans across networks, hosts, web apps, and containers.
Vulnerability Management Lifecycle
Vulnerability Management Lifecycle
Continuous cycle from discovery to remediation to monitoring
📚 CWE vs CVE vs CVSS vs CWSS — Know the Difference
These four acronyms form the backbone of vulnerability management. Understanding how they relate is essential for any security role.
📝 CWE — Common Weakness Enumeration
What: Catalog of software/hardware weakness types
Maintained by: MITRE
Example: CWE-79 (XSS), CWE-89 (SQL Injection)
Think: The category of bug — “what kind of mistake was made?”
🔴 CVE — Common Vulnerabilities & Exposures
What: Unique ID for a specific discovered vulnerability
Maintained by: MITRE / NVD (NIST)
Example: CVE-2021-44228 (Log4Shell)
Think: The specific bug — “this exact flaw in this software”
📊 CVSS — Common Vulnerability Scoring System
What: Severity score (0-10) for a specific CVE
Maintained by: FIRST.org
Scores: Base + Temporal + Environmental
Think: “How bad is this specific bug?”
🎯 CWSS — Common Weakness Scoring System
What: Risk score for a weakness type (CWE)
Maintained by: MITRE
Factors: Technical Impact + Attack Surface + Environmental
Think: “How risky is this type of weakness overall?”
| Aspect | CWE | CVE | CVSS | CWSS |
|---|---|---|---|---|
| Full Name | Common Weakness Enumeration | Common Vulnerabilities & Exposures | Common Vulnerability Scoring System | Common Weakness Scoring System |
| Scope | Weakness types | Specific instances | Scores for CVEs | Scores for CWEs |
| Maintained By | MITRE | MITRE / NVD | FIRST.org | MITRE |
| Format | CWE-ID | CVE-Year-ID | 0.0 – 10.0 | 0.0 – 100.0 |
| Used For | Classifying weakness categories | Tracking specific vulnerabilities | Prioritizing CVE remediation | Prioritizing CWE mitigation |
| Example | CWE-89 (SQL Injection) | CVE-2021-44228 (Log4Shell) | 9.8 Critical | 78.5 High |
How They Connect
A CWE (weakness type) leads to many CVEs (specific bugs). Each CVE gets a CVSS severity score. Each CWE gets a CWSS risk score. CWE + CWSS help you fix classes of bugs. CVE + CVSS help you fix specific bugs.
🌋 The Vulnpocalypse — Why Traditional VM Is Broken
The term "Vulnpocalypse" describes the unsustainable explosion in CVE volume that has made traditional "patch everything" vulnerability management impossible. No team can keep up — and trying to is the wrong strategy.
Interview Preparation
What is the Vulnpocalypse and how do you manage vulnerability overload?
The Vulnpocalypse refers to the unsustainable explosion in CVE volume — over 40,000 CVEs were published in 2024 alone (roughly 110 per day), driven by AI-assisted discovery, open-source dependency sprawl, expanded CNA programs, and cloud infrastructure growth. Traditional 'patch everything' VM is mathematically impossible. The answer is intelligent prioritization using 4 pillars:
1EPSS OVER CVSS ALONE — less than 5% of CVEs are ever exploited in the wild. Use EPSS (Exploit Prediction Scoring System) to identify which CVEs have high exploitation probability in the next 30 days. A CVSS 9.8 with EPSS 0.05% is lower priority than a CVSS 6.5 with EPSS 82%.
2CISA KEV WATCHLIST — treat every entry in CISA's Known Exploited Vulnerabilities catalog as Priority Zero with mandatory SLA regardless of CVSS score.
3EASM-FIRST — internet-facing assets carry 10x the risk of internal systems. Prioritize all CVEs on externally exposed assets before internal-only ones.
4COMPENSATING CONTROLS & RISK ACCEPTANCE — formally risk-accept low-EPSS, internal-only findings with documented owner and review date, and apply WAF rules or segmentation as compensating controls for medium CVEs on isolated systems. This approach reduces 40,000 CVEs to the ~200 that genuinely matter for your environment.
How do you prioritize vulnerabilities for remediation?
Use risk-based prioritization combining:
1CVSS base score for technical severity,
2EPSS for exploit probability,
3Asset criticality and business context,
4Exploit availability (Metasploit modules, PoC code, active exploitation),
5Exposure (internet-facing vs. internal),
6Compensating controls. A CVSS 7.0 vulnerability on an internet-facing payment server with a known exploit ranks higher than a CVSS 9.8 on an isolated test server.
What KPIs would you track for a vulnerability management program?
Key KPIs:
1Mean Time to Remediate (MTTR) by severity,
2Vulnerability density per asset,
3Scan coverage percentage,
4SLA compliance rates for patching,
5Recurrence rate (vulnerabilities re-introduced),
6Risk reduction over time,
7Number of critical/high vulnerabilities open beyond SLA. Track trends monthly and report to leadership.
How do you use scripting and coding in Java and Python for security engineering, vulnerability management, and compliance?
Security engineers who can code have a massive force multiplier — automation replaces repetitive manual work and scales security across the organization.
- Python is the go-to language for security scripting because of its rich library ecosystem
- Common use cases — writing API integrations to pull scan results from Veracode, Qualys, or Nessus and push them into Jira or ServiceNow automatically
- Building custom parsers to normalize vulnerability data from multiple scanners into a unified format (CSV, JSON, or database)
- Automating compliance evidence collection — scripting checks for CIS Benchmarks, SOC 2 controls, or PCI-DSS requirements and generating audit-ready reports
- Key libraries — requests (API calls), pandas (data analysis and reporting), paramiko (SSH automation), boto3 (AWS security audits), python-nmap (network scanning), BeautifulSoup (web scraping for OSINT)
- Java is used for building enterprise security tools, custom SAST rules, and integrations with Java-based platforms
- Common use cases — writing custom Veracode API wrappers to orchestrate policy scans across hundreds of applications in CI/CD
- Building custom static analysis rules using SpotBugs or Error Prone to detect organization-specific anti-patterns
- Creating security middleware and filters in Spring Boot applications — custom authentication filters, request validation, and audit logging
- Developing custom Burp Suite extensions in Java for automated testing of application-specific vulnerabilities
- Automate the full vulnerability lifecycle — scan scheduling, result ingestion, deduplication, severity enrichment (adding business context to CVSS scores), SLA tracking, and escalation notifications
- Build dashboards that aggregate data from SAST, SCA, DAST, and infrastructure scanners into a single pane of glass
- Script auto-ticketing — when a Critical finding is detected, automatically create a Jira ticket with CWE ID, affected component, remediation guidance, and assign to the right team
- Track metrics programmatically — MTTR, vulnerability density per application, recurrence rates, SLA compliance percentages
- Script compliance checks — verify encryption settings, access controls, logging configurations, and patch levels against policy baselines
- Generate automated compliance reports for auditors — map vulnerabilities to specific control frameworks (NIST 800-53, ISO 27001, PCI-DSS, HIPAA)
- Build drift detection scripts that alert when configurations deviate from approved baselines
- Automate evidence collection for SOC 2 Type II audits — pull access reviews, change management logs, and security scan results into structured reports
- Python script to query Veracode REST API, pull all High/Critical findings across the portfolio, calculate MTTR per team, and email a weekly executive summary
- Java utility to scan all Spring Boot applications for missing security annotations
- Python automation to check AWS S3 bucket policies, IAM configurations, and CloudTrail logging against CIS AWS Benchmark and flag non-compliant resources
Explain the difference between CWE, CVE, CVSS, and CWSS — how do they relate to each other?
These four form the vulnerability management vocabulary:
1CWE (Common Weakness Enumeration) — maintained by MITRE, it's a catalog of software weakness TYPES. Think of it as the category. CWE-79 is XSS, CWE-89 is SQL Injection, CWE-787 is Out-of-bounds Write. It answers: what KIND of mistake was made?
2CVE (Common Vulnerabilities & Exposures) — maintained by MITRE/NVD, it's a unique ID for a SPECIFIC discovered vulnerability in a specific product. CVE-2021-44228 is Log4Shell. It answers: which EXACT bug in which software?
3CVSS (Common Vulnerability Scoring System) — maintained by FIRST.org, it scores CVEs on a 0-10 scale with three metric groups: Base (attack vector, complexity, impact), Temporal (exploit maturity, remediation level), and Environmental (your specific context). It answers: how BAD is this specific bug?
4CWSS (Common Weakness Scoring System) — maintained by MITRE, it scores CWE weakness TYPES on a 0-100 scale considering technical impact, attack surface, and environmental factors. It answers: how risky is this TYPE of weakness overall? THE RELATIONSHIP: A CWE (weakness type like SQL Injection) can lead to MANY CVEs (specific SQL injection bugs in specific products). Each CVE gets a CVSS score (0-10 severity). Each CWE gets a CWSS score (0-100 risk). CWE + CWSS help you prioritize fixing CLASSES of bugs through secure coding standards. CVE + CVSS help you prioritize patching SPECIFIC bugs in your environment. Real-world example: Developers find a SQLi bug in your app → it maps to CWE-89 → it gets assigned CVE-2024-XXXXX → NVD rates it CVSS 9.8 Critical → you prioritize immediate remediation based on CVSS + EPSS + business context.
What is the difference between EASM, Vulnerability Management, and Penetration Testing — and how do they work together?
These three are complementary disciplines, not competitors. EASM (External Attack Surface Management) answers 'What can an attacker see about us?' — it continuously discovers all internet-facing assets, including shadow IT, forgotten staging environments, and dangling DNS records you didn't know existed. Vulnerability Management answers 'What known weaknesses exist and how do we fix them?' — it scans known assets for CVEs, missing patches, and misconfigurations, then tracks remediation against SLAs. Penetration Testing answers 'Can those weaknesses actually be exploited?' — a skilled red team validates exploitation in practice, confirming real-world impact. HOW THEY FIT TOGETHER: EASM discovers unknowns → feeds those assets into the VM program for deep scanning → PenTesting validates whether remaining risks are truly exploitable. Without EASM, your VM program only scans what you know about — attackers find the rest first. Without VM, you know what's exposed but not how to fix it. Without PenTesting, you know what's vulnerable but not whether it's exploitable in your specific environment. KEY DIFFERENCES: Scope — EASM is external-only; VM covers internal + external; PenTesting is defined scope. Frequency — EASM is continuous (24/7); VM runs on scan cycles; PenTesting is point-in-time (quarterly/annual). Asset Discovery — EASM discovers unknown assets; VM assumes you have an inventory; PenTesting uses a predefined scope. Exploitation — only PenTesting actively exploits. Mature programs run all three in parallel.
Framework Mapping
| Framework | Relevant Controls |
|---|---|
| NIST | SP 800-53 RA-5 (Vulnerability Monitoring), SI-2 (Flaw Remediation), CM-8 (Component Inventory) |
| OWASP | Vulnerability Disclosure, Dependency Check, Dependency Track |
| MITRE | T1190 (Exploit Public-Facing App), T1068 (Exploitation for Privilege Escalation) |
