Von Dr. Yvette Teiken
Ich schreibe diesen Beitrag als Gründerin und Inhaberin eines mittelständischen Softwareunternehmens. Bei erminas entwickeln wir Software für die industrielle Digitalisierung. Unsere Lösungen laufen bei Kunden im produktiven Einsatz – das bedeutet Verantwortung. Verantwortung für funktionierende Systeme, für Sicherheit und für Vertrauen.
Wir sind kein Großkonzern mit einer eigenen Security-Abteilung. Und das gilt für viele KMU. Trotzdem tragen wir die gleiche Verantwortung wie die Großen – gegenüber unseren Kunden, unseren Mitarbeitenden und unserer Gesellschaft.
Wie Cybersicherheit im Alltag aussieht
In vielen mittelständischen Unternehmen ist Security kein eigenes Team. Sicherheitsfragen tauchen mitten im Alltag auf – zwischen Deadlines, Kundenwünschen und laufendem Betrieb. Meistens ganz unauffällig, bis etwas passiert.
Dann kommt die Schlagzeile. Eine kritische Sicherheitslücke. Alle fragen sich:
- Sind wir betroffen?
- Betrifft das unsere Kunden?
- Haben wir das im Griff?
Und plötzlich ist alles dringend.
Stress entsteht, wenn Strukturen fehlen
Nicht das Patchen ist das Problem – sondern der Weg dorthin.
- Welche Bibliothek nutzen wir?
- Wo genau?
- Bei welchem Kunden läuft das?
- Ist der Fix schon drin?
- Wurde er ausgeliefert?
Ohne klare Strukturen wird jede Sicherheitslücke zur Stressprobe. Statt besonnen zu reagieren, gerät man in Erklärungsnot – intern wie extern. Das führt zu Unsicherheit, vermeidbarer Hektik und manchmal auch Vertrauensverlust.
Der Cyber Resilience Act: Kein Gegner, sondern Hilfe
Mit dem Cyber Resilience Act (CRA) kommt ein gesetzlicher Rahmen, der Transparenz und Verantwortung einfordert. Für uns ist das kein Bedrohungsszenario, sondern eine Chance:
- Klare Prozesse statt Ad-hoc-Reaktionen,
- transparente Informationen für Kunden,
- fundierte Entscheidungen statt Bauchgefühl.
Der CRA zwingt niemanden zur Perfektion. Aber er fordert Nachvollziehbarkeit – und die ist mit guter Teamarbeit und klugen Werkzeugen erreichbar.
Was das für unsere Arbeit bedeutet – Ein realistisches Szenario aus unserem Alltag
Stellen wir uns vor, es wird eine kritische Sicherheitslücke in einer weit verbreiteten Open-Source-Bibliothek bekannt, die auch in unseren Produkten zum Einsatz kommt.
Früher hätte das bei uns eine Kettenreaktion ausgelöst: Wer nutzt was? Wo? Welche Version? Ist das schon gefixt? Wer muss informiert werden?
Heute läuft das strukturierter ab – dank klarer Prozesse und einem gemeinsamen Verständnis von Verantwortung.
Schritt 1: Überblick durch die SBOM
Unsere Software enthält für jedes Release eine Software Bill of Materials (SBOM). Damit sehen wir sofort:
- ob die betroffene Bibliothek überhaupt verwendet wird,
- in welcher Version,
- in welchen Produkten,
- und: Welche Kundeninstallationen konkret betroffen sind.
Das reduziert den potenziellen Kreis von „alle“ auf „diese fünf Installationen“. Das schafft Fokus – und spart wertvolle Zeit.
Schritt 2: Patchstatus prüfen
Die nächste Frage: Gibt es bereits einen Patch? Wenn ja:
- Haben wir ihn schon integriert?
- Ist er Teil eines Releases?
- Wurde dieses Release bereits an die betroffenen Kunden ausgeliefert?
Auch das lässt sich nachvollziehen – nicht immer automatisiert, aber transparent dokumentiert. Und wenn noch kein Patch existiert, wissen wir zumindest, wo wir priorisieren müssen.
Schritt 3: Threat Model einbeziehen
Nicht jede Lücke ist automatisch kritisch im realen Einsatz. Darum bewerten wir zusätzlich:
- Wird die betroffene Funktion bei uns überhaupt genutzt?
- Ist das System nach außen exponiert?
- Könnte ein externer Zugriff auf die Schwachstelle überhaupt stattfinden?
Dieses Bedrohungsmodell hilft, Panik zu vermeiden und Prioritäten richtig zu setzen. Es ist ein Unterschied, ob etwas nur theoretisch oder praktisch angreifbar ist.
Schritt 4: Kommunikation mit dem Kunden
Auf dieser Basis können wir souverän kommunizieren – nicht ausweichend, sondern klar:
- „Ihr System nutzt die Bibliothek, aber nicht die betroffene Version – kein Handlungsbedarf.“
- „Ja, die Lücke betrifft Sie. Wir haben die gepatchte Version intern getestet, Auslieferung erfolgt morgen.“
- Oder auch: „Derzeit ist kein Fix verfügbar, aber Ihr konkretes Nutzungsszenario ist nicht angreifbar. Wir beobachten das eng und informieren Sie aktiv.“
Diese Gespräche sind ganz anders als früher: Statt Unsicherheit zeigen wir Übersicht. Statt technischer Erklärungen vermitteln wir Sicherheit. Das stärkt das Vertrauen – gerade in kritischen Momenten.
Das ist ein Unterschied. Und er zeigt sich in der Kundenbeziehung: Vertrauen wächst, wenn wir Verantwortung übernehmen und nachvollziehbar handeln.
Gemeinsam besser reagieren – im Projekt CRACoWi
Im EU-Projekt CRACoWi entwickeln wir genau dafür pragmatische Ansätze. Nicht mit der Erwartung, dass KMU alles sofort perfekt machen, sondern mit dem Ziel, überhaupt handlungsfähig zu werden.
- Verantwortung teilen statt abwälzen.
- Gemeinschaftlich lernen.
- Werkzeuge einsetzen, die im Alltag funktionieren.
Das entspricht unserer Haltung: Wir wollen gemeinsam wachsen, fair arbeiten und menschlich bleiben – auch in stressigen Situationen.
Fazit: Cybersicherheit ist Teamarbeit
Sichere Software ist kein Luxus, sondern Teil unserer Verantwortung. Der CRA kann uns helfen, besser organisiert, ruhiger und transparenter zu arbeiten – ganz ohne Hochglanzstrategie.
Wer heute Strukturen schafft, reduziert den Stress von morgen.