Schwachstellenscans und Patches

Kurze Zusammenfassung

Das Schwachstellenmanagement ist ein kontinuierlicher Zyklus: Erkennung → Risikobewertung → Beseitigung (Patch/Migration/Config) → Überprüfung → Berichterstattung. Scantechnologien (SCA/SAST/DAST/IAST/Cloud/Container) liefern Signale, und der Kontext (Belichtung, Privilegien, Daten, EPSS, Exploits) bestimmt die Priorität. Ziel ist es, das reale Risiko ohne Ausfallzeiten durch Automatisierung, kanarische Layouts und klare SLOs zu reduzieren.

Scan-Taxonomie

SCA (Software Composition Analysis): Analyse von Abhängigkeiten/Lizenzen; CVE-Erkennung in Bibliotheken, SBOM.
SAST: Statische Analyse des eigenen Codes vor der Montage.
DAST: dynamische „Black Box“ gegen den laufenden Dienst.
IAST: Sensoren innerhalb der Anwendung (während Tests) - weniger FP, tieferer Kontext.
Container/OS Scan: Images (Basisbild, Pakete), Hosts (Kernel/Pakete/Configs), CIS-Benchmarks.
Cloud/Infra (CSPM/KSPM): Cloud-Miskonfigs/K8s (IAM, Netzwerke, Verschlüsselung, öffentliche Bakette).
Secrets Scan: Schlüssel/Token-Leaks in Repositories und Images.
Binary/Artifact Scan: Überprüfung der gesammelten Artefakte (Signaturen, Schwachstellen).

Risikomodell und Priorisierung

Bewertung = CVSS v3. x (Basis) × EPSS (Verwertungswahrscheinlichkeit) × Kontext (Belichtung, Daten, Privilegien, Ausgleichsmaßnahmen).

• Belichtung im Internet/innen, Vorhandensein von WAF/mTLS/Isolation.
• Daten: PII/Finanzen/Geheimnisse.
• Prozess-/Knotenprivilegien, laterales Bewegungspotential.
• Vorhandensein eines öffentlichen Exploits/Massenangriffs, Compliance-Anforderungen.

Beispiel für einen CVSS-Vektor: 'CVSS: 3. 1/AV: N/AC: L/PR: N/UI: N/S: U/C: H/I: H/A: H '→ kritisiert; wenn die Dienstleistung öffentlich und ohne Ausgleichsmaßnahmen erbracht wird - P1.

• P1 (kritisch, ausgenutzt): fix ≤ 48 Stunden
• P2 (hoch): Fix ≤ 7 Tage.
• P3 (Durchschnitt): Fix ≤ 30 Tage.
• P4 (niedrig/inform.) : geplant/per Backlog.

Lebenszyklus des Schwachstellenmanagements

1. Bestandsaufnahme von Assets: Services, Images, Cluster, Betriebssysteme, Pakete, Abhängigkeiten, Versionen.
2. Scannen nach Zeitplan und nach Ereignis: Commits, Assemblies, Deploys, tägliche/wöchentliche Fenster.
3. Triage: Deduplizierung, Normalisierung (CVE→Ticket), Mapping pro Besitzer.
4. Priorisierung nach Kontext: CVSS/EPSS + Belichtung/Daten.
5. Remediation: Patch/Abhängigkeitsupdate/Config-Hardning/Virtueller Patch (WAF).
6. Verifizierung: Re-Scan, Tests, Kanarienvogel.
7. Berichterstattung: Abschlussmetriken, Alter der Schwachstellen, SLO-Konformität.
8. Lektionen: Fix in Vorlagen (Basisbild, Helmchart), Politik für die Zukunft.

Integration in CI/CD

In der PR-Phase: SAST + SCA + Secret-Scan; „break build“ durch P1/P2 oder appruv Anforderung.
In der Build-Phase: Scan des Images, SBOM-Generierung (CycloneDX/SPDX), Signatur der Artefakte (Cosign).
In der deploy-Phase: Zulassungspolitik (Admission) - Bilder mit 'critical/high' Schwachstellen und ohne Signatur/SBOM verbieten.
Postdeploy: DAST/IAST gegen Staging und teilweise Produktion (sichere Profile).

Beispiel: Renovate/Dependabot (Fragment)

json
{
"extends": ["config:recommended"],
"vulnerabilityAlerts": { "enabled": true },
"packageRules": [
{ "matchUpdateTypes": ["minor","patch"], "automerge": true },
{ "matchManagers": ["dockerfile"], "enabled": true }
]
}

Zulassungspolitik (Kubernetes, OPA/Gatekeeper - vereinfacht)

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])
}

Patch-Management (OS, Container, K8s)

ОС (Linux/Windows)

Patch-Fenster: regelmäßige Fenster + Notfall außergewöhnlich für P1.
Strategie: zuerst der Kanarienvogel 5-10% der Knoten, dann die Wellen.
Automatische Auflösung: Ansible/WSUS/Intune/SSM; Abhängigkeitsprüfung und Rollbacks.
Kernel Live Patching (wo möglich), um Ausfallzeiten zu minimieren.
Neustart-Dienste: gesteuert drain/cordon für K8s Knoten, graceful shutdown.

Container

Immutable-Ansatz: nicht „apt upgrade“ in rantayme; Erstellen Sie das Bild mit der aktualisierten Basis neu.
Basis-Images: golden images (Alpine/Debian/Distroless) regelmäßig aktualisieren, Versionen fixieren (digest).
Mehrstufige Baugruppen: Oberfläche minimieren (Build-Tools entfernen).
Check vor Deploy: Bildblock mit kritischen CVEs.

Kubernetes/Service Mesh

Control Plane: zeitnahe Minor Releases, Schließung von CVE k8s/etcd/containerd.
Node OS/Container-Laufzeit: geplante Updates, Versionskompatibilität.
Mesh/Ingress: Versionen von Envoy/Istio/NGINX - kritisch (oft CVE in Parsern/NTTR3).
Admission Policies: ban': latest', Signaturanforderung, Grenzen für Schwachstellen.

Virtuelle Patches und Kompensationsmaßnahmen

• WAF/WAAP: Signatur/positives Modell für einen bestimmten Endpunkt.
• Fichflaghi: Deaktivieren Sie die anfällige Funktionalität.
• Netzwerk ACL/mTLS/IP allow-list: Beschränken Sie den Zugriff auf einen anfälligen Dienst.
• Config-Hardning: Downgrading, Sandbox, Read-Only FS, Abschalten gefährlicher Module.
• Reduzierung der TTL-Token/Schlüssel, Rotation der Geheimnisse.

Verwaltung von Ausnahmen (Risikoakzeptanz)

Der Ausschluss erfolgt durch ein Ticket mit: Begründung, Ausgleichsmaßnahmen, SLA zur Beseitigung, Revisionsdatum.
In der Berichterstattung als „vorübergehende Risikoübernahme“ kennzeichnen und in die monatliche Übersicht aufnehmen.

Beobachtbarkeit und Metriken

• Mean Time To Patch (MTTP) по P1/P2/P3.
• Anteil der durch Scans abgedeckten Vermögenswerte (%).
• Alter der offenen Schwachstellen (p50/p90), backlog burn-down.
• Prozentsatz der Bilder mit SBOM und Signatur.

• Durchführung von SLO nach Schließzeiten (z. B. ≥ 95% P1 ≤ 48 Stunden).
• Auswirkungen auf das Aptime (Anzahl der Patchvorfälle).
• Wiederholte Identifizierung der gleichen CVEs (Fixqualität in Vorlagen).

Playbooks (abgekürzt)

P1: Kritische RCE im öffentlichen Dienst

1. WAF-Regel/Wirth-Patch aktivieren.
2. Blockieren Sie den Zugriff auf nicht autorisierte Quellen (falls zulässig).
3. Dringende Reassemblierung/OS-Patch, Kanarienvogel → Wellen.
4. Wiederholte DAST/Telemetrieprüfung, Fehlerüberwachung.
5. Post-Incident: Fix im Basis-Image/Helm-Chart verankern, Test zum CI hinzufügen.

1. Sofortige Rotation von Geheimnissen/Schlüsseln, Widerruf von Token.

2. Suche nach Gebrauchsspuren, Begrenzung der Endpunkte.

3. Scans von Repos/Bildern auf Geheimnisse, Implementierung eines Pre-Commit-Scanners.

Beispiele für Artefakte

1) SQL-Bericht zu „heißen“ Schwachstellen

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) Admission-Richtlinie (Kyverno, Block der kritischen Schwachstellen)

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) SBOM-Generierung und Signatur (Makefile Fragment)

make sbom:
cyclonedx create --output sbom.json sign:
cosign sign --key cosign.key $(IMAGE_DIGEST)

Spezifität für iGaming/Fintech

Hochrisikobereiche: Zahlungs-Gateways, Auszahlungs-Backoffice, Betrugsbekämpfung, PII/PAN-Verarbeitung - Patches haben Priorität P1/P2.
Wartungsfenster: Abstimmung mit Turnieren/Aktionen, Pre-Warm-Caches, Kanarienvögeln in niedrig belasteten Regionen.
Regulatory (PCI DSS/GDPR): Zeitrahmen für die Beseitigung von Schwachstellen, Beweise (Screenshots/Berichte), Segmentierung der CHD-Zone, Verschlüsselung.
Affiliate-Integrationen: Erfordern Sie versionierte SDKs/Clients, Mandate-SCA und HMAC/mTLS auf Webhooks.

Typische Fehler

„Alles scannen - nichts reparieren“: keine Besitzer und SLOs.
Fokus nur auf CVSS ohne Kontext (Belichtung, EPSS, Daten).
Ein Patch im Container-Rantayme, anstatt das Image neu zusammenzustellen.
Keine Kanarienvögel/Rollback-Pläne.
Ignorieren Sie die Misconphigs der Cloud/K8s (oft kritischer als CVE).
Keine SBOM/Unterschrift - schwache Rückverfolgbarkeit (Supply Chain).

Roadmap für die Umsetzung

1. Bestandsaufnahme von Vermögenswerten und Eigentümern; einheitliches Register der Dienste/Bilder.
2. Scanner-Stack: SCA/SAST/DAST/Container/Cloud + secret-scan; Integration in CI/CD.
3. SLO und Priorisierungsrichtlinien: CVSS + EPSS + Kontext; Ticket-Vorlagen.
4. Admission/Policy-as-Code: Verbot kritischer Schwachstellen, Anforderung von SBOM/Signaturen.
5. Patch-Prozesse: Fenster, Kanarienvögel, Rollbacks; Autopiloten für Moll/Patch-Versionen.
6. Berichterstattung und Metriken: MTTP, Abdeckung, Alter; wöchentlicher Risikoüberblick.
7. Regelmäßige Übungen: Simulation eines kritischen CVE, Überprüfung von Playbooks und Rollback.

Ergebnis

Ein ausgereiftes Schwachstellenmanagement ist ein Prozess und keine einmalige „Säuberung“: automatische Erkennung, kontextbezogene Priorisierung, störungsfreie Patches über Kanarienvögel/Rollback, Policy-as-Code am Eingang zum Prod und transparente Ausführungsmetriken. Durch die Verankerung von Fixierungen in Grundbildern und Mustern reduzieren Sie das Wiederholungsrisiko und halten die Angriffsfläche nachhaltig unter Kontrolle.