Wenn ihr im Java Script Ökosystem unterwegs seid und
noch nichts gegen Chai Hulut unternommen habt, dann solltet
ihr jetzt alles stehen und liegen lassen.
Also ganz im Ernst, denn vor einigen Tagen ist ein
großflächiger Supply Chain Angriff auf NPM entdeckt worden.
Dabei wurde ein Wurm Virus namens Chai Hulut eingesetzt,
der innerhalb von kürzester Zeit über 500 populäre npm Pakete
infiziert hat. Die Malware stiehlt
Anmeldeinformationen zu Cloud Providern und Package Managern
und repliziert sich selbst in weitere Pakete, was du jetzt tun
musst und wie du dich langfristig vor zukünftigen
Bedrohungen schützt, darum geht's in dieser Folge.
Und damit herzlich willkommen zum to do Developer Podcast.
Folge 133 zum Thema Supply Chain Security Mein Name ist Malte
Lantin und ich bin Solutions Engineer bei github und den
Podcast mache ich seit langem gemeinsam mit Robin, Manuel und
Robin Manuel. Was ist bei dir der aktuelle
Stand? Ja, bis vor kurzem war ich noch
bei Microsoft. Ich bin aber gerade tatsächlich
arbeitslos. Ich habe mich entschieden, nach
10 Jahren Microsoft mal was Neues zu machen und ein bisschen
was anderes auszuprobieren. Ich gehe in die Einhornzucht, so
viel kann ich schon mal verraten, alle genauen Details
zähle ich dann hier, sobald es losgeht, also genau wohin es
mich verschlägt und was so mein nächster Schritt ist, das Teile
ich natürlich mit euch auch hier im Podcast.
Aber wie gesagt, erst wenn es dann offiziell losgeht, ich bin
gerade noch so zwischen zwischen 2 Abenteuern unterwegs, mache
jetzt auch noch mal ein bisschen Urlaub und guck das.
Genau gucke, dass ich einen Smoothie Übergang habe und wie
gesagt, habe mir so ein bisschen überlegt mal was anderes zu
machen, vor allem auch mal wieder ein bisschen was
kleineres zu machen und da werde ich bestimmt ganz viele coole
neue Erfahrungen sammeln, die dann bestimmt hier zu ganz
vielen neuen Themen und Folgen und so weiter beitragen, aber da
gibt es in Zukunft mehr. Es wird aber dabei bleiben,
natürlich, wir machen diesen Podcast hier weiter und machen
den auch weiterhin privat, teilen hier aber unsere
Erfahrungen quasi aus echten Kundenprojekten und diskutieren
aktuelle Themen, die die Developer Welt bewegen und.
Und das Thema, worüber wir heute sprechen, da kann man ganz schön
sagen, dass das die Developer Welt bewegt hat.
Shay Hulut ein quasi ein Wurm, der vor allem das Java Script
Ökosystem auf den Kopf gestellt hat.
Was ist denn da passiert? Ja, tatsächlich, vorletzte
Woche, da ist ein Beben durch die gesamte Softwareindustrie
gegangen, quasi durch das gesamte Developer eco System.
Da tatsächlich das Java Script Eco System und damit halt ein
ganz großer Teil der Open Source Community einmal durchgerüttelt
wurde durch den Chai Hulu Wurm, der sich.
Super schnell ausgebreitet hat, und das war so ein bisschen das
neue dabei. Wir hatten ja in der
Vergangenheit schon zahlreiche Supply Chain Angriffe auch im
Java Script Eco System, Wir hatten da auch in der
Vergangenheit schon folgen zu gemacht, wir haben über Cover js
gesprochen, wir haben aber über andere Angriffe gesprochen, wo
tatsächlich über viele Jahre mit sehr.
Ausgeklügelten Social Engineering Methoden, Zugriffe
auf bekannte Open Source Projekte erschlichen wurden.
Aber dieses Mal war es ein bisschen anders, weil es
wirklich ein Wurm war, der sich dort in.
Diesem Ökosystem extrem schnell ausgebreitet hat.
Das bedeutet, wir konnten nicht einfach irgendwie ein Paket, ein
Paket patchen, sondern mussten tatsächlich immer wieder
reinschauen, weil irgendwie stündlich neue dazu kamen, von
denen wir tatsächlich auch betroffen sein konnten, und das
war tatsächlich etwas sehr Neues.
Ja, vor allem muss man sagen, es ist nicht einfach nur yet
Another malwhere genau deswegen, sondern hat ja eigentlich so
eine fundamentale Schwachstelle in der Art und Weise, wie wir
generell Third Party Pakete managen, aufgedeckt und wir
rollen jetzt diese Folge immer so ein bisschen auf.
Was ist denn eigentlich passiert, wie schützen wir uns,
was wissen wir denn eigentlich als Developer jetzt machen also
wie gesagt, das war im Intro ernst gemeint, wenn ihr noch
nichts getan habt, hört noch kurz die Folge zu Ende, weil wir
da genau die ersten Schritte jetzt besprechen und dann?
Wir müssen alle aktiv werden und zumindest mal checken, ob wir
davon betroffen sind. Und deswegen würde ich jetzt
eigentlich mal sagen, wir gehen direkt rein und gucken mal, was
ist denn über, also wie konnte das denn überhaupt passieren,
was ist denn da, also wie konnte sich dieser Wurm so schnell
verbreiten und was macht er vor allem.
Ja, du hattest gerade gesagt, es ist ein Wurm und da haben wir
auch so ein bisschen so eine June Referenz mit chaihu Loot
und es waren wirklich in kürzester Zeit über 500 Pakete
infiziert und letzten Endes funktionierte so, dass ein
erstes Paket kompromittiert wurde und dort über letzten
Endes dieses Paket im Post Install Script etwas
nachinstalliert. Wurde der Post Install.
Genau das heißt, ich habe das nicht unter Kontrolle, was dann
am Ende dort auch von diesen Paketen nachinstalliert wird.
Und dann wird das tatsächlich mit sehr hohen Rechten dann auch
ausgeführt und nach der Installation dieses
kompromittierten Paketes wurde dann entsprechend diese Malware
auf meiner lokalen Maschine meiner Developer Maschine
installiert. Ja, Posten soll das läuft halt
automatisch nach der Installation und das Halt bei
Default. Da werden keine Fragen gestellt,
das wird einfach ausgeführt und da muss man sich ja schon
irgendwie fragen ob es ist jetzt auch nicht das erste Mal, dass
wir da irgendwie was sehen, scheinen sich Hacker scheint
sehr sehr beliebt zu sein bei Hackern dieser Step, ob wir uns
das überhaupt in Zukunft noch leisten können, dass es quasi
irgendwelche ein paar wenige Skript, die das ja eigentlich
erst mal nur verwenden, aber wie, das ist eben in npm
eingebacken, dass da natürlich dann einfach.
Software ausgeführt wird, die normalerweise ein bisschen zur
Konfiguration oder zur Kompilierung auf dem Zielsystem,
wenn es sich um verschiedene Zielsysteme wie Windows, Linux,
Mac OS oder sowas handelt. Dafür ist das eigentlich da.
Und ja, was da halt eben gemacht wurde ist, dass sofort dieser
Wurm losgegangen ist und nach der Installation der Pakete,
also nach der Infektion des Systems.
Das Teil die gesamte Maschine darauf gescannt hat, ob nicht
noch irgendwo Personal Access Tokens zum Beispiel für github,
API Keys für Cloud Zugänge zum Beispiel mit Azure, AWS oder
Google oder halt irgendwelche anderen schützenswerten
Schlüssel gelegen haben. Unter anderem ist das Open
Source Projekt Truffle Hock da wohl zum Einsatz gekommen.
Das ist eigentlich was, wo man seinen eigenen Rechner drauf
scannen kann, aber nicht noch irgendwelche Überbleibsel davon
hat und. Und das ist natürlich eigentlich
hochschützenswert, weil es dir eventuell wirklich auch Zugriff
auf die gesamte Firmeninfrastruktur gibt, auf
irgendwelche Cloud Accounts und und so hat er sich dann ja am
Ende auch verbreitet, hinzu Package registrys, die du
vielleicht entweder intern im Unternehmen verwendest oder, und
das war natürlich dann für den Woman einen Jackpot, wenn Du
selber Main tainer von einem Open Source depository bist, was
irgendwelche Packages auf npm hochlädt.
Ja, üblicherweise ist ja immer so die Guideline keine.
Secrets in den Repositories zu halten, aber natürlich außerhalb
der Repositories habe ich häufig irgendwelche Umgebungsdateien,
wo vielleicht irgendwelche Credentials drin liegen, die ich
während der Entwicklungsphase benötige und gegebenenfalls habe
ich wie gesagt auch irgendwelche Access Tokens, die mich
gegenüber package registrys authentifizieren.
Nicht immer mache ich das über die empfohlenen sicheren
Standards, dass ich dort mich entsprechend anmelde mit auch so
einer Phishing und. Resistant Authentication,
sondern ich habe vielleicht ein einfaches Token, mit dem ich
mich gegen diese Systeme authentifiziere und wie du
gerade gesagt hattest, wurde dort eine Open Source Software
über dieses Post install installiert, was dann nicht mein
Repository auf Secrets gescannt hat für mich, sondern
tatsächlich wurden dort auch über mein Repository hinaus
meine lokale Platte gescannt auf Secrets und diese Secrets wurden
dann exfiltriert da. Das heißt, die wurden dann
hochgeladen auf ein Repository auf github, welches die Hacker
in dem Fall angelegt hatten und in diesem Repository befanden
sich dann ganz viele gültige Secrets von diversen Developern,
die Halt über diese Malware gefischt wurden.
Also tatsächlich. Ist dieser Wurm eine Malware,
die jetzt auf der lokalen Maschine erstmal keinen Schaden
anrichtet, sondern letzten Endes nach Informationen sucht und
diese Informationen dann exfiltriert und die dann den
entsprechenden Urhebern dieses Wurms zur Verfügung stellt,
damit sie dann mit diesen Secrets letzten Endes zu der
tatsächlich schadhaften. Zum schadhaften Schritt
übergehen können, wo sie wirklich dir massiv schaden
können und natürlich dann auch ihren eigenen Wurm
weiterverbreiten können. Ja, genau, und zwar sie haben
sogar noch relativ schick gemacht.
Sie haben sogar gesagt, also ich lade hier diese Creentials in
dein Gitter repository, also nicht in deins, sondern dieses
Gitter repository hoch, was sie da angelegt haben und falls das
nicht funktionieren sollte, hier haben wir auch noch mal einen
Web Hook, also wir haben hier Web Hook site, slash irgendwas
verwendet, also wirklich auf mehreren Arten und weisen hat
dieser Wurm mal die Daten nach außen gepumpt und.
Und wie eben schon gesagt, Jackpot war es dann, wenn der
eben wirklich zugangstoken zu anderen Package Managern
gefunden hat, denn dann hat er sofort dort quasi sich die
neueste Version von diesem Paket runtergeladen, das einfach nur
um dieses Post install Skript ergänzt und wieder hochgeladen,
sodass er sich dann quasi selber direkt weiter verbreitet hat auf
alle anderen, die dann dieses Package benutzen.
Von dem Entainer, von dem der Wurm gerade die Zugangstoken für
npm und sowas abgegriffen hat und das sind so Dinge die.
Jetzt häufiger gesehen haben. Das betrifft ja auch nicht nur
npm. Also bei diesem, bei diesem Wurm
jetzt schon, aber Python hat gerade erst neue Warnungen
rausgegeben bezüglich Phishing Attacken, da hat auch jung, da
hat auch eine Organisation versucht, das ist so die der
Package Manager und die Package Registry von Python.
Zu Fischen und wie PJ. Org statt pi pi.
Org angelegt und wirklich dann versucht Mantainern irgendwelche
e Mails zuschicken, dass sie irgendwie aktiv werden müssen um
da credentials abzugreifen. Rust hat auf crades io gerade 2
Pakete gefunden, die zur Laufzeit auf deiner Maschine
nach Crypto Keys und Wallets suchen.
The Crades AO ist ein bisschen die ist die Package Library von
Rust und eigentlich geht es hier immer um das Gleiche.
Du lädst dir ein Paket runter, das führt dann irgendwelche
Software bei dir aus. Die versucht irgendwelche
Secrets zu klauen oder irgendwelche anderen Daten zu
gelangen und das kann ja in immense Auswirkungen haben, weil
du ja vielleicht diese Pakete nicht immer nur bei dir auf
deiner developer Maschine aufrufst, sondern auch zu
Laufzeit zu bildzeit auf irgendwelchen Servern zu Runtime
bei deinen Kunden dann wieder und so weiter das heißt,
eigentlich ist es ja katastrophal, wenn ich einem
Angreifer die Möglichkeit gebe, wirklich executable ausführbaren
Code mit in diese Pakete zu schippen.
Und gerade wenn du dann über diese Tokens dann umfangreiche
Rechte auf den einzelnen Plattformen und Systemen
bekommst, dann können natürlich auch wirklich massive Schäden
entstehen, wie zum Beispiel mit einem entsprechenden Personal
Access Token auf github und andere Plattformen können
einfach auch Repositories verschoben werden, das heißt,
dort wurden dann interne Unternehmensrepositories in den
privaten Bereich als Public Repository verschoben und damit
dann auch interne Unternehmensinformationen nach
draußen gegeben. Gegeben.
Du hast Situationen, wo tatsächlich dann auf deinen
Cloud subscriptions dann irgendwelche Services ausgeführt
werden. Ich meine das ist jetzt nichts
Neues, dieses Fishing nach Credentials von oder access
Tokens von solchen Hyperscalern wie Azure und Google findet ja
tagtäglich statt, ich glaube man kann.
Wenn man ein solches Secret in sein öffentliches Gitter
repository packt, dann kann man davon ausgehen, dass das
innerhalb von Minuten missbraucht wird und man dann
relativ schnell einen Krypto Miner in seiner Cloud
Subscription laufen hat und alle diese Dinge können natürlich
passieren, weil solche Secrets über einen einfachen String
extrem viele Rechte geben, in deinem Namen etwas in.
In einem Dienst oder Cloud Service zu machen, und das ist
natürlich eine massive Schwachstelle.
Es gibt mittlerweile, und da kommen wir gleich auch noch mal
im Detail drauf, viele Wege, wie man sich dort schützen kann,
aber in der Praxis ist es immer noch so, dass diese Access
Tokens und Secrets ganz häufig verwendet werden.
Ja, jetzt muss ich mir natürlich überlegen.
Klar kannst du jetzt sagen, auf meinem Developer Rechner sind
hoffentlich keine Access Tokens irgendwie für irgendwelche
Developer für irgendwelche Produktionssysteme drauf, aber.
Aber man muss ja auch ein bisschen weiterdenken.
Man checkt das dann irgendwie ein oder dieses geupdatete
Paket, das geht dann in die Cicd, das heißt, es wird zur
Bild Time auf den Bild Servern ausgeführt, da sind vielleicht
schon ganz andere Möglichkeiten auf eine Infrastruktur
zuzugreifen, dann wird es ja vielleicht entweder auf meinen
Server deployed und ist da auf einmal zur zur Runtime auf
einmal in meinem Kobolides Cluster und sowas und kann von
da aus vielleicht dann sogar mit meiner Datenbank sprechen und da
vielleicht sogar Sachen löschen oder sowas oder sich da aus den
Environment Variablen irgendwelche Secrets ziehen.
Im blödsten Fall habe ich vielleicht sogar eine
Webanwendung, die die das Paket dann auch noch an den Anwender,
also dann auf die Client Runtime ausspielt.
Das heißt, ich habe ja ganz ganz viele Umgebungen, wo diese
Skripte dann laufen und und scannen können, das heißt, es
ist ja nicht nur mein Developerrechter der und da
müssen wir uns, glaube ich alle mal ganz ehrlich an die Nase
fassen, wahrscheinlich auch ein bisschen zu viele Tokens und zu
viele Secrets hier und da irgendwie rumfliegen hat und.
Und deswegen müssen wir da und da werden wir jetzt gleich mal
drüber sprechen, quasi Maßnahmen treffen, dass sowas auch in
Zukunft nicht mehr passieren kann, weil das wird nicht das
letzte Mal gewesen sein, dass unser Rechner gescannt wird.
Wir müssen davon ausgehen, dass wir uns eventuell davor gar
nicht schützen können und deswegen eben Maßnahmen treffen,
dass eigentlich wir alle von alle Secrets und alle Tokens von
unseren Rechnern und im Idealfall auch aus allen CCD
Pipelines verbannen werden, das schauen wir uns gleich mal an.
Tatsächlich sind auch sofort Maßnahmen ergriffen worden und
nicht nur von den Developern, die diese schadhaften Pakete
einsetzen, sondern auch von Seiten von Gitter bzw npm, wo
sich diese Pakete verbreitet haben.
Und da wurden ganz viele Pakete gelöscht, die von diesem.
Wurm infiziert wurden und dementsprechend da auch
verhindert, dass man sich diese Pakete aus Versehen noch
nachinstalliert. Nachdem das Ganze schon bekannt
geworden ist. Das bedeutet, wenn du dieses.
Entsprechende Paket noch nicht auf der lokalen Maschine oder
auf Deinem Bird System hast, bist du zumindest im Rahmen der
bekannten Pakete aktuell sicher. Aber wenn die Pakete schon auf
der Maschine sind, muss man natürlich aufräumen und zudem
hat npm noch einige Schritte unternommen, die verhindern
sollen, dass so etwas noch einmal auftritt und dazu gehören
solche Dinge wie multifaktor Authentifizierung auf den
Publisher, Accounts oder auch kürzere Gültigkeiten.
Für die Tokens, fürs Package Publishing und natürlich
Empfehlungen, die an Package Publisher rausgegangen sind, wie
zum Beispiel keine weitere Verwendung von sogenannten
Legacy oder Classic Tokens, sondern nur noch moderne Tokens
mit entsprechenden Access Permissions zu verwenden, wo man
sehr genau entscheiden kann, welche Rechte ich auf diesen
Tokens habe. Das heißt, die Idee ist, dass
wir tatsächlich verhindern, dass wenn solche Tokens verloren
gehen, der Angriffsvektor mit diesen Tokens mit.
Möglichst reduziert wird. Genau das hat vor allem github
gesagt, dass sie diese Classic Tokens jetzt so schnell wie
möglich irgendwie depricaten werden und eine maximale
Gültigkeit von 7 Tagen für Tokens nur noch erlauben.
Die Packages. Publishen zusammen mit dieser 2
Faktor Authentifizierung und die Idee ist sogar langfristig, das
sogar noch deutlich kürzer zu machen.
Also eigentlich will ich, dass gestohlene Tokens sofort nutzlos
sind, weil sie entweder nur auf einer ganz bestimmten Maschine
verwendet werden können, wie zum Beispiel auf irgendwelchen cicd
Servern, die dann diese Pakete publishen, weil man auch so ein
bisschen gerade irgendwie einsieht, das was ich vorhin
schon mal gesagt habe, wir müssen uns, glaube ich damit
abfinden, dass wir uns nicht zu 100% sicher davor schützen
können, dass Tokens gestohlen werden und.
Und deswegen ist es so wichtig, dass wir eigentlich sagen, ey,
ich will, wenn wir Tokens verwenden, die gar nicht mehr
irgendwo gespeichert haben, die sollen idealerweise von der von
meinem Bildserver kurzzeitig auch nur generiert werden,
meistens noch in einem zweiten Faktor.
Daher kommen, also zumindest von einer bestimmten IP Adress Range
kommen oder auf einer bestimmten Hardware ausgeführt werden und
da hat sich jetzt geht aber auch direkt mit starkem machen
gesagt, wir sie würden, sie werden massiv noch mal das
Trusted Publishing fördern und da mehr Provider Onboarden
Trusted Publishing läuft so, dass.
Dass ich im Prinzip eine Vertrauensverbindung zwischen
der npm Packet Registry oder vielen anderen Registrys
herstellen kann und zwischen meinem zwischen in meinem bei
Gitterwald im Fall von meinen Gitter Actions runnern, die auch
teilweise von Gitter selber ja in der Cloud betrieben werden,
und dass ich mich dann quasi, dass ich nur diese Runner auch
nur aus diesem Repository überhaupt gegen.
Gegen diese Libraries eben auch identifizieren können, noch nur
in diesen einen Schritten von meinem Bildprozess und so weiter
also versuchen da jetzt noch mal noch noch mehr Augenmerk drauf
zu legen und die Provider, das fand ich eigentlich ganz cool,
haben sich da quasi direkt hingestellt und gesagt okay
jetzt reichts, wir müssen da noch mal noch mal 2 schippen
drauflegen, was das die ganze Security angeht und eigentlich
müssen wir die Verwendung von Tokens komplett verband,
zumindest von langlebigen Tokens und.
Und kurzfristige Tokens einsetzen, das zumindest so für
die Zukunft von Morgen, von morgen, wie wir das in Zukunft
verhindern können. Wir müssen aber jetzt sofort
tätig werden, also alle Developer, die jetzt hier
zuhören, die irgendwie ein Projekt haben, was in der Java
Script Welt unterwegs ist. Was npm verwendet es gibt ein
paar Sofortmaßnahmen, die wir quasi jetzt sofort machen
müssen. Und das Wichtigste ist zum
ersten Mal. Mal zu schauen, welche Tokens
sind gegebenenfalls dort gestohlen worden.
Das heißt, ich muss auf meiner lokalen Maschine schauen, welche
Tokens sind da und muss diese Tokens sofort rotieren, wenn ich
da keinen Überblick habe oder keinen Überblick bekommen kann,
weil ich vielleicht irgendwie ein Unternehmen bin und.
Keinen Zugriff auf die einzelnen Developer Maschinen habe, muss
ich als Vorsichtsmaßnahme einfach alle Tokens, alle
Credentials einmal rotieren um sicherzugehen, dass diese nicht
mehr missbraucht werden können. Das können Personal access
Tokens sein, das können Cloud API PS sein, das heißt ich
sollte sowohl meine Maschinen scannen als auch als
Vorsichtsmaßnahme diese Tokens entsprechend.
Rotieren. Ja, ich würde einfach ganz klar
sagen, dass ich davon ausgehen muss, dass ich betroffen bin.
Also im Worst case habe ich halt Tokens, irgendwelche Secrets
rotiert und war gar nicht betroffen, aber dieser Angriff
ist so groß, dass ich sagen würde, nimm an, dass du
betroffen bist. Rotier alle Personal access
Tokens, Secrets, npm Keys, Cloud API Keys, die du irgendwie
rausgegeben hast. Wenn du selber lieber noch mal
bist. Du kannst ja sogar einfach
dieses Truffle Hock Tool selber mal selber mal verwenden, das
ist nämlich auch genau das was dieser Virus verwendet hat.
Link dazu gibt es auch in der Beschreibung.
Da kann man selber seine Maschine mal danach durchsuchen,
ob man solche Keys hat, aber ich würde einfach ganz klar
empfehlen, geh mal davon aus, dass du betroffen bist in
irgendeiner Art und Weise. Und dann musst du natürlich
hingehen und deine npm Pakete auditen und musst schauen, gehst
du irgendwo auf immer die neueste Version?
Falls ja solltest du auf jeden Fall jetzt auf eine Version
gehen, die auf jeden Fall sicher ist.
Sogenanntes known safe Release, also alle Sachen die vor dem
Auftreten dieses Wurms veröffentlicht wurden sind.
Erstmal von diesem Wurf wahrscheinlich nicht betroffen.
Das heißt, wenn ich da auf diese Version runtergehe, dann bin ich
da erstmal auf der sicheren Seite.
Ich kann natürlich für die Zukunft andere Maßnahmen
ergreifen, aber das sind erstmal diese Sofortmaßnahmen, die ich
sofort umsetzen muss. Genau also alles, was vor dem 16
September 2025. Das ist so der Tag, wo das alles
angefangen hat, irgendwie aufzupoppen alles vorher erstmal
glaube ich als halbwegs safe zu deklarieren.
Zumal mittlerweile ja auch hier die ganzen großen Package libri
Provider genug Zeit hatten, diese Signatur von diesem Wurm
eben zu erkennen und die entsprechenden Packages zu
löschen. Ich sollte natürlich aber auch
gucken, dass ich einmal komplett meinen Node modules Ordner
lösche und meinen Cache mein npm Cache lösche, dass da quasi auf
keinen Fall mehr Pakete noch bei mir in der auf der lokalen
Maschine sind, auch die können ja vielleicht aus der Library
aus der NPM Registry entfernt worden sein, aber noch bei mir
auf der auf der Maschine sein. Ja, und dann gucke ich einfach
mal, ob ich betroffen bin. Es gibt von Jfrog eine Liste,
eine sehr, sehr lange Liste von Paketen, die scheinbar davon
betroffen waren, da findet ihr auch den Link in der Show Notes
und dann durchsucht ihr mal euren Euren S Bom, den habt ihr
ja spätestens seit Folge 103 von diesem Podcast hoffentlich alle.
Ansonsten kann man natürlich auch irgendwie in die Log
Dateien reingucken und mal schauen, welche Pakete
eigentlich da welche Projekte installieren und dann muss man
das abgleichen und gucken. Bin ich denn betroffen worden
oder ich mache es einfach, wie ich jetzt empfohlen habe, gesagt
habe ich gehe einfach mal davon aus, dass ich betroffen wurde
und muss dann natürlich auch entsprechende Paketversionen
aktualisieren. Und gerade wenn ich ein
Unternehmen bin, sollte ich auch mal in meine Firewall
reinschauen und mir irgendwie. Outbound Connections anschauen,
die irgendwie fishy aussehen. Du hast es ja gerade gesagt,
dieses webhook Dot Side oder irgendwelche Pushes auf Repos,
die ich nicht kenne, weil das sind durchaus ganz klare
Indikatoren, dass dieser Wurm in meinem Netzwerk aktiv war und
gegebenenfalls Secrets nach außen publiziert hat und ich
dementsprechend mit einer noch schnelleren Geschwindigkeit
vorgehen muss, um halt diese Vorsichtsmaßnahmen zu ergreifen.
Ja, und langfristig müssen wir uns natürlich Strategien
überlegen, wie wir sowas in Zukunft nicht mehr machen.
Und eine Sache, die glaube ich ganz klar ist, ist, wir können
es uns eigentlich nicht mehr leisten, keine genauen Versionen
von irgendwelchen Paketen zu pin, ich weiß, es ist irgendwie
angenehm zu sagen, ja, gib mir mal ungefähr die Version XY, was
auch immer, solange das kein neuer Major Release oder keine
neue Features ist, wird das schon irgendwie passen.
Es ist angenehm, aber genauso konnte sich dieser Wurm eben
schnell verbreiten. Dass ich eine ungefähre Version
in meinen Packages angelegt habe, bedeutet konkret, ich will
eigentlich keine Tilde und keine Carrits, also diese spitze
klammern nach oben, dieses Dach mehr in den in den Package json
Dateien sehen, ich sollte wenn ich das natürlich eh noch nicht
mache, aber die Empfehlung ist natürlich immer log Files mit zu
committen also einen Package log json in Jahren Punkt Login Bann
Punkt Login Uv Punkt log. Pn pm log log Punkt Yamel all
diese ganzen Log Dateien, die gehören mit eingecheckt weil ich
damit sicherstellen kann, dass zumindest erstmal schon mal alle
die bei locker auf dem gleichen Dependency Tree arbeiten und wir
können wie gesagt uns eigentlich nicht mehr leisten ungefähre
Version zu verwenden, weil dann eben es kommt eine neue
Kompromittierte Package Version, die kann ja vielleicht sogar
wenige Stunden später schon wieder entdeckt und gefixt
worden sein, aber wenn ich in diesen Stunden einfach ein Bild
gemacht habe und die Version ungefähr gepasst hat.
Dann kann es eben passieren, dass der sogar auf meinem
Bildserver mit runtergeladen wird und deswegen werde ich dazu
übergehen und keine Tilde und keine Carrits mehr verwenden,
sondern Versionen ganz klar mit ihrer kompletten Versionsnummer
zu pin. Ja, und tatsächlich gilt das ja
für alle Package Eco Systeme oder für immer.
Wenn ich die Pencs habe. Das gilt jetzt nicht nur für NPM
und Java Script Pakete, sondern das sollte ich tatsächlich immer
berücksichtigen. Wir hatten in der Vergangenheit
ja auch schon mal über solche Dinge wie github actions
gesprochen, wo ich verschiedene. Versionen habe von meinen
Actions die ich verwende und auch hier sollte ich die Commits
entsprechend pin um sicherzugehen, dass ich das
bekomme, was ich als sicher erachte und geprüft habe und
tatsächlich bei den Paketen und bei den Registrys gehen einige
Unternehmen und das kann. Kann man ja mal darüber
nachdenken, ob man das auch machen möchte, weil man
vielleicht sicherheitskritische Software entwickelt, gehen
einige Unternehmen so weit, dass sie tatsächlich auch Kopien der
Pakete als sicher klassifizierte Kopien der Pakete in eigene
Registrys legen, die sie lokal betreiben oder tatsächlich von
ganz wichtigen Depenses, vielleicht auch Forks anlegen,
die sie selber pflegen. Das ist jetzt wirklich die.
Extra sicher Variante, weil ich da natürlich sicher gehen kann,
dass ich alles unter Kontrolle habe und ich kann auch sicher
gehen, dass nicht einzelne Developer vielleicht mal von
diesen Best practices, die du gerade besprochen hast,
abweichen, sondern ich kann tatsächlich vorgeben, dass nur
mein eigener Package Stream verwendet wird in meinem
Unternehmen und alles andere blocke ich gegen die Firewall
durch die Firewall und dementsprechend kann ich ganz
genau kontrollieren, welche Versionen von welchem Paket
überhaupt in meinem Unternehmen vor.
Verfügbar sind und verwendet werden können.
Und immer wenn ich diesen eigenen Package Stream habe, der
nicht automatisch von npm die Pakete immer nachlädt und
dementsprechend alles auch inklusive Malware vorhält, dann
kann ich natürlich sehr gut kontrollieren, was letzten Endes
an Dependencies nachgeladen wird, aber da ist natürlich
etwas, was für kleine Unternehmen oder individuelle
Entwickler meistens Overkill ist.
Und deswegen sind ja diese großen Package Manager so
beliebt, weil es damit so einfach ist, auf dieses riesige
eco System. Themen von Open Source
Komponenten zurückzugreifen und es gibt einige Unternehmen, die
gehen so weit und sagen, ich verzichte auf dieses Verhalten,
was ich gerade in der Java Script Community ganz oft sehe,
dass ich für jeden. Für jede Zeile Code, die ich
sparen kann, ziehe ich lieber eine Dependency rein.
Da gehen Sie tatsächlich hin und sagen okay, dann schreibe ich
vielleicht mal lieber irgendwie 20 Zeilen Codes selber als yet
another dependency in mein Projekt reinzuholen, aber das
muss man sich natürlich überlegen, das ist so ein
bisschen so eine Abwägungssache, auch zwischen Komfort und
zusätzlichem Aufwand und natürlich dem Thema Sicherheit.
Ja, was du gerade als zweites gesagt hast, halte ich für
deutlich realistischer. Ehrlich gesagt.
Also ja, ich weiß, dass es Unternehmen gibt, die wenn die
auf super Safe spielen und alle Packages lokal speichern und
sogar eigene Forks machen. Ich glaube also da leidet
natürlich auch sehr die Developer Experience drunter,
ich glaube das ist schon ein Thema, wo wir uns irgendwie alle
irgendwie auch gemeinsam irgendwie dran arbeiten müssen,
also ich glaube die ist so eine Version pin okay aber
wahrscheinlich wenn ich in so einer Hochsicherheitsumgebung
arbeite, dann muss ich das schon so machen, dass ich da meine
eigenen Packages habe, aber sonst?
Ich glaube, ich würde eher sagen, was du gerade als zweites
gesagt hast. Mal irgendwie überlegen.
Brauche ich wirklich einen Axios für meinen simplen http request
oder reicht da vielleicht auch mittlerweile die in Node js
eingebaute Fetch Library, die mittlerweile sogar ziemlich gut
ist? Oder reicht vielleicht auch der
der eingebaute Node js testrunner für meine Sachen
brauche ich also das, was du gerade als zweites vielleicht
sollte ich aufhören diese kleinen Helper Library zu
verhindern und so ein bisschen vielleicht meinen Angriffsvektor
auch mal zu verkleinern und. Und ja, so ein bisschen besser
zu kontrollieren, was habe ich denn eigentlich für
Dependencies, vor allem so transitive Dependencies, also
das sind die Dependencies von meinen Dependencies, weil die
sind ja noch viel, viel schwieriger zu kontrollieren, da
hole ich mir oft auch wirklich Mist irgendwie mit rein, den ich
nicht kontrollieren kann, da gibt es auch 23 Arten und
weisen, wie ich damit umgehen kann.
Es gibt in npm zum Beispiel sogenannte over Rights, da kann
ich eine bestimmte Version von einer Dependency von meiner
dependency enforcen. Das heißt, nehmen wir eigentlich
installiert, ist irgendwie ein kleines Tool und das nutzt der
Klassiker irgendwie. Low Dash und Label, dann Low
Dash in einer bestimmten Version nachladen, die ich gar nicht
kontrollieren kann, da kann ich, das kann ich entforcen, da kann
ich zum Beispiel bei npm sagen, Nee, Low Dash wird immer, immer,
immer in dieser Version, die ich hier definiert habe,
nachgeladen, das kann natürlich auch schief gehen, weil das
Projekt dann vielleicht trotzdem genau diese eine Version
braucht, aber da gibt es auch so ein bisschen Mittel und Wege
von, aber gerade diese transitiven Dependencies, die
sind natürlich ja oft schwieriger einzufangen und.
Und das zweite, was natürlich ultra schwierig anzufangen sind,
sind diese Post Install Skripte, durch die sich jetzt auch wieder
dieser Wurm verbreitet hat. Also da würde ich sagen,
langfristig können wir auch mal drüber nachdenken, ob wir die
nicht mal deaktivieren. In npm kann ich das sagen, da
gibt es einen npm config, da kann ich einfach sagen Agnor
Scripts ist gleich true und das ist erstmal mein Default und
wenn dann so ein npm Paket dann wirklich so ein Post Install
Skript ausführen will, dann kriegt er halt einen Fehler und
dann kann ich ja immer noch mal hingehen und mir ganz genaue
Gedanken machen ob ich das nicht vielleicht für dieses eine Paket
erlaube, weil das da vielleicht sinnvoll ist und.
Oder ich mich selber vielleicht noch mal aktiv werden muss nach
der Installation. Aber eigentlich ist das so ein
Convenience Feature was wir uns glaube ich nicht mehr leisten
können. Aber was ich auf jeden Fall
machen kann, ist zumindest auch Updates bewusst zu verzögern.
So ein bisschen Zeit als Puffer reinzunehmen, weil was wir
wirklich in den letzten Supply Chain Security Attacks gelernt
haben ist, dass solche Dinge relativ schnell gefunden werden.
Das bedeutet, immer wenn ich dann sage okay ich installiere.
Verliere eine neue Version von einem Paket.
Er ist nach 2448 Stunden oder noch länger, dann bin ich ganz
häufig auch schon auf der sicheren Seite, weil bevor ich
dann dieses Update installiere, ist eine entsprechende
Verwundbarkeit auch schon bekannt und dann können
natürlich auch Tools wie Depender Board mich entsprechend
davor warnen die Dependency zu aktualisieren.
Das Ganze kann ich in npm setzen über dieses Minimum Release age.
Und damit kann ich dann festlegen, dass bestimmte Pakete
einfach nicht installiert werden, wenn sie halt in einem
kürzeren Zeitrahmen veröffentlicht wurden und kann
damit schon vielleicht in Kombination mit dem, was du
gerade gesagt hattest, mit reduziertem Angriffsvektor, in
dem ich einfach die Anzahl der Bibliotheken, die ich nutze,
reduziere, kann ich schon ganz viel verhindern.
Ja, auf jeden Fall find ich n sehr guten Tipp.
Wie gesagt, PNPM kann das schon irgendwie eingebaut mit diesem
Minimum Release Age auch noch mal.
Ich weiß nicht ob es alle schon machen, aber wenn ich zum
Beispiel in meiner CICD Pakete nachinstalliere bei bei NPM.
Oder bzw nicht Paket danach installiere, sondern einfach
irgendwie sage ich mache einen npm install.
Nee mache ich nicht, ich nehme bitte kein npm install in meiner
cicd ich nehme npmci das steht nicht für Continuous
Integration, sondern das steht für Clean Install oder wenn ich
irgendwie Ban benutze, kann ich auch Ban install Frozen Logfile
eingeben und das nutze ich statt npm install und das garantiert
mir, dass die Gelockten package Versionen auch 1 zu 1 so.
Verwendet werden und es versucht dann eben keine Ranges
aufzulösen. Falls ich die oder meine
Transitiven Dependences, die die sogar noch irgendwo haben, gibt
mir also eine noch höhere Reproduzierbarkeit, dass genau
das, was auch im Logfile steht, installiert wird und das will
ich eigentlich auch haben, dass ich nicht irgendwie sage okay
ich habe bei mir in einer Umgebung einen Scan gemacht, da
ist alles safe und in der anderen Umgebung wird eine
leicht andere Version von dem Paket dann doch irgendwie
installiert und. Weil ich über npm in Stall
mache. Ich weiß, wahrscheinlich hätte
das vor ein paar Wochen alles noch sehr paranoid geklungen,
aber jetzt zeigt tatsächlich hier dieser Wurm, wie relevant
das eigentlich ist und dass wir uns zukünftig noch mehr Gedanken
machen müssen, über wie wir unsere Umgebungen schützen und
natürlich auch, wie wir uns von diesen leidigen Tokens, die
natürlich immer wieder das Thema sind, verabschieden, und da
müssen wir einfach gucken, dass wir da die Maintainer in Zukunft
in die Pflicht nehmen oder beziehungsweise die Plattformen,
die Maintainer in Zukunft in die in die Pflicht nehmen und.
Und einfach sagen, es darf eigentlich gar kein Token mehr
irgendwo rumfliegen auf meinem Rechner, der mir so einen großen
Zugriff gibt, dass da jemand Fremdes quasi ein Update von
einem Paket, was von 100 Tausenden Leuten verwendet wird,
hochladen kann, oder dass überhaupt ich irgendwie von
meinem Rechner aus in Token oder liegen kann, der dann jemand
anderen von einem anderen Rechner aus nur mit diesem Token
Zugriff auf meine Cloud Umgebung oder auf irgendwelche
schützenswerten Sachen gibt. Ja, wir hatten es gerade schon
gesagt, was da so die Best practices sind, betrifft
wahrscheinlich nicht so viele von euch, die eigene Packages
veröffentlichen, aber da ganz wichtig nur feingranulare,
kurzlebige Tokens verwenden, wenn.
Nichts anderes möglich ist für den eigenen Account auch
multifaktor Authentifizierung, auch Phishing Resistant
multifaktor Authentifizierung verwenden über zum Beispiel
Paskeys oder andere sichere Systeme und damit kann ich dann
natürlich auch als Maintainer und Publisher von solchen
Paketen zur gesamten Sicherheit des Ökosystems beitragen, weil
wir haben in der Vergangenheit gesehen irgendwie am Ende sind
wir alle Menschen und auch für solche Phishing und Social
Engineering Attacken irgendwo anfällig und.
Und sobald dann jemand die Kontrolle über meine Credentials
erlangt hat diese Person gegebenenfalls die Möglichkeit,
extrem großen Schaden anzurichten und wir haben es ja
jetzt in diesem Wurm gesehen. Man musste am Anfang nur ein
Paket infizieren und hat sich dann entsprechend exponentiell
verbreitet und innerhalb von wirklich sehr kurzer Zeit waren
Hunderte von Projekte betroffen, weil halt alle diese Mantainer
bestimmte Sicherheitsvorkehrungen leider
nicht beachtet haben oder beachten konnten und.
Ja, weil sie die eben auch nicht Pflicht sind.
Und ich finde, das müssen wir jetzt viel mehr irgendwie
machen. Das, das werde ich auch in den
in den Teams, in denen ich arbeite, jetzt versuchen
durchzusetzen, dass wir das als Standard machen.
Ich will gar keine Tokens mehr sehen, gar keine Secrets mehr
sehen, nirgendwo, es hat sich mit einer Identity
authentifiziert zu werden gegenüber allem gegenüber meinem
Git repository, aber auch innerhalb von meinem Git
repository sollen meine, meine, meine cicd Pipelines keine
Secrets mehr haben, mit denen sich gegen meine Cloud Umgebung
oder in mein koboniertes Cluster einloggen, die haben.
Auch eine Identity zu bekommen, das geht mittlerweile über
Trusted Publishing bei vielen Providern.
Da habe ich eben schon gesagt, gibt es eine Trust Relationship
zwischen dem Runner, der meine cicd Pipeline ausführt und npm
oder meinem Cloud Provider und so weiter das läuft über Oidc,
also ein Teil von O aus. Und da wird dann einfach
geguckt, dass die eine Identity bekommen und nur die dürfen dann
auch zugreifen. Da kann ich auch ganz klar
sagen, was haben die für Zugriffsrechte, das Gleiche hat
für alle Deployments und sowas zu passieren.
Also ich will eigentlich selbst gegen eine dev Umgebung auf
meinem Rechner nicht ein einziges Secret, nicht einen
einzigen API und nicht einen einzigen Token mehr sehen.
Ja, ich meine, das hört sich jetzt so einfach an, aber häufig
ist es natürlich so, dass wir auch im Alltag dann vielleicht
den einfachsten Weg gehen, weil wir irgendwie in diesem.
In diesem Spannungsfeld zwischen Produktivität und wir müssen wie
schnell Ergebnisse liefern und dem Thema Security sind, das
heißt, Wir haben auch teilweise so ein bisschen so eine Security
Fatigue und ich meine, man kennt es ja auch aus dem privaten
Umfeld und von sich selber, wenn man jetzt tatsächlich von immer
mehr online Plattformen aufgefordert wird, multifaktor
Authentifizierung einzurichten und dann fragt man sich ja,
warum brauche ich das denn jetzt auf meinem github Account und
dann merkt man tatsächlich okay wenn ich das nicht habe, kann
vielleicht jemand relativ. Schnell über einen einfachen
Token die volle Kontrolle über meinen Account übernehmen, weil
ich dort keine multifaktor Authentifizierung hinterlegt
habe und von daher ist es, glaube ich ganz wichtig, dass
wir da auch alle sagen okay, wir müssen Security da ein bisschen
stärker priorisieren. Ja, und aber auch noch mal.
Das sind natürlich auch 2 verschiedene Dinge.
Ich kann ja durchaus 2 Faktor Authentifizierung auf meinem
Gitter Account haben und wir trotzdem so einen langlebigen
Token erstellen, mit dem ich dann irgendwelche Sachen machen
kann und ich glaube das müssen wir halt vor allem auch noch mal
deaktivieren und irgendwie sagen, es für bestimmte Dinge,
das Macht der Gitter manchmal schon für bestimmte Aktionen auf
der Gitter Plattform fordert es mich dann noch mal auf.
Hey kannst du dafür vielleicht noch mal kurz deinen zweiten
Faktor rausholen und ja. Trotzdem kann ich ja irgendwie
so einen langlebigen Token erstellen, der niemals abläuft
oder irgendwie erst in 2 Jahren abläuft und sowas, aber ich kann
das schon verstehen irgendwie, wir müssen, ich glaube wir
müssen da dann nicht nur so ein Verständnis für schaffen, wie
wir das jetzt mit dieser Podcast Folge versuchen, sondern es muss
auch irgendwie einfacher und convenient sein und da müssen
die Plattformen eben ran, dass es eben ganz einfach ist, dass
man sich da ohne API Key, sondern einfach durch durch den
Login Mechanismus anmelden kann, dass eben diese Tokens auch
quasi nur eine bestimmte Laufzeit bekommen und dass es
mir ein bisschen schwieriger gemacht wird.
Da so einen Token zu kriegen, der so viel darf und dass ich
eigentlich das ist, und das hat der github so ein bisschen
gesagt, dass sie da jetzt noch mal ein extra Augenmerk drauf
legen, dass ich eigentlich über diese diese Trusted Publishing
approaches und so was gehe und in der Cloud mit einer Identität
arbeite, und wir müssen uns natürlich auch Gedanken drüber
machen, wie wir Maintainer von Open Source Projekten, die ja
ganz, ganz viel einfach in ihrer Freizeit und teilweise unbezahlt
oder nur ganz ganz niedrig bezahlt.
Irgendwie so Ultra große Projekte mit ja mit 100
Tausenden von von Downloads, wie wir die vielleicht besser
unterstützen, das hatten wir ja schon mal gesagt, wir haben ja
schon mal eine Folge zu XC utils gemacht, da ging es ja auch so
um dieses dieses Stichwort, irgendwie maintainer Burnout, da
wurde ja auch mit so viel Social Engineering und Druck gearbeitet
auf diesen armen Kleinen, einen Maintainer, der so ein riesen
Linux Paket was ultra wichtig in fast allen Distributionen drin
war Maintaint hat und ich glaube wir müssen uns hier wieder
einmal die Frage stellen. Ob unser Ökosystem nicht
irgendwo systematische Fehler eingebaut hat, die es einfach
sehr anfällig für solche Probleme machen.
Ja, es gibt ja diesen Cartoon, den kennen wahrscheinlich viele
von euch, wo tatsächlich dieses riesige Gerüst von komplexer
Anwendung auf den Schultern von einem kleinen Retainer.
Der eine kleine Komponente im Entaint liegt.
Und tatsächlich ist es ja in der Realität so, wenn man sich
gerade so ein bisschen diesen Dependency Tree anschaut von
vielen der npm Pakete gibt es bestimmte Pakete, die immer.
Und immer wieder als Dependency auftauchen.
Und die sind natürlich der größtmögliche Angriffsvektor,
auch um solche Supply Chain Attacken durchzuführen.
Und da ist es natürlich wichtig zu schauen, okay können wir auch
diesen Maintainern von diesen kritischen Projekten helfen, da
gibt es verschiedene Möglichkeiten, es gibt halt
irgendwie ein Sponsoring, was man vielleicht für ein Gitter
propository für ein Projekt machen kann, man kann natürlich
auch selber sich einbringen, wenn man die Zeit und die
Kompetenzen hat. Aber ich glaube, es ist ganz
wichtig, dass man da auch ein gewisses Bewusstsein für
entwickelt, wie groß auch am Ende die Last auf teilweise
einzelnen liegt, weil man denkt, so immer.
Irgendwie so ein Open Source Projekt.
Da arbeiten immer ganz viele dran.
Aber selbst wenn irgendwie ganz viele Ideen beisteuern, häufig
sind es irgendwie ein 2 Leute, die dann alle diese PRS reviewen
die ganzen Ideen durchgehen müssen und auf denen dann
letzten Endes auch die Last liegt, irgendwie ein stabiles
Produkt bereitzustellen und genau diese Leute brauchen die
Unterstützung, damit halt auch keine menschlichen Fehler
passieren, weil die Leute halt einfach überlastet sind, weil
sie vielleicht auch noch einen Dayjob haben und dann irgendwie
abends noch. Dann die ganzen PRS Reviews,
müssen die halt irgendwelche Leute in ihrem Projekt gestellt
haben und da rutscht dann auch mal schnell was durch.
Okay Fazit Was heißt das denn jetzt?
Wir haben gesagt, ganz klar, 3 konkrete Handlungsempfehlungen,
das eine sofort past Keys 2 Faktor Authentifizierung, also
Fishing secur 2 Faktor Authentifizierung, also nicht
diesen komischen sechsstelligen Zahlencode, den kann man nämlich
fischen, sondern wirklich sowas wie Web own oder past Keys
aktivieren das. Zweitens npmci anstatt npm
install in euren cicd Pipelines verwenden und eigentlich mal
drüber nachdenken, ob man nicht dieses Signor Scripts einführt
und wahrscheinlich am allerwichtigsten versucht
irgendwelche Tokens zu verbannen.
Wir haben es jetzt 100 mal schon gesagt, Trusted Publishing ist
hier das Stichwort, gibt das Mal ein Trusted Publishing plus der
Name von eurer Cicd Plattform und das Mal einführen und
übernehmen. Und.
Und wir haben auch gelernt, dass Sicherheit eine gemeinsame
Verantwortung ist, also sowohl von denen, die diese Plattform
wie NPM anbieten, als auch den Maintainern, die die Pakete dort
veröffentlichen und von uns als Development, die das Ganze
einsetzen. Und nur wenn hier alle Ihre
Aufgabe erledigen, können wir das Ökosystem sicherer machen
und wir haben gesehen, ganz viele arbeiten da jetzt dran,
wir haben auch einige Links in den Shownotes, wo ihr einfach
noch mal reingehen könnt und schauen könnt, was ihr in eurer
Rolle jetzt macht. Machen könnt und was ihr machen
solltet, um halt euren Beitrag zu leisten.
Und noch mal als Abschlussappell alles rotieren.
Wir gehen jetzt einfach mal alle davon aus, dass wir davon
betroffen sind. Es ist auch kein
Wahnsinnsaufwand, mal ein paar Tokens und Secrets zu rotieren,
kann man sich immer daran gewöhnen das ab und zu zu
machen, wachsam bleiben, mal alle Abhängigkeiten prüfen, wie
gesagt, es gibt eine lange Liste von Jfrog, die ist unten in den
Shownotes. Und bitte, bitte, bitte nochmal
der Pell Sicherheit als ganz festen Bestandteil von so einem
Development Prozess begreifen. Ich glaube es hat uns wieder
einmal gezeigt, dass jeder einzelne Developer, jede
einzelne Entwicklerin, jeder einzelne Entwickler betroffen
sein kann, dem man sich einfach so ein Paket auch nur zu der
Laufzeit reinholt und dann vielleicht einen ganz woanders
gespeicherten Token liegt und ist natürlich jetzt irgendwie
eine schwere ernste Folge, wenig Spaß, wenig Gelächter, wenig
Gelächter diese Podcast Folge, aber ich glaube ein ganz
wichtiges Thema und. Wie gesagt, eigentlich hätte man
sich schon vor 2 Wochen wahrscheinlich damit befassen
und darum kümmern müssen, wenn ich es noch nicht getan habe.
Ganz, ganz, ganz, ganz dringend machen und dann geht es auch
wieder weiter und ich glaube da kann man auch mit einem guten
Gewissen, wenn man die ganzen Sachen umgesetzt hat,
weitermachen und denken Ach guck mal, fühlt sich doch auch
irgendwie besser an zu wissen, ich habe hier keine Talkings
rumfliegen, mein Code ist sicher, mein Projekt ist sicher
aufgesetzt. Und von daher hoffen wir auch,
dass euch die Folge weiter gebracht hat, dass ihr ein
bisschen besseres Verständnis für diesen Wurm entwickelt habt,
dass ihr ein bisschen hinter die Kulissen schauen konntet,
gemeinsam mit uns und wenn euch die Folge gefallen hat, dann
lasst uns bitte eine positive Bewertung da auf Spotify oder
Apple Podcast. Wir freuen uns immer sehr und es
hilft natürlich auch, dass der Podcast von anderen gefunden
wird und. Wir freuen uns natürlich auch
sehr, wenn ihr Lust habt, uns einen Kaffee auszugeben.
Da findet ihr einen Link zu bei mir Coffee unten in den
Shownotes zusammen mit allen anderen Links, die wir da für
Euch zusammengetragen haben. Oder wenn ihr sogar vielleicht
zu eurem eigenen Kaffee die Podcast Gebrandete Nerd Tasse
haben wollt. Wir haben einen kleinen Fanshop,
da könnt ihr natürlich auch mal vorbeigucken, links zu allem
gibt es in der Beschreibung und ansonsten gibt es nächsten
Montag eine neue Podcast Folge, denn der To do Cast der
erscheint jede Woche, jeden Montag immer abwechselnd in
einer Themenfolge wie dieser hier oder einer News folge, wo
wir so ein bisschen die News der letzten 2 Wochen zusammentragen.
Hört also auch nächste Woche wieder rein.
Bis dahin, schreibt viel Code, schreibt vor allem sicheren Code
und konfiguriert euer Codeprojekt sicher und bis
nächste Woche. Bis bald.