Technischer Support
Dokumentation
Anmeldung
Kontakt
Gehen Sie direkt zu einer KI-Zusammenfassung dieses Blogbeitrags 
Wichtigste Erkenntnisse
- Rev5-Anbieter behalten das bisherige POA&M-Verfahren bei, bis sie die FedRAMP-Vorschriften für Sicherheitslücken aus dem Jahr 2026 übernehmen, die ab dem 7. Dezember 2026 verbindlich sind.
- Ein Scannerfehler, der behoben wird, bevor die Frist abläuft, muss nicht in der alten POA&M-Liste erfasst werden, und ein dort aufgeführter Fehler wird geschlossen, sobald der Nachweis für die Behebung vorliegt.
- Bei routinemäßigen Bibliotheks-Patches entfällt die behördliche Genehmigung gemäß dem bisherigen Playbook sowie die Meldepflicht gemäß den Vorschriften von 2026.
- Eine gepatchte Komponente, die von einem Scanner weiterhin gemeldet wird, hat gemäß den FedRAMP-Definitionen von 2026 keinen eindeutigen Status.
Wenn Sie als Cloud-Dienstleister (CSP) Open-Source-Komponenten bereitstellen, kann eine Korrektur an einer dieser Komponenten Auswirkungen auf Ihren Aktionsplan und Ihre Meilensteine (POA&M) haben. Der bisherige Leitfaden schreibt nicht vor, dass Sie eine vom Scanner erkannte Sicherheitslücke, die Sie beheben, erst dann auflisten müssen, wenn die Frist dafür abgelaufen ist. Eine bereits aufgeführte Sicherheitslücke kann auf „Geschlossen“ gesetzt werden, sobald Korrekturmaßnahmen umgesetzt wurden und der Nachweis der Behebung zur Überprüfung durch Dritte vorliegt.
Die alte POA&M-Seite von FedRAMP ist nun als reine Referenz gekennzeichnet, und die Schwachstellenregeln der Klasse C aus der Revision 5 (Rev5) von 2026 enthalten keine POA&M-Regel für Anbieter. Bis zur Übernahme dieser Regeln, die am 7. Dezember 2026 verbindlich werden, behalten Sie weiterhin die alte POA&M-Seite bei. Wie wirkt sich also ein Patch auf den Status eines Elements aus, wer überprüft den neuen Status und welcher Änderungsprozess gilt – vor und nach der Umstellung? Die Antworten finden sich in verschiedenen Dokumenten, doch keines davon befasst sich mit einer rückwirkend angewendeten Korrektur.
Eine gepatchte Komponente entspricht den FedRAMP-Regeln für die Aufnahme und den Abschluss, doch die Dokumente lassen zwei Fragen offen: ob ein Open-Source-Betreuer als Anbieter gilt und welchen Status die Komponente hat, solange sie noch von einem Scanner gemeldet wird.
Der aktuelle Stand des FedRAMP-Programms „POA&M“
Im Rahmen des bisherigen Rev5-Prozesses führen Sie das POA&M in der FedRAMP-Vorlage. Der bisherige Leitfaden zu dieser Vorlage, der „POA&M Template Completion Guide“ (Version 2.2, 23. November 2021), beschreibt das POA&M als Aufzeichnung der bekannten Schwachstellen und Sicherheitsmängel des Systems, gepaart mit den von Ihnen geplanten Korrekturmaßnahmen. Im Rahmen Ihres kontinuierlichen Überwachungszyklus laden Sie jeden Monat eine aktualisierte Kopie hoch, die der Genehmigungsbeauftragte (AO) der Behörde gemäß dem bisherigen „Continuous Monitoring Playbook“ prüft. Seit dem 24. Juni 2026 werden die POA&M-Seite und das Playbook auf der bisherigen FedRAMP-Website während der Übergangsphase zu den Vorschriften von 2026 nur noch als Referenz angegeben.
Die FedRAMP-Vorschriften zur Erkennung und Behebung von Schwachstellen (VDR) sowie zur Bewertung und Meldung von Schwachstellen (VER) können seit dem 4. Juli 2026 freiwillig umgesetzt werden. Für Rev5-Anbieter werden sie am 7. Dezember 2026 verbindlich, und die Übergangsfrist endet am 7. März 2027. Die Fristen für die Risikominderung und Behebung beginnen, sobald der Anbieter eine Schwachstelle bewertet hat, und die Anbieter müssen mindestens einmal monatlich allen erforderlichen Parteien über die Aktivitäten zur Erkennung und Reaktion auf Schwachstellen Bericht erstatten.
Bei den hier zitierten Vorschriften handelt es sich um die FedRAMP-Vorschriften der Klasse C. Laut FedRAMP deckt Klasse C die meisten Sicherheitsziele der Stufen „Low“ und „Moderate“ ab, und Anbieter, die nach Klasse B oder D zertifiziert sind, sollten die Vorschriften ihrer jeweiligen Klasse überprüfen. In den Rev5-Regeln der Klasse C ist die einzige POA&M-Regel „Aufrechterhaltung der Aktionspläne und Meilensteine der Behörde“ (VER-AGM-MAP), die sich an Behörden richtet. Darin heißt es, dass diese die von Ihnen gemeldeten Informationen nutzen SOLLTEN, um POA&Ms für ihre eigenen Sicherheitsprogramme aufrechtzuerhalten, wenn die Richtlinien der Behörde dies vorschreiben. FedRAMP definiert „SOLLTE“ als eine Regel, von der eine Partei aus triftigen Gründen abweichen darf, sofern sie die Entscheidung dokumentiert, und „MUSS“ als absolute Anforderung. In der Zusammenfassung der Änderungen für 2026 durch FedRAMP heißt es, dass POA&Ms „vollständig abgeschafft wurden“. Jedes POA&M gemäß den Regeln von 2026 ist das eigene der Behörde und basiert auf Ihren Berichten.
Wie ein Artikel in das POA&M gelangt und es wieder verlässt
Nach den bisherigen Richtlinien entscheidet der Zeitpunkt darüber, ob ein Scanner-Befund im Rahmen der kontinuierlichen Überwachung an das FedRAMP POA&M weitergeleitet wird. Sie tragen ihn erst dann auf, wenn er überfällig ist (30, 90 oder 180 Tage nach der Entdeckung, je nach Schweregrad). Befunde aus anderen Quellen, wie z. B. Penetrationstests und Befragungen, werden unabhängig davon aufgeführt, ob sie überfällig sind oder nicht. Gleiches gilt für jeden Eintrag mit einem Abweichungsantrag – also das Formular, das Sie bei Ihrer AO einreichen, um einen Fehlalarm, eine Risikoanpassung oder eine betriebliche Anforderung geltend zu machen. In einer Fußnote wird darauf hingewiesen, dass etwaige Service-Level-Vereinbarungen oder Präferenzen der AO weiterhin gelten und dass beide eine Auflistung aller offenen Risiken verlangen können.
Gemäß dem Leitfaden kann ein Punkt in das Arbeitsblatt „Abgeschlossen“ verschoben werden, sobald Sie alle Korrekturmaßnahmen umgesetzt haben und „Nachweise für die Minderung“ zur Überprüfung bereitliegen. Eine unabhängige Bewertungsorganisation (3PAO) – der bisherige Begriff, der in den Definitionen von 2026 durch „Gutachter“ ersetzt wird – überprüft die Nachweise bei Erst- und regelmäßigen Bewertungen, und Ihre AO kann dies jederzeit anfordern. Ein Punkt kann auch dorthin verschoben werden, wenn Ihre AO einen Antrag auf Einstufung als „falscher positiver Befund“ genehmigt. Lieferantenabhängigkeiten, bei denen auf die Behebung durch den Lieferanten gewartet wird, sowie betriebliche Anforderungen, die auf der bisherigen POA&M-Seite als nicht behebbare Feststellungen beschrieben werden, verbleiben im Arbeitsblatt „Offen“.
Hinweis: In der alten Anleitung heißt es, dass im Sicherheitsbewertungsbericht (SAR) identifizierte Fehlalarme, die durch Belege wie beispielsweise einen einwandfreien Scanbericht untermauert sind, nicht in den POA&M aufgenommen werden müssen.
| Bühne | Ältere Dokumente | Regeln für 2026 | Grundlage |
|---|---|---|---|
| Gibt ein | Scanner-Befunde, deren Frist bereits abgelaufen ist. Sonstige Befunde, unabhängig davon, ob deren Frist abgelaufen ist oder nicht. Einträge mit Abweichungsanfragen. | Ein monatlicher Bericht über die Erkennung von Sicherheitslücken und die entsprechenden Maßnahmen an alle erforderlichen Stellen. Keine Vorschrift der Regel 2026 verpflichtet Anbieter zur Führung eines POA&M. | Leitfaden für ältere Systeme §3; VER-TFR-MHR und VER-RPT-VDT (2026, MUSS) |
| Wenn keine Lösung gefunden wird | Anbieterabhängigkeiten und betriebliche Anforderungen bleiben offen. | Eine Schwachstelle, die innerhalb von 192 Tagen nach der Bewertung nicht vollständig gemindert oder behoben wurde oder voraussichtlich nicht vollständig gemindert oder behoben wird, wird als akzeptierte Schwachstelle eingestuft. | Alte POA&M-Seite (nur zu Referenzzwecken); VER-TFR-MAV (2026, MUSS) |
| Schließt | Korrekturmaßnahmen, bei denen nachweislich eine Milderung vorliegt, oder ein von der AO anerkanntes falsch-positives Ergebnis. | Es ist kein „abgeschlossener“ Status definiert. „Behoben“ (neutralisiert oder beseitigt, nicht mehr nachweisbar) ist der Endzustand, der im Bericht als endgültiger Status ausgewiesen wird. | Leitfaden für Alt-Systeme §2.2; 2026 Begriffsbestimmungen; VER-RPT-VDT (2026, MUSS); VDR-CSO-RES |
| Überprüft von | Ein 3PAO bei Erst- und regelmäßigen Bewertungen. Der Umfang der jährlichen Bewertung umfasst auch abgeschlossene Punkte, Abhängigkeiten von Lieferanten und Abweichungsanträge. Der AO genehmigt Fehlalarme. | In den Rev5-Vorschriften für VDR und VER der Klasse C werden keine konkreten Personen genannt. Eine jährliche unabhängige Überprüfung deckt alle geltenden Vorschriften ab. | Leitfaden für das bisherige System §2.2; Seite zur jährlichen Bewertung des bisherigen Systems; VDR und VER (2026); IVV-CSO-FIA (2026, MUSS) |
| Verwaltet von | Der CSP, wobei der AO monatlich eine Überprüfung vornimmt. | Behörden für ihre eigenen Programme. | Legacy-Leitfaden, Überblick; VER-AGM-MAP (2026, SOLLTE) |
Was sich durch eine gepatchte Komponente ändert
In diesem Artikel bezeichnet der Begriff „gepatchte Komponente“ eine Bibliothek oder ein Paket, das Sie bereitstellen, nachdem ein Betreuer, Anbieter oder ein Dritter eine Korrektur bereitgestellt hat. Es handelt sich dabei nicht um einen FedRAMP-Begriff.
Eintrag und Abschluss sind im bisherigen Leitfaden separate Vorgänge. Wenn Sie eine Korrekturmaßnahme implementieren, bevor die Frist für eine vom Scanner gefundene Sicherheitslücke abgelaufen ist, ist laut Leitfaden kein Eintrag dafür erforderlich. Ist der Eintrag bereits vorhanden, zählt die implementierte Korrekturmaßnahme als eine Ihrer Korrekturmaßnahmen, und der Abschluss erfolgt gemäß den beiden im Leitfaden beschriebenen Vorgehensweisen.
Eine Lieferantenabhängigkeit folgt einem anderen Zeitplan. Die alte POA&M-Seite verknüpft sie mit einem nachgelagerten Lieferanten, beispielsweise dem Hersteller eines handelsüblichen Standardprodukts (COTS), dessen Korrektur noch nicht verfügbar ist. Eine risikoreiche Lieferantenabhängigkeit muss dennoch innerhalb von 30 Tagen durch kompensierende Kontrollmaßnahmen auf ein moderates Risiko gemindert werden. Sobald der Lieferant den Fix zur Verfügung stellt, beginnt der Leitfaden die Behebungsfrist an diesem Datum, fordert Sie auf, das Veröffentlichungsdatum zu erfassen, und ermöglicht es Ihnen, das geplante Fertigstellungsdatum zu überschreiben.
Auf der alten POA&M-Seite wird außerdem empfohlen, Belege für die Kommunikation mit Anbietern zum Patch-Status vorzulegen, wie beispielsweise Benachrichtigungen und E-Mail-Korrespondenz. Dabei handelt es sich um eine andere Art von Belegen als die Nachweise für Abhilfemaßnahmen, mit denen ein Eintrag abgeschlossen wird.
Auch die Bereitstellung des Fixes stellt eine Änderung dar. Das bisherige Playbook unterteilt Änderungen in routinemäßige, wiederkehrende, adaptive und transformative Änderungen. Es stuft kleinere, inkrementelle Patches ohne kompatibilitätsbrechende Änderungen – einschließlich routinemäßiger Bibliotheks-Patches – als routinemäßige, wiederkehrende Änderungen ein, die keiner Überprüfung und Genehmigung durch das AO bedürfen. Aktualisierungen von Bibliotheken mit bekannten kompatibilitätsbrechenden Änderungen sind ein Beispiel für eine adaptive Änderung, die eine solche Überprüfung und Genehmigung erfordert.
Die Vorschriften zur Meldung wesentlicher Änderungen (Significant Change Notification, SCN) für 2026 behalten diese drei Arten bei. Gemäß der Vorschrift zur Bewertung von Änderungen (SCN-CSO-EVA) bewerten Sie jede potenzielle wesentliche Änderung, um deren Art zu ermitteln. Die Vorschrift zu den Nicht-Meldepflichten (SCN-RTR-NNR) besagt, dass Anbieter KEINE formellen Meldungen für routinemäßige, wiederkehrende Änderungen senden SOLLTEN. FedRAMP räumt dem Ausdruck „SOLLTE NICHT“ denselben Spielraum ein wie dem Ausdruck „SOLLTE“. Zu den Beispielen gehören weiterhin routinemäßige Patches für Bibliotheken. Gemäß der Regel zu den Meldepflichten (SCN-ADP-NTF) müssen Sie innerhalb von 10 Werktagen nach Abschluss einer adaptiven Änderung eine Meldung vornehmen. Die SCN-Regeln gelten für Rev5-Anbieter ab dem 1. Januar 2027.
Was die Dokumente offen lassen
Die Verantwortung liegt bei Ihnen, unabhängig davon, wer die Korrektur vornimmt. Die Regel zur Reaktion auf Sicherheitslücken (VDR-CSO-RES) legt die Verantwortung für die Nachverfolgung, Eindämmung und Behebung erkannter Sicherheitslücken beim Anbieter fest. Die Regel zur Erkennung von Sicherheitslücken (VDR-CSO-DET) führt die Überwachung der Lieferkette als eine der Methoden auf, mit denen ein Anbieter diese erkennt. Daher müssen Sie auch Sicherheitslücken erkennen, die mit einer Komponente einhergehen.
Wenn man auf die Behebung durch einen anderen wartet, geben die alten Dokumente zwar den Status der Anbieterabhängigkeit an, aber weder im Leitfaden noch auf der POA&M-Seite wird erwähnt, ob ein Open-Source-Betreuer als Anbieter gilt. Ist dies der Fall, kann eine Sicherheitslücke, auf deren Behebung durch den Betreuer noch gewartet wird, offen bleiben und monatlich überprüft werden. Ist dies nicht der Fall, gilt sie wie jeder andere Scanner-Befund als überfällig. Das ist die erste Lücke.
Eine gepatchte Komponente, bei der die Versionsnummer nach der Korrektur unverändert bleibt, kann nach der Bereitstellung weiterhin in den Scan-Ergebnissen erscheinen. In der Dokumentation von Red Hat zum Thema „Security Backporting“ wird erklärt, warum dies so ist: Einige Scan- und Audit-Tools ermitteln ausschließlich anhand der Versionsnummer, ob eine Komponente anfällig ist. Diese Tools kennzeichnen eine Komponente als anfällig, wenn eine Korrektur aus einer neueren Version auf eine ältere Version angewendet wird.
Gemäß den FedRAMP-Definitionen von 2026 gilt eine behobene Schwachstelle als neutralisiert oder beseitigt und wird nicht mehr erkannt. Eine vollständig geminderte Schwachstelle birgt ein vernachlässigbares Risiko, wird jedoch weiterhin erkannt. Ein Fehlalarm ist eine erkannte Schwachstelle, die tatsächlich nicht vorhanden ist und es auch nie war. Der bisherige Leitfaden verknüpft den Abschluss mit dem Nachweis der Risikominderung, während die Regeln von 2026 Risikominderung und Behebung voneinander trennen (VDR-CSO-RES).
Hinweis: Die Definition von „falschen Positiven“ durch FedRAMP schließt auch behobene und vollständig geminderte Schwachstellen aus.
Nehmen wir eine gepatchte Komponente, die von einem Scanner weiterhin gemeldet wird. Nach diesen Definitionen gilt sie nicht als behoben, solange sie erkannt wird, und es handelt sich auch nicht um einen Fehlalarm, da die Sicherheitslücke bereits vor der Korrektur vorhanden war. Der Begriff „vollständig behoben“ kommt dem in der Formulierung am nächsten, aber keines der in diesem Artikel genannten Dokumente verwendet diesen Ausdruck für eine Korrektur, bei der die Versionsnummer unverändert bleibt.
Auch im alten Leitfaden bleibt der Status offen. Sie können einen Eintrag schließen, wenn Sie nachweisen können, dass das Problem behoben wurde, oder Sie können Ihren AO bitten, einen Fehlalarm zu genehmigen. Der Leitfaden gibt nicht an, welche der beiden Möglichkeiten für eine gepatchte Komponente gilt, die ein Scanner weiterhin meldet. Das gleiche Problem tritt bereits bei der Erfassung auf: Ein Befund, den ein Scanner weiterhin meldet, kann überfällig werden, obwohl Sie ihn bereits behoben haben.
Das ist die zweite Lücke. Bevor Sie umstellen, fragen Sie Ihren AO oder Assessor, welchen Status er für diese Komponente im bisherigen POA&M und in Ihren Schwachstellenberichten für 2026 erwartet. Fragen Sie außerdem, ob ein Open-Source-Betreuer als Anbieter behandelt wird.
Eine Lösung finden, ohne auf den Betreuer warten zu müssen
SecureChain von TuxCare überprüft den Quellcode von Open-Source-Paketen auf Malware, erstellt sie anhand dieses Codes in isolierten Umgebungen neu und blockiert Pakete, die die Überprüfung nicht bestehen, bevor sie in Ihre Umgebung gelangen. Im Rahmen einer Service-Level-Vereinbarung patcht SecureChain aktive Komponenten. Für Versionen, die von den Upstream-Betreuern nicht mehr unterstützt werden, portiert Endless Lifecycle Support (ELS) Korrekturen für Schwachstellen mit kritischem, hohem, mittlerem und geringem Schweregrad auf die verwendeten Versionen zurück. Zusammen decken SecureChain und ELS die Sprachen JavaScript, Python, Java, Go, PHP und Rust ab. Zu den von SecureChain bereitgestellten Informationen gehören die Herkunftsangaben gemäß „Supply-chain Levels for Software Artifacts“ (SLSA) Level 3, eine Software-Stückliste (SBOM) sowie Daten aus dem „Vulnerability Exploitability eXchange“ (VEX). VEX-Daten können angeben, dass ein Paket bereits den Fix für eine Sicherheitslücke enthält. Dies liefert Ihrem AO oder Prüfer einen Nachweis, den er überprüfen kann, wenn ein Scanner das Paket weiterhin als problematisch markiert.
Wenn Sie nicht sagen können, woher die Fehlerbehebung für eine Komponente kommen wird, sobald deren Betreuer die Arbeit einstellt, oder welche Sicherheitslücken eine Komponente in Ihren Dienst eingebracht hat, sehen Sie sich an, wie SecureChain für Open-Source-Software diese beiden Probleme angeht.
FAQ
Was ist ein POA&M in den FedRAMP-Dokumenten?
Ein Aktionsplan und Meilensteine (POA&M) ist laut dem „FedRAMP POA&M Template Completion Guide“ (Version 2.2, 23. November 2021) eine Aufstellung der bekannten Schwachstellen und Sicherheitsmängel eines Systems, gepaart mit den Korrekturmaßnahmen, die ein Cloud-Dienstleister (CSP) plant. FedRAMP hat seine alte POA&M-Seite seit dem 24. Juni 2026 als reine Referenz gekennzeichnet.
Wer pflegt und überprüft einen POA&M?
Im bisherigen „Continuous Monitoring Playbook“ lädt der Cloud-Dienstleister (CSP) monatlich einen aktualisierten Aktionsplan mit Meilensteinen (POA&M) hoch, der anschließend vom zuständigen Genehmigungsbeauftragten der Behörde geprüft wird. FedRAMP hat das Playbook seit dem 24. Juni 2026 als reine Referenz gekennzeichnet. Gemäß der Vorschrift VER-AGM-MAP in den Regeln zur Schwachstellenbewertung und -meldung von 2026 SOLLTEN (wird empfohlen) die Behörden ihre eigenen POA&Ms führen, wenn ihre Sicherheitsrichtlinien dies erfordern.
Was muss der Schwachstellenbericht eines Anbieters gemäß den Vorschriften von 2026 enthalten?
Die Vorschrift VER-RPT-VDT der FedRAMP-Regeln zur Bewertung und Meldung von Sicherheitslücken, die ab dem 7. Dezember 2026 gilt, legt fest, welche Angaben ein Anbieter zu jeder erkannten Sicherheitslücke machen muss. Dazu gehören beispielsweise der Zeitpunkt und die Quelle der Erkennung, die Erreichbarkeit über das Internet, die wahrscheinliche Ausnutzbarkeit, der geschätzte Schaden für Behörden (die „Potential Agency Impact N-Rating“) sowie die endgültige Entscheidung. Akzeptierte Schwachstellen, die innerhalb von 192 Tagen nach der Bewertung nicht vollständig gemindert oder behoben wurden oder voraussichtlich nicht vollständig gemindert oder behoben werden, werden separat aufgeführt.
Wann gelten die FedRAMP-Vorschriften für wesentliche Änderungen ab 2026?
Die fakultative Übernahme der FedRAMP-Vorschriften zur Meldung wesentlicher Änderungen in die konsolidierten Vorschriften für 2026 begann am 4. Juli 2026. Für Anbieter der Revision 5 (Rev5) gelten diese Vorschriften ab dem 1. Januar 2027, wobei die Übergangsfrist am 1. Juni 2027 endet. Für die Vorschriften zu Sicherheitslücken gelten eigene Fristen.
Was sagen Anträge auf wesentliche Änderungen und Benachrichtigungen über die damit verbundenen Sicherheitslücken aus?
Ein Antrag auf wesentliche Änderung nach altem Verfahren enthält den entsprechenden Aktionsplan und die Meilensteine (POA&M), wenn die Änderung ein bekanntes Risiko betrifft. Dies geht aus dem alten „Continuous Monitoring Playbook“ hervor, das FedRAMP nun als reine Referenz kennzeichnet. Gemäß der Vorschrift SCN-CSO-INF der Regeln zur Meldung wesentlicher Änderungen von 2026 muss eine Meldung unter anderem die betreffende Schwachstelle enthalten, sofern zutreffend.
