Detection and Handling of Vulnerabilities in Images
🌟 Objective
Ensure that all container images used in pipelines, test environments or production are analysed for known vulnerabilities (CVEs), producing objective technical signals that support informed decisions on mitigation, acceptance or blocking.
This file defines how to detect and classify vulnerabilities, not how to decide automatically on the acceptability of risk.
🧬 What vulnerabilities in images are
Each container image includes potentially vulnerable libraries, runtimes and binaries, introduced through different routes:
- Inherited from the base image;
- Introduced by application dependencies;
- Transitive (dependencies of dependencies);
- Resulting from the build process itself.
A vulnerability identified by a scanner indicates:
- the presence of an affected component,
- association with a known CVE,
- potential technical impact.
⚠️ The presence of a CVE does not automatically imply exploitable risk in the real context of the application.
⚠️ Detection is not risk assessment
It is fundamental to avoid the following incorrect equivalence:
- ✔️ CVE detected → valid technical signal
- ❌ CVE detected ≠ automatically unacceptable risk
- ❌ High CVSS ≠ guaranteed real impact
Risk assessment requires additional context:
- code actually exposed;
- available attack vectors;
- runtime permissions and hardening;
- criticality of the application and data processed.
This file deals with technical detection and classification, not with the final decision.
📘 Analysis tools (SCA for containers)
| Tool | Technical function | Role in SbD-ToE |
|---|---|---|
| Trivy | Fast detection of CVEs | Initial signal |
| Grype | SBOM ↔ vulnerability correlation | Precision and traceability |
| Snyk Container | Additional contextualisation (SaaS) | Support for triage |
| Docker Scout | Visualisation of layers and dependencies | Exploratory analysis |
These tools detect presence, not exploitability or real impact.
🛠️ How to apply detection correctly
- Generate the SBOM of the final image (see
06-inventario-sbom.md); - Run an SCA scanner on the real image;
- Produce a technical report, including:
- CVE;
- affected package;
- version;
- CVSS;
- fix available or not;
- Classify the vulnerabilities technically:
- with a fix available;
- without a fix available;
- inherited from the base image;
- Preserve the results as versioned evidence;
- Route the results to human analysis, where applicable.
Automation does not eliminate the need for interpretation.
📂 Storage and traceability of results
To ensure auditability:
- Store reports per image and digest;
- Version results per build;
- Associate scanner, database and timestamp;
- Correlate with the SBOM and the image signature.
Untraceable results have no operational or auditable value.
🔍 Correct use of scanning results
In SbD-ToE, vulnerability results must be used to:
- Prioritise fixes;
- Detect security regressions;
- Support documented acceptance or mitigation decisions;
- Feed continuous improvement metrics.
They must not be used as:
- a substitute for risk analysis;
- proof of security;
- a sole blocking mechanism without context.
✅ Good practices
- Define initial technical thresholds (e.g. CVSS ≥ 7) as a trigger, not as a verdict;
- Distinguish exploitable vulnerabilities from theoretical ones;
- Regularly review vulnerabilities inherited from the base image;
- Automate remediation when a fix is available;
- Document risk acceptance where applicable;
- Review decisions after incidents or new information.
📎 Cross-references
| Document | Relation to vulnerabilities |
|---|---|
01-imagens-base.md | Minimisation reduces the CVE surface |
06-inventario-sbom.md | Scanner uses the SBOM as its basis |
03-assinatura-cadeia-trust.md | Integrity of the analysed image |
09-riscos-processo-imagens.md | Scanners as a signal, not a decision |
15-aplicacao-lifecycle.md | Integration into the SSDLC |
🚨 Detected vulnerabilities are technical signals, not sentences.
Real risk only exists when the signal is interpreted in the correct context.