Willkommen zurück zu Secrets Not Included, dem Podcast mit Dani und Ole über DevSecOps. Und in dieser Woche machen wir mal einen kleinen Rundumschlag zu Cybersecurity mit KI und ich glaube nochmal einen kurzen Ausflug Richtung Post-Quantum-Verstüß-Doc.

Ja, genau. In der Vorbereitung hatten wir mehrere Themen rausgesucht und irgendwie konnten uns nicht für eins entscheiden, haben wir gedacht, machen wir alle.

Und welche Vorbereitung erstmal, Daniel? Lass mich...

Ja, so die fünf Minuten vorher, wo wir uns links zu schmeißen und sagen, was wir wollen. Ja, also grundlegend, zumindest das Thema, was mir gerade im Kopf geblieben ist aus diesen fünf Minuten Vorbereitung, ist, dass Postquanten, und das Thema hatten wir ja auch schon, Postquantenverschlüsselung jetzt auch vom BSI behandelt wurde, beziehungsweise gesagt wurde, bis wann man theoretisch darauf komplett verzichten sollte. Jetzt weiß ich,

Ja, genau. Da gab es ja so ein kleines Update jetzt die Tage. Nicht, dass es die Information nicht vorher schon gab. Ich glaube, vorher war sie sogar enger geknüpft. Vorher hat das BSI gesagt, bis Ende 2030, jetzt sagen sie bis Ende 2031. Ich habe nicht so genau die Quelle aus dem Artikel dafür gefunden. Auf jeden Fall wurden die technischen Richtlinien aktualisiert in der Richtung, was das Verschlüsselungsverfahren angeht. Und ich halte mir ja so ein bisschen an der Google-Timeline bis Ende 2029 weiter fest. Ich finde, das ist schöner als 2030.

Ja, definitiv. Achso. Ja, super. Jetzt fühle ich mich alt. Danke. Ja.

30, das fühlt sich so erwachsen an. Ja, schau mal, das hier 1000 wird dann 30, also das, oder 29a.

Ja, genau, genau. Ja, es hört sich auch schlimmer an, als es ist. Also für mich als Entwickler, wir hatten das letzte Mal schon im Podcast das Thema und ich habe dann angefangen zu überlegen, was ich eigentlich machen müsste, beziehungsweise ich bin ehrlich, ich habe einen Schlüssel, der 15 Jahre alt ist. Also als ich mit Computern angefangen habe, habe ich auch irgendwo mal... so mit PGP und solchen Sachen angefangen und GPG und sowas. Und da habe ich noch einen Schlüssel, den ich seitdem immer genutzt habe und richtig stolz darauf war, dass ich damals schon eine hohe Verschlüsselung, also eine Bitrate hatte. Und nach unserem letzten Gespräch ist mir so eingefallen, ja stimmt, du hast da noch was, was du tauschen müsstest. Und ich habe mir jetzt auch letzte Zeit

Ja, Thema langlebige Credentials, ne? Mhm.

Ja, genau. Langlebige Credentials. Und ja, den habe ich jetzt getauscht, weil ich halt einen Schlüssel auch zum Signieren nutze, zum Beispiel dieses Git-Comments-Signieren und sowas. Und das ist gar nicht so viel Arbeit. Also man denkt ja erstmal so, mein Gott, jetzt muss ich alles umbauen und tun und machen. das ist einen neuen Schlüssel generieren. Je nachdem, als Externer oder als Freelancer bist du manchmal in mehreren Projekten, dann musst du in mehreren GitHub, GitLab, was auch immer, da mal ein paar Sachen austauschen. Aber ich denke mal, bis 2030 dürfte die Timeline lang genug sein, dass das nicht den Stress ausartet. Mhm.

Ja, ich glaube, da ist es wichtiger auch zu verstehen, dass es natürlich auch sowas wie MTLS betrifft und dass da halt auch natürlich, wie bei allen Zertifikaten für TLS, die Laufzeiten reduziert werden sollten, müssen.

Ja, also eher so ein Legacy-System.

musst du nicht zwingen, solltest du aber tun. Und wenn du das heute halt machst, dann hast du halt durch die Rotation auch schon mal so einen Tacken mehr Sicherheit, gerade wenn du halt irgendwo nicht auf TLS 1.3 gehen kannst. Ja, genau so.

Als Betreiber, ja. Aber wenn du zum Beispiel, also ich gehe immer davon, natürlich von mir aus, und oft habe ich dann in solchen Projekten entweder CertBot laufen, wo ich schon fast vergesse, dass da Zertifikate sind und die automatisch erneuert werden. Und da dürfte der Aufwand auch recht gering sein. Oder AWS, CertManager ist ja genauso. Hast du einmal aufgesetzt und loll.

Ja, aber kann der Search-Bot tatsächlich dir intern eine Zertifikate neu machen?

Also interne.

Ja.

Soweit habe ich gar nicht gedacht. Ähm. Mhm.

Deswegen sage ich ja MTLS, dass das halt die Externen, die nach außen gehen, alles geschenkt, das ist gut automatisiert, automatisierbar. Die internen sind auch gut automatisierbar, da muss man halt ein bisschen mehr, also da ist einfach oder habe ich zumindest festgestellt, du musst über mehr Dinge nachdenken. Wenn du natürlich sowas hast wie Franken-PHP im Worker-Mode, dann bekommt das nicht sofort mit, dass es ein neues Zertifikat hat. Das ist doof, wenn ein Zertifikat irgendwie kurzlebig ist, ein paar Stunden, und dein Worker halt nicht jetzt so häufig neu startet,

Ja.

dann hast du auf einmal das Problem, dass der halt sagt, ich bekomme die Verbindung nicht mehr gebaut. Das Zertifikat ist ja gar nicht gültig. Das stimmt nicht überein, deswegen ja bei MTLS. Das ist so ein Ding, da muss man tatsächlich aufpassen und da kann man schnell aufs Knie fallen, aber es ist jetzt auch nicht so, dass diese Probleme unlösbar wären. Also man... Und man merkt sie schneller. Also wenn man so ein Zertifikat hat, dass da irgendwie 90 Tage rumfliegt und nach 90 Tagen stellt man fest, der Renew funktioniert gar nicht so erfolgreich und das wird natürlich dann sonntags abends oder so sein oder mitten in der Nacht oder wie es immer so ist.

Ostermontag.

Montag wäre ja nicht so schlimm.

Doch Ostermontag.

Montag ist man immerhin da.

Wenn du frei hast, hast du das zweite Bierchen im Kopf und dann kommt so eine Nachricht.

Ja, genau, so.

Mhm.

Immer ungünstiger Zeitpunkt, wo das passiert. Und jetzt bekommst du, ich hab mal mit sechs Stunden rumexperimentiert, ne, Zertifikatsgültigkeit. Also jetzt halte ich für übertrieben, aber so zum Ausprobieren und Rumspielen und Testen, ob so ein Renew schnell und zuverlässig funktioniert, war es cool. Weil ich nach sechs Stunden gemerkt habe, nein, das funktioniert nicht. So.

Ja, aber besser als nach, weiß ich nicht, 30 Tagen oder nach längerer Phase.

Genau, dann habe ich da so ein paar Runden gedreht und dann funktionierte es auch.

Ich bin da auch nicht drauf gekommen.

Ja, das war mein Unvermögen, dass ich natürlich nicht dran gedacht habe, dass der Worker da irgendwie noch was cachen könnte oder so. Aber letztendlich kein unlösbares Problem, nur etwas, wo man halt dann vielleicht doch nochmal nicht einfach mal erneuert und vielleicht doch mal erst nachdenkt.

Zumindest mal ausprobieren, ne?

Da hat dich der KI ein Stück weit zu weit vertraut, dass die Information richtig ist. Nee, brauchst du nicht weiter bedenken. Ist alles kein Thema. Mein Freund, die liebe KI, da hast du dich gehört.

Ja, gerade so Auto-Renew ist das gleiche Thema wie Backups, ne? Backups funktionieren nur, wenn du sie auch zurückspielen kannst und da würde ich genau das Gleiche sagen beim Zertifikat erneuern. Es funktioniert nur, wenn es wirklich automatisiert sich erneuert und auch dann wieder einspielt, ne?

Ja, und halt wirklich alle Schritte durchführt. Also das Einspielen war kein Thema, das Erneuern war kein Thema, aber der Service, der da läuft, muss es natürlich dann auch aktiv verwenden und mitbekommen.

Jetzt bin ich gerade am überlegen, ohne dass ich das Thema gegoogelt habe. Caching von Browser ist aber kein Problem bei dem Thema, oder?

So. Ah, das ist ja dein internes Netzwerk, ist das der Browser da ja erstmal außen vor?

Ach, stimmt, wir sind wieder noch beim Internen. Ich bin schon wieder extern. Mhm.

So, und beim Externen ist es ja auch, also war es ja schon immer relativ hilfreich bei solchen Themen, wenn die DNS-Rekords nicht zu lange Gültigkeit haben.

Auch daran ist das gekoppelt, ne?

Also zumindest war es, kenne ich es halt so, dass wenn du eine lange Gültigkeit deines A- oder AAA-Rekords da hast, dann hast du immer das Thema mit, ah, jetzt holt jemand nicht das neue Zertifikat, aber ich weiß nicht, ob das heute noch so tatsächlich das große Thema ist. Eigentlich sehe ich es nicht mehr so, dass tatsächlich das Austauschen des öffentlichen Zertifikats am Browser noch wirklich Probleme macht. Das hat sich ja auch geändert.

Dank den ganzen Automatisierungen habe ich mich dann, also wenig Probleme bis jetzt mitgehabt in den letzten Jahren, dass ich das fast vergessen habe, wie es funktioniert.

Ja. Ja.

Ja, ja, ja.

Ja, das ist halt auch so ein Ding, es läuft einfach und wenn es dann mal nicht läuft, dann muss man so tief, tief in den Gehirnwindungen anfangen zu kramen und zu überlegen, wie war das denn früher? Aber immerhin können wir, wir sind ja alt genug, wir können uns daran erinnern, wie es früher war.

Wir sind alt genug, dass wir uns langsam nicht mehr daran erinnern können. Das lässt schon wieder nach.

Auch das

Ja, ja, genau. Mhm.

Ja, aber stell dir vor, es ist besser zu wissen, dass man es vergessen hat, wie es funktioniert und dass die Lösung irgendwo in Stack Overflow von 2000 steht und die KI das garantiert indexiert haben wird, dass man zumindest sich daran erinnert, wo war es denn, an welcher Stelle, was haben wir kaputt gemacht vom Internet.

Ja. Genau, wenn es nicht Caching war, war es DNS. Sehr gut. Ich sehe schon die ersten Beschwerden kommen, wenn man sich Chefs beschweren soll.

So, und dann gilt wie immer, es war der DNS.

Meine Kollegen sagen nur noch, dass Caching und DNS war es. Ja, genau.

Ja, so. Also alle Probleme gelöst. Ja, einfach unseren Podcast zuschicken. Bin ich schuld, ist okay, kann ich mit umgehen. Genau.

Ja, aber ich meine, das ist jetzt eine Baustelle, aber was gibt es noch für Baustellen, wo man theoretisch jetzt die, also wo man die, mein Gott, Dingens ändern sollte, also die Zertifikate beziehungsweise die Verschlüsselung ändern sollte, also jetzt außer für seine privaten Sachen, die man signiert, E-Mails, SSH-Schlüssel und sowas.

Ja, auch ganz klassische...... Ja genau, TLS in jeglicher Form, also auch für Mails und so, die Übermittlungsstrecke, sollte man daran denken, dass auch da Zertifikate natürlich sein müssen und Einstellungen sein müssen, dass halt die aktuellen Algorithmen verwendet werden.

Mhm.

Und ansonsten ist es halt gerade so ein Ding, ich glaube, das habe ich beim letzten Mal auch schon gesagt, Es wird Zeit, dass man anfängt, einfach Sachen zu machen und einfach Sachen machen bedeutet an zumindest vielen Stellen langsam, das wird nativ supported. Es ist etwas, was man einschalten muss. Und sowas wie Caddy unterstützt das auch schon relativ lange als App Server.

Hm. Hm.

Das ist jetzt alles noch nicht so aufregend. Wichtig ist, man fängt an, sich alles, wo Zertifikate und Schlüssel irgendwie eingesetzt sind, mal aufzuschreiben und dann mal so eine Liste zu machen und abzuhaken. Ich würde mal behaupten, alles, was öffentlich ist, mal so als erstes schauen, dass der Webserver TLS 1.3 supportet und ausliefert und dann halt Hybridbetrieb erstmal, ja, das ist ja das Sinnvolle, dass man erstmal neu und alt supportet. Und das machen aber auch die Systeme jetzt nach und nach. Man muss nur updaten, das aktuell halten und einschalten.

Bis jetzt.

Also, man muss da gar keine Angst vor haben. Es ist nur besser verschlüsselt. Was dafür vielleicht noch ganz spannend ist, warum es halt jetzt so relevant ist und irgendwie mehr ins Bewusstsein kommt und auch das BSI ja jetzt eine Richtlinien aktualisiert, die sie jährlich aktualisieren, das ist jetzt nicht so ungewöhnlich, dass sie es tun, ist, man hat dazu auch noch ein Paper jetzt veröffentlicht, das noch nicht per Reviewed, wenn ich es richtig im Kopf habe, aber dass man tatsächlich zum Beispiel für die RSA 2000, schieß mich tot, 84 Bit, 48 Bit,

48, 2048, ja. Ja, ja. Upsi. Mhm.

Ja, genau. Erinnerung, ne? Zwar irgendwie die Zahlen stehen da. Dass tatsächlich unter 100.000 physische Qubits notwendig sind zum Entschlüsseln. Und bisher war man halt davon ausgegangen, dass der Faktor höher ist, um mindestens eine Stelle. Und damit halt die Wahrscheinlichkeit des Entschlüsselns natürlich gesunken ist.

massiv gesunken ist. Also du brauchst ja viel weniger Ressourcen dafür, ja.

Ja, so. Und damit ist... Genau.

Das heißt aber auch, dass die Zeit zum Entschlüsseln viel kürzer wird. Oder?

Also der heutige Quantencomputer bräuchte immer noch relativ lange, weil er einfach nicht so viel Leistung hat bisher.

Hm?

Aber das heißt, das Store now decrypt later, das Later jetzt näher gerückt. Ja, weil du einfach die Leistungsfähigkeit der Maschine ist halt, muss nicht so hoch sein, wie angenommen bisher. Ja, das heißt halt auch, wenn man sich den Fahrplan anschaut, dann sollte man vielleicht doch irgendwie Richtung Google tendieren, dass man sich so aus dem Zeitraum setzt, so sagt, bis Ende des Jahrzehnts haben wir das jetzt überall mal. umgestellt. Zumindest mal, wie gesagt, aus meiner Sicht ist erstmal alles, was öffentliche Kommunikation erfordert, das Hauptziel.

Ich könnte mir auch vorstellen, dass viele Sachen automatisiert nebenbei passieren. Also wie lange besteht so eine Infrastruktur? Also alle paar Jahre wird die auch mal umgebaut, weil auf irgendeiner Messe oder Konferenz war halt wieder das nächste Hype-Thema. Dann dreht man mal wieder alles auf links.

Sagt das dem Windows-Server von 2000, der immer noch in dem einen oder anderen Keller steht und kritische Infrastruktur betreibt.

Oh Mann.

Also das Problem sind ja bei diesen Themen die Legacy-Sachen.

Nicht ausschalten. Ja.

Also alles, was eigentlich heute schon einen großen roten Zettel dran hat, nicht ausschalten, nicht ändern, jeden Tag beten, dass es weiterläuft. Oder wo man auch einfach weiß, da sind technische Schulden und die lassen sich nicht gut abbauen. Diese Themen, da ist es natürlich jetzt heute wichtig, anzufangen zu planen, was machen wir denn? Und halt auch am Tagesende die Budget sich zu schnappen, die Budget zu organisieren, zu haben, um damit einzusteigen. Weil es sind nur noch drei, vier Jahre, bis man das irgendwie dann gelöst haben muss. So, und jetzt kommen ja auch dann die ganzen Leute wieder, die sagen, ah ja, ich hoste hier noch ein Shop-System, PHP 7.4. Nee, was 7.4? 5.4? Oder irgendwie sowas Altes?

Beides ist alt. Ja, ja.

Ja, ich erinnere mich nicht mehr so gut an den LinkedIn-Post von gestern. Ich war kurzzeitig zu geschockt, um es wirklich zu merken. Habe ich jetzt einfach in einen Container gepackt und kann ich jetzt weiter betreiben. Weil der Hoster hat das abgeschaltet. Oder schaltet jetzt das PHP ab. Es muss 7.4 sein, hoffe ich, für den Hoster. Also, und das sind natürlich genau die Systeme, wo man halt sagen muss, okay, Freunde der Nacht, also ihr habt hier echte Themen, die ihr eigentlich vorgestern schon hättet anfangen müssen zu lösen.

Mhm.

Ja, weil das die Bestandssoftware in einen Container packen, okay, ist ein netter Schritt, okay, dann packen wir halt ein Proxy davor, damit nach außen das irgendwie sicherer wird und so. Also mir fallen da auch 1, 2, 3, 4, 15 Maßnahmen ein, die man machen kann, um das weiter zu betreiben. Ähm, Aber am Tagesende musst du wegkommen von deinem Legacy-System. Ja.

Aber dann, ja, das Problem ist aber dann generell ein anderes. Also wenn du deine einzige Einnahmequelle oder dein Geschäftsfall sozusagen als Online-Shop nicht so supportest, dass du Legacy-Sachen und auch PHP-Versionen upgradest, dann... Und ich wundere mich, dass ich letzte Zeit immer davon lese, dass Magento-Shops und andere anfällig sind.

Trotzdem musst du... Ja, trotzdem musst du...

Also ja, wenn die zehn Jahre lang nicht aktualisiert werden, dann...

Ja, genau. Das ist ein anderes Problem im Kern.

Das wird sich halt nur da zeigen.

Aber da zeigt es sich dann halt mal wieder. Ja, das...

Wäre jetzt interessant, ob es zum Beispiel in Zukunft, also ich bin wieder bei dem Externen und bei dem Shop gerade, wenn solche Altsysteme laufen, ob die Browser irgendwann hingehen und sagen, Edgy Badge, HTTP, alte Zertifikate, machen wir gar nicht mehr. Und auf einmal gibt HTTPS für deinen Shop nicht. Also...

Ja, das passiert glaube ich jetzt ja schon mit dem 1er TLS, bin ich richtig.

Okay. Ja.

Also so langsam laufen, läuft deshalb auch dafür aus. Das ist jetzt ja nicht so, dass alles ewig weiterlebt. Irgendwann kommt der Punkt. Deswegen sage ich ja, man könnte das jetzt noch so schalenmodellmäßig verpacken. Und da Pflaster draufkleben, so Sachen gibt es. Das ist ja auch nichts anderes als in den Container packen und weiterbetreiben. Es ist ja auch nur ein Pflaster, das man draufklebt. Ich finde, die Idee ist, ich verstehe die Idee, es ist aber halt keine Lösung. Genau.

Langfristig keine Lösung. Kurzfristig kann das definitiv eine sein. Also wir kennen das ja alle, wirtschaftlich läuft es bei allen nicht gerade toll gerade und kann ich vollkommen verstehen. Also das ist auch nicht abwertend gemeint, wenn wir darüber reden. Also es kann sein, dass man einfach sagt, nächstes Jahr Kollege ist ausgelastet, der dafür zuständig ist. Nächstes Jahr hätte er wieder Zeit, Projekt wäre da fertig. Dann ist das vollkommen legitim in meinen Augen zu sagen, wir machen das bis dahin und dann wird das angegangen.

Ja, und dann hat jemand GPT-54-Cyber oder Entropic-Mythos doch losgelassen aus dem Glasswing-Projekt.

Das passiert nur selten. Mhm. Mhm. Mhm.

Und dann ist eine wandelnde Sicherheitslücke, auch wenn es ja defensive Modelle sein sollen, sollen, auf einmal ein sehr attraktives, aktives Sicherheitsrisiko, das du mit dir rumschleppst. Wir stehen ja gerade vor dieser kritischen Schwelle und ich sehe es als enorm kritisch an, dass das Project Glasswing zum Beispiel sehr unzugänglich ist. also ich meine, jetzt sind wir beide nicht Google und haben Zugriff drauf. OpenAI geht mit dem Cyber-Defense-Modell, das sie jetzt angekündigt haben, ein bisschen anderen Weg. Ja, da kann man halt über ein spezielles Programm reinkommen und dann nutzen, so wie ich es gelesen habe. Den Weg finde ich besser, dass Sicherheitsforscher und Cyber-Security-Menschen Zugriff darauf haben oder bekommen können.

Und damit kannst du was machen? Also kannst du... Achso, ich lade meinen Code hoch und sage, guck mal, passt das oder passt das nicht?

Das ist das gleiche wie mit Antropic Mythos. Du kannst deine Software auf Sicherheitslücken untersuchen.

Ja, mhm.

Genau, jetzt würde natürlich hier Daniel, wie heißt er denn weiter... der Curl-Erfinder, Maintainer, sagen, das liefert alles AI-Slop, ja, die haben ja ihr Bug-Bounty-Programm eingestellt, wegen zu viel AI-Slop, der da gekommen ist.

Kann ich verstehen.

Angebliche Sicherheitslücken, die tatsächlich gar keine Sicherheitslücken waren.

Mhm.

Das soll jetzt ja tatsächlich beim Mythos nicht so sein. Auf der anderen Seite hat jemand anderes ein Paper auch veröffentlicht, der hätte mit GPT-4 wo auch diese Sicherheitslücken identifizieren können und finden können. Also bin ich mir auch nicht so sicher, was die Veröffentlichung jetzt angeht. Aber wenn das alles so stimmt, was in diesen Ankündigungen steht, dann haben wir halt einfach das Problem, dass Sicherheitslücken super schnell gefunden werden und letztendlich super schnell quasi instant ein Exploit dafür auch erzeugen. da ist, also die Lücke ausnutzbar ist. Und dann kommen wir in dieses riesen Schlamassel rein. Wir sagen auf der einen Seite Lieferkettensicherheit.

Auf der anderen Seite müssen wir...

Die erhöhen wir gerade dadurch, dass wir aktiv das Patchen zurückstellen, weil wir festgestellt haben, ah, okay, die MPM-Packages und ja auch andere Pakete, die werden aktiv manipuliert. Da besteht ein enormes Sicherheitsrisiko, wenn wir sofort einspielen. Auf der anderen Seite sagen wir jetzt aber, oder haben wir jetzt auf einmal die Situation, dass KI-Modelle sehr, sehr schnell Sicherheitslücken identifizieren und es dann halt auch eine Ausnutzbarkeit gibt über KI-Modelle, die vielleicht aber gar nicht selber in der Lage sind, einen erfolgreichen Fix dafür zu schreiben. Das sind ja zwei Paar Schuhe. Sachen finden, ausnutzen und fixen sind ja irgendwie drei unterschiedliche Aufgaben. Ähm, Und sagen eigentlich, okay, jetzt haben wir die Sicherheitslücke, es ist bekannt, wie sie ausgenutzt werden kann, jetzt müssen wir sofort patchen. Sagen aber in den Automatisierungstools, nee, wir warten jetzt x Einheiten, bis wir das tun.

Sieben Tage.

So, und jetzt clasht ja gerade die komplette Geschichte. Wir hatten, ich glaube, vor zwei Wochen oder letzte Woche oder so über die Lieferkettensicherheit ja erst gesprochen, einspielen. Ist das jetzt mit dem Ding noch der richtige Weg? Ich weiß es nicht.

Gute Frage, also keine Ahnung, weil einerseits musst oder willst du natürlich schnell genug sein, damit du nicht ausnutzbar bist. hängt jetzt ein bisschen davon ab, wovon man spricht. Es gibt ja zumindest Online-Shops, sage ich mal, wo du auch Updates bekommst. Die haben ihre Release-Zyklen mit allem drum und dran. Die weiß ich gar nicht, ob die so schnell sind. Also die werden ja auch nicht täglich releasen, dass du sagst, guck mal, da ist was rausgekommen, sondern die haben dann auch längere Release-Zyklen, wo du mit sieben Tagen, sagen wir mal, noch halbwegs safe bist.

Ja.

Abhängigkeiten, die du mit Composer installierst, gerade unser Entwickler- Gilde würde ich jetzt mal sagen, wir wollen natürlich näher dran sein. Wenn wir was bauen und dann Sachen produzieren, ausliefern, die andere dann nutzen, also auf der anderen Seite von der Shop-Entwicklung zum Beispiel sitzen, dann wollen wir natürlich möglichst aktuell sein. Und da bist du dann problematisch, wenn du sagst, ich warte da sieben Tage, plus der Kunde wartet auch nochmal Tage, dann hast du dann, wenn du Pech hast, so zwei, drei Monate irgendwie, bist du da so ein Patch mal rausgekommen.

Ja, auf der anderen Seite gibt es halt immer noch den starken Trend zu sagen oder wiedererstarken Trend zu sagen, Sicherheitslücken, die wir kennen, sind auch Gefahren, die wir abwehren können.

Mhm.

So, das ist jetzt halt natürlich eine sehr unterschiedliche Philosophie. Ich bin ja eher derjenige, der sagt, schnell patchen, möglichst Zero CVEs. Ähm, Versus, naja, Sicherheitslücken an sich sind nicht schlimm. Auch wenn sie high oder kritisch sind, heißt das nicht, dass wir jetzt aktiv das System verändern, sondern dann müssen wir halt schauen, dass wir vor dem System Veränderungen machen.

Also Intrusion Detection und andere Sachen meinst du, oder?

Ja.

Oder Firewall-Regeln, beziehungsweise zum Beispiel sowas.

Ja, die Kiste ist ja tief, in die man da greifen kann.

Mhm.

Und man muss ja auch bewerten, wenn das System gar nicht direkt von außen zugreifbar ist, wie realistisch ist jetzt das Ausnutzen der Sicherheitslücke? So, ja, ich sag ja, ich bin auch eher Team, okay, lass uns bitte die Sachen immer schnell patchen, weil selbst wenn es die Datenbank ist oder mein Key-Value-Store, du kommst indirekt dran und wer sagt denn nicht, dass es dann halt doch irgendwo noch eine andere Lücke gibt, mit der du die Lücke dann ausnutzen kannst.

Das und ich bin immer zu unkreativ, was das Ausnutzen von Sachen betrifft. Also selbst Intranets, habe ich mal mitbekommen, haben Mitarbeiter von Franchise-Unternehmen versucht, das System auszunutzen, das war in einem Intranet.

ja, das müssen doch nicht mal von Franchise-Unternehmen sein, das können deine eigenen Leute sein und das sind auch deine eigenen Leute, das kenne ich auch.

Ja, genau. Oder dass auch irgendwelche schützenswerten Daten leicht abrufbar sind, wo du sagst, das darf auch in einem Intranet nicht sein. Auch wenn es verboten ist, darauf zuzugreifen, habe ich leider alles schon gesehen. Und so wie du sagst, es muss nur eine zweite Lücke irgendwo sein. Es muss nur jemand in das Intranet kommen. Und dann ist aus diesem internen Netz auf einmal ein öffentliches Netz geworden. Ja.

ich sage jetzt mal, die Lahnbuchse im Patientenzimmer. Ja, aber tatsächlich tatsächlich ist dein Interesse, also ich habe häufiger oder ich sichere häufiger

Ja, bring your own device. Guck mal, ich habe da schöne Browser-Erweiterungen installiert. So eine Leiste.

kritische Informationen aus Intranetz weg für die weitere Verwendung für Menschen, die andere Dinge als ich in der Uni sich angeschaut haben, als ich das bei Internetsachen mache.

Ja.

Weil halt dann doch das Vertrauen in der Organisation zu den Leuten, mit denen man jeden Tag zu tun hat, größer ist, als zu völlig Fremden. Verständlicherweise auch irgendwie. Aber dann sind halt die Sicherheitsregeln dann vielleicht doch nicht ganz so hoch.

Also zumindest das Bewerten macht definitiv Sinn. Also wie groß ist der Impact? Was für Daten sind das? Wie schützenswert oder weniger schützenswert ist das? Sind das

Genau, und dann verzögert man halt auch eher mal die Updates in den internen Systemen als mit den externen Systemen, weil man sagt, ah ja, komm, da kommt ja so keiner ran, das ist ja nur bei uns abrufbar und dann ist es halt schon, dann ist es als nächstes über das VPN abrufbar und und wie es halt so immer ist und das ist halt so das Ding, klar, dein Intranet wird jetzt bestimmt nicht, also da wird der Angriff von jetzt den

Ja, kennt ihr.

jetzt neuen Modellen, KI-Modellen eher unwahrscheinlich sein. Hoffe ich.

Ich bin auch gerade überlegen.

Dass man jetzt nicht sich überlegt, ah, wir integrieren hier sowas in unser System. Aber wenn du jetzt ein Safehouse-Ki-Modell hast,

Ja, warte mal. Also Open Claw, brauchst du nur einen fleißigen Mitarbeiter, der Open Claw irgendwo installiert hat? Root-Rechte, gib ihm.

Ja, du musst ja nur ein Modelllokal installieren, wenn du die passenden Devices im Netzwerk hast oder halt ein VPN und darüber geht jemand rein mit einem Device, das nicht von dir ist.

Und das Ding... Ist ja Standard heutzutage.

Bring your own device. Ob das jetzt zulässig ist oder nicht zulässig ist, ist ja erstmal hingestellt.

Hm.

Das ist vielleicht möglich und die Möglichkeit eröffnet halt dann deine Problembaustelle. Auch lokale kleine Modelle werden immer leistungsfähiger. du musst jetzt nicht das riesige Modell haben, wenn du veraltete Software hast, wird das ein kleines Modell, das eher genauso schnell finden und ausnutzen können wie ein großes. Und ehrlicherweise auch KI von großen Beratungsunternehmen, die da draußen sind und ihre Agenten und Chats und Tassen nicht gesehen verkaufen, sind halt extrem schlecht gesichert.

Es gibt immer mehr an den Nachrichten.

Zum Teil noch nicht mal Passwörter drauf und so weiter. Man muss sich einfach bewusst sein, die Systeme stecken voller Fehler. Egal, welche Software. Egal, ob es Cobaltzelle oder Open-Source-Software ist. In Open-Source-Software kannst du sie selber finden und beheben, in kommerzieller, proprietärer Software nicht. Aber keine Angst, deine KI kann das Reverse-Engineeren und wird das im Zweifelsfall ausnutzen. Und jetzt gerade mit Glasswing, also Mythos und GPT-5.4 Cyber-Systeme,

Mhm.

Ist das ein realer werdendes Szenario, dass wir uns halt darauf einstellen müssen, dass Sicherheit Sicherheit interessanterweise weiter von Menschen verantwortet werden muss, wir aber alle viel, viel schneller werden müssen und gleichzeitig viel mehr Informationen reviewen müssen, verarbeiten müssen, prüfen müssen, ob wir jetzt zum Beispiel ein Update unbedenklicherweise einspielen oder nicht.

Genau, das ist das Problem.

Also ob das Update unbedenklich ist und wir es dann einspielen. So, jetzt verständlicher, glaube ich. Ja, das Backband-Tipp-Programm wurde geschlossen, weil da so viel AI-Slope gekommen ist.

Ja, aber genau, also gerade dieses Reviewen und du hast ja vorhin auch gesagt, Curl Bibliothek akzeptiert auch viele Sachen nicht mehr mit dem Bug-Bounty-Programm. Und da sehe ich... Ja, ja. Genau, und da sehe ich auch das Problem. Du kannst zwar durch KI auch solche Sachen vorfiltern lassen und auch vorreviewen lassen, was auch Sinn macht. Also auf der anderen Seite bei Pull-Requests solche Sachen einfach schon mal vorlaufen lassen. Jetzt mit den anderen Modellen, die du genannt hattest, denke ich mal, wird das auch alles noch besser, was da dann theoretisch schon in der Vorarbeit passiert. Aber irgendwann muss ja da ein Mensch sitzen und sagen, ich entscheide, ich sage ja oder nein. Also egal, ob es jetzt in der Supply Chain ist, also dass der irgendwelche Bibliotheken baut, die irgendwo eingebunden werden oder auf der anderen Seite, die haben Entwickler, die am Online-Shop sitzen und da Features bauen und sich darauf verlassen müssen, dass die ganzen Sachen, die da mit reinkommen, kannst du ja auch nicht alles reviewen.

Ja.

Also da kommst du ja gar nicht mehr zum Arbeiten. Mhm.

Ja, und deswegen bin ich ja wieder so ein riesiger Fan von Renovate, um jetzt wieder Name-Dropping zu machen, ja, als Depender-Bot kann das aber genauso, ähm, als dass Dependencies darüber upgedatet werden.

Sponsor. Also...

Ja, und dann ist es wenigstens jedes Ding einzeln nachvollziehbar. Ja, das ist ein automatisierter Prozess und hey, ja, du kannst ja einstellen, das Update muss erstmal so und so viele Stunden alt sein oder Tage oder Wochen, Monate, Jahre, Jahrzehnte, ähm, Und dann ist es aber halt nicht so unkontrolliert mit, ah ja, ich mache mal NPM-Update oder Composer-Update.

Ja.

So, dann kommt da so eine Latte rein. Das prüft doch ehrlicherweise niemand. Deswegen am besten nicht der Mensch macht die Updates, sondern der Bot. Und der sorgt dafür, dass das, was nach den Regeln ist, geupdatet wird. Und dann hast du es nachvollziehbar einzeln drein gelaufen, mit deiner Pipeline geprüft. Was deine Pipeline dann macht, ist halt dein Thema und welche Maßnahmen du da halt drein machen möchtest.

Ja, aber was man sagen muss ist, genau, du brauchst eine Pipeline. Also so gewohnt, wie wir daran sind, also gewisse Sachen, die früher schon nicht schlecht waren und Qualitätsstandards erhöht haben, werden jetzt einfach heutzutage nicht nur Standard, sondern Mindestmaß, was du haben musst. Du brauchst eine Pipeline, du brauchst Tests in unterschiedlichsten Ausführungen, damit du überhaupt hinterherkommst. Also so viel wie möglich automatisieren, damit du, also KI sorgt nicht dafür, also dass wir

Ja.

weniger langweilige Sachen machen, aber wir müssen drumherum viel mehr automatisieren, um die ganzen Sachen entscheiden zu können. Du musst, wenn du dann solche Updates machst, automatisiert zum Beispiel auch Abhängigkeiten installierst. Ja, dann laufen natürlich Unit-Tests, du hast hoffentlich auch vielleicht Smoke-Tests, die dann sagen, dass der Shop nicht abgeschmiert ist nach dem Update oder das Testsystem noch läuft, damit du automatisiert deployen kannst. Da laufen nochmal Smoke-Tests. weil ansonsten brauchst du das zehnfache an Leuten, wenn du das alles noch von Hand machst. Und das, was vor fünf Jahren noch so hieß mit, ja, man muss ja nicht überall ein Schleifchen dran machen und darf es nicht übertreiben, ist heutzutage wirklich Mindestanforderungen, die du brauchst, mit allen, komplette Pipeline, mit Linting, mit Tests, die ausgeführt werden und, und, und, und. Und natürlich auch Renovate und solche Sachen.

Absolut.

Da kommst du heutzutage, glaube ich, nicht mehr dran vorbei.

Und das macht ja auch den Einstieg eigentlich in dieses ganze Thema viel komplexer. Wer kann sich heute noch leisten, ohne Pipeline zu arbeiten? Und vor allem ist das Ding ist ja auch...

Ich will kein Name-Dropping machen. Ich habe es erlebt. Also auch heute. Also ich kann es nicht verstehen. Vielleicht ist es auch so, dass man als Entwickler so irgendwann die Scheuklappen auf hat. Das gibt es heutzutage noch. Das ist nicht unmöglich.

Ja, mir ist das klar, dass es das noch gibt, aber mal so aus betriebswirtschaftlicher Sicht gesehen, welches Unternehmen kann sich heute noch leisten,

Ja.

nicht in der Softwareentwicklung, ja, ganz egal welches System, aber nicht zu automatisieren und die Nachvollziehbarkeit auch zu haben, ja, Richtung auch CAA-Gedachtnis 2 und die ganzen Regulierungen, die ja auch

Mhm. Mhm.

zum Teil in Kraft sind, also in Kraft, also in Kraft treten müssen, oder mal wieder in verspätet in Kraft treten, aber das ist ja ein anderes Thema, aber allein um der Regulierung gerecht zu werden und aber auch um den ganzen Anforderungen, die ja auch immer wieder steigen durch die Vorgaben und technischen Richtlinien des BSIs, jetzt mit IT-Grundschutz++ auch und solchen Dingen, die da ja rausgekommen sind, ähm, sind wir ja in der Situation, dass die Sachen mehr auditierbar sein müssen, mehr nachvollziehbar sein muss. Natürlich entsteht dabei auch wieder sehr, sehr viel Papierkrieg an sich.

Mhm.

Aber dass wir halt in der Softwareentwicklung auch tatsächlich in der Situation sind, zu sagen, wann ist denn jetzt was reingekommen und das halt gut nachvollziehbar haben und das halt nicht so ist, ah ja, hier am Freitagnachmittag hat jetzt mal jemand Composer Update gemacht, das haben wir dann Montag ausgespielt, hier sind alle Dependencies mal geupdatet worden, weil wir haben das ein halbes Jahr lang nicht gemacht. Okay, dann kannst du ja auch nicht mehr sagen, was hat denn ein Fehler vorgesagt, also es ist ja alles, dann, ja,

Ja, genau, das erschwert die Fehlersuche. Und wie jetzt bei Axios, also als Negativbeispiel reite ich da jetzt gerne drauf rum. Du kannst einfach hingehen und sagen, habe ich die Version installiert oder nicht? Und weißt, innerhalb von zwei Minuten wurde sie zu dem Zeitpunkt installiert, wo es anfällig war oder nicht? Und kannst dann sagen, okay, Häkchen dran, ich bin nicht betroffen oder ich bin betroffen. Weißt dann aber auch direkt, was du machen musst. Und wenn du aber das nicht hast, ja, keine Ahnung, ne?

Und der Vorteil ist ja auch, wenn du halt nicht darauf angewiesen bist, dass Entwickler immer wieder Updates machen, dann hast du natürlich auch den Vorteil, Und du weißt auch, dass diese zuverlässig laufen.

Genau.

Stell dir mal vor, derjenige, der in Urlaub ist, ach, derjenige, der in Urlaub ist, ist gut, ne?

Genau.

Derjenige, der das normalerweise macht, ist in Urlaub. So, guck mal, gibt's mehr Sinn. Ähm, ähm, ähm, ähm, ähm, mach das jetzt nicht, fährt vier Wochen im Sommer weg in Urlaub. So, dann läuft vier Wochen lang kein Update. Und wenn er dann wiederkommt, macht er das und alles knallt. So, ja, wenn man da einen zuverlässigen Prozess hat, der automatisiert ist, dann weiß man aber auch, okay, das ist läuft und dann musst du halt einfach nur jedem beibringen zu sagen, okay, du machst jetzt keinen Composer, MPM, hast du nicht gesehen, Update mehr selber, sondern deine Entwicklungsumgebung bringt das mit, die musst du halt einfach mal regelmäßig, musst du halt einfach deinen Container neu ziehen lassen, fertig.

Ja, genau.

Der Prozess verändert sich dann, bringt aber halt auch Vorteile mit sich. Ich weiß, jetzt kommen dann wieder der eine oder andere, das gefällt mir nicht. Aber hey, ob du jetzt ein Container-Update ziehst oder ob du jetzt regelmäßig irgendwie selber Updates machen musst, durchtesten musst und so weiter und so fort. Du bekommst das aus der Pipeline und deine Tests, wenn du sie denn hast, haben schon bewiesen, dass alles heil ist.

Ja, also das ist einfach Geschwindigkeit, die du da mitbekommst. Also für uns Entwickler natürlich Sicherheit, weniger Bauchschmerzen, bessere Debugging-Fähigkeiten, aber ist ja auch für alle anderen Projektbeteiligten interessant. Du bekommst Geschwindigkeit dadurch, dass du viel schneller deployen kannst.

Ja, und halt auch damit halt ein Stück weit Sicherheit. Compliance-Anforderungen werden erfüllt für die Juristen, die dann auch glücklich sein sollen.

Genau.

Es schafft Sicherheit und damit ist man immer noch nicht schnell genug, was unsere KI-Probleme angeht, die da so auf uns zukommen, aus Sicherheitssicht.

Man reduziert das Zeitfenster extrem. Also wenn ich überlege, ich hätte ein Projekt, wo keine Pipeline ist oder wo ich viel manuell machen muss bei einem Deployment, das führt automatisch dazu, dass ich nicht zweimal oder dreimal am Tag etwas deploye.

Genau.

Wir nehmen die zwei Extreme. Auf dem einen hast du wirklich so, ich baue was, mache ein Git-Push, lasse das reviewen und sobald das irgendjemand gesagt hat, Daumen hoch, putzelt das automatisiert bis aufs Produktivsystem durch. Kleinständerung.

Ja. Ja.

irgendwelche Bugs, die in einem Logging auftreten oder zum Beispiel wir haben ein Paket geupdatet und da gab es dann doch einen Seiteneffekt, der nicht aufgefallen ist vorher. Hast du dann, sagen wir mal, wenn die Pipeline 15, 20 Minuten läuft, vielleicht eine halbe Stunde gefixt. Hast du das nicht und musst das manuell machen. Was passiert? Ich bin gerade an etwas am Arbeiten, also muss ich das an Seite legen, weil wenn du die Pipeline nicht hast, dann hast du auch davor schon das Chaos. Dann kannst du nicht deployen, weil es wurde schon drei Tage nicht deployed. Da sind noch vier andere Änderungen, die warten auf Deployment. Ich muss irgendwie mich irgendwo anmelden und Sachen zusammen klicken. Das dauert. Da wähle ich einmal das falsche System aus. Ich deploye nicht aufs Testsystem, sondern auf Produktiv oder so, weil ich den falschen Dropdown ausgewählt habe.

Ja, oder es ist alles auf einmal ganz dringend und ich muss jetzt unbedingt sofort das ausrollen. Die anderen Änderungen, die da drin sind, im Branche, sind nicht getestet.

Mhm.

So. Ja.

Also, was ich meinte ist einfach, es staut sich vorher schon viel, weil du dann einfach nur alle paar Tage oder Wochen sogar nur deployst.

Oder Monate.

Und das ist einfach, oder noch schlimmer. Und das, was früher immer gesagt wurde, so, ja, automatisierte Deployments, bisschen produktiv, ist schon schön, das ist ein Schleifchen. Uns reicht weniger. Das ist mittlerweile nicht mehr so. Das muss, also es muss Mindeststandard werden oder es wird Mindeststandard, weil du anders nicht mehr hinterher kommst als Entwickler. Du hast zwar mehr Zeit, weil KI, die

Ja, nicht nur als Entwickler, also als gesamtes Ding.

Mhm.

Du brauchst es heute, du kommst nicht mehr drumherum und ich finde es sehr fahrlässig, dass man das nicht auf seiner Liste gerade hat und angeht, wenn man das noch nicht hat.

Ja, das ist der größte Gewinn. Du kannst dir ausrechnen, wie viel Lebenszeit du sparst. Du kannst dir in Online-Shops Umsatz ausrechnen, der ausfällt, wenn du zum Beispiel Downtimes hast, weil Chaos beim Deployment ist.

Aber ich glaube, das ist

Also das sind ja alles messbare Werte sogar. Und das ist eigentlich das Schöne. Also für Entwickler, wir haben Bauchschmerzen, wir jammern immer darüber und sagen, wir hätten das ja gerne. Aber auch auf der anderen Seite ist es ja schön, dass man sagen kann, guck mal, es ist messbar. Weiß ich nicht, viel weniger Ausfälle. Man kann aufzeigen, wie häufig deployed wird, wie häufig man zurückrollen muss oder Fehlerraten sich verändern. Das sind so schöne Werte, die du... Ja. Ja.

Angesichts der Zeit dann ein Thema für eine neue Runde Secrets Not Included. Weil sonst fange ich jetzt auch wieder mit Deployments an, Daniel.

Sorry. Schon wieder. Ja. Ja.

Nö, alles gut, alles gut. Ich mag die Themen ja, aber dann sprengen wir unser Zeitfenster völlig. Ich möchte dich gar nicht so jetzt abwürgen abrupt. Automatisiertes Deployments sind top. Und ich glaube, dann sehen wir uns aber in einer neuen, nächsten Folge Secrets Not Included in der nächsten Woche. Ja. Macht's gut. Bis dahin. Ciao, ciao.

Bis dann. Ciao.