Produit
Tout ce dont vous avez besoin pour sécuriser le code, le nuage et le temps d'exécution, dans un système central
Code
Dépendances
Prévenir les risques liés aux logiciels libres (SCA)
Secrets
Attraper les secrets dévoilés
SAST
Sécuriser le code tel qu'il est écrit
Images des conteneurs
Sécuriser facilement les images
Logiciels malveillants
Prévenir les attaques de la chaîne d'approvisionnement
L'infrastructure en tant que code
Recherche de mauvaises configurations dans l'IaC
Risque de licence et SBOM
Éviter les risques, respecter les règles
Logiciels obsolètes
Connaître les durées d'exécution de la fin de vie
Cloud
Cloud / CSPM
Configurations erronées de l'informatique en nuage
DAST
Tests de sécurité en boîte noire
Analyse de l'API
Testez vos API pour détecter les vulnérabilités
Machines virtuelles
Pas d'agents, pas de frais généraux
Défendre
Protection Runtime
Pare-feu intégré / WAF
Caractéristiques
AI AutoFix
Corrections en 1 clic avec Aikido AI
Sécurité CI/CD
Analyse avant fusion et déploiement
Intégrations IDE
Obtenir un retour d'information instantané pendant le codage
Scanner sur site
L'analyse locale axée sur la conformité
Solutions
Cas d'utilisation
Conformité
Automatiser SOC 2, ISO et plus encore
Gestion de la vulnérabilité
Gestion des vulnérabilités tout-en-un
Sécurisez votre code
Sécurité avancée du code
Générer des SBOM
1 clic sur les rapports du SCA
SGAA
AppSec de bout en bout
GPSC
Sécurité de bout en bout dans le nuage
L'IA à l'Aïkido
Laissez l'Aikido AI faire le travail
Bloc 0-Jours
Bloquer les menaces avant qu'elles n'aient un impact
Industries
FinTech
Technologies de la santé
HRTech
Technologie juridique
Sociétés du groupe
Agences
Startups
Entreprise
Applications mobiles
Fabrication
Tarifs
Ressources
Développeur
Docs
Comment utiliser l'Aïkido
Documentation sur l'API publique
Centre de développement de l'aïkido
Changelog
Voir ce qui a été expédié
Sécurité
Recherche interne
Renseignements sur les logiciels malveillants et les CVE
Apprendre
Académie de la sécurité des logiciels
Trust Center
Sûr, privé, conforme
Blog
Les derniers messages
Source ouverte
Aikido Intel
Fil d'information sur les logiciels malveillants et les menaces OSS
Zen
Protection par pare-feu intégrée à l'application
OpenGrep
Moteur d'analyse de code
Intégrations
IDE
Systèmes CI/CD
Nuages
Systèmes Git
Conformité
Messagers
Gestionnaires de tâches
Plus d'intégrations
A propos
A propos
A propos
Rencontrer l'équipe
Carrières
Nous recrutons
Dossier de presse
Télécharger les actifs de la marque
Calendrier
A bientôt ?
Source ouverte
Nos projets OSS
Témoignages de clients
La confiance des meilleures équipes
Programme de partenariat
Partenariat avec nous
Contact
Connexion
Essai gratuit
Sans CB
Aikido
Menu
Aikido
EN
EN
FR
JP
DE
PT
Connexion
Essai gratuit
Sans CB
Apprendre
/
Hub des cadres de conformité
/
Chapitre 1Chapitre 2Chapitre 3

CMMC

4minutes de lecture140

Chapitre suivant
Chapitre précédent
Chapitre suivant
Chapitre précédent
Chapitre suivant
Chapitre précédent
Chapitre suivant
Chapitre précédent
Chapitre suivant
Chapitre précédent
Chapitre suivant
Chapitre précédent
Chapitre suivant
Chapitre précédent
Chapitre suivant
Chapitre précédent
Chapitre suivant
Chapitre précédent
Chapitre suivant
Chapitre précédent
Chapitre suivant
Chapitre précédent
Chapitre suivant
Chapitre précédent
Chapitre suivant
Chapitre précédent
Chapitre suivant
Chapitre précédent
Chapitre suivant
Chapitre précédent
Chapitre suivant
Chapitre précédent
Chapitre suivant
Chapitre précédent
Chapitre suivant
Chapitre précédent
Chapitre suivant
Chapitre précédent
Chapitre suivant
Chapitre précédent
Chapitre suivant
Chapitre précédent
Chapitre suivant
Chapitre précédent
Chapitre suivant
Chapitre précédent
Chapitre suivant
Chapitre précédent
Chapitre suivant
Chapitre précédent
Chapitre suivant
Chapitre précédent

TL;DR

Si vous traitez des contrats du DoD et touchez des informations fédérales (FCI ou CUI), la certification CMMC (Cybersecurity Maturity Model Certification) est obligatoire.

Trois niveaux :

  • Niveau 1 : Hygiène cybernétique de base (auto-évaluation).
  • Niveau 2 : NIST 800-171 (évaluation par un tiers).
  • Niveau 3 : sécurité avancée (audits menés par le gouvernement).

Pas de CMMC = pas de contrat. Obtenez la certification, restez éligible.

Résumé du tableau de bord du CMMC :

  • Effort du développeur : Modéré à élevé (selon le niveau ; nécessite la mise en œuvre de contrôles liés au contrôle d'accès, à la gestion de la configuration, à l'intégrité du système, à la gestion des vulnérabilités, aux pratiques de codage sécurisées pertinentes pour la protection des CUI).
  • Coût de l'outillage : Modéré à élevé (nécessite des outils pour le contrôle d'accès, l'AMF, la sécurité des terminaux, l'analyse des vulnérabilités, la journalisation/SIEM, la gestion de la configuration, éventuellement la DLP, alignés sur les contrôles NIST 800-171).
  • Impact sur le marché : Critique (obligatoire pour la participation aux contrats du DoD impliquant FCI/CUI ; en passe de devenir une exigence fondamentale pour l'ensemble de la DIB).
  • Flexibilité : Faible à modérée (basée sur les contrôles spécifiques du NIST ; le niveau 2 autorise des plans d'action et des jalons (POA&M) limités au moment de l'évaluation, mais l'objectif est la conformité totale).
  • Intensité de l'audit : Élevée (le niveau 1 correspond à l'auto-évaluation, mais le niveau 2 exige une évaluation formelle par un tiers (C3PAO) et le niveau 3 exige une évaluation par le gouvernement).

Qu'est-ce que le CMMC ?

Le programme de certification du modèle de maturité de la cybersécurité (CMMC) est une initiative du ministère américain de la défense (DoD) visant à mettre en œuvre des normes de cybersécurité dans l'ensemble de la base industrielle de défense (DIB). Son objectif principal est de protéger les informations sensibles non classifiées qui résident sur les réseaux des entrepreneurs, en particulier :

  • Informations sur les contrats fédéraux (FCI) : Informations non destinées à être rendues publiques, fournies par le gouvernement ou produites pour lui dans le cadre d'un contrat.
  • Informations non classifiées contrôlées (CUI) : Informations nécessitant des contrôles de sauvegarde ou de diffusion en vertu de la loi, de la réglementation ou de la politique gouvernementale.

Le CMMC 2.0, l'itération actuelle, simplifie le modèle original en trois niveaux de maturité :

  • Niveau 1 (fondamental) : Se concentre sur la protection de base des FCI. S'aligne sur les 15 exigences de base spécifiées dans la FAR 52.204-21. Nécessite une auto-évaluation annuelle.
  • Niveau 2 (avancé) : Se concentre sur la protection des CUI. S'aligne complètement sur les 110 exigences de sécurité décrites dans le document NIST SP 800-171 Rev 2. Exige des évaluations triennales menées par un organisme tiers d'évaluation accrédité par le CMMC (C3PAO) pour la plupart des contrats impliquant des CUI. Un sous-ensemble de programmes de niveau 2 peut autoriser l'auto-évaluation.
  • Niveau 3 (expert) : Se concentre sur la protection des CUI contre les menaces persistantes avancées (APT). Il comprend les 110 contrôles de la norme NIST SP 800-171 ainsi qu'un sous-ensemble de contrôles de la norme NIST SP 800-172 (Enhanced Security Requirements). Exige des évaluations triennales menées par le gouvernement.

Contrairement aux approches précédentes d'auto-attestation de la norme NIST 800-171, le CMMC introduit des évaluations obligatoires (par soi-même, par un tiers ou par le gouvernement, selon le niveau) pour vérifier la mise en œuvre des pratiques de cybersécurité requises. Le niveau CMMC requis sera spécifié dans les appels d'offres et les contrats du ministère de la défense.

Pourquoi est-ce important ?

Le CMMC change la donne pour la base industrielle de défense (DIB) :

  • Obligatoire pour les contrats du ministère de la défense : À terme, l'obtention et le maintien du niveau requis du CMMC seront une condition préalable à l'attribution ou à la participation des entreprises à des contrats du DoD impliquant des FCI ou des CUI. En cas de non-conformité, les entreprises perdront leur éligibilité aux travaux du DoD.
  • Protection des informations sensibles : L'objectif est de réduire considérablement le vol d'informations sensibles relatives à la défense (FCI/CUI) dans la chaîne d'approvisionnement de la DIB, ce qui constitue une préoccupation majeure en matière de sécurité nationale.
  • Normalisation de la cybersécurité : Elle crée une norme de cybersécurité unifiée pour l'ensemble de la DIB, en passant d'une auto-attestation incohérente à une conformité vérifiée.
  • Renforcement de la sécurité de la chaîne d'approvisionnement : Les exigences sont transmises aux sous-traitants qui traitent les FCI/CUI, afin de sécuriser l'ensemble de la chaîne d'approvisionnement.
  • Renforcement de la responsabilité : L'auto-attestation est remplacée par des évaluations vérifiées, ce qui renforce la responsabilité dans la mise en œuvre des contrôles de sécurité requis.
  • Instaurer la confiance : La certification CMMC garantit au DoD (et aux maîtres d'œuvre) que les sous-traitants ont mis en place des mesures de cybersécurité appropriées.

Pour toute entreprise qui travaille actuellement avec le ministère de la défense ou qui envisage de le faire, la compréhension et la mise en conformité avec le CMMC deviennent essentielles à la survie et à la croissance sur le marché de la défense.

Quoi et comment mettre en œuvre (technique et politique)

La mise en œuvre du CMMC implique l'adoption des pratiques de cybersécurité associées au niveau cible, qui sont largement inspirées de la FAR 52.204-21 et de la NIST SP 800-171 / 800-172:

  1. Déterminer le niveau requis : Déterminer le niveau CMMC requis en fonction du type d'informations traitées (FCI uniquement pour le niveau 1 ; CUI pour le niveau 2/3) et des exigences contractuelles spécifiques.
  2. Définir le champ d'application : Identifier clairement les systèmes, les biens, les lieux et le personnel qui manipulent des FCI/CUI. Cette "frontière CUI" est essentielle pour l'évaluation. Documenter les flux de données.
  3. Analyse des lacunes : Évaluer le niveau de sécurité actuel par rapport aux exigences du niveau CMMC visé (15 contrôles pour L1 ; 110 contrôles NIST 800-171 pour L2 ; L2 + sous-ensemble NIST 800-172 pour L3). Identifier les lacunes.
  4. Remédiation et mise en œuvre : combler les lacunes identifiées en mettant en œuvre les contrôles requis. Ces contrôles couvrent 14 domaines dérivés de la norme NIST 800-171 :
    • Contrôle d'accès (CA) : Mise en œuvre du principe du moindre privilège, gestion des comptes, contrôle de l'accès à distance, utilisation de l'AMF (nécessaire pour les CUI).
    • Sensibilisation et formation (AT) : Organiser des formations de sensibilisation à la sécurité.
    • Audit et responsabilité (AU) : Générer et conserver les journaux du système, s'assurer que les actions peuvent être tracées jusqu'aux utilisateurs.
    • Gestion de la configuration (CM) : établir des lignes de base pour la configuration, gérer les changements, restreindre l'installation de logiciels.
    • Identification et authentification (IA) : Identifier et authentifier les utilisateurs de manière unique (y compris l'AMF pour l'accès aux CUI).
    • Réponse aux incidents (RI) : Élaborer et tester un plan de réponse aux incidents.
    • Maintenance (MA) : Effectuer la maintenance du système en toute sécurité.
    • Protection des supports (MP) : Assainir ou détruire les supports contenant des informations confidentielles.
    • Sécurité du personnel (SP) : Contrôler les personnes avant de leur accorder l'accès.
    • Protection physique (PE) : Limiter l'accès physique, escorter les visiteurs.
    • Évaluation des risques (ER) : Évaluer périodiquement les risques, rechercher les vulnérabilités.
    • Évaluation de la sécurité (CA) : Élaborer le plan de sécurité du système (SSP), surveiller les contrôles, gérer les POA&M.
    • Protection des systèmes et des communications (SC) : Surveiller/contrôler les limites des communications (pare-feu), mettre en œuvre des protections cryptographiques (par exemple, chiffrement validé par la norme FIPS 140 pour les données CUI au repos/en transit), refuser le trafic réseau par défaut.
    • Intégrité du système et de l'information (SI) : Identifier/gérer les failles, protéger contre les logiciels malveillants, surveiller les changements non autorisés.
  5. Documentation : Élaborer une documentation clé :
    • Plan de sécurité du système (SSP) : Il décrit la manière dont chaque contrôle requis est respecté.
    • Politiques et procédures : Documentation formelle étayant la mise en œuvre des contrôles.
    • Plan d'action et étapes (POA&M) : Si des lacunes subsistent (elles ne sont autorisées que temporairement pour le CMMC de niveau 2 dans des conditions spécifiques), documenter le plan pour y remédier.
  6. Auto-évaluation (tous les niveaux) : Réaliser une évaluation interne par rapport aux exigences et calculer un score d'évaluation NIST SP 800-171 le cas échéant (requis pour la soumission au SPRS).
  7. Préparer l'évaluation : Rassembler les preuves, préparer le personnel aux entretiens, s'assurer que la documentation est complète.
  8. Faire l'objet d'une évaluation :
    • Niveau 1 : Auto-évaluation annuelle.
    • Niveau 2 : évaluation triennale par C3PAO (pour la plupart) ou auto-évaluation (pour certains).
    • Niveau 3 : évaluation triennale menée par le gouvernement.

La mise en œuvre repose en grande partie sur l'alignement des pratiques sur la norme NIST SP 800-171 et sur la démonstration de la maturité et de l'efficacité par le biais de la documentation et de l'évaluation.

Les erreurs courantes à éviter

L'obtention de la certification du CMMC nécessite une planification minutieuse. Évitez les erreurs suivantes :

  1. Sous-estimation de la portée/complexité : Ne pas identifier avec précision tous les systèmes/lieux où les FCI/CUI sont stockés, traités ou transmis, ce qui conduit à une évaluation incomplète.
  2. Manque d'engagement de la part des dirigeants : Traiter le CMMC comme un problème purement informatique sans le soutien de la direction pour les ressources nécessaires, les changements de politique et les changements culturels.
  3. Ressources insuffisantes : Sous-financement de l'effort ou manque de personnel ayant l'expertise nécessaire pour mettre en œuvre et documenter correctement les contrôles NIST 800-171.
  4. Documentation insuffisante : Les DPS, les politiques et les procédures sont faibles ou inexistantes, ou les preuves de la mise en œuvre des contrôles ne sont pas collectées de manière adéquate au cours de l'évaluation.
  5. Ignorer la norme NIST SP 800-171 : Supposer que les pratiques de sécurité existantes sont suffisantes sans effectuer une analyse détaillée des lacunes par rapport aux 110 contrôles requis pour le niveau 2.
  6. Négliger la chaîne d'approvisionnement : Ne pas transmettre les exigences du CMMC aux sous-traitants qui s'occupent des FCI/CUI, ou ne pas gérer les risques liés aux fournisseurs de services externes (ESP), comme les plateformes en nuage.
  7. Procrastination : Attendre que les exigences du CMMC apparaissent dans les contrats, sous-estimer les 9 à 18 mois ou plus nécessaires à la préparation et à la remédiation.
  8. Le traiter comme un exercice de "vérification de la boîte" : Mettre en œuvre des contrôles de manière superficielle sans s'assurer qu'ils sont réellement efficaces et intégrés dans les opérations.

Ce que les auditeurs et les évaluateurs demanderont (accent mis sur les développeurs)

Alors que les évaluations du CMMC couvrent les pratiques générales en matière d'informatique et de sécurité, les développeurs qui manipulent des CUI ou qui travaillent sur des systèmes relevant du CMMC peuvent être amenés à démontrer qu'ils respectent des contrôles tels que les suivants :

  • (CM Controls) "Comment les modifications apportées à la configuration du logiciel sont-elles gérées et suivies ?"
  • (Contrôles SI) "Quelles sont les mesures mises en place pour détecter et prévenir les codes malveillants pendant le développement ?"
  • (Contrôles SA - liés à 800-171) "Décrivez vos pratiques de développement de logiciels sécurisés". (Bien qu'il ne soit pas explicitement détaillé dans la norme 800-171 elle-même dans la mesure du SSDF, le développement sécurisé est une attente implicite pour la protection des CUI).
  • (Contrôles AC) "Comment l'accès aux environnements de développement et au code source contenant des CUI est-il contrôlé ?"
  • (Contrôles de l'UA) "Les actions des développeurs sont-elles enregistrées, en particulier lorsqu'ils accèdent à des systèmes contenant des CUI ?"
  • (Contrôles de l'AR) "Comment les vulnérabilités sont-elles identifiées et corrigées dans les logiciels développés sur mesure qui traitent les CUI ?" (par exemple, utilisation de SAST/DAST)
  • (Contrôles SC) "Comment les CUI sont-ils protégés pendant la transmission (par exemple, cryptage utilisé dans les API) ?"

Les évaluateurs rechercheront les contrôles techniques mis en œuvre, les procédures documentées suivies par les développeurs et les preuves (journaux, résultats d'analyse, examens d'accès) confirmant la conformité.

Des gains rapides pour les équipes de développement

Les équipes de développement peuvent contribuer à l'état de préparation du CMMC, en particulier pour le niveau 2 (alignement NIST 800-171) :

  1. Identifier les CUI dans le développement : comprendre si/où des CUI peuvent exister dans le code, les données de test, la documentation ou les outils de développement. Mettre en œuvre des procédures de traitement si nécessaire.
  2. Sécuriser les environnements de développement : Appliquer des contrôles d'accès (moindre privilège, MFA) aux serveurs de développement, aux référentiels de code et aux pipelines CI/CD, en particulier en cas de manipulation de CUI.
  3. Intégrer SAST/SCA : utiliser des outils automatisés pour trouver rapidement les vulnérabilités dans le code et les dépendances. (Soutient RA.L2-3.11.2, SI.L2-3.14.1)
  4. Gestion des secrets : Veiller à ce qu'aucun secret ou justificatif d'identité (en particulier ceux qui permettent d'accéder à des données CUI) ne soit codé en dur. (Compatible avec AC.L1-3.1.1, AC.L1-3.1.2)
  5. Formaliser la gestion des changements : Utiliser Gitflow/PR, exiger des approbations, lier les changements aux problèmes. (Compatible avec CM.L2-3.4.1, CM.L2-3.4.2)
  6. Formation à la sécurité des développeurs : Sensibilisation de base à la sécurité et formation au codage sécurisé. (Soutient AT.L2-3.2.1)

Ignorez ceci et... (Conséquences de la non-conformité)

Pour les organisations de la base industrielle de défense, la non-conformité au CMMC aura des conséquences directes et graves au fur et à mesure du déploiement du cadre :

  • Inéligibilité aux contrats du ministère de la défense : Principale conséquence. Si les organisations ne parviennent pas à atteindre le niveau requis du CMMC, elles ne pourront pas se voir attribuer de nouveaux contrats du ministère de la défense ou poursuivre des travaux dans le cadre de contrats existants qui impliquent des FCI/CUI.
  • Perte de revenus : Le fait d'être exclu des contrats du DoD peut signifier une perte importante de revenus actuels et futurs pour les entrepreneurs du secteur de la défense.
  • Exclusion de la chaîne d'approvisionnement : Les contractants principaux exigeront de leurs sous-traitants qu'ils respectent les exigences du CMMC, ce qui signifie que les sous-traitants non conformes seront exclus des chaînes d'approvisionnement du ministère de la défense.
  • Désavantage concurrentiel : Les entreprises qui obtiennent la certification du CMMC auront un avantage significatif sur leurs concurrents qui ne l'obtiennent pas.
  • Pénalités contractuelles potentielles : Les contrats existants pourraient être affectés si les exigences du CMMC sont répercutées et non respectées, ce qui pourrait entraîner des problèmes de rupture de contrat (bien que les spécificités soient encore en cours d'évolution).

En fait, la conformité au CMMC est en train de devenir un coût de fonctionnement pour la DIB.

FAQ

Qui a besoin de la certification du CMMC ?

Toutes les organisations de la chaîne d'approvisionnement de la base industrielle de défense (DIB) qui traitent des informations contractuelles fédérales (FCI) ou des informations non classifiées contrôlées (CUI) devront un jour atteindre un niveau CMMC spécifique, comme l'exigent leurs contrats avec le DoD.

Quelle est la différence entre le CMMC 1.0 et le CMMC 2.0 ?

Le CMMC 2.0 a ramené les 5 niveaux originaux à 3. Il a supprimé les pratiques et processus propres au CMMC, alignant le niveau 2 directement sur la norme NIST SP 800-171 et le niveau 3 sur la norme NIST SP 800-171 + un sous-ensemble de la norme NIST SP 800-172. Elle autorise également les auto-évaluations au niveau 1 (et un sous-ensemble du niveau 2) et permet l'utilisation limitée de plans d'action et de jalons (POA&M) au moment de l'évaluation du niveau 2 dans des conditions spécifiques.

Quelle est la différence entre FCI et CUI ?

Les FCI (Federal Contract Information) sont des informations qui ne sont pas destinées à être rendues publiques et qui sont fournies par/pour le gouvernement dans le cadre d'un contrat. Les CUI (Controlled Unclassified Information) sont une catégorie plus large nécessitant des contrôles de sauvegarde, définis par des lois, des règlements ou des politiques gouvernementales (par exemple, les données contrôlées à l'exportation, certaines données techniques). La manipulation d'informations classifiées et contrôlées entraîne la nécessité d'une CMMC de niveau 2 ou 3.

Quand la CMMC sera-t-elle exigée dans les contrats ?

Le DoD met en œuvre la CMMC de manière progressive, potentiellement à partir de la mi ou de la fin de l'année 2025, en fonction de la finalisation de la règle du programme CMMC (actuellement en cours d'examen). La CMMC devrait apparaître de plus en plus dans les contrats au cours des années suivantes et devenir une exigence pour presque tous les contrats du DoD concernant les FCI/CUI vers la fin de 2027 ou le début de 2028.

Qu'est-ce que la norme NIST SP 800-171 et quel est son rapport avec le CMMC ?

La norme NIST SP 800-171 énonce les exigences relatives à la protection des CUI dans les systèmes non fédéraux. Le niveau 2 du CMMC est directement aligné sur les 110 exigences de sécurité spécifiées dans la norme NIST SP 800-171 Rev 2. La conformité à la norme NIST 800-171 est la base pour atteindre le niveau 2 du CMMC.

Qu'est-ce qu'un C3PAO ?

Un organisme d'évaluation tierce partie du CMMC (C3PAO) est un organisme accrédité par l'organisme d'accréditation du CMMC (The Cyber AB) autorisé à effectuer des évaluations de certification de niveau 2 du CMMC.

Pouvons-nous utiliser des services en nuage (comme AWS, Azure, Google Cloud) pour le CMMC ?

Oui, mais l'environnement du fournisseur de services en nuage (CSP) doit répondre à des exigences spécifiques. Pour les contrats exigeant le niveau 2 de la CMMC, les contractants peuvent utiliser des offres de CSP autorisées par FedRAMP Moderate (ou High) ou équivalentes. Les responsabilités en matière de contrôles sont partagées entre le contractant et le CSP, ce qui nécessite une documentation minutieuse (par exemple, la matrice des responsabilités partagées).

Chapitre suivant
Chapitre précédent
Chapitre suivant
Chapitre précédent
Chapitre suivant
Chapitre précédent
Chapitre suivant
Chapitre précédent
Chapitre suivant
Chapitre précédent
Chapitre suivant
Chapitre précédent
Chapitre suivant
Chapitre précédent
Chapitre suivant
Chapitre précédent
Chapitre suivant
Chapitre précédent
Chapitre suivant
Chapitre précédent
Chapitre suivant
Chapitre précédent
Chapitre suivant
Chapitre précédent
Chapitre suivant
Chapitre précédent
Chapitre suivant
Chapitre précédent
Chapitre suivant
Chapitre précédent
Chapitre suivant
Chapitre précédent
Chapitre suivant
Chapitre précédent
Chapitre suivant
Chapitre précédent
Chapitre suivant
Chapitre précédent
Chapitre suivant
Chapitre précédent
Chapitre suivant
Chapitre précédent
Chapitre suivant
Chapitre précédent
Chapitre suivant
Chapitre précédent
Chapitre suivant
Chapitre précédent
Chapitre suivant
Chapitre précédent
Chapitre suivant
Chapitre précédent
Aller à :
Lien texte

La sécurité bien faite.
. Plus de 25 000 entreprises lui font confiance.

Essai gratuit
Sans CB
Réservez une démo
Partager :

www.aikido.dev/learn/software-security-tools/cmmc

Table des matières

Chapitre 1 : Comprendre les cadres de conformité

Que sont les cadres de conformité et pourquoi sont-ils importants ?
Comment les cadres de conformité affectent les flux de travail DevSecOps
Éléments communs aux différents cadres

Chapitre 2 : Explication des principaux cadres de conformité

Conformité SOC 2
ISO 27001
ISO 27017 / 27018
NIST SP 800-53
NIST SSDF (SP 800-218)
OWASP ASVS
GDPR
Directive NIS2
DORA
Loi européenne sur la cyber-résilience (CRA)
CMMC
PCI DSS
FedRAMP
HIPAA / HITECH
Huit essentiels
CCoP de Singapour (pour CII)
Loi japonaise sur la cybersécurité et mesures connexes (APPI)

Chapitre 3 : Mise en œuvre de la conformité dans le développement

Choisir les bons cadres pour votre organisation
Construire des pipelines DevSecOps conformes
Formation des équipes de développement à la conformité
Préparation de l'audit pour les développeurs
Maintien de la conformité à long terme
La fin

Articles de blog connexes

Voir tous
Voir tous
4 juin 2024
-
Conformité

Certification SOC 2 : 5 choses que nous avons apprises

Ce que nous avons appris sur SOC 2 au cours de notre audit. ISO 27001 vs. SOC 2, pourquoi le type 2 a du sens, et comment la certification SOC 2 est essentielle pour les clients américains.

16 janvier 2024
-
Conformité

NIS2 : Qui est concerné ?

À qui s'applique le NIS2 ? Qui est concerné ? Quels sont les secteurs essentiels et importants et les seuils de taille des entreprises ? L'application Aikido dispose d'une fonction de rapport NIS2.

5 décembre 2023
-
Conformité

Certification ISO 27001 : 8 choses que nous avons apprises

Ce que nous aurions aimé savoir avant d'entamer le processus de mise en conformité avec la norme ISO 27001:2022. Voici nos conseils pour toute entreprise SaaS qui souhaite obtenir la certification ISO 27001.

Entreprise
ProduitTarifsA proposCarrièresContactPartenariat avec nous
Ressources
DocsDocuments de l'API publiqueBase de données des vulnérabilitésBlogIntégrationsGlossaireDossier de presseAvis des clients
Sécurité
Trust CenterAperçu de la sécuritéModifier les préférences en matière de cookies
Juridique
Politique de confidentialitéPolitique en matière de cookiesConditions d'utilisationAccord-cadre de souscriptionAccord sur le traitement des données
Cas d'utilisation
ConformitéDAST & DASTSGAAGestion de la vulnérabilitéGénérer des SBOMSécurité de WordPressSécurisez votre codeL'aïkido pour MicrosoftAikido pour AWS
Industries
HealthTechMedTechFinTechSecurityTechLegalTechHRTechPour les agencesPour les entreprisesPrivate Equity et sociétés de groupe
Comparer
vs Tous les vendeursvs Snykvs Wizvs Mendvs Orca Securityvs Veracodevs GitHub Advanced Securityvs GitLab Ultimatevs Checkmarxvs Semgrepvs SonarQube
Contact
hello@aikido.dev
LinkedInX
S'abonner
Restez informé(e) de toutes les mises à jour
Nous n'en sommes pas encore là.
👋🏻 Merci ! Vous avez été abonné.
L'équipe Aikido
Nous n'en sommes pas encore là.
© 2025 Aikido Security BV | BE0792914919
🇪🇺 Adresse du siège social : Coupure Rechts 88, 9000, Gand, Belgique
🇪🇺 Adresse du bureau : Gebroeders van Eyckstraat 2, 9000, Gand, Belgique
🇺🇸 Adresse du bureau : 95 Third St, 2nd Fl, San Francisco, CA 94103, US
SOC 2
Conforme
ISO 27001
Conforme