Technischer Support
Dokumentation
Anmeldung
Kontakt
Gehen Sie direkt zu einer KI-Zusammenfassung dieses Blogbeitrags 
Wichtigste Erkenntnisse
- Seit dem 13. Juli 2026 dürfen Ausschreibungen im Verteidigungsbereich nur noch Selbstbewertungen der Stufe 1 oder 2 vorschreiben, während Phase 2 weiterhin ausgesetzt bleibt.
- In keiner der 110 Anforderungen der Stufe 2 wird Open Source erwähnt, doch da Software als Vermögenswert gilt, fallen Open-Source-Pakete auf den betroffenen Systemen ebenso unter die Anforderungen wie alle anderen.
- Vier Anforderungen betreffen sie: Bestandsaufnahme, vom Benutzer installierte Software, Schwachstellen-Scans und Behebung von Sicherheitslücken.
- Drei davon sind Fünf-Punkte-Anforderungen, sodass eine Lücke bei einer dieser Anforderungen nicht durch einen Aktionsplan und Meilensteine aufgeschoben werden kann.
Die Compliance-Anforderungen der „Cybersecurity Maturity Model Certification“ (CMMC) stellen keine spezifischen Anforderungen an Ihre Open-Source-Komponenten. Die 110 Anforderungen, die das CMMC an Auftragnehmer stellt, die mit „Controlled Unclassified Information“ (CUI) umgehen, betreffen jedoch auch die Open-Source-Pakete in Ihrer Build-Umgebung. Dies gilt auch weiterhin, nachdem das Pentagon am 13. Juli 2026 Phase 2 des CMMC-Programms ausgesetzt hat – den Schritt, der die Bewertung durch Dritte zu einer Voraussetzung für die Vergabe entsprechender Aufträge gemacht hätte. Diese 110 Anforderungen bilden nach wie vor die Grundlage für Selbstbewertungen.
Was die CMMC-Compliance-Anforderungen abdecken
CMMC umfasst drei Stufen. Welche Stufe für Sie gilt, hängt von den betreffenden Informationen und den Anforderungen in Ihrem Vertrag oder Ihrer Ausschreibung ab.
| Ebene | Informationen | Anforderungen | Wer bewertet? |
|---|---|---|---|
| Stufe 1 | Informationen zu Bundesaufträgen (FCI) | 15 grundlegende Anforderungen aus der Federal Acquisition Regulation | Sie, im Rahmen einer jährlichen Selbsteinschätzung |
| Stufe 2 | CUI | 110 Anforderungen aus der Norm SP 800-171, Revision 2, des National Institute of Standards and Technology (NIST) | Sie oder eine unabhängige CMMC-Prüfstelle (C3PAO), sofern dies in der Ausschreibung vorgesehen ist (derzeit ausgesetzt) |
| Stufe 3 | CUI bei ausgewählten Programmen | 24 ausgewählte Anforderungen aus NIST SP 800-172, zusätzlich zu Stufe 2 | Die Defense Contract Management Agency (DCMA) |
Die 110 Anforderungen der Stufe 2 erstrecken sich über 14 Bereiche, von der Zugriffskontrolle bis hin zur System- und Informationsintegrität.
Der Stand der CMMC-Compliance-Anforderungen im Jahr 2026
Die Bestimmung des „Defense Federal Acquisition Regulation Supplement“ (DFARS) , mit der das CMMC in Verträge aufgenommen wird, trat am 10. November 2025 in Kraft und markiert damit den Beginn von Phase 1. Im Rahmen von Phase 1 legt das Verteidigungsministerium (DoD) gegebenenfalls eine Selbstbewertung der Stufen 1 oder 2 als Voraussetzung für die Auftragsvergabe fest.
Phase 2, deren Frist am 10. November 2026 ablief, hätte als Voraussetzung für die Auftragsvergabe Bewertungen der Stufe 2 durch C3PAOs vorgesehen. Am 13. Juli 2026 setzte der Chief Information Officer des Verteidigungsministeriums diese Regelung aus. Programmmanager können nun lediglich Selbstbewertungen der Stufe 1 oder 2 verlangen, und Verträge, die bereits eine Bewertung durch ein C3PAO oder eine von der Regierung geleitete Bewertung vorsehen, sind zum nächsten Optionszeitraum oder bei der nächsten administrativen Änderung anzupassen.
Die Programmregel selbst wurde seit der Bekanntgabe der Aussetzung per Rundschreiben nicht überarbeitet, sodass sie nach wie vor die ursprünglichen vier Phasen beschreibt. Änderungen werden auf der CMMC-Seite des Chief Information Officer des Verteidigungsministeriums veröffentlicht.
Derzeit bilden die 110 Anforderungen die gemeinsame Grundlage, und Open Source findet über diese Eingang.
Was die Vorschrift zu Open-Source-Komponenten besagt
Die 110 Anforderungen der Stufe 2 entsprechen den Anforderungen in NIST SP 800-171, Revision 2, und laut Programmvorschrift sind sie identisch. Das NIST hat Revision 2 inzwischen durch Revision 3 ersetzt, doch das CMMC stützt sich weiterhin auf Revision 2, ebenso wie der Bewertungsleitfaden des Verteidigungsministeriums (DoD). In der Praxis bedeutet dies, dass für Ihre Open-Source-Pakete die Anforderungen der Revision 2 gelten und nicht die der Revision 3.
Jede der 110 Anforderungen wird in den NIST- und DoD-Dokumenten von zwei Begleitelementen begleitet: einer Reihe von Bewertungszielen (einer Checkliste mit Bedingungen, die erfüllt sein müssen, damit die Anforderung als erfüllt gilt) und einer Erläuterung (einem erklärenden Text, der die Absicht beschreibt, aber selbst keine Anforderung darstellt).
Der Leitfaden zur Bewertung der Stufe 2 fordert Selbstbewerter dazu auf, dieselben Kriterien anzuwenden wie ein externer Gutachter und die Aussagen der Mitarbeiter in Interviews nicht als Beweis dafür zu werten, wie das System tatsächlich funktioniert. Der Abschnitt zur Punktevergabe in der Richtlinie legt den Nachweisstandard fest: Entwürfe, Arbeitspapiere und nicht genehmigte Richtlinien zählen nicht. Für Open Source bedeutet dies, dass ein Entwurf eines Bestandsverzeichnisses oder einer Scan-Richtlinie, der von niemandem genehmigt wurde, nicht als Nachweis gilt.
In keiner der 110 Anforderungsformulierungen werden Open Source, Software-Stücklisten (SBOMs), Herkunft oder Lieferkette namentlich genannt. Software fließt über die Definitionen ein. Im CMMC gilt Software als Asset, sodass die Open-Source-Pakete auf einem System in Ihrem Bewertungsumfang denselben Anforderungen unterliegen wie die übrige Software dieses Systems. Ob ein System in den Bewertungsumfang fällt, hängt davon ab, wie es mit CUI umgeht: Ressourcen, die CUI verarbeiten, speichern oder übertragen, werden anhand aller Anforderungen der Stufe 2 bewertet. Der Umfang umfasst auch Ressourcen, die diese Systeme schützen, wie beispielsweise Firewalls und Identitätsdienste. Ein Build-Server oder eine Entwickler-Workstation, die niemals mit CUI in Berührung kommt, kann außerhalb des Umfangs liegen – dies ist die Abwägung hinsichtlich des Umfangs, auf die sich die Anforderung bezüglich benutzerinstallierter Software später stützt. Der Leitfaden des Verteidigungsministeriums (DoD) zum Bewertungsumfang enthält die vollständige Aufschlüsselung.
Das Risiko in der Lieferkette wird in zwei Anforderungen der Stufe 3 genannt, doch da Stufe 3 eine eigenständige Stufe mit einer eigenen, von der Regierung durchgeführten Bewertung ist, gilt keine der beiden Anforderungen für Stufe 2.
Vier Vorgehensweisen, die Ihren Abhängigkeitsbaum abdecken
Führen Sie ein Verzeichnis der auf dem System vorhandenen Komponenten (CM.L2-3.4.1). Sie müssen eine Liste der Hardware und Software führen, aus der jedes betroffene System besteht, einschließlich der Versionsnummern, und diese bei Änderungen am System auf dem neuesten Stand halten. Open Source spielt hier eine Rolle, da die Pakete in Ihrer Anwendung – einschließlich derer, die indirekt von anderen Paketen eingebunden werden – Software mit Versionsnummern sind. Wenn sie nicht auf der Liste stehen, ist die Liste unvollständig.
Kontrollieren Sie, was Benutzer installieren (CM.L2-3.4.9). Sie benötigen eine Richtlinie, welche Software Benutzer installieren dürfen, eine Möglichkeit, diese durchzusetzen, und eine Möglichkeit, zu überprüfen, was installiert wurde. Im erläuternden Text des NIST heißt es, dass die Richtlinie Software „mit unbekannter oder verdächtiger Herkunft“ verbieten kann – dies kommt in Stufe 2 der Frage nach der Herkunft der Software am nächsten. Diese Formulierung bezüglich der „Herkunft“ ist eine Orientierungshilfe und kann daher für sich genommen nicht zu Ihrem Nachteil gewertet werden. Die Anforderung selbst – eine Richtlinie darüber, was installiert werden darf, deren Durchsetzung sowie eine Aufzeichnung darüber, was installiert wurde – ist nicht optional. Wenn Ihre Build-Umgebung zum Bewertungsumfang gehört, können die Pakete, die Entwickler dort hinzufügen, wie jede andere Installation gewertet werden.
Führen Sie regelmäßig Schwachstellenscans durch (RA.L2-3.11.2). Sie müssen Systeme und Anwendungen in einem von Ihnen festgelegten Rhythmus scannen und zusätzliche Scans durchführen, sobald neue Schwachstellen bekannt gegeben werden. Open-Source-Pakete in Ihren Anwendungen sind Teil der zu scannenden Objekte.
Insgesamt decken die Anforderungen hinsichtlich Bestandsaufnahme, vom Benutzer installierter Software und Schwachstellen-Scans ab, was in Ihrer Build enthalten ist, was darin zulässig ist und welche bekannten Schwachstellen darin vorhanden sind. Der vierte Punkt, die zeitnahe Behebung von Schwachstellen (SI.L2-3.14.1), befasst sich damit, was geschieht, sobald eine Schwachstelle entdeckt wird.
Warum für die rechtzeitige Behebung von Fehlern eine von Ihnen festgelegte Zahl erforderlich ist
SI.L2-3.14.1 schreibt vor, Systemmängel rechtzeitig zu identifizieren, zu melden und zu beheben, doch weder in der Anforderung noch im erläuternden Text des NIST noch im Bewertungsleitfaden des DoD wird festgelegt, wie lange „rechtzeitig“ dauert. Alle drei überlassen es Ihnen, einen Zeitrahmen festzulegen, und das im Leitfaden selbst angeführte Beispiel nennt eine bestimmte Anzahl von Tagen, die sich nach dem Schweregrad des Fehlers richtet. Sie müssen lediglich nachweisen, dass Sie einen solchen Zeitrahmen definiert und eingehalten haben.
Ein Zeitrahmen, den Sie regelmäßig verpassen, hinterlässt eine Lücke in der Dokumentation, und ohne einen festgelegten Zeitrahmen kann die Bewertungscheckliste nicht ausgefüllt werden.
Der schwierigere Fall ist eine Komponente, die niemand mehr wartet, da vom Upstream-Entwickler kein Fix bereitgestellt wird. Der Leitfaden zählt angewendete Patches, Konfigurationsänderungen sowie Workarounds oder Abhilfemaßnahmen als Möglichkeiten zur Behebung eines Fehlers, sodass Ihnen mehrere Wege offenstehen. Sie können die Komponente ersetzen, auf eine neuere Release-Serie umsteigen, eine Abhilfe einrichten oder einen Fix auf die von Ihnen verwendete Version anwenden lassen – wobei jede dieser Maßnahmen unterschiedliche Spuren hinterlässt. Ein Austausch oder ein Upgrade setzt voraus, dass ein Ersatz oder eine neuere Serie existiert und dass Ihr Code die Änderung verkraften kann. Deshalb ist ein Upgrade nicht immer eine Option, insbesondere wenn die Komponente tief in der Projektstruktur verankert ist.
Was eine POA&M-Versicherung abdeckt und was nicht
Eine Bewertung führt für jede Anforderung zu einem von drei Ergebnissen („erfüllt“, „nicht erfüllt“ oder „nicht zutreffend“) sowie zu einem Gesamtstatus. Der Status „abgeschlossen“ bedeutet, dass alle Anforderungen erfüllt sind. Der Status „unter Vorbehalt“ bedeutet, dass noch einige Lücken bestehen, deren Beseitigung Sie zugesagt haben.
Die Bewertungsmethode der Richtlinie weist jeder Anforderung je nach dem potenziellen Schaden, den eine Lücke verursachen könnte, 1, 3 oder 5 Punkte zu. Sie beginnen mit 110 Punkten und verlieren für jede nicht erfüllte Anforderung Punkte. Von den vier Anforderungen, die für Ihre Open-Source-Pakete gelten, sind drei (Bestandsaufnahme, Schwachstellenscan und Behebung von Schwachstellen) jeweils fünf Punkte wert, während für vom Benutzer installierte Software ein Punkt vergeben wird.
Ein Aktionsplan mit Meilensteinen (POA&M) ermöglicht es Ihnen, einige Lücken über eine Bewertung hinaus zu übertragen, wobei Abschnitt 170.21 der Programmvorschrift dies stark einschränkt. Den Status „Bedingt“ – der einen POA&M zulässt – erhalten Sie nur bei einer Punktzahl von mindestens 88 von 110.
In den Plan dürfen nur Anforderungen aufgenommen werden, die einen Punkt wert sind, mit Ausnahme der Verschlüsselungsanforderung, die normalerweise fünf Punkte wert ist, aber auch dann aufgenommen werden kann, wenn sie mit drei Punkten bewertet wird, weil die verwendete Verschlüsselung nicht gemäß den Federal Information Processing Standards (FIPS) validiert ist. Die Regel schließt außerdem sechs spezifische Anforderungen unabhängig von der Punktzahl vom Plan aus: die Anforderung zum Systemsicherheitsplan, zwei Anforderungen zu externen Verbindungen und öffentlichen Informationen sowie drei Anforderungen zum physischen Zugriff.
Das Einfügen einer Lücke in den Plan ändert nichts an dessen Ergebnis, das so lange „NICHT ERFÜLLT“ bleibt, bis die Lücke geschlossen ist.
Jedes im Plan aufgeführte Vorhaben muss innerhalb von 180 Tagen abgeschlossen und bestätigt werden, andernfalls erlischt der Status „Bedingt“. Diese 180-tägige Frist für den Abschluss gilt sowohl für eine Selbstbewertung der Stufe 2 als auch für eine Bewertung durch Dritte.
Bestandsaufnahme, Schwachstellenscans und die Behebung von Sicherheitslücken sind Fünf-Punkte-Anforderungen, daher kann keine davon in den Plan aufgenommen werden: Entweder Sie erfüllen sie zum Zeitpunkt der Bewertung, oder Sie erhalten nicht den Status „Bedingt“. Vom Benutzer installierte Software ist eine Ein-Punkte-Anforderung, daher kann eine Lücke in diesem Bereich in den Plan aufgenommen werden, solange Ihre Gesamtpunktzahl weiterhin mindestens 88 beträgt. Sie gilt dennoch als „NICHT ERFÜLLT“ und muss innerhalb von 180 Tagen behoben werden.
Hinweis: Der operative Aktionsplan gemäß CA.L2-3.12.2 ist ein eigenständiges Dokument. Die Regel definiert ihn als Aufzeichnung vorübergehender Schwachstellen und Mängel sowie der Maßnahmen zu deren Behebung, ohne dass dabei ein Zeitrahmen festgelegt wird; er ist nicht mit einem Bewertungs-POA&M gleichzusetzen. Die 180-Tage-Frist bezieht sich auf den POA&M.
CMMC-Compliance-Anforderungen für Auftragnehmer und kleine Unternehmen
Die Programmvorschrift gilt für Auftragnehmer und Unterauftragnehmer des Verteidigungsministeriums (DoD), die im Rahmen ihrer Tätigkeit FCI oder CUI verarbeiten, speichern oder übertragen, und gilt auch für Unterauftragnehmer, die dies ebenfalls tun. Die Programmmanager des DoD legen die CMMC-Stufe für jede Beschaffung auf der Grundlage der betreffenden Informationen und der Kritikalität des Programms fest, sodass zwei Unternehmen gleicher Größe unterschiedliche Stufen erhalten können. Innerhalb von Stufe 2 gelten für alle die gleichen 110 Anforderungen.
Die Größe spielt in der Argumentation des Verteidigungsministeriums selbst eine Rolle. In der Ankündigung vom 13. Juli, mit der Phase 2 ausgesetzt wurde, hieß es, die Überprüfung des Ministeriums ziele darauf ab, Hindernisse für kleine und nicht-traditionelle Unternehmen abzubauen. Bis diese Überprüfung zu Änderungen führt, ist das System der Selbstbewertung die einzige bestehende Erleichterung.
Wo SecureChain zum Einsatz kommt
SecureChain von TuxCare stellt Open-Source-Pakete bereit, die vor der Bereitstellung an Sie geprüft und so lange mit Patches versorgt werden, wie Sie darauf angewiesen sind. Es dient als zentrale Quelle für JavaScript, Python, Java, Go, Rust und PHP.
Jedes Paket wird in isolierten Umgebungen aus dem Quellcode neu kompiliert und auf Malware sowie verdächtigen Code überprüft. Alles, was die Überprüfung nicht besteht, wird blockiert, bevor es in Ihre Umgebung gelangt. Aktive Komponenten werden im Rahmen einer Service-Level-Vereinbarung gepatcht. Wenn die Wartung durch den Upstream-Anbieter endet, stellt der „Endless Lifecycle Support“ (ELS) weiterhin Korrekturen für nicht mehr gewartete Komponenten bereit.
Außerdem erstellt das System Aufzeichnungen über die gelieferten Ergebnisse, darunter Herkunftsdaten gemäß „Supply-chain Levels for Software Artifacts“ (SLSA) Level 3, eine SBOM sowie VEX-Daten (Vulnerability Exploitability eXchange).
Was Sie vorlegen müssen
In den CMMC-Richtlinien taucht der Begriff „Open Source“ an keiner Stelle auf. Wenn Sie jedoch Ihre Systembestandsaufnahme, Ihre Scan-Ergebnisse und Ihre Aufzeichnungen darüber, was wann behoben wurde, bewerten, muss jedes Open-Source-Paket in Ihren Anwendungen in allen drei Dokumenten aufgeführt sein. Wenn Sie diese drei Unterlagen für ein Paket derzeit nicht vorlegen können, ist dies die Lücke, die Sie als Erstes schließen müssen.
FAQ
Was sind die CMMC-Compliance-Anforderungen?
Das Programm „Cybersecurity Maturity Model Certification“ (CMMC) legt Sicherheitsanforderungen für Verteidigungsunternehmen fest, die mit Federal Contract Information (FCI) oder Controlled Unclassified Information (CUI) umgehen. Stufe 1 umfasst 15 grundlegende Anforderungen, Stufe 2 umfasst die 110 Anforderungen aus der Norm SP 800-171, Revision 2, des National Institute of Standards and Technology (NIST), und Stufe 3 ergänzt diese um 24 ausgewählte Anforderungen aus der Norm SP 800-172.
Ab wann ist die Einhaltung der CMMC-Vorgaben im Jahr 2026 vorgeschrieben?
Das hängt vom Vertrag ab. Seit dem 10. November 2025 können neue Ausschreibungen des Verteidigungsministeriums im Rahmen des CMMC-Programms (Cybersecurity Maturity Model Certification) Selbstbewertungen der Stufe 1 oder 2 als Voraussetzung für die Auftragsvergabe vorschreiben. Phase 2, in deren Rahmen am 10. November 2026 Bewertungen der Stufe 2 durch Dritte eingeführt worden wären, ist seit dem 13. Juli 2026 ausgesetzt.
Welche CMMC-Compliance-Anforderungen gelten für kleine Unternehmen?
Kleine Unternehmen unterliegen denselben Anforderungen wie andere Auftragnehmer ihrer Stufe. Die Programmvorschriften legen Anforderungen je nach Art der verarbeiteten Informationen fest, und Stufe 2 umfasst eine Liste mit 110 Anforderungen, die für alle gelten. In der Ankündigung des Verteidigungsministeriums vom Juli 2026, einen Teil des Programms auszusetzen, hieß es, die Überprüfung ziele darauf ab, die Hürden für kleine und nicht-traditionelle Unternehmen zu senken.
Sind für CMMC-Stufe 2 Herkunftsnachweise für Open-Source-Software erforderlich?
Nein. Im Rahmen des „Cybersecurity Maturity Model Certification“ (CMMC)-Programms wird in keiner der 110 Anforderungen der Stufe 2 auf Open Source oder Herkunft Bezug genommen. In der Erläuterung zu vom Benutzer installierter Software (CM.L2-3.4.9) heißt es zwar, dass zu den verbotenen Installationen auch Software mit unbekannter oder verdächtiger Herkunft gehören kann, doch handelt es sich dabei lediglich um einen Erläuterungstext. Das Lieferkettenrisiko wird in zwei Anforderungen der Stufe 3 erwähnt.
Können ein Aktionsplan und Meilensteine die Behebung von Mängeln abdecken?
Das ist nicht möglich. Ein Aktionsplan und Meilensteine können – abgesehen von einer Ausnahme im Bereich Verschlüsselung – nur Anforderungen mit einem Punkt umfassen, und die Behebung von Schwachstellen (SI.L2-3.14.1) wird gemäß der Programmregel mit fünf Punkten bewertet. Ein Plan muss außerdem mindestens 88 von 110 Punkten erreichen und innerhalb von 180 Tagen abgeschlossen sein, sonst erlischt der Status „Bedingt“.
Wie gewährleistet man die Einhaltung der CMMC-Vorgaben nach einer Bewertung?
Im Rahmen des „Cybersecurity Maturity Model Certification“ (CMMC)-Programms muss ein zuständiger Beauftragter – also die Person, die befugt ist, die Einhaltung der Vorschriften durch das Unternehmen zu bestätigen – jedes Jahr die fortdauernde Einhaltung der Vorschriften bestätigen. Ein Status der Stufe 2 gilt drei Jahre lang, bevor eine neue Bewertung erforderlich ist, während Selbstbewertungen der Stufe 1 jährlich wiederholt werden.
