Alte Software, neue Haftung?

[00:00]
Alte Software – neue Haftung. Was zum Geier soll das heißen?
Ich behaupte mal: Jeder hat irgendwo Software.
Und klar, manchmal schaut man ein paar Monate nicht so genau auf die Security.
Aber viele unserer Kund:innen, gerade im Banken- und Versicherungsbereich, haben „richtige“ Software – also Systeme, die seit 30 Jahren und länger bestehen und über mehrere Generationen weiterentwickelt wurden.

[00:30]
Und wir bei Gepardec sagen: „Einfach wegwerfen“ ist keine Option.
In dieser Software steckt total viel Businesswert.
Da sind Mann- und Frau-Jahre an Know-how, Prozesswissen, Businesslogik eingeflossen.
Wir reden hier hauptsächlich von Individualsoftware – das ist ja auch unser Kerngeschäft.
Also Software, die man nicht einfach fertig kaufen kann.

[01:00]
Und diesen Wert gilt es zu erhalten – gerade in Zeiten von Cyberangriffen und steigenden Compliance-Anforderungen.
Wir schauen uns also gemeinsam an: Wie funktioniert das eigentlich?
Welche Probleme gibt es? Was sind die Lösungen?

[01:30]
Ich bin Christoph Kofler, Bergführer für Software-Modernisierung.
Und den Titel meine ich durchaus ernst.
Ich war vor Jahren mit meinem Papa wandern – in einem Gebiet, das wir nicht kannten.
Wir haben uns einen Bergführer genommen. Der hat gefragt:
Wohin wollt ihr? Wie lange soll es dauern? Panorama? Klettern?
Dann hat er uns eine coole Woche organisiert. Warum? Weil er die Gegend kannte.

[02:15]
Diese Metapher übertrage ich auf unsere Kundenprojekte:
Wir helfen euch, dahin zu kommen, wo ihr hinwollt – effizient, sicher, in eurem Tempo.
Und jeder will etwas anderes.

[02:40]
Ich starte mit dem Thema, das uns alle betrifft: den Cyber Resilience Act.
Bevor ich etwas dazu sage: Wer ist davon eigentlich betroffen?
Vielleicht noch nicht alle? Oder es ist noch nicht ganz klar?
Wir machen es für unsere Kund:innen sicher.

[03:10]
Unsere Kund:innen – zum Beispiel Banken und Versicherungen – sind direkt betroffen.
Und wir als Zulieferer sind automatisch mit im Spiel.
Denn jeder, der von NIS2 oder CRA betroffen ist, ist auch für seine Zulieferer verantwortlich.

[03:40]
Warum gibt’s das Ganze überhaupt?
Nicht nur, weil in der EU jemand eine neue Idee hatte.
Es gibt klare Daten: Seit 2021 ist Cybersecurity das größte Geschäftsrisiko in Europa.
Und das ist nicht übertrieben – das ist Fakt.

[04:20]
Der Cyber Resilience Act will genau da ansetzen.
Ja, es ist mühsam.
Aber da sind auch viele sinnvolle Dinge drin.

[04:40]
Zum Beispiel:
Früher gab es NIS2-Richtlinien.
Studien zeigen, dass Organisationen, die sich daran halten, resilienter sind.
Der CRA geht genau in diese Richtung – nur verbindlich.

[05:10]
Wer ist nicht betroffen?
Unternehmen mit weniger als 50 Mitarbeiter:innen und unter 10 Millionen Euro Jahresumsatz –
es sei denn, sie arbeiten für betroffene Firmen.
Einzelhandel ohne Onlineshop, Hotels, Gastronomie, Marketing, PR, Sportvereine usw.

[05:40]
Aber die Strafen? Die sind saftig.
Zwischen 7 und 15 Millionen Euro. Oder bis zu 2,5 % vom Jahresumsatz.
Ganz ehrlich: Das erinnert stark an DSGVO.

[06:10]
In Österreich haben wir den CRA noch nicht gesetzlich umgesetzt.
Eigentlich hätte das bis Oktober 2024 passieren sollen.
Aber es gibt EU-Richtlinien und einen offiziellen Implementation Guide – 155 Seiten.
Und der ist sehr konkret: Es geht nicht mehr nur um „macht mal Risikomanagement“,
sondern um klare Anforderungen.

[07:00]
Beispiel: Software-Dependencies.
Wer weiß, was das ist? Klar, oder?
Wir alle nutzen Frameworks, Libraries – also Open Source und Co.
Quarkus, Logging, Frontend-Bausteine.
Das ist Standard – niemand erfindet Logging-Tools neu.

[07:40]
Aber diese Teile sind verwundbar.
Sie enthalten Schwachstellen – täglich werden neue entdeckt.
Wer kennt Log4Shell? Oder die Panik damals? Genau darum geht’s.
Und deshalb: Wenn du Software auslieferst, musst du wissen, was drinsteckt.
Und: Du musst sicherstellen, dass alle Komponenten aktuell und sicher sind.

[08:30]
Das ist keine freundliche Empfehlung – das ist Vorgabe.
Du kannst dich nicht einfach darauf verlassen, dass dein Zulieferer das schon macht.
Und wenn du selbst Software entwickelst oder betreibst – bist du direkt verantwortlich.

[09:10]
Dann gibt’s da noch DORA – den Digital Operational Resilience Act.
Der betrifft Finanzdienstleister: Banken, Versicherungen, Fintechs.
Und auch wieder: alle IT-Dienstleister, die dort mitarbeiten.
Strafen: bis zu 2 % vom Jahresumsatz oder 1 Million pro Einzelperson.

[10:00]
Und: DORA ist ab 17. Jänner 2025 direkt wirksam.
Ohne extra Umsetzung in Österreich.
Das ist ernst.

[10:30]
Drittes Thema: Der Cyber Resilience Act betrifft auch Produkte mit Softwareanteil.
Beamer, Mikrofone, Maschinensteuerung – alles, was Software enthält.
Da kann der Hersteller nicht mehr sagen: „Nach 2 Jahren gibt’s kein Update mehr.“
Er muss – sonst drohen auch hier Strafen.

[11:40]
Cybercrime ist heute ein Geschäftsmodell.
Früher: Hacker im Auftrag von Staaten.
Heute: Erpressung.
Daten verschlüsseln, Geld fordern – sonst sind die Daten weg.
Und das trifft nicht nur große Firmen. Alphabetisch wird durchgegriffen.

[13:30]
Man kann heute im Darknet Ransomware-Angriffe als Dienstleistung buchen.
Ja, wirklich.
Und die erbeuteten Daten werden auf Schwarzmärkten versteigert.
Mit Countdown, Deadline und allem drum und dran.

[15:00]
Wie läuft so ein Angriff technisch ab?
Schritt 1: Schwachstelle ausnutzen – z. B. im Webserver.
Schritt 2: Weiterhangeln ins interne System.
Schritt 3: Rechte ausweiten.
Schritt 4: Daten verschlüsseln, absaugen, erpressen.

[17:00]
Wo helfen Updates?
Genau da!
Wenn du regelmäßig updatest, machst du’s dem Angreifer schwer.
Aber: Viele sagen, sie haben „eh alles gefixt“.
Und dann passiert – jahrelang – wieder nichts.

[18:00]
Warum ist Updaten so schwer?
Weil’s organisatorisch niemand will.
Weil Entwickler lieber neue Features bauen.
Weil es keinen Verantwortlichen gibt.
Weil „es eh läuft“.

[20:00]
Wir als Dienstleister haben mit dieser Haltung oft zu tun.
Man muss Überzeugungsarbeit leisten – intern wie extern.
Und oft kommt der Weckruf erst nach einem Security-Incident.

[22:00]
Man redet erst drüber, wenn schon was passiert ist.
Wir hatten z. B. selbst einen Security-Vorfall – nichts Dramatisches, aber doch ernst.
Innerhalb weniger Stunden eingedämmt, aber es hat allen gezeigt:
Es kann jederzeit etwas passieren.
Und wir arbeiten für Banken – da gelten alle Anforderungen direkt auch für uns.

[23:00]
Was passiert oft?
Nach einem Vorfall wird hektisch ein Fix gebaut.
Alle atmen durch.
Dann wird’s wieder vergessen.
Bis zur nächsten Lücke.

[24:00]
In manchen Projekten haben wir unseren Kund:innen schon Deadlines gesetzt.
„Entweder wir machen das Update bis dahin – oder ihr betreibt den Server selbst.“
So hart das klingt, es ist manchmal der einzige Weg.

[25:00]
Denn es ist nicht so, dass man ewig Zeit hat.
Manche Schwachstellen sind in Tagen ausnutzbar.
Und oft ist das Update sogar billiger als der Aufwand, es hinauszuzögern.

[26:00]
Und jetzt ehrlich:
Wer in der Firma ist überhaupt für Updates zuständig?
Product Owner? CISO? Entwicklerteam?
In den meisten Firmen: niemand.
Und das ist das Hauptproblem.

[27:00]
Bevor man über Tools oder Technik redet, braucht man das:
– Management-Attention
– Budget
– gemeinsame Awareness
– und: Verantwortlichkeiten

[28:00]
Sicherheit ist kein technisches Problem.
Es ist ein Kulturthema.
Wenn der Product Owner ständig Features vorzieht,
verliert das Thema Updates jedes Mal.

[29:00]
Wie kann man Updates sinnvoll in den Entwicklungsprozess integrieren?
Zum Beispiel bei jedem Sprint?
Oder zumindest regelmäßig, mit festen Regeln?

[30:00]

Ein dediziertes Update-Team hat viele Vorteile:
Sie können Automatisierung richtig ausbauen.
Sie müssen keine Überzeugungsarbeit leisten.
Und sie haben ein klares Mandat: updaten, updaten, updaten.

Aber – sie brauchen auch das Vertrauen der Entwicklungsteams.
Wenn die nur Scherben hinterlassen, wird niemand mit ihnen arbeiten wollen.
Das heißt: Sie müssen wirklich gut sein.

[32:00]
Da spring ich jetzt ein bisschen drüber.
Oder Ludwig – coverst du das gleich?
Oder soll ich noch was dazu sagen?

[32:20]
(Übergang)
Gut, dann switchen wir jetzt.
Der Ludwig zeigt euch jetzt sozusagen, wie eine automatisierte Lösung ausschauen kann.
Ich glaub, in heutigen Tagen – wenn man 12 oder 20 Mal im Jahr updatet –
dann will man die Sachen einfach nicht mehr mit der Hand machen.

[33:00]
Ludwig Steindl:
Ja, danke. Guten Morgen auch von meiner Seite.
Ich bin Ludwig Steindl, Softwarearchitekt bei der Gepardec.
Nicht ganz so ein poetischer Titel wie „Bergführer“, aber vielleicht kommt das noch.
Gerne auch Ideen posten.

Ich begleite in unseren Projekten oft Teams bei architektonischen Fragestellungen.
Gerade bei komplexeren Projekten, wo man nicht einfach alles neu baut,
sondern viel Bestehendes modernisieren muss.

[33:40]
Früher war mein Ansatz oft:
Wenn wir neue Software brauchen, dann reißen wir das Alte einfach weg und bauen’s neu.
So wie in Las Vegas – da lebt ein Hotel 20 Jahre, dann wird’s gesprengt und neu gebaut.
Aber in Europa? Da steht ein Gebäude auch mal 2000 Jahre.

Und so ähnlich ist es mit Software in Banken und Versicherungen:
Da kannst du nicht einfach alles wegreißen.
Du musst mit dem arbeiten, was da ist – und es modernisieren.

[34:00]
Ich erinnere mich an einen Kunden mit 40 Jahre alter Applikation.
Da war klar: Neu schreiben geht nicht.
Aber ganz ohne Veränderung geht’s auch nicht – denn irgendwann kommst du an technische Grenzen.
Und da beginnt mein Part: Technische Modernisierung, ohne die Fachlichkeit zu verlieren.

[35:00]
Wir verwenden z. B. Renovate – ein Bot, der automatisch prüft, ob neue Versionen verfügbar sind.
Dann aktualisiert er z. B. in Java-Projekten die pom.xml oder andere Abhängigkeitsdateien.

[36:00]
Dieser Bot läuft in der CI/CD-Pipeline.
Er kann täglich laufen oder manuell angestoßen werden.
Er erstellt einen Pull Request mit dem Versionsupdate.

[37:00]
Wenn alles durchläuft – Tests, Build, Deployment – kann man automatisch mergen.
Wenn nicht, muss man nachbessern.

[38:00]
Dann kommt OpenRewrite ins Spiel:
Ein Tool, das erkennt, wo sich Code durch das Update ändern muss.
Nicht nur simple Replace-Regeln, sondern richtiges Refactoring – durch sogenannte „Rezepte“.

[39:00]
Beispiel: Migration von Quarkus 2 auf Quarkus 3.
Viele Pfade, viele Namensänderungen.
OpenRewrite übernimmt das automatisch.

[40:00]
Wenn danach Tests fehlschlagen – kein Problem.
Wir nutzen dafür WebIDEs, z. B. Red Hat Dev Spaces.
Einfach Container starten, Code fixen, Commit – fertig.

[41:00]
Diese Umgebung braucht kein Setup am Laptop – alles läuft im Browser, vorkonfiguriert.

[42:00]
Danach laufen die Tests wieder durch.
Und dann kommt der letzte Schritt:
Wir wollen ja beweisen, dass die Welt jetzt sicherer ist als vorher.

[43:00]
Dafür nutzen wir Dependency Track.
Das Tool analysiert SBOMs – also Software Bill of Materials –
und zeigt, welche Schwachstellen (CVEs) enthalten sind.

[44:00]
So sehen wir im Zeitverlauf:
Vor dem Update gab’s z. B. 12 kritische CVEs, danach nur noch 2.
Oder: Mit der neuen Version ist wieder eine neue Schwachstelle dazugekommen.
Auch das kann passieren – aber man weiß Bescheid.

[45:00]
So kann man aufzeigen: Wir haben die Welt ein Stück sicherer gemacht.
Und das kann man auch dem Management zeigen.

[46:00]
Ein Beispiel: Log4Shell.
Bei einem Kunden mit 20 Teams wussten wir auf Knopfdruck,
welche Applikationen betroffen waren – dank Dependency Track.
Andere Kund:innen: Keine Ahnung, wo das überall drinhängt.

[47:00]
Und dann der Klassiker:
Die Version, die man bräuchte, ist nicht mit dem Java-Stack kompatibel.
Man muss fünf andere Dinge upgraden, um überhaupt das Sicherheitsupdate einzuspielen.
Das dauert dann eben nicht zwei Tage, sondern drei Monate.

[48:00]
Und genau darum geht’s:
Wenn ich die Basisprozesse nicht automatisiere,
bin ich im Ernstfall nicht handlungsfähig.

[49:00]
Das braucht kein Megabudget – aber man muss es ernst nehmen.
Es ist ein strategisches Thema.

[50:00]
Es geht auch darum, Prozesse zu schaffen – und sie dann tatsächlich zu leben.
Denn sobald jemand kommt und sagt:
„Das Feature muss in die Produktion – das ist wichtiger“,
verschiebt sich alles wieder.

[51:00]
Da hilft dann auch keine Ressource, kein Prozess.
Wenn’s nicht gelebt wird, passiert’s nicht.
Das heißt nicht, dass man alles andere ignorieren soll –
aber es muss einen Stellenwert in der Kultur haben.

[52:00]
Frage aus dem Publikum:
„Das mit Automated Coaching – ist das sowas wie kontextbezogene AI?“
Antwort:
Nein, nicht direkt. Es geht eher um automatisierte Tools,
aber nicht mit künstlicher Intelligenz im Hintergrund.
Wobei – die Idee, das zu verbinden, wäre spannend.

[53:00]
Jetzt zeige ich kurz, wie das live aussieht.
Ich habe das in GitHub Actions integriert –
das könnte genauso gut mit Jenkins oder Tekton laufen.

[54:00]
Der Job triggert Renovate.
Er prüft, ob es neue Versionen gibt.
Findet er z. B. Quarkus 2.16, schaut er nach, ob 3.2.1 verfügbar ist.
Dann erstellt er einen neuen Branch mit Pull Request.

[55:00]
Hier sehen wir z. B. einen Pull Request,
in dem nur die Version angepasst wurde.
Alles andere bleibt gleich.

[56:00]
Weil die CI/CD-Pipeline läuft,
werden alle Checks durchgeprüft.
Wenn alles grün ist – super.
Wenn nicht, müssen wir eingreifen.

[57:00]
Beispiel:
Beim Update auf Quarkus 3 kracht es –
„Package doesn’t exist“ usw.
Also: Breaking Changes.

[58:00]
Jetzt starten wir OpenRewrite.
Das erkennt automatisch:
Aha, Quarkus 2 → Quarkus 3.
Dafür gibt’s Rezepte aus der Community.
Die werden angewendet – automatisch.

[59:00]
Wichtig: Wir trennen sauber.
Renovate-Branch ist das eine.
Der Auto-Update-Branch von OpenRewrite ist das andere.

[1:00:00]
Wir sehen jetzt: Es wurde mehr geändert als nur die Versionsnummer.
Namespace-Anpassungen, Code-Stellen – alles automatisch passiert.

[1:01:00]
Die Tests laufen aber noch nicht.
Also geht’s in die WebIDE.
Ein Container mit kompletter Entwicklungsumgebung wird gestartet.
Vollständig vorbereitet – kein Setup nötig.

[1:02:00]
Ich kann da direkt im Code arbeiten.
Test suchen, Fehler erkennen, beheben.
Build starten, testen, committen.

[1:03:00]
Ich kann sogar Hot Deployments machen.
Code ändern, direkt sehen, was passiert.
Das ist gerade bei größeren Projekten enorm praktisch.

[1:04:00]
Wenn alles läuft, committen, merge – fertig.
Und dann schauen wir uns an,
was sich sicherheitstechnisch verbessert hat.

[1:05:00]
Im Dependency Track sehen wir z. B.,
welche CVEs vor und nach dem Update vorhanden sind.
Wir können die Exploitability Score mit der CVSS Score kombinieren.

[1:06:00]
Beispiel:
SnakeYAML hatte eine kritische Schwachstelle mit Score 9.8
und einer Ausnutzungswahrscheinlichkeit von 99 %.
Da sollte man reagieren – dringend.

[1:07:00]
Und genau hier hilft es,
wenn man schnell handeln kann –
weil man Prozesse und Tools dafür schon vorbereitet hat.

[1:08:00]
Es geht nicht darum, alles sofort perfekt zu machen.
Aber man muss die Basis schaffen.
Und man muss es leben.
Sonst wird’s bei jedem neuen Feature wieder nach hinten geschoben.

[1:09:00]
Das war jetzt die komplette Prozesskette.
Von Versionserkennung, automatisierten Updates,
Test, Review, Merge –
bis hin zu Reporting & Sicherheitsnachweis.

[1:10:00]
Frage:
„Funktioniert das auch für komplexere Szenarien?“
Antwort:
Ja, aber natürlich ist nicht alles automatisierbar.
Manche Teile muss man immer noch selbst angreifen.
Aber der Aufwand ist deutlich geringer.

[1:11:00]
Letzter Gedanke:
Du zahlst einen Maler ja auch nicht nur dafür, dass er das Bild malt.
Sondern auch dafür, dass er am Ende den Pinsel ausspült.
Updates sind genau dieser letzte Schritt.

[1:12:00]
Und ohne den Schritt –
ist die Software vielleicht „fertig“,
aber nicht bereit für das, was kommt.