Support technique
Documentation
Connexion
Nous contacter
Accédez directement au résumé généré par l'IA de cet article de blog 
Principaux enseignements
- Depuis le 13 juillet 2026, les appels d'offres dans le domaine de la défense peuvent n'exiger que des auto-évaluations de niveau 1 ou de niveau 2, la phase 2 restant suspendue.
- Aucune des 110 exigences de niveau 2 ne mentionne l'open source, mais les logiciels constituant un actif, les progiciels open source installés sur les systèmes concernés sont donc pris en compte au même titre que les autres.
- Quatre exigences s'appliquent à eux : l'inventaire, les logiciels installés par les utilisateurs, l'analyse des vulnérabilités et la correction des failles.
- Trois d'entre elles constituent des exigences à cinq points ; par conséquent, toute lacune dans l'une d'entre elles ne peut pas faire l'objet d'un report dans le cadre d'un plan d'action et d'étapes clés.
Les exigences de conformité de la certification CMMC (Cybersecurity Maturity Model Certification) n’imposent aucune contrainte spécifique concernant vos logiciels libres. Cependant, les 110 exigences définies par le CMMC pour les sous-traitants traitant des informations non classifiées contrôlées (CUI) s’appliquent tout de même aux paquets open source présents dans votre build. Cela reste vrai même après que le Pentagone a suspendu, le 13 juillet 2026, la phase 2 du programme CMMC, étape qui aurait fait de l’évaluation par un tiers une condition d’attribution des contrats concernés. Ces mêmes 110 exigences constituent toujours la base des auto-évaluations.
Ce que couvrent les exigences de conformité au CMMC
Le CMMC comporte trois niveaux. Le niveau qui vous concerne dépend des informations en jeu et des exigences stipulées dans votre contrat ou votre appel d'offres.
| Niveau | Informations | Conditions | Qui évalue ? |
|---|---|---|---|
| Niveau 1 | Informations sur les marchés publics fédéraux (FCI) | Les 15 exigences fondamentales du Règlement fédéral sur les marchés publics | Vous, dans le cadre d'une auto-évaluation annuelle |
| Niveau 2 | CUI | 110 exigences issues de la norme SP 800-171, révision 2, de l'Institut national des normes et des technologies (NIST) | Vous-même, ou un organisme tiers d'évaluation CMMC (C3PAO), lorsque l'appel d'offres l'exige (suspendu pour le moment) |
| Niveau 3 | CUI sur certains programmes | 24 exigences sélectionnées issues de la norme NIST SP 800-172, en plus du niveau 2 | L'Agence de gestion des contrats de défense (DCMA) |
Les 110 exigences de niveau 2 couvrent 14 catégories, allant du contrôle d'accès à l'intégrité des systèmes et des informations.
État d'avancement des exigences de conformité CMMC en 2026
La règle du « Defense Federal Acquisition Regulation Supplement » (DFARS) qui intègre le CMMC dans les contrats est entrée en vigueur le 10 novembre 2025, marquant ainsi le début de la phase 1. Dans le cadre de cette phase 1, le ministère de la Défense (DoD) impose, le cas échéant, une obligation d’auto-évaluation de niveau 1 ou 2 comme condition d’attribution du marché.
La phase 2, dont la date butoir était fixée au 10 novembre 2026, aurait ajouté les évaluations de niveau 2 réalisées par les C3PAO comme condition d’attribution du marché. Le 13 juillet 2026, le directeur des systèmes d’information du ministère de la Défense a suspendu cette mesure. Les responsables de programme peuvent désormais exiger uniquement des auto-évaluations de niveau 1 ou 2, et les contrats qui prévoient déjà une évaluation par un C3PAO ou menée par le gouvernement doivent être modifiés lors de la prochaine période d’option ou lors d’une modification administrative.
Le règlement du programme n'ayant pas été réécrit depuis que la suspension a été communiquée par note de service, il décrit toujours les quatre phases initiales. C'est sur la page consacrée au CMMC du directeur des systèmes d'information du ministère de la Défense que sont publiées les modifications.
Pour l'instant, les 110 exigences constituent le terrain d'entente, et c'est par leur intermédiaire que l'open source fait son apparition.
Ce que prévoit la réglementation concernant les composants open source
Les 110 exigences de niveau 2 correspondent à celles de la norme NIST SP 800-171, révision 2, et le règlement du programme précise qu’elles sont identiques. Le NIST a depuis remplacé la révision 2 par la révision 3, mais le CMMC continue d’utiliser la révision 2, tout comme le guide d’évaluation du DoD. Concrètement, cela signifie que la version des exigences qui s'applique à vos progiciels open source est celle de la révision 2, et non celle de la révision 3.
Chacune des 110 exigences s'accompagne, dans les documents du NIST et du DoD, de deux éléments : un ensemble d'objectifs d'évaluation (une liste de contrôle des conditions à remplir pour que l'exigence soit considérée comme satisfaite) et une note explicative (un texte décrivant l'intention visée, mais qui ne constitue pas en soi une exigence).
Le guide d’évaluation de niveau 2 demande aux personnes chargées de l’auto-évaluation d’utiliser les mêmes critères qu’un évaluateur tiers et de ne pas considérer les déclarations du personnel lors des entretiens comme une preuve du fonctionnement réel du système. La section « Notation » de la règle définit la norme en matière de preuves : les projets, les documents de travail et les politiques non approuvées ne sont pas pris en compte. Pour l’open source, cela signifie qu’un projet d’inventaire ou une politique de numérisation qui n’a été validé par personne ne constitue pas une preuve.
Aucune des 110 exigences ne fait explicitement référence à l’open source ni ne mentionne les listes de composants logiciels (SBOM), la provenance ou la chaîne d’approvisionnement. Le logiciel est pris en compte à travers les définitions. Dans le cadre du CMMC, le logiciel est considéré comme un actif ; par conséquent, les paquets open source présents sur un système entrant dans le champ d’application de votre évaluation sont soumis aux mêmes exigences que le reste des logiciels de ce système. Ce qui fait qu’un système entre dans le champ d’application, c’est ce qu’il fait des informations classifiées (CUI) : les actifs qui les traitent, les stockent ou les transmettent sont évalués au regard de chaque exigence de niveau 2. Le champ d’application inclut également les actifs qui protègent ces systèmes, tels que les pare-feu et les services d’identité. Un serveur de compilation ou un poste de travail de développeur qui n’entre jamais en contact avec des informations classifiées (CUI) peut en être exclu ; c’est sur ce jugement de périmètre que repose ultérieurement l’exigence relative aux logiciels installés par l’utilisateur. Le guide de délimitation du champ d’application du DoD en présente la ventilation complète.
Le risque lié à la chaîne d'approvisionnement est mentionné dans deux exigences de niveau 3, mais le niveau 3 constitue un échelon distinct, soumis à une évaluation spécifique menée par les pouvoirs publics ; par conséquent, aucune de ces exigences ne s'applique au niveau 2.
Quatre pratiques pour accéder à votre arborescence de dépendances
Tenez un inventaire des éléments présents sur le système (CM.L2-3.4.1). Vous devez tenir à jour une liste du matériel et des logiciels qui composent chaque système concerné, y compris les numéros de version, et la mettre à jour à mesure que le système évolue. L'open source entre ici en jeu, car les paquets de votre application, y compris ceux intégrés indirectement par d'autres paquets, sont des logiciels dotés de numéros de version. S'ils ne figurent pas sur la liste, celle-ci est incomplète.
Contrôler ce que les utilisateurs installent (CM.L2-3.4.9). Vous devez disposer d’une politique définissant les logiciels que les utilisateurs sont autorisés à installer, d’un moyen de la faire respecter et d’un moyen de vérifier ce qui a été installé. Le texte explicatif du NIST précise que la politique peut interdire les logiciels « dont la provenance est inconnue ou suspecte », ce qui est ce qui se rapproche le plus, au niveau 2, d’une question sur l’origine des logiciels. Cette mention relative à la « provenance » est une recommandation ; elle ne peut donc pas à elle seule vous porter préjudice. L’exigence en elle-même — à savoir une politique régissant les installations, son application et un registre des installations effectuées — n’est pas facultative. De plus, si votre environnement de développement fait partie du périmètre d’évaluation, les paquets que les développeurs y ajoutent peuvent être considérés comme des installations au même titre que les autres.
Effectuez des analyses de vulnérabilité selon un calendrier défini (RA.L2-3.11.2). Vous devez analyser les systèmes et les applications à la fréquence que vous définissez et lancer des analyses supplémentaires lorsque de nouvelles vulnérabilités sont signalées. Les paquets open source présents dans vos applications font partie des éléments analysés.
Pris dans leur ensemble, les exigences relatives à l'inventaire, aux logiciels installés par les utilisateurs et à l'analyse des vulnérabilités couvrent le contenu de votre image, ce qui y est autorisé et les vulnérabilités connues qu'elle comporte. La quatrième exigence, qui consiste à corriger les failles dans les meilleurs délais (SI.L2-3.14.1), traite de ce qui se passe une fois qu'une vulnérabilité a été détectée.
Pourquoi la correction rapide des failles nécessite une valeur que vous définissez
La norme SI.L2-3.14.1 stipule qu’il faut identifier, signaler et corriger les failles du système dans les meilleurs délais, mais ni l’exigence elle-même, ni le texte explicatif du NIST, ni le guide d’évaluation du DoD ne précisent ce que recouvre la notion de « meilleurs délais ». Ces trois documents vous laissent le soin de fixer un délai, et l’exemple donné dans le guide lui-même correspond à un nombre de jours déterminé en fonction de la gravité de la faille. Ce que vous devez démontrer, c’est que vous en avez défini un et que vous l’avez respecté.
Tout délai que vous ne respectez pas systématiquement laisse une trace de ce manquement, et en l'absence de délai défini, la liste de contrôle d'évaluation ne peut pas être complétée.
Le cas le plus complexe concerne un composant dont plus personne n’assure la maintenance, car aucun correctif n’est fourni en amont. Le guide considère les correctifs appliqués, les modifications de configuration, ainsi que les solutions de contournement ou les mesures d’atténuation comme des moyens de corriger une faille ; vous disposez donc de plusieurs options. Vous pouvez remplacer le composant, passer à une série de versions plus récente, mettre en place une solution de contournement ou faire appliquer un correctif à la version que vous utilisez ; chacune de ces options laisse des traces différentes. Le remplacement ou la mise à niveau supposent l’existence d’un substitut ou d’une série plus récente, ainsi que la capacité de votre code à s’adapter à ce changement. C’est pourquoi la mise à niveau n’est pas toujours envisageable, en particulier lorsque le composant se trouve profondément ancré dans l’arborescence.
Ce qu’une assurance POA&M couvre et ne couvre pas
Une évaluation aboutit à l'un des trois résultats suivants pour chaque exigence (« SATISFAIT », « NON SATISFAIT » ou « sans objet ») et à un statut global. Le statut « définitif » signifie que toutes les exigences sont satisfaites. Le statut « conditionnel » signifie qu'il subsiste quelques lacunes et que vous vous êtes engagé à y remédier.
La méthode de notation prévue par la règle attribue 1, 3 ou 5 points à chaque exigence en fonction des dommages potentiels qu’une lacune pourrait causer. Vous commencez avec 110 points et en perdez pour chaque exigence non respectée. Parmi les quatre exigences qui s’appliquent à vos paquets open source, trois (inventaire, analyse des vulnérabilités et correction des failles) valent chacune cinq points, tandis que les logiciels installés par les utilisateurs en valent un.
Un plan d'action et des étapes clés (POA&M) vous permettent de reporter la résolution de certaines lacunes au-delà de l'évaluation, mais l'article 170.21 du règlement du programme impose des limites très strictes à cette possibilité. Vous ne pouvez obtenir le statut « conditionnel », celui qui autorise un POA&M, qu'avec un score d'au moins 88 sur 110.
Seules les exigences valant un point peuvent être incluses dans le plan, à l’exception de l’exigence relative au chiffrement, qui vaut normalement cinq points mais peut être incluse lorsqu’elle est notée à trois, car le chiffrement utilisé n’est pas validé selon les normes FIPS (Federal Information Processing Standards). La règle exclut également six exigences spécifiques du plan, quelle que soit leur note : l’exigence relative au plan de sécurité du système, deux concernant les connexions externes et les informations publiques, et trois exigences relatives à l’accès physique.
Le fait d'ajouter un écart au plan ne modifie en rien son résultat, qui reste « NON SATISFAIT » jusqu'à ce qu'il soit comblé.
Toute opération figurant dans le plan doit être finalisée et confirmée dans un délai de 180 jours, faute de quoi le statut « conditionnel » expirera. Ce délai de 180 jours s'applique aussi bien à une auto-évaluation de niveau 2 qu'à une évaluation réalisée par un tiers.
L'inventaire, l'analyse des vulnérabilités et la correction des failles constituent des exigences à cinq points ; aucune d'entre elles ne peut donc être reportée dans le plan : soit vous les respectez au moment de l'évaluation, soit vous n'obtenez pas le statut « Conditionnel ». Les logiciels installés par les utilisateurs constituent une exigence à un point ; une lacune à ce niveau peut donc être reportée dans le plan tant que votre score global reste d'au moins 88. Elle est tout de même considérée comme « NON RESPECTÉE » et doit être corrigée dans un délai de 180 jours.
Remarque : le plan d’action opérationnel prévu par la norme CA.L2-3.12.2 constitue un document distinct. La norme le définit comme un registre répertoriant les vulnérabilités et les lacunes temporaires ainsi que les mesures prévues pour y remédier, sans calendrier précis, et il ne s’agit pas du même document que le plan d’action et de suivi (POA&M) issu de l’évaluation. Le délai de 180 jours s’applique au POA&M.
Exigences de conformité au CMMC pour les sous-traitants et les petites entreprises
La règle du programme s’applique aux titulaires de contrats et de sous-contrats du DoD qui traitent, stockent ou transmettent des FCI ou des CUI dans le cadre de leur travail, et elle s’étend aux sous-traitants qui effectuent les mêmes opérations. Les responsables de programme du DoD déterminent le niveau CMMC pour chaque marché en fonction des informations concernées et de la criticité du programme ; ainsi, deux entreprises de taille identique peuvent se voir attribuer des niveaux différents. Au sein du niveau 2, les 110 exigences constituent une liste unique pour tous.
L'importance de cette question transparaît dans le raisonnement même du ministère de la Défense. L'annonce du 13 juillet, qui a suspendu la phase 2, précisait que l'examen mené par le ministère visait à réduire les obstacles pour les petites entreprises et les entreprises non traditionnelles. En attendant que cet examen débouche sur des changements, le régime d'auto-évaluation constitue la seule mesure d'allègement disponible.
Le rôle de SecureChain
SecureChain, proposé par TuxCare, fournit des paquets open source qui sont contrôlés avant de vous être livrés et pour lesquels des correctifs sont fournis tant que vous les utilisez. Il sert de source unique pour JavaScript, Python, Java, Go, Rust et PHP.
Chaque paquet est recompilé à partir du code source dans des environnements isolés et soumis à des contrôles visant à détecter les logiciels malveillants et les codes suspects ; tout élément ne passant pas ces contrôles est bloqué avant d’atteindre votre environnement. Les composants actifs bénéficient de correctifs dans le cadre d’un accord de niveau de service. Lorsque la maintenance en amont prend fin, le service « Endless Lifecycle Support » (ELS) continue de fournir des correctifs pour les composants qui ne sont plus pris en charge.
Elle génère également des documents relatifs à ses livraisons, notamment des informations de provenance conformes à la norme SLSA (Supply-chain Levels for Software Artifacts) de niveau 3, une liste des composants logiciels (SBOM) et des données VEX (Vulnerability Exploitability eXchange).
Documents à présenter
Le CMMC ne mentionne nulle part les termes « open source ». Cependant, lorsque vous évaluez vous-même votre inventaire des systèmes, vos résultats d’analyse et votre registre des corrections apportées et de leurs dates, chaque composant open source de vos applications doit apparaître dans chacun de ces éléments. Si vous n’êtes pas en mesure de fournir ces trois éléments pour un composant à l’heure actuelle, c’est cette lacune qu’il faut combler en priorité.
FAQ
Quelles sont les exigences de conformité au CMMC ?
Le programme de certification du modèle de maturité en cybersécurité (CMMC) définit des exigences de sécurité pour les sous-traitants du secteur de la défense qui traitent des informations relatives aux contrats fédéraux (FCI) ou des informations non classifiées mais soumises à des restrictions d’accès (CUI). Le niveau 1 couvre 15 exigences de base, le niveau 2 couvre les 110 exigences de la norme SP 800-171, révision 2, de l’Institut national des normes et des technologies (NIST), et le niveau 3 ajoute 24 exigences sélectionnées issues de la norme SP 800-172.
À partir de quand la conformité à la norme CMMC sera-t-elle obligatoire en 2026 ?
Cela dépend du contrat. Depuis le 10 novembre 2025, les nouveaux appels d’offres du ministère de la Défense peuvent exiger des auto-évaluations de niveau 1 ou 2 comme condition d’attribution dans le cadre du programme de certification du modèle de maturité en cybersécurité (CMMC). La phase 2, qui aurait dû introduire des évaluations de niveau 2 réalisées par des tiers le 10 novembre 2026, est suspendue depuis le 13 juillet 2026.
Quelles sont les exigences de conformité CMMC pour les petites entreprises ?
Les petites entreprises sont soumises aux mêmes exigences que les autres prestataires de leur niveau. La réglementation du programme définit des exigences en fonction du type d’informations traitées, et le niveau 2 correspond à une liste unique de 110 exigences applicables à tous. Dans son annonce de juillet 2026 concernant la suspension d’une partie du programme, le ministère de la Défense a indiqué que son réexamen visait à réduire les obstacles pour les petites entreprises et les entreprises non traditionnelles.
Le niveau 2 du CMMC exige-t-il des registres de provenance pour les logiciels libres ?
Non. Dans le programme de certification du modèle de maturité en cybersécurité (CMMC), aucune des 110 exigences de niveau 2 ne mentionne spécifiquement l’open source ou la provenance. La note explicative relative aux logiciels installés par l’utilisateur, CM.L2-3.4.9, précise que les installations interdites peuvent inclure des logiciels dont la provenance est inconnue ou suspecte, mais il s’agit là d’une simple note explicative. Le risque lié à la chaîne d’approvisionnement est mentionné dans deux exigences de niveau 3.
Un plan d'action et des étapes clés peuvent-ils couvrir la correction des défauts ?
Ce n'est pas possible. Un plan d'action et ses étapes clés ne peuvent comporter que des exigences valant un point, à l'exception d'une seule relative au chiffrement ; la correction des failles (SI.L2-3.14.1) est quant à elle notée sur cinq points dans le cadre de la règle du programme. Un plan doit également obtenir une note d'au moins 88 sur 110 et être clôturé dans un délai de 180 jours, faute de quoi le statut « Conditionnel » expire.
Comment maintenir la conformité à la norme CMMC après une évaluation ?
Dans le cadre du programme de certification du modèle de maturité en matière de cybersécurité (CMMC), un responsable habilité, c'est-à-dire la personne habilitée à attester de la conformité de l'entreprise, doit confirmer chaque année que cette conformité est toujours respectée. Le statut de niveau 2 est valable trois ans avant qu'une nouvelle évaluation ne soit nécessaire, tandis que les auto-évaluations de niveau 1 doivent être renouvelées chaque année.
