Vulnerability Management Interview Questions

A CVE identifier is a unique, standardized reference number assigned to one specific, publicly disclosed vulnerability, maintained by the CVE Program — it carries no severity information on its own. The National Vulnerability Database (NVD), run by NIST, separately enriches each CVE entry with a CVSS severity score and other metadata after the ID is assigned.

Identification (detect/discover vulnerabilities), Evaluation (assess severity and prioritize), Remediation/Mitigation (apply patches or compensating controls), and Verification (confirm the fix is effective and report).

I would build a four-stage pipeline. Stage 1 — Ingestion: the nightly scanner output is parsed into normalized finding records and deduplicated against the previous run so we only see net-new or changed findings. Stage 2 — Automated Validation: each finding is enriched with asset context (is the host internal-only? is it behind a WAF?) and cross-referenced against a patch-level database. Findings triggered by stale version strings are auto-suppressed if a patch verification check confirms the CVE is actually remediated. Known false-positive signatures are matched against a suppression rule set; matches are auto-dismissed with a reference to the rule. Stage 3 — Analyst Triage: anything that survives auto-validation is queued for a human analyst who confirms the finding, marks it as a false positive with a reason, or escalates it for remediation. Stage 4 — Resolution: confirmed vulnerabilities are routed to the asset owner with an SLA; confirmed false positives are logged in a feedback database. When an analyst marks a finding as a false positive, the system prompts them to create or extend a suppression rule (scoped to asset + CVE + detection signature) so the scanner or the pipeline automatically suppresses that finding on future runs. Suppression rules have an expiry date (e.g., 90 days) and are reviewed quarterly to catch environment changes that could turn a previous false positive into a real risk.

I would start by exporting all recurring findings and grouping them by scanner plugin ID and asset group. For each group, an analyst manually verifies one representative instance — for the SSL certificate finding, they would inspect the actual certificate chain and confirm the signature algorithm; for the Apache disclosure finding, they would verify the ServerTokens configuration by making an HTTP request and checking the response headers. Once a pattern is confirmed as a false positive, I apply a targeted scanner exception scoped to that specific plugin and asset group rather than disabling the plugin globally, because the same plugin may flag genuine issues on other assets where the configuration differs. For example, I would create an exception rule: 'Suppress plugin 12345 on assets in the internal-services group.' I prefer credential-based authenticated scanning where possible because it eliminates many network-level false positives by letting the scanner verify patch status directly — for instance, confirming a patch is installed rather than inferring vulnerability from version banners alone. Every exception is time-limited (e.g., 90-day expiry) so that when the environment changes — a certificate renewed with a different algorithm, a server reconfigured, or a new CVE assigned to the same software — the expired exception forces a fresh evaluation against the current state rather than continuing to suppress what may now be a true positive. Additionally, I would set up a quarterly review where all active exceptions are re-tested against the current environment, and any infrastructure change (new host, OS upgrade, config change) in the CMDB triggers an automatic re-scan of affected assets with exceptions temporarily lifted for that scan cycle, so a newly-introduced vulnerability that matches a previously-suppressed pattern is caught immediately.

A network vulnerability scanner automatically probes systems across a network to identify known vulnerabilities — such as missing patches, misconfigurations, and weak services — typically by comparing detected software versions and settings against a database of known vulnerability signatures (e.g., CVE entries).

False. A zero-day vulnerability is a flaw for which no patch or fix is publicly available yet, meaning defenders have had zero days to prepare. The statement actually describes a known, patched vulnerability — the opposite of a zero-day.

A CVSS v3.1 base score of 9.4 falls in the Critical band (9.0-10.0). The spec defines five qualitative severity bands over the 0-10 score range: None, Low (0.1-3.9), Medium (4.0-6.9), High (7.0-8.9), and Critical (9.0-10.0).

Nessus, Qualys, and OpenVAS are all purpose-built vulnerability scanners that fingerprint hosts and services against known-vulnerability signatures to produce a prioritized findings list. John the Ripper is an offline password-cracking tool and Wireshark is a packet-capture and protocol-analysis tool — neither performs vulnerability scanning, despite being common tools in the same field.

True. Banner-based vulnerability detection is a proxy signal, not proof of exploitability — vendors regularly backport security fixes into an existing release without changing the reported version string, so a scanner keyed purely on the version string can flag an already-patched system as vulnerable. This is why manual exploitation validation, or an active/authenticated scan check, exists to confirm exploitability rather than trusting the banner alone.

A zero-day is a vulnerability that is being actively exploited, or is publicly known, before the vendor has released a patch — and often before the vendor is even aware of it — meaning defenders have had zero days of lead time to remediate it before it could be used against them. A known vulnerability has an assigned CVE, is documented in a database like the NVD, and typically already has a vendor-supplied patch or a documented mitigation available, so managing it is a matter of scheduling and applying the fix rather than facing an unpatchable exposure.

A vulnerability management lifecycle runs in a fixed order: discovery (scan and identify potential vulnerabilities), triage (validate findings and filter out false positives), prioritization (rank by CVSS, EPSS, exploit availability, and asset criticality), remediation (apply the fix), and verification (rescan to confirm the vulnerability is actually closed). Skipping verification is how a program ends up believing something is fixed when it never was actually re-checked.

The external attack surface includes internet-facing web applications, publicly accessible cloud storage buckets, and shadow-IT subdomains created without IT oversight. Internal VPN-only workstations and private internal code repositories are not externally reachable, so they fall outside the external attack-surface scope even though they still matter for internal vulnerability management.

CVSS v3.1's Attack Vector metric describes the context an attacker must have relative to the vulnerable component: Network (remotely exploitable, potentially over the internet), Adjacent (same network segment), Local (requires local access), or Physical (requires physically touching the device). It's a separate metric from Privileges Required (prior authentication needed), User Interaction (victim action needed), and Scope (impact beyond the component's own security authority).

CVSS v3.1's Base metric group has exactly eight metrics: Attack Vector, Attack Complexity, Privileges Required, User Interaction, and Scope, plus Confidentiality, Integrity, and Availability impact. 'Patch Availability' isn't a Base metric name — the closest real concept, Remediation Level, is an optional Temporal metric, not a Base one — and 'Time Since Disclosure' isn't a CVSS metric at all.

False. Mature vulnerability management programs use risk-based prioritization — combining CVSS with exploit availability, asset exposure, and business criticality — to set differentiated remediation SLAs, not one blanket rule for every Critical finding regardless of context. A 24-hour SLA fits a Critical, internet-facing, actively-exploited finding, but not identically for an isolated internal asset with the same CVSS score.

CVSS base score measures technical severity in the abstract — it assumes the most exploitable, most impactful conditions and doesn't account for whether a working exploit actually exists in the wild, whether the affected asset is internet-facing or otherwise reachable by an attacker, whether compensating controls (a WAF, network segmentation) already reduce real exposure, or how business-critical the asset is. Two findings with an identical CVSS score can carry very different real-world risk. Mature programs combine CVSS with EPSS (a data-driven estimate of exploitation likelihood), asset exposure and criticality, and current threat intelligence to prioritize the remediation queue instead of sorting purely by CVSS score.

The Exploit Prediction Scoring System — a data-driven model maintained by FIRST.org that estimates the probability (0-1, often reported as a percentile) that a specific CVE will be exploited in the wild in roughly the next 30 days. CVSS scores theoretical severity — how bad exploitation would be, if it happened. EPSS scores real-world exploitation likelihood. They're meant to be used together for prioritization, not as substitutes for each other: a high-CVSS, high-EPSS finding is the clearest signal to remediate first.

The correct execution order is: D → B → E → F → A → C — asset inventory, vulnerability scan, prioritization, staging test, production deployment, then verification. Each step produces the input the next one requires: you cannot scan assets you have not inventoried, cannot prioritize vulnerabilities you have not identified, cannot test patches you have not prioritized, cannot deploy what you have not tested, and cannot verify what you have not deployed.

The correct vulnerability management lifecycle order is: (1) Discover and inventory in-scope assets, (2) Scan assets to identify vulnerabilities, (3) Prioritize vulnerabilities based on risk, (4) Remediate or mitigate them, and (5) Verify remediation through re-scanning. Each phase depends on the previous phase's output, as described in NIST SP 800-40 and similar frameworks.

Line 2 — an unauthenticated flaw exploitable remotely over the internet should be scored Attack Vector: Network, not Physical, which requires the attacker to physically touch or manipulate the device

Line 6 — the function branches only on CVSS base score and never factors in exploit likelihood (EPSS) or asset criticality, so a low-exposure internal test finding gets the same urgency as an internet-facing one with the same CVSS score, while a lower-CVSS but actively-exploited flaw gets deprioritized behind it

The core failure mode is a coverage blind spot: when ephemeral assets spin up and terminate between scheduled scan windows, they are never inventoried or scanned, so exploitable vulnerabilities on them go undetected for their entire lifecycle. This effectively means a portion of the attack surface is invisible to the VM program. Two compensating controls: (1) Integrate vulnerability scanning into the build/deployment pipeline using image scanning at CI/CD time and admission-control scanning at container runtime, so vulnerabilities are assessed before or at launch rather than during a scheduled window. (2) Deploy an agent-based or API-driven continuous assessment model (e.g., cloud-native security posture management or runtime agents) that reports vulnerability state at asset boot and periodically throughout its life, decoupling detection from network scan schedules.

In vulnerability management program operations, the key performance indicator that measures the average elapsed time from initial vulnerability detection to verified remediation is known as Mean Time to Remediate. This metric is commonly tiered by severity (e.g., Critical ≤ 7 days, High ≤ 30 days) and directly reflects the efficiency of the patch management lifecycle.

In ITIL-aligned patch management operations, when a critical security patch must be deployed outside the standard change window, expedited approval is typically sought from the Emergency Change Advisory Board — a smaller, on-call subset of the Change Advisory Board convened specifically to evaluate and authorize urgent, high-risk changes to production environments.

In enterprise vulnerability scanning, authenticated scanning supplies logon credentials to the scanner so it can directly inspect the target host's local patch registry and installed-software inventory, producing significantly fewer false positives and false negatives than unauthenticated network-based scanning that relies solely on banner grabbing and fingerprinting.