Secure SDLC
Die IEC 62443-4-1 beschreibt, was ein sicherer Entwicklungsprozess erreichen muss. Sie sagt nicht, wie er in Ihrem Unternehmen funktionieren soll — mit Ihren Produkten, Ihrer Teamgröße und Ihrer Toolchain. Wir bauen diesen Zyklus und binden ihn danach in Ihre KI-Werkzeuge ein, damit die Nachweise mit dem Code Schritt halten.
Warum überführen
Die Norm ist so geschrieben, dass sie für jeden Hersteller industrieller Produkte gilt — vom Zwei-Personen-Firmwareteam bis zum Konzern. Genau diese Allgemeingültigkeit macht eine unveränderte Übernahme unmöglich: Sie legt Ergebnisse fest und überlässt die Prozessgestaltung Ihnen.
Ein heruntergeladenes Richtlinienpaket scheitert aus einem einfachen Grund. Ein Auditor prüft nicht Ihre Dokumente gegen die Norm, sondern ob Ihre Organisation tut, was die Dokumente behaupten. Ein Zyklus, der Arbeit beschreibt, die niemand ausführt, erzeugt schneller Feststellungen als gar kein Dokument.
Das Ziel ist deshalb keine Dokumentation, die die Norm erwähnt. Es ist ein Zyklus, dem Ihre Entwickler folgen, weil er zu ihrer Arbeitsweise passt — und der Auditnachweise als Nebenprodukt erzeugt.
Stufe 1
Jede Praktik wird im Audit separat bewertet. Eine nicht abgedeckte Praktik begrenzt daher Ihr Reifegradergebnis, unabhängig davon, wie stark die übrigen sind. Wir arbeiten alle acht ab — in der Reihenfolge, in der eine die nächste speist.
Einen verantwortlichen Prozesseigner benennen, Security Champions in den Produktteams etablieren statt einer abgekoppelten zentralen Funktion, und vorhandene Sicherheitsexpertise gegen die benötigten Rollen abgleichen. Lücken werden zu einem Schulungsplan mit Aufzeichnungen — Kompetenz ist auditierbar, nicht unterstellt. Umfasst außerdem die Kontrolle von Drittanbieter- und Open-Source-Komponenten sowie die Sicherheit der Entwicklungsumgebung selbst.
Den Produktsicherheitskontext definieren: wo das Produkt eingesetzt wird, womit es verbunden ist, welche Aufgaben ihm anvertraut werden und welche Angreifer relevant sind. Das Bedrohungsmodell baut auf diesem Kontext auf; die Sicherheitsanforderungen werden daraus abgeleitet, sodass jede auf eine Bedrohung zurückführt und nicht auf eine generische Checkliste.
Anforderungen in Design übersetzen: Vertrauensgrenzen, minimale Rechte, Fehlerverhalten und gestaffelte Maßnahmen, damit keine einzelne Schutzschicht alles trägt. Designreviews und Aktualisierungen des Bedrohungsmodells finden an definierten Punkten statt, Feststellungen werden bis zum Abschluss verfolgt statt notiert und vergessen.
Für jede eingesetzte Sprache einen dokumentierten sicheren Programmierstandard einführen, durchgesetzt per Linter und statischer Analyse, soweit automatisierbar. Das Implementierungsreview prüft anschließend, ob das Sicherheitsdesign im Code tatsächlich umgesetzt wurde. Diese Praktik gilt für KI-generierten Code genauso wie für handgeschriebenen.
Vier eigenständige Tätigkeiten, die die Norm getrennt behandelt und Auditoren einzeln prüfen: funktionale Prüfung der Sicherheitsanforderungen, Prüfung der Bedrohungsminderung gegen das Bedrohungsmodell, Schwachstellenscans von Code und Abhängigkeiten sowie Penetrationstests. Jede braucht einen Plan, einen kompetenten Prüfer und eine Aufzeichnung.
Ein einheitlicher Eingangskanal für intern und extern gemeldete Schwachstellen, eine konsistente Schweregradbewertung, Auswirkungsanalyse über alle betroffenen Produktversionen und ein koordinierter Offenlegungsprozess. Auf diese Praktik stützt sich der Cyber Resilience Act am stärksten — und sie ist mehr als Patchen.
Updates vor der Freigabe qualifizieren, über einen integritätsgeschützten Kanal ausliefern und den Unterstützungszeitraum je Produkt dokumentieren. Behebungsfristen werden zu einem zugesagten Service Level, das Sie belegen können — einschließlich der Frage, wie Sie Geräte erreichen, die selten online sind.
Sicherheitsrichtlinien sind eine Lieferleistung an Ihre Kunden, kein internes Nachweisdokument: Härtungsleitfäden, Hinweise zu sicherer Konfiguration und Integration, Defense-in-Depth-Erwartungen an Integratoren und sichere Außerbetriebnahme. Häufig die schwächste Praktik, weil sie standardmäßig niemandem gehört.
Abschlusskriterien
Zwei Dinge unterscheiden einen Zyklus, der besteht, von einem, der stecken bleibt. Erstens eine ununterbrochene Kette von der Bedrohung bis zum Release. Zweitens ein vorab vereinbartes Reifegradziel, damit „überführt" eine messbare Bedeutung hat.
Ein fehlendes Glied ist die häufigste Auditfeststellung, die wir sehen. Nicht eine fehlende Maßnahme — sondern eine vorhandene Maßnahme, die niemand mit der Anforderung verbinden kann, die sie erfüllt, oder eine Anforderung ohne Test, der ihre Wirksamkeit belegt.
ML 1 bedeutet, die Praktik findet statt, ist aber nicht dokumentiert. ML 2 bedeutet, sie ist gesteuert und wiederholbar. ML 3 bedeutet, sie ist definiert und organisationsweit gelebt. Die meisten Hersteller brauchen ML 2 – ML 3, und nicht zwingend denselben Grad für jede Praktik. Dieses Ziel je Praktik festzulegen verwandelt ein offenes Programm in einen Plan mit Ende.
Stufe 2
Der eigentliche Aufwand der IEC 62443-4-1 liegt nicht in der Entscheidung, was zu tun ist. Er liegt darin, Nachweise für 47 Anforderungen Release für Release zu erzeugen und aktuell zu halten, während sich das Produkt weiter verändert. Genau diesen Aufwand reduziert KI — den Durchsatz an Nachweisen, nicht die Verantwortung dafür.
Ein vollständig geschlossener Kreis ohne Menschen ist die Variante, die ein Auditor zuerst angreift. Drei Grenzen halten die Automatisierung belastbar.
SVV erwartet eine von der Umsetzung unabhängige Verifizierung. Schreibt dieselbe Instanz den Code und die Tests, die ihn bestehen lassen, ist diese Unabhängigkeit verloren. Erzeugung und Verifizierung bleiben getrennt, mit einer namentlich benannten Person, die die Verifizierung verantwortet.
SM verlangt benannte, geschulte und kompetente Personen. Kompetenz ist eine Eigenschaft Ihrer Organisation, und kein Werkzeug kann sie für Sie vorhalten. Aufzeichnungen nennen die verantwortlichen Menschen; KI erscheint nie als qualifizierte Stelle.
KI entwirft, ein benannter Mensch prüft und genehmigt — und die Genehmigung ist das Artefakt, mit Version, Datum und Verantwortlichem. Auf Abruf neu erzeugte Nachweise ändern sich außerdem zwischen Audits; die Ausgabe wird daher wie jedes andere gelenkte Dokument versioniert und eingecheckt.
Industriekunden unterliegen häufig vertraglichen oder exportrechtlichen Beschränkungen, wenn Quellcode die Organisation verlässt — und Ihre Entwicklungsumgebung fällt nach SM-7 selbst in den Anwendungsbereich. Vor der Einbindung klären wir Mandantenmodell, Aufbewahrung und Trainingsgarantien, den Umfang der Repository-Zugriffe und wie Geheimnisse aus Prompts und Logs fernbleiben. Diese Entscheidung gehört in Ihre Zyklusdokumentation, denn ein Auditor wird danach fragen.
Zusammenarbeit
Kaum jemand beginnt bei null. Es gibt Freigabeverfahren, Design-Reviews, ein Qualitätsmanagement, vielleicht einen Safety-Lebenszyklus. IEC 62443-4-1 verlangt nicht, das alles zu verwerfen — sondern den Nachweis, dass Ihr Vorgehen die acht Praktiken abdeckt und Nachweise hinterlässt. Welcher der beiden Wege greift, klärt vor allem der erste Schritt.
Wenn Security-Arbeit stattfindet, aber nicht dokumentiert ist oder je Team und Produktlinie unterschiedlich läuft.
Wir entwerfen den Prozess entlang Ihrer Produkte und schreiben Verfahren, Vorlagen und Freigabekriterien gemeinsam mit Ihren Entwicklern, statt ein Handbuch zu übergeben. Am Ende gehört er Ihrem Team, und wir sind dabei, während er entsteht und das erste echte Release ihn durchläuft.
Wenn ein etablierter Prozess existiert — ISO 9001, ASPICE, ein Safety-Lebenszyklus oder ein ausgereiftes agiles Setup.
Wir bilden Ihre bestehenden Phasen, Rollen und Artefakte auf die acht Praktiken ab, behalten alles Konforme unter den Bezeichnungen, die Ihre Teams schon verwenden, und ergänzen nur, was wirklich fehlt. Einen funktionierenden Prozess einer Norm zuliebe umzubenennen, erzeugt Widerstand, aber keine Konformität.
Die meisten Organisationen liegen dazwischen: einige Praktiken werden nahezu unverändert übernommen, andere neu aufgebaut. Das Assessment klärt das je Praktik, damit der Plan Ihrem Prozess folgt und nicht einer Vorlage.
Ablauf
Der Weg verändert, was innerhalb der Schritte passiert, nicht deren Reihenfolge. In beiden Fällen bleiben wir bis zum Piloten beteiligt, statt ein Dokument abzugeben und Sie mit der Anwendung allein zu lassen.
Kontakt
Eine kurze Beschreibung dessen, was Sie entwickeln, wie Ihre Teams organisiert sind und worauf Sie hinarbeiten, genügt für den Anfang. Wir melden uns mit einer Einschätzung, welcher Weg passt, wo wir beginnen würden und was die Arbeit für Ihr Team bedeutet.
Wir antworten innerhalb von zwei Werktagen.
Vollständige KontaktdatenBitte verzichten Sie in einer ersten Nachricht auf vertrauliche technische Details und Geschäftsgeheimnisse. Nach unserer Antwort können wir für Sensibles einen verschlüsselten Kanal vereinbaren.
Lieber mit Daten beginnen als mit einem Gespräch? Das Gap-Assessment bewertet Ihren aktuellen Zyklus je Praktik und liefert die fehlenden Nachweise — dieselbe Grundlage, die Schritt 1 erzeugt.
Gap-Assessment starten