Practice vulnerability scanning vocabulary: CVE remediation SLAs, transitive dependencies, false positive suppression, and severity-based remediation timelines.
0 / 10 completed
1 / 10
A security engineer says 'the scanner found 3 critical CVEs in our dependencies'. What is a CVE?
CVE (Common Vulnerabilities and Exposures) is the standard system for identifying and cataloguing security vulnerabilities. Each CVE has a unique ID (e.g., CVE-2021-44228 for Log4Shell), a severity score (CVSS), and a description. Scanners check your dependencies against the CVE database to identify known vulnerabilities.
2 / 10
'We remediate critical CVEs within 24 hours.' What does this SLA mean in practice?
Remediation SLAs define how quickly vulnerabilities must be addressed based on severity. Critical CVEs (typically CVSS 9.0+) pose the highest risk and require the fastest response. Remediation may mean patching the dependency, applying a workaround, or documenting an accepted risk if no fix is available. The SLA clock starts from when the vulnerability is confirmed.
3 / 10
'The vulnerability is in a transitive dependency.' What is a transitive dependency?
A transitive (or indirect) dependency is a package your code depends on through another package. For example, your app imports Package A, which imports Package B — B is a transitive dependency. Transitive vulnerabilities are common and harder to manage because you may not even know they exist without a scanner or SBOM.
4 / 10
'The false positive was suppressed with justification.' What is required when suppressing a vulnerability finding?
Suppressing a false positive means telling the scanner to ignore a specific finding. Good security practice requires documenting the justification: why is this finding not exploitable in your context? (e.g., 'the vulnerable code path is never called', 'the network is isolated'). Suppressions without justification create audit risk and obscure real issues.
5 / 10
What does 'remediation SLA by severity' mean?
Remediation SLAs are tiered by severity to focus resources on the highest risks. A typical policy: Critical = 24-48 hours, High = 7 days, Medium = 30 days, Low = 90 days. This ensures the team isn't paralysed trying to fix everything at once while ensuring critical risks are addressed rapidly.
6 / 10
Sarah (Security Analyst) posted in the #devops channel: 'The scanner identified a potential vulnerability – a missing TLS cipher suite – in our API gateway. It's currently flagged as high severity.' What does 'TLS cipher suite' refer to in this context?
TLS (Transport Layer Security) is a protocol for securing network communications. A 'cipher suite' defines the specific algorithms used to encrypt and authenticate data transmitted between two systems – think of it as the 'recipe' for secure communication. Misconceptions often arise because 'TLS' is frequently confused with 'SSL', though SSL is an older version.
7 / 10
During a code review of a new microservice, David (Senior Developer) comments: 'The vulnerability scanner identified a potential SQL injection risk due to unsanitized user input. We should implement parameterized queries for all database interactions.' What is the primary purpose of using 'parameterized queries' in this scenario?
SQL injection is a common vulnerability where attackers can manipulate database queries through user input. Parameterized queries treat user input as *data*, not code, effectively preventing malicious SQL commands from being executed. This isolates the query and avoids the risk of unauthorized data access or modification.
8 / 10
Maria (DevOps Engineer) is writing a PR description for a vulnerability scan report: 'The scanner flagged a high severity vulnerability – a lack of input validation – in the user registration form. We've added server-side validation to mitigate this risk.' What does 'server-side validation' typically involve?
Server-side validation is crucial for security because client-side JavaScript can be bypassed by attackers. By performing input validation on the server, you ensure that only legitimate data makes it into your system, significantly reducing the risk of vulnerabilities like cross-site scripting (XSS) or SQL injection. Client-side validation should *complement*, not replace, server-side checks.
9 / 10
Ben (Security Engineer) is explaining the vulnerability scanning workflow to a new team member: 'We use a dynamic analysis tool that automatically identifies vulnerabilities by simulating attacks against our running applications. The output includes 'false positives' – findings that incorrectly identify vulnerabilities.' What does a 'false positive' indicate?
False positives are common in automated vulnerability scanners. They occur when the scanner flags a potential issue that doesn't actually represent a real security risk – for example, because a particular configuration is considered vulnerable but isn't actively exploited or doesn't pose a significant threat. It's important to investigate and dismiss these findings properly.
10 / 10
Emily (Lead Developer) is responding to a Slack message from a junior developer: 'I've suppressed the vulnerability finding related to a deprecated library. Should I just ignore it?' What action should Emily advise the developer to take?
Suppressing a vulnerability finding is a serious action that requires careful consideration and documentation. Simply ignoring it isn't acceptable; a justification must be provided explaining why the vulnerability is being treated differently from others – often due to low impact or lack of exploitability. Crucially, ongoing monitoring is needed to mitigate any residual risk.
What will I learn from the "Vulnerability Scanning Workflow Vocabulary" exercise?
Practice vulnerability scanning vocabulary: CVE remediation SLAs, transitive dependencies, false positive suppression, and severity-based remediation timelines.
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 required.
How many questions are in this exercise?
This set contains 10 multiple-choice questions, each with a detailed explanation shown after you answer.
Do I need to create an account to track my progress?
No account is required. Your progress bar and score reset each time you reload the page, but you can retry the exercise as many times as you like.
Who is this Supply Chain Security exercise for?
This exercise is built for IT professionals and non-native English speakers who need to read, write, and discuss supply chain security topics confidently at work.
What happens if I answer a question incorrectly?
You will see the correct answer highlighted along with a detailed explanation of why it is correct -- so every wrong answer becomes a learning moment, not just a lost point.
Can I retry this exercise?
Yes -- click "Try again" on the results screen at any time to reset your score and go through all the questions again.
How long does this exercise take to complete?
Most learners finish all 10 questions in under 10 minutes, since each question is answered by clicking a single option.
Where can I find more Supply Chain Security exercises?
See the full Supply Chain Security exercises hub for more vocabulary drills on this topic.
Is this exercise mobile-friendly?
Yes -- the exercise works on any device with a modern browser, including phones and tablets, with no app download required.