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
- Le guide du programme fédéral de gestion des risques et des autorisations (FedRAMP), révision 5 (Rev5), impose aux prestataires de mettre en ligne chaque mois un plan d'action et un calendrier actualisés.
- Les règles consolidées du programme FedRAMP pour 2026 fixent au 7 décembre 2026 la date d'entrée en vigueur des nouvelles règles relatives aux vulnérabilités, la période de grâce prenant fin le 7 mars 2027.
- Une anomalie non corrigée figure dans les rapports mensuels du prestataire jusqu'à ce qu'elle soit résolue, et la réglementation de 2026 exige qu'elle soit classée comme « vulnérabilité acceptée » si elle n'est pas entièrement atténuée ou corrigée dans les 192 jours suivant son évaluation.
- Les images de base, les dépendances épinglées et les composants abandonnés font réapparaître sans cesse les mêmes problèmes liés à l'open source, jusqu'à ce que quelqu'un modifie la configuration de compilation.
- Une équipe chargée de la plateforme peut planifier les mises à jour des images de base, analyser les problèmes récurrents et décider rapidement des mesures à prendre concernant les composants pour lesquels aucun correctif n'est disponible en amont.
La surveillance continue (ConMon) du programme FedRAMP impose aux fournisseurs de services cloud de transmettre chaque mois un plan d’action et un calendrier de jalons (POA&M) mis à jour. Chaque vulnérabilité distincte fait l’objet d’une rubrique spécifique dans ce document. Si un composant de votre version présente encore un problème non résolu, celui-ci a tendance à figurer à nouveau dans le POA&M du mois suivant. Il s’agit de la voie « Révision 5 » (Rev5) décrite dans le guide de surveillance continue (Continuous Monitoring Playbook) du programme FedRAMP (Federal Risk and Authorization Management Program).
Une non-conformité qui revient chaque mois remet le même choix open source sur la table des évaluateurs, et c’est ce que le titre entend par « remettre en cause ». Dans le cadre du parcours Rev5, le guide orientent les réunions ConMon inter-agences vers les éléments en retard, les dépendances vis-à-vis des fournisseurs et tout ce qui nécessite une acceptation des risques. Les évaluateurs valident également les demandes de dérogation et les dépendances vis-à-vis des fournisseurs lors de chaque évaluation annuelle. En vertu des règles FedRAMP de 2026, un constat qui n’est toujours pas entièrement atténué ou corrigé 192 jours après l’évaluation doit être qualifié de « vulnérabilité acceptée », accompagné d’une explication écrite justifiant ce choix. À partir de 2027, chaque agence cliente recevra également chaque trimestre un récapitulatif des vulnérabilités acceptées.
Les règles FedRAMP de 2026 stipulent également que les prestataires doivent concevoir leurs services de manière à réduire par défaut les risques liés aux vulnérabilités. Pour les composants open source, cela implique de choisir les éléments qui composent votre version, et c'est à votre équipe chargée de la plateforme qu'il revient de faire ces choix.
Fonctionnement de la surveillance continue FedRAMP, mois après mois
Dans le cadre du parcours Rev5 (Playbook version 1.0, 17 novembre 2025), le prestataire analyse les systèmes d’exploitation, les applications web et les bases de données au moins une fois par mois. Il télécharge ensuite le POA&M et l’inventaire mis à jour, ainsi que les fichiers bruts d’analyse lorsque ses contrats avec les agences l’exigent. Le responsable habilité de l’agence examine le POA&M et approuve les demandes de dérogation, qui invitent l’agence à traiter un résultat comme un faux positif, un ajustement de risque ou une exigence opérationnelle.
Les règles consolidées du FedRAMP pour 2026 (CR26) ont été publiées le 24 juin 2026. Deux de leurs ensembles de règles, « Détection et réponse aux vulnérabilités » et « Évaluation et signalement des vulnérabilités », couvrent les classes B à D de la version Rev5 ainsi que les classes B et C de la version 20x, le nouveau parcours de certification du FedRAMP. Certains délais dépendent à la fois du parcours et de la classe. La phase d’adoption anticipée a débuté le 4 juillet 2026. Les nouveaux candidats doivent se conformer à ces ensembles de règles à compter du 7 décembre 2026. Les prestataires existants doivent les adopter d’ici cette date, sous peine de se voir imposer un plan d’actions correctives. Le 7 mars 2027, le délai de grâce prendra fin et FedRAMP révoquera la certification des prestataires qui ne se seront pas conformés.
| Article | Guide Rev5 v1.0 | Règles relatives à la vulnérabilité CR26, à compter du 15 octobre 2026 | Base |
|---|---|---|---|
| Numérisation et vérification | Les systèmes d'exploitation, les applications Web et les bases de données font l'objet d'une analyse au moins une fois par mois. | Les prestataires de classe C et D Rev5 doivent vérifier et valider les ressources matérielles au moins une fois par mois (les prestataires de classe B devraient en faire de même). Les prestataires de classe C 20x doivent le faire tous les trois jours. | Exigences FedRAMP |
| Rapport mensuel | Mise à jour du POA&M et de l'inventaire | L'activité liée aux vulnérabilités est consignée au moins une fois par mois, dans un format cohérent et lisible par l'utilisateur. Les rapports résument également l'ensemble de l'activité enregistrée depuis le rapport précédent (Rev5, classes B à D). | Exigences FedRAMP |
| Résultats non corrigés | Ces éléments sont suivis dans le cadre des postes POA&M. Les demandes de dérogation doivent être approuvées par l'agence. | Elle doit être classée comme « vulnérabilité acceptée », accompagnée d'une explication, si elle n'est pas, ou ne sera pas, entièrement atténuée ou corrigée dans les 192 jours suivant son évaluation. | Consignes du guide pratique fournies par le bureau du programme ; exigence CR26 (OBLIGATOIRE) |
Que deviennent les conclusions non tranchées après le premier rapport ?
Dans le cadre du processus Rev5, un constat non résolu est suivi dans le POA&M avec un plan de correction, et le prestataire peut déposer une demande de dérogation qui sera soumise à la décision de l'agence. Un élément du POA&M qui dépend d'un fournisseur en amont est suivi en tant que dépendance vis-à-vis du fournisseur.
Pour un prestataire comptant plusieurs agences parmi ses clients, le guide prévoit une réunion mensuelle collaborative ConMon. Il précise qu’il n’est pas réaliste d’aborder tous les points du POA&M, en particulier ceux que le prestataire prévoit de résoudre dans les délais fixés par le FedRAMP. La discussion doit se concentrer sur les points en retard, les dépendances vis-à-vis des fournisseurs et les demandes de dérogation, notamment celles nécessitant une acceptation des risques. Ainsi, tout constat restant en suspens au-delà de sa date d’échéance doit être porté à l’attention de chaque administration du groupe.
Extrait des règles consolidées du programme FedRAMP pour 2026 : FedRAMP recommande aux agences de n’examiner que les vulnérabilités en retard et acceptées dont la note « N » (impact potentiel sur l’agence) est supérieure à 2, sauf si le prestataire recommande des mesures d’atténuation ou si le service fait partie d’un système fédéral à risque élevé. La note N, allant de N0 à N5, correspond à l’estimation par le fournisseur de l’ampleur des dommages qu’une exploitation pourrait causer aux agences utilisant le service. Les vulnérabilités acceptées ne doivent généralement être examinées que lorsqu’elles sont ajoutées ou lorsque l’utilisation qu’en fait l’agence change.
Les règles de 2026 limitent également la durée pendant laquelle un prestataire peut laisser une faille en suspens tout en prévoyant de la corriger. Il doit classer toute vulnérabilité qui n’est pas, ou ne sera pas, entièrement atténuée ou corrigée dans les 192 jours suivant son évaluation comme une vulnérabilité acceptée. À partir de ce moment-là, chaque rapport mensuel explique pourquoi, précise si la vulnérabilité est accessible depuis Internet, si elle est susceptible d’être exploitée, et indique son niveau de gravité N actuel.
| Résultat | Ce que prévoient les règles | Base |
|---|---|---|
| Atténuation partielle | Cela permet de réduire le risque sans pour autant éliminer la vulnérabilité. Lorsqu'il n'est pas possible de mettre en œuvre une atténuation ou une correction complète, les prestataires doivent agir rapidement, de manière progressive et avec persévérance. | Note d'orientation FedRAMP (RECOMMANDÉ) |
| Atténuation totale | Réduit le risque à un niveau négligeable, mais la vulnérabilité persiste tant qu'elle n'a pas été corrigée. | Note d'orientation FedRAMP |
| Assainissement | Élimine complètement la vulnérabilité. | Note d'orientation FedRAMP |
| Vulnérabilité confirmée | Étiquette attribuée à une vulnérabilité que le fournisseur n'a pas l'intention d'atténuer ou de corriger entièrement. Obligatoire dès lors qu'une vulnérabilité n'est pas, ou ne sera pas, entièrement atténuée ou corrigée dans les 192 jours suivant son évaluation. Le fournisseur doit en indiquer la raison. | Définition ; exigence (DOIT) |
| Faux positif | Les prestataires doivent évaluer les vulnérabilités détectées afin de déterminer s'il s'agit de faux positifs. | Recommandation (IL CONVIENDRAIT DE) |
Le fait d'accepter une constatation transfère la décision relative au risque à vos clients : chaque administration décide si elle souhaite continuer à utiliser le service alors que la constatation est toujours en suspens, et FedRAMP demande aux administrations de consigner cette décision dans leur propre POA&M.
Pourquoi les mêmes conclusions sur l'open source reviennent sans cesse sur le tapis ?
Pour les systèmes conteneurisés, le Playbook exige un identifiant unique pour chaque classe d’image de conteneur et relie chaque conteneur de production à son image source. Il stipule également que l’application des correctifs logiciels doit s’effectuer sur l’image de remplacement, et jamais directement sur l’environnement de production. Ainsi, un paquet vulnérable présent dans une image de base a tendance à apparaître dans tous les conteneurs construits à partir de celle-ci, et la solution habituelle consiste à construire une nouvelle image. Tant qu’aucun rebasage n’est effectué, l’ensemble des paquets reste généralement inchangé, et la vulnérabilité persiste.
Les dépendances « épinglées » fonctionnent de la même manière. Un fichier de verrouillage maintient une bibliothèque à la version que vous avez choisie ; ainsi, une bibliothèque faisant l’objet d’un avis de sécurité reste à cette version jusqu’à ce que quelqu’un la modifie. Pour un composant activement maintenu, la solution consiste à utiliser une version corrigée fournie par l’amont, que quelqu’un intègre ensuite à votre build. La mise à jour comporte ses propres risques, comme l’explique notre article intitulé « Pourquoi “se contenter de mettre à jour” est un mauvais conseil en matière de sécurité ».
Lorsque le développeur en amont cesse d’assurer la maintenance d’un composant, de nouvelles vulnérabilités peuvent encore être signalées, mais aucune version corrigée n’est généralement publiée. La vulnérabilité reste alors ouverte jusqu’à ce que le composant soit remplacé ou que quelqu’un corrige la version que vous utilisez, même après que le délai de 192 jours a imposé le statut « acceptée ». Un service utilise rarement un seul langage de programmation ; ainsi, les composants abandonnés peuvent s’accumuler simultanément dans plusieurs écosystèmes.
Ce que les scanners ne vous disent pas à propos d'un colis
Les résultats de l'analyse s'appuient sur des vulnérabilités connues. Le « Playbook » exige que les résultats lisibles par machine comportent le numéro de référence CVE (Common Vulnerabilities and Exposures) pour toute vulnérabilité répertoriée dans la base de données nationale des vulnérabilités (National Vulnerability Database). Les règles de 2026 précisent que les anciennes directives FedRAMP se concentraient généralement sur les vulnérabilités de type CVE et ne traitaient pas les autres types ; la règle de détection mentionne la surveillance de la chaîne d'approvisionnement parmi les techniques utilisées par les prestataires.
Les scanners et autres outils de surveillance continue FedRAMP utilisés par un fournisseur fournissent des rapports sur le contenu de la version. Un paquet qui a été altéré ou compilé à partir d’une source autre que sa source publique peut ne pas apparaître comme un résultat CVE, et un paquet malveillant peut ne comporter aucun identifiant CVE. Une nomenclature logicielle (SBOM) présente le même angle mort : un composant peut être répertorié avec exactitude tout en ayant été altéré. Ces deux éléments décrivent ce qui est présent, mais aucun ne précise si cela aurait dû l’être.
Ce que l'ingénierie des plateformes peut changer d'ici le prochain rapport
Si vous êtes responsable de la version sous-jacente à un cycle de surveillance continue FedRAMP, vous pouvez modifier le contenu du prochain rapport en modifiant les éléments inclus dans cette version.
Extrait des règles consolidées du programme FedRAMP pour 2026 : les prestataires doivent évaluer les vulnérabilités par groupes logiques de ressources concernées ; les règles de détection et de réponse du programme FedRAMP s'appliquent alors à chaque groupe plutôt qu'à chaque instance.
Commencez par planifier les mises à jour des images de base. Planifiez-les de manière à ce que les images reconstruites soient en production avant votre analyse mensuelle, afin que toute correction apportée à l'image de base mise à jour apparaisse dans le rapport suivant. Conformément à la règle de regroupement, un paquet vulnérable présent dans une seule image de base peut être considéré comme un seul regroupement, même s'il apparaît dans plusieurs conteneurs.
Évaluez le nombre de non-conformités récurrentes avant de plaider en faveur de leur correction. Prenez vos trois derniers rapports et comptez les non-conformités qui apparaissent dans chacun d’entre eux. Cela donne une idée approximative de la part de travail mensuel qui relève des non-conformités reportées et fournit à celui qui finance les travaux des éléments sur lesquels s’appuyer pour agir. Ensuite, classez séparément les non-conformités récurrentes et les nouvelles avant de procéder au triage, car les nouvelles nécessitent un nouvel examen et risquent d’être négligées parmi les éléments déjà connus.
Lorsqu'un composant ne bénéficie d'aucun correctif en amont, décidez avant l'échéance des 192 jours s'il convient de le remplacer, d'appliquer un correctif à la version que vous utilisez ou d'accepter la vulnérabilité.
Veillez à inclure les dépendances transitives dans votre inventaire de paquets, car les paquets que vous avez sélectionnés directement ne constituent qu'une partie de ce qui est livré.
Les problèmes qui reviennent sans cesse trouvent leur origine dans la compilation, et c'est en modifiant cette dernière qu'on parvient à les résoudre.
La place de SecureChain dans le cycle de vie des paquets
SecureChain est le produit de TuxCare destiné aux paquets open source présents dans votre build. Pour les paquets qu’il couvre, il les recompile à partir du code source dans des environnements verrouillés et isolés, puis les analyse à la recherche de logiciels malveillants et de code suspect, empêchant ainsi tout élément non conforme d’atteindre votre environnement. Chaque paquet est accompagné d’une attestation de provenance SLSA de niveau 3, d’une SBOM et d’une déclaration VEX. Les paquets encore maintenus font l’objet d’une surveillance des nouvelles vulnérabilités (CVE) et sont corrigés dans le cadre d’un accord de niveau de service. Lorsque les responsables de la maintenance en amont cessent leurs activités, TuxCare effectue le portage des correctifs critiques et à haut niveau de gravité vers les versions exactes que vous utilisez. La couverture s’étend à JavaScript, Python, Java, Go et PHP.
Si votre rapport mensuel continue de signaler des composants pour lesquels les correctifs ne sont plus fournis en amont, consultez la liste des éléments couverts par SecureChain.
FAQ
Qu'est-ce que le ConMon dans le cadre du programme FedRAMP, et quelles informations sont communiquées chaque mois ?
Dans le cadre du FedRAMP, le programme fédéral américain d’autorisation des services cloud, la surveillance continue (ConMon) couvre les rapports de sécurité réguliers fournis par un prestataire une fois que son service a été autorisé. Dans le cadre du parcours de la révision 5 (Rev5), les prestataires de services cloud analysent chaque mois leurs systèmes d’exploitation, leurs applications web et leurs bases de données, puis transmettent un plan d’action et un calendrier (POA&M) actualisés ainsi qu’un inventaire, conformément au guide de surveillance continue (version 1.0).
Les fournisseurs Rev5 et 20x signalent-ils les vulnérabilités de la même manière ?
En vertu de son règlement consolidé pour 2026, le programme FedRAMP exige des prestataires de la révision 5 (Rev5) et des prestataires 20x de classes B et C qu’ils signalent les activités liées aux vulnérabilités au moins une fois par mois et qu’ils classent comme « acceptées » toutes les vulnérabilités qui n’ont pas été entièrement atténuées ou corrigées dans les 192 jours suivant leur évaluation. La fréquence des vérifications varie selon la voie et la classe. Les prestataires Rev5 de classe C doivent vérifier et valider les ressources matérielles au moins une fois par mois, tandis que les prestataires 20x de classe C doivent le faire tous les 3 jours.
Qu'est-ce qu'une vulnérabilité acceptée dans le cadre du programme FedRAMP ?
En vertu de ses règles de 2026, le programme FedRAMP considère qu’une vulnérabilité est « acceptée » lorsque le prestataire n’a pas l’intention de la corriger ou de la remédier entièrement. Cette mention est également requise dès lors qu’une vulnérabilité n’est pas, ou ne sera pas, entièrement corrigée ou remédiée dans les 192 jours suivant son évaluation. Les prestataires doivent justifier pourquoi chaque vulnérabilité est acceptée, en précisant son accessibilité depuis Internet, son exploitabilité probable et son impact estimé sur l’agence.
Qu'est-ce qu'une demande de dérogation dans le cadre du programme FedRAMP ?
Dans le cadre du programme FedRAMP, un prestataire de niveau 5 (Rev5) peut déposer une demande de dérogation afin de demander à l’agence de considérer un constat comme un faux positif, un ajustement de risque ou une exigence opérationnelle. Le guide de surveillance continue précise que les agences approuvent ces demandes et que les évaluateurs les valident lors de l’évaluation annuelle.
Les analyses FedRAMP distinguent-elles les paquets open source des autres logiciels ?
FedRAMP ne classe pas les résultats en fonction de leur statut « open source » dans le « Continuous Monitoring Playbook » ni dans les règles de vulnérabilité de 2026. Le « Playbook » associe les résultats aux actifs de l'inventaire et aux images de conteneurs, tandis que la règle de détection de 2026 mentionne la surveillance de la chaîne d'approvisionnement comme technique. Pour remonter à l'origine d'un résultat, vous devez mener votre propre analyse.
Quand les règles de FedRAMP relatives aux vulnérabilités pour 2026 entreront-elles en vigueur ?
Le 4 juillet 2026, FedRAMP a ouvert la possibilité d'adopter, à titre facultatif, ses règles de 2026 relatives aux vulnérabilités. Les nouveaux candidats devront s'y conformer à compter du 7 décembre 2026. Les prestataires existants sont invités à les adopter d'ici là et devront s'y conformer au plus tard le 7 mars 2027, faute de quoi FedRAMP révoquera leur certification.
