Sichere Entwicklung nach NIS2, ISO 27001 und CRA. Was verlangt wird, was ein laufender Scan belegt.
Vier Regelwerke sprechen über Sicherheit im eigenen Code. Keines schreibt ein Scanner-Produkt vor. Diese Seite zeigt die Stellen, sagt offen, wo keine ausdrückliche Pflicht steht, und ordnet ein, welchen Nachweis ein Scan bei jedem Commit dafür liefert.
Wer im Audit gefragt wird, wie Schwachstellen im eigenen Code behandelt werden, braucht zwei Dinge: die richtige Stelle im Regelwerk und einen datierten Beleg. Das eine liefert diese Seite. Das andere entsteht im laufenden Scan, mit Fund, Maßnahme und Datum.
Wo sichere Entwicklung tatsächlich steht.
Zwei davon sind Pflichtenkataloge, eines gilt nur für Hersteller, eines ist gar kein Gesetz. Der Unterschied entscheidet darüber, was Du im Audit vorlegen musst.
Sicherheit bei Erwerb, Entwicklung und Wartung
Der Maßnahmenkatalog der Richtlinie hat einen eigenen Buchstaben für den Umgang mit Systemen über ihren Lebenszyklus: beschaffen, entwickeln, warten, Schwachstellen behandeln und offenlegen. Deutschland hat das in § 30 BSIG übernommen. Wer eigenen Code betreibt, ist mit jeder Lücke darin in diesem Buchstaben zu Hause. Wie er sie findet, lässt der Gesetzgeber offen.
Sicherer Entwicklungslebenszyklus
Mit der Revision 2022 hat die Norm der sicheren Entwicklung vier eigene Nummern gegeben: den Lebenszyklus der Entwicklung (A.8.25), die Anforderungen an die Anwendungssicherheit (A.8.26), die sichere Codierung selbst (A.8.28) und, quer dazu, den technischen Umgang mit Schwachstellen (A.8.8). Ein Auditor fragt jede dieser Nummern einzeln ab.
Pflichten für Produkte mit digitalen Elementen
Anders als NIS2 richtet sich die Verordnung nicht an Betreiber, sondern an diejenigen, die Software oder vernetzte Geräte auf den Markt bringen. Für sie beginnt die Verantwortung mit dem Inverkehrbringen und endet nicht damit. Zeitlich gestaffelt: in Kraft seit dem 10. Dezember 2024, Meldung aktiv ausgenutzter Schwachstellen seit dem 11. September 2026, die übrigen Pflichten ab dem 11. Dezember 2027. Ein Unternehmen, das Software nur im eigenen Haus einsetzt, steht nicht auf dieser Liste.
Der fachliche Referenzrahmen
Die Top 10 sind eine Rangliste, keine Vorschrift: die zehn Risikoklassen, die in Anwendungen am häufigsten zu Vorfällen führen, alle paar Jahre neu sortiert. In der Ausgabe 2025 führt die fehlerhafte Zugriffskontrolle, und die Software-Lieferkette ist erstmals in die ersten drei aufgerückt. Wir nutzen die Liste als Reihenfolge, in der Funde bewertet werden. Wer sie als Zertifikat verkauft, hat sie nicht gelesen.
Zur Einordnung, bevor jemand eine Kaufpflicht daraus liest: In keinem der vier Texte wird ein Scanner vorgeschrieben. Verlangt wird ein Ergebnis, nämlich Schwachstellen kennen, bewerten und beheben, nicht ein Produkt. Und der CRA gilt nur für Hersteller. Was ein laufender Scan leistet, ist die Dokumentation dieses Ergebnisses mit Datum. Mehr behaupten wir nicht.
Welcher Beleg zu welcher Stelle passt.
Ein Audit fragt selten nach dem Werkzeug. Es fragt, ob eine Anforderung umgesetzt ist und womit Du das zeigst. So sieht die Zuordnung aus.
- Schwachstellenmanagement
§ 30 BSIG, ISO A.8.8
Alle Abhängigkeiten werden gegen bekannte Schwachstellen geprüft. Wird eine Bibliothek aktualisiert, stehen Fund, Maßnahme und Datum in der Dokumentation.
- Sichere Codierung
ISO A.8.28
Unsichere Muster wie ungeprüfte Eingaben, gefährliche Systemaufrufe und fehlende Zugriffskontrollen werden bei jedem Commit erkannt, nicht einmal im Jahr zum Prüftermin.
- Umgang mit Zugangsdaten
§ 30 BSIG, ISO A.8.28
Hartkodierte Passwörter, Schlüssel und Tokens werden gefunden, auch im Verlauf des Repositories, und kritische Secrets werden rotiert statt nur gemeldet.
- Entwicklungslebenszyklus
ISO A.8.25, A.8.26
Jede Änderung wird im Zusammenhang der Codebasis bewertet, bevor der Code weiterläuft. Das ist der Nachweis, dass Sicherheit im Prozess steckt und nicht nur im Jahresbericht.
Drei Dinge, die ein Scan nicht leistet. Und die wir nicht behaupten.
Er ersetzt keinen Penetrationstest.
Der Scan arbeitet an einer Stelle: im Code, bei jeder Änderung, gegen bekannte Muster. Ein Penetrationstest setzt außen an und versucht, das laufende System als Ganzes zu überwinden, samt Netz, Konfiguration und Menschen. Wer den einen hat, hat den anderen nicht. Was ein Test leisten muss und was nach dem Bericht passiert, steht auf unserer Seite zum Penetrationstest.
Er findet keine Geschäftslogik-Fehler.
Ob ein Sachbearbeiter die Rechnungen einer fremden Abteilung sehen darf, steht in keinem Muster, sondern in der Fachlichkeit. Solche Fehler in der Berechtigungslogik erkennt keine automatische Analyse, und ein Nachweis, der so tut, wäre falsch. Wir schreiben ihn nicht.
Er ist kein Zertifikat.
Der Scan erzeugt Belege für einzelne Controls. Ein ISMS, eine Zertifizierung oder die Wirksamkeitsbewertung nach § 30 BSIG bleiben eigene Schritte, die er unterstützt, aber nicht abnimmt.
Von der Anbindung zur datierten Akte.
Anbindung
Repositories werden angebunden, der Bestand wird erstmalig auf Secrets, verwundbare Abhängigkeiten und unsichere Muster gescannt.
Erster Befund
Ein klarer Bericht: welche Funde echt und kritisch sind, welche warten können und was zuerst passieren muss.
Aufräumen
Kritische Secrets rotiert, verwundbare Bibliotheken aktualisiert, gefährliche Muster entschärft. Jede Maßnahme datiert.
Belegen
Ab jetzt bei jedem Commit. Neue kritische Funde werden sofort bearbeitet, und die Dokumentation wächst mit, statt vor dem Audit gesammelt zu werden.
Fragen zu Code-Sicherheit und Compliance
Ist ein Code-Scanner nach NIS2 Pflicht?
Nein. Vorgeschrieben ist das Ergebnis: Schwachstellen in eigenen Systemen kennen, behandeln und offenlegen können, § 30 BSIG. Womit ein Unternehmen das erreicht, steht ihm frei. Der Grund, warum wir trotzdem zum Scan raten, ist der Nachweis: Er hinterlässt zu jedem Fund ein Datum und eine Maßnahme, und genau danach fragt eine Aufsicht.
Gilt der Cyber Resilience Act für unser Unternehmen?
Die Frage ist, ob Ihr etwas mit Software darin verkauft: eine Maschine mit Steuerung, ein Gerät mit App, ein Softwareprodukt. Dann seid Ihr Hersteller im Sinne der Verordnung, und die Fristen laufen, seit dem 11. September 2026 die Meldung ausgenutzter Schwachstellen, ab dem 11. Dezember 2027 der Rest. Nutzt Ihr Software nur selbst, betrifft Euch der CRA nicht, NIS2 aber möglicherweise schon.
Reicht der Scan als Nachweis für ISO 27001?
Er belegt die Controls A.8.25, A.8.26 und A.8.28 zur sicheren Entwicklung sowie A.8.8 zum Schwachstellenmanagement mit datierten Funden und Maßnahmen. Ein Managementsystem und die Zertifizierung selbst bleiben eigene Schritte, die der Scan unterstützt, aber nicht ersetzt.
Was steht konkret im Nachweis?
Zu jedem Fund die Einordnung nach echtem Risiko, die umgesetzte Maßnahme und das Datum: Secret rotiert, Bibliothek aktualisiert, Muster entschärft. Falschmeldungen werden aussortiert, bevor sie in der Akte landen.
Ersetzt das einen Penetrationstest?
Nein. Beide Prüfungen beantworten verschiedene Fragen: der Scan, ob im Code bekannte Fehlerklassen stecken, der Test, ob ein Angreifer von außen durchkommt. Ein Auditor, der einen Pentest sehen will, akzeptiert keinen Scan-Bericht als Ersatz, und umgekehrt.
Welche Nachweise fehlen Dir heute für § 30 BSIG oder A.8.28?
Kostenlose Code-Analyse, klares Ergebnis, keine Verpflichtung.