Vulnerability Management, Interview Questions.

A continuous cycle: discover assets, scan, prioritise by risk, remediate or mitigate, verify, and report. It is a process, not a one-off scan.

A vulnerability is a weakness. A threat is something that can exploit it. Risk is the likelihood and impact of that exploitation in your context. Risk is what you prioritise on.

CVE is an identifier for a specific vulnerability. CWE classifies the weakness type (such as out-of-bounds write). CVSS scores technical severity from 0 to 10: none 0, low 0.1 to 3.9, medium 4.0 to 6.9, high 7.0 to 8.9, critical 9.0 to 10.

Unauthenticated scans see what an outsider sees and find fewer issues. Authenticated scans log in to read patch levels and configuration, giving much more accurate and complete results with fewer false positives.

A reported issue that does not exist. Verify by checking the actual version or configuration, comparing backported fixes (distribution packages often fix without changing version), and confirming with the system owner.

Testing and deploying vendor updates on a schedule, with emergency paths for critical issues, rollback plans, and tracking of exceptions. It is the main way vulnerabilities are removed.

CVSS measures technical severity, not whether anyone exploits it or how much it matters to you. Add exploit likelihood (EPSS), confirmed exploitation (CISA KEV catalogue), asset criticality, internet exposure, compensating controls and data sensitivity.

EPSS estimates the probability a vulnerability will be exploited in the near term. The Known Exploited Vulnerabilities catalogue lists issues with evidence of real exploitation. KEV entries deserve the fastest action.

Numbers vary by organisation. What matters is that the policy is written, owned, measured and has an exception path.

You cannot patch what you do not know exists. Maintain an inventory of hosts, cloud resources, containers, software and owners from multiple sources (CMDB, cloud APIs, EDR, network discovery) and reconcile them. Unknown assets are a leading source of breaches.

Apply a compensating control: isolate or segment, disable the vulnerable feature, add WAF or IPS rules, restrict access, increase monitoring. Record a time-limited risk acceptance signed by the owner with a review date.

Scan images in CI and in registries, fix at the base image or dependency level, rebuild and redeploy rather than patching in place, and use SBOMs to find affected services fast. Filter by whether the vulnerable code is reachable and loaded.

Continuously discovering internet-facing assets, including forgotten domains, test environments, cloud services and third-party hosted systems, and assessing their exposure from an outsider's perspective.

Show risk trends, not raw counts: number of exposed critical issues, mean time to remediate by tier, SLA compliance, aging backlog, KEV items open, and coverage of scanning. Keep a short narrative with decisions needed.

Start with asset discovery and ownership, define scanning scope and credentials, set a risk-based prioritisation model, agree SLAs with IT and engineering, integrate tickets into their workflow, automate where safe (patching, rebuilds), add exception management, and publish metrics. Begin with the internet-facing and critical systems.

Deliver findings with context, clear fix guidance, one owner and a priority reason, avoid sending huge raw lists, batch by root cause, and respect release cycles while holding to critical deadlines. Measure the workload you add and reduce noise.

Coverage gaps, false positives and negatives, blind spots for business logic and custom code, difficulty with ephemeral cloud assets, and scan impact on fragile systems. Combine with agents, code analysis, cloud posture tools and periodic manual testing.

Identify exposure using inventory, apply vendor mitigations, block or restrict access, add detection rules and hunt for exploitation, and monitor vendor advisories. Communicate status and have a plan for rapid patching when available.

Use passive monitoring, strict segmentation, application allowlisting, controlled change windows, vendor coordination and compensating controls. Accept and track residual risk formally.

Rescan with the same method, confirm the version or configuration directly, retest the exploit conditions safely when appropriate, and close the ticket only after verification. Unverified closures create false confidence.

Filter to internet-facing and critical assets, then KEV and high EPSS, group by root cause (one image or template can fix hundreds), automate base image and OS updates, and set owners for the rest with SLAs. Report progress on risk, not count.

Verify the actual package build and vendor advisory for backported fixes, check scanner plugin details and the credentials used, rescan, and mark a documented false positive if confirmed.

Explain the risk in business terms, propose a rolling or maintenance-window approach, apply compensating controls now, and escalate for formal risk acceptance if the delay stays. Put a deadline on the acceptance.