Sicherheit vordem Release entscheiden.
Sichere Entwicklung verbindet Anforderungen, Architektur, Code, Komponenten, Tests und Betrieb. Der Prozess hält diese Spur über eine konkrete Version zusammen. So bleibt erkennbar, warum ein Release freigegeben wurde und wie spätere Schwachstellen in die Pflege zurückfinden.
Ein Release trägt
seine Entscheidungen.
Entwicklung verantwortet den sicheren Lebenszyklus der gebauten oder wesentlich angepassten Lösung. Architektur setzt Prinzipien, Lieferanten steuern externe Leistungen, Schwachstellen bewerten spätere Befunde. Der Entwicklungsprozess verbindet diese Beiträge mit der freigegebenen Version.
| Arbeitsobjekt | Im Prozess zu entscheiden | Nachweis | Nicht verwechselt mit |
|---|---|---|---|
| Sicherheitsanforderung | Welche Schutzwirkung und Missbrauchsgrenze gelten für die Version? | Versionierte Anforderung mit Herkunft und Abnahme. | Allgemeiner Policy Text. |
| Entwurf | Wie werden Vertrauen, Datenfluss, Berechtigungen und Fehlerfälle beherrscht? | Architekturentscheid und Bedrohungsmodell. | Nachträglicher Penetrationstest. |
| Komponente | Welche Herkunft, Version, Lizenz, Schwachstelle und Pflegefähigkeit sind akzeptabel? | Komponentenbestand mit Freigabestatus. | Unverbundene SBOM Datei. |
| Release | Welche offenen Befunde, Ausnahmen und Betriebsbedingungen werden akzeptiert? | Freigabe mit Version, Owner und Restgefahr. | Erfolgreicher Build allein. |
| Pflege | Wie gelangen Meldungen, Updates und Supportende zurück in Produkt und Betrieb? | Verantworteter Updateweg und Supportstatus. | Projektabschluss. |
Sicherheit bleibt
versionsgebunden.
Jeder Schritt erzeugt ein Ergebnis, das in den nächsten eingeht. Automatisierte Prüfungen beschleunigen diese Kette, ersetzen aber weder Entwurfsentscheid noch Releaseverantwortung.
Bestimmen
Produkt, Release, Betriebsmodell und verantwortliche Pflege eindeutig abgrenzen.
Versionierter Umfang
Ableiten
Schutzbedarf, Bedrohungen, Architektur und anwendbare Pflichten übersetzen.
Prüfbare Anforderungen
Modellieren
Vertrauensgrenzen, Datenflüsse, Missbrauchsfälle und Sicherheitsprinzipien entscheiden.
Genehmigter Entwurf
Umsetzen
Code, Konfiguration und Abhängigkeiten in einer geschützten Umgebung erstellen.
Reproduzierbarer Build
Verifizieren
Anforderungen mit Review, Analyse und risikobasierten Sicherheitstests prüfen.
Bewertete Befunde
Freigeben
Offene Befunde, Ausnahmen, Betriebsbedingungen und Rückweg verbindlich entscheiden.
Releaseentscheid
Übergeben
Version, Komponenten, Konfiguration, Monitoring und Supportinformation bereitstellen.
Betriebsfähige Übergabe
Erhalten
Feldbeobachtungen, Schwachstellen und Updates bis zum Supportende zurückführen.
Beherrschter Lebenszyklus
Das Gate braucht
eine Stopplogik.
Ein Release Gate ist nur belastbar, wenn es einen offenen Punkt tatsächlich stoppen oder als befristete Ausnahme an einen befugten Risk Owner übergeben kann.
Version
Produktkennung, Build, Quellstand, Artefakte und ausgelieferte Variante stimmen überein.
Anforderungen
Sicherheitsanforderungen sind umgesetzt, geprüft oder mit begründeter Abweichung entschieden.
Komponenten
Abhängigkeiten, Herkunft, bekannte Befunde und Updatefähigkeit sind für den Release bekannt.
Tests
Testumfang, Ergebnis, Restlücken und Grenzen der eingesetzten Verfahren sind dokumentiert.
Betrieb
Härtung, Secrets, Logging, Wiederherstellung und sichere Standardkonfiguration sind übergeben.
Pflege
Meldeweg, Updateverantwortung, Supportzeitraum und Kundeninformation sind geklärt.
Offene Risiken
bleiben sichtbar.
Die Zahl gefundener Fehler hängt stark von Testtiefe und Produktgrösse ab. Aussagekräftiger sind Abdeckung, Alter und Entscheidungsstatus der Befunde sowie Wiederholungen gleicher Ursachen.
Freigaben mit nicht geprüften oder nicht zugeordneten Sicherheitsanforderungen.
Offene Abweichungen ohne Risk Owner, Ablaufdatum oder Betriebsbedingung.
Ausgelieferte Komponenten ohne Herkunft, Version oder tragfähigen Updateweg.
Zeit kritischer Befunde von der Bestätigung bis zur verifizierten Korrektur.
Schwachstellen aus bereits erkannten und angeblich behobenen Ursachen.
Unterstützte Releases ohne erreichbaren Meldeweg oder kontrollierte Updateauslieferung.
Sicher entwickeln.
Gezielt verpflichten.
Der gemeinsame Prozess gilt für eigene und beauftragte Entwicklung. Produktrechtliche Pflichten des CRA werden nur dort ergänzt, wo Produkt, Wirtschaftsakteur und Marktbezug in seinen Anwendungsbereich fallen.
Sicherer Lebenszyklus
Annex A.8.25 bis A.8.31 stützen sichere Entwicklung, Anforderungen, Architektur, Coding, Tests, Umgebungen und ausgelagerte Entwicklung.
SSDF 1.1
Ordnet sichere Softwareentwicklung in vorbereiten, schützen, sichere Software erzeugen und auf Schwachstellen reagieren.
Produktsicherheit
Verbindet Cyberrisikobeurteilung, Produktanforderungen, technische Dokumentation, Schwachstellenbehandlung, Updates und Support für erfasste Produkte.
Artikel 21
Nennt Sicherheit bei Erwerb, Entwicklung und Wartung von Netz und Informationssystemen einschliesslich Schwachstellenbehandlung.
Sicherheit wird
mitgeliefert.
Entwicklung übersetzt Sicherheitsanforderungen in überprüfbare Eigenschaften eines Produkts oder Services. Die Referenzen definieren den Rahmen, die Prozessübergaben machen ihn im Release wirksam.
| Referenz | Beitrag zum Prozess | Grenze |
|---|---|---|
| ISO/IEC 27001:2022 | A.8.25 bis A.8.31 betreffen sichere Entwicklung, Test, Auslagerung und Trennung von Umgebungen. | Ersetzt keine technische Secure-Development-Methodik. |
| NIST SSDF | Strukturiert sichere Entwicklungspraktiken über Organisation, Schutz, Produktion und Reaktion. | Ist kein Produktfreigabe-Gate ohne eigene Kriterien. |
| CRA | Kann für Produkte mit digitalen Elementen Anforderungen an sichere Entwicklung und Schwachstellenbehandlung auslösen. | Gilt nur für betroffene Produkte und Wirtschaftsakteure. |
| Inhalt | Beitrag | Weiter |
|---|---|---|
| 04 Architektur | Liefert Schutzprinzipien, Vertrauensgrenzen und begründete Zielbilder. | Prozess öffnen → |
| 17 Änderungen | Steuert Freigabe, Test und Rückfall im Übergang in den Betrieb. | Prozess öffnen → |
| 10 Schwachstellen | Übernimmt Befunde aus Entwicklung und Produktbetrieb in die Behandlungsentscheidung. | Prozess öffnen → |
Security Tool Navigator · Werkzeuge zum Prozess
Werkzeuge nach Gebiet einordnen.
Die Werkzeugklassen dieses Prozesses sind im Security Tool Navigator nach Sicherheitsgebieten geordnet. Die Gebietsseiten zeigen Abgrenzung, Auswahlfragen für CIO und CISO und alle Werkzeugklassen im Zusammenhang.