Vulnerability Management

TL;DR

• A scan that doesn’t block anything is a report, not a control — scanning without a build-failing threshold doesn’t prevent vulnerabilities from reaching production.
• Enforcement requires a real failure threshold in the pipeline (e.g., block on critical/high, allow medium/low with tracking) to function as an actual gate.
• Risk-based triage (severity, exploitability, reachability) is essential for sustainable remediation; “fix everything” policies are unsustainable and lead teams to disable the gate.
• Reachability analysis — whether a vulnerable library is actually invoked by the application — matters as much as severity; a present-but-unused CVE is lower practical risk.
• Multiple scanners (Trivy, Grype, others) use different databases and logic; running more than one catches scanner-specific blind spots.
• Periodic re-scanning of deployed images catches CVEs disclosed after the original build-time scan; build-time scanning alone structurally cannot.

Core Concepts

Scanning mechanics: Trivy and Grype

Trivy and Grype are widely-used open-source vulnerability scanners that analyze container images, filesystems, and dependency manifests by checking package versions against known vulnerability databases (CVE databases, advisories) and reporting matches. Both serve the same fundamental purpose; the real discipline is in what happens with the results, not the mechanics of running the tool.

Enforcement vs. observation

A scan that only publishes results to a dashboard, with no build-failing threshold, doesn’t prevent anything. Every finding, including critical ones, still deploys to production. A scan is only a control when it can block a pipeline step; otherwise, it’s documentation of risk, not a control against it. Enforcement requires a real failure threshold in the CI pipeline (commonly: fail on critical/high severity, allow medium/low with tracking).

Risk-based triage: the sustainable approach

An unfiltered “fix everything before deploy” policy against a base image with hundreds of findings is often practically impossible. Teams predictably either disable/bypass the gate under delivery pressure or burn effort on low-severity findings while higher-risk ones don’t receive proportional attention. Sustainable triage prioritizes by: severity (CVSS score), known exploitability (is there a public exploit?), and critically, actual reachability in the application.

Reachability: the missing piece in basic scanning

A CVE in a library that’s present in the image but never invoked by any real application code path has meaningfully lower practical risk than the same CVE in a library actively used by network-facing, externally-reachable code. Treating every finding identically regardless of reachability wastes remediation effort on findings that, while technically present, aren’t realistically exploitable in this specific application’s actual behavior.

Multiple scanners: defense in depth

Different vulnerability scanners use different databases and detection logic, and can produce meaningfully different results for the same image. Relying on a single scanner as the only line of defense risks that tool’s specific blind spots becoming the organization’s only blind spots. Running more than one scanner, or at minimum understanding the specific detection gaps of the one in use, provides defense in depth.

Build-time vs. periodic scanning

Build-time scanning only catches vulnerabilities known at the moment of the build. A CVE disclosed after an image was already built and scanned clean doesn’t retroactively appear in the original scan result — it’s new information. Periodic re-scanning of already-deployed images catches vulnerabilities disclosed after the original build, which build-time-only scanning structurally cannot. Both are necessary.

Trivy vs. Grype vs. Other Scanners

Configuration / Command Reference

# Trivy: scan a container image and fail on critical/high severity
trivy image --severity HIGH,CRITICAL --exit-code 1 myregistry.com/myapp:latest

# Trivy: save scan report to JSON for analysis
trivy image -f json -o scan-report.json myregistry.com/myapp:latest

# Grype: scan an image
grype myregistry.com/myapp:latest

# Grype: output JSON and specify severity threshold
grype myregistry.com/myapp:latest -o json > scan.json

# Periodic re-scanning: cron job or scheduled task
0 2 * * * /usr/bin/trivy image --severity HIGH,CRITICAL myregistry.com/myapp:latest >> /var/log/trivy-scan.log 2>&1

# Run both scanners and fail if either finds critical severity
#!/bin/bash
trivy image --severity CRITICAL --exit-code 0 myapp:latest | grep "CRITICAL" && echo "Trivy found critical CVE" && exit 1
grype myapp:latest --fail-on critical || exit 1
exit 0

Common Pitfalls

• Pitfall: Vulnerability scanning deployed and generating findings, but no build-failing threshold, so findings never actually block deployment. Why: Scanning without enforcement is documentation, not prevention; every critical finding still reaches production. Fix: Configure pipeline to fail on critical/high severity findings; make enforcement explicit and non-optional.
• Pitfall: “Fix everything before deploy” policy against a large finding count, causing teams to quietly bypass or disable the scan gate. Why: The policy is unsustainable; teams choose delivery velocity over an impossible remediation burden. Fix: Implement risk-based triage (severity, exploitability, reachability); priori focus on genuinely high-risk findings.
• Pitfall: Remediation effort spent equally across all findings regardless of whether the vulnerable library is actually used. Why: Reachability is omitted from the triage process; low-practical-risk findings consume effort. Fix: Evaluate reachability; deprioritize findings in unused code paths relative to those in actively-exercised, exposed code.
• Pitfall: Images scanned once at build time, never re-scanned; CVE disclosed months later goes undetected in production. Why: Build-time scanning only catches vulnerabilities known at build time; new disclosures are new information. Fix: Implement periodic re-scanning of deployed images as a distinct practice from build-time scanning.
• Pitfall: Relying entirely on one scanner’s results without understanding its specific detection gaps. Why: A single scanner’s blind spots become the organization’s only blind spots. Fix: Run multiple scanners (or at minimum, document the gaps of the one in use) for defense in depth.

Interview Questions

• A CI pipeline runs a vulnerability scan but doesn’t fail the build. What’s the practical security value of this setup? — Tests whether enforcement is correctly identified as the fundamental gap between scanning and actual vulnerability management.
• A scan shows 200 findings in a base image. Walk through how you’d prioritize remediation. — Tests whether risk-based triage (severity, exploitability, reachability) is the reasoned approach versus an unfiltered “fix all” policy.
• Why would you re-scan already-deployed images periodically if they already passed a scan at build time? — Tests understanding of the disclosure-timing gap and the structural limitation of build-time-only scanning.
• What’s the risk of relying entirely on one vulnerability scanner for your security posture? — Tests awareness of scanner-specific blind spots and the value of defense-in-depth multiple scanning.