Technischer Support
Dokumentation
Anmeldung
Kontakt
Gehen Sie direkt zu einer KI-Zusammenfassung dieses Blogbeitrags 
Wichtigste Erkenntnisse
- Das Playbook des Federal Risk and Authorization Management Program (FedRAMP), Revision 5 (Rev5), schreibt vor, dass Anbieter monatlich einen aktualisierten Aktionsplan und Meilensteine hochladen müssen.
- In den konsolidierten FedRAMP-Vorschriften für 2026 ist der 7. Dezember 2026 als Datum für die Einführung der neuen Vorschriften zu Sicherheitslücken festgelegt, wobei die Übergangsfrist am 7. März 2027 endet.
- Ein nicht behobener Befund bleibt in den Monatsberichten des Anbieters so lange vermerkt, bis er behoben ist, und gemäß den Vorschriften für 2026 muss er als akzeptierte Schwachstelle gekennzeichnet werden, wenn er nicht innerhalb von 192 Tagen nach der Bewertung vollständig gemindert oder behoben wird.
- Basisimages, festgelegte Abhängigkeiten und veraltete Komponenten sorgen dafür, dass immer wieder dieselben Open-Source-Befunde auftreten, bis jemand den Build ändert.
- Ein Plattformteam kann das Rebase von Basis-Images planen, wiederkehrende Befunde auswerten und frühzeitig entscheiden, wie mit Komponenten umgegangen werden soll, für die es keine Upstream-Korrektur gibt.
Im Rahmen der kontinuierlichen Überwachung (ConMon) von FedRAMP muss ein Cloud-Dienstleister jeden Monat einen aktualisierten Aktionsplan mit Meilensteinen (POA&M) hochladen. Jede einzelne Schwachstelle erhält darin einen eigenen Eintrag. Wenn eine Komponente in Ihrer Build-Version noch einen offenen Befund aufweist, bleibt dieser Befund in der Regel auch im nächsten Monat im POA&M enthalten. Dies entspricht dem „Revision 5“-Pfad (Rev5) im „Continuous Monitoring Playbook“ von FedRAMP, dem Federal Risk and Authorization Management Program.
Ein Befund, der jeden Monat erneut auftaucht, konfrontiert die Prüfer erneut mit derselben Open-Source-Entscheidung, und genau das ist mit dem Begriff „erneute Auseinandersetzung“ im Titel gemeint. Auf dem Rev5-Pfad lenkt das Playbook die behördenübergreifenden ConMon-Sitzungen auf überfällige Punkte, Abhängigkeiten von Anbietern und alles, was einer Risikoakzeptanz bedarf. Die Prüfer validieren zudem bei jeder jährlichen Bewertung Abweichungsanträge und Lieferantenabhängigkeiten. Gemäß den FedRAMP-Vorschriften für 2026 muss ein Befund, der 192 Tage nach der Bewertung noch nicht vollständig gemindert oder behoben wurde, als akzeptierte Schwachstelle gekennzeichnet werden, wobei eine schriftliche Begründung dafür vorzulegen ist. Ab 2027 erhält jeder Behördenkunde zudem vierteljährlich eine Zusammenfassung der akzeptierten Schwachstellen.
Die FedRAMP-Vorschriften für 2026 sehen außerdem vor, dass Anbieter ihre Dienste so gestalten sollten, dass das Risiko von Sicherheitslücken standardmäßig minimiert wird. Bei Open-Source-Komponenten bedeutet dies, dass entschieden werden muss, was in den Build aufgenommen wird – und diese Entscheidungen trifft Ihr Plattformteam.
So funktioniert die kontinuierliche Überwachung im Rahmen von FedRAMP Monat für Monat
Auf dem Rev5-Pfad (Playbook-Version 1.0, 17. November 2025) scannt der Anbieter mindestens einmal monatlich Betriebssysteme, Webanwendungen und Datenbanken. Anschließend lädt er das aktualisierte POA&M und das Inventar sowie die Rohdaten der Scan-Dateien hoch, sofern dies in seinen Agenturvereinbarungen vorgesehen ist. Der zuständige Verantwortliche der Behörde prüft das POA&M und genehmigt Abweichungsanträge, in denen die Behörde gebeten wird, einen Befund als Fehlalarm, als Risikoanpassung oder als betriebliche Anforderung zu behandeln.
Die konsolidierten Vorschriften von FedRAMP für 2026 (CR26) traten am 24. Juni 2026 in Kraft. Zwei der darin enthaltenen Regelwerke – „Erkennung und Reaktion auf Schwachstellen“ sowie „Bewertung und Meldung von Schwachstellen“ – gelten für die Rev5-Klassen B bis D sowie für die Klassen B und C im Rahmen von „20x“, dem neueren Zertifizierungspfad von FedRAMP. Einige Zeitpläne hängen sowohl vom Zertifizierungspfad als auch von der Klasse ab. Die vorzeitige Umsetzung begann am 4. Juli 2026. Neue Antragsteller müssen die Regelwerke ab dem 7. Dezember 2026 befolgen. Bestehende Anbieter sollten diese bis zu diesem Datum umsetzen, andernfalls droht ihnen ein Korrekturmaßnahmenplan. Am 7. März 2027 endet die Übergangsfrist, und FedRAMP entzieht Anbietern, die die Vorschriften nicht umgesetzt haben, die Zertifizierung.
| Artikel | Rev5-Leitfaden v1.0 | Regeln zur CR26-Sicherheitslücke, Stand: 15. Oktober 2026 | Grundlage |
|---|---|---|---|
| Scannen und Überprüfung | Betriebssysteme, Webanwendungen und Datenbanken werden mindestens einmal im Monat überprüft. | Anbieter der Klassen C und D gemäß Rev5 müssen maschinenbasierte Ressourcen mindestens einmal monatlich überprüfen und validieren (Anbieter der Klasse B sollten dies ebenfalls tun). Anbieter der Klasse C gemäß 20x müssen dies alle drei Tage tun. | FedRAMP-Anforderungen |
| Monatsbericht | Aktualisierte POA&M-Daten und Bestandsliste | Die Aktivitäten im Zusammenhang mit Sicherheitslücken werden mindestens einmal monatlich in einem einheitlichen, für Menschen lesbaren Format gemeldet. Die Berichte fassen zudem alle Aktivitäten seit dem letzten Bericht zusammen (Rev5, Klassen B bis D). | FedRAMP-Anforderungen |
| Nicht geklärte Befunde | Werden als POA&M-Posten erfasst. Abweichungsanträge bedürfen der Genehmigung durch die Behörde. | Sie muss als anerkannte Sicherheitslücke gekennzeichnet werden, verbunden mit einer Erläuterung, falls sie nicht innerhalb von 192 Tagen nach der Bewertung vollständig gemindert oder behoben wurde oder werden wird. | Leitlinien aus dem Playbook des Programmbüros; CR26-Anforderung (MUSS) |
Was mit noch nicht endgültig festgestellten Sachverhalten nach dem ersten Bericht geschieht
Im Rev5-Prozess wird ein noch nicht behobener Befund im POA&M mit einem Abhilfemaßnahmenplan erfasst, und der Dienstleister kann einen Abweichungsantrag stellen, über den die Behörde entscheidet. Ein POA&M-Punkt, der von einem vorgelagerten Lieferanten abhängt, wird als Lieferantenabhängigkeit erfasst.
Für einen Anbieter mit mehr als einem Behördenkunden sieht das Playbook eine monatliche gemeinsame ConMon-Sitzung vor. Darin heißt es, dass es nicht praktikabel ist, jeden POA&M-Punkt zu behandeln, insbesondere jene, deren Behebung der Anbieter innerhalb der von FedRAMP vorgeschriebenen Fristen erwartet. Im Mittelpunkt der Diskussion sollten überfällige Punkte, Abhängigkeiten von Lieferanten und Abweichungsanträge stehen, insbesondere solche, die eine Risikoakzeptanz erfordern. Ein Befund, der über seine Fälligkeitsfrist hinaus offen bleibt, soll daher vor jeder Behörde der Gruppe zur Sprache kommen.
Aus den konsolidierten FedRAMP-Vorschriften für 2026: FedRAMP empfiehlt, dass Behörden nur überfällige und akzeptierte Schwachstellen mit einer „Potential Agency Impact“-Einstufung (N-Rating) über 2 überprüfen, es sei denn, der Anbieter empfiehlt Abhilfemaßnahmen oder der Dienst wird in einem Bundesystem mit höherem Risiko betrieben. Die N-Einstufung von N0 bis N5 ist die Einschätzung des Anbieters hinsichtlich des Ausmaßes des Schadens, den eine Ausnutzung der Schwachstelle den Behörden, die den Dienst nutzen, zufügen könnte. Akzeptierte Schwachstellen müssen in der Regel nur dann überprüft werden, wenn sie neu hinzukommen oder sich die Nutzung durch die Behörde ändert.
Die Vorschriften für 2026 legen zudem fest, wie lange ein Anbieter einen Befund offen lassen darf, während er dessen Behebung plant. Jede Schwachstelle, die nicht innerhalb von 192 Tagen nach der Bewertung vollständig gemindert oder behoben wurde oder werden wird, muss als akzeptierte Schwachstelle eingestuft werden. Von da an wird in jedem Monatsbericht erläutert, warum dies der Fall ist, ob die Schwachstelle über das Internet erreichbar ist, ob sie wahrscheinlich ausnutzbar ist und welche aktuelle N-Einstufung sie hat.
| Ergebnis | Was in den Regeln steht | Grundlage |
|---|---|---|
| Teilweise Minderung | Verringert das Risiko, ohne die Schwachstelle zu beseitigen. Wenn eine vollständige Risikominderung oder Behebung nicht möglich ist, sollten Anbieter dies unverzüglich, schrittweise und beharrlich tun. | FedRAMP-Leitfaden (SHOULD) |
| Vollständige Minderung | Reduziert das Risiko auf ein vernachlässigbares Maß, doch die Sicherheitslücke besteht weiterhin, bis sie behoben ist. | FedRAMP-Leitfaden |
| Sanierung | Beseitigt die Sicherheitslücke vollständig. | FedRAMP-Leitfaden |
| Bestätigte Sicherheitslücke | Kennzeichnung für eine Sicherheitslücke, die der Anbieter nicht vollständig mindern oder beheben will. Erforderlich, sobald eine Sicherheitslücke innerhalb von 192 Tagen nach der Bewertung nicht vollständig gemindert oder behoben wurde oder werden wird. Der Anbieter muss die Gründe dafür angeben. | Definition; Anforderung (MUSS) |
| Falsch-positiv | Anbieter sollten erkannte Schwachstellen bewerten, um festzustellen, ob es sich um Fehlalarme handelt. | Empfehlung (SOLLTE) |
Die Anerkennung eines Befunds verlagert die Risikobewertung auf Ihre Kunden: Jede Behörde entscheidet selbst, ob sie den Dienst trotz des offenen Befunds weiterhin nutzt, und FedRAMP fordert die Behörden auf, diese Entscheidung in ihrem eigenen POA&M zu dokumentieren.
Warum immer wieder dieselben Erkenntnisse zum Thema Open Source auftauchen
Für containerisierte Systeme schreibt das Playbook eine eindeutige Asset-Kennung für jede Klasse von Container-Images vor und ordnet jeden Produktionscontainer seinem Quell-Image zu. Außerdem heißt es darin, dass Software-Patches auf dem Ersatz-Image durchgeführt werden sollten, niemals direkt in der Produktionsumgebung. Ein anfälliges Paket in einem Basis-Image taucht daher in der Regel in jedem daraus erstellten Container auf, und die übliche Abhilfe besteht darin, ein neues Image zu erstellen. Solange niemand ein Rebase durchführt, bleibt der Paketsatz in der Regel unverändert, und die Sicherheitslücke bleibt damit bestehen.
Festgelegte Abhängigkeiten verhalten sich genauso. Eine Sperrdatei hält eine Bibliothek in der von Ihnen gewählten Version fest, sodass eine Bibliothek mit einer offenen Sicherheitswarnung in dieser Version verbleibt, bis jemand sie ändert. Bei einer aktiv gepflegten Komponente besteht die Lösung darin, dass der Upstream eine korrigierte Version veröffentlicht, die dann jemand in Ihren Build integriert. Ein Upgrade birgt eigene Risiken, und unser Beitrag darüber, warum „einfach ein Upgrade durchführen“ ein schlechter Sicherheitsratschlag ist, geht darauf ein.
Wenn der Upstream-Entwickler die Pflege einer Komponente einstellt, können zwar weiterhin neue Sicherheitslücken darin aufgedeckt werden, doch eine Version mit Behebung ist in der Regel nicht zu erwarten. Der Befund bleibt dann offen, bis die Komponente ersetzt wird oder jemand die von Ihnen verwendete Version patcht – selbst nachdem nach Ablauf der 192-Tage-Frist die Kennzeichnung „akzeptiert“ erzwungen wird. Da ein Dienst selten auf eine einzige Sprache beschränkt ist, können sich veraltete Komponenten über mehrere Ökosysteme hinweg ansammeln.
Was Scanner Ihnen über ein Paket verschweigen
Die Scan-Ergebnisse basieren auf bekannten Schwachstellen. Das Playbook verlangt die Angabe der CVE-Referenznummer (Common Vulnerabilities and Exposures) in maschinenlesbaren Befunden für jede Schwachstelle, die in der National Vulnerability Database aufgeführt ist. In den Regeln für 2026 heißt es, dass sich ältere FedRAMP-Leitlinien im Allgemeinen auf Schwachstellen vom Typ CVE konzentrierten und andere Arten unberücksichtigt ließen; die Erkennungsregel führt die Überwachung der Lieferkette als eine der von Anbietern verwendeten Techniken auf.
Die Scanner und andere FedRAMP-Tools zur kontinuierlichen Überwachung, die ein Anbieter einsetzt, liefern Berichte darüber, was im Build enthalten ist. Ein Paket, das manipuliert oder aus einer anderen Quelle als dem öffentlichen Quellcode erstellt wurde, wird möglicherweise nicht als CVE-Befund angezeigt, und ein bösartiges Paket verfügt möglicherweise gar nicht über eine CVE-Nummer. Eine Software-Stückliste (SBOM) weist denselben blinden Fleck auf: Eine Komponente kann korrekt aufgeführt sein und dennoch manipuliert worden sein. Beide beschreiben, was angekommen ist, aber keine der beiden gibt Auskunft darüber, ob es eigentlich hätte vorhanden sein sollen.
Was sich im Bereich Platform Engineering bis zum nächsten Bericht ändern kann
Wenn Sie für den Build verantwortlich sind, der im Rahmen eines kontinuierlichen FedRAMP-Überwachungszyklus erstellt wird, können Sie den Inhalt des nächsten Berichts beeinflussen, indem Sie die in diesen Build aufgenommenen Daten anpassen.
Aus den konsolidierten FedRAMP-Vorschriften für 2026: Anbieter sollten Schwachstellen für logische Gruppierungen betroffener Ressourcen bewerten; die FedRAMP-Vorschriften zur Erkennung und Reaktion gelten dann für jede Gruppierung und nicht für jede einzelne Instanz.
Planen Sie zunächst die Rebases der Basisimages ein. Legen Sie den Zeitpunkt so fest, dass die neu erstellten Images vor Ihrem monatlichen Scan in der Produktion sind, damit alle Korrekturen im aktualisierten Basisimage im nächsten Bericht erscheinen. Gemäß der Gruppierungsregel kann ein anfälliges Paket in einem einzelnen Basisimage als eine einzige Gruppierung behandelt werden, selbst wenn es in mehreren Containern vorkommt.
Ermitteln Sie, wie viele Feststellungen wiederholt auftreten, bevor Sie sich für deren Behebung einsetzen. Nehmen Sie Ihre letzten drei Berichte zur Hand und zählen Sie die Feststellungen, die in allen drei Berichten vorkommen. Das zeigt in etwa, wie viel der monatlichen Arbeit aus früheren Berichten stammt, und gibt demjenigen, der die Arbeit finanziert, eine Grundlage für weitere Maßnahmen. Kennzeichnen Sie dann wiederkehrende und neue Feststellungen vor der Triage getrennt, da neue Feststellungen eine neue Beurteilung erfordern und unter den bekannten Punkten leicht übersehen werden können.
Wenn für eine Komponente noch kein Fix vom Hersteller vorliegt, entscheiden Sie vor Ablauf der 192-Tage-Frist, ob Sie die Komponente ersetzen, die von Ihnen verwendete Version patchen oder die Sicherheitslücke in Kauf nehmen möchten.
Beziehen Sie transitive Abhängigkeiten in Ihre Paketliste ein, da die von Ihnen direkt ausgewählten Pakete nur einen Teil der insgesamt ausgelieferten Pakete ausmachen.
Die immer wieder auftretenden Fehler haben ihren Ursprung im Build, und eine Änderung am Build ist die Lösung für diese Fehler.
Wo SecureChain in den Lebenszyklus eines Pakets passt
SecureChain ist das Produkt von TuxCare für die Open-Source-Pakete in Ihrem Build. Die von SecureChain abgedeckten Pakete werden in abgesicherten, isolierten Umgebungen aus dem Quellcode neu kompiliert und auf Malware sowie verdächtigen Code überprüft, sodass alles, was die Überprüfung nicht besteht, nicht in Ihre Umgebung gelangt. Jedes Paket wird mit einer SLSA-Provenienzbescheinigung der Stufe 3, einer SBOM und einer VEX-Erklärung geliefert. Pakete, die weiterhin gepflegt werden, werden auf neue CVEs überwacht und im Rahmen einer Service-Level-Vereinbarung gepatcht. Sobald die Upstream-Betreuer die Pflege einstellen, portiert TuxCare kritische und hochgradig schwerwiegende Korrekturen auf genau die Versionen zurück, die Sie verwenden. Die Abdeckung umfasst JavaScript, Python, Java, Go und PHP.
Falls Ihr Monatsbericht weiterhin Komponenten enthält, für die der Upstream-Entwickler keine Fehlerbehebungen mehr bereitstellt, informieren Sie sich darüber, was SecureChain abdeckt.
FAQ
Was ist „ConMon“ im Rahmen von FedRAMP und was wird jeden Monat gemeldet?
Im Rahmen von FedRAMP, dem Cloud-Zulassungsprogramm der US-Bundesbehörden, umfasst die kontinuierliche Überwachung (Continuous Monitoring, ConMon) die laufende Sicherheitsberichterstattung eines Anbieters nach der Zulassung seines Dienstes. Auf dem Weg zur Revision 5 (Rev5) führen Cloud-Dienstleister monatlich Scans von Betriebssystemen, Webanwendungen und Datenbanken durch und laden gemäß dem „Continuous Monitoring Playbook“ (Version 1.0) einen aktualisierten Aktionsplan mit Meilensteinen (POA&M) sowie ein Inventar hoch.
Melden Rev5- und 20x-Anbieter Sicherheitslücken auf dieselbe Weise?
Gemäß den konsolidierten Vorschriften für 2026 verlangt FedRAMP von Anbietern der Revision 5 (Rev5) sowie von Anbietern der Klassen B und C mit dem 20x-Status, mindestens einmal monatlich über Schwachstellenaktivitäten zu berichten und alle Schwachstellen, die nicht innerhalb von 192 Tagen nach der Bewertung vollständig gemindert oder behoben wurden, als akzeptiert zu kennzeichnen. Die Häufigkeit der Überprüfungen variiert je nach Pfad und Klasse. Rev5-Anbieter der Klasse C müssen maschinenbasierte Ressourcen mindestens einmal monatlich überprüfen und validieren, während 20x-Anbieter der Klasse C dies alle drei Tage tun müssen.
Was versteht man unter einer akzeptierten Sicherheitslücke im Rahmen von FedRAMP?
Gemäß den FedRAMP-Vorschriften für 2026 gilt eine Schwachstelle als akzeptiert, wenn der Anbieter nicht beabsichtigt, sie vollständig zu mindern oder zu beheben. Diese Einstufung ist zudem erforderlich, sobald eine Schwachstelle nicht innerhalb von 192 Tagen nach der Bewertung vollständig gemindert oder behoben wurde oder werden wird. Die Anbieter müssen für jede Schwachstelle angeben, warum sie als akzeptiert gilt, sowie deren Erreichbarkeit über das Internet, die wahrscheinliche Ausnutzbarkeit und die geschätzten Auswirkungen auf die Behörde.
Was ist ein Abweichungsantrag im Rahmen von FedRAMP?
Im Rahmen von FedRAMP kann ein Anbieter der Revision 5 (Rev5) einen Abweichungsantrag stellen, in dem er die Behörde bittet, einen Befund als Fehlalarm, als Risikoanpassung oder als betriebliche Anforderung zu behandeln. Im „Continuous Monitoring Playbook“ ist festgelegt, dass die Behörden diese Anträge genehmigen und die Prüfer sie im Rahmen der jährlichen Bewertung validieren.
Werden bei FedRAMP-Scans Open-Source-Pakete von anderer Software getrennt?
FedRAMP sortiert die Befunde weder im „Continuous Monitoring Playbook“ noch in den Schwachstellenregeln für 2026 nach ihrem Open-Source-Status. Das Playbook verknüpft die Befunde mit Bestandsressourcen und Container-Images, und die Erkennungsregel für 2026 führt die Überwachung der Lieferkette als Methode auf. Um die Herkunft eines Befunds zurückzuverfolgen, ist eine eigene Analyse erforderlich.
Wann treten die FedRAMP-Vorschriften zu Sicherheitslücken für 2026 in Kraft?
FedRAMP hat am 4. Juli 2026 die freiwillige Umsetzung seiner Schwachstellenvorschriften für 2026 ermöglicht. Neue Antragsteller müssen diese ab dem 7. Dezember 2026 befolgen. Bestehende Anbieter sollten die Vorschriften bis dahin umsetzen und müssen dies bis zum 7. März 2027 tun; andernfalls wird FedRAMP die Zertifizierung widerrufen.
