- Wichtige Erkenntnisse
- Was ist eine sichere Software-Attestierung?
- Executive Order 14028: Wo alles begann
- Das CISA-Bescheinigungsformular für sichere Softwareentwicklung
- Das Secure Software Development Framework (SSDF)
- Wichtig: Diese Richtlinie wird fortlaufend weiterentwickelt.
- Wie Codesignierung und kryptografische Inventarisierung die Attestierung unterstützen
- Wie Verschlüsselungsberatung hilft
- Häufig gestellte Fragen
- Sammeln Sie die Beweise für Ihre Bestätigung
Die Zertifizierung sicherer Software ist eine Anforderung der Executive Order 14028, nach der Softwarehersteller, deren Software von der US-Bundesregierung genutzt wird, formell bestätigen müssen, dass sie die sicheren Entwicklungspraktiken des NIST Secure Software Development Framework (SSDF) einhalten. Die Zertifizierung erfolgt mittels des CISA Secure Software Development Attestation Form. Starke Nachweise über Codesignierung und kryptografische Inventarisierung unterstützen diese Zertifizierungen.
Die Zertifizierung sicherer Software ist das Verfahren der US-Regierung, um sicherzustellen, dass die von ihr erworbene Software sicher entwickelt wurde. Gemäß Executive Order 14028 müssen Softwarehersteller, die an Bundesbehörden verkaufen, formell bestätigen, dass sie sichere Entwicklungspraktiken auf Basis des NIST Secure Software Development Framework (SSDF) mithilfe eines standardisierten CISA-Formulars einhalten. Gute Verfahren zur Codesignierung und Inventarisierung liefern den Nachweis für diese Zertifizierung.
Wichtige Erkenntnisse
- Mit der Executive Order 14028 (Mai 2021) wurden bundesweite Sicherheitsanforderungen für die Software-Lieferkette eingeführt, einschließlich der Zertifizierung sicherer Software.
- Softwarehersteller, die an die US-Regierung verkaufen, müssen selbst bestätigen, dass sie die sicheren Entwicklungspraktiken des NIST SSDF (NIST SP 800-218) einhalten. Hierfür verwenden sie das Secure Software Development Attestation Form der CISA.
- Das Formular wird vom CEO oder einem autorisierten Vertreter des Unternehmens unterzeichnet; alternativ zur Selbstauskunft kann ein FedRAMP-Drittanbieter (3PAO) eingesetzt werden.
- Die Richtlinie hat sich geändert: Eine Exekutivverordnung vom Juni 2025 hob die Anfang 2025 eingeführten erweiterten Anforderungen an Artefakte und Validierungen auf und führte das ursprüngliche Selbstbestätigungsverfahren wieder ein. Die genauen Anforderungen entwickeln sich weiterhin.
- Starke Codesignatur (sichere Schlüssel, signierte Builds, Herkunftsnachweis) und ein kryptografisches und Komponenteninventar sind praktische Belege, die diese Zusicherungen stützen.
Was ist eine sichere Software-Attestierung?
Die Zertifizierung sicherer Software ist eine formelle Erklärung eines Softwareherstellers, dass seine Software gemäß anerkannten sicheren Entwicklungsmethoden entwickelt wurde. Ziel ist der Schutz der Software-Lieferkette: Nach aufsehenerregenden Lieferkettenangriffen verlangt die US-Regierung, dass jegliche von ihr verwendete Software in einer sicheren Umgebung mit Kontrollmechanismen entwickelt wird, die das Risiko von Manipulationen oder versteckten Schwachstellen minimieren. Anstatt die Prozesse jedes Anbieters direkt zu überprüfen, verlangt die Regierung von den Anbietern eine offizielle und gegenüber der Geschäftsleitung nachvollziehbare Bestätigung, dass sie einen definierten Mindeststandard an sicheren Praktiken erfüllen.
Executive Order 14028: Wo alles begann
Im Mai 2021 wurde mit der Executive Order 14028 „Verbesserung der nationalen Cybersicherheit“ eine Reihe von Initiativen der Bundesregierung zur Cybersicherheit angestoßen, darunter ein Schwerpunkt auf der Sicherheit der Software-Lieferkette. Das Nationale Institut für Standards und Technologie (NIST) wurde beauftragt, Richtlinien für die sichere Softwareentwicklung zu erarbeiten, die als Secure Software Development Framework (SSDF), NIST SP 800-218, veröffentlicht wurden. Zudem wurde die Grundlage dafür geschaffen, dass Softwarehersteller die Einhaltung dieser Praktiken bestätigen müssen. Das Office of Management and Budget (OMB) erließ daraufhin die Memoranden M-22-18 und M-23-16, die Bundesbehörden anwiesen, diese Selbstauskünfte von ihren Softwareanbietern einzuholen.
Das CISA-Bescheinigungsformular für sichere Softwareentwicklung
Um die Zertifizierung von Anbietern zu standardisieren, entwickelte CISA (gemeinsam mit OMB) das Formular zur Bestätigung der sicheren Softwareentwicklung, auch bekannt als „Common Form“. Die endgültige Fassung wurde im März 2024 zusammen mit einem Repository für Einreichungen veröffentlicht. Wichtige Punkte zum Formular:
- Was es abdeckt: Der Hersteller bestätigt, dass seine Software gemäß spezifischen Sicherheitspraktiken aus dem NIST SSDF entwickelt wurde, die die Entwicklungsumgebung, den Schutz der Codeintegrität und die Offenlegung bekannter Schwachstellen umfassen.
- Wer unterschreibt: Das Formular muss vom CEO des Softwareherstellers oder einem bevollmächtigten Vertreter unterzeichnet werden, der das Unternehmen rechtsverbindlich vertreten kann, wodurch die Verantwortlichkeit auf die Führungsebene verlagert wird.
- Selbstauskunft oder Bestätigung durch Dritte: Ein Hersteller kann entweder eine Selbstauskunft abgeben oder eine zertifizierte FedRAMP-Drittanbieter-Prüforganisation (3PAO) beauftragen, die Konformität mit dem SSDF zu bestätigen.
- Welche Software ist abgedeckt? Dies gilt für Software, die von Bundesbehörden verwendet wird, einschließlich neu entwickelter Software, Hauptversionsaktualisierungen und Software, die über kontinuierliche Updates (wie SaaS) bereitgestellt wird.
Das Secure Software Development Framework (SSDF)
Die SSDF (NIST SP 800-218) bildet die Grundlage der Zertifizierung. Es handelt sich um eine Reihe von Best Practices für die sichere Softwareentwicklung, die in vier Bereiche unterteilt sind. Vereinfacht ausgedrückt:
| SSDF-Gruppe | Was es bedeutet |
|---|---|
| Bereiten Sie die Organisation vor | Stellen Sie sicher, dass Menschen, Prozesse und Technologie bereit sind, Software sicher zu entwickeln. |
| Schützen Sie die Software | Schützen Sie alle Komponenten der Software vor Manipulation und unberechtigtem Zugriff, einschließlich der Sicherstellung der Codeintegrität und der Signierung. |
| Produzieren Sie gut gesicherte Software | Software so entwerfen, entwickeln und testen, dass Sicherheitslücken vor der Veröffentlichung minimiert werden. |
| Auf Schwachstellen reagieren | Kontinuierliche Identifizierung, Offenlegung und Behebung von Schwachstellen. |
Wichtig: Diese Richtlinie wird fortlaufend weiterentwickelt.
Die Anforderungen an die Zertifizierung sicherer Software (Secure Software Attestation, SSDF) sind einem ständigen Wandel unterworfen. Die Executive Order 14028 (2021) und die OMB-Memoranden sind weiterhin gültig, und das CISA-Selbstzertifizierungsformular wird nach wie vor verwendet. Im Januar 2025 zielte eine weitere Executive Order (EO 14144) darauf ab, die Regelungen zu stärken, indem maschinenlesbare Zertifizierungen, unterstützende Dokumente und eine Validierung durch die CISA eingeführt wurden. Im Juni 2025 wurden diese Verbesserungen durch eine nachfolgende Executive Order wieder aufgehoben, wodurch der ursprüngliche Selbstzertifizierungsansatz ohne die obligatorischen Dokumente und die Validierungsebene wiederhergestellt wurde. Parallel dazu wird an einer Regelung der Federal Acquisition Regulation (FAR) zur Formalisierung der Anforderungen gearbeitet, und das NIST wurde angewiesen, das SSDF zu aktualisieren.
Die praktische Schlussfolgerung: Die Anforderung, sichere Softwareentwicklung nachzuweisen, besteht weiterhin und wird voraussichtlich auch künftig bestehen bleiben. Die konkreten Mechanismen (Artefakte, Validierung, FAR-Formulierungen) werden jedoch noch festgelegt. Softwarehersteller sollten unabhängig davon die zugrundeliegenden Sicherheitspraktiken implementieren, da diese die Basis jeder Version der Richtlinie bilden. Prüfen Sie die aktuellen Anforderungen stets anhand offizieller Quellen von CISA, OMB und FAR, bevor Sie sich auf einzelne Details verlassen.
Wie Codesignierung und kryptografische Inventarisierung die Attestierung unterstützen
Ein oft übersehener, entscheidender Punkt: Eine Bescheinigung ist eine Behauptung, und Behauptungen sind überzeugender, wenn sie durch Beweise untermauert werden können. Mehrere SSDF-Praktiken, insbesondere jene unter „Schutz der Software“, lassen sich direkt auf Codesignierung, kryptografische Verfahren und die Komponenteninventarisierung übertragen. Der Nachweis dieser Aspekte macht eine Bescheinigung nicht nur zu einem Wunschtraum, sondern zu einer vertretbaren Grundlage.
- Codeintegrität und Herkunft: Die SSDF fordert den Schutz der Codeintegrität und die Überprüfung, ob Software manipuliert wurde. Signieren Sie Ihre Builds und Releases mit Schlüsseln, die in einem geschützten System gespeichert sind. HSM, liefert einen kryptografischen Nachweis der Integrität und Herkunft, und die vertrauenswürdige Zeitstempelung sorgt dafür, dass diese Signaturen über die Zeit gültig bleiben.
- Schutz des Unterzeichnungsprozesses: Sichere Entwicklung erfordert, dass Signaturschlüssel geschützt sind und die Signierung in einer kontrollierten, nachvollziehbaren Umgebung erfolgt, nicht auf den Laptops der Entwickler. Zentralisierte, richtlinienbasierte Signaturverfahren erzeugen die entsprechenden Prüfprotokolle.
- Die Komponenten kennen: Das SSDF und die zugehörigen Richtlinien betonen, wie wichtig es ist, zu wissen, was sich in der eigenen Software befindet. Eine Software-Stückliste (SBOM) und eine kryptografische Stückliste (CBOM) Erstellen Sie ein Inventar Ihrer Komponenten und der von Ihnen verwendeten Kryptografie, um die Offenlegung von Sicherheitslücken und (zunehmend) die Erwartungen an die Quantenfähigkeit zu erfüllen.
- Laufende Beweise: Die Attestierung ist kein einmaliger Vorgang. Kontinuierliche Signierung, Inventarisierung und Überwachung liefern fortlaufende Nachweise, die Ihre Attestierung bei Softwareänderungen unterstützen.
Wie Verschlüsselungsberatung hilft
Encryption Consulting unterstützt Softwarehersteller dabei, Anforderungen an die sichere Entwicklung in nachweisbare Praxis umzusetzen. CodeSign Secure sichert Ihre Signaturschlüssel in einem HSM, zentralisiert und automatisiert die Codesignierung in Build-Pipelines mit Richtliniendurchsetzung und vollständigen Audit-Trails und wendet vertrauenswürdige Zeitstempel an. Dies unterstützt direkt die Codeintegritätspraktiken des SSDF hinter einer Attestierung. CBOM Secure bietet kryptografische Erkennung und Inventarisierung und ermöglicht Ihnen so die Transparenz der Kryptografie und Komponenten Ihrer Software. Dies unterstützt das Schwachstellenmanagement, die Transparenz der Lieferkette und die Post-Quanten-Bereitschaft. Zusammen bieten sie Ihnen die Grundlage für eine zuverlässige Attestierung. Unterstützt durch ISO/IEC 27001:2022- und SOC 2-zertifizierte Verfahren.
Häufig gestellte Fragen
Was ist EO 14028?
Die Exekutivanordnung 14028 mit dem Titel „Verbesserung der nationalen Cybersicherheit“ wurde im Mai 2021 erlassen. Sie stieß eine Reihe von Cybersicherheitsinitiativen der US-Bundesregierung an, darunter ein Schwerpunkt auf der Sicherheit der Software-Lieferkette. Unter anderem wurde das NIST beauftragt, Richtlinien für die sichere Softwareentwicklung zu erstellen, die zum Secure Software Development Framework (SSDF, NIST SP 800-218) wurden. Damit wurde die Grundlage geschaffen, um von Herstellern von Software, die von der Bundesregierung genutzt wird, die Einhaltung sicherer Entwicklungspraktiken zu bestätigen. Das SSDF bildet weiterhin die Basis für die Zertifizierungsanforderungen der Bundesregierung für sichere Software.
Was ist das CISA-Bescheinigungsformular für sichere Softwareentwicklung?
Es handelt sich um ein standardisiertes Formular, auch bekannt als Common Form, mit dem Softwarehersteller, deren Software von US-Bundesbehörden genutzt wird, bestätigen, dass sie die sicheren Entwicklungspraktiken des NIST SSDF einhalten. CISA veröffentlichte die finale Version im März 2024 zusammen mit einem Repository für Einreichungen. Das Formular muss vom CEO des Herstellers oder einem Bevollmächtigten unterzeichnet werden, wodurch die Verantwortung auf Führungsebene liegt. Alternativ zur Selbstauskunft kann ein Hersteller einen zertifizierten FedRAMP-Drittanbieter (3PAO) mit der Bestätigung der SSDF-Konformität beauftragen.
Wer muss die Sicherheitszertifizierung für Software einhalten?
Die Anforderung gilt für Hersteller von Software, die von US-Bundesbehörden genutzt wird. Sie umfasst neu entwickelte Software, Hauptversionsaktualisierungen bestehender Software sowie Software, die über kontinuierliche Updates wie Software-as-a-Service (SaaS) bereitgestellt wird. Wenn ein Unternehmen Software an die Bundesregierung verkauft oder dies plant, ist die Zertifizierung faktisch Voraussetzung für die Geschäftstätigkeit, da die Behörden sie für die Nutzung der Software benötigen. Auch Organisationen, die nicht an die Regierung verkaufen, wenden häufig dieselben Verfahren an, da diese allgemein anerkannte Sicherheitserwartungen für die Software-Lieferkette widerspiegeln.
Ist die Zertifizierung sicherer Software im Jahr 2026 noch erforderlich?
Die grundlegende Anforderung, die sichere Entwicklung zu bestätigen (gemäß EO 14028 und den OMB-Memoranden), bleibt bestehen, und das CISA-Formular wird weiterhin verwendet. Die Details haben sich jedoch geändert: Eine Exekutivanordnung vom Januar 2025 führte erweiterte Anforderungen ein (maschinenlesbare Bestätigungen, Artefakte und CISA-Validierung), während eine Exekutivanordnung vom Juni 2025 diese Erweiterungen wieder aufhob und zum ursprünglichen Selbstbestätigungsverfahren zurückkehrte. Eine formale FAR-Regelung steht noch aus. Da sich die Verfahren ständig weiterentwickeln, sollten Sie die aktuellen Anforderungen stets anhand offizieller Quellen von CISA, OMB und FAR überprüfen.
Was ist die SSDF?
Das Secure Software Development Framework (SSDF), veröffentlicht vom NIST als SP 800-218, ist eine Sammlung empfohlener Praktiken für die sichere Softwareentwicklung. Es ist in vier Gruppen unterteilt: Vorbereitung der Organisation, Schutz der Software, Entwicklung sicherer Software und Reaktion auf Sicherheitslücken. Das SSDF bildet die Grundlage für die bundesstaatliche Zertifizierungspflicht. Mit der Zertifizierung bestätigt ein Hersteller die Einhaltung der im SSDF festgelegten Praktiken. Das NIST aktualisiert das Framework regelmäßig; Hersteller sollten daher die jeweils aktuelle Version beachten.
Wie trägt die Codesignierung zu einer sicheren Softwareattestierung bei?
Die Codesignierung liefert konkrete Belege für verschiedene SSDF-Praktiken, insbesondere solche zum Schutz der Softwareintegrität. Das Signieren von Builds und Releases mit in einem HSM gesicherten Schlüsseln liefert den kryptografischen Beweis, dass die Software authentisch und unverändert ist, und die vertrauenswürdige Zeitstempelung gewährleistet die Gültigkeit dieser Signaturen über die Zeit. Die zentralisierte, richtlinienbasierte Signierung mit Audit-Trails belegt zudem, dass die Signierung in einer kontrollierten Umgebung und nicht auf den Rechnern einzelner Entwickler erfolgt. In Kombination mit einer Stückliste für Software und Kryptografie wird so aus einer bloßen Behauptung eine fundierte, beweisgestützte Bestätigung.
Sammeln Sie die Beweise für Ihre Bestätigung
Sichere Software-Attestierung basiert auf nachweisbaren Verfahren. Entdecken Sie CodeSign Secure und CBOM Secure von Encryption Consulting , um Ihre Signaturen abzusichern, Ihre Schlüssel zu schützen und Ihre Kryptografie und Komponenten zu inventarisieren. So können Sie die Sicherheit Ihrer Entwicklung mit entsprechenden Nachweisen belegen.
- Wichtige Erkenntnisse
- Was ist eine sichere Software-Attestierung?
- Executive Order 14028: Wo alles begann
- Das CISA-Bescheinigungsformular für sichere Softwareentwicklung
- Das Secure Software Development Framework (SSDF)
- Wichtig: Diese Richtlinie wird fortlaufend weiterentwickelt.
- Wie Codesignierung und kryptografische Inventarisierung die Attestierung unterstützen
- Wie Verschlüsselungsberatung hilft
- Häufig gestellte Fragen
- Sammeln Sie die Beweise für Ihre Bestätigung
