3. NOVEMBER 2025

4 MIN.

Sichere Softwareentwicklung in der Industrie – Praxisbericht eines Entwicklungsleiters

Cybersicherheit ist kein Buzzwort mehr, sie ist geforderte Realität. Mit dem Cyber Resilience Act (CRA) und NIS-2 wird Sicherheit für vernetzte Produkte schrittweise in den kommenden Jahren zur Pflicht, inklusive Nachweisbarkeit über den gesamten Lebenszyklus. Wir erleben in unseren Projekten immer wieder, wie tief diese Anforderungen tatsächlich reichen und wie groß die Wirkung ist, wenn Sicherheit als Prozess verstanden und gelebt wird, nicht als letztes Feature vor dem Release.

Warum sichere Softwareentwicklung?

Wer Software in vernetzten Produktionsumgebungen einsetzt, steht nicht nur unter dem Druck, Angriffe und Ausfälle zu vermeiden, sondern muss zugleich diese Anforderungen an Regularien wie dem CRA oder der NIS-2-Richtlinie erfüllen. Beides verlangt von Unternehmen, IT-Sicherheit nicht erst am Ende, sondern bereits im Entwicklungsprozess als festen Bestandteil von Qualität und Compliance fest zu verankern. Bereits als erste Diskussionen um den CRA Fahrt aufnahmen, war klar: Das betrifft nicht nur Compliance, sondern die gesamte Entwicklungskultur. Secure-by-Design, Vulnerability-Handling und Nachweise sind keine optionalen Extras mehr, sie werden Pflicht.

Die Basis bleibt – und fehlt oft

In der Praxis sehen wir, dass die Basis zu oft fehlt: Klare Anforderungen mit einer bidirektionale Nachverfolgbarkeit von

• Anforderung
• Architektur
• Implementierung
• Testfällen

sind kein Luxus, sondern Grundvoraussetzung, um zuverlässig mit vertretbarem Aufwand wirklich das zu liefern, was gefordert war.

Durch die Auflagen des CRA sind wir verpflichtet über die gesamte Lebensdauer unserer Produkte kostenlose Sicherheitsupdates zu liefern, also auch noch Jahre später. Ohne diese Basis führen notwendige, insbesondere architektonische, Änderungen zu extrem hohen Aufwänden, da im Grunde genommen alle Features reverse-engineert werden müssen. Außerdem ist es auch danach noch ungewiss, ob die Software noch gleich funktioniert wie zuvor. Ein Hinweis an Manager: Auch das Geschäftsmodell muss passen, sonst bleiben in ein paar Jahren nur noch Kosten.

Für diese Basis haben wir unsere agile Entwicklung bereits vor Jahren an A-SPICE orientiert. Warum? Weil A-SPICE eine gute Struktur in Planung, Umsetzung und Verifikation bringt und damit die Grundlage schafft, um Security sauber zu verankern.

Security als Prozess – das Herzstück

Um Security als integralen Bestandteil unserer Entwicklungslandschaft zu verankern, haben wir diese an IEC 62443-4-1, ISO 27001, TISAX und A-SPICE ausgerichtet. Als Entwicklungsleiter war mir wichtig, Sicherheit für Entwickler:innen klar und leicht umsetzbar zu gestalten, ohne dabei die Prüfbarkeit und Auditierbarkeit zu vernachlässigen.

Hier sind die Bausteine, die sich in der Praxis bewährt haben:

Risk Assessment & Threat Modeling
Wir leben den risikobasierten Ansatz: Basierend auf identifizierten Risiken entscheiden wir, welche Maßnahmen wir priorisieren und welche wir gegebenenfalls nicht durchführen. Das hilft uns zu verstehen, wo wir ansetzen müssen und welche Maßnahmen wirklich wirken. Threat Modeling ist für uns die logische Fortsetzung, damit Angriffsvektoren systematisch als Risiken betrachtet und mitigiert werden, bevor es teuer wird.

Secure Architecture & Defense-in-Depth
Security by Design ist für uns nicht verhandelbar. In unserem Produkt edge.SHIELDOR haben wir gezielt mehrere Ebenen und Strukturen – vertikal und horizontal – implementiert, um IT und OT sauber zu trennen. Diese Architektur hat nicht nur die Sicherheit erhöht, sondern auch die Entwicklung beschleunigt, weil klare Sicherheitszonen und Schnittstellen die Arbeit am Quellcode erleichtert haben.

Secure Design & Coding Policies
Wir haben Secure-Design- und Secure-Coding-Standards eingeführt. Sie geben Entwickler/innen mit und ohne Security-Fokus Orientierungspunkte. Toolunterstützung wie statische Codeanalyse sind dabei unerlässlich. Auch wenn es am Anfang schwerfällt: Wir haben konsequent alle Findings behoben und die Pipelines so konfiguriert, dass strikte Regeln den Zustand stabil halten.

Security Testing (inkl. Systemtests & Pentests)
Wir verlassen uns nicht auf Tools allein: Neben automatisierten Scans (SAST, DAST, Fuzzing) führen wir Security-fokussierte Systemtests und interne wie externe Penetrationstests durch. Immer wieder finden unsere Security-erfahren Entwickler:innen durch explorative manuelle Tests Probleme, die kein Tool gemeldet hat.

Release Management als Risiko-Management
Jede Freigabe ist für uns eine Risikoentscheidung. Fehler lassen sich nicht
gänzlich ausschließen, aber wir können ihr Auftreten unwahrscheinlicher machen. Wir aggregieren KPIs, bewerten alle sicherheitsrelevanten Bugs, Vulnerabilities und sonstigen Risiken, analysieren Dritt-Komponenten (SBOM-gestützt) und
entscheiden: Release nur bei LOW-bewerteten Risiken, höhere Risiken nur mit dokumentierten und wirksamen Mitigationen. Das ist aufwändig, aber es gibt uns ein klares Bild, ob ein Release wirklich reif ist, bevor es beim Kunden fehlschlägt.

Quality Gate: Internes Audit durch QA
Bevor wir ein Release veröffentlichen, prüft unsere QA in einem unabhängigen
internen Audit, ob das Produkt nach unseren Prozessen entwickelt, getestet und geprüft wurde. Dieses Quality Gate ist für uns Messlatte und Ansporn zugleich.
Und zugleich einer der wichtigsten Pfeiler des gelebten KVP, da wir die NCs und PIs ernst nehmen.

Vulnerability Management & PSIRT
Nach dem Release beginnt die Pflicht zur Wachsamkeit. Wir haben einen Vulnerability-Management-Prozess etabliert und Tools zur Software Composition Analysis (SCA) für die SBOM-Erstellung sowie deren Analyse eingeführt. Ob mögliche Schwachstellen bei unseren Kunden ausnutzbar sind, bewerten wir CVSS-basiert. Zudem haben wir klare SLAs für Security-Patches definiert. CRA-konforme Meldungen innerhalb von 24 bzw. 72 Stunden sind damit kein Problem mehr.

Prozesse, Workflows & Audits
Wir dokumentieren nicht für die Schublade, sondern für uns, für eine effiziente Zusammenarbeit. Die Nachweisbarkeit entsteht dabei automatisch. Regelmäßig interne Prozessaudits helfen uns, Lücken zu schließen und den KVP zu leben.

Unser Ergebnis: Im Dezember 2024 wurden wir vom TÜV Rheinland nach IEC 62443-4-1 ML-2 zertifiziert. Das war für uns die Bestätigung, dass sich der Aufwand lohnt.

Regulatorischer Druck: CRA & Co.

Der CRA verankert Sicherheit über den gesamten Produktlebenszyklus, mit Bußgeldern, die weh tun. Wir sehen in vielen externen Projekten, dass das Thema Security und der CRA schnell zu Unsicherheit oder sogar Ohnmacht führen kann. Wie oben gezeigt, sind diese Themen jedoch durchweg handhabbar und durch Prozesse sowie Workflows problemlos wiederholbar.

Wenn ich gefragt werde „Womit sollte man starten“ ist meine Empfehlung: Mit einer Gap-Analyse. Sie zeigt, wo man steht und was als Nächstes zu tun ist. Wenn der CRA (noch) nicht in allen Details klar ist, kann man sich zudem an der IEC 62443-4-1 und -2 orientieren. Wir sind genauso gestartet und es hat uns den Weg geebnet.

Fazit

Sicherheit beginnt nicht bei der Firewall, sondern beim Design. Die vollständige Anwendung des CRA beginnt im Dezember 2027, erste Meldepflichten greifen bereits ab September 2026. Wir haben gelernt: Wer Security als Prozess denkt, gewinnt. Weniger Vorfälle, schnellere Audits, mehr Vertrauen. Veränderungen an Entwicklungsabläufen und sogar an den Produkten brauchen Zeit. Jetzt ist die Zeit zu handeln.

Autor: Dr. Simon Walz

Dr. Simon Walz ist Head of Product Development bei TRIOVEGA. Mit über zehn Jahren Erfahrung in der industriellen Softwareentwicklung und einem starken Fokus auf IT- und OT-Sicherheit verantwortet er die Entwicklung sicherer Softwarelösungen und die Umsetzung von Normen wie IEC 62443 in der Praxis. Zudem begleitet er Kunden von der technischen Konzeption bis zur Umsetzung moderner Schutzmechanismen.

BUCHEN SIE IHR UNVERBINDLICHES BERATUNGSGESPRÄCH