Live-Webinar auf EnglischWebinar mit Jason Lee, Mi., 14. Okt.Your newest insider is an AI agent.Jason LeeFormer CISO, Zoom & SplunkAnmelden

Jedes Image, beim Push geprüft.

Jedes Image beim Push gescannt, zuerst die CVEs, die ein Angreifer erreichen kann.

Cloud testenDemo buchen
checkout-apiContainer-SicherheitDemo-Projekt
  • HochCVE-2023-5363 in openssl 3.1.3-r0api-server:v2.4.1

    Im Basis-Image, erreicht vom TLS-Listener in prod-eu.

    FROM node:18-alpine3.18FROM node:18.19.1-alpine3.19

    Fix bereitBasis auf node:18.19.1-alpine3.19 angehoben, Image als v2.4.2 neu gebaut, 0 erreichbare CVE.

Jede Schicht gelesen, das Erreichbare zuerst.

  • OS-Pakete

    • alpine 3.18
    • openssl 3.1.3-r0

  • Malware, Secrets, Fehlkonfigurationen

    • /app/.env
    • USER root

  • Erreichbare CVEs zuerst

    • CVE-2023-5363
    • api-server:v2.4.1 :443

  • Aktuelle Basis-Images

    • node:18-alpine3.18
    • node:18.19.1-alpine3.19

Die CVE, die zählt, vor allen anderen.

Jede CVE im Image

  • Alarm: CVE-2023-5363 in openssl 3.1.3-r0
  • Alarm: Nur-Windows-CVE in einem Linux-Image

Was ein Angreifer erreichen kann

  • Hoch: CVE-2023-5363 in openssl 3.1.3-r0api-server:v2.4.1
  • Mittel: Zwei CVEs des Basis-Images, zu einer gebündeltbilling-worker:3.2.0
  • Verworfen: Nur-Windows-CVE in einem Linux-Imageapi-server:v2.4.1

Registry verbinden, der Rest läuft automatisch.

Images werden in unseren Pods geladen und gescannt, bei jedem Push und nach Zeitplan, nie in Ihrer CI.

  1. Ihre RegistryDocker Hub, ECR, ACR, GCR, GHCR, Quay, Harbor, JFrog oder Scaleway.Gepusht
  2. Unsere PodsLaden das Image, nie Ihre CI.Geladen
  3. Die SchichtenOS-Pakete und App-Abhängigkeiten, gelesen.Gefunden
  4. Der FixEin Update des Basis-Images, als Pull Request.Fix bereit

Beginnen Sie mit einem Repository.

Verbinden Sie GitHub, GitLab, Bitbucket oder Azure DevOps, wählen Sie ein Repository, und der erste Scan startet.

Cloud testenDemo buchen

Im Detail

Jede Schicht des Images, gelesen.
Alles, was er prüft

Container-Scanning ohne Alert-Flut.

  • Einmal pullen, überall scannen

    Jedes Image in jeder verbundenen Registry wird von unseren Pods gezogen und gescannt, bei jedem Push und nach Zeitplan.

  • KI-Triage ab Werk

    Cybe Analysis steht zwischen dem rohen CVE-Feed und Ihrem Dashboard.

  • Findings dort, wo Sie arbeiten

    Weitergeleitet an Jira, GitHub Issues, GitLab Issues und Slack. Das zentrale Dashboard bleibt die maßgebliche Quelle für SAST, SCA, Secrets, IaC, CI/CD und Container.

Fünf Prüfungen für jedes Image, das Sie ausliefern.

OS-Pakete und App-Abhängigkeiten aus allen großen Registries, mit KI-Triage.

  • Jede große Registry

    Verbinden Sie Docker Hub, Amazon ECR, Azure ACR, Google GCR, GitHub GHCR, Red Hat Quay, Harbor, JFrog Artifactory oder Scaleway Registry.

  • OS-Pakete und App-Abhängigkeiten

    Pakete auf OS-Ebene (Alpine, Debian, Ubuntu, RHEL/UBI) und Abhängigkeiten der Anwendung (npm, PyPI, Maven, Go-Module, Cargo, NuGet, Composer), alles im selben Scan.

  • KI-Triage für jede CVE

    Cybe Analysis bewertet rohe CVE-Treffer neu, filtert offensichtliches Rauschen heraus, gruppiert wiederkehrende Muster nach Basis-Image und ordnet sie nach Erreichbarkeit von außen ein.

  • Autofix für Basis-Images

    Beseitigt ein Upgrade des Basis-Images eine ganze Klasse von CVEs, öffnet Cybe AutoFix einen PR für das Dockerfile mit dem neuen gepinnten Digest und einem Hinweis zu Regressionen.

  • Kontinuierliche Compliance

    CIS-Benchmarks für Docker und Kubernetes integriert.

Vom Layer zur Korrektur

  • Ein Layer, eine CVE.

    Markiert im Layer, der sie eingeschleppt hat.

  • Beurteilt zur Laufzeit.

    In Prod aufgerufen und exponiert, also zuerst.

  • Sauber neu gebaut.

    Basis aktualisiert, Image neu gebaut, Gate grün.

Registries, aus denen CybeDefend Ihre Images zieht

Wir ziehen Images aus Docker Hub, ECR, ACR, GCR, GHCR, Quay, Harbor, JFrog und Scaleway. Scans bei jedem Push und geplante Durchläufe laufen in unseren Pods, nie in Ihrer CI. Die Findings landen im zentralen Dashboard, in Ihrem Jira und in Ihrem Slack.

  • Registries

    Docker Hub, Amazon ECR, Azure ACR, Google GCR, GitHub GHCR, Red Hat Quay, Harbor, JFrog Artifactory, Scaleway und jede OCI-Registry.

  • Zugangsdaten

    Pro Projekt begrenzt und im Ruhezustand verschlüsselt. Die Pulls bleiben in unseren Pods.

  • Wohin die Findings gehen

    Das Dashboard, Jira, GitHub Issues, GitLab Issues und Slack.

Häufige Fragen zu CybeDefend Container.

Welche Registries unterstützt CybeDefend?
Docker Hub, Amazon ECR, Azure ACR, Google GCR, GitHub GHCR, Red Hat Quay, Harbor, JFrog Artifactory und Scaleway Registry. Selbst gehostete Registries, die der OCI Distribution Specification folgen, binden Sie über denselben Connector an.
Wie wird ein Scan ausgelöst?
Sobald eine Registry verbunden ist, lösen Push-Events einen Scan in unseren Pods aus. Geplante Durchläufe ziehen jedes Image in einstellbaren Abständen neu, sodass neu veröffentlichte CVEs automatisch mit Ihrem Inventar abgeglichen werden. Einen Scan können Sie auch jederzeit manuell aus dem Dashboard oder der CLI starten.
Wie sieht der Autofix aus?
Beseitigt das Anheben des Basis-Images eine ganze Klasse von CVEs, öffnet Cybe AutoFix einen PR für das Dockerfile mit dem neuen gepinnten Digest und einer kurzen Begründung. Wie jede andere Änderung in Ihrem Repo lässt sich der PR prüfen und mergen und muss die CI-Prüfungen bestehen.
Wie geht CybeDefend mit Zugangsdaten um?
Zugangsdaten für Registries gelten jeweils nur für ein Projekt, werden verschlüsselt gespeichert und über denselben Secret-Store rotiert, den Sie ohnehin nutzen. Die Images werden in unseren Pods gezogen, nie auf einem Runner, den Sie sonst selbst härten müssten. So verlassen Registry-Secrets die Plattform nie.