Scansione delle vulnerabilità e delle patch
Breve riepilogo
La gestione delle vulnerabilità è un ciclo continuo: rilevamento, valutazione del rischio di eliminazione (patch, migrazione/config), verifica dei rapporti. Le tecnologie di scansione (SCA/SAST/DAST/IAST/Cloud/Container) forniscono segnali, mentre il contesto (esposizione, privilegi, dati, EPSS, esposti) determina la priorità. Lo scopo è quello di ridurre i rischi reali senza interruzioni di attività, utilizzando automazione, canarie e SLO chiari.
Tassonomia scansione
SCA (Software Composition Analysis) - Analisi delle dipendenze/licenze rilevamento CVE nelle librerie, SBOM.
SAST - Analisi statica del proprio codice prima dell'assemblaggio.
DAST: Scatola nera dinamica contro il servizio operativo.
IAST: sensori all'interno dell'applicazione (durante i test) - meno FP, più profondo il contesto.
Container/OS Scan: immagini (base immagine, pacchetti), host (kernel/pacchetti/confighi), benchmark CIS.
Cloud/Infra (CSPM/KSPM): misconfigi cloud/K8s (IAM, reti, crittografia, bustini pubblici).
Secret Scan: perdite di chiavi/token nei repository e nelle immagini.
Binary/Artifact Scan - Verifica dei manufatti raccolti (firme, vulnerabilità).
Modello di rischio e priorità
Valutazione = CVSS v3. x base) x EPSS (probabilità di utilizzo) x contesto (esposizione, dati, privilegi, compensazioni).
Fattori contestuali:- Esposizione a Internet/interno, presenza di WAF/mTLS/isolamento.
- Dati: PII/finanza/segreti.
- Privilegi di processo/sito, capacità laterale movement.
- La presenza di un esploratore pubblico/attacchi di massa, i requisiti della compilazione.
Esempio di vettore CVSS: 'CVSS: 3. 1/AV: N/AC: L/PR: N/UI: N/S: U/C: H/I: H/A: H's ha criticato; se il servizio è pubblico e senza misure compensative è P1.
Soglie SLO (esempio):- P1 (critici, operativi): fix da 48 ore
- P2 (alto): ≤ 7 giorni.
- P3 (media): 30 giorni.
- P4 (basso/inform) - piano/backlog.
Ciclo di vita di gestione delle vulnerabilità
1. Inventario delle risorse: servizi, immagini, cluster, sistema operativo, pacchetti, dipendenze, versioni.
2. Scansione pianificata ed evento: commit, assemblaggio, deposito, finestre di ricambio/settimanale.
3. Triage: deduplicazione, normalizzazione (CVE→Ticket), mupping sul proprietario.
4. Priorità di contesto: CVSS/EPSS + esposizione/dati.
5. Remediazione: patch/aggiornamento della dipendenza/config hardnening/patch virtuale (WAF).
6. Verifica: scansione, test, canarino.
7. Rapporti: metriche di chiusura, età di vulnerabilità, conformità SLO.
8. Lezioni: fix in modelli (base immagine, Helm chart), regole per il futuro.
Integrazione con CI/CD
Nella fase PR: SAST + SCA + segreto-scan; «break build» per P1/P2 o requisito di appro.
Nella fase build: scan immagine, generazione SBOM (CycloneDX/SPDX), firma manufatti (cosign).
Durante la fase deploy, il criterio di tolleranza è il divieto di immagini con vulnerabilità e senza firma/SBOM.
Dopo DAST/IAST vs stage e parzialmente production (profili sicuri).
Esempio: Renovate/Dipendabot (sezione)
json
{
"extends": ["config:recommended"],
"vulnerabilityAlerts": { "enabled": true },
"packageRules": [
{ "matchUpdateTypes": ["minor","patch"], "automerge": true },
{ "matchManagers": ["dockerfile"], "enabled": true }
]
}
Criterio di tolleranza (Kubernets, OPA/Gatekeeper - Semplificato)
rego package policy.vuln
deny[msg] {
input.image.vuln.critical > 0 msg:= sprintf("Image %s has critical vulns", [input.image.name])
}
deny[msg] {
input.image.sbom == false msg:= sprintf("Image %s without SBOM", [input.image.name])
}
Gestione patch (sistema operativo, contenitori, K8s)
ОС (Linux/Windows)
Patch window: finestre regolari + emergenza straordinaria per P1.
Strategia: prima canarino 5-10% nodi, poi onde.
Espansione automatica: Ansibile/WSUS/Intune/SSM; Controllo delle dipendenze e dei rimborsi.
Kernel Live Patching (se possibile) per ridurre al minimo l'inattività.
Servizi di restauro: drain/cordon gestito per K8s nod, graceful shutdown.
Contenitori
Approccio immutabile: non «apt upgrade» nel rantaim; Rielaborare l'immagine con la base aggiornata.
Immagini di base: aggiorna regolarmente le immagini golden (Alpine/Debian/Distroless), fissa le versioni (digest).
Assiemi multistadici - Consente di ridurre al minimo la superficie (elimina build-tools).
Controllo prima del deploy - Blocco di immagini con CVE critici.
Kubernetes/Service Mesh
CVE k8s/etcd/containerd.
Node OS/Container runtime: aggiornamenti pianificati, compatibilità di versione.
Mesh/Ingress: le versioni Invoy/Istio/NGINX sono critiche (spesso CVE nei parser/NTTR3).
Admision Policies: proibizione'latest ', obbligo di firma, limiti di vulnerabilità.
Patch virtuali e misure di compensazione
Quando la patch non può essere rapidamente:- WAF/WAAP è un modello di firma/positivo per un endpoint specifico.
- Ficchflagi, disattivare le funzioni vulnerabili.
- ACL/mTLS/IP allow-list - Limita l'accesso al servizio vulnerabile.
- Config hardnening: disabilitazione, sandbox, read-only FS, disattivazione dei moduli pericolosi.
- Riduzione TTL di token/chiavi, rotazione di segreti.
Gestione esclusioni
L'eccezione viene compilata con ticket con giustificazione, misure di compensazione, SLA di eliminazione, data di revisione.
Nel report, contrassegnare come «accettazione temporanea del rischio» e includere nella panoramica mensile.
Osservabilità e metriche
Tecnica:- Mean Time To Patch (MTTP) по P1/P2/P3.
- Percentuale di risorse coperte da scansione (%).
- L'età delle vulnerabilità scoperte (p50/p90), backlog burn-down.
- Percentuale di immagini con SFOM e firma.
- Esecuzione SLO di chiusura (ad esempio, 95% P1 a 48 ore).
- Impatto sulla farmacia (problemi di patch).
- Ricontrollare gli stessi CVE (qualità del fisso nei modelli).
Playbook (abbreviato)
P1 RCE critico nel servizio pubblico
1. Attiva regola WAF/virt patch.
2. Blocca l'accesso a fonti non autorizzate (se consentito).
3. Incrocio d'emergenza immagine/patch del sistema operativo, canarino delle onde.
4. Ripetizione DAST/Controllo della telemetria, monitoraggio degli errori.
5. Post-incidente: fissa il fisso nell'immagine di base/Helm chart, aggiungi il test a CI.
1. Rotazione immediata dei segreti/chiavi, recensione dei token.
2. Ricerca di tracce d'uso, limitazione degli endpoint.
3. Scansioni di repo/immagine su segreti, implementazione di scanner pre-commit.
Esempi di manufatti
1) Report SQL sulle vulnerabilità a caldo
sql
SELECT service, cve, cvss, epss, exposed, has_exploit, created_at,
PRIORITY(exposed, has_exploit, cvss, epss) AS prio
FROM vuln_findings
WHERE status = 'open' AND (cvss >= 8.0 OR has_exploit = true)
ORDER BY prio DESC, created_at ASC;
2) Politica di adozione (Kyverno, blocco critico delle vulnerabilità)
yaml apiVersion: kyverno.io/v1 kind: ClusterPolicy metadata:
name: block-critical-vulns spec:
validationFailureAction: Enforce rules:
- name: image-must-have-no-critical match: { resources: { kinds: ["Pod"] } }
validate:
message: "Image contains critical vulnerabilities"
pattern:
metadata:
annotations:
vuln.scanner/critical: "0"
3) Generazione SBOM e firma (Makefile porzione)
make sbom:
cyclonedx create --output sbom.json sign:
cosign sign --key cosign.key $(IMAGE_DIGEST)
Particolare per iGaming/Fintech
Zone ad alto rischio: gateway, backofis, antifrode, trattamento PII/PAN - patch priorità P1/P2.
Finestre di servizio: allineamento con tornei/promozioni, cache pre-warm, canarini in regioni a bassa quota.
Regolazione (PCI DSS/GDPR): tempi di risoluzione delle vulnerabilità, prove (screenshot/report), segmentazione della zona CHD, crittografia.
Integrazioni di partnership: richiedere SDK/client versionati, SCA di mandato e HMAC/mTLS web.
Errori tipici
"Scansioniamo tutto, non c'è nessun proprietario e nessun SLO.
Attivo solo su CVSS senza contesto (esposizione, EPSS, dati).
La patch nel RENT del contenitore invece di riassorbire l'immagine.
Assenza di canarie/piani rollback.
Ignora i misconfighi della nuvola/K8s (spesso più critici di CVE).
Nessuna firma SBOM - tracciabilità debole (supply chain).
Road map per l'implementazione
1. Inventario di beni e proprietari; un unico registro dei servizi/immagini.
2. Pile scanner: SCA/SAST/DAST/Container/Cloud + secret-scan; integrazione in CI/CD.
3. Criteri SLO e priorità: CVSS + EPSS + Contesto; modelli di ticket.
4. Admision/Policy-as-Code - Divieto di vulnerabilità critiche, requisito SBOM/firme.
5. Processi di patch: finestre, canarini, ripristini; pilota automatico per versioni minori/patch.
6. Rapporti e metriche: MTTP, copertura, età; una panoramica settimanale del rischio.
7. Esercitazioni regolari: simulazione CVE critica, controllo playbook e rollback.
Totale
La gestione matura delle vulnerabilità è un processo, non una singola «sculacciatura»: rilevamento automatico, priorità contestuale, patch senza interferenze attraverso canarini/rollback, policy-as-code all'ingresso del prato e metriche di esecuzione trasparenti. Fissando le immagini e i modelli di base, si riduce il rischio di ripetizione e si mantiene la superficie di attacco sotto controllo sostenibile.