Secrets Not Included: Lieferkettensicherheit

Herzlich willkommen zu einer neuen Folge Secrets Not Included mit Daniel und Ole. Und diese Woche möchte Daniel über die neuesten, schärfsten Sicherheitslücken reden. Daniel, was hast du mitgebracht?

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... ein Payload nachgeladen hat, sagen wir mal. 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. Ganz interessant an dem Ganzen ist aber, es war jetzt kein Payload, der in dem Projekt drinnen war. sondern es war einfach nur eine Dependency von Axios, die beim npm-Install nachgeladen wird.

Mhm.

Also gibt bei npm genauso bei Composer ja auch immer die Möglichkeit, so Skripte nachträglich auszuführen. 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. Und bei Axios war das so. 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 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. Also im Idealfall hast du nachher nicht mehr gefunden, dass du was auf dem Rechner hattest und deine Credentials waren trotzdem weg.

Ja, perfekt. Also ich meine, das passt ja auch zu dem, wo wir schon drüber gesprochen haben, dass eigentlich Credentials doof sind.

Jetzt können wir uns ja hinsetzen an einem so erhobenen Finger. Haben wir doch gesagt.

Ja, ja, natürlich.

Ja.

Natürlich. 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. Wofür ich ja ein bisschen Hate abbekommen habe. 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,

Mhm.

de facto quasi niemand hin und prüft, was ist denn jetzt in diesen Paketen an Änderungen drin. Dafür kommen ja auch zu viele Änderungen rein. 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. Dafür ist einfach die Paketlandschaft zu komplex geworden. Aber ich finde, das zeigt halt gut zwei Dinge. 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.

Mhm.

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. 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. Das ist ja das eine Ding. 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. Okay.

Ja, das Thema SBOM hattest du ja letztens mal angesprochen. Das wäre zum Beispiel sehr interessant gewesen, weil man dann gesehen hätte, dass neue Abhängigkeiten hinzukommen.

Ja, das ist ja nicht

Beziehungsweise das wäre so, um das präventiv verhindern nicht, aber man hätte es eher sehen können vielleicht.

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. 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? Klar, dann kannst du schauen. Ich bin jetzt ein Riesenfan von diesen Automatisierungen und sage, okay,

Mhm.

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. 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 eben eine absichtliche Lücke drin hat.

Also Schadcode einfach. Ja.

Wenn die denn entdeckt wird. Das ist ja immer die Annahme. 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. 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. Ja. Das ist mir eigentlich noch nicht genug. Ich weiß aber noch nicht eine coole Lösung, wie man das effektiv machen kann.

Der macht einfach, ne? Oh ja, ja.

Das eigentliche Risiko, was ich im Moment sehe, ist, wenn man natürlich seinen KI-Agenten programmieren lässt. 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. 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. Ich finde, das ist das größere Risiko in dieser ganzen Lieferketten-Geschichte, gerade für eigene Credentials, Und deswegen finde ich es, keine Credentials auf dem Rechner haben, also keine langlebigen, keine unentschlüsselten und so. 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.

Mhm.

dann sind dir immer noch die Sachen abhanden gekommen. Aber sie können zumindest nicht einfach genutzt werden. Und... Ja.

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? 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.

Ich würde nicht unbedingt sagen Tools, sondern eigentlich Methoden.

Ja, ja.

Du musst halt gewisse Methoden anwenden oder in deinen Prozessen im Prinzip etabliert haben. 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. Der kümmert sich da drum Und nur wenn da irgendwas ist, dann kümmere ich mich selber drum. 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.

Mhm. Meinst du so ein Diff größer als, weiß ich nicht, 5% oder so? Also, ne, nicht mehr als 5% gleichzeitig. Obwohl, wäre egal gewesen. Jetzt wäre es eine Zeile oder ein Paket gewesen, was gereicht hätte, ne? Mhm. Mhm.

Ja. Ja, aber wenn einfach eine neue Dependency dazu kommt. und die zum Beispiel auch nicht in der Commit-Message erwähnt ist. 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. 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. Vielleicht ist das noch eine Idee. Muss ich mal schauen, vielleicht baue ich das mal.

nächstes Wochenende.

Naja, heute Nacht. Das ist halt das Wichtige, wenn man sich auf so Prozesse einigt. Die Prozesse scheitern halt am ehesten an Menschen, die dann sagen, ah, ich mache jetzt schnell mal eben etwas. 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. 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.

Ja.

So, dann kannst du natürlich hingehen und auch durch Prüfungen quasi das prüfen, bevor irgendwas im Repository landet. Aber du kannst natürlich nie verhindern, dass ein Entwickler etwas macht, was du nicht vorsiehst. Und auch die KI irgendwas nicht macht, was vorgesehen ist. Aber ja, Softwarelieferkette ist definitiv das heißeste Thema aktuell.

Mhm.

Und gerade im MPM. Ich finde das faszinierend, dass wir im Prinzip wöchentlich Sicherheitslücken oder Lieferketten-Schwierigkeiten, nenne ich es jetzt mal so, bei MPM sehen, bei Paketen, die über GitHub-Actions gebaut werden und gefühlt bei WordPress. Jetzt ist WordPress nicht so mein Thema, das ist mir jetzt nicht so, also ich lese das nur immer zwischendrin. Aber das sind ja schon massive Störungen und da müssen wir als Dienstleister, als Entwickler und Devops, DevSecOps, wer auch immer jetzt in diesem ganzen Bereich unterwegs ist, müssen wir halt viel mehr Augenmerk drauflegen. Und ich finde, das ist viel komplexer geworden.

Ich spiele gerade ein bisschen mit dem Gedanken, also das ist ja so viel, dass du eigentlich menschlich nicht alles reviewen kannst.

Ja.

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. Also die kann ja schon mal vorab drüber gucken, ist ja besser als nichts. Zumindest zu sagen, was passiert da, was kommt da Neues hinzu.

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? müsste man mal ausprobieren, ehrlicherweise, ob das, also wie erfolgreich das ist.

Genau. Genau.

Wir lassen das ja tatsächlich über unsere Codeänderungen lassen, wir die KI auch Security Reviews machen und so Sachen. Aber wir lassen jetzt nicht explizit bisher so Dependency-Änderungen prüfen. Aber es ist vielleicht auch einfach etwas, was man ausprobieren kann. Ich weiß nicht, ob es mittlerweile ein festes Produkt dafür gibt. rausgebracht. So, das ist jetzt aber......

Also ich kenne zum Beispiel Coder Rabbit noch, was du auch nutzen kannst und einbinden kannst. 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. Oder die unterscheiden sich so ein bisschen. Deswegen fand ich das immer interessant, die gegeneinander zu nutzen. Das war meine Überlegung, ob das damit angeschlagen wäre oder nicht. Hätte ich mal ausprobiert oder müsste ich mal ausprobieren.

Ja, die Frage, die sich mir halt immer stellt, ist, ist, wenn wir jetzt noch ein Modell einbinden, Also gerade die großen Modelle ist natürlich schwierig, selber zu betreiben. Und irgendwann schicken wir halt so viel Daten durch die Gegend. 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.

Ja, also, was die Lösung ist, weiß ich nicht. 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.

Ich glaube, das ist unabhängig von der Größe. 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. Wenn ich bei uns die Pipelines anschaue, wie viele Änderungen bei uns reinkommen, jeden Tag,

Ja. Mhm.

dann brauche ich halt in den Pipelines ehrlicherweise etwas, was mir sagt, okay, hier ist jetzt etwas, das muss sich jemand anschauen. Hier gehen Tests kaputt oder hier schlägt eine von unseren Policies an oder, oder, oder. damit sich das jemand anschauen kann, weil sonst kommst du einfach nicht hinterher. 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. Und aus meiner Sicht müssen wir Lieferketten, Sicherheit Sicherheit zeitnah anders lösen in der Open-Source-Community. Ja, wir brauchen mehr Zuverlässigkeit und damit ja ganz offensichtlich auch Sicherheit für den Login und die Berechtigung, Releases zu machen.

herstellen?

Häufig ist es ja, dass Accounts einfach nicht gut abgesichert sind. So.

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.

Ja.

Ich habe einfach unterstellt, dass jeder Zwei-Faktor-Authentifizierung aktiv hat und in meiner kleinen, kleinen, kleinen Welt ist jeder verantwortungsbewusst. Alles andere wäre natürlich grob fahrlässig, aber auch das ist ja nicht unumgehbar.

Naja, und zum anderen, dann hast du halt wieder irgendeinen Long-Living-Token irgendwo rumfliegen. Und dann kommst du halt doch wieder rein in die Accounts, einfach über die CLI. Du musst ja nicht unbedingt über die Oberfläche in den Account und dich ganz normal einloggen. Das reicht ja, wenn du so einen GitHub-Token hast und dann da mit reingehst.

Ja, genau. All Access Token mit allen Zugriffsdaten.

Das ist ja der Punkt, wo ich auch immer wieder herkomme und sage, hey, schaut mal, wir müssen... 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. Einfach um das Risiko und die Möglichkeiten so weit einzuschränken, dass wenn die wegkommen, der Blaze-Radius, also der Schadens-Radius halt minimiert ist.

Mhm.

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. Und, ähm, ich will jetzt nicht sagen, ah, da ist jemand total unverantwortlich mit seiner Account-Sicherheit umgegangen oder so, ne? Also, gar keine Umstände will ich das jemandem unterstellen. Ähm, Aber... Das mit dem Versuchen möchte ich jetzt nicht sagen.

Wir sind einfach nur unbedeutend genug, dass es bei uns noch keiner versucht hat. Also, dass die Guten das nicht versucht haben, so rum. Hm.

Also meine E-Mails sagen was anderes. Ähm... Ähm... Ja. Sagen wir so, solange mein Yubi-Key hier reingesteckt ist, wird es schwierig. Ähm... 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. 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.

Ich muss sagen, mir ging jetzt zum Beispiel durch den Kopf, wäre ich von diesem Axios-Ding betroffen gewesen. 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.

Ja gut, aber du hast ja mehr als ein Projekt auf dem Rechner. Ja.

Genau, genau. Und dann fängt es schon an. 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? Also zum Glück, so bei den meisten Sachen, habe ich jetzt über Terraform mit AWS vieles geregelt. Da ist dann entweder eh automatisch wechselnde Credentials, zum Beispiel für die Datenbank oder solche Sachen mit drin, Langlebigere Sachen hätte ich jetzt auch tauschen können und dann mit einem Deploy austauschen können. 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... Zum Beispiel jetzt für Slack hatte ich irgendwann mal so ein Notifications eingerichtet. Da musst du dann wieder so ein Key… Also solche Sachen sind schwer zu tauschen oder nicht schwer aufwendig zu tauschen.

Ja, genau.

Es brauchen viel Zeit, es ist nicht schwer, aber es ist halt Fleißarbeit. Mhm.

Und was wir ja machen, ist zum Beispiel, wir führen MPM und PHP gar nicht mehr auf den lokalen Maschinen aus. Die sind da einfach nicht mehr installiert. Die sind nur im Container vorhanden. So. 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.

Das ist ein guter USP für eine Dev-Umgebung, ne?

Ja, genau.

Eine dockerisierte Dev-Umgebung, wenn du nicht gerade dein halbes Betriebssystem mountest mit deinem Home-Verzeichnis. Mhm.

Das ist ja so der nächste Punkt, was man eigentlich dann mountet. 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.

Hm. Hm. Da würde ich dich schön wegsperren.

Wenn der halt im Container rumwerkelt, dann weiß er ja auch gar nichts von der Außenwelt.

Also, was vielleicht nicht line-tauglich ist, aber unter Linux kannst du ja auch einen Change-Root machen. Also, dass du ein komplettes System umhängst und dann ist das auch wie ein Container.

Ja, genau.

Für ein OpenClaw oder so würde ich das echt empfehlen. Ist aber fricklich. Für... Hm.

Und mein Gedanke ist ja, wie machen wir es einfach, aber trotzdem sicher? 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. Und ich glaube, das ist auch eine ganz schlaue Idee. Aber wenn er dann irgendeinen Shit macht und installiert, dann war es halt ein Container und dann sind es im Zweifelsfall da Secrets verloren gegangen. Das ist auch schon wieder mystisch.

Also es ist einfach eine Extraschicht drumherum.

Aber... Ja.

Die ist auch nicht hundertprozentig bulletproof, aber besser als nichts. Mhm.

So, das Risiko ist halt geringer. 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... 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.

So tief war ich nicht drin.

Ja. Ja, gut. Ja. Ja, deshalb.

Also ich habe nur gelesen, dass der sich systemagnostisch bewegt hat. Also der wusste wohl auf welchem Linux, Windows oder Mac und dann passend installiert und agiert. Also schlecht war er wohl nicht.

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.

Mir gefällt die Docker-Variante sehr, weil die ist, ne?

Ja, ich meine auch im Docker.

Ach so, im Docker. Ja, du solltest den nicht als Root ausführen, so meinst du das. Also, ich... Hm?

Ja. Ja, nicht nur nicht als root. 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.

Hmm. Hmm.

Also gar nichts von dieser Existenz weiß. Aber ich habe noch nicht, also das habe ich mir noch nicht tief genug angeschaut, ob das musst. So, musst ja NPM-Pakete laden und ausführen, das ist auch immer so. Also, die mag ich ja am wenigsten, ne? Die PHP-Pakete, das ist auch geschenkt. 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.

Ja.

Jetzt ist halt die Frage, muss Cloud oder OpenCode oder whatever PHP ausführen können? 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.

Das bzw. es führt Python aus, um meistens über Sachen drüber zu grappen oder andere Sachen. Also das führt ja einiges aus und baut sich auch kleine Python-Skripte immer wieder, sieht man ja wieder.

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?

Ein paar Sachen baut und über Sachen iteriert, gerade wenn es so mit Excel-Dateien geht oder so.

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.

Mhm.

Ähm, 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. 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.

Ja, gerne.

So, dann sind meine Secrets sicher. Dann habe ich aber halt wieder PHP und so auf meiner Maschine drauf. Oder ich mache einen extra Container nur für Cloud, der neben dem anderen steht. Und ja, so. Ich finde, also wer da mal eine gute Idee hat, einfach mal erzählen. Mir fehlt die da bisher, dass ich sage, okay, das ist wirklich sicher. Zum einen, dass die Credentials nicht so leicht verloren gehen können. 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.

Was ich mich noch frage ist, also das ist ja alles auch so eine Vertrauenssache. Und irgendjemand muss ja diesen Comet gepusht haben. Und für mich ist es so, dass ich zum Beispiel, also bei mir das immer so einstelle, dass auch die Comets signiert sind. Jetzt frage ich mich, hm?

Ich grüße auf einen Fall. Bin ich großer Fan von?

Hm, jetzt frage ich mich gerade, also jetzt bei dem Axios-Fall, ähm, 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?

Das ist, finde ich, eine falsche Annahme.

Okay.

Wenn ich mir Open Source Projekte anschaue, ist das Signieren einfach kein Standard. Also ich bin auch vom Signieren und Attestieren von allen Artefakten großer Fan, also von den Commits, von Tags, von Releases, von so. Auch, dass die Pipeline nicht erwartet, das gebaut hat und dann mit dem richtigen Zertifikat und so weiter. Und dass wir das gegenprüfen, dass es auch tatsächlich quasi von uns kommt. Ja.

Habe ich anscheinend noch nicht oft genug gemacht. Also, ja.

aber das ist jetzt nicht so verbreitet. Also wenn du mal in ein beliebiges PHP-Projekt reinschaust, wie viele Commits sind da signiert? Ja, aber das ist halt einfach ein Standard, der nicht genutzt wird in der Form. Und ich gebe dir recht, dass wir zum Beispiel auch keine Commits annehmen, die nicht signiert sind.

Wäre der nächste konsequente Schritt, ja. Ja. Ja.

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.

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.

Ja, genau, du kannst auch dein SSHK hinterlegen.

Ja, ich bin komisch, was das betrifft anscheinend.

Aber ich meine, wenn du tatsächlich so richtig öffentlich prüfbar haben möchtest, müsstest du halt das ja irgendwo öffentlich ablegen. So, und und ich finde, das ist ein wunderbarer Standard, der viel zu selten genutzt wird.

Ich... 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.

Das ist auch ein Ding, was ich mir einfach wünschen würde, dass das passiert. Oder halt ein S-H-Key. Also ein Key.

Ja, das ist ja auch. Wir machen es da ganz besonders. Wir machen wieder ein Schleifchen dran. Also es geht natürlich auch weniger. 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. 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. 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.

Yep.

Es sei denn, die sind signiert. 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... komprimiert wird, weil du den vernünftig irgendwo gesichert hast, kann doch keiner neuen Code hinzufügen, ohne dass es irgendwie komisch wird. Und das ist etwas, was kannst du auch sehr leicht sicherstellen. Mhm.

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. So.

Okay, das müsste ich auf meiner Seite sicherstellen, dass ich das erwarte. Mhm.

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? Dass, du müsstest halt mehr oder weniger noch einen Pipeline-Schritt haben, der sagt, okay, ist das denn jetzt auch richtig signiert? So. Aber 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. Du musst im Prinzip ja dafür sorgen, bestmöglich dafür sorgen, dass halt niemand in deinen Account reinkommt.

Ich hab dich dazu gekriegt, was zu sagen, was dir nicht passt.

Und was immer sichergestellt ist, dass du das bist.

Ja. Ja.

Und ich finde, da signieren nochmal so ein i-Tüpfelchen. Ähm. Und bedeutet aber natürlich auch wieder, langlebige Credentials ist ja nichts anderes dann an der Stelle. Das Ding gehört dann vernünftig, das gehört dann halt auch wieder vernünftig irgendwo hingeschrieben, was nicht deine Festplatte ist. 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.

Nein, nein.

Wo du dann am besten nochmal drauf touchst, So, aber dann tatscht er ja auch irgendwann. Also, so. Ja, schwierig. Ich glaube, es gibt viele Wege, es gibt viele Möglichkeiten, Möglichkeiten, wie die Lieferkette insgesamt sicherer werden könnte. Nur wir beide werden das jetzt nicht alleine lösen.

Und wenn, dann werden wir lange beschäftigt. Ja. Ja. Ja.

Fürchte ich auch, Daniel, fürchte ich auch. 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. Wunderbar. Dann sehen wir uns nächste Woche wieder. Macht's gut.

Bis dann.

Tschö.

Tschüss.