Practice vocabulary for vulnerability remediation SLAs, CVSS scoring, risk acceptance, patch vs. virtual patch, and compensating controls.
0 / 18 completed
1 / 18
What is a 'remediation SLA' for vulnerabilities, and what are typical timeframes by severity?
Remediation SLAs set enforceable deadlines for fixing vulnerabilities based on severity. Common industry benchmarks: critical (CVSS 9.0–10.0) — 24 hours; high (7.0–8.9) — 7 days; medium (4.0–6.9) — 30 days; low (0.1–3.9) — 90 days. Exact values vary by organisation and compliance framework (PCI DSS, NIST). SLA breaches are tracked in vulnerability management platforms and may trigger escalations.
2 / 18
What is CVSS and what does a CVSS score represent?
CVSS (Common Vulnerability Scoring System), maintained by FIRST, produces a score from 0 to 10 using a formula that weighs exploitability metrics (attack vector, complexity, privileges required, user interaction) and impact metrics (confidentiality, integrity, availability). Scores map to severity bands: None (0), Low (0.1–3.9), Medium (4.0–6.9), High (7.0–8.9), Critical (9.0–10.0). CVSS v3.1 and v4.0 are current versions.
3 / 18
What is the difference between a 'patch' and a 'virtual patch' for a vulnerability?
A software patch updates the vulnerable component — ideally the fastest permanent fix. A virtual patch (also called a shield or mitigation) adds a protective layer — a WAF rule blocking the exploit pattern, a network ACL, or a runtime security control — that prevents exploitation without changing the vulnerable software. Virtual patches are used when a software patch is unavailable (zero-day) or when patching requires extended change-control lead time.
4 / 18
What is a 'compensating control' in vulnerability management vocabulary?
A compensating control mitigates risk when the ideal fix is not immediately feasible. Examples: isolating a legacy system with an unpatched vulnerability behind a firewall with strict ACLs; deploying a WAF rule to block the known exploit pattern; requiring MFA for accounts that could be leveraged via the vulnerability. Compensating controls must be documented and approved as part of a risk acceptance or exception process.
5 / 18
What is a 'vulnerability backlog' and why does it become a problem?
A vulnerability backlog grows when the rate of new findings (from continuous scanning) exceeds the team's remediation capacity. An unmanaged backlog means the organisation's attack surface expands over time. Effective vulnerability management requires prioritisation (CVSS score, exploitability, asset criticality), SLA enforcement, regular triage, and sometimes formally accepting lower-priority risks to keep the backlog manageable.
6 / 18
Reviewer: 'The PR includes a fix for CVE-2023-12345, but the remediation SLA states we have 72 hours to address critical vulnerabilities. This is going to push us over our limit!'
As a developer discussing this with your security team via Slack, which of the following best explains the urgency and potential consequences of exceeding the SLA?
Developer: 'I understand the concern, but we're already working on it. Should I escalate?'
This question tests understanding of SLAs in the context of vulnerability remediation. The SLA isn't just a deadline; it's tied to response time – initially addressing the issue. Options A and B present overly dramatic or dismissive interpretations of the SLA. Option C correctly frames the SLA as an initial commitment while acknowledging the need for thorough testing, which is crucial in real-world development. Option D suggests ignoring the SLA completely, which would be a significant risk considering potential regulatory requirements and security best practices.
7 / 18
PR Description:
Subject: Urgent - Critical Vulnerability Remediation Required
Details:
We've identified a critical vulnerability (CVE-2023-7890) in our payment processing system. The remediation SLA dictates that all critical vulnerabilities must be patched within 24 hours of discovery. Our current estimated time to implement the fix, including testing and deployment, is projected to be 48 hours due to dependencies on a legacy component. The security team has flagged this as potentially high-impact.
Reviewer: 'We need to ensure we're meeting our SLA commitments for critical vulnerabilities. Delaying remediation could expose us to significant risk.'
As a developer discussing this with the Security Team via Slack, which of the following best explains the urgency and potential consequences of not meeting the 24-hour SLA?
This question assesses understanding of the *impact* of SLA breaches beyond simply fulfilling a contractual requirement. The incorrect options reflect common misconceptions: prioritizing speed over quality is risky, viewing SLAs as purely legal obligations ignores their purpose (risk mitigation), and assuming robust monitoring automatically prevents exploitation is often false. Option 2 is correct because failing to meet the critical vulnerability remediation SLA within 24 hours dramatically elevates the risk of a successful attack, with potentially severe consequences like financial loss and reputational damage – this is precisely what the reviewer highlighted.
8 / 18
Reviewer: 'The PR includes a fix for CVE-2023-12345, but the remediation SLA states we have 72 hours to address critical vulnerabilities. This is going to push us over our limit!'
As a developer discussing this with your security team via Slack, which of the following best explains the urgency and potential consequences of exceeding the SLA?
Developer: 'I understand the concern, but we're already working on it. Should I escalate?'
This question tests understanding of SLAs in the context of vulnerability remediation. The SLA isn't just a deadline; it's tied to response time – initially addressing the issue. Options A and B present overly dramatic or dismissive interpretations of the SLA. Option C correctly frames the SLA as an initial commitment while acknowledging the need for thorough testing, which is crucial in real-world development. Option D suggests ignoring the SLA completely, which would be a significant risk considering potential regulatory requirements and security best practices.
9 / 18
PR Description:
Subject: Urgent - Critical Vulnerability Remediation Required
Details:
We've identified a critical vulnerability (CVE-2023-7890) in our payment processing system. The remediation SLA dictates that all critical vulnerabilities must be patched within 24 hours of discovery. Our current estimated time to implement the fix, including testing and deployment, is projected to be 48 hours due to dependencies on a legacy component. The security team has flagged this as potentially high-impact.
Reviewer: 'We need to ensure we're meeting our SLA commitments for critical vulnerabilities. Delaying remediation could expose us to significant risk.'
As a developer discussing this with the Security Team via Slack, which of the following best explains the urgency and potential consequences of not meeting the 24-hour SLA?
This question assesses understanding of the *impact* of SLA breaches beyond simply fulfilling a contractual requirement. The incorrect options reflect common misconceptions: prioritizing speed over quality is risky, viewing SLAs as purely legal obligations ignores their purpose (risk mitigation), and assuming robust monitoring automatically prevents exploitation is often false. Option 2 is correct because failing to meet the critical vulnerability remediation SLA within 24 hours dramatically elevates the risk of a successful attack, with potentially severe consequences like financial loss and reputational damage – this is precisely what the reviewer highlighted.
10 / 18
Reviewer: 'The PR includes a fix for CVE-2023-12345, but the remediation SLA states we have 72 hours to address critical vulnerabilities. This is going to push us over our limit!'
As a developer discussing this with your security team via Slack, which of the following best explains the urgency and potential consequences of exceeding the SLA?
Developer: 'I understand the concern, but we're already working on it. Should I escalate?'
This question tests understanding of SLAs in the context of vulnerability remediation. The SLA isn't just a deadline; it's tied to response time – initially addressing the issue. Options A and B present overly dramatic or dismissive interpretations of the SLA. Option C correctly frames the SLA as an initial commitment while acknowledging the need for thorough testing, which is crucial in real-world development. Option D suggests ignoring the SLA completely, which would be a significant risk considering potential regulatory requirements and security best practices.
11 / 18
PR Description:
Subject: Urgent - Critical Vulnerability Remediation Required
Details:
We've identified a critical vulnerability (CVE-2023-7890) in our payment processing system. The remediation SLA dictates that all critical vulnerabilities must be patched within 24 hours of discovery. Our current estimated time to implement the fix, including testing and deployment, is projected to be 48 hours due to dependencies on a legacy component. The security team has flagged this as potentially high-impact.
Reviewer: 'We need to ensure we're meeting our SLA commitments for critical vulnerabilities. Delaying remediation could expose us to significant risk.'
As a developer discussing this with the Security Team via Slack, which of the following best explains the urgency and potential consequences of not meeting the 24-hour SLA?
This question assesses understanding of the *impact* of SLA breaches beyond simply fulfilling a contractual requirement. The incorrect options reflect common misconceptions: prioritizing speed over quality is risky, viewing SLAs as purely legal obligations ignores their purpose (risk mitigation), and assuming robust monitoring automatically prevents exploitation is often false. Option 2 is correct because failing to meet the critical vulnerability remediation SLA within 24 hours dramatically elevates the risk of a successful attack, with potentially severe consequences like financial loss and reputational damage – this is precisely what the reviewer highlighted.
12 / 18
Reviewer: 'The PR includes a fix for CVE-2023-12345, but the remediation SLA states we have 72 hours to address critical vulnerabilities. This is going to push us over our limit!'
As a developer discussing this with your security team via Slack, which of the following best explains the urgency and potential consequences of exceeding the SLA?
Developer: 'I understand the concern, but we're already working on it. Should I escalate?'
This question tests understanding of SLAs in the context of vulnerability remediation. The SLA isn't just a deadline; it's tied to response time – initially addressing the issue. Options A and B present overly dramatic or dismissive interpretations of the SLA. Option C correctly frames the SLA as an initial commitment while acknowledging the need for thorough testing, which is crucial in real-world development. Option D suggests ignoring the SLA completely, which would be a significant risk considering potential regulatory requirements and security best practices.
13 / 18
PR Description:
Subject: Urgent - Critical Vulnerability Remediation Required
Details:
We've identified a critical vulnerability (CVE-2023-7890) in our payment processing system. The remediation SLA dictates that all critical vulnerabilities must be patched within 24 hours of discovery. Our current estimated time to implement the fix, including testing and deployment, is projected to be 48 hours due to dependencies on a legacy component. The security team has flagged this as potentially high-impact.
Reviewer: 'We need to ensure we're meeting our SLA commitments for critical vulnerabilities. Delaying remediation could expose us to significant risk.'
As a developer discussing this with the Security Team via Slack, which of the following best explains the urgency and potential consequences of not meeting the 24-hour SLA?
This question assesses understanding of the *impact* of SLA breaches beyond simply fulfilling a contractual requirement. The incorrect options reflect common misconceptions: prioritizing speed over quality is risky, viewing SLAs as purely legal obligations ignores their purpose (risk mitigation), and assuming robust monitoring automatically prevents exploitation is often false. Option 2 is correct because failing to meet the critical vulnerability remediation SLA within 24 hours dramatically elevates the risk of a successful attack, with potentially severe consequences like financial loss and reputational damage – this is precisely what the reviewer highlighted.
14 / 18
Slack Message: 'Hey team, just noticed a new vulnerability report for CVE-2023-9876 – High severity. The SLA requires us to address this within 24 hours. I'm checking if we have the resources ready.' What does 'SLA' likely stand for in this context?
An SLA (Service Level Agreement) defines the expected performance or quality of a service. In this case, it's an agreement between your team and whoever issued the vulnerability report regarding the timeframe for addressing it. Options A & C are misinterpretations; B is irrelevant to the question, and D represents a specific remediation action.
15 / 18
Code Review Comment: 'This fix addresses CVE-2023-4567. The SLA specifies a response time of 7 days for medium vulnerabilities. Do we have the necessary documentation to support this remediation?' What is the primary purpose of referencing a vulnerability's severity in an SLA?
The severity level (High, Medium, Low) in an SLA dictates the urgency and priority of remediation. Higher severity vulnerabilities require faster response times and more resources due to their greater potential impact on security and business operations. Options A, B & C are related to cost or task management, not the core purpose of SLAs.
16 / 18
PR Description:
Subject: Patch Release - Critical Vulnerability Remediation
Details:
The PR includes a patch for CVE-2023-1122. The SLA mandates a fix within 48 hours for critical vulnerabilities, regardless of existing backlog. What does 'regardless of existing backlog' imply in this scenario?
'Regardless of existing backlog' means that the SLA's requirements (in this case, a 48-hour timeframe) take precedence over any other outstanding work or issues. It signifies an absolute commitment to addressing the critical vulnerability within the defined SLA, irrespective of other priorities. Options A & C are incorrect; B is too strong, and D is simply untrue.
17 / 18
Standup Update: 'We've deployed the patch for CVE-2023-5555. The SLA requires us to submit a detailed report outlining the remediation steps within 24 hours. What type of document would this requirement be referring to?
The SLA is demanding a 'risk assessment summary' – this document would detail the steps taken to address the vulnerability and provide an overview of the associated risks. This demonstrates accountability and ensures that the remediation aligns with the severity level and potential impact defined in the SLA. Options A & B are incorrect, and D is too broad.
18 / 18
API Response:GET /vulnerability_status?cve=CVE-2023-6666{
"status": "open",
"severity": "critical",
"sla_deadline": "2024-03-15T12:00:00Z",
"assigned_to": null
}
What does the sla_deadline field indicate?
The sla_deadline field represents the target timeframe within which the vulnerability must be remediated according to the Service Level Agreement. This is a key component in tracking progress and ensuring compliance with SLA requirements. Options A & C are misinterpretations; B describes its function accurately.
What does the "Vulnerability Remediation SLA Vocabulary" exercise cover?
Practice vocabulary for vulnerability remediation SLAs, CVSS scoring, risk acceptance, patch vs. virtual patch, and compensating controls.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall.
How many questions are in "Vulnerability Remediation SLA Vocabulary"?
This exercise has 18 questions. Each one gives instant feedback with an explanation, so you can see exactly why an answer is right or wrong.
Do I need to create an account to save my progress?
No account is required. The progress bar and score are tracked in your browser for the current session -- the exercise is designed to be a quick, repeatable drill rather than something you resume later.
What happens if I get an answer wrong?
You'll see the correct answer highlighted immediately, along with a short explanation of why it's correct. Wrong answers aren't penalized beyond your score, and you can keep going through every question.
How is this exercise different from reading an article?
Articles explain vocabulary and concepts through prose, while exercises like this one are interactive drills -- multiple-choice questions -- that test and reinforce your recall of specific terms and phrasing.
Can I retry this exercise?
Yes -- use the "Try again" button on the results screen to reset your score and go through all the questions again from the start.
Where can I find more Devsecops Pipeline Language exercises?
Browse the full Devsecops Pipeline Language hub for related drills, or check the site-wide exercises index for other IT English topics.
Is this exercise suitable for beginners?
This exercise assumes basic familiarity with IT terminology. If a term feels unfamiliar, check the site Glossary for a plain-English definition before attempting the questions.
How often is new content like this published?
New exercises are added regularly across all categories, alongside new vocabulary sets and articles. Check back on the exercises hub to see what's new.