Interview › Security & DevSecOps
How do you decide whether to patch, mitigate, or accept the risk of a vulnerability? [Intermediate]
Answer
I decide whether to patch, mitigate, or accept risk based on exploitability, exposure, business impact, patch availability, operational risk of the fix, compensating controls, and compliance requirements. Patching is preferred, mitigation is temporary, and acceptance requires documented approval.
Technical explanation
Patch when a safe fix is available and the vulnerability is reachable or high-impact.
Mitigate when immediate patching is risky or unavailable; examples include disabling a feature, blocking ingress, WAF rule, network segmentation, or reducing privileges.
Accept only when the residual risk is understood, approved by the right authority, time-bounded, and reviewed regularly.
Hands-on example
Example: a critical RCE affects a library used by an internet-facing API. Patch immediately if tests pass. If no patch exists, block the vulnerable endpoint at the gateway, restrict network access, increase detection, and set an exception expiry for the vendor fix.
Check how well your resume matches the role with our free resume checker— match score, ATS check, and the skills you're missing.
More Security & DevSecOps interview questions
- What is DevSecOps, and how does it differ from traditional security gating at the end? [Basic]
- What does shift-left security mean, and why does it matter? [Basic]
- What is the difference between SAST, DAST, IAST, and SCA? [Basic]
- When in the pipeline does each of SAST, DAST, and SCA run? [Basic]
- What is the difference between SAST and DAST, and what does each catch and miss? [Basic]
- What is software composition analysis (SCA), and why does it matter for dependencies? [Basic]
- What is SonarQube, and what does it analyse? [Basic]
- Is SonarQube primarily SAST, code quality, or both? [Basic]