Webinar en anglaisWebinar avec Jason Lee, mer. 14 oct.Your newest insider is an AI agent.Jason LeeFormer CISO, Zoom & SplunkS'inscrire

Chaque image, scannée au push.

Chaque image analysée au push, les CVE qu'un attaquant peut atteindre d'abord.

Essayer le cloudRéserver une démo
checkout-apiSécurité des conteneursProjet de démonstration
  • ÉlevéeCVE-2023-5363 dans openssl 3.1.3-r0api-server:v2.4.1

    Dans l'image de base, atteinte par le listener TLS de prod-eu.

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

    Correctif prêtImage de base passée en node:18.19.1-alpine3.19, image reconstruite en v2.4.2, 0 CVE atteignable.

Chaque couche lue, l'atteignable d'abord.

  • Les paquets système

    • alpine 3.18
    • openssl 3.1.3-r0

  • Malwares, secrets, erreurs de configuration

    • /app/.env
    • USER root

  • D'abord les CVE atteignables

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

  • Des images de base à jour

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

La CVE qui compte, avant les autres.

Toutes les CVE de l'image

  • Alerte: CVE-2023-5363 dans openssl 3.1.3-r0
  • Alerte: CVE propre à Windows sur une image Linux

Ce qu'un attaquant peut atteindre

  • Élevée: CVE-2023-5363 dans openssl 3.1.3-r0api-server:v2.4.1
  • Moyenne: Deux CVE de l'image de base, regroupées en unebilling-worker:3.2.0
  • Écartée: CVE propre à Windows sur une image Linuxapi-server:v2.4.1

Connectez un registry, le reste est automatique.

Les images sont récupérées et scannées dans nos pods, au push et selon un planning, jamais dans votre CI.

  1. Votre registryDocker Hub, ECR, ACR, GCR, GHCR, Quay, Harbor, JFrog ou Scaleway.Poussée
  2. Nos podsRécupèrent l'image, jamais votre CI.Récupérée
  3. Les couchesPaquets système et dépendances applicatives, lus.Détectée
  4. Le correctifUne montée de l'image de base, en pull request.Correctif prêt

Commencez par un dépôt.

Connectez GitHub, GitLab, Bitbucket ou Azure DevOps, choisissez un dépôt, et le premier scan démarre.

Essayer le cloudRéserver une démo

En détail

Chaque couche de l'image, lue.
Tout ce qu'il vérifie

Le scan de conteneurs, sans la pile d'alertes.

  • Récupérée une fois, scannée partout

    Chaque image de chaque registry connecté est récupérée et scannée par nos pods, à chaque push et selon une planification.

  • Triage IA prêt à l'emploi

    Cybe Analysis se place entre le flux CVE brut et votre dashboard.

  • Les alertes, là où vous travaillez

    Envoyées vers Jira, GitHub Issues, GitLab Issues et Slack. Le dashboard unifié reste la source de vérité pour le SAST, le SCA, les secrets, l'IaC, la CI/CD et les conteneurs.

Cinq contrôles sur chaque image que vous livrez.

Paquets OS et dépendances applicatives, sur tous les grands registries, avec triage IA.

  • Tous les grands registries

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

  • Paquets OS et dépendances applicatives

    Paquets système (Alpine, Debian, Ubuntu, RHEL/UBI) et dépendances applicatives (npm, PyPI, Maven, Go modules, Cargo, NuGet, Composer), dans le même scan.

  • Triage IA sur chaque CVE

    Cybe Analysis réévalue les correspondances CVE brutes, écarte le bruit évident, regroupe les motifs récurrents par image de base et tient compte de l'exposition.

  • Autofix par montée de l'image de base

    Quand la mise à jour de l'image de base élimine toute une classe de CVE, Cybe AutoFix ouvre une PR sur le Dockerfile avec le nouveau digest épinglé et une note de régression.

  • Conformité continue

    Les CIS Benchmarks Docker et Kubernetes, intégrés.

De la couche au correctif

  • Une couche, une CVE.

    Signalée sur la couche qui l'a introduite.

  • Jugée à l'exécution.

    Appelée et exposée en prod : elle passe en premier.

  • Reconstruite saine.

    Base mise à jour, image reconstruite, contrôle au vert.

Les registries d'où CybeDefend récupère vos images

Nous récupérons les images depuis Docker Hub, ECR, ACR, GCR, GHCR, Quay, Harbor, JFrog et Scaleway. Les déclenchements au push et les passages planifiés tournent dans nos pods, jamais dans votre CI. Les alertes arrivent dans le dashboard unifié, dans votre Jira et dans votre Slack.

  • Registries

    Docker Hub, Amazon ECR, Azure ACR, Google GCR, GitHub GHCR, Red Hat Quay, Harbor, JFrog Artifactory, Scaleway et tout registry OCI.

  • Identifiants

    Cloisonnés par projet et chiffrés au repos. Les images restent dans nos pods.

  • Où vont les alertes

    Le dashboard, Jira, GitHub Issues, GitLab Issues et Slack.

Questions fréquentes sur CybeDefend Container.

Quels registries pouvez-vous connecter ?
Docker Hub, Amazon ECR, Azure ACR, Google GCR, GitHub GHCR, Red Hat Quay, Harbor, JFrog Artifactory et Scaleway Registry. Les registries auto-hébergés compatibles avec la spécification OCI Distribution sont accessibles via le même connecteur.
Comment un scan est-il déclenché ?
Une fois le registry connecté, chaque événement de push déclenche un scan dans nos pods. Des passages planifiés récupèrent de nouveau chaque image à la fréquence de votre choix, pour qu'une CVE nouvellement publiée soit automatiquement confrontée à votre inventaire. Vous pouvez aussi lancer un scan à la demande depuis le dashboard ou la CLI.
À quoi ressemble l'autofix ?
Quand la montée de version de l'image de base élimine une classe de CVE, Cybe AutoFix ouvre une PR sur le Dockerfile avec le nouveau digest épinglé et une courte justification. La PR se relit, se fusionne et passe par votre CI comme tout autre changement de votre dépôt.
Comment les identifiants sont-ils gérés ?
Les identifiants du registry sont cloisonnés par projet, chiffrés au repos et renouvelés via le coffre à secrets que vous utilisez déjà. Les images sont récupérées dans nos pods, jamais sur un runner qu'il vous faudrait durcir : les secrets du registry ne quittent jamais la plateforme.