Vulnerability Scanning
Find known weaknesses in dependencies, images, and infrastructure before attackers do.
Theory
Vulnerability scanning automatically checks your software and infrastructure for known weaknesses (catalogued as CVEs). Where it applies:
- SCA (Software Composition Analysis) — scan dependencies for vulnerable libraries (Dependabot, Snyk)
- Container scanning — scan image layers for vulnerable packages (Trivy, Grype)
- SAST / DAST — analyze source code / test the running app
- IaC scanning — catch misconfigurations in Terraform/K8s (tfsec, Checkov)
The goal is shift left: catch issues in CI before deploy. Severity is scored by CVSS; prioritize fixes by severity and exploitability/reachability, not just raw counts.
Real-World Example
# Scan a container image for known CVEs
trivy image myapp:1.4.2
# Scan dependencies
npm audit --audit-level=high
# Scan Terraform for misconfigurations
checkov -d ./infraHands-On Exercise
- Match each scanner type (SCA, SAST, DAST, IaC) to what it analyzes.
- Explain “shift left” in the context of scanning.
- Why prioritize by exploitability, not just CVE count?
- How would you gate a CI build on scan results?
Cheat Sheet▾
| Scan type | Targets |
|---|---|
| SCA | Dependencies (libraries) |
| Container scan | Image layers/packages |
| SAST | Source code |
| DAST | Running application |
| IaC scan | Terraform/K8s misconfig |
| CVE / CVSS | Known vuln / severity score |
| Shift left | Catch issues early in CI |
Common Interview Questions▾
What is shift-left security?
Moving security checks (scanning, testing) earlier in the development lifecycle — into CI and the developer’s workflow — so issues are caught before deploy, when they’re cheaper to fix.
Why prioritize vulnerabilities by more than CVE count?
A high count is meaningless without context. Prioritize by severity (CVSS), exploitability, and whether the vulnerable code is actually reachable in your app.
Official Documentation
📝 My notes on this topic
Auto-saves as you type