Practice vulnerability scanning vocabulary: CVE remediation SLAs, transitive dependencies, false positive suppression, and severity-based remediation timelines.
0 / 5 completed
1 / 5
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 / 5
'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 / 5
'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 / 5
'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 / 5
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.