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
- Conformément aux règles du programme FedRAMP pour 2026, les délais de correction recommandés vont de 12 heures à 192 jours, à compter de la date à laquelle le prestataire a identifié la vulnérabilité.
- Les nouveaux candidats devront se conformer aux règles FedRAMP de 2026 relatives aux vulnérabilités à compter du 7 décembre 2026, tandis que les prestataires existants devront les adopter au plus tard le 7 mars 2027.
- Les vulnérabilités qui ne seront pas entièrement atténuées ou corrigées dans les 192 jours suivant leur évaluation doivent être classées comme « vulnérabilités acceptées ».
- Aucun délai de mise en conformité FedRAMP n'est suspendu lorsqu'un responsable de maintenance d'un logiciel libre cesse de publier des correctifs.
- Une vulnérabilité dont le délai de traitement n'est pas respecté, alors que le fournisseur a toujours l'intention de la corriger ou d'y remédier complètement, est considérée comme en retard, et chaque rapport mensuel doit la signaler en fournissant une explication.
FedRAMP fixe des délais pour atténuer ou corriger les vulnérabilités de votre service, y compris celles présentes dans les bibliothèques open source. Ces délais s'appliquent indépendamment de l'existence ou non d'un correctif.
En l'absence de correctif, vous pouvez atténuer les vulnérabilités, mais celles-ci continueront d'apparaître dans vos rapports mensuels jusqu'à ce qu'elles soient corrigées. Conformément aux nouvelles règles du programme FedRAMP, une vulnérabilité qui n'est pas entièrement atténuée (réduite à un risque négligeable) ou corrigée dans les 192 jours suivant son évaluation doit être classée comme « vulnérabilité acceptée ». Vous devrez alors expliquer dans vos rapports les raisons pour lesquelles elle est acceptée.
Ces nouvelles règles, intitulées « Règles consolidées pour 2026 », remplacent les anciens documents du programme FedRAMP. Les prestataires existants doivent se conformer aux règles relatives aux vulnérabilités au plus tard le 7 mars 2027.
Calendrier de correction des vulnérabilités dans le cadre du programme FedRAMP avant et après l'entrée en vigueur des règles de 2026
Le 24 juin 2026, FedRAMP a classé ses documents hérités comme étant uniquement à titre de référence. En ce qui concerne les vulnérabilités, ces documents sont remplacés par deux ensembles de règles figurant dans les « Règles consolidées pour 2026 » : « Détection et réponse aux vulnérabilités » (VDR) et « Évaluation et signalement des vulnérabilités » (VER). Les prestataires qui n’ont pas encore adopté ces règles de 2026 continuent de suivre les processus hérités pendant la période de transition. Les règles de 2026 utilisent le terme « certification » là où les documents hérités utilisaient le terme « autorisation ».
La page « Plan d’action et jalons » (POA&M) de l’ancienne version indique que FedRAMP exige que les vulnérabilités classées « Critiques » ou « Élevées » soient corrigées dans les 30 jours suivant leur découverte, celles classées « Modérées » dans les 90 jours et celles classées « Faibles » dans les 180 jours. Le guide de surveillance continue de l’ancienne version utilise le score de base du système commun d’évaluation des vulnérabilités (CVSS) pour cette classification.
En vertu de la réglementation de 2026, chaque service certifié est classé dans une catégorie allant de A, le niveau d’assurance le plus bas, à D, le plus élevé. Le délai de correction commence dès l’évaluation. L’évaluation doit intervenir dans les 14 jours suivant la détection pour la classe A, et dans les 2 jours pour la classe D. La durée de ce délai dépend de la classe et de la note « N » attribuée par le prestataire à la vulnérabilité, qui estime l’ampleur des dommages que son exploitation pourrait causer aux agences, allant de N0 (très peu susceptible d’affecter les agences) à N5 (effets dévastateurs sur plusieurs agences).
La durée dépend également de la probabilité que la vulnérabilité soit exploitable, c'est-à-dire qu'un attaquant potentiel puisse l'utiliser pour causer des dommages, et de sa visibilité depuis Internet, c'est-à-dire qu'une charge utile provenant d'Internet puisse la déclencher. Les vulnérabilités qui remplissent ces deux critères se voient attribuer le délai le plus court. Le VDR ne fixe des délais que pour les niveaux N2 à N5, laissant les niveaux N0 et N1 à la discrétion des opérations courantes du fournisseur.
| Article | Documents historiques | Règles de 2026 (VDR et VER) | Base |
|---|---|---|---|
| La période commence le | Découverte | L'évaluation, qui doit avoir lieu dans un délai de 14, 7, 5 ou 2 jours à compter de la détection pour les classes A, B, C et D | Ancienne page POA&M ; VER-TFR-EVU |
| Durée de la période | 30, 90 et 180 jours, selon le niveau de risque | De 12 heures à 192 jours selon la classe, la qualification « N », l'exploitabilité et l'accessibilité | Ancienne page POA&M ; VDR-TFR-PVR |
| Force | « Le programme FedRAMP exige » | « SHOULD » pour les délais, « MUST » pour le libellé de vulnérabilité accepté | Ancienne page POA&M ; VDR-TFR-PVR ; VER-TFR-MAV |
| Note | Niveau de risque basé sur le CVSS | Estimation de la note « N » du prestataire | Guide stratégique, page 6 ; VER-EVA-EPA |
Les délais de mise en conformité prévus dans la réglementation de 2026 sont assortis de la mention « SHOULD ». FedRAMP définit « SHOULD » comme une règle à laquelle un prestataire peut déroger pour des raisons valables, à condition d’expliquer sa décision dans sa documentation de sécurité. Néanmoins, l’avis NTC-0014 de FedRAMP, daté du 16 juin 2026, précise que ces délais constituent des délais maximaux et indique que les prestataires devraient prendre des mesures d’atténuation ou de mise en conformité bien plus rapidement.
Dates d'adoption et directive à l'origine de celles-ci
La mise en conformité s'effectue prestataire par prestataire, conformément à la page « Échéances de la version 5 » du programme FedRAMP. Les nouveaux candidats devront se conformer aux deux ensembles de règles à compter du 7 décembre 2026. Les prestataires existants qui ne se seront pas mis en conformité à cette date devront mettre en place un plan d'actions correctives, comprenant notamment la notification de toutes les agences, et FedRAMP révoquera la certification de l'offre si les règles ne sont toujours pas respectées au 7 mars 2027.
La date du 7 décembre s'inscrit dans le cadre de la directive opérationnelle contraignante (BOD) 26-04 de l'Agence pour la cybersécurité et la sécurité des infrastructures (CISA), publiée le 10 juin 2026. Cette directive s'impose aux agences civiles fédérales, qui ont jusqu'au 7 décembre pour commencer à se conformer à son tableau des mesures correctives, et s'applique aux prestataires par le biais des règles et des contrats du programme FedRAMP. Le délai prévu dans ce tableau va de 3 à 60 jours. La norme NTC-0014 stipule que les prestataires qui respectent les normes VDR et VER satisfont aux exigences de la directive.
Ce que révèlent les documents au sujet d'un problème non résolu
Un problème pour lequel aucune solution n’est disponible est traité différemment selon chaque ensemble de documents. Les documents hérités parlent de « dépendance vis-à-vis d’un fournisseur » (VD), qui s’applique lorsqu’un prestataire doit compter sur un fournisseur, par exemple celui qui fournit un produit commercial prêt à l’emploi, pour obtenir un correctif qui n’est pas encore disponible. Une VD n’est pas une demande de dérogation (le type de demande historique qu’une agence approuve pour les faux positifs, les ajustements de risque et les exigences opérationnelles) ; elle ne nécessite donc aucune autorisation.
Une vulnérabilité (VD) reste en suspens, et le prestataire fait le point avec le fournisseur au moins une fois par mois. Même en l'absence de correctif de la part du fournisseur, une vulnérabilité à haut risque (c'est-à-dire correspondant à l'ancien niveau de risque « Haut ») doit être atténuée pour passer au niveau « Modéré » grâce à des contrôles compensatoires dans un délai de 30 jours.
Une exigence opérationnelle concerne un constat qui ne peut pas faire l'objet d'une correction, souvent parce que le système ne fonctionnerait pas comme prévu ou parce qu'un fournisseur a indiqué qu'il ne proposerait pas de solution. FedRAMP n'approuvera pas une telle exigence pour un constat à haut risque, bien que le prestataire puisse tout de même en atténuer les effets.
L'ancienne page POA&M utilise le terme « fournisseur », mais ne précise pas si un responsable de maintenance bénévole est considéré comme tel. Les ensembles de règles VDR et VER n'utilisent pas du tout le terme « dépendance vis-à-vis d'un fournisseur ». Le VDR stipule qu'un fournisseur incapable d'atténuer ou de corriger entièrement une vulnérabilité doit l'atténuer partiellement, de manière rapide, progressive et persistante.
Dans le cadre de la norme VDR-TFR-PVR, un fournisseur respecte un délai en atténuant partiellement, en atténuant totalement ou en corrigeant une vulnérabilité afin d’obtenir une note « N » inférieure dans ce délai. La norme NTC-0014 précise que, aux fins de la directive BOD 26-04, un fournisseur peut atténuer une vulnérabilité jusqu’à ce qu’elle ne soit plus exploitable de manière automatisée ou accessible depuis Internet ; à ce stade, la directive n’exige pas de correction complète.
VER exige l'attribution du label « vulnérabilité acceptée » si 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. Chaque rapport comporte alors l'explication du fournisseur justifiant cette acceptation, ainsi que les informations relatives à l'accessibilité et à l'exploitabilité de la vulnérabilité, et sa note N actuelle.
Quand les calendriers de lancement en amont s'alignent sur l'horloge
Par rapport au calendrier de correction des vulnérabilités du FedRAMP, le « patch gap » correspond à la période, au cours de laquelle aucun correctif n’est disponible, pour une vulnérabilité donnée. L’ancienne page POA&M, le « Playbook », les règles de 2026 relatives aux vulnérabilités et les définitions du FedRAMP ne mentionnent pas les responsables de maintenance des logiciels open source ni ne précisent si un projet fait encore l’objet de nouvelles versions. Le VDR mentionne bien la surveillance de la chaîne d’approvisionnement parmi les techniques permettant de détecter les faiblesses ; par conséquent, ce qu’un paquet apporte à une version fait partie de ce qu’un fournisseur est censé surveiller. Au-delà de la gestion décrite ci-dessus, ces documents ne précisent pas ce qu’un fournisseur doit faire lorsque le responsable de maintenance n’a pas l’intention de corriger la vulnérabilité.
Supposons que votre service soit titulaire d'une certification de classe C et détecte, le jour 0, une vulnérabilité dans un logiciel libre dont les responsables ont cessé de publier des correctifs. Les prestataires de classe C doivent procéder à une évaluation dans les 5 jours suivant la détection ; supposons donc que l'évaluation ait lieu le jour 5 et que la vulnérabilité soit classée N3.
| Comment se déroule l'évaluation ? | Délai à compter de l'évaluation | Jour (si l'évaluation a lieu le 5e jour) | Base |
|---|---|---|---|
| Probablement vulnérable et accessible depuis Internet | 16 jours (devrait) | Jour 21 | VDR-TFR-PVR, classe C, N3 |
| Probablement vulnérable, mais non accessible depuis Internet | 32 jours (devrait) | 37e jour | VDR-TFR-PVR, classe C, N3 |
| Peu susceptible d'être exploité | 128 jours (devrait) | Jour 133 | VDR-TFR-PVR, classe C, N3 |
| L'un quelconque de ces trois éléments, s'il n'est pas (ou ne devrait pas être) entièrement atténué ou corrigé dans les 192 jours suivant l'évaluation | Une étiquette de vulnérabilité validée est requise dès lors qu’une atténuation ou une correction complète ne pourra pas être mise en œuvre dans un délai de 192 jours (obligatoire) | Dès que le prestataire en a connaissance, et au plus tard le 197e jour | VER-TFR-MAV |
Le fait que les responsables de la maintenance publient ou non un correctif ne modifie en rien ces chiffres. Le choix de la ligne applicable dépend de l’évaluation du fournisseur, et FedRAMP inclut un avertissement à ce sujet. Sa note sur la règle d’exploitabilité précise que les fournisseurs qui classent régulièrement les vulnérabilités comme « peu susceptibles d’être exploitées » sans examen approfondi sont plus susceptibles de subir des conséquences négatives si l’une d’entre elles venait à être exploitée. Une sous-évaluation imprudente ou délibérée, ajoute-t-elle, jouera en défaveur de la certification d’un fournisseur. Les fournisseurs doivent également partir du principe que l’exploitation peut être automatisée, sauf s’ils disposent de preuves du contraire.
La directive de la CISA permet d’ajuster le calendrier en fonction de l’évolution des faits. L’une de ses notes précise que le fait de déconnecter un système d’Internet entraîne son déplacement vers une autre ligne du tableau de la directive. Les vulnérabilités connues et exploitées conservent toutefois leurs dates limites. La directive VDR-TFR-KEV stipule que les fournisseurs doivent y remédier avant les dates limites indiquées dans le catalogue de la CISA, même lorsqu’elles sont entièrement atténuées, et la directive NTC-0014 ne prévoit de dérogation que pour des raisons techniques valables.
Un responsable de maintenance qui continue à publier des versions peut fournir à un fournisseur un élément à intégrer avant la fin du délai. Celui qui a cessé ses activités laisse le délai s'écouler sans rien à intégrer, et cette lacune peut apparaître dans n'importe quel écosystème linguistique à partir duquel un service récupère des paquets.
Que se passe-t-il lorsqu'un délai est écoulé ?
L’ancien « Playbook » répertorie des exemples de déclencheurs parmi lesquels les agences peuvent choisir. La présence d’au moins cinq vulnérabilités à fort impact ou éléments POA&M non corrigés depuis plus de 30 jours nécessite au minimum un « examen détaillé des constatations », c’est-à-dire une demande d’évaluation de la défaillance et un rapport sur sa cause et sa solution. Dès que cinq éléments ou plus dépassent le seuil des 60 jours, la mesure minimale consiste en un plan d’actions correctives de l’agence, qui exige une analyse des causes profondes et un plan de correction formel. À partir de là, une agence peut passer à la suspension ou à la révocation d’une autorisation d’exploitation (ATO), une mesure qu’elle doit signaler au FedRAMP.
La discussion sur le POA&M lors de la réunion collaborative mensuelle du Playbook avec les agences devrait porter sur les éléments en retard, les dépendances vis-à-vis des fournisseurs et les demandes de dérogation ; ainsi, un constat qui reste en suspens a tendance à refaire surface.
Les pages VDR et VER ne prévoient pas de sanction en cas de non-respect d’un délai de niveau « SHOULD ». Un fournisseur doit tout de même justifier cet écart, comme l’exige toute exigence de niveau « SHOULD », et la norme VER impose en outre une obligation de rapport. Selon les définitions de FedRAMP, une vulnérabilité est considérée comme en retard lorsque le fournisseur a l’intention de l’atténuer ou d’y remédier complètement, mais ne l’a pas fait, ou ne le fera pas, dans les délais recommandés ou requis. Le label « vulnérabilité acceptée » couvre les vulnérabilités que le prestataire n’a pas l’intention d’atténuer ou de corriger entièrement, ainsi que toute vulnérabilité ayant dépassé la limite de 192 jours. Le VER exige que chaque rapport précise si une vulnérabilité est en retard ou susceptible de le devenir, et d’en expliquer les raisons le cas échéant.
Correction des paquets après le départ des responsables de maintenance
SecureChain de TuxCare recompile à partir du code source les paquets open source qu’il couvre, dans des environnements sécurisés et isolés, et analyse leur code source à la recherche de logiciels malveillants connus et de motifs de code suspects. Tout élément ne passant pas le contrôle est exclu de votre environnement. Alors que les responsables de maintenance continuent de publier des correctifs, SecureChain applique des correctifs aux paquets dans le cadre d’un accord de niveau de service, en utilisant les correctifs en amont lorsqu’ils sont disponibles et ceux développés par les ingénieurs de TuxCare lorsque les correctifs en amont ne suffisent pas.
Lorsque le développeur en amont cesse de publier des mises à jour, TuxCare continue d'apporter des correctifs au paquet, qui passe ensuite automatiquement sous le régime du « Endless Lifecycle Support » (ELS): les ingénieurs de TuxCare assurent alors le portage des correctifs vers les versions que vous utilisez déjà, et ce tant que vous continuez à utiliser ce paquet.
SecureChain fournit également des informations de provenance, des nomenclatures logicielles (SBOM) et des données VEX (Vulnerability Exploitability eXchange), qui permettent de mettre en évidence les éléments qu'un paquet a introduits dans votre build. Ensemble, SecureChain et ELS couvrent les langages JavaScript, Python, Java, Go et PHP.
Si vous ne savez pas qui corrige un paquet une fois que ses responsables ont cessé de publier des correctifs alors que le délai FedRAMP continue de courir, ni ce que ce paquet a apporté à votre compilation, découvrez comment SecureChain aborde ces deux questions.
FAQ
Qui est responsable des mesures correctives dans le cadre du programme FedRAMP ?
En vertu des Règles consolidées pour 2026, la responsabilité incombe au fournisseur de services cloud : les règles relatives à la détection et à la réponse aux vulnérabilités exigent des fournisseurs qu’ils assurent le suivi, atténuent et corrigent toutes les vulnérabilités détectées. L’ancien guide de surveillance continue (version 1.0, 17 novembre 2025, désormais à titre de référence uniquement) attribue également la responsabilité principale au fournisseur, les responsables habilités de l’agence examinant son plan d’action mensuel et ses étapes clés.
Qui attribue la note qui détermine la date limite fixée par le programme FedRAMP ?
Dans l'ancien guide de surveillance continue, désormais à titre de référence uniquement, la notation de risque initiale correspond au score de base du système CVSS (Common Vulnerability Scoring System) version 3 de la National Vulnerability Database. Les règles de 2026 relatives à l'évaluation et au signalement des vulnérabilités exigent que le prestataire évalue l'impact potentiel d'une vulnérabilité sur l'agence en lui attribuant une note N comprise entre N0 et N5.
À quel moment commence le délai de mise en conformité FedRAMP ?
L'ancienne page « Plan d'action et étapes clés », désormais à titre de référence uniquement, prévoit des délais de 30, 90 ou 180 jours à compter de la découverte, en fonction du niveau de risque. Les règles de 2026 relatives à la détection et à la réponse aux vulnérabilités prévoient des délais à compter de l'évaluation, laquelle, selon les règles d'évaluation et de signalement des vulnérabilités, doit intervenir dans les 14, 7, 5 ou 2 jours suivant la détection, en fonction de la classe de certification.
Quelles dispositions du FedRAMP s'appliquent à un problème pour lequel aucune solution n'est disponible ?
Les termes « dépendance vis-à-vis du fournisseur » et « exigence opérationnelle » sont des termes hérités de la page « Plan d’action et étapes clés ». Le premier désigne une vulnérabilité en attente d’un correctif de la part du fournisseur, tandis que le second désigne une vulnérabilité qui ne peut pas être corrigée. Les règles de 2026 relatives à la détection et à la réponse aux vulnérabilités recommandent une atténuation partielle, et les règles d’évaluation et de signalement des vulnérabilités exigent l’attribution du label « vulnérabilité acceptée » si une atténuation complète ou une correction ne peut être mise en œuvre dans les 192 jours suivant l’évaluation.
Qu'est-ce qui est considéré comme « mis en conformité » au regard des règles FedRAMP de 2026 ?
Une vulnérabilité corrigée, selon les définitions des Règles consolidées pour 2026, a été neutralisée ou éliminée et n’est plus détectée. Une vulnérabilité entièrement atténuée est toujours détectée, mais son risque est négligeable. Les règles relatives à la détection et à la réponse aux vulnérabilités précisent que les notions d’atténuation et de correction ne sont pas interchangeables.
Comment FedRAMP désigne-t-il une vulnérabilité dont le délai de correction n'a pas été respecté ?
Une vulnérabilité est considérée comme « en retard » lorsque le fournisseur prévoit toujours de la corriger ou d’y remédier pleinement, mais qu’il n’a pas respecté, ou ne respectera pas, le délai fixé. Si le fournisseur n’envisage pas de le faire, il s’agit alors d’une vulnérabilité « acceptée ». Conformément aux règles de 2026 relatives à l’évaluation et au signalement des vulnérabilités, chaque rapport doit signaler toute vulnérabilité en retard ou susceptible de le devenir, en fournissant une explication.
