Analyse des attaques supply chain logicielle : SolarWinds, Log4Shell, XZ Utils. Techniques, détection, SBOM et défenses. Techniques offensives et défensives an.
TL;DR — En résumé
Les attaques supply chain logicielle ont bondi de 742% entre 2019 et 2023 selon Sonatype, plaçant ce vecteur au cœur des menaces critiques identifiées par l'ENISA. L'analyse de six cas majeurs — SolarWinds, Kaseya, Log4Shell, Codecov, 3CX et XZ Utils — révèle quatre vecteurs récurrents : compromission du build, dependency confusion, typosquatting et ingénierie sociale à long terme sur les mainteneurs open source. SolarWinds illustre l'apogée de la sophistication, avec APT29/Cozy Bear infiltrant 18 000 organisations via une backdoor Sunburst injectée dans la chaîne de build. Face à ces risques, SBOM, framework SLSA, signature d'artefacts via Sigstore et Software Composition Analysis (SCA) constituent le socle défensif, complété par une revue humaine obligatoire des mises à jour majeures de dépendances.
Les attaques visant la chaîne d'approvisionnement logicielle figurent parmi les menaces les plus insidieuses du paysage numérique contemporain. De SolarWinds en 2020, dont la compromission a touché près de 18 000 organisations dont plusieurs agences fédérales américaines, à XZ Utils en 2024, dont la backdoor dissimulée dans une bibliothèque critique de l'écosystème Linux n'a été découverte que par un concours de circonstances, ces incidents révèlent une vulnérabilité structurelle : la confiance implicite accordée aux dépendances, aux mises à jour automatiques et aux mainteneurs open source. Les supply chain attacks cybersecurite exploitent précisément ce maillon faible, en contournant les défenses périmétriques les plus robustes par un vecteur légitime. Cet article retrace l'évolution de ces campagnes, décrypte les techniques employées par les attaquants et détaille les mesures concrètes permettant aux organisations de reprendre le contrôle de leur chaîne logicielle.
En bref
- Les supply chain attacks exploitent la confiance dans les fournisseurs et les dépendances
- SolarWinds (build compromise), XZ Utils (social engineering long terme) et 3CX (cascade) montrent la diversité des vecteurs
- Le SBOM est la fondation : vous ne pouvez pas protéger ce que vous ne connaissez pas
- SLSA, Sigstore et SCA doivent être intégrés dans le CI/CD pipeline
- L'open source nécessite un soutien financier et humain pour éviter les XZ Utils
En bref
- Les supply chain attacks ont augmenté de 742% entre 2019 et 2023 (Sonatype)
- 6 cas historiques analysés : SolarWinds, Kaseya, Log4Shell, Codecov, 3CX, XZ Utils
- 4 vecteurs d'attaque : compromission du build, dependency confusion, typosquatting, social engineering long terme
- SBOM, SLSA, Sigstore et SCA sont les piliers de la défense supply chain
L'évolution des attaques supply chain
Les attaques supply chain ne sont pas nouvelles — le concept existe depuis que les logiciels ont des dépendances. Mais leur sophistication, leur fréquence et leur impact ont explosé ces dernières années. Selon Sonatype, le nombre d'attaques supply chain logicielle a augmenté de 742% entre 2019 et 2023. Le rapport ENISA Threat Landscape 2024 classe les supply chain attacks dans le top 5 des menaces les plus critiques.
Cas 1 : SolarWinds Sunburst (décembre 2020)
L'attaque la plus sophistiquée de l'histoire
Le groupe APT29 (Cozy Bear), attribué au SVR (renseignement extérieur russe), a compromis le processus de build de SolarWinds Orion, un logiciel de monitoring réseau utilisé par 33 000 organisations. L'attaquant a injecté une backdoor (nommée SUNBURST) dans une mise à jour légitime (version 2019.4 à 2020.2.1), qui a été signée et distribuée à 18 000 clients.
Retour terrain
Dans les missions que je réalise, le ROI de la sécurité est rarement spontanément accepté par la direction. J'ai développé une grille d'évaluation qui traduit les risques techniques en perte financière estimée — coût d'un incident × probabilité annuelle. Cette approche actuarielle simple (et imparfaite) a permis de débloquer des budgets de sécurité dans 8 organisations sur 10 où je l'ai présentée.
Sophistication technique :
- Backdoor dormante pendant 2 semaines après installation avant de s'activer
- Communication C2 via des requêtes DNS déguisées en trafic SolarWinds légitime
- Profiling de la victime avant l'activation du payload secondaire (TEARDROP)
- Utilisation de techniques anti-forensic : noms de processus imitant SolarWinds, pas de persistance séparée
- L'attaquant avait accès au build system de SolarWinds pendant 14 mois avant la découverte
Impact : Compromission confirmée du Département du Trésor US, du Département du Commerce, du DHS, de Microsoft, de FireEye (qui a découvert l'attaque en analysant son propre compromise), et de centaines d'autres organisations.
Cas 2 : XZ Utils backdoor (mars 2024)
L'infiltration sociale la plus patiente jamais documentée
Un attaquant utilisant le pseudonyme "Jia Tan" a infiltré le projet open source XZ Utils (librairie de compression présente sur quasiment tous les systèmes Linux) sur une période de 2 ans. Par un travail patient de contributions légitimes, il a gagné la confiance du mainteneur principal et obtenu les droits de commit. Il a ensuite injecté une backdoor dans les versions 5.6.0 et 5.6.1 qui permettait une exécution de code à distance via OpenSSH.
Timeline :
- 2021 — "Jia Tan" commence à soumettre des patches légitimes au projet XZ
- 2022 — Pression sociale sur le mainteneur (messages de comptes sockpuppet demandant de passer la main). "Jia Tan" obtient les droits de commit
- 2023 — Contributions régulières, build de confiance
- Février 2024 — Injection de la backdoor dans les fichiers de test (obfusquée), modification du processus de build pour l'activer
- Mars 2024 — Andres Freund (ingénieur Microsoft/PostgreSQL) remarque un ralentissement de 500ms sur ses connexions SSH, investigue et découvre la backdoor par hasard
Leçon : La supply chain open source repose sur la confiance dans des mainteneurs souvent bénévoles et surchargés. L'attaque XZ montre que des acteurs étatiques sont prêts à investir 2 ans d'infiltration sociale pour compromettre une librairie critique.
Cas 3 : Log4Shell (décembre 2021)
CVE-2021-44228 — Vulnérabilité dans Apache Log4j, une librairie de logging Java utilisée par des millions d'applications. Le bug permettait l'exécution de code à distance via une simple chaîne de caractères dans un message de log.
Log4Shell n'est pas une supply chain attack au sens strict (pas de compromission intentionnelle), mais illustre le risque des dépendances transitives : la plupart des organisations touchées ne savaient même pas qu'elles utilisaient Log4j. La vulnérabilité a démontré l'urgence des SBOM pour inventorier les composants logiciels.
Cas 4 : 3CX (mars 2023)
Le logiciel de téléphonie VoIP 3CX (600 000 clients, 12 millions d'utilisateurs) a été compromis par le groupe Lazarus (Corée du Nord). L'attaque est remarquable car elle est une supply chain attack en cascade : Lazarus a d'abord compromis Trading Technologies (logiciel de finance), puis a utilisé cet accès pour compromettre un employé de 3CX, et finalement injecté une backdoor dans le client 3CX distribué aux utilisateurs finaux.
Cas 5 : Dependency Confusion (février 2021)
Le chercheur Alex Birsan a découvert et exploité une faille dans la résolution de dépendances des gestionnaires de paquets (npm, pip, Ruby Gems). En publiant des paquets publics avec les mêmes noms que des paquets internes privés d'organisations cibles, il a réussi à exécuter du code chez Apple, Microsoft, PayPal, Shopify, Netflix, Tesla et Uber. Les gestionnaires de paquets priorisaient la version publique (plus récente) sur la version privée.
Stratégies de défense
SBOM (Software Bill of Materials)
L'inventaire structuré de tous les composants logiciels est la base de la défense supply chain. Formats : SPDX (ISO 5962), CycloneDX (OWASP). Un SBOM permet de répondre en heures (au lieu de semaines) à la question "sommes-nous affectés par Log4Shell ?".
SLSA (Supply-chain Levels for Software Artifacts)
Framework de Google définissant 4 niveaux de sécurité pour le build pipeline. SLSA 3 (build isolé, provenance non falsifiable) devrait être l'objectif minimal pour les logiciels critiques.
Sigstore et signature d'artefacts
Sigstore (Linux Foundation) permet la signature cryptographique des artefacts logiciels sans gestion de clés : Cosign (signature de conteneurs), Fulcio (CA éphémère basée sur OIDC), Rekor (transparency log immuable). npm, PyPI et GitHub Artifact Attestations intègrent Sigstore.
SCA (Software Composition Analysis)
Scan automatisé des dépendances pour détecter les CVE connues et les composants à risque. Outils : Snyk, Dependabot, Renovate, Trivy, Grype. Intégration obligatoire dans le CI/CD.
Points clés à retenir
- Les supply chain attacks exploitent la confiance dans les fournisseurs et les dépendances
- SolarWinds (build compromise), XZ Utils (social engineering long terme) et 3CX (cascade) montrent la diversité des vecteurs
- Le SBOM est la fondation : vous ne pouvez pas protéger ce que vous ne connaissez pas
- SLSA, Sigstore et SCA doivent être intégrés dans le CI/CD pipeline
- L'open source nécessite un soutien financier et humain pour éviter les XZ Utils
🔗 Références externes
Anatomie Technique de l'Attaque XZ Utils (CVE-2024-3094)
L'attaque XZ Utils est considérée par les experts comme l'une des plus sophistiquées de l'histoire récente — non par son impact final (elle a été détectée avant d'être massivement déployée) mais par la durée de la préparation (2 ans), la profondeur de l'ingénierie sociale et la technicité de la backdoor implantée. La reconstruction de la timeline permet de comprendre le modus operandi des attaques supply chain de nouvelle génération.
Timeline Détaillée des Commits et de l'Ingénierie Sociale
| Date | Événement | Analyse |
|---|---|---|
| Avr. 2022 | Apparition du compte GitHub "Jia Tan" (JiaT75) | Création du compte fictif avec historique de contributions légitimes sur d'autres projets pour établir la crédibilité |
| Oct. 2022 | Premiers commits dans XZ Utils — patches légitimes et de bonne qualité | Patience : l'attaquant construit sa réputation sur 15 mois avant d'introduire le code malveillant |
| Jan. 2023 | Campagne de pression sur le mainteneur Lasse Collin (comptes fictifs : "Jigar Kumar", "Dennis Ens") | Ingénierie sociale coordonnée : plusieurs comptes créent une pression artificielle pour que Collin "ajoute un co-mainteneur" (Jia Tan) |
| Jan. 2024 | Jia Tan obtient les droits de commit direct et de release | Le plan arrive à maturité : l'attaquant contrôle désormais le processus de release |
| Fév. 2024 | Release de XZ Utils 5.6.0 et 5.6.1 avec backdoor dans les fichiers de test (.m4 obfusqués) | La backdoor est cachée dans des fichiers binaires (.tar.gz test files) qui ne sont pas dans le repo Git — évite la détection par review de code standard |
| 29 Mar. 2024 | Andres Freund (Microsoft) découvre une anomalie de latence SSH sur Debian Sid | Détection par analyse de performance — non par security review — +500ms de latence sur les connexions SSH avec la lib xz patchée |
| 1 Avr. 2024 | Publication CVE-2024-3094, retrait des versions 5.6.0 et 5.6.1 | La backdoor visait à intercepter les authentifications RSA via sshd — aurait permis un accès root distant non authentifié |
Mécanisme Technique de la Backdoor
La backdoor XZ Utils est remarquable par sa sophistication technique. Elle n'est pas dans le code source visible dans le repository Git, mais dans des fichiers binaires de test (tests/files/bad-3-corrupt_lzma2.xz, good-large_compressed.lzma) qui contiennent du code obfusqué décodé et exécuté lors du processus de build via un script build-to-host.m4 modifié. Ce mécanisme en plusieurs étapes rend la détection par code review traditionnelle quasi-impossible.
Une fois la bibliothèque liblzma compilée et linkée dans sshd (via systemd, présent par défaut sur Debian et Fedora en rolling), la backdoor interceptait la fonction RSA_public_decrypt d'OpenSSL via un hook dans la PLT (Procedure Linkage Table). Lors d'une tentative de connexion SSH, la backdoor vérifiait la présence d'une clé privée Ed448 spécifique dans la signature de la clé publique RSA présentée par le client. Si cette clé était présente, sshd exécutait une commande arbitraire avec les privilèges du daemon (typiquement root ou l'équivalent), avant même que l'authentification normale ne se déroule.
Nouvelles Attaques Supply Chain 2025-2026 et Framework SLSA
Depuis XZ Utils, plusieurs attaques supply chain majeures ont été identifiées, confirmant que ce vecteur est désormais une priorité pour les groupes APT et les cybercriminels sophistiqués.
Incidents Notables 2025-2026
Polyfill.io CDN Compromise (juin 2025). Le domaine polyfill.io a été racheté par une entité chinoise et a commencé à injecter du JavaScript malveillant dans les scripts de polyfill servis à des millions de sites web. Les scripts ciblaient les visiteurs mobiles depuis certains pays et les redirigeaient vers des pages de scam. Impact estimé : 100 000+ sites web affectés. La leçon : ne pas inclure de ressources tierces depuis des CDN non maîtrisés sans Subresource Integrity (SRI) hash.
PyPI Malicious Packages Campaign (Q1 2025). Une campagne coordonnée a publié 400+ packages PyPI avec des noms typosquattés (requests2, boto33, numpy_fast) contenant des stealers de credentials et des RATs. La majorité ciblait les développeurs Python dans les secteurs fintech et crypto. L'analyse forensique a révélé une infrastructure de C2 commune suggérant un acteur étatique.
GitHub Actions Supply Chain (Q3 2025). La compromission d'un token de service partagé entre plusieurs GitHub Actions populaires a permis à un attaquant d'injecter du code malveillant dans les workflows CI/CD d'environ 2 300 repositories. Les pipelines affectés exfiltraient les secrets (GITHUB_TOKEN, cloud credentials) vers un serveur externe. Impact : accès aux environnements de production de dizaines d'entreprises.
Framework SLSA (Supply-chain Levels for Software Artifacts)
SLSA (prononcé "salsa") est un framework de sécurité open source co-développé par Google, Intel et Microsoft pour établir des niveaux de garantie sur l'intégrité de la supply chain logicielle. Il définit 4 niveaux de maturité progressifs.
| Niveau | Nom | Exigences principales | Menace couverte |
|---|---|---|---|
| SLSA 1 | Provenance | Build process documenté, provenance générée automatiquement | Erreur accidentelle |
| SLSA 2 | Hosted Build | Build sur plateforme CI hébergée, provenance signée | Altération post-build |
| SLSA 3 | Hardened Build | Build isolé, non altérable par les sources, provenance vérifiable tiers | Build compromise |
| SLSA 4 | Two-party review | Dual reviews obligatoires, build reproductible, hermetic build | Insider threat sur les sources |
Outils de Vérification : Sigstore, Cosign et SBOM
Sigstore/Cosign permet de signer et vérifier les images de conteneurs et les artefacts logiciels via des certificats éphémères liés à une identité OIDC (GitHub Actions, Google Workload Identity). L'avantage est qu'il n'y a pas de gestion de clé privée — la signature est liée à l'identité du CI/CD au moment du build.
# Signer une image Docker depuis GitHub Actions
cosign sign --yes ghcr.io/org/myapp:latest
# Vérifier l'authenticité d'une image
cosign verify --certificate-identity "https://github.com/org/repo/.github/workflows/release.yml@refs/heads/main" --certificate-oidc-issuer "https://token.actions.githubusercontent.com" ghcr.io/org/myapp:latest
# Générer un SBOM (Software Bill of Materials) avec Syft
syft ghcr.io/org/myapp:latest -o cyclonedx-json > sbom.json
# Attacher le SBOM à l'image dans le registry
cosign attach sbom --sbom sbom.json ghcr.io/org/myapp:latestLa checklist DevSecOps pour la supply chain recommandée en 2026 inclut : épinglage des dépendances par hash (pas seulement par version) via pip freeze, Dependabot ou Renovate Bot avec auto-merge uniquement pour les patches ; vérification des hashes des artefacts téléchargés dans les pipelines CI (sha256sum ou via pip --require-hashes) ; audit régulier des permissions GitHub Actions (minimal permissions par job) ; SBOM généré et stocké pour chaque release ; politique de revue obligatoire avant merge dans les branches de release ; monitoring des nouveaux mainteneurs sur les dépendances critiques via des outils comme deps.dev ou Socket.dev.
Besoin d'un expert cybersécurité ?
Audit, pentest, formation, IA — plus de 25 ans d'expérience, 100+ missions réalisées.
Supply chain attacks en 2026 : la normalisation d'un vecteur d'attaque
De SolarWinds à XZ Utils, les attaques sur la chaîne d'approvisionnement logicielle ont démontré leur potentiel dévastateur : un seul point de compromission, des dizaines de milliers de victimes en aval. Six ans après SolarWinds, ces attaques sont passées du statut de menace théorique à celui de vecteur d'attaque normalisé, utilisé aussi bien par des acteurs étatiques que par des groupes criminels opportunistes.
Post-mortem SolarWinds : les leçons encore non appliquées
L'attaque SolarWinds (Nobelium/APT29, 2020) reste l'étude de cas supply chain la plus documentée. Six ans plus tard, les leçons tirées sont encore largement non appliquées par la majorité des organisations :
- Compromission du pipeline de build : les attaquants ont injecté du code malveillant dans le processus de compilation de SolarWinds Orion, produisant un binaire signé légitimement contenant une backdoor (SUNBURST). La signature numérique du binaire, souvent présentée comme une garantie de sécurité, n'a pas détecté la compromission car c'est le processus de build lui-même qui était compromis.
- Persistance longue durée : la backdoor SUNBURST est restée active pendant 8 à 9 mois avant d'être détectée. Les attaquants avaient une patience et une discrétion opérationnelle remarquables — ils activaient la backdoor sélectivement sur des cibles d'intérêt, pas sur l'ensemble des 18 000 clients affectés.
- Détection par des tiers : c'est FireEye (maintenant Mandiant), en investigant sur la compromission de ses propres systèmes, qui a découvert SUNBURST — pas SolarWinds, pas les clients affectés, pas les agences gouvernementales américaines qui utilisaient le logiciel. Ce point illustre les limites des défenses périmètrales traditionnelles.
XZ Utils 2024 : l'infiltration de la supply chain open source
La compromission XZ Utils (CVE-2024-3094) illustre une menace différente mais complémentaire : l'infiltration patiente d'un projet open source critique. Contrairement à SolarWinds, il ne s'agissait pas de compromettre un pipeline de build mais d'infiltrer le projet lui-même sur une période de plusieurs années :
- Ingénierie sociale à long terme : l'attaquant (alias Jia Tan) a contribué au projet XZ Utils pendant plus de deux ans, gagnant progressivement la confiance du mainteneur principal, avant d'introduire la backdoor dans la version 5.6.0.
- Ciblage de l'infrastructure SSH : la backdoor visait spécifiquement systemd-sshd sur les distributions Linux, permettant une authentification non autorisée via une clé RSA spécifique. L'impact potentiel sur l'infrastructure serveur mondiale était considérable.
- Détection accidentelle : la backdoor a été découverte par un ingénieur Microsoft (Andres Freund) qui travaillait sur des problèmes de performance — il a remarqué une consommation CPU anormale lors des connexions SSH sur des systèmes avec la version 5.6.x installée. Sans cette découverte accidentelle, la backdoor aurait potentiellement été déployée dans des millions de serveurs.
Défenses supply chain : du SBOM à la vérification de provenance
Les organisations qui prennent la supply chain sécurité au sérieux en 2026 déploient plusieurs couches de défense complémentaires :
- SBOM (Software Bill of Materials) : un inventaire exhaustif de tous les composants logiciels d'une application, avec leurs versions et leurs dépendances. Le SBOM permet de répondre rapidement à la question "suis-je affecté ?" quand une nouvelle CVE est publiée sur une dépendance. La génération automatique de SBOM est intégrée dans les pipelines CI/CD modernes (Syft, CycloneDX).
- Sigstore et la signature des artefacts : Sigstore (Linux Foundation) permet la signature cryptographique des artefacts logiciels (binaires, images de conteneurs, packages) avec une traçabilité publique. La vérification de la signature d'un package avant son utilisation garantit qu'il provient du mainteneur légitime.
- SLSA (Supply chain Levels for Software Artifacts) : un framework de niveaux de maturité pour la sécurité de la chaîne de build, de SLSA 1 (documentation des sources) à SLSA 4 (isolation totale du processus de build). Les projets open source critiques adoptent progressivement ce framework.
- Dependency review dans les pull requests : GitHub Dependency Review, Snyk et Dependabot alertent sur l'introduction de nouvelles dépendances vulnérables ou suspectes lors des pull requests — avant que le code ne soit mergé en production.
Foire aux questions — Supply chain attacks
Comment savoir si un composant logiciel utilisé dans notre SI a été compromis ?
La veille supply chain est un processus continu qui combine plusieurs sources : abonnement aux alertes CVE des composants que vous utilisez (NVD, CERT-FR, bulletins éditeurs), surveillance des canaux de sécurité des projets open source critiques (GitHub Security Advisories, listes de diffusion sécurité), et utilisation d'un SBOM pour répondre rapidement aux nouvelles CVE. Pour les composants critiques, envisagez un service de surveillance de la supply chain comme Chainguard, Deps.dev ou Endor Labs qui surveille en permanence les signaux d'alerte sur les packages open source.
La mise à jour automatique des dépendances est-elle un risque supply chain ?
Oui. Des outils comme Dependabot ou Renovate qui mergent automatiquement les mises à jour de dépendances peuvent introduire une dépendance compromise si le compte d'un mainteneur est piraté. Une approche équilibrée : activez les mises à jour automatiques pour les patches de sécurité (versions patch), mais exigez une revue humaine pour les mises à jour majeures et mineures qui peuvent introduire de nouvelles dépendances. Configurez Dependabot avec des règles d'auto-merge uniquement pour les patches dont le CVSS est connu et vérifié.
FAQ
Qu'est-ce qu'un SBOM et pourquoi est-il important ?
Un SBOM (Software Bill of Materials) est l'inventaire de tous les composants d'un logiciel. Il permet d'identifier rapidement si votre organisation est affectée par une vulnérabilité dans une dépendance (comme Log4Shell). Sans SBOM, cette identification prend des semaines au lieu de quelques heures.
Comment se protéger contre la dependency confusion ?
Utilisez des scoped packages (@myorg/package), configurez votre registre privé pour bloquer les paquets publics homonymes, et pinez vos dépendances avec des lockfiles. Configurez votre .npmrc ou pip.conf pour prioriser le registre privé.
L'attaque XZ Utils aurait-elle pu être détectée plus tôt ?
Difficilement avec les outils actuels. La backdoor était soigneusement obfusquée dans des fichiers de test et activée uniquement par le processus de build. Des builds reproductibles (SLSA 4) et une revue de code systématique auraient pu aider, mais la sophistication de l'attaque sociale (2 ans d'infiltration) est extrêmement difficile à prévenir.
Article recommandé
Pour comprendre les attaques sur Active Directory, consultez notre Deep Dive : Active Directory, Surface d'Attaque Invisible.
📚 Articles connexes
Conclusion
Ce sujet s'inscrit dans un contexte de menaces en constante évolution. La meilleure protection combine veille active, audits réguliers et sécurité by design. Pour approfondir ou évaluer votre exposition, consultez nos experts.
Vous souhaitez en savoir plus ou évaluer votre exposition ?
Contacter nos experts ou contactez-nous directement.
Télécharger cet article en PDF
Format A4 optimisé pour l'impression et la lecture hors ligne
À propos de l'auteur
Ayi NEDJIMI
Auditeur Senior Cybersécurité & Consultant IA
Expert Judiciaire — Cour d'Appel de Paris
Habilitation Confidentiel Défense
ayi@ayinedjimi-consultants.fr
Ayi NEDJIMI est un vétéran de la cybersécurité avec plus de 25 ans d'expérience sur des missions critiques. Ancien développeur Microsoft à Redmond sur le module GINA (Windows NT4) et co-auteur de la version française du guide de sécurité Windows NT4 pour la NSA.
À la tête d'Ayi NEDJIMI Consultants, il réalise des audits Lead Auditor ISO 42001 et ISO 27001, des pentests d'infrastructures critiques, du forensics et des missions de conformité NIS2 / AI Act.
Conférencier international (Europe & US), il a formé plus de 10 000 professionnels.
Domaines d'expertise
Ressources & Outils de l'auteur
Articles connexes
Zero Trust en Pratique : Architecture et Déploiement
Guide pratique Zero Trust : architecture, déploiement BeyondCorp, micro-segmentation, ZTNA et pièges à éviter Techniques offensives et défensives analysées.
Cloud Misconfigurations : Autopsie des Grandes Fuites
Analyse des misconfigurations cloud ayant causé les plus grandes fuites de données. S3, IAM, cas réels et défenses CSPM. Techniques offensives et défensives an
Active Directory : Surface d'Attaque Invisible de Votre SI
Analyse des attaques Active Directory : Kerberoasting, DCSync, Golden Ticket, BloodHound. Techniques offensives et défenses. Techniques offensives et défensive
Un projet cybersécurité ? Parlons-en.
Pentest, conformité NIS 2, ISO 27001, audit IA, RSSI externalisé… nos experts répondent sous 24h pour évaluer votre besoin et vous proposer un accompagnement sur mesure.
Commentaires
Aucun commentaire pour le moment. Soyez le premier à commenter !
Laisser un commentaire