Principaux enseignements
- Les prestataires Rev5 conservent l'ancien système POA&M jusqu'à ce qu'ils adoptent les règles FedRAMP de 2026 relatives aux vulnérabilités, dont l'application sera obligatoire à compter du 7 décembre 2026.
- Un problème détecté par le scanner et résolu avant la date d'échéance ne nécessite aucune saisie dans l'ancien système POA&M, et un problème répertorié est clôturé dès que la preuve de sa résolution est disponible.
- Les corrections de routine apportées à la bibliothèque ne nécessitent pas l'autorisation de l'agence prévue par l'ancien « Playbook », ni la notification prévue par la réglementation de 2026.
- Un composant pour lequel un correctif a été appliqué, mais dont le scanner signale toujours l'absence de statut clair selon les définitions du programme FedRAMP pour 2026.
Si vous êtes un fournisseur de services cloud (CSP) proposant des composants open source, la correction d’une vulnérabilité peut modifier le contenu de votre plan d’action et de vos jalons (POA&M). L’ancien guide ne vous oblige pas à répertorier une vulnérabilité détectée par un scanner que vous corrigez avant la date d’échéance. Une vulnérabilité déjà répertoriée peut passer à l’état « Fermée » une fois que les mesures correctives ont été mises en œuvre et que les preuves de l’atténuation sont prêtes à être vérifiées par un tiers.
La page POA&M héritée de FedRAMP est désormais indiquée comme étant à titre de référence uniquement, et ses règles de vulnérabilité de classe C de la révision 5 (Rev5) de 2026 ne comportent aucune règle POA&M pour les prestataires. Tant que vous n’avez pas adopté ces règles, qui deviendront obligatoires le 7 décembre 2026, vous conservez l’ancienne version du POA&M. Qu’est-ce qu’un correctif change concernant le statut d’un élément, qui vérifie ce nouveau statut, et quel processus de modification s’applique, avant et après la transition ? Les réponses se trouvent dans différents documents, et aucun ne traite des correctifs rétroportés.
Un composant mis à jour respecte les règles d'admission et de clôture du programme FedRAMP, mais la documentation présente deux lacunes : la question de savoir si un responsable de maintenance open source est considéré comme un fournisseur, et quel est le statut du composant tant qu'un scanner continue de le signaler.
État actuel du programme POA&M du FedRAMP
Dans le cadre de l’ancien processus Rev5, vous conservez le POA&M dans le modèle fourni par FedRAMP. Le guide de référence associé à ce modèle, intitulé « POA&M Template Completion Guide » (version 2.2, 23 novembre 2021), décrit le POA&M comme un registre des faiblesses et des lacunes de sécurité connues du système, associé aux mesures correctives que vous prévoyez de mettre en œuvre. Vous téléchargez une copie mise à jour chaque mois dans le cadre de votre cycle de surveillance continue, et le responsable habilité (AO) de l’agence l’examine conformément au « Continuous Monitoring Playbook »(guide de surveillance continue) hérité. Depuis le 24 juin 2026, le site hérité de FedRAMP précise que sa page POA&M et son « Playbook » ne sont fournis qu’à titre de référence pendant la période de transition vers la réglementation de 2026.
Les règles du programme FedRAMP relatives à la détection et à la réponse aux vulnérabilités (VDR) ainsi qu’ à l’évaluation et au signalement des vulnérabilités (VER) ont été ouvertes à l’adoption facultative le 4 juillet 2026. Elles deviendront obligatoires pour les prestataires Rev5 le 7 décembre 2026, et la période de grâce prendra fin le 7 mars 2027. Les délais de mitigation et de correction commencent à courir dès que le prestataire évalue une vulnérabilité, et les prestataires doivent rendre compte de leurs activités de détection et de réponse aux vulnérabilités à toutes les parties concernées au moins une fois par mois.
Les règles citées ici correspondent aux versions de classe C du programme FedRAMP. Selon FedRAMP, la classe C couvre la plupart des objectifs de sécurité de niveau « faible » et « modéré » ; les prestataires certifiés en classe B ou D doivent donc vérifier les règles applicables à leur propre classe. Dans les règles de la classe C de la révision 5, la seule règle relative aux POA&M (plans d’action et jalons) est « Maintenir les plans d’action et jalons des agences » (VER-AGM-MAP), et elle s’adresse aux agences. Elle stipule que celles-ci DEVRAIENT utiliser les informations que vous leur communiquez pour maintenir les POA&M de leurs propres programmes de sécurité lorsque la politique de l’agence l’exige. FedRAMP définit « DEVRAIT » comme une règle à laquelle une partie peut déroger pour des raisons valables à condition de documenter cette décision, et « DOIT » comme une exigence absolue. Le résumé de FedRAMP concernant les modifications de 2026 indique que les POA&M « ont été entièrement supprimés ». Tout POA&M relevant des règles de 2026 est propre à l’agence, élaboré à partir de vos rapports.
Comment un article entre et sort du POA&M
Selon l’ancienne procédure, c’est le délai qui détermine si un résultat de scan est transmis au POA&M du FedRAMP dans le cadre de la surveillance continue. Vous le signalez dès qu’il est en retard (30, 90 ou 180 jours à compter de sa détection, selon la gravité). Les constatations issues d’autres sources, telles que les tests d’intrusion et les entretiens, sont répertoriées qu’elles soient ou non en retard. Il en va de même pour chaque élément faisant l’objet d’une demande de dérogation, c’est-à-dire le formulaire que vous soumettez à votre AO pour signaler un faux positif, un ajustement de risque ou une exigence opérationnelle. Une note de bas de page précise que tout accord de niveau de service ou toute préférence de l’AO reste applicable, et que l’un ou l’autre peut exiger la liste de tous les risques en suspens.
Conformément au guide, un élément peut être transféré vers la feuille de calcul « Fermé » une fois que vous avez appliqué toutes les mesures correctives et que vous disposez de « preuves d’atténuation » prêtes à être inspectées. Un organisme d’évaluation tiers (3PAO) — terme obsolète que les définitions de 2026 remplacent par « évaluateur » — vérifie ces preuves lors des évaluations initiales et périodiques, et votre AO peut les demander à tout moment. Un élément peut également y être transféré lorsque votre AO approuve une demande de dérogation pour faux positif. Les dépendances vis-à-vis des fournisseurs, qui nécessitent une correction de la part de ces derniers, et les exigences opérationnelles, que l’ ancienne page POA&M décrit comme des constatations ne pouvant faire l’objet d’une correction, restent dans la feuille de calcul « En cours ».
Remarque : le guide précédent précise que les faux positifs identifiés dans le rapport d'évaluation de sécurité (SAR), étayés par des éléments probants tels qu'un rapport d'analyse ne présentant aucun problème, ne doivent pas être inclus dans le POA&M.
| Stade | Documents historiques | Règles de 2026 | Base |
|---|---|---|---|
| Entre | Résultats de numérisation en retard. Autres résultats, qu'ils soient en retard ou non. Éléments faisant l'objet d'une demande de dérogation. | Un rapport mensuel sur les activités de détection et de réponse aux vulnérabilités, destiné à toutes les parties concernées. Aucune règle de la norme 2026 n'oblige les fournisseurs à tenir un registre POA&M. | Guide des systèmes hérités §3 ; VER-TFR-MHR et VER-RPT-VDT (2026, OBLIGATOIRE) |
| Quand aucune solution ne fonctionne | Les dépendances vis-à-vis des fournisseurs et les exigences opérationnelles restent en suspens. | Une vulnérabilité qui n'est pas, ou qui ne devrait pas être, entièrement atténuée ou corrigée dans les 192 jours suivant son évaluation est qualifiée de « vulnérabilité acceptée ». | Ancienne page POA&M (à titre indicatif uniquement) ; VER-TFR-MAV (2026, OBLIGATOIRE) |
| Fermeture | Mesures correctives mises en œuvre avec preuve d'atténuation, ou faux positif approuvé par l'AO. | Aucun statut « fermé » n'est défini. L'état final correspond à « remédié » (neutralisé ou éliminé, n'est plus détecté), avec une conclusion définitive dans le rapport. | Guide des systèmes hérités §2.2 ; Définitions 2026 ; VER-RPT-VDT (2026, OBLIGATOIRE) ; VDR-CSO-RES |
| Vérifié par | Un 3PAO, lors des évaluations initiales et périodiques. Le périmètre de l'évaluation annuelle couvre également les éléments clôturés, les dépendances vis-à-vis des fournisseurs et les demandes de dérogation. L'AO valide les faux positifs. | Les règles Rev5 relatives aux VDR et VER de classe C ne désignent personne en particulier. Une évaluation indépendante annuelle porte sur l'ensemble des règles applicables. | Guide « Legacy » §2.2 ; page « Évaluation annuelle » du programme « Legacy » ; VDR et VER (2026) ; IVV-CSO-FIA (2026, OBLIGATOIRE) |
| Conservé par | Le CSP, avec un suivi mensuel assuré par l'AO. | Les agences, pour leurs propres programmes. | Guide pratique « Legacy », aperçu général ; VER-AGM-MAP (2026, RECOMMANDÉ) |
Ce que modifie un composant corrigé
Dans cet article, un « composant corrigé » désigne une bibliothèque ou un paquet que vous déployez après qu’un responsable de maintenance, un fournisseur ou un tiers a fourni un correctif. Il ne s’agit pas d’un terme utilisé par FedRAMP.
Dans l'ancien guide, la création d'une entrée et la clôture constituent deux événements distincts. Si vous déployez un correctif avant l'expiration du délai fixé pour une vulnérabilité détectée par le scanner, le guide n'exige pas la création d'une entrée correspondante. Si l'élément figure déjà dans la liste, le correctif déployé est comptabilisé comme l'une de vos actions correctives, et la clôture suit l'une des deux procédures décrites dans le guide.
Une dépendance vis-à-vis d’un fournisseur suit un calendrier différent. L’ancienne page POA&M la lie à un fournisseur en aval, tel que le fabricant d’un produit commercial prêt à l’emploi (COTS), dont le correctif n’est pas encore disponible. Une dépendance vis-à-vis d’un fournisseur à haut risque doit tout de même être atténuée à un niveau modéré grâce à des contrôles compensatoires dans un délai de 30 jours. Une fois que le fournisseur a mis le correctif à disposition, le guide fait débuter la période de remédiation à cette date, vous demande d’enregistrer la date de publication et vous permet de remplacer la date d’achèvement prévue.
L'ancienne page POA&M recommande également de fournir des preuves des échanges avec les fournisseurs concernant l'état d'avancement des correctifs, telles que des notifications et des échanges par e-mail. Il s'agit là d'un type de preuve différent de celui des mesures d'atténuation qui permettent de clôturer un élément.
Le déploiement du correctif constitue également un changement. L’ancien Playbook classe les changements en trois catégories : les changements de routine récurrents, les changements adaptatifs et les changements transformateurs. Il classe les correctifs mineurs et incrémentiels n’entraînant pas de changements de compatibilité, y compris les correctifs de routine des bibliothèques, comme des changements de routine récurrents qui ne nécessitent ni examen ni validation par l’AO. Les mises à jour des bibliothèques comportant des changements de compatibilité connus constituent un exemple de changement adaptatif, qui, lui, nécessite un examen et une validation par l’AO.
Les règles de 2026 relatives aux notifications de changement significatif (SCN) conservent ces trois types. En vertu de la règle « Évaluation des changements » (SCN-CSO-EVA), vous devez évaluer chaque changement potentiellement significatif afin d’en déterminer le type. La règle « Absence d’obligation de notification » (SCN-RTR-NNR) stipule que les prestataires NE DOIVENT PAS envoyer de notifications formelles pour les changements récurrents de routine. FedRAMP accorde à « NE DOIT PAS » la même marge d’appréciation qu’à « DOIT ». Ses exemples incluent toujours l’application de correctifs de routine aux bibliothèques. En vertu de la règle relative aux obligations de notification (SCN-ADP-NTF), vous devez notifier tout changement adaptatif dans les 10 jours ouvrés suivant sa finalisation. Les règles SCN seront obligatoires pour les prestataires Rev5 à compter du 1er janvier 2027.
Ce que les documents laissent en suspens
La responsabilité vous incombe, quelle que soit la personne qui met en œuvre la correction. La règle relative à la gestion des vulnérabilités (VDR-CSO-RES) attribue au fournisseur la responsabilité du suivi, de l’atténuation et de la correction des vulnérabilités détectées. La règle relative à la détection des vulnérabilités (VDR-CSO-DET) mentionne la surveillance de la chaîne d’approvisionnement parmi les moyens dont dispose un fournisseur pour les détecter ; vous devez donc également détecter les vulnérabilités associées à un composant.
Lorsque l'on attend la correction d'un tiers, les documents existants indiquent le statut de dépendance vis-à-vis du fournisseur, mais ni le guide ni la page POA&M ne précisent si un responsable de maintenance open source est considéré comme un fournisseur. Si c'est le cas, une vulnérabilité en attente de correction par son responsable de maintenance peut rester ouverte, avec des vérifications mensuelles. Dans le cas contraire, elle est considérée comme en retard, comme n'importe quel autre résultat de scan. C'est là la première lacune.
Un composant corrigé dont le correctif ne modifie pas le numéro de version peut continuer à apparaître dans les résultats d'analyse après son déploiement. La documentation de Red Hat sur le « backporting » de sécurité explique pourquoi : certains outils d'analyse et d'audit déterminent si un composant est vulnérable en se basant uniquement sur son numéro de version. Ces outils signalent un composant comme vulnérable lorsqu'un correctif issu d'une version plus récente est appliqué à une version plus ancienne.
Dans les définitions du programme FedRAMP de 2026, une vulnérabilité corrigée est neutralisée ou éliminée et n’est plus détectée. Une vulnérabilité entièrement atténuée présente un risque négligeable, mais reste détectée. Un faux positif est une vulnérabilité détectée qui n’existe pas réellement et n’a jamais existé. L’ancien guide lie la clôture à la preuve de l’atténuation, tandis que les règles de 2026 distinguent clairement l’atténuation de la correction (VDR-CSO-RES).
Remarque : la définition des « faux positifs » donnée par FedRAMP exclut également les vulnérabilités corrigées et dont les risques ont été entièrement atténués.
Prenons l'exemple d'un composant corrigé que le scanner continue de signaler. Selon ces définitions, il n'est pas considéré comme corrigé tant qu'il est détecté, et il ne s'agit pas d'un faux positif puisque la vulnérabilité était présente avant la correction. L'expression « entièrement corrigé » est celle qui se rapproche le plus de cette situation, mais aucun des documents cités dans cet article ne l'indique pour une correction qui ne modifie pas le numéro de version.
L'ancien guide laisse également cette question en suspens. Vous pouvez clôturer un élément si vous apportez la preuve d'une atténuation du risque, ou demander à votre responsable de sécurité (AO) d'approuver un faux positif. Le guide ne précise pas laquelle de ces deux options s'applique à un composant pour lequel un correctif a été appliqué, mais qui continue d'être signalé par un scanner. Le même problème se pose dès l'entrée : un problème que le scanner continue de signaler peut dépasser la date limite même si vous l'avez corrigé.
C'est là la deuxième lacune. Avant de changer de système, demandez à votre responsable des achats (AO) ou à votre évaluateur quel statut ils prévoient d'attribuer à cette composante dans l'ancien système POA&M et dans vos rapports de vulnérabilité de 2026. Demandez-leur également s'ils considèrent un responsable de maintenance open source comme un fournisseur.
Obtenir un correctif sans attendre le responsable de la maintenance
SecureChain de TuxCare analyse le code source des paquets open source à la recherche de logiciels malveillants, les recompile à partir de ce code dans des environnements isolés et bloque les paquets qui ne passent pas l’inspection avant qu’ils n’atteignent votre environnement. Dans le cadre d’un accord de niveau de service, SecureChain applique des correctifs aux composants actifs. Pour les versions qui ne sont plus prises en charge par les responsables en amont, le service Endless Lifecycle Support (ELS) rétroporte les correctifs des vulnérabilités de gravité critique, élevée, moyenne et faible vers les versions en cours d’utilisation. Ensemble, SecureChain et ELS couvrent JavaScript, Python, Java, Go, PHP et Rust. Les informations fournies par SecureChain comprennent la provenance de niveau 3 selon la norme SLSA (Supply-chain Levels for Software Artifacts), une nomenclature logicielle (SBOM) et des données VEX (Vulnerability Exploitability eXchange). Les données VEX peuvent indiquer qu’un paquet contient déjà le correctif d’une vulnérabilité. Cela fournit à votre responsable de la sécurité (AO) ou à votre évaluateur un élément de référence à vérifier lorsqu’un scanner signale encore le paquet.
Si vous ne savez pas d'où proviendront les correctifs pour un composant une fois que son responsable de maintenance aura cessé ses activités, ni quelles vulnérabilités ce composant a introduites dans votre service, découvrez comment SecureChain for Open Source Software aborde ces deux aspects.
FAQ
Qu'est-ce qu'un POA&M dans les documents du programme FedRAMP ?
Un plan d’action et de jalons (POA&M) est, selon le Guide de remplissage du modèle POA&M de FedRAMP (version 2.2, 23 novembre 2021), un document répertoriant les faiblesses et les lacunes de sécurité connues d’un système, ainsi que les mesures correctives prévues par un fournisseur de services cloud (CSP). Depuis le 24 juin 2026, FedRAMP a classé son ancienne page consacrée au POA&M comme étant uniquement à titre de référence.
Qui assure la mise à jour et la révision d'un POA&M ?
Dans l’ancien guide de surveillance continue (Continuous Monitoring Playbook), le fournisseur de services cloud (CSP) télécharge chaque mois un plan d’action et un calendrier des étapes clés (POA&M) mis à jour, qui est ensuite examiné par le responsable habilité de l’agence. Depuis le 24 juin 2026, FedRAMP a classé ce guide comme document de référence uniquement. En vertu de la règle VER-AGM-MAP figurant dans les règles de 2026 relatives à l’évaluation et au signalement des vulnérabilités, les agences DEVRAIENT (il leur est recommandé) tenir à jour leurs propres POA&M lorsque leurs politiques de sécurité l’exigent.
Que contient le rapport sur les vulnérabilités d'un prestataire au titre de la réglementation de 2026 ?
La règle VER-RPT-VDT des règles d’évaluation et de signalement des vulnérabilités du programme FedRAMP, dont l’application sera obligatoire à compter du 7 décembre 2026, précise les éléments qu’un prestataire doit signaler pour chaque vulnérabilité détectée. Parmi ces éléments figurent notamment l’heure et la source de la détection, l’accessibilité depuis Internet, la probabilité d’exploitation, l’estimation du préjudice pour les agences (notation N de l’impact potentiel sur les agences) et la décision finale. Les vulnérabilités acceptées, c'est-à-dire celles qui ne sont pas, ou ne devraient pas être, entièrement atténuées ou corrigées dans les 192 jours suivant l'évaluation, sont répertoriées séparément.
À quel moment s'appliquent les règles du FedRAMP de 2026 relatives aux changements significatifs ?
L'adoption facultative des règles du FedRAMP relatives à la notification des changements significatifs, figurant dans les règles consolidées pour 2026, a débuté le 4 juillet 2026. Pour les prestataires relevant de la révision 5 (Rev5), ces règles s'appliquent à compter du 1er janvier 2027, et la période de grâce prend fin le 1er juin 2027. Les règles relatives aux vulnérabilités s'appliquent selon leur propre calendrier.
Que révèlent les demandes de modification importantes et les notifications concernant les vulnérabilités associées ?
Une demande de changement significatif issue de l'ancien cadre mentionne le plan d'action et les jalons (POA&M) correspondants lorsque le changement porte sur un risque connu, conformément à l'ancien guide de surveillance continue (Continuous Monitoring Playbook), que le programme FedRAMP considère désormais comme une référence uniquement. En vertu de la règle SCN-CSO-INF des règles de notification des changements significatifs de 2026, une notification doit inclure la vulnérabilité associée, le cas échéant, parmi d'autres informations requises.



