Transcript
Kai Ole Hartwig: Herzlich willkommen zu einer neuen Folge Secrets Not Included mit Daniel und Ole.
Kai Ole Hartwig: Und diese Woche möchte Daniel über die neuesten, schärfsten Sicherheitslücken reden.
Kai Ole Hartwig: Daniel, was hast du mitgebracht?
Daniel Langemann: Ja, es gab ja diese Woche, beziehungsweise vor ein paar Tagen war das, dass das Axios-Paket von NPM ja nicht gehackt oder übernommen wurde, beziehungsweise es wurde eine Version veröffentlicht, die...
Daniel Langemann: ein Payload nachgeladen hat, sagen wir mal.
Daniel Langemann: Wenn ich npm install gemacht habe, wurde ein in dem Paket ein abhängiges Paket mit installiert, was dann zum Beispiel Credentials und Token und solche Sachen auf dem Rechner dann basierend ausgespäht und weiter gesendet hat.
Daniel Langemann: Ganz interessant an dem Ganzen ist aber, es war jetzt kein Payload, der in dem Projekt drinnen war.
Daniel Langemann: sondern es war einfach nur eine Dependency von Axios, die beim npm-Install nachgeladen wird.
Kai Ole Hartwig: Mhm.
Daniel Langemann: Also gibt bei npm genauso bei Composer ja auch immer die Möglichkeit, so Skripte nachträglich auszuführen.
Daniel Langemann: Entweder eigene, beziehungsweise viele Pakete machen das ja auch, die installieren dann ihre Abhängigkeiten, Config, alles Mögliche und natürlich auch andere weitere Abhängigkeiten.
Daniel Langemann: Und bei Axios war das so.
Daniel Langemann: Da ist jemand hingegangen und hat dann kurz vorher auf NPM ein schadhaftes Paket veröffentlicht, hat es geschafft, den Account sozusagen zu übernehmen und hat da einfach nur eine Zeile hinzugefügt und sozusagen sein schadhaftes Paket als Abhängigkeit mit eingebaut und dadurch
Daniel Langemann: konnte er beim npm install mit seinem repository dann noch weitere Skripte ausführen und dann natürlich Sachen machen, also Sachen nachinstallieren, Sachen ausspähen und das Tool war auch, also habe ich gelesen, ich habe es selber leider nicht gesehen oder ausprobiert, das war auch so fit, dass es wirklich ausgespäht hat und danach hinter sich aufgeräumt hat.
Daniel Langemann: Also im Idealfall hast du nachher nicht mehr gefunden, dass du was auf dem Rechner hattest und deine Credentials waren trotzdem weg.
Kai Ole Hartwig: Ja, perfekt.
Kai Ole Hartwig: Also ich meine, das passt ja auch zu dem, wo wir schon drüber gesprochen haben, dass eigentlich Credentials doof sind.
Daniel Langemann: Jetzt können wir uns ja hinsetzen an einem so erhobenen Finger.
Daniel Langemann: Haben wir doch gesagt.
Kai Ole Hartwig: Ja, ja, natürlich.
Daniel Langemann: Ja.
Kai Ole Hartwig: Natürlich.
Kai Ole Hartwig: Habe ich euch allen vor Wochen schon gesagt und bei LinkedIn auch geschrieben, SSH-Keys sind doof, wenn sie länger als zwei Minuten gültig sind oder so ähnlich.
Kai Ole Hartwig: Wofür ich ja ein bisschen Hate abbekommen habe.
Kai Ole Hartwig: Auf Freunde Nacht, also ganz ehrlich, das ist ja auch, also es ist halt ein klassischer Angriff auf die Software-Lieferkette und ehrlicherweise ist das halt so ein Ding, okay, man sagt halt, ah, hier ist ein Update, installier mal und gut, es ist jetzt sicher,
Daniel Langemann: Mhm.
Kai Ole Hartwig: de facto quasi niemand hin und prüft, was ist denn jetzt in diesen Paketen an Änderungen drin.
Kai Ole Hartwig: Dafür kommen ja auch zu viele Änderungen rein.
Kai Ole Hartwig: Also wenn man von jeder Änderung und dann auch gerade den Abhängigkeiten alles prüfen würde, dann müsstest du ja in jedem Unternehmen fünf Leute dafür beschäftigen.
Kai Ole Hartwig: Dafür ist einfach die Paketlandschaft zu komplex geworden.
Kai Ole Hartwig: Aber ich finde, das zeigt halt gut zwei Dinge.
Kai Ole Hartwig: Und vielleicht ein Ding ist noch mega gefährlich dabei, aber es zeigt eigentlich, du musst eine Update-Retention irgendwie haben und idealerweise Updates nicht einfach nach Gefühl selber lokal ausführen, sondern durch einen geregelten Prozess mit Renovate oder Depender-Bot oder Ähnlichem.
Daniel Langemann: Mhm.
Kai Ole Hartwig: weil dann kannst du halt sagen, okay, so ein Update, spiel das erst nach x Tagen oder Stunden oder so ein, je nachdem, womit du dich wohlfühlst.
Kai Ole Hartwig: Klar, dann brauchst du auch wieder einen Break-Glass-Prozess, um zu sagen, ah ja, jetzt habe ich was ganz Kritisches, jetzt muss ich aber sofort ausspielen können.
Kai Ole Hartwig: Das ist ja das eine Ding.
Kai Ole Hartwig: Aber auch, dass du irgendwie sinnvollerweise so einen eigenen Proxy betreibst, wo du alle Pakete, die du einbindest, in einer Kopie hast, wo du weißt, okay, damit funktioniert alles so, wie ich es haben möchte.
Kai Ole Hartwig: Okay.
Daniel Langemann: Ja, das Thema SBOM hattest du ja letztens mal angesprochen.
Daniel Langemann: Das wäre zum Beispiel sehr interessant gewesen, weil man dann gesehen hätte, dass neue Abhängigkeiten hinzukommen.
Kai Ole Hartwig: Ja, das ist ja nicht
Daniel Langemann: Beziehungsweise das wäre so, um das präventiv verhindern nicht, aber man hätte es eher sehen können vielleicht.
Kai Ole Hartwig: Die S-Bomb ist ja quasi nicht vorher, also außer das Paket liefert irgendwie eine S-Bomb mit und die S-Bomb wird verglichen und man sagt dann, oh, jetzt ist was nicht in Ordnung.
Kai Ole Hartwig: Aber wenn du natürlich selber eine S-Bomb schreibst und feststellst, oh, ich habe jetzt ganz andere, neue Dependencies drin, warum sind die denn da?
Kai Ole Hartwig: Klar, dann kannst du schauen.
Kai Ole Hartwig: Ich bin jetzt ein Riesenfan von diesen Automatisierungen und sage, okay,
Daniel Langemann: Mhm.
Kai Ole Hartwig: Jetzt nachträglich schauen ist total nett, aber ich möchte eigentlich einen Prozess haben oder Prozesse insgesamt in einer Prozessarchitektur haben für die Entwicklung, dass das Risiko möglichst minimiert wird.
Kai Ole Hartwig: Dadurch, dass ich ein Update erst x Stunden oder Tage später mache, verringere ich halt das Risiko, dass ich ein Paket lade, eine Paketversion lade, die
Kai Ole Hartwig: eben eine absichtliche Lücke drin hat.
Daniel Langemann: Also Schadcode einfach.
Daniel Langemann: Ja.
Kai Ole Hartwig: Wenn die denn entdeckt wird.
Kai Ole Hartwig: Das ist ja immer die Annahme.
Kai Ole Hartwig: Bisher funktioniert es ja in der Open-Source-Welt sehr, sehr gut, dass so Lücken sehr frühzeitig und sehr effektiv entdeckt werden, dadurch, dass da Menschen sitzen, die neugierig sind.
Kai Ole Hartwig: In allen Fällen der letzten Jahre war es ja so, Menschen waren neugierig, warum etwas auf einmal anders ist und dadurch wurden die Sachen entdeckt.
Kai Ole Hartwig: Ja.
Kai Ole Hartwig: Das ist mir eigentlich noch nicht genug.
Kai Ole Hartwig: Ich weiß aber noch nicht eine coole Lösung, wie man das effektiv machen kann.
Daniel Langemann: Der macht einfach, ne?
Daniel Langemann: Oh ja, ja.
Kai Ole Hartwig: Das eigentliche Risiko, was ich im Moment sehe, ist, wenn man natürlich seinen KI-Agenten programmieren lässt.
Kai Ole Hartwig: dass der natürlich nicht unbedingt sich an die Best Practice hält, die man ihm vorgibt und halt dann nicht so Dinge macht, wie in die Packaged Sales eine feste Version schreibt.
Kai Ole Hartwig: sondern halt mit Hütchen oder so und dann wird halt doch bei Install einfach die neuere Version gezogen und nicht die Version, die da fest drin war und so Sachen und das sehe ich halt als echtes Risiko, dass halt einfach die KI auf die Idee kommt, ah ja gut, jetzt ziehe ich das einfach aus der Originalpaketquelle und nicht über den Proxy und so Sachen.
Kai Ole Hartwig: Ich finde, das ist das größere Risiko in dieser ganzen Lieferketten-Geschichte, gerade für eigene Credentials,
Kai Ole Hartwig: Und deswegen finde ich es, keine Credentials auf dem Rechner haben, also keine langlebigen, keine unentschlüsselten und so.
Kai Ole Hartwig: Und halt zum Beispiel mit dem Yubuki arbeiten, dass du dann, wenn du halt auf der Platte Credentials liegen hast, aus welchen Gründen auch immer, dass das Ding immerhin verschlüsselt ist und dass dann ein Zertifikat halt nur mit so einem Hardware-Token entschlüsselt werden kann.
Daniel Langemann: Mhm.
Kai Ole Hartwig: dann sind dir immer noch die Sachen abhanden gekommen.
Kai Ole Hartwig: Aber sie können zumindest nicht einfach genutzt werden.
Kai Ole Hartwig: Und... Ja.
Daniel Langemann: Ja, ich glaube auch so die Mischung aus vielen Sachen macht das, also nicht eine Lösung, also genau dieses Absichern der Credentials und alles ist definitiv super richtig, wenn irgendwie solche Sachen passieren, man kann viele Sachen, also mehrere Sachen machen und man muss mehrere Sachen machen, also das ist eigentlich immer das Fazit, es gibt nicht, diese eine ist, das eine Tool, was ich installiere, da bin ich safe und kann alles auf meine Pipeline oder auf meinen Server loslassen und ist alles sicher, ne?
Daniel Langemann: Und das macht auch Security so spannend oder schwer, weil du halt viele Tools hast, die zusammenspielen müssen oder wenn sie es nicht tun, dann noch einfach sinnfrei sind.
Kai Ole Hartwig: Ich würde nicht unbedingt sagen Tools, sondern eigentlich Methoden.
Daniel Langemann: Ja, ja.
Kai Ole Hartwig: Du musst halt gewisse Methoden anwenden oder in deinen Prozessen im Prinzip etabliert haben.
Kai Ole Hartwig: Das muss halt zum Beispiel auch einfach klar sein, dass dann niemand hingeht und sagt, jetzt update ich meine MPM-Pakete oder Composer-Pakete oder welche Pakete auch immer einfach manuell, sondern es gibt diesen automatisierten Prozess und der macht das.
Kai Ole Hartwig: Der kümmert sich da drum
Kai Ole Hartwig: Und nur wenn da irgendwas ist, dann kümmere ich mich selber drum.
Kai Ole Hartwig: Also du könntest dann ja auch hingehen, muss ich mal ausprobieren, aber das ist vielleicht auch eine schöne Idee, und deine S-BOM vergleichen und wenn dann auf einmal unerwarteter Weise was dazu kommt, dass dann die Pipelines blockieren.
Daniel Langemann: Mhm.
Daniel Langemann: Meinst du so ein Diff größer als, weiß ich nicht, 5% oder so?
Daniel Langemann: Also, ne, nicht mehr als 5% gleichzeitig.
Daniel Langemann: Obwohl, wäre egal gewesen.
Daniel Langemann: Jetzt wäre es eine Zeile oder ein Paket gewesen, was gereicht hätte, ne?
Daniel Langemann: Mhm.
Daniel Langemann: Mhm.
Kai Ole Hartwig: Ja.
Kai Ole Hartwig: Ja, aber wenn einfach eine neue Dependency dazu kommt.
Kai Ole Hartwig: und die zum Beispiel auch nicht in der Commit-Message erwähnt ist.
Kai Ole Hartwig: Wenn du ein Commit machst und sagst, hey, ich füge jetzt bla bla bla ein als Paket, kannst du ja auslesen, ah, jetzt ist das Paket dazu gekommen, das ist fein und damit ist alles gut.
Kai Ole Hartwig: Aber wenn das halt unerwartet bei einem Update geht, dass dann halt quasi deine Pipeline stehen bleibt und du manuell bestätigen musst oder so.
Kai Ole Hartwig: Vielleicht ist das noch eine Idee.
Kai Ole Hartwig: Muss ich mal schauen, vielleicht baue ich das mal.
Daniel Langemann: nächstes Wochenende.
Kai Ole Hartwig: Naja, heute Nacht.
Kai Ole Hartwig: Das ist halt das Wichtige, wenn man sich auf so Prozesse einigt.
Kai Ole Hartwig: Die Prozesse scheitern halt am ehesten an Menschen, die dann sagen, ah, ich mache jetzt schnell mal eben etwas.
Kai Ole Hartwig: Dann vorbei am Prozess, dann verlierst du natürlich die Sicherheit, die du durch Automatisierung zum Beispiel gewonnen hast oder durch einfach das Festlegen eines vorgegebenen Prozesses, verlierst du.
Kai Ole Hartwig: Und genauso, wenn halt jemand sagt, okay, ich, ach, das ist mir jetzt egal, die Secrets, dass die immer verschlüsselt sind, das nervt mich irgendwie, ich umgehe das bei mir lokal.
Daniel Langemann: Ja.
Kai Ole Hartwig: So, dann kannst du natürlich hingehen und auch durch Prüfungen quasi das prüfen, bevor irgendwas im Repository landet.
Kai Ole Hartwig: Aber du kannst natürlich nie verhindern, dass ein Entwickler etwas macht, was du nicht vorsiehst.
Kai Ole Hartwig: Und auch die KI irgendwas nicht macht, was vorgesehen ist.
Kai Ole Hartwig: Aber ja, Softwarelieferkette ist definitiv das heißeste Thema aktuell.
Daniel Langemann: Mhm.
Kai Ole Hartwig: Und gerade im MPM.
Kai Ole Hartwig: Ich finde das faszinierend, dass wir im Prinzip wöchentlich Sicherheitslücken oder Lieferketten-Schwierigkeiten, nenne ich es jetzt mal so,
Kai Ole Hartwig: bei MPM sehen, bei Paketen, die über GitHub-Actions gebaut werden und gefühlt bei WordPress.
Kai Ole Hartwig: Jetzt ist WordPress nicht so mein Thema, das ist mir jetzt nicht so, also ich lese das nur immer zwischendrin.
Kai Ole Hartwig: Aber das sind ja schon massive Störungen und da müssen wir als Dienstleister, als Entwickler
Kai Ole Hartwig: und Devops, DevSecOps, wer auch immer jetzt in diesem ganzen Bereich unterwegs ist, müssen wir halt viel mehr Augenmerk drauflegen.
Kai Ole Hartwig: Und ich finde, das ist viel komplexer geworden.
Daniel Langemann: Ich spiele gerade ein bisschen mit dem Gedanken, also das ist ja so viel, dass du eigentlich menschlich nicht alles reviewen kannst.
Kai Ole Hartwig: Ja.
Daniel Langemann: Gibt es schon etwas in die Richtung oder meinst du, sowas könnte Sinn machen, dass man sagt, wenn ich solche Updates einspiele, dass ich einfach sage, hier, liebe KI, guck mal drüber.
Daniel Langemann: Also die kann ja schon mal vorab drüber gucken, ist ja besser als nichts.
Daniel Langemann: Zumindest zu sagen, was passiert da, was kommt da Neues hinzu.
Kai Ole Hartwig: Tja, Tja, jetzt ist die Frage, ist es die Tokens wert und erkennt sie das, dass da es eingefügt ist, was potenziell schädlich ist?
Kai Ole Hartwig: müsste man mal ausprobieren, ehrlicherweise, ob das, also wie erfolgreich das ist.
Daniel Langemann: Genau.
Daniel Langemann: Genau.
Kai Ole Hartwig: Wir lassen das ja tatsächlich über unsere Codeänderungen lassen, wir die KI auch Security Reviews machen und so Sachen.
Kai Ole Hartwig: Aber wir lassen jetzt nicht explizit bisher so Dependency-Änderungen prüfen.
Kai Ole Hartwig: Aber es ist vielleicht auch einfach etwas, was man ausprobieren kann.
Kai Ole Hartwig: Ich weiß nicht, ob es mittlerweile ein festes Produkt dafür gibt.
Kai Ole Hartwig: rausgebracht.
Kai Ole Hartwig: So, das ist jetzt aber......
Daniel Langemann: Also ich kenne zum Beispiel Coder Rabbit noch, was du auch nutzen kannst und einbinden kannst.
Daniel Langemann: Also das nutze ich halt gerne und oft, weil das auch irgendwie so ein anderes Model ist und halt immer die Sachen findet, die Cloud Code oder Open Code, Chat-JPT oder sonst wer nicht gefunden haben.
Daniel Langemann: Oder die unterscheiden sich so ein bisschen.
Daniel Langemann: Deswegen fand ich das immer interessant, die gegeneinander zu nutzen.
Daniel Langemann: Das war meine Überlegung, ob das damit angeschlagen wäre oder nicht.
Daniel Langemann: Hätte ich mal ausprobiert oder müsste ich mal ausprobieren.
Kai Ole Hartwig: Ja, die Frage, die sich mir halt immer stellt, ist, ist, wenn wir jetzt noch ein Modell einbinden,
Kai Ole Hartwig: Also gerade die großen Modelle ist natürlich schwierig, selber zu betreiben.
Kai Ole Hartwig: Und irgendwann schicken wir halt so viel Daten durch die Gegend.
Kai Ole Hartwig: Stimmt dann auch unser Prozess, wenn wir alles immer durch, also wenn wir jetzt noch anfangen, durch verschiedene KI-Modelle zu reviewen und durch die Gegend zu schmeißen.
Daniel Langemann: Ja, also, was die Lösung ist, weiß ich nicht.
Daniel Langemann: Das Problem ist einfach aktuell, als Einzelner oder auch als Agentur kannst du ja gar nicht alles reviewen, was da an Abhängigkeiten über NPM oder Composer oder was auch immer ins Projekt kommt.
Kai Ole Hartwig: Ich glaube, das ist unabhängig von der Größe.
Kai Ole Hartwig: Also ich kenne kein Projekt, das personell so ausgestattet wäre, wäre, dass mit der aktuellen Geschwindigkeit an Updates mitgehalten werden kann, um das zu reviewen.
Kai Ole Hartwig: Wenn ich bei uns die Pipelines anschaue, wie viele Änderungen bei uns reinkommen, jeden Tag,
Daniel Langemann: Ja.
Daniel Langemann: Mhm.
Kai Ole Hartwig: dann brauche ich halt in den Pipelines ehrlicherweise etwas, was mir sagt, okay, hier ist jetzt etwas, das muss sich jemand anschauen.
Kai Ole Hartwig: Hier gehen Tests kaputt oder hier schlägt eine von unseren Policies an oder, oder, oder.
Kai Ole Hartwig: damit sich das jemand anschauen kann, weil sonst kommst du einfach nicht hinterher.
Kai Ole Hartwig: Also egal, wie groß dein Team ist, je größer das Team ist, je mehr Software hast du oder Verantwortung für irgendwelche Systeme hast du ja auch de facto.
Kai Ole Hartwig: Und aus meiner Sicht müssen wir Lieferketten, Sicherheit Sicherheit zeitnah anders lösen in der Open-Source-Community.
Kai Ole Hartwig: Ja, wir brauchen mehr Zuverlässigkeit und damit ja ganz offensichtlich auch Sicherheit für den Login und die Berechtigung, Releases zu machen.
Daniel Langemann: herstellen?
Kai Ole Hartwig: Häufig ist es ja, dass Accounts einfach nicht gut abgesichert sind.
Kai Ole Hartwig: So.
Daniel Langemann: Ich muss sagen, ich habe mich noch nicht schlau gemacht oder noch nicht weitergelesen, was da passiert ist und wie die Leute an die Accounts gekommen sind.
Kai Ole Hartwig: Ja.
Daniel Langemann: Ich habe einfach unterstellt, dass jeder Zwei-Faktor-Authentifizierung aktiv hat und in meiner kleinen, kleinen, kleinen Welt ist jeder verantwortungsbewusst.
Daniel Langemann: Alles andere wäre natürlich grob fahrlässig, aber auch das ist ja nicht unumgehbar.
Kai Ole Hartwig: Naja, und zum anderen, dann hast du halt wieder irgendeinen Long-Living-Token irgendwo rumfliegen.
Kai Ole Hartwig: Und dann kommst du halt doch wieder rein in die Accounts, einfach über die CLI.
Kai Ole Hartwig: Du musst ja nicht unbedingt über die Oberfläche in den Account und dich ganz normal einloggen.
Kai Ole Hartwig: Das reicht ja, wenn du so einen GitHub-Token hast und dann da mit reingehst.
Daniel Langemann: Ja, genau.
Daniel Langemann: All Access Token mit allen Zugriffsdaten.
Kai Ole Hartwig: Das ist ja der Punkt, wo ich auch immer wieder herkomme und sage, hey, schaut mal, wir müssen...
Kai Ole Hartwig: kurzlebige Sachen haben und deswegen auch zum Beispiel das OIDC für SSH und so und das ja auch in der Pipeline verwenden und so weiter.
Kai Ole Hartwig: Einfach um das Risiko und die Möglichkeiten so weit einzuschränken, dass wenn die wegkommen,
Kai Ole Hartwig: der Blaze-Radius, also der Schadens-Radius halt minimiert ist.
Daniel Langemann: Mhm.
Kai Ole Hartwig: Und wir spüren natürlich, wenn in der Open-Source-Welt was komplementiert wird, also dann spürt das natürlich sehr schnell sehr viele Menschen.
Kai Ole Hartwig: Und, ähm, ich will jetzt nicht sagen, ah, da ist jemand total unverantwortlich mit seiner Account-Sicherheit umgegangen oder so, ne?
Kai Ole Hartwig: Also, gar keine Umstände will ich das jemandem unterstellen.
Kai Ole Hartwig: Ähm,
Kai Ole Hartwig: Aber... Das mit dem Versuchen möchte ich jetzt nicht sagen.
Daniel Langemann: Wir sind einfach nur unbedeutend genug, dass es bei uns noch keiner versucht hat.
Daniel Langemann: Also, dass die Guten das nicht versucht haben, so rum.
Daniel Langemann: Hm.
Kai Ole Hartwig: Also meine E-Mails sagen was anderes.
Kai Ole Hartwig: Ähm... Ähm... Ja.
Kai Ole Hartwig: Sagen wir so, solange mein Yubi-Key hier reingesteckt ist, wird es schwierig.
Kai Ole Hartwig: Ähm...
Kai Ole Hartwig: Aber ja, es gibt halt einfach dieses Risiko und wir brauchen, glaube ich, mal in der Open Source-Welt eine ganz ehrliche Diskussion darüber, wie schaffen wir allgemein mehr Sicherheit.
Kai Ole Hartwig: Also zum Beispiel auch mit den GitHub-Actions, die wir ja auch schon hatten als Sicherheitsstücken, wo dann einfach Sachen ausgeführt wurden, die nicht ausgeführt werden sollten und so.
Daniel Langemann: Ich muss sagen, mir ging jetzt zum Beispiel durch den Kopf, wäre ich von diesem Axios-Ding betroffen gewesen.
Daniel Langemann: Ich meine, das Projekt, an dem ich zu dem Zeitpunkt theoretisch am Arbeiten war, ist klein genug, dass ich im Kopf habe, dass da fünf Credentials und ein SSH-Key, also was da theoretisch alles hätte flirten gehen können.
Kai Ole Hartwig: Ja gut, aber du hast ja mehr als ein Projekt auf dem Rechner.
Kai Ole Hartwig: Ja.
Daniel Langemann: Genau, genau.
Daniel Langemann: Und dann fängt es schon an.
Daniel Langemann: Und dann ist mir bewusst geworden, dass ich zum Beispiel, zumindest bei den kleineren Projekten, entweder wenig Inventarisierung habe, dass ich sagen könnte, guck mal, was ist da alles und wie schnell könnte ich die Sachen eigentlich tauschen?
Daniel Langemann: Also zum Glück, so bei den meisten Sachen, habe ich jetzt über Terraform mit AWS vieles geregelt.
Daniel Langemann: Da ist dann entweder eh automatisch wechselnde Credentials, zum Beispiel für die Datenbank oder solche Sachen mit drin,
Daniel Langemann: Langlebigere Sachen hätte ich jetzt auch tauschen können und dann mit einem Deploy austauschen können.
Daniel Langemann: Was sich bei mir gezogen hätte, glaube ich, wären, wie du sagst, so Account Credentials zum Beispiel, die irgendwie noch elendig Zugriff brauchen, um...
Daniel Langemann: Zum Beispiel jetzt für Slack hatte ich irgendwann mal so ein Notifications eingerichtet.
Daniel Langemann: Da musst du dann wieder so ein Key… Also solche Sachen sind schwer zu tauschen oder nicht schwer aufwendig zu tauschen.
Kai Ole Hartwig: Ja, genau.
Daniel Langemann: Es brauchen viel Zeit, es ist nicht schwer, aber es ist halt Fleißarbeit.
Daniel Langemann: Mhm.
Kai Ole Hartwig: Und was wir ja machen, ist zum Beispiel, wir führen MPM und PHP gar nicht mehr auf den lokalen Maschinen aus.
Kai Ole Hartwig: Die sind da einfach nicht mehr installiert.
Kai Ole Hartwig: Die sind nur im Container vorhanden.
Kai Ole Hartwig: So.
Kai Ole Hartwig: Das heißt auch, das reduziert ja den direkten Zugriff klar, kannst du auch wieder aus dem Container rauskommen und so weiter und so fort.
Daniel Langemann: Das ist ein guter USP für eine Dev-Umgebung, ne?
Kai Ole Hartwig: Ja, genau.
Daniel Langemann: Eine dockerisierte Dev-Umgebung, wenn du nicht gerade dein halbes Betriebssystem mountest mit deinem Home-Verzeichnis.
Daniel Langemann: Mhm.
Kai Ole Hartwig: Das ist ja so der nächste Punkt, was man eigentlich dann mountet.
Kai Ole Hartwig: Auch ob man nicht sinnvollerweise grundsätzlich immer seinen KI-Agenten, der programmieren soll, nicht auch einfach im Container leben lässt und gar nicht mehr lokal.
Daniel Langemann: Hm.
Daniel Langemann: Hm.
Daniel Langemann: Da würde ich dich schön wegsperren.
Kai Ole Hartwig: Wenn der halt im Container rumwerkelt, dann weiß er ja auch gar nichts von der Außenwelt.
Daniel Langemann: Also, was vielleicht nicht line-tauglich ist, aber unter Linux kannst du ja auch einen Change-Root machen.
Daniel Langemann: Also, dass du ein komplettes System umhängst und dann ist das auch wie ein Container.
Kai Ole Hartwig: Ja, genau.
Daniel Langemann: Für ein OpenClaw oder so würde ich das echt empfehlen.
Daniel Langemann: Ist aber fricklich.
Daniel Langemann: Für... Hm.
Kai Ole Hartwig: Und mein Gedanke ist ja, wie machen wir es einfach, aber trotzdem sicher?
Kai Ole Hartwig: So, und das ist halt auch, ich habe jetzt schon von vielen gelesen, dass sie sagen, ah ja, ich lasse das Ding nur im Container laufen.
Kai Ole Hartwig: Und ich glaube, das ist auch eine ganz schlaue Idee.
Kai Ole Hartwig: Aber wenn er dann irgendeinen Shit macht und installiert,
Kai Ole Hartwig: dann war es halt ein Container und dann sind es im Zweifelsfall da Secrets verloren gegangen.
Kai Ole Hartwig: Das ist auch schon wieder mystisch.
Daniel Langemann: Also es ist einfach eine Extraschicht drumherum.
Kai Ole Hartwig: Aber... Ja.
Daniel Langemann: Die ist auch nicht hundertprozentig bulletproof, aber besser als nichts.
Daniel Langemann: Mhm.
Kai Ole Hartwig: So, das Risiko ist halt geringer.
Kai Ole Hartwig: Und da kannst du dann halt auch, wenn du ja eh deine Secrets in der Runtime liegen hast, dann ist das ja schon mal weniger...
Kai Ole Hartwig: Ich weiß gar nicht, ob der Hack jetzt tatsächlich die Runtime geprüft hat oder nur.env und so abgefrühstückt hat und SSH-Keys.
Daniel Langemann: So tief war ich nicht drin.
Kai Ole Hartwig: Ja.
Kai Ole Hartwig: Ja, gut.
Kai Ole Hartwig: Ja.
Kai Ole Hartwig: Ja, deshalb.
Daniel Langemann: Also ich habe nur gelesen, dass der sich systemagnostisch bewegt hat.
Daniel Langemann: Also der wusste wohl auf welchem Linux, Windows oder Mac und dann passend installiert und agiert.
Daniel Langemann: Also schlecht war er wohl nicht.
Kai Ole Hartwig: Ich hätte auch schon mal überlegt, ob man die Runtime noch mal ein bisschen mehr absichert, dass der User, der quasi dann die KI drin läuft, dann nicht Runtime lesen darf.
Daniel Langemann: Mir gefällt die Docker-Variante sehr, weil die ist, ne?
Kai Ole Hartwig: Ja, ich meine auch im Docker.
Daniel Langemann: Ach so, im Docker.
Daniel Langemann: Ja, du solltest den nicht als Root ausführen, so meinst du das.
Daniel Langemann: Also, ich... Hm?
Kai Ole Hartwig: Ja.
Kai Ole Hartwig: Ja, nicht nur nicht als root.
Kai Ole Hartwig: sondern dass du tatsächlich dem User, in dem dein Cloud oder OpenCode oder whatever, DevStraw gerade läuft als Agent zum Programmieren, dass der tatsächlich auf Slash Run nicht lesen darf und schreiben, logischerweise.
Daniel Langemann: Hmm.
Daniel Langemann: Hmm.
Kai Ole Hartwig: Also gar nichts von dieser Existenz weiß.
Kai Ole Hartwig: Aber ich habe noch nicht, also das habe ich mir noch nicht tief genug angeschaut, ob das
Kai Ole Hartwig: musst.
Kai Ole Hartwig: So, musst ja NPM-Pakete laden und ausführen, das ist auch immer so.
Kai Ole Hartwig: Also, die mag ich ja am wenigsten, ne?
Kai Ole Hartwig: Die PHP-Pakete, das ist auch geschenkt.
Kai Ole Hartwig: Aber du musst dann ja natürlich auch das PHP ausführen können und dann kannst du halt auch schon wieder über Umwege das alles lesen.
Daniel Langemann: Ja.
Kai Ole Hartwig: Jetzt ist halt die Frage, muss Cloud oder OpenCode oder whatever PHP ausführen können?
Kai Ole Hartwig: Und dann ist halt wahrscheinlich am Tagesende wieder die Antwort, ja schon, weil sonst kannst du ja auch selber gar nicht prüfen, ob alles in Ordnung ist.
Daniel Langemann: Das bzw.
Daniel Langemann: es führt Python aus, um meistens über Sachen drüber zu grappen oder andere Sachen.
Daniel Langemann: Also das führt ja einiges aus und baut sich auch kleine Python-Skripte immer wieder, sieht man ja wieder.
Kai Ole Hartwig: Ja, aber halt zum, wenn ich ihm halt sage, ja, hey, du musst immer PHP-Stand ausführen und dann sage ich gleichzeitig halt, ah, nee, das jetzt PHP ausführen darfst du nicht, das scheitert halt irgendwie, ne?
Daniel Langemann: Ein paar Sachen baut und über Sachen iteriert, gerade wenn es so mit Excel-Dateien geht oder so.
Kai Ole Hartwig: So, wenn ich ihm dann sage, ah, du musst aber dafür den Benutzer wechseln, ja, dann, also, das ist dann schon wieder so ein bisschen sinnfrei.
Daniel Langemann: Mhm.
Kai Ole Hartwig: Ähm,
Kai Ole Hartwig: Ich weiß noch nicht so genau, wie man die Lieferkettensicherheit mit der KI tatsächlich sicherstellen soll, dass das lokale System wirklich so betrieben ist und so sicher ist, dass es das nicht ist.
Kai Ole Hartwig: Ich habe auch schon mal drüber nachgedacht, wir hatten auch die Variante, dass wir gesagt haben, okay, der KI-Assistent läuft auf dem Host, aber darf zum Beispiel nicht in die Docker-Container rein, weil da liegen halt die entschlüsselten Secrets in der Gun-Time.
Daniel Langemann: Ja, gerne.
Kai Ole Hartwig: So, dann sind meine Secrets sicher.
Kai Ole Hartwig: Dann habe ich aber halt wieder PHP und so auf meiner Maschine drauf.
Kai Ole Hartwig: Oder ich mache einen extra Container nur für Cloud, der neben dem anderen steht.
Kai Ole Hartwig: Und ja, so.
Kai Ole Hartwig: Ich finde, also wer da mal eine gute Idee hat, einfach mal erzählen.
Kai Ole Hartwig: Mir fehlt die da bisher, dass ich sage, okay, das ist wirklich sicher.
Kai Ole Hartwig: Zum einen, dass die Credentials nicht so leicht verloren gehen können.
Kai Ole Hartwig: Ja, und bitte jetzt nicht wieder mit, ah, ich habe hier ein Proxy für die Credentials, weil das hilft mir am Tagesende, also das löst eigentlich mein Problem nicht.
Daniel Langemann: Was ich mich noch frage ist, also das ist ja alles auch so eine Vertrauenssache.
Daniel Langemann: Und irgendjemand muss ja diesen Comet gepusht haben.
Daniel Langemann: Und für mich ist es so, dass ich zum Beispiel, also bei mir das immer so einstelle, dass auch die Comets signiert sind.
Daniel Langemann: Jetzt frage ich mich, hm?
Kai Ole Hartwig: Ich grüße auf einen Fall.
Kai Ole Hartwig: Bin ich großer Fan von?
Daniel Langemann: Hm, jetzt frage ich mich gerade, also jetzt bei dem Axios-Fall, ähm,
Daniel Langemann: Da muss ja ein Commit gewesen sein, der nicht signiert ist, weil ich unterstelle dem Entwickler mal, dass wir alle paranoid sind, dass wir das machen, weil wie will denn jemand anders meinen Commit signieren, wenn meine Credentials nicht verloren gehen?
Kai Ole Hartwig: Das ist, finde ich, eine falsche Annahme.
Daniel Langemann: Okay.
Kai Ole Hartwig: Wenn ich mir Open Source Projekte anschaue, ist das Signieren einfach kein Standard.
Kai Ole Hartwig: Also ich bin auch vom Signieren und Attestieren von allen Artefakten großer Fan, also von den Commits, von Tags, von Releases, von so.
Kai Ole Hartwig: Auch, dass die Pipeline nicht erwartet, das gebaut hat und dann mit dem richtigen Zertifikat und so weiter.
Kai Ole Hartwig: Und dass wir das gegenprüfen, dass es auch tatsächlich quasi von uns kommt.
Kai Ole Hartwig: Ja.
Daniel Langemann: Habe ich anscheinend noch nicht oft genug gemacht.
Daniel Langemann: Also, ja.
Kai Ole Hartwig: aber das ist jetzt nicht so verbreitet.
Kai Ole Hartwig: Also wenn du mal in ein beliebiges PHP-Projekt reinschaust, wie viele Commits sind da signiert?
Kai Ole Hartwig: Ja, aber das ist halt einfach ein Standard, der nicht genutzt wird in der Form.
Kai Ole Hartwig: Und ich gebe dir recht, dass wir zum Beispiel auch keine Commits annehmen, die nicht signiert sind.
Daniel Langemann: Wäre der nächste konsequente Schritt, ja.
Daniel Langemann: Ja.
Daniel Langemann: Ja.
Kai Ole Hartwig: Ja, aber das sind natürlich alles Sicherheitsschritte, die musst du machen und dann musst du halt auch sagen, okay, in meinem Projekt, wenn ihr da mitmachen wollt, dann müsst ihr eure Dinger signieren und dann musst du halt auch einen öffentlich überprüfbaren Schlüssel verwenden und hinterlegen, also keinen SSH-Key dafür benutzen, den kannst du nicht überprüfen, sondern du musst halt einen GPG-Key nehmen.
Daniel Langemann: Ja, also bei allen großen Hostern oder Plattformen, egal ob Bitbucket, GitLab oder GitHub, kannst du ja auch den Public-GPG-Key hinterlegen und der zeigt dann an, dass dieser Commit passend signiert wurde.
Kai Ole Hartwig: Ja, genau, du kannst auch dein SSHK hinterlegen.
Daniel Langemann: Ja, ich bin komisch, was das betrifft anscheinend.
Kai Ole Hartwig: Aber ich meine, wenn du tatsächlich so richtig öffentlich prüfbar haben möchtest, müsstest du halt das ja irgendwo öffentlich ablegen.
Kai Ole Hartwig: So, und und ich finde, das ist ein wunderbarer Standard, der viel zu selten genutzt wird.
Daniel Langemann: Ich...
Daniel Langemann: Aber es ist ja auch technisch nicht besonders schwer oder braucht irgendwelche besonderen Sachen, sondern brauchst einen GPG-Key, den du dir generierst, Public und Private.
Kai Ole Hartwig: Das ist auch ein Ding, was ich mir einfach wünschen würde, dass das passiert.
Kai Ole Hartwig: Oder halt ein S-H-Key.
Kai Ole Hartwig: Also ein Key.
Daniel Langemann: Ja, das ist ja auch.
Daniel Langemann: Wir machen es da ganz besonders.
Daniel Langemann: Wir machen wieder ein Schleifchen dran.
Daniel Langemann: Also es geht natürlich auch weniger.
Daniel Langemann: Aber mir ging es zum Beispiel immer darum, gerade wenn ich als Externer irgendwo im Projekt bin und das Schlimmste oder das Blödeste, was passieren kann, ist Rebasen verändert den Comet.
Daniel Langemann: Und was passiert, wenn ein Pull-Request gemacht wird, an dem ich mitgemacht habe und jemand klickt auf Rebacen beim Zusammenführen, dann stehen auf einmal da irgendwelche Sachen dran, die ich gar nicht gemacht habe, weil irgendein Kollege mit rein committed hat oder so, weil mehrere an einem PR gearbeitet haben.
Daniel Langemann: Und für mich war das immer so, ich kann dann absichern, das bin ich wirklich gewesen und ansonsten ist die Historie ja, da kann ja jeder machen, was er will und rewriten.
Kai Ole Hartwig: Yep.
Daniel Langemann: Es sei denn, die sind signiert.
Daniel Langemann: Und jetzt zu dem Thema war das, oder ist das halt auch mein Gedanke gewesen, wenn ich ja deinen Schlüssel kenne und sehe und nur Commits von dir zulasse, wie kann dann jemand den Account, also selbst wenn dein Account geklaut wird und der GPG-Key oder dein SSH-Key, den du genutzt hast, nicht...
Daniel Langemann: komprimiert wird, weil du den vernünftig irgendwo gesichert hast, kann doch keiner neuen Code hinzufügen, ohne dass es irgendwie komisch wird.
Daniel Langemann: Und das ist etwas, was kannst du auch sehr leicht sicherstellen.
Daniel Langemann: Mhm.
Kai Ole Hartwig: Naja, das Ding ist ja, wenn dein Account komplementiert ist und du halt volle Schreibberechtigung auf die Einstellung hast, dann kannst du halt auch sagen, hey, okay, pass auf, ich muss jetzt nicht mehr signieren.
Kai Ole Hartwig: So.
Daniel Langemann: Okay, das müsste ich auf meiner Seite sicherstellen, dass ich das erwarte.
Daniel Langemann: Mhm.
Kai Ole Hartwig: Ja, du müsstest, also man darf sich dann natürlich nicht darauf verlassen, dass jetzt die Einstellung in deinem Source-Code-Verwaltung immer so bleibt, wie sie ist, ne?
Kai Ole Hartwig: Dass, du müsstest halt mehr oder weniger noch einen Pipeline-Schritt haben, der sagt, okay, ist das denn jetzt auch richtig signiert?
Kai Ole Hartwig: So.
Kai Ole Hartwig: Aber
Kai Ole Hartwig: Und auf der anderen Seite kannst, also wenn du einmal in so einem Account drin bist, das ist halt das Problem, dann kannst du wieder sehr, sehr viele Sachen machen.
Kai Ole Hartwig: Du musst im Prinzip ja dafür sorgen, bestmöglich dafür sorgen, dass halt niemand in deinen Account reinkommt.
Daniel Langemann: Ich hab dich dazu gekriegt, was zu sagen, was dir nicht passt.
Kai Ole Hartwig: Und was immer sichergestellt ist, dass du das bist.
Daniel Langemann: Ja.
Daniel Langemann: Ja.
Kai Ole Hartwig: Und ich finde, da signieren nochmal so ein i-Tüpfelchen.
Kai Ole Hartwig: Ähm.
Kai Ole Hartwig: Und bedeutet aber natürlich auch wieder, langlebige Credentials ist ja nichts anderes dann an der Stelle.
Kai Ole Hartwig: Das Ding gehört dann vernünftig, das gehört dann halt auch wieder vernünftig irgendwo hingeschrieben, was nicht deine Festplatte ist.
Kai Ole Hartwig: Ja, dann brauchst du wieder so ein Ding, wie so ein YubiKey, wo das Ding drauf ist und womit du dann signieren kannst, wenn es eingesteckt ist.
Daniel Langemann: Nein, nein.
Kai Ole Hartwig: Wo du dann am besten nochmal drauf touchst,
Kai Ole Hartwig: So, aber dann tatscht er ja auch irgendwann.
Kai Ole Hartwig: Also, so.
Kai Ole Hartwig: Ja, schwierig.
Kai Ole Hartwig: Ich glaube, es gibt viele Wege, es gibt viele Möglichkeiten, Möglichkeiten, wie die Lieferkette insgesamt sicherer werden könnte.
Kai Ole Hartwig: Nur wir beide werden das jetzt nicht alleine lösen.
Daniel Langemann: Und wenn, dann werden wir lange beschäftigt.
Daniel Langemann: Ja.
Daniel Langemann: Ja.
Daniel Langemann: Ja.
Kai Ole Hartwig: Fürchte ich auch, Daniel, fürchte ich auch.
Kai Ole Hartwig: Dann, ich glaube, wir sind, jetzt ist alles gesagt dazu, wir sind am Ende unserer wunderbaren Folge von Secrets Not Included angelangt für diese Woche.
Kai Ole Hartwig: Wunderbar.
Kai Ole Hartwig: Dann sehen wir uns nächste Woche wieder.
Kai Ole Hartwig: Macht's gut.
Daniel Langemann: Bis dann.
Kai Ole Hartwig: Tschö.
Daniel Langemann: Tschüss.
