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
- FedRAMP 20x est désormais opérationnel pour les classes A, B et C, et les règles de 2026 entreront en vigueur le 1er janvier 2027.
- Un indicateur clé de sécurité décrit la surveillance automatique des logiciels tiers afin de détecter les vulnérabilités en amont, à l'aide de méthodes telles que les notifications contractuelles.
- Les indicateurs clés de sécurité ne mentionnent jamais les dépendances ni les listes de composants logiciels ; le périmètre découle donc des définitions des règles.
- L'identification des vulnérabilités est une exigence, tandis que les délais de correction pour les vulnérabilités de classe C constituent des recommandations dont les prestataires peuvent s'écarter à condition de justifier leur décision par écrit.
FedRAMP 20x considère un document de sécurité obsolète comme une vulnérabilité. Conformément aux règles de détection des vulnérabilités du Programme fédéral de gestion des risques et des autorisations (FedRAMP), une déclaration de contrôle obsolète figurant dans le « Security Decision Record » (SDR) d’un prestataire — qui a remplacé le « System Security Plan » — est détectée et corrigée comme n’importe quelle autre faille.
Si la documentation doit s’adapter au système, il en va de même pour les logiciels qui le composent, y compris le code que vous n’avez pas écrit. Les logiciels tiers exécutés au sein d’une offre de services cloud relèvent du champ d’application de la norme 20x, même si les indicateurs clés de sécurité (KSI) n’utilisent jamais le terme «dépendances ».Les règles y parviennent en définissant ce qu’est une offre de services cloud, et certains KSI mentionnent directement les logiciels tiers et les risques liés à la chaîne d’approvisionnement.
Ce que la norme FedRAMP 20x change pour les fournisseurs de services cloud
FedRAMP, le programme fédéral qui normalise l'évaluation de la sécurité des services cloud, relève de l'Administration des services généraux (GSA). Ce que 20x change, c'est la provenance des preuves. Les fournisseurs étayent désormais leurs affirmations par des preuves qu'un système peut valider automatiquement, au lieu de longs documents écrits que des personnes examinent manuellement.
FedRAMP a également modifié sa terminologie. Le programme qualifie désormais le résultat de « certification » plutôt que d’« autorisation ». FedRAMP certifie l’offre, et chaque administration continue de prendre sa propre décision quant à l’autorisation d’utilisation.
État d'avancement du programme FedRAMP 20x à l'issue de la phase pilote
Le projet pilote FedRAMP 20x s'est déroulé en deux phases. La phase 1, une démonstration de faisabilité à faible impact, s'est déroulée d'avril à septembre 2025. La phase 2, de niveau « modéré », a été testée de novembre 2025 à mars 2026, et les premières autorisations dans le cadre de ce projet pilote de niveau « modéré » ont été délivrées le 6 mars 2026. Les deux phases pilotes sont désormais terminées, et le programme en est à sa phase 3, celle du déploiement à grande échelle.
Ces projets pilotes ont été intégrés dans les « Règles consolidées pour 2026 » (CR26). Les dernières actualités concernant le programme FedRAMP 20x sont principalement d’ordre administratif, puisque le journal des modifications des règles fait état de précisions et de légers ajustements jusqu’au 8 octobre 2026.
Si vous cherchiez la certification FedRAMP 20x « Modérée », sachez que son nom actuel est « Classe C ». La certification « Faible » s'appelle désormais « Classe B » et la certification « Élevée » « Classe D ». La « Classe A » est une nouvelle certification, qui constitue un point d'entrée pour les prestataires disposant de programmes de sécurité aboutis et souhaitant accéder au marché fédéral. Le parcours 20x est ouvert aux Classes A, B et C.
La révision 5 (Rev5), l'ancienne procédure, suit un calendrier précis. Voici les dates à retenir.
| Date | Étape importante |
|---|---|
| Mai 4, 2026 | Publication de la version d'aperçu public de CR26 |
| Juillet 4, 2026 | La mise en œuvre anticipée facultative débute, avec des dates d'entrée en vigueur qui varient selon le référentiel réglementaire |
| Août 31, 2026 | Mise en service des pipelines de classe B et C |
| Janvier 1, 2027 | Date d'entrée en vigueur générale pour les règles de 2026. Certaines séries de règles s'appliquent plus tôt, comme les règles relatives aux vulnérabilités qui entreront en vigueur le 7 décembre 2026, tandis que certaines dates de grâce de la Rev5 sont reportées à une date ultérieure. |
| Premier semestre de l'exercice 2027 (d'octobre 2026 à mars 2027) | Pilote de classe D (titulaire d'une licence provisoire) |
| Juin 11, 2027 | FedRAMP ne reçoit plus de nouvelles certifications Rev5 |
| Au plus tard le 31 décembre 2028 | Les certifications Rev5 existantes restent valides, sauf indication contraire de la part du FedRAMP. |
Fonctionnement des KSI 20x du programme FedRAMP
Un indicateur KSI 20x du programme FedRAMP définit une capacité de sécurité, telle que la journalisation des modifications apportées au service ou la surveillance des logiciels tiers à la recherche de vulnérabilités en amont. Ces indicateurs répertorient généralement les contrôles associés issus de la publication spéciale 800-53 du National Institute of Standards and Technology (NIST), un catalogue de contrôles de sécurité largement utilisé, de sorte qu’ils s’inscrivent dans un cadre existant.
Vous pouvez également découvrir comment ces référentiels s'harmonisent au sein du secteur dans notre guide consacré aux principales normes de sécurité dans le cloud.
FedRAMP regroupe les KSI par thèmes. La liste actuelle comprend notamment la gestion du changement, la gestion des identités et des accès, la réponse aux incidents, la planification de la reprise après sinistre, les politiques et l'inventaire, la configuration des services et les risques liés à la chaîne d'approvisionnement.
Les prestataires vérifient ces indicateurs de manière persistante. FedRAMP définit cette notion comme une répétition fréquente selon des cycles, des interruptions étant autorisées si elles sont intentionnelles et documentées ; cela ne signifie donc pas une vérification strictement continue. Les chiffres les plus précis proviennent des règles relatives aux vulnérabilités, qui ont leur propre date de début. Les prestataires de classe C doivent vérifier et valider l’état des ressources informatiques, telles que les logiciels, le matériel et les services cloud, au moins tous les trois jours. Les ressources qui ne fonctionnent pas sur des ordinateurs, comme les politiques et les procédures du personnel, font l’objet d’une vérification au moins tous les trois mois.
Le « Security Decision Record » (SDR) est un registre continu des décisions prises par un prestataire en matière de sécurité, et FedRAMP exige qu’il soit tenu à jour, vérifié et validé de manière permanente. Les « évaluateurs » — terme désormais utilisé par FedRAMP à la place d’« organismes d’évaluation tiers » (3PAO) — examinent généralement les éléments justificatifs qui le sous-tendent, FedRAMP jouant le rôle d’évaluateur final.
Certains de ces indicateurs concernent les logiciels que vous utilisez.
Interactions entre les KSI et les logiciels tiers
Le champ d’application joue ici un rôle prépondérant. Les prestataires doivent identifier toutes les ressources d’information susceptibles de traiter des données de clients fédéraux ou d’affecter leur confidentialité, leur intégrité ou leur disponibilité ; cet ensemble constitue l’offre de services cloud. Le programme FedRAMP définit la notion de « ressource d’information » de manière suffisamment large pour inclure les logiciels, le code, le matériel et les services cloud. Cela couvre donc le code tiers s’exécutant au sein de l’offre, qu’une règle le mentionne ou non.
À partir de là, les indicateurs deviennent plus précis. Trois d'entre eux traitent directement des logiciels tiers et des risques liés à la chaîne d'approvisionnement, tandis que deux autres portent sur les stocks et les contrôles d'intégrité de l'ensemble de l'offre, y compris les logiciels.
| KSI | Thème | Ce que cela décrit |
|---|---|---|
| KSI-SCR-MON | Risques liés à la chaîne d'approvisionnement | Les logiciels tiers font l'objet d'une surveillance automatique visant à détecter les vulnérabilités en amont, grâce à des méthodes pouvant inclure des notifications contractuelles ou des services de surveillance active. |
| KSI-SCR-MIT | Risques liés à la chaîne d'approvisionnement | Les risques liés à la chaîne d'approvisionnement font l'objet d'une identification, d'un examen et d'une atténuation permanents |
| KSI-CNA-IBP | Architecture native du cloud | L'utilisation et la configuration des ressources matérielles tierces font l'objet d'une comparaison constante avec les bonnes pratiques et les recommandations du fournisseur d'origine. |
| KSI-PIY-GIV | Politique et inventaire | Répertoires de ressources d'information générés automatiquement à partir de sources faisant autorité |
| KSI-SVC-VRI | Configuration du service | Méthodes cryptographiques utilisées pour vérifier l'intégrité des ressources matérielles |
La règle de détection des vulnérabilités mentionne également la surveillance de la chaîne d’approvisionnement comme l’une des techniques utilisées par les prestataires pour identifier les faiblesses. Aucune des KSI n’utilise les termes « dépendance », « open source », « paquet » ou « SBOM ». À première vue, une bibliothèque tierce s’exécutant au sein de votre service est considérée comme un logiciel tiers au sens de la KSI-SCR-MON. Ce que les règles ne précisent pas, c’est le niveau de granularité requis pour la surveillance ni la nature des preuves susceptibles de satisfaire un évaluateur, et c’est là qu’intervient l’interprétation.
Source : la mesure de contrôle SA-22, « Composants système non pris en charge », correspond à la norme KSI-SCR-MIT. Elle prévoit le remplacement des composants dès que le développeur, le fournisseur ou le fabricant cesse de les prendre en charge, ou la mise en place de sources alternatives pour assurer la continuité de la prise en charge. Elle fait déjà partie des exigences de base de la version 5 du programme FedRAMP pour les classes B, C et D.
Ajoutez la clause SA-22 à côté des définitions du périmètre d'application ; l'exigence selon laquelle vous devez remplacer les composants non pris en charge ou prendre les dispositions nécessaires pour assurer la continuité de leur prise en charge n'est pas nouvelle. Dans le cadre de la version 20x, les preuves attestant que vous avez géré les composants non pris en charge doivent provenir d'une validation automatisée, et non d'une explication écrite.
Ce que les règles imposent et ce qu'elles laissent à l'appréciation
Les exigences du programme FedRAMP 20x en matière de vulnérabilités se déclinent en deux niveaux de rigueur, « MUST » et « SHOULD », que FedRAMP définit tous deux. « MUST » correspond à une exigence absolue. « SHOULD » signifie qu'un prestataire peut avoir des raisons valables de s'en écarter, mais qu'il doit alors évaluer les implications et justifier sa décision dans sa documentation relative à la sécurité.
La détection et la gestion des vulnérabilités font clairement partie des obligations incontournables. Les fournisseurs doivent identifier de manière systématique, continue et rapide les vulnérabilités présentes dans leurs offres, puis les suivre, les évaluer, les atténuer et y remédier.
Le délai est l’élément flexible. Pour la classe C, les délais de mitigation ou de correction relèvent du niveau « SHOULD ». Ils dépendent de l’impact potentiel d’une vulnérabilité sur les agences, de son accessibilité depuis Internet et de la probabilité qu’elle soit exploitée ; ils vont de 2 jours à l’extrémité « grave » du tableau à 192 jours à l’autre extrémité. Les fournisseurs doivent également remédier aux vulnérabilités connues pour être exploitées (KEV) avant les dates limites indiquées dans le catalogue de la Cybersecurity and Infrastructure Security Agency (CISA), même si une vulnérabilité a déjà été entièrement atténuée, et doivent éviter de déployer de nouvelles ressources matérielles qui en comportent déjà une. Dans la pratique, cela implique une obligation stricte de détecter les vulnérabilités dans le code tiers, les délais de correction étant fixés par défaut et ne pouvant être modifiés qu’avec des justifications documentées.
Le langage KEV trouve son origine dans la directive opérationnelle contraignante (BOD) n° 26-04, publiée par la CISA le 10 juin 2026. Il s'applique directement aux agences civiles fédérales du pouvoir exécutif, qui doivent passer par le programme FedRAMP pour s'assurer que leurs offres de services cloud sont conformes aux exigences de ce programme.
Les règles relatives à la détection et à la gestion des vulnérabilités s’appliquent selon leur propre calendrier. Les prestataires qui obtiennent ou conservent une certification sont tenus de les respecter à compter du 7 décembre 2026, avec une période de grâce allant jusqu’au 7 mars 2027. Cette date est antérieure à celle du 1er janvier 2027 prévue pour l’application générale de ces règles.
Préparez-vous dès maintenant à la conformité à la norme FedRAMP 20x
Les candidats qui postulent pour la première fois et les titulaires actuels d’une certification Rev5 ne sont pas soumis aux mêmes exigences de conformité FedRAMP 20x. Si vous visez une première certification, les nouvelles certifications Rev5 prendront fin le 11 juin 2027 ; la certification 20x est donc l’objectif le plus probable, à moins que vous n’ayez besoin de la classe D, qui n’est pour l’instant couverte que par la Rev5. Si vous êtes déjà titulaire d’une certification Rev5, les dates limites varient en fonction du référentiel, et FedRAMP a récemment repoussé certaines dates de grâce pour la Rev5 jusqu’au 13 septembre 2026 ; consultez donc la page des dates limites pour connaître la vôtre.
Pour les logiciels tiers, commencez par l’inventaire. KSI-PIY-GIV, l’indicateur d’inventaire, prévoit que les inventaires soient générés automatiquement à partir de sources faisant autorité chaque fois que cela est nécessaire ; la nomenclature logicielle produite lors de votre compilation peut constituer une source potentielle. Associez-y une surveillance couvrant les paquets transitifs, c’est-à-dire ceux qui sont intégrés par d’autres paquets, ainsi que ceux que vous avez sélectionnés délibérément, car ce sont ceux-là dont on perd le plus facilement la trace.
La définition des risques liés à la chaîne d'approvisionnement donnée par KSI-SCR-MIT semble également aller au-delà des vulnérabilités connues ; il convient donc d'intégrer dans le plan une évaluation des risques liés aux éléments livrés sur site.
Remarque : en vertu des règles relatives au périmètre d’évaluation minimal (Minimum Assessment Scope), lorsque la règle d’identification du périmètre s’applique, chaque ressource d’information tierce concernée doit faire l’objet d’une documentation relative à son utilisation et à sa configuration, d’une justification, de mesures d’atténuation et de contrôles compensatoires. FedRAMP définit ce terme comme toute ressource d’information qui n’est pas entièrement incluse dans le périmètre d’évaluation minimal de l’offre de service cloud, comme un service externe. Une bibliothèque intégrée à votre propre service relèverait en revanche normalement de ce périmètre. La norme KSI-SCR-MON couvre les « ressources d’information logicielles tierces », une notion plus large que le terme défini de « ressource d’information tierce » et qui englobe le code tiers s’exécutant au sein de votre propre service.
Examinez ensuite les composants pour lesquels la prise en charge a pris fin. Les composants qui n'ont pas de responsable de maintenance en amont ont tendance à ne pas bénéficier de correctifs, et on conseille généralement d'augmenter le numéro de version ; toutefois, la mise à niveau n'est pas toujours une solution sûre, il faut donc envisager un remplacement ou un correctif rétroporté.
Les outils FedRAMP 20x de gouvernance, de gestion des risques et de conformité (GRC) font également partie du tableau. Lors de la phase 1 du projet pilote, les fournisseurs de solutions GRC représentaient la plus grande part des demandes, cherchant à obtenir la certification de leurs propres produits. Quel que soit l’outil que vous choisissiez, les données probantes proviennent toujours de vos propres systèmes et sont validées selon le calendrier fixé par la réglementation.
Sachez ce qui se passe avant même qu’un évaluateur ne vous pose la question
Tôt ou tard, un évaluateur vous demandera probablement quels paquets tiers votre service utilise et qui se charge de les mettre à jour lorsque le support en amont prend fin. C'est une question délicate lorsque certains de ces paquets ont été installés via d'autres paquets, ou lorsque leurs responsables de maintenance ont changé d'activité.
SecureChain est un moyen de réduire cet écart. Pour les paquets qu’il couvre, TuxCare recompose chacun d’entre eux à partir du code source dans un environnement sécurisé et isolé, les analyse à la recherche de logiciels malveillants cachés et de code suspect avant qu’ils n’atteignent votre environnement, et applique les correctifs pour les nouvelles vulnérabilités CVE dans le cadre d’un SLA. Lorsque les responsables de maintenance en amont cessent de fournir des correctifs, le service « Endless Lifecycle Support » prend le relais pour continuer à appliquer les correctifs. La couverture s’étend à JavaScript, Python, Java, Go, Rust et PHP, et les versions compilées incluent une provenance SLSA de niveau 3, des SBOM et des enregistrements VEX.
Si vous n'êtes pas en mesure aujourd'hui de citer les bibliothèques tierces utilisées par votre service, ou d'expliquer ce qui se passe lorsqu'une d'entre elles ne bénéficie plus du soutien de son développeur d'origine, c'est ce problème qu'il faut résoudre en priorité.
FAQ
Qu'est-ce que FedRAMP 20x ?
Le programme fédéral de gestion des risques et des autorisations (FedRAMP) est le programme standardisé d'évaluation de la sécurité des services cloud mis en place par le gouvernement fédéral. FedRAMP 20x est son nouveau parcours de certification, qui remplace les examens nécessitant une grande quantité de documents par une validation automatisée et des preuves lisibles par machine. Il est ouvert aux nouvelles demandes de certification, et un projet pilote « à fort impact » est prévu pour une phase ultérieure.
Que sont les KSI FedRAMP 20x ?
Les indicateurs clés de sécurité (KSI) sont des déclarations relatives aux capacités de sécurité qu’un fournisseur de services cloud doit démontrer dans le cadre de la voie 20x du Programme fédéral de gestion des risques et des autorisations (FedRAMP). Ils sont regroupés par thèmes, tels que la gestion du changement et les risques liés à la chaîne d’approvisionnement, et énumèrent généralement les contrôles de sécurité fédéraux auxquels ils se rapportent. Le FedRAMP préconise une validation automatisée dans la mesure du possible.
Existe-t-il un niveau « modéré » dans le cadre du programme FedRAMP 20x ?
Ce n'est plus sous ce nom. Le programme fédéral de gestion des risques et des autorisations (FedRAMP) a remplacé ses niveaux d'impact « Faible », « Modéré » et « Élevé » par des certifications de classe B, C et D ; ainsi, le niveau « Modéré » correspond désormais à la classe C. La classe C est accessible via la nouvelle voie « 20x » du FedRAMP, tandis que la classe D devrait faire l'objet d'un projet pilote ultérieur.
Où en est le projet pilote FedRAMP 20x ?
Les deux phases pilotes du programme « 20x », la nouvelle voie du Programme fédéral de gestion des risques et des autorisations (FedRAMP), sont désormais achevées. La phase 1 a porté sur le niveau « faible impact » en 2025, et la phase 2 sur le niveau « modéré » de novembre 2025 à mars 2026. Le FedRAMP en est désormais à la phase 3, celle de l’adoption à grande échelle, avec une mise en œuvre progressive des règles de 2026 et une date d’application générale obligatoire fixée au 1er janvier 2027.
Quelles sont les exigences du programme FedRAMP 20x en matière de vulnérabilités ?
Dans le cadre du programme fédéral de gestion des risques et des autorisations (FedRAMP), les prestataires doivent identifier les vulnérabilités de leur service cloud et y remédier. Les prestataires de classe C, correspondant à l'ancien niveau « modéré », doivent également vérifier et valider l'état de leurs ressources technologiques au moins tous les trois jours. Les délais de correction applicables à la classe C ont un caractère indicatif, et tout écart par rapport à ceux-ci doit être justifié par écrit.
Les dépendances logicielles entrent-elles dans le champ d'application du programme FedRAMP 20x ?
Les logiciels intégrés à un service cloud relèvent de ce champ d’application, y compris le code tiers, car le champ d’application du Programme fédéral de gestion des risques et des autorisations (FedRAMP) couvre toute ressource d’information susceptible de traiter des données de clients fédéraux ou d’affecter leur confidentialité, leur intégrité ou leur disponibilité. Un indicateur clé de sécurité (KSI) porte sur la surveillance des logiciels tiers afin de détecter les vulnérabilités en amont. Aucun KSI n’utilise les termes « dépendance » ou « nomenclature logicielle », mais une bibliothèque tierce intégrée au service reste une ressource d’information relevant du champ d’application et un logiciel tiers au sens du KSI-SCR-MON. Le niveau de granularité de la surveillance est laissé à l’appréciation des évaluateurs.
Que signifie « GRC » dans le cadre du programme FedRAMP 20x ?
Les outils de gouvernance, de gestion des risques et de conformité (GRC) aident les équipes à organiser leur travail de conformité et à rassembler les éléments justificatifs. Lors du premier projet pilote de la version 20x, la nouvelle voie du Programme fédéral de gestion des risques et des autorisations (FedRAMP), les fournisseurs d’outils GRC ont constitué la catégorie la plus représentée parmi les demandes, cherchant à obtenir la certification de leurs propres produits. Ces outils constituent un moyen de recueillir les éléments justificatifs exigés par les règles du FedRAMP.
