Insecure Software war früher teurer. Heute kann es gar nicht verkauft werden.

Zwei Fragen, der Reihe nach. Funktioniert eine Sicherheitsprüfung am Ende eines Builds tatsächlich? Und falls nicht, was muss stattdessen passieren?

CVE-1999-0001, der erste Eintrag in der Liste der Common Vulnerabilities and Exposures, dem öffentlichen Register, in dem offengelegte Software-Schwachstellen erfasst werden, war die erste Schwachstelle, die dort jemals verzeichnet wurde. Ein einziger Eintrag. Im Jahr 2025 verzeichnete diese Datenbank 48.185 neue Schwachstellen in einem einzigen Jahr, ein Rekord und mehr als 20 % mehr als im Vorjahr, laut dem 2025 CVE Data Review von JerryGamblin. Die Angriffsfläche ist nicht gewachsen. Sie ist explodiert, und der Großteil davon geht auf Sicherheitsanforderungen zurück, die niemand aufgeschrieben hat.

Die Regulierung wuchs mit, aber langsamer, und dann plötzlich überhaupt nicht mehr langsamer. Die DSGVO kam 2018 mit einem Grundsatz: Datenschutz durch Technikgestaltung. Sie war Gesetz, las sich aber wie ein guter Rat mit angehängter Strafe. Dann kamen NIS2, verbindlich seit Oktober 2024, und der Cyber Resilience Act, der schrittweise bis Dezember 2027 in Kraft tritt. Diese lesen sich nicht wie Ratschläge. NIS2 macht Führungskräfte persönlich für Versäumnisse im Cybersicherheits-Risikomanagement verantwortlich, so die Europäische Kommission. Der Cyber Resilience Act geht noch weiter: Ab Dezember 2027 darf ein Produkt ohne CE-Kennzeichnung, die belegt, dass es von Anfang an sicher entwickelt wurde, nirgendwo in der EU legal verkauft werden, so die eigene CRA-Zusammenfassung der Europäischen Kommission. Keine Geldbuße. Keine Verwarnung. Überhaupt kein Marktzugang.

Ein Krankenhaus führte letztes Jahr ein neues Patientenportal ein. Drei Wochen später fand ein Sicherheitsforscher heraus, dass das Ändern einer einzigen Zahl in der Adressleiste des Browsers die Akten eines anderen Patienten aufrief. Das Anforderungsdokument enthielt eine Zeile für „Patienten-Login“. Es enthielt keine Zeile dazu, was dieser Login preisgeben durfte. Niemand hatte diesen Teil aufgeschrieben, also hat ihn auch niemand gebaut.

Funktioniert eine Sicherheitsprüfung am Ende tatsächlich?

Nein, und der Grund ist struktureller Natur, keine Frage des Aufwands. Ein Anforderungsdokument sagt Entwicklern, was sie bauen sollen. Wenn es nicht festhält, was die Software niemals tun darf, Daten preisgeben, einen Audit-Trail auslassen, einen Verschlüsselungsstandard verfehlen, dann prüft auch nachgelagert niemand auf diese Dinge. Tests finden Fehler gemessen an einer Spezifikation. Sie können nicht das Fehlen einer Regel aufdecken, die nie geschrieben wurde.

Das ist die Lücke zwischen „Sicherheit vor der Auslieferung testen“ und „Sicherheit vor dem Bau spezifizieren“, und die meisten Unternehmen machen noch immer Ersteres. Es sieht nach Sorgfalt aus. Heraus kommen ein Penetrationstest-Bericht eine Woche vor dem Launch, eine Liste von Befunden und ein hektisches Nachbessern dessen, was die Architektur bereits voraussetzt. Bis dahin steht das Datenmodell, die Drittanbieter-Integrationen sind angebunden, und die Hälfte der Befunde erhält eine Ausnahmegenehmigung statt einer Korrektur, weil ein Neubau teuer ist und sich der Launch-Termin nicht verschiebt.

Die Europäische Kommission stützte ihre Begründung für den ursprünglichen Vorschlag des Cyber Resilience Act von 2022 auf Erkenntnisse, wonach rund 60 % der Produkte auf dem Markt bereits beim Launch mit bekannten Schwachstellen ausgeliefert wurden und zwei Drittel der Cyberangriffe auf eine Schwachstelle zurückgehen, die sich durch das Design hätte vermeiden lassen. „Europa ist nur so stark wie sein schwächstes Glied“, sagte Thierry Breton, EU-Kommissar für den Binnenmarkt, als der Cyber Resilience Act vorgeschlagen wurde. Er sprach nicht über Kosten. Er sprach darüber, welche Produkte auf dem europäischen Markt überhaupt existieren dürfen.

Wie sieht die Spezifikation zum Zeitpunkt der Anforderungen tatsächlich aus?

Nicht als längeres Anforderungsdokument. Sondern als ein anderes, bei dessen Erstellung Sicherheits- und Compliance-Verantwortliche mit am Tisch sitzen, statt es hinterher zu prüfen.

1. Schreiben Sie die Einschränkung direkt neben das Feature, nicht in ein separates Dokument, das niemand liest. „Benutzer können ihr Passwort zurücksetzen“ steht neben „Reset-Tokens laufen nach 15 Minuten ab und werden mit Zeitstempel und Anforderer-ID protokolliert“, denn die zweite Zeile ist das, was die Meldepflichten für Sicherheitsvorfälle unter NIS2 tatsächlich verlangen, und sie lässt sich im Nachhinein nicht aus funktionierendem Code ableiten.
2. Nennen Sie die Regulierung, aus der die Anforderung stammt. Nicht „sensible Daten verschlüsseln“, sondern „Daten bei der Übertragung und im Ruhezustand verschlüsseln, gemäß Cyber Resilience Act Anhang I, da dieses Produkt mit einer Netzwerkverbindung ausgeliefert wird“. Eine Anforderung ohne benannte Quelle ist die erste, die gestrichen wird, wenn sich die Deadline verschiebt.
3. Holen Sie jemanden, der die Regulierung versteht, in das Anforderungs-Review, nicht nur in das Sicherheits-Review. Bis ein Compliance-Beauftragter eine Spezifikation zu sehen bekommt, ist die Architektur meist schon festgelegt, und dann bedeutet „das hier ergänzen“ immer „das hier neu bauen“.
4. Behandeln Sie das Anforderungsdokument als Nachweis, nicht nur als Plan. Unter dem CRA müssen Hersteller nachweisen, wie ein Produkt seine grundlegenden Anforderungen erfüllt. Ein Anforderungsdokument, das die Einschränkung und ihre regulatorische Quelle bereits benennt, ist der Großteil dieses Nachweises: einmal geschrieben, nicht unter Zeitdruck vor einem Audit rekonstruiert.

Genau für diese Ebene ist die AI-Driven-Compliance-Practice von Calsoft gebaut: kontinuierliche Kontrollüberwachung und Nachweisautomatisierung, die noch lange nach dem Launch belegen, dass eine Anforderung weiterhin erfüllt ist, statt einer einmaligen Prüfung davor. Sobald eine Einschränkung in den Anforderungen festgeschrieben ist, zeigen Sie so fortlaufend, dass das System sie weiterhin einhält, und nicht nur, dass es das an dem Tag tat, an dem jemand abgezeichnet hat.

Das Krankenhaus aus dieser Geschichte hat den Fehler in der Zugriffskontrolle schließlich behoben. Die Korrektur dauerte einen Nachmittag. Das Vertrauen der Patienten, deren Akten offengelegt worden waren, zurückzugewinnen, dauerte erheblich länger, und kein Patch erreicht diesen Teil.

Die Unternehmen, die das 2027 gut machen, werden nicht diejenigen sein, die ihr Compliance-Review bestanden haben. Es werden diejenigen sein, bei denen das Review nichts zu beanstanden fand, weil die Anforderungen es bereits vorher festgehalten hatten.

FAQs

Warum sollten Sicherheitsanforderungen früh im SDLC definiert werden?

Tests prüfen nur, was gebaut wurde, gemessen an einer Spezifikation. Wenn Sicherheitsanforderungen nie in dieser Spezifikation auftauchen, bemerkt nachgelagert niemand ihr Fehlen. Unter dem Cyber Resilience Act ist eine fehlende Anforderung kein spät gefundener Fehler, sondern eine Compliance-Lücke, die ein Produkt vollständig vom EU-Markt ausschließen kann.

Wie übersetzt man Compliance-Anforderungen in Software-Anforderungen?

Schreiben Sie die Formulierung der Regulierung direkt in die Spezifikation, nicht als Fußnote. Statt „sensible Daten verschlüsseln“ schreiben Sie „Daten bei der Übertragung und im Ruhezustand verschlüsseln, gemäß Cyber Resilience Act Anhang I“. Eine Anforderung ohne benannte regulatorische Quelle ist in der Regel die erste, die gestrichen wird, wenn sich eine Deadline verschiebt.

Wie hält man Sicherheits- und Compliance-Anforderungen aktuell, wenn sich Regulierungen ändern?

Behandeln Sie das Anforderungsdokument als lebenden Nachweis, nicht als einmalige Freigabe. NIS2 und der Cyber Resilience Act führen ihre Pflichten schrittweise über mehrere Jahre ein. Deshalb ist es die kontinuierliche Überwachung, nicht die periodische Überprüfung, die zeigt, dass ein System eine Anforderung auch dann noch erfüllt, wenn sich die zugrunde liegende Regulierung ändert.