1 00:00:00,160 --> 00:00:03,440 Wenn ihr im Java Script Ökosystem unterwegs seid und 2 00:00:03,440 --> 00:00:06,320 noch nichts gegen Chai Hulut unternommen habt, dann solltet 3 00:00:06,320 --> 00:00:08,000 ihr jetzt alles stehen und liegen lassen. 4 00:00:08,160 --> 00:00:11,120 Also ganz im Ernst, denn vor einigen Tagen ist ein 5 00:00:11,120 --> 00:00:15,040 großflächiger Supply Chain Angriff auf NPM entdeckt worden. 6 00:00:15,360 --> 00:00:18,520 Dabei wurde ein Wurm Virus namens Chai Hulut eingesetzt, 7 00:00:18,520 --> 00:00:23,160 der innerhalb von kürzester Zeit über 500 populäre npm Pakete 8 00:00:23,160 --> 00:00:24,880 infiziert hat. Die Malware stiehlt 9 00:00:24,880 --> 00:00:28,560 Anmeldeinformationen zu Cloud Providern und Package Managern 10 00:00:28,720 --> 00:00:32,800 und repliziert sich selbst in weitere Pakete, was du jetzt tun 11 00:00:32,800 --> 00:00:35,160 musst und wie du dich langfristig vor zukünftigen 12 00:00:35,160 --> 00:00:37,520 Bedrohungen schützt, darum geht's in dieser Folge. 13 00:00:43,200 --> 00:00:47,200 Und damit herzlich willkommen zum to do Developer Podcast. 14 00:00:47,200 --> 00:00:54,160 Folge 133 zum Thema Supply Chain Security Mein Name ist Malte 15 00:00:54,160 --> 00:00:58,120 Lantin und ich bin Solutions Engineer bei github und den 16 00:00:58,120 --> 00:01:01,600 Podcast mache ich seit langem gemeinsam mit Robin, Manuel und 17 00:01:01,600 --> 00:01:04,280 Robin Manuel. Was ist bei dir der aktuelle 18 00:01:04,280 --> 00:01:07,440 Stand? Ja, bis vor kurzem war ich noch 19 00:01:07,440 --> 00:01:09,760 bei Microsoft. Ich bin aber gerade tatsächlich 20 00:01:09,760 --> 00:01:12,080 arbeitslos. Ich habe mich entschieden, nach 21 00:01:12,080 --> 00:01:15,640 10 Jahren Microsoft mal was Neues zu machen und ein bisschen 22 00:01:15,640 --> 00:01:19,200 was anderes auszuprobieren. Ich gehe in die Einhornzucht, so 23 00:01:19,200 --> 00:01:21,280 viel kann ich schon mal verraten, alle genauen Details 24 00:01:21,280 --> 00:01:24,080 zähle ich dann hier, sobald es losgeht, also genau wohin es 25 00:01:24,080 --> 00:01:26,960 mich verschlägt und was so mein nächster Schritt ist, das Teile 26 00:01:26,960 --> 00:01:28,880 ich natürlich mit euch auch hier im Podcast. 27 00:01:29,440 --> 00:01:31,600 Aber wie gesagt, erst wenn es dann offiziell losgeht, ich bin 28 00:01:31,600 --> 00:01:34,080 gerade noch so zwischen zwischen 2 Abenteuern unterwegs, mache 29 00:01:34,080 --> 00:01:36,480 jetzt auch noch mal ein bisschen Urlaub und guck das. 30 00:01:37,200 --> 00:01:39,440 Genau gucke, dass ich einen Smoothie Übergang habe und wie 31 00:01:39,440 --> 00:01:41,840 gesagt, habe mir so ein bisschen überlegt mal was anderes zu 32 00:01:41,840 --> 00:01:43,200 machen, vor allem auch mal wieder ein bisschen was 33 00:01:43,200 --> 00:01:47,120 kleineres zu machen und da werde ich bestimmt ganz viele coole 34 00:01:47,120 --> 00:01:49,440 neue Erfahrungen sammeln, die dann bestimmt hier zu ganz 35 00:01:49,440 --> 00:01:52,560 vielen neuen Themen und Folgen und so weiter beitragen, aber da 36 00:01:52,560 --> 00:01:54,680 gibt es in Zukunft mehr. Es wird aber dabei bleiben, 37 00:01:54,680 --> 00:01:57,080 natürlich, wir machen diesen Podcast hier weiter und machen 38 00:01:57,080 --> 00:01:58,760 den auch weiterhin privat, teilen hier aber unsere 39 00:01:58,760 --> 00:02:01,920 Erfahrungen quasi aus echten Kundenprojekten und diskutieren 40 00:02:01,920 --> 00:02:04,680 aktuelle Themen, die die Developer Welt bewegen und. 41 00:02:04,800 --> 00:02:07,120 Und das Thema, worüber wir heute sprechen, da kann man ganz schön 42 00:02:07,120 --> 00:02:09,120 sagen, dass das die Developer Welt bewegt hat. 43 00:02:09,280 --> 00:02:14,040 Shay Hulut ein quasi ein Wurm, der vor allem das Java Script 44 00:02:14,040 --> 00:02:15,600 Ökosystem auf den Kopf gestellt hat. 45 00:02:15,840 --> 00:02:19,640 Was ist denn da passiert? Ja, tatsächlich, vorletzte 46 00:02:19,640 --> 00:02:23,280 Woche, da ist ein Beben durch die gesamte Softwareindustrie 47 00:02:23,280 --> 00:02:27,600 gegangen, quasi durch das gesamte Developer eco System. 48 00:02:27,840 --> 00:02:32,880 Da tatsächlich das Java Script Eco System und damit halt ein 49 00:02:32,880 --> 00:02:36,960 ganz großer Teil der Open Source Community einmal durchgerüttelt 50 00:02:36,960 --> 00:02:39,760 wurde durch den Chai Hulu Wurm, der sich. 51 00:02:40,320 --> 00:02:43,920 Super schnell ausgebreitet hat, und das war so ein bisschen das 52 00:02:43,920 --> 00:02:45,440 neue dabei. Wir hatten ja in der 53 00:02:45,440 --> 00:02:50,160 Vergangenheit schon zahlreiche Supply Chain Angriffe auch im 54 00:02:50,160 --> 00:02:52,480 Java Script Eco System, Wir hatten da auch in der 55 00:02:52,480 --> 00:02:56,560 Vergangenheit schon folgen zu gemacht, wir haben über Cover js 56 00:02:56,560 --> 00:02:59,920 gesprochen, wir haben aber über andere Angriffe gesprochen, wo 57 00:02:59,920 --> 00:03:03,600 tatsächlich über viele Jahre mit sehr. 58 00:03:04,000 --> 00:03:08,320 Ausgeklügelten Social Engineering Methoden, Zugriffe 59 00:03:08,320 --> 00:03:12,320 auf bekannte Open Source Projekte erschlichen wurden. 60 00:03:12,480 --> 00:03:14,600 Aber dieses Mal war es ein bisschen anders, weil es 61 00:03:14,600 --> 00:03:18,080 wirklich ein Wurm war, der sich dort in. 62 00:03:18,400 --> 00:03:22,320 Diesem Ökosystem extrem schnell ausgebreitet hat. 63 00:03:22,320 --> 00:03:26,520 Das bedeutet, wir konnten nicht einfach irgendwie ein Paket, ein 64 00:03:26,520 --> 00:03:30,560 Paket patchen, sondern mussten tatsächlich immer wieder 65 00:03:30,560 --> 00:03:34,480 reinschauen, weil irgendwie stündlich neue dazu kamen, von 66 00:03:34,480 --> 00:03:37,600 denen wir tatsächlich auch betroffen sein konnten, und das 67 00:03:37,600 --> 00:03:40,080 war tatsächlich etwas sehr Neues. 68 00:03:40,720 --> 00:03:42,760 Ja, vor allem muss man sagen, es ist nicht einfach nur yet 69 00:03:42,760 --> 00:03:45,720 Another malwhere genau deswegen, sondern hat ja eigentlich so 70 00:03:45,720 --> 00:03:49,520 eine fundamentale Schwachstelle in der Art und Weise, wie wir 71 00:03:49,520 --> 00:03:53,600 generell Third Party Pakete managen, aufgedeckt und wir 72 00:03:53,600 --> 00:03:55,400 rollen jetzt diese Folge immer so ein bisschen auf. 73 00:03:55,400 --> 00:03:57,840 Was ist denn eigentlich passiert, wie schützen wir uns, 74 00:03:57,840 --> 00:04:00,040 was wissen wir denn eigentlich als Developer jetzt machen also 75 00:04:00,040 --> 00:04:02,240 wie gesagt, das war im Intro ernst gemeint, wenn ihr noch 76 00:04:02,240 --> 00:04:05,040 nichts getan habt, hört noch kurz die Folge zu Ende, weil wir 77 00:04:05,040 --> 00:04:07,040 da genau die ersten Schritte jetzt besprechen und dann? 78 00:04:07,360 --> 00:04:09,960 Wir müssen alle aktiv werden und zumindest mal checken, ob wir 79 00:04:09,960 --> 00:04:12,080 davon betroffen sind. Und deswegen würde ich jetzt 80 00:04:12,080 --> 00:04:14,080 eigentlich mal sagen, wir gehen direkt rein und gucken mal, was 81 00:04:14,080 --> 00:04:17,279 ist denn über, also wie konnte das denn überhaupt passieren, 82 00:04:17,279 --> 00:04:19,760 was ist denn da, also wie konnte sich dieser Wurm so schnell 83 00:04:19,760 --> 00:04:22,160 verbreiten und was macht er vor allem. 84 00:04:22,880 --> 00:04:25,440 Ja, du hattest gerade gesagt, es ist ein Wurm und da haben wir 85 00:04:25,440 --> 00:04:29,520 auch so ein bisschen so eine June Referenz mit chaihu Loot 86 00:04:29,760 --> 00:04:34,320 und es waren wirklich in kürzester Zeit über 500 Pakete 87 00:04:34,320 --> 00:04:38,160 infiziert und letzten Endes funktionierte so, dass ein 88 00:04:38,560 --> 00:04:43,360 erstes Paket kompromittiert wurde und dort über letzten 89 00:04:43,360 --> 00:04:47,760 Endes dieses Paket im Post Install Script etwas 90 00:04:47,840 --> 00:04:50,880 nachinstalliert. Wurde der Post Install. 91 00:04:51,600 --> 00:04:55,320 Genau das heißt, ich habe das nicht unter Kontrolle, was dann 92 00:04:55,320 --> 00:04:58,520 am Ende dort auch von diesen Paketen nachinstalliert wird. 93 00:04:58,520 --> 00:05:01,120 Und dann wird das tatsächlich mit sehr hohen Rechten dann auch 94 00:05:01,120 --> 00:05:04,480 ausgeführt und nach der Installation dieses 95 00:05:04,480 --> 00:05:08,640 kompromittierten Paketes wurde dann entsprechend diese Malware 96 00:05:08,640 --> 00:05:11,480 auf meiner lokalen Maschine meiner Developer Maschine 97 00:05:11,480 --> 00:05:14,960 installiert. Ja, Posten soll das läuft halt 98 00:05:14,960 --> 00:05:18,480 automatisch nach der Installation und das Halt bei 99 00:05:18,480 --> 00:05:20,120 Default. Da werden keine Fragen gestellt, 100 00:05:20,120 --> 00:05:21,920 das wird einfach ausgeführt und da muss man sich ja schon 101 00:05:21,920 --> 00:05:24,880 irgendwie fragen ob es ist jetzt auch nicht das erste Mal, dass 102 00:05:24,880 --> 00:05:27,440 wir da irgendwie was sehen, scheinen sich Hacker scheint 103 00:05:27,440 --> 00:05:29,680 sehr sehr beliebt zu sein bei Hackern dieser Step, ob wir uns 104 00:05:29,680 --> 00:05:33,520 das überhaupt in Zukunft noch leisten können, dass es quasi 105 00:05:33,520 --> 00:05:35,520 irgendwelche ein paar wenige Skript, die das ja eigentlich 106 00:05:35,520 --> 00:05:37,600 erst mal nur verwenden, aber wie, das ist eben in npm 107 00:05:37,600 --> 00:05:40,240 eingebacken, dass da natürlich dann einfach. 108 00:05:40,480 --> 00:05:42,800 Software ausgeführt wird, die normalerweise ein bisschen zur 109 00:05:42,800 --> 00:05:45,480 Konfiguration oder zur Kompilierung auf dem Zielsystem, 110 00:05:45,480 --> 00:05:47,960 wenn es sich um verschiedene Zielsysteme wie Windows, Linux, 111 00:05:47,960 --> 00:05:50,640 Mac OS oder sowas handelt. Dafür ist das eigentlich da. 112 00:05:51,280 --> 00:05:54,720 Und ja, was da halt eben gemacht wurde ist, dass sofort dieser 113 00:05:54,720 --> 00:05:57,120 Wurm losgegangen ist und nach der Installation der Pakete, 114 00:05:57,680 --> 00:05:59,520 also nach der Infektion des Systems. 115 00:05:59,840 --> 00:06:02,720 Das Teil die gesamte Maschine darauf gescannt hat, ob nicht 116 00:06:02,720 --> 00:06:06,000 noch irgendwo Personal Access Tokens zum Beispiel für github, 117 00:06:06,440 --> 00:06:10,240 API Keys für Cloud Zugänge zum Beispiel mit Azure, AWS oder 118 00:06:10,240 --> 00:06:13,520 Google oder halt irgendwelche anderen schützenswerten 119 00:06:13,600 --> 00:06:16,080 Schlüssel gelegen haben. Unter anderem ist das Open 120 00:06:16,080 --> 00:06:20,200 Source Projekt Truffle Hock da wohl zum Einsatz gekommen. 121 00:06:20,200 --> 00:06:22,040 Das ist eigentlich was, wo man seinen eigenen Rechner drauf 122 00:06:22,040 --> 00:06:24,080 scannen kann, aber nicht noch irgendwelche Überbleibsel davon 123 00:06:24,080 --> 00:06:26,080 hat und. Und das ist natürlich eigentlich 124 00:06:26,080 --> 00:06:28,320 hochschützenswert, weil es dir eventuell wirklich auch Zugriff 125 00:06:28,440 --> 00:06:30,880 auf die gesamte Firmeninfrastruktur gibt, auf 126 00:06:30,880 --> 00:06:33,680 irgendwelche Cloud Accounts und und so hat er sich dann ja am 127 00:06:33,680 --> 00:06:36,640 Ende auch verbreitet, hinzu Package registrys, die du 128 00:06:36,640 --> 00:06:39,040 vielleicht entweder intern im Unternehmen verwendest oder, und 129 00:06:39,040 --> 00:06:41,360 das war natürlich dann für den Woman einen Jackpot, wenn Du 130 00:06:41,360 --> 00:06:44,160 selber Main tainer von einem Open Source depository bist, was 131 00:06:44,160 --> 00:06:46,080 irgendwelche Packages auf npm hochlädt. 132 00:06:46,960 --> 00:06:50,400 Ja, üblicherweise ist ja immer so die Guideline keine. 133 00:06:51,040 --> 00:06:55,040 Secrets in den Repositories zu halten, aber natürlich außerhalb 134 00:06:55,040 --> 00:06:59,440 der Repositories habe ich häufig irgendwelche Umgebungsdateien, 135 00:06:59,600 --> 00:07:02,160 wo vielleicht irgendwelche Credentials drin liegen, die ich 136 00:07:02,160 --> 00:07:06,000 während der Entwicklungsphase benötige und gegebenenfalls habe 137 00:07:06,000 --> 00:07:08,640 ich wie gesagt auch irgendwelche Access Tokens, die mich 138 00:07:08,640 --> 00:07:11,520 gegenüber package registrys authentifizieren. 139 00:07:11,680 --> 00:07:15,880 Nicht immer mache ich das über die empfohlenen sicheren 140 00:07:15,880 --> 00:07:19,680 Standards, dass ich dort mich entsprechend anmelde mit auch so 141 00:07:19,680 --> 00:07:23,520 einer Phishing und. Resistant Authentication, 142 00:07:23,600 --> 00:07:26,400 sondern ich habe vielleicht ein einfaches Token, mit dem ich 143 00:07:26,400 --> 00:07:29,280 mich gegen diese Systeme authentifiziere und wie du 144 00:07:29,280 --> 00:07:31,760 gerade gesagt hattest, wurde dort eine Open Source Software 145 00:07:31,760 --> 00:07:35,040 über dieses Post install installiert, was dann nicht mein 146 00:07:35,120 --> 00:07:38,640 Repository auf Secrets gescannt hat für mich, sondern 147 00:07:38,640 --> 00:07:42,080 tatsächlich wurden dort auch über mein Repository hinaus 148 00:07:42,720 --> 00:07:46,800 meine lokale Platte gescannt auf Secrets und diese Secrets wurden 149 00:07:46,960 --> 00:07:50,800 dann exfiltriert da. Das heißt, die wurden dann 150 00:07:50,800 --> 00:07:56,400 hochgeladen auf ein Repository auf github, welches die Hacker 151 00:07:56,400 --> 00:08:00,560 in dem Fall angelegt hatten und in diesem Repository befanden 152 00:08:00,560 --> 00:08:05,360 sich dann ganz viele gültige Secrets von diversen Developern, 153 00:08:05,360 --> 00:08:08,800 die Halt über diese Malware gefischt wurden. 154 00:08:08,960 --> 00:08:12,040 Also tatsächlich. Ist dieser Wurm eine Malware, 155 00:08:12,040 --> 00:08:15,040 die jetzt auf der lokalen Maschine erstmal keinen Schaden 156 00:08:15,040 --> 00:08:18,320 anrichtet, sondern letzten Endes nach Informationen sucht und 157 00:08:18,320 --> 00:08:22,000 diese Informationen dann exfiltriert und die dann den 158 00:08:22,000 --> 00:08:26,000 entsprechenden Urhebern dieses Wurms zur Verfügung stellt, 159 00:08:26,000 --> 00:08:29,520 damit sie dann mit diesen Secrets letzten Endes zu der 160 00:08:29,840 --> 00:08:34,240 tatsächlich schadhaften. Zum schadhaften Schritt 161 00:08:34,240 --> 00:08:37,440 übergehen können, wo sie wirklich dir massiv schaden 162 00:08:37,440 --> 00:08:39,880 können und natürlich dann auch ihren eigenen Wurm 163 00:08:39,880 --> 00:08:42,919 weiterverbreiten können. Ja, genau, und zwar sie haben 164 00:08:42,919 --> 00:08:44,000 sogar noch relativ schick gemacht. 165 00:08:44,000 --> 00:08:46,560 Sie haben sogar gesagt, also ich lade hier diese Creentials in 166 00:08:46,560 --> 00:08:48,800 dein Gitter repository, also nicht in deins, sondern dieses 167 00:08:48,800 --> 00:08:51,840 Gitter repository hoch, was sie da angelegt haben und falls das 168 00:08:51,840 --> 00:08:53,520 nicht funktionieren sollte, hier haben wir auch noch mal einen 169 00:08:53,520 --> 00:08:56,800 Web Hook, also wir haben hier Web Hook site, slash irgendwas 170 00:08:56,800 --> 00:08:59,280 verwendet, also wirklich auf mehreren Arten und weisen hat 171 00:08:59,280 --> 00:09:01,880 dieser Wurm mal die Daten nach außen gepumpt und. 172 00:09:02,000 --> 00:09:04,640 Und wie eben schon gesagt, Jackpot war es dann, wenn der 173 00:09:04,640 --> 00:09:07,120 eben wirklich zugangstoken zu anderen Package Managern 174 00:09:07,120 --> 00:09:11,400 gefunden hat, denn dann hat er sofort dort quasi sich die 175 00:09:11,400 --> 00:09:14,560 neueste Version von diesem Paket runtergeladen, das einfach nur 176 00:09:14,560 --> 00:09:18,560 um dieses Post install Skript ergänzt und wieder hochgeladen, 177 00:09:18,560 --> 00:09:21,400 sodass er sich dann quasi selber direkt weiter verbreitet hat auf 178 00:09:21,400 --> 00:09:23,920 alle anderen, die dann dieses Package benutzen. 179 00:09:24,000 --> 00:09:27,360 Von dem Entainer, von dem der Wurm gerade die Zugangstoken für 180 00:09:27,360 --> 00:09:30,960 npm und sowas abgegriffen hat und das sind so Dinge die. 181 00:09:31,440 --> 00:09:34,040 Jetzt häufiger gesehen haben. Das betrifft ja auch nicht nur 182 00:09:34,040 --> 00:09:36,160 npm. Also bei diesem, bei diesem Wurm 183 00:09:36,160 --> 00:09:39,320 jetzt schon, aber Python hat gerade erst neue Warnungen 184 00:09:39,320 --> 00:09:43,200 rausgegeben bezüglich Phishing Attacken, da hat auch jung, da 185 00:09:43,200 --> 00:09:47,040 hat auch eine Organisation versucht, das ist so die der 186 00:09:47,040 --> 00:09:49,600 Package Manager und die Package Registry von Python. 187 00:09:50,000 --> 00:09:54,800 Zu Fischen und wie PJ. Org statt pi pi. 188 00:09:54,880 --> 00:09:57,800 Org angelegt und wirklich dann versucht Mantainern irgendwelche 189 00:09:57,800 --> 00:10:00,240 e Mails zuschicken, dass sie irgendwie aktiv werden müssen um 190 00:10:00,240 --> 00:10:04,320 da credentials abzugreifen. Rust hat auf crades io gerade 2 191 00:10:04,320 --> 00:10:07,360 Pakete gefunden, die zur Laufzeit auf deiner Maschine 192 00:10:07,360 --> 00:10:09,840 nach Crypto Keys und Wallets suchen. 193 00:10:09,920 --> 00:10:12,320 The Crades AO ist ein bisschen die ist die Package Library von 194 00:10:12,320 --> 00:10:14,640 Rust und eigentlich geht es hier immer um das Gleiche. 195 00:10:15,040 --> 00:10:17,760 Du lädst dir ein Paket runter, das führt dann irgendwelche 196 00:10:18,080 --> 00:10:20,760 Software bei dir aus. Die versucht irgendwelche 197 00:10:20,760 --> 00:10:22,960 Secrets zu klauen oder irgendwelche anderen Daten zu 198 00:10:22,960 --> 00:10:26,960 gelangen und das kann ja in immense Auswirkungen haben, weil 199 00:10:26,960 --> 00:10:28,640 du ja vielleicht diese Pakete nicht immer nur bei dir auf 200 00:10:28,640 --> 00:10:30,880 deiner developer Maschine aufrufst, sondern auch zu 201 00:10:30,880 --> 00:10:34,000 Laufzeit zu bildzeit auf irgendwelchen Servern zu Runtime 202 00:10:34,160 --> 00:10:36,640 bei deinen Kunden dann wieder und so weiter das heißt, 203 00:10:36,640 --> 00:10:38,400 eigentlich ist es ja katastrophal, wenn ich einem 204 00:10:38,400 --> 00:10:42,960 Angreifer die Möglichkeit gebe, wirklich executable ausführbaren 205 00:10:42,960 --> 00:10:45,520 Code mit in diese Pakete zu schippen. 206 00:10:46,400 --> 00:10:50,160 Und gerade wenn du dann über diese Tokens dann umfangreiche 207 00:10:50,160 --> 00:10:53,000 Rechte auf den einzelnen Plattformen und Systemen 208 00:10:53,000 --> 00:10:56,960 bekommst, dann können natürlich auch wirklich massive Schäden 209 00:10:56,960 --> 00:11:00,240 entstehen, wie zum Beispiel mit einem entsprechenden Personal 210 00:11:00,240 --> 00:11:02,800 Access Token auf github und andere Plattformen können 211 00:11:02,800 --> 00:11:05,440 einfach auch Repositories verschoben werden, das heißt, 212 00:11:05,680 --> 00:11:09,440 dort wurden dann interne Unternehmensrepositories in den 213 00:11:09,600 --> 00:11:13,400 privaten Bereich als Public Repository verschoben und damit 214 00:11:13,400 --> 00:11:15,680 dann auch interne Unternehmensinformationen nach 215 00:11:15,680 --> 00:11:16,720 draußen gegeben. Gegeben. 216 00:11:16,960 --> 00:11:19,920 Du hast Situationen, wo tatsächlich dann auf deinen 217 00:11:19,920 --> 00:11:23,280 Cloud subscriptions dann irgendwelche Services ausgeführt 218 00:11:23,280 --> 00:11:25,120 werden. Ich meine das ist jetzt nichts 219 00:11:25,120 --> 00:11:30,720 Neues, dieses Fishing nach Credentials von oder access 220 00:11:30,720 --> 00:11:35,840 Tokens von solchen Hyperscalern wie Azure und Google findet ja 221 00:11:35,840 --> 00:11:38,080 tagtäglich statt, ich glaube man kann. 222 00:11:38,680 --> 00:11:42,480 Wenn man ein solches Secret in sein öffentliches Gitter 223 00:11:42,480 --> 00:11:44,920 repository packt, dann kann man davon ausgehen, dass das 224 00:11:44,920 --> 00:11:47,520 innerhalb von Minuten missbraucht wird und man dann 225 00:11:47,520 --> 00:11:49,760 relativ schnell einen Krypto Miner in seiner Cloud 226 00:11:49,760 --> 00:11:53,520 Subscription laufen hat und alle diese Dinge können natürlich 227 00:11:53,520 --> 00:11:58,000 passieren, weil solche Secrets über einen einfachen String 228 00:11:58,000 --> 00:12:03,120 extrem viele Rechte geben, in deinem Namen etwas in. 229 00:12:03,320 --> 00:12:07,320 In einem Dienst oder Cloud Service zu machen, und das ist 230 00:12:07,320 --> 00:12:09,840 natürlich eine massive Schwachstelle. 231 00:12:09,840 --> 00:12:12,120 Es gibt mittlerweile, und da kommen wir gleich auch noch mal 232 00:12:12,120 --> 00:12:16,000 im Detail drauf, viele Wege, wie man sich dort schützen kann, 233 00:12:16,160 --> 00:12:19,760 aber in der Praxis ist es immer noch so, dass diese Access 234 00:12:19,760 --> 00:12:22,720 Tokens und Secrets ganz häufig verwendet werden. 235 00:12:23,280 --> 00:12:24,480 Ja, jetzt muss ich mir natürlich überlegen. 236 00:12:24,480 --> 00:12:27,280 Klar kannst du jetzt sagen, auf meinem Developer Rechner sind 237 00:12:27,280 --> 00:12:29,760 hoffentlich keine Access Tokens irgendwie für irgendwelche 238 00:12:29,760 --> 00:12:32,280 Developer für irgendwelche Produktionssysteme drauf, aber. 239 00:12:32,920 --> 00:12:34,360 Aber man muss ja auch ein bisschen weiterdenken. 240 00:12:34,360 --> 00:12:36,400 Man checkt das dann irgendwie ein oder dieses geupdatete 241 00:12:36,400 --> 00:12:39,120 Paket, das geht dann in die Cicd, das heißt, es wird zur 242 00:12:39,120 --> 00:12:42,120 Bild Time auf den Bild Servern ausgeführt, da sind vielleicht 243 00:12:42,120 --> 00:12:44,960 schon ganz andere Möglichkeiten auf eine Infrastruktur 244 00:12:44,960 --> 00:12:47,640 zuzugreifen, dann wird es ja vielleicht entweder auf meinen 245 00:12:47,640 --> 00:12:50,520 Server deployed und ist da auf einmal zur zur Runtime auf 246 00:12:50,520 --> 00:12:52,560 einmal in meinem Kobolides Cluster und sowas und kann von 247 00:12:52,560 --> 00:12:55,520 da aus vielleicht dann sogar mit meiner Datenbank sprechen und da 248 00:12:55,520 --> 00:12:58,240 vielleicht sogar Sachen löschen oder sowas oder sich da aus den 249 00:12:58,240 --> 00:13:00,640 Environment Variablen irgendwelche Secrets ziehen. 250 00:13:01,080 --> 00:13:02,560 Im blödsten Fall habe ich vielleicht sogar eine 251 00:13:02,560 --> 00:13:05,520 Webanwendung, die die das Paket dann auch noch an den Anwender, 252 00:13:05,520 --> 00:13:08,720 also dann auf die Client Runtime ausspielt. 253 00:13:09,120 --> 00:13:11,120 Das heißt, ich habe ja ganz ganz viele Umgebungen, wo diese 254 00:13:11,120 --> 00:13:14,680 Skripte dann laufen und und scannen können, das heißt, es 255 00:13:14,680 --> 00:13:17,200 ist ja nicht nur mein Developerrechter der und da 256 00:13:17,200 --> 00:13:19,240 müssen wir uns, glaube ich alle mal ganz ehrlich an die Nase 257 00:13:19,240 --> 00:13:22,000 fassen, wahrscheinlich auch ein bisschen zu viele Tokens und zu 258 00:13:22,000 --> 00:13:25,160 viele Secrets hier und da irgendwie rumfliegen hat und. 259 00:13:25,240 --> 00:13:27,320 Und deswegen müssen wir da und da werden wir jetzt gleich mal 260 00:13:27,320 --> 00:13:29,760 drüber sprechen, quasi Maßnahmen treffen, dass sowas auch in 261 00:13:29,760 --> 00:13:31,680 Zukunft nicht mehr passieren kann, weil das wird nicht das 262 00:13:31,680 --> 00:13:34,160 letzte Mal gewesen sein, dass unser Rechner gescannt wird. 263 00:13:34,160 --> 00:13:36,640 Wir müssen davon ausgehen, dass wir uns eventuell davor gar 264 00:13:36,640 --> 00:13:39,920 nicht schützen können und deswegen eben Maßnahmen treffen, 265 00:13:39,920 --> 00:13:43,600 dass eigentlich wir alle von alle Secrets und alle Tokens von 266 00:13:43,600 --> 00:13:46,480 unseren Rechnern und im Idealfall auch aus allen CCD 267 00:13:46,480 --> 00:13:49,200 Pipelines verbannen werden, das schauen wir uns gleich mal an. 268 00:13:50,160 --> 00:13:53,400 Tatsächlich sind auch sofort Maßnahmen ergriffen worden und 269 00:13:53,400 --> 00:13:57,440 nicht nur von den Developern, die diese schadhaften Pakete 270 00:13:57,440 --> 00:14:02,320 einsetzen, sondern auch von Seiten von Gitter bzw npm, wo 271 00:14:02,320 --> 00:14:04,440 sich diese Pakete verbreitet haben. 272 00:14:04,560 --> 00:14:08,400 Und da wurden ganz viele Pakete gelöscht, die von diesem. 273 00:14:08,960 --> 00:14:12,800 Wurm infiziert wurden und dementsprechend da auch 274 00:14:12,800 --> 00:14:15,840 verhindert, dass man sich diese Pakete aus Versehen noch 275 00:14:15,840 --> 00:14:18,040 nachinstalliert. Nachdem das Ganze schon bekannt 276 00:14:18,040 --> 00:14:20,240 geworden ist. Das bedeutet, wenn du dieses. 277 00:14:20,680 --> 00:14:23,120 Entsprechende Paket noch nicht auf der lokalen Maschine oder 278 00:14:23,120 --> 00:14:26,240 auf Deinem Bird System hast, bist du zumindest im Rahmen der 279 00:14:26,240 --> 00:14:30,240 bekannten Pakete aktuell sicher. Aber wenn die Pakete schon auf 280 00:14:30,240 --> 00:14:33,920 der Maschine sind, muss man natürlich aufräumen und zudem 281 00:14:33,920 --> 00:14:37,680 hat npm noch einige Schritte unternommen, die verhindern 282 00:14:37,680 --> 00:14:41,200 sollen, dass so etwas noch einmal auftritt und dazu gehören 283 00:14:41,200 --> 00:14:44,480 solche Dinge wie multifaktor Authentifizierung auf den 284 00:14:44,480 --> 00:14:47,680 Publisher, Accounts oder auch kürzere Gültigkeiten. 285 00:14:48,160 --> 00:14:51,840 Für die Tokens, fürs Package Publishing und natürlich 286 00:14:51,840 --> 00:14:54,880 Empfehlungen, die an Package Publisher rausgegangen sind, wie 287 00:14:54,880 --> 00:14:58,160 zum Beispiel keine weitere Verwendung von sogenannten 288 00:14:58,160 --> 00:15:02,160 Legacy oder Classic Tokens, sondern nur noch moderne Tokens 289 00:15:02,160 --> 00:15:05,680 mit entsprechenden Access Permissions zu verwenden, wo man 290 00:15:05,680 --> 00:15:08,320 sehr genau entscheiden kann, welche Rechte ich auf diesen 291 00:15:08,640 --> 00:15:11,360 Tokens habe. Das heißt, die Idee ist, dass 292 00:15:11,360 --> 00:15:15,440 wir tatsächlich verhindern, dass wenn solche Tokens verloren 293 00:15:15,440 --> 00:15:18,040 gehen, der Angriffsvektor mit diesen Tokens mit. 294 00:15:18,160 --> 00:15:20,840 Möglichst reduziert wird. Genau das hat vor allem github 295 00:15:20,840 --> 00:15:23,200 gesagt, dass sie diese Classic Tokens jetzt so schnell wie 296 00:15:23,200 --> 00:15:27,920 möglich irgendwie depricaten werden und eine maximale 297 00:15:27,920 --> 00:15:30,320 Gültigkeit von 7 Tagen für Tokens nur noch erlauben. 298 00:15:30,320 --> 00:15:33,440 Die Packages. Publishen zusammen mit dieser 2 299 00:15:33,440 --> 00:15:36,560 Faktor Authentifizierung und die Idee ist sogar langfristig, das 300 00:15:36,560 --> 00:15:38,240 sogar noch deutlich kürzer zu machen. 301 00:15:38,240 --> 00:15:42,080 Also eigentlich will ich, dass gestohlene Tokens sofort nutzlos 302 00:15:42,080 --> 00:15:44,840 sind, weil sie entweder nur auf einer ganz bestimmten Maschine 303 00:15:44,840 --> 00:15:47,120 verwendet werden können, wie zum Beispiel auf irgendwelchen cicd 304 00:15:47,120 --> 00:15:50,880 Servern, die dann diese Pakete publishen, weil man auch so ein 305 00:15:50,880 --> 00:15:52,440 bisschen gerade irgendwie einsieht, das was ich vorhin 306 00:15:52,440 --> 00:15:54,040 schon mal gesagt habe, wir müssen uns, glaube ich damit 307 00:15:54,040 --> 00:15:56,720 abfinden, dass wir uns nicht zu 100% sicher davor schützen 308 00:15:56,720 --> 00:15:58,680 können, dass Tokens gestohlen werden und. 309 00:15:58,760 --> 00:16:00,880 Und deswegen ist es so wichtig, dass wir eigentlich sagen, ey, 310 00:16:00,880 --> 00:16:03,400 ich will, wenn wir Tokens verwenden, die gar nicht mehr 311 00:16:03,400 --> 00:16:07,280 irgendwo gespeichert haben, die sollen idealerweise von der von 312 00:16:07,280 --> 00:16:10,640 meinem Bildserver kurzzeitig auch nur generiert werden, 313 00:16:11,120 --> 00:16:12,520 meistens noch in einem zweiten Faktor. 314 00:16:12,520 --> 00:16:14,720 Daher kommen, also zumindest von einer bestimmten IP Adress Range 315 00:16:14,720 --> 00:16:18,480 kommen oder auf einer bestimmten Hardware ausgeführt werden und 316 00:16:18,480 --> 00:16:20,320 da hat sich jetzt geht aber auch direkt mit starkem machen 317 00:16:20,320 --> 00:16:22,400 gesagt, wir sie würden, sie werden massiv noch mal das 318 00:16:22,400 --> 00:16:26,240 Trusted Publishing fördern und da mehr Provider Onboarden 319 00:16:26,240 --> 00:16:27,840 Trusted Publishing läuft so, dass. 320 00:16:28,440 --> 00:16:30,560 Dass ich im Prinzip eine Vertrauensverbindung zwischen 321 00:16:30,800 --> 00:16:34,080 der npm Packet Registry oder vielen anderen Registrys 322 00:16:34,080 --> 00:16:38,480 herstellen kann und zwischen meinem zwischen in meinem bei 323 00:16:38,480 --> 00:16:41,080 Gitterwald im Fall von meinen Gitter Actions runnern, die auch 324 00:16:41,080 --> 00:16:43,280 teilweise von Gitter selber ja in der Cloud betrieben werden, 325 00:16:43,680 --> 00:16:46,240 und dass ich mich dann quasi, dass ich nur diese Runner auch 326 00:16:46,240 --> 00:16:48,480 nur aus diesem Repository überhaupt gegen. 327 00:16:49,720 --> 00:16:52,560 Gegen diese Libraries eben auch identifizieren können, noch nur 328 00:16:52,560 --> 00:16:56,320 in diesen einen Schritten von meinem Bildprozess und so weiter 329 00:16:56,320 --> 00:17:00,240 also versuchen da jetzt noch mal noch noch mehr Augenmerk drauf 330 00:17:00,240 --> 00:17:03,200 zu legen und die Provider, das fand ich eigentlich ganz cool, 331 00:17:03,200 --> 00:17:05,079 haben sich da quasi direkt hingestellt und gesagt okay 332 00:17:05,079 --> 00:17:08,400 jetzt reichts, wir müssen da noch mal noch mal 2 schippen 333 00:17:08,400 --> 00:17:10,720 drauflegen, was das die ganze Security angeht und eigentlich 334 00:17:10,720 --> 00:17:13,440 müssen wir die Verwendung von Tokens komplett verband, 335 00:17:13,440 --> 00:17:15,040 zumindest von langlebigen Tokens und. 336 00:17:15,640 --> 00:17:18,800 Und kurzfristige Tokens einsetzen, das zumindest so für 337 00:17:18,800 --> 00:17:21,920 die Zukunft von Morgen, von morgen, wie wir das in Zukunft 338 00:17:21,920 --> 00:17:24,520 verhindern können. Wir müssen aber jetzt sofort 339 00:17:24,520 --> 00:17:26,520 tätig werden, also alle Developer, die jetzt hier 340 00:17:26,520 --> 00:17:28,840 zuhören, die irgendwie ein Projekt haben, was in der Java 341 00:17:28,840 --> 00:17:32,840 Script Welt unterwegs ist. Was npm verwendet es gibt ein 342 00:17:32,840 --> 00:17:36,360 paar Sofortmaßnahmen, die wir quasi jetzt sofort machen 343 00:17:36,360 --> 00:17:38,800 müssen. Und das Wichtigste ist zum 344 00:17:38,800 --> 00:17:41,440 ersten Mal. Mal zu schauen, welche Tokens 345 00:17:41,440 --> 00:17:44,240 sind gegebenenfalls dort gestohlen worden. 346 00:17:44,240 --> 00:17:47,360 Das heißt, ich muss auf meiner lokalen Maschine schauen, welche 347 00:17:47,360 --> 00:17:51,280 Tokens sind da und muss diese Tokens sofort rotieren, wenn ich 348 00:17:51,280 --> 00:17:54,400 da keinen Überblick habe oder keinen Überblick bekommen kann, 349 00:17:54,400 --> 00:17:56,560 weil ich vielleicht irgendwie ein Unternehmen bin und. 350 00:17:56,840 --> 00:17:59,480 Keinen Zugriff auf die einzelnen Developer Maschinen habe, muss 351 00:17:59,480 --> 00:18:02,720 ich als Vorsichtsmaßnahme einfach alle Tokens, alle 352 00:18:02,720 --> 00:18:06,480 Credentials einmal rotieren um sicherzugehen, dass diese nicht 353 00:18:06,480 --> 00:18:09,200 mehr missbraucht werden können. Das können Personal access 354 00:18:09,200 --> 00:18:12,400 Tokens sein, das können Cloud API PS sein, das heißt ich 355 00:18:12,400 --> 00:18:15,840 sollte sowohl meine Maschinen scannen als auch als 356 00:18:15,840 --> 00:18:20,080 Vorsichtsmaßnahme diese Tokens entsprechend. 357 00:18:20,480 --> 00:18:22,520 Rotieren. Ja, ich würde einfach ganz klar 358 00:18:22,520 --> 00:18:25,760 sagen, dass ich davon ausgehen muss, dass ich betroffen bin. 359 00:18:25,760 --> 00:18:29,160 Also im Worst case habe ich halt Tokens, irgendwelche Secrets 360 00:18:29,160 --> 00:18:31,560 rotiert und war gar nicht betroffen, aber dieser Angriff 361 00:18:31,560 --> 00:18:34,240 ist so groß, dass ich sagen würde, nimm an, dass du 362 00:18:34,240 --> 00:18:36,960 betroffen bist. Rotier alle Personal access 363 00:18:36,960 --> 00:18:39,920 Tokens, Secrets, npm Keys, Cloud API Keys, die du irgendwie 364 00:18:39,920 --> 00:18:41,600 rausgegeben hast. Wenn du selber lieber noch mal 365 00:18:41,600 --> 00:18:42,720 bist. Du kannst ja sogar einfach 366 00:18:42,720 --> 00:18:45,680 dieses Truffle Hock Tool selber mal selber mal verwenden, das 367 00:18:45,680 --> 00:18:48,240 ist nämlich auch genau das was dieser Virus verwendet hat. 368 00:18:48,720 --> 00:18:50,120 Link dazu gibt es auch in der Beschreibung. 369 00:18:50,120 --> 00:18:53,760 Da kann man selber seine Maschine mal danach durchsuchen, 370 00:18:54,000 --> 00:18:56,320 ob man solche Keys hat, aber ich würde einfach ganz klar 371 00:18:56,320 --> 00:18:58,840 empfehlen, geh mal davon aus, dass du betroffen bist in 372 00:18:58,840 --> 00:19:01,880 irgendeiner Art und Weise. Und dann musst du natürlich 373 00:19:01,880 --> 00:19:06,600 hingehen und deine npm Pakete auditen und musst schauen, gehst 374 00:19:06,600 --> 00:19:09,440 du irgendwo auf immer die neueste Version? 375 00:19:09,520 --> 00:19:12,640 Falls ja solltest du auf jeden Fall jetzt auf eine Version 376 00:19:12,640 --> 00:19:14,680 gehen, die auf jeden Fall sicher ist. 377 00:19:14,680 --> 00:19:18,720 Sogenanntes known safe Release, also alle Sachen die vor dem 378 00:19:18,720 --> 00:19:22,080 Auftreten dieses Wurms veröffentlicht wurden sind. 379 00:19:22,720 --> 00:19:25,200 Erstmal von diesem Wurf wahrscheinlich nicht betroffen. 380 00:19:25,200 --> 00:19:28,640 Das heißt, wenn ich da auf diese Version runtergehe, dann bin ich 381 00:19:28,640 --> 00:19:30,720 da erstmal auf der sicheren Seite. 382 00:19:30,920 --> 00:19:33,720 Ich kann natürlich für die Zukunft andere Maßnahmen 383 00:19:33,720 --> 00:19:36,480 ergreifen, aber das sind erstmal diese Sofortmaßnahmen, die ich 384 00:19:36,480 --> 00:19:40,320 sofort umsetzen muss. Genau also alles, was vor dem 16 385 00:19:40,320 --> 00:19:43,840 September 2025. Das ist so der Tag, wo das alles 386 00:19:43,840 --> 00:19:46,240 angefangen hat, irgendwie aufzupoppen alles vorher erstmal 387 00:19:46,640 --> 00:19:49,600 glaube ich als halbwegs safe zu deklarieren. 388 00:19:50,080 --> 00:19:52,560 Zumal mittlerweile ja auch hier die ganzen großen Package libri 389 00:19:52,560 --> 00:19:55,040 Provider genug Zeit hatten, diese Signatur von diesem Wurm 390 00:19:55,040 --> 00:19:56,880 eben zu erkennen und die entsprechenden Packages zu 391 00:19:56,880 --> 00:19:58,920 löschen. Ich sollte natürlich aber auch 392 00:19:58,920 --> 00:20:01,520 gucken, dass ich einmal komplett meinen Node modules Ordner 393 00:20:01,520 --> 00:20:06,000 lösche und meinen Cache mein npm Cache lösche, dass da quasi auf 394 00:20:06,000 --> 00:20:08,280 keinen Fall mehr Pakete noch bei mir in der auf der lokalen 395 00:20:08,280 --> 00:20:11,280 Maschine sind, auch die können ja vielleicht aus der Library 396 00:20:11,520 --> 00:20:13,880 aus der NPM Registry entfernt worden sein, aber noch bei mir 397 00:20:13,880 --> 00:20:17,200 auf der auf der Maschine sein. Ja, und dann gucke ich einfach 398 00:20:17,200 --> 00:20:21,240 mal, ob ich betroffen bin. Es gibt von Jfrog eine Liste, 399 00:20:21,240 --> 00:20:25,440 eine sehr, sehr lange Liste von Paketen, die scheinbar davon 400 00:20:25,440 --> 00:20:28,120 betroffen waren, da findet ihr auch den Link in der Show Notes 401 00:20:28,120 --> 00:20:31,600 und dann durchsucht ihr mal euren Euren S Bom, den habt ihr 402 00:20:31,600 --> 00:20:35,040 ja spätestens seit Folge 103 von diesem Podcast hoffentlich alle. 403 00:20:35,640 --> 00:20:37,320 Ansonsten kann man natürlich auch irgendwie in die Log 404 00:20:37,320 --> 00:20:38,840 Dateien reingucken und mal schauen, welche Pakete 405 00:20:38,840 --> 00:20:41,800 eigentlich da welche Projekte installieren und dann muss man 406 00:20:41,800 --> 00:20:43,920 das abgleichen und gucken. Bin ich denn betroffen worden 407 00:20:44,160 --> 00:20:46,160 oder ich mache es einfach, wie ich jetzt empfohlen habe, gesagt 408 00:20:46,160 --> 00:20:48,160 habe ich gehe einfach mal davon aus, dass ich betroffen wurde 409 00:20:48,480 --> 00:20:51,440 und muss dann natürlich auch entsprechende Paketversionen 410 00:20:51,760 --> 00:20:54,560 aktualisieren. Und gerade wenn ich ein 411 00:20:54,560 --> 00:20:56,720 Unternehmen bin, sollte ich auch mal in meine Firewall 412 00:20:56,720 --> 00:21:00,960 reinschauen und mir irgendwie. Outbound Connections anschauen, 413 00:21:00,960 --> 00:21:03,720 die irgendwie fishy aussehen. Du hast es ja gerade gesagt, 414 00:21:03,720 --> 00:21:09,040 dieses webhook Dot Side oder irgendwelche Pushes auf Repos, 415 00:21:09,040 --> 00:21:12,720 die ich nicht kenne, weil das sind durchaus ganz klare 416 00:21:12,720 --> 00:21:18,320 Indikatoren, dass dieser Wurm in meinem Netzwerk aktiv war und 417 00:21:18,320 --> 00:21:22,160 gegebenenfalls Secrets nach außen publiziert hat und ich 418 00:21:22,160 --> 00:21:25,840 dementsprechend mit einer noch schnelleren Geschwindigkeit 419 00:21:25,840 --> 00:21:28,800 vorgehen muss, um halt diese Vorsichtsmaßnahmen zu ergreifen. 420 00:21:30,080 --> 00:21:32,960 Ja, und langfristig müssen wir uns natürlich Strategien 421 00:21:32,960 --> 00:21:35,280 überlegen, wie wir sowas in Zukunft nicht mehr machen. 422 00:21:35,760 --> 00:21:38,560 Und eine Sache, die glaube ich ganz klar ist, ist, wir können 423 00:21:38,560 --> 00:21:43,200 es uns eigentlich nicht mehr leisten, keine genauen Versionen 424 00:21:43,200 --> 00:21:45,880 von irgendwelchen Paketen zu pin, ich weiß, es ist irgendwie 425 00:21:45,880 --> 00:21:51,840 angenehm zu sagen, ja, gib mir mal ungefähr die Version XY, was 426 00:21:51,840 --> 00:21:54,200 auch immer, solange das kein neuer Major Release oder keine 427 00:21:54,200 --> 00:21:56,080 neue Features ist, wird das schon irgendwie passen. 428 00:21:56,760 --> 00:21:59,360 Es ist angenehm, aber genauso konnte sich dieser Wurm eben 429 00:21:59,360 --> 00:22:01,360 schnell verbreiten. Dass ich eine ungefähre Version 430 00:22:01,360 --> 00:22:05,200 in meinen Packages angelegt habe, bedeutet konkret, ich will 431 00:22:05,200 --> 00:22:08,640 eigentlich keine Tilde und keine Carrits, also diese spitze 432 00:22:08,640 --> 00:22:13,680 klammern nach oben, dieses Dach mehr in den in den Package json 433 00:22:13,680 --> 00:22:17,440 Dateien sehen, ich sollte wenn ich das natürlich eh noch nicht 434 00:22:17,440 --> 00:22:20,320 mache, aber die Empfehlung ist natürlich immer log Files mit zu 435 00:22:20,320 --> 00:22:24,080 committen also einen Package log json in Jahren Punkt Login Bann 436 00:22:24,080 --> 00:22:28,560 Punkt Login Uv Punkt log. Pn pm log log Punkt Yamel all 437 00:22:28,560 --> 00:22:31,720 diese ganzen Log Dateien, die gehören mit eingecheckt weil ich 438 00:22:31,720 --> 00:22:34,480 damit sicherstellen kann, dass zumindest erstmal schon mal alle 439 00:22:34,480 --> 00:22:38,320 die bei locker auf dem gleichen Dependency Tree arbeiten und wir 440 00:22:38,320 --> 00:22:41,280 können wie gesagt uns eigentlich nicht mehr leisten ungefähre 441 00:22:41,280 --> 00:22:44,320 Version zu verwenden, weil dann eben es kommt eine neue 442 00:22:44,400 --> 00:22:46,800 Kompromittierte Package Version, die kann ja vielleicht sogar 443 00:22:46,800 --> 00:22:49,280 wenige Stunden später schon wieder entdeckt und gefixt 444 00:22:49,280 --> 00:22:51,680 worden sein, aber wenn ich in diesen Stunden einfach ein Bild 445 00:22:51,680 --> 00:22:53,760 gemacht habe und die Version ungefähr gepasst hat. 446 00:22:54,040 --> 00:22:55,880 Dann kann es eben passieren, dass der sogar auf meinem 447 00:22:55,880 --> 00:22:58,680 Bildserver mit runtergeladen wird und deswegen werde ich dazu 448 00:22:58,680 --> 00:23:02,480 übergehen und keine Tilde und keine Carrits mehr verwenden, 449 00:23:02,640 --> 00:23:05,920 sondern Versionen ganz klar mit ihrer kompletten Versionsnummer 450 00:23:05,920 --> 00:23:08,000 zu pin. Ja, und tatsächlich gilt das ja 451 00:23:08,000 --> 00:23:10,840 für alle Package Eco Systeme oder für immer. 452 00:23:10,840 --> 00:23:14,160 Wenn ich die Pencs habe. Das gilt jetzt nicht nur für NPM 453 00:23:14,160 --> 00:23:17,920 und Java Script Pakete, sondern das sollte ich tatsächlich immer 454 00:23:17,920 --> 00:23:19,840 berücksichtigen. Wir hatten in der Vergangenheit 455 00:23:19,840 --> 00:23:22,400 ja auch schon mal über solche Dinge wie github actions 456 00:23:22,400 --> 00:23:26,480 gesprochen, wo ich verschiedene. Versionen habe von meinen 457 00:23:26,480 --> 00:23:29,280 Actions die ich verwende und auch hier sollte ich die Commits 458 00:23:29,280 --> 00:23:31,760 entsprechend pin um sicherzugehen, dass ich das 459 00:23:31,760 --> 00:23:36,600 bekomme, was ich als sicher erachte und geprüft habe und 460 00:23:36,600 --> 00:23:40,400 tatsächlich bei den Paketen und bei den Registrys gehen einige 461 00:23:40,400 --> 00:23:42,760 Unternehmen und das kann. Kann man ja mal darüber 462 00:23:42,760 --> 00:23:45,520 nachdenken, ob man das auch machen möchte, weil man 463 00:23:45,520 --> 00:23:48,720 vielleicht sicherheitskritische Software entwickelt, gehen 464 00:23:48,720 --> 00:23:52,160 einige Unternehmen so weit, dass sie tatsächlich auch Kopien der 465 00:23:52,160 --> 00:23:56,480 Pakete als sicher klassifizierte Kopien der Pakete in eigene 466 00:23:56,480 --> 00:24:00,320 Registrys legen, die sie lokal betreiben oder tatsächlich von 467 00:24:00,320 --> 00:24:03,360 ganz wichtigen Depenses, vielleicht auch Forks anlegen, 468 00:24:03,360 --> 00:24:05,760 die sie selber pflegen. Das ist jetzt wirklich die. 469 00:24:06,320 --> 00:24:10,120 Extra sicher Variante, weil ich da natürlich sicher gehen kann, 470 00:24:10,120 --> 00:24:13,360 dass ich alles unter Kontrolle habe und ich kann auch sicher 471 00:24:13,360 --> 00:24:16,560 gehen, dass nicht einzelne Developer vielleicht mal von 472 00:24:16,560 --> 00:24:18,720 diesen Best practices, die du gerade besprochen hast, 473 00:24:18,720 --> 00:24:22,160 abweichen, sondern ich kann tatsächlich vorgeben, dass nur 474 00:24:22,240 --> 00:24:25,680 mein eigener Package Stream verwendet wird in meinem 475 00:24:25,680 --> 00:24:27,840 Unternehmen und alles andere blocke ich gegen die Firewall 476 00:24:27,840 --> 00:24:30,480 durch die Firewall und dementsprechend kann ich ganz 477 00:24:30,480 --> 00:24:34,560 genau kontrollieren, welche Versionen von welchem Paket 478 00:24:34,560 --> 00:24:36,160 überhaupt in meinem Unternehmen vor. 479 00:24:36,320 --> 00:24:38,400 Verfügbar sind und verwendet werden können. 480 00:24:38,640 --> 00:24:40,920 Und immer wenn ich diesen eigenen Package Stream habe, der 481 00:24:40,920 --> 00:24:44,520 nicht automatisch von npm die Pakete immer nachlädt und 482 00:24:44,520 --> 00:24:48,080 dementsprechend alles auch inklusive Malware vorhält, dann 483 00:24:48,080 --> 00:24:51,520 kann ich natürlich sehr gut kontrollieren, was letzten Endes 484 00:24:51,520 --> 00:24:54,720 an Dependencies nachgeladen wird, aber da ist natürlich 485 00:24:54,720 --> 00:24:57,640 etwas, was für kleine Unternehmen oder individuelle 486 00:24:57,640 --> 00:24:59,440 Entwickler meistens Overkill ist. 487 00:24:59,440 --> 00:25:02,680 Und deswegen sind ja diese großen Package Manager so 488 00:25:02,680 --> 00:25:05,680 beliebt, weil es damit so einfach ist, auf dieses riesige 489 00:25:05,680 --> 00:25:08,440 eco System. Themen von Open Source 490 00:25:09,040 --> 00:25:13,320 Komponenten zurückzugreifen und es gibt einige Unternehmen, die 491 00:25:13,320 --> 00:25:16,800 gehen so weit und sagen, ich verzichte auf dieses Verhalten, 492 00:25:16,800 --> 00:25:18,840 was ich gerade in der Java Script Community ganz oft sehe, 493 00:25:18,840 --> 00:25:21,560 dass ich für jeden. Für jede Zeile Code, die ich 494 00:25:21,560 --> 00:25:23,760 sparen kann, ziehe ich lieber eine Dependency rein. 495 00:25:24,000 --> 00:25:27,000 Da gehen Sie tatsächlich hin und sagen okay, dann schreibe ich 496 00:25:27,000 --> 00:25:30,640 vielleicht mal lieber irgendwie 20 Zeilen Codes selber als yet 497 00:25:30,640 --> 00:25:33,680 another dependency in mein Projekt reinzuholen, aber das 498 00:25:33,680 --> 00:25:35,200 muss man sich natürlich überlegen, das ist so ein 499 00:25:35,200 --> 00:25:38,720 bisschen so eine Abwägungssache, auch zwischen Komfort und 500 00:25:38,720 --> 00:25:42,160 zusätzlichem Aufwand und natürlich dem Thema Sicherheit. 501 00:25:42,680 --> 00:25:44,360 Ja, was du gerade als zweites gesagt hast, halte ich für 502 00:25:44,360 --> 00:25:45,600 deutlich realistischer. Ehrlich gesagt. 503 00:25:45,600 --> 00:25:48,400 Also ja, ich weiß, dass es Unternehmen gibt, die wenn die 504 00:25:48,400 --> 00:25:51,480 auf super Safe spielen und alle Packages lokal speichern und 505 00:25:51,480 --> 00:25:54,960 sogar eigene Forks machen. Ich glaube also da leidet 506 00:25:54,960 --> 00:25:57,000 natürlich auch sehr die Developer Experience drunter, 507 00:25:57,000 --> 00:25:59,920 ich glaube das ist schon ein Thema, wo wir uns irgendwie alle 508 00:25:59,920 --> 00:26:02,160 irgendwie auch gemeinsam irgendwie dran arbeiten müssen, 509 00:26:02,160 --> 00:26:04,760 also ich glaube die ist so eine Version pin okay aber 510 00:26:04,760 --> 00:26:06,960 wahrscheinlich wenn ich in so einer Hochsicherheitsumgebung 511 00:26:06,960 --> 00:26:09,040 arbeite, dann muss ich das schon so machen, dass ich da meine 512 00:26:09,040 --> 00:26:10,720 eigenen Packages habe, aber sonst? 513 00:26:11,320 --> 00:26:13,120 Ich glaube, ich würde eher sagen, was du gerade als zweites 514 00:26:13,120 --> 00:26:14,400 gesagt hast. Mal irgendwie überlegen. 515 00:26:14,480 --> 00:26:19,000 Brauche ich wirklich einen Axios für meinen simplen http request 516 00:26:19,000 --> 00:26:21,920 oder reicht da vielleicht auch mittlerweile die in Node js 517 00:26:21,920 --> 00:26:24,400 eingebaute Fetch Library, die mittlerweile sogar ziemlich gut 518 00:26:24,400 --> 00:26:26,400 ist? Oder reicht vielleicht auch der 519 00:26:26,640 --> 00:26:30,160 der eingebaute Node js testrunner für meine Sachen 520 00:26:30,160 --> 00:26:32,080 brauche ich also das, was du gerade als zweites vielleicht 521 00:26:32,400 --> 00:26:34,720 sollte ich aufhören diese kleinen Helper Library zu 522 00:26:34,720 --> 00:26:37,280 verhindern und so ein bisschen vielleicht meinen Angriffsvektor 523 00:26:37,760 --> 00:26:40,960 auch mal zu verkleinern und. Und ja, so ein bisschen besser 524 00:26:40,960 --> 00:26:42,440 zu kontrollieren, was habe ich denn eigentlich für 525 00:26:42,440 --> 00:26:45,080 Dependencies, vor allem so transitive Dependencies, also 526 00:26:45,080 --> 00:26:47,960 das sind die Dependencies von meinen Dependencies, weil die 527 00:26:47,960 --> 00:26:50,800 sind ja noch viel, viel schwieriger zu kontrollieren, da 528 00:26:50,800 --> 00:26:53,600 hole ich mir oft auch wirklich Mist irgendwie mit rein, den ich 529 00:26:53,600 --> 00:26:57,560 nicht kontrollieren kann, da gibt es auch 23 Arten und 530 00:26:57,560 --> 00:26:58,880 weisen, wie ich damit umgehen kann. 531 00:26:58,880 --> 00:27:02,160 Es gibt in npm zum Beispiel sogenannte over Rights, da kann 532 00:27:02,160 --> 00:27:05,120 ich eine bestimmte Version von einer Dependency von meiner 533 00:27:05,120 --> 00:27:08,160 dependency enforcen. Das heißt, nehmen wir eigentlich 534 00:27:08,160 --> 00:27:10,600 installiert, ist irgendwie ein kleines Tool und das nutzt der 535 00:27:10,600 --> 00:27:12,960 Klassiker irgendwie. Low Dash und Label, dann Low 536 00:27:12,960 --> 00:27:14,880 Dash in einer bestimmten Version nachladen, die ich gar nicht 537 00:27:14,880 --> 00:27:18,160 kontrollieren kann, da kann ich, das kann ich entforcen, da kann 538 00:27:18,160 --> 00:27:20,640 ich zum Beispiel bei npm sagen, Nee, Low Dash wird immer, immer, 539 00:27:20,640 --> 00:27:22,560 immer in dieser Version, die ich hier definiert habe, 540 00:27:22,560 --> 00:27:25,280 nachgeladen, das kann natürlich auch schief gehen, weil das 541 00:27:25,280 --> 00:27:27,400 Projekt dann vielleicht trotzdem genau diese eine Version 542 00:27:27,400 --> 00:27:30,960 braucht, aber da gibt es auch so ein bisschen Mittel und Wege 543 00:27:30,960 --> 00:27:33,240 von, aber gerade diese transitiven Dependencies, die 544 00:27:33,240 --> 00:27:36,600 sind natürlich ja oft schwieriger einzufangen und. 545 00:27:37,080 --> 00:27:38,920 Und das zweite, was natürlich ultra schwierig anzufangen sind, 546 00:27:38,920 --> 00:27:42,680 sind diese Post Install Skripte, durch die sich jetzt auch wieder 547 00:27:42,680 --> 00:27:44,480 dieser Wurm verbreitet hat. Also da würde ich sagen, 548 00:27:44,480 --> 00:27:46,880 langfristig können wir auch mal drüber nachdenken, ob wir die 549 00:27:46,880 --> 00:27:49,360 nicht mal deaktivieren. In npm kann ich das sagen, da 550 00:27:49,360 --> 00:27:51,760 gibt es einen npm config, da kann ich einfach sagen Agnor 551 00:27:51,760 --> 00:27:54,960 Scripts ist gleich true und das ist erstmal mein Default und 552 00:27:54,960 --> 00:27:59,200 wenn dann so ein npm Paket dann wirklich so ein Post Install 553 00:27:59,200 --> 00:28:01,400 Skript ausführen will, dann kriegt er halt einen Fehler und 554 00:28:01,400 --> 00:28:03,000 dann kann ich ja immer noch mal hingehen und mir ganz genaue 555 00:28:03,000 --> 00:28:04,840 Gedanken machen ob ich das nicht vielleicht für dieses eine Paket 556 00:28:04,840 --> 00:28:06,360 erlaube, weil das da vielleicht sinnvoll ist und. 557 00:28:06,720 --> 00:28:08,680 Oder ich mich selber vielleicht noch mal aktiv werden muss nach 558 00:28:08,680 --> 00:28:10,240 der Installation. Aber eigentlich ist das so ein 559 00:28:10,400 --> 00:28:13,680 Convenience Feature was wir uns glaube ich nicht mehr leisten 560 00:28:13,680 --> 00:28:16,240 können. Aber was ich auf jeden Fall 561 00:28:16,240 --> 00:28:21,040 machen kann, ist zumindest auch Updates bewusst zu verzögern. 562 00:28:21,040 --> 00:28:24,480 So ein bisschen Zeit als Puffer reinzunehmen, weil was wir 563 00:28:24,480 --> 00:28:28,720 wirklich in den letzten Supply Chain Security Attacks gelernt 564 00:28:28,720 --> 00:28:32,880 haben ist, dass solche Dinge relativ schnell gefunden werden. 565 00:28:33,040 --> 00:28:36,560 Das bedeutet, immer wenn ich dann sage okay ich installiere. 566 00:28:36,680 --> 00:28:38,960 Verliere eine neue Version von einem Paket. 567 00:28:38,960 --> 00:28:44,320 Er ist nach 2448 Stunden oder noch länger, dann bin ich ganz 568 00:28:44,320 --> 00:28:47,440 häufig auch schon auf der sicheren Seite, weil bevor ich 569 00:28:47,440 --> 00:28:49,920 dann dieses Update installiere, ist eine entsprechende 570 00:28:49,920 --> 00:28:52,760 Verwundbarkeit auch schon bekannt und dann können 571 00:28:52,760 --> 00:28:56,240 natürlich auch Tools wie Depender Board mich entsprechend 572 00:28:56,320 --> 00:28:59,840 davor warnen die Dependency zu aktualisieren. 573 00:28:59,840 --> 00:29:04,080 Das Ganze kann ich in npm setzen über dieses Minimum Release age. 574 00:29:04,960 --> 00:29:08,000 Und damit kann ich dann festlegen, dass bestimmte Pakete 575 00:29:08,000 --> 00:29:11,120 einfach nicht installiert werden, wenn sie halt in einem 576 00:29:11,120 --> 00:29:14,480 kürzeren Zeitrahmen veröffentlicht wurden und kann 577 00:29:14,480 --> 00:29:17,280 damit schon vielleicht in Kombination mit dem, was du 578 00:29:17,280 --> 00:29:20,720 gerade gesagt hattest, mit reduziertem Angriffsvektor, in 579 00:29:20,720 --> 00:29:23,280 dem ich einfach die Anzahl der Bibliotheken, die ich nutze, 580 00:29:23,360 --> 00:29:25,760 reduziere, kann ich schon ganz viel verhindern. 581 00:29:26,640 --> 00:29:28,120 Ja, auf jeden Fall find ich n sehr guten Tipp. 582 00:29:28,120 --> 00:29:30,520 Wie gesagt, PNPM kann das schon irgendwie eingebaut mit diesem 583 00:29:30,520 --> 00:29:32,560 Minimum Release Age auch noch mal. 584 00:29:32,560 --> 00:29:34,880 Ich weiß nicht ob es alle schon machen, aber wenn ich zum 585 00:29:34,880 --> 00:29:38,000 Beispiel in meiner CICD Pakete nachinstalliere bei bei NPM. 586 00:29:38,480 --> 00:29:40,200 Oder bzw nicht Paket danach installiere, sondern einfach 587 00:29:40,200 --> 00:29:41,920 irgendwie sage ich mache einen npm install. 588 00:29:42,160 --> 00:29:44,680 Nee mache ich nicht, ich nehme bitte kein npm install in meiner 589 00:29:44,680 --> 00:29:48,520 cicd ich nehme npmci das steht nicht für Continuous 590 00:29:48,520 --> 00:29:51,440 Integration, sondern das steht für Clean Install oder wenn ich 591 00:29:51,440 --> 00:29:54,600 irgendwie Ban benutze, kann ich auch Ban install Frozen Logfile 592 00:29:54,800 --> 00:29:58,760 eingeben und das nutze ich statt npm install und das garantiert 593 00:29:58,760 --> 00:30:03,520 mir, dass die Gelockten package Versionen auch 1 zu 1 so. 594 00:30:03,920 --> 00:30:06,480 Verwendet werden und es versucht dann eben keine Ranges 595 00:30:06,480 --> 00:30:08,600 aufzulösen. Falls ich die oder meine 596 00:30:08,600 --> 00:30:11,600 Transitiven Dependences, die die sogar noch irgendwo haben, gibt 597 00:30:11,600 --> 00:30:14,720 mir also eine noch höhere Reproduzierbarkeit, dass genau 598 00:30:14,720 --> 00:30:18,800 das, was auch im Logfile steht, installiert wird und das will 599 00:30:18,800 --> 00:30:21,440 ich eigentlich auch haben, dass ich nicht irgendwie sage okay 600 00:30:21,600 --> 00:30:24,720 ich habe bei mir in einer Umgebung einen Scan gemacht, da 601 00:30:24,720 --> 00:30:26,400 ist alles safe und in der anderen Umgebung wird eine 602 00:30:26,400 --> 00:30:28,400 leicht andere Version von dem Paket dann doch irgendwie 603 00:30:28,400 --> 00:30:30,640 installiert und. Weil ich über npm in Stall 604 00:30:30,640 --> 00:30:33,000 mache. Ich weiß, wahrscheinlich hätte 605 00:30:33,000 --> 00:30:35,440 das vor ein paar Wochen alles noch sehr paranoid geklungen, 606 00:30:35,760 --> 00:30:38,840 aber jetzt zeigt tatsächlich hier dieser Wurm, wie relevant 607 00:30:38,840 --> 00:30:42,240 das eigentlich ist und dass wir uns zukünftig noch mehr Gedanken 608 00:30:42,240 --> 00:30:45,840 machen müssen, über wie wir unsere Umgebungen schützen und 609 00:30:45,840 --> 00:30:48,960 natürlich auch, wie wir uns von diesen leidigen Tokens, die 610 00:30:48,960 --> 00:30:52,240 natürlich immer wieder das Thema sind, verabschieden, und da 611 00:30:52,240 --> 00:30:55,080 müssen wir einfach gucken, dass wir da die Maintainer in Zukunft 612 00:30:55,080 --> 00:30:56,800 in die Pflicht nehmen oder beziehungsweise die Plattformen, 613 00:30:56,800 --> 00:30:59,000 die Maintainer in Zukunft in die in die Pflicht nehmen und. 614 00:30:59,360 --> 00:31:02,480 Und einfach sagen, es darf eigentlich gar kein Token mehr 615 00:31:02,480 --> 00:31:06,080 irgendwo rumfliegen auf meinem Rechner, der mir so einen großen 616 00:31:06,080 --> 00:31:08,920 Zugriff gibt, dass da jemand Fremdes quasi ein Update von 617 00:31:08,920 --> 00:31:11,520 einem Paket, was von 100 Tausenden Leuten verwendet wird, 618 00:31:12,560 --> 00:31:15,920 hochladen kann, oder dass überhaupt ich irgendwie von 619 00:31:15,920 --> 00:31:20,120 meinem Rechner aus in Token oder liegen kann, der dann jemand 620 00:31:20,120 --> 00:31:22,640 anderen von einem anderen Rechner aus nur mit diesem Token 621 00:31:22,800 --> 00:31:25,280 Zugriff auf meine Cloud Umgebung oder auf irgendwelche 622 00:31:25,280 --> 00:31:28,480 schützenswerten Sachen gibt. Ja, wir hatten es gerade schon 623 00:31:28,480 --> 00:31:31,560 gesagt, was da so die Best practices sind, betrifft 624 00:31:31,560 --> 00:31:35,280 wahrscheinlich nicht so viele von euch, die eigene Packages 625 00:31:35,280 --> 00:31:39,120 veröffentlichen, aber da ganz wichtig nur feingranulare, 626 00:31:39,120 --> 00:31:41,440 kurzlebige Tokens verwenden, wenn. 627 00:31:41,760 --> 00:31:44,720 Nichts anderes möglich ist für den eigenen Account auch 628 00:31:44,720 --> 00:31:47,560 multifaktor Authentifizierung, auch Phishing Resistant 629 00:31:47,560 --> 00:31:50,320 multifaktor Authentifizierung verwenden über zum Beispiel 630 00:31:50,320 --> 00:31:54,200 Paskeys oder andere sichere Systeme und damit kann ich dann 631 00:31:54,200 --> 00:31:57,840 natürlich auch als Maintainer und Publisher von solchen 632 00:31:58,000 --> 00:32:02,720 Paketen zur gesamten Sicherheit des Ökosystems beitragen, weil 633 00:32:02,720 --> 00:32:05,880 wir haben in der Vergangenheit gesehen irgendwie am Ende sind 634 00:32:05,880 --> 00:32:09,440 wir alle Menschen und auch für solche Phishing und Social 635 00:32:09,440 --> 00:32:11,640 Engineering Attacken irgendwo anfällig und. 636 00:32:12,000 --> 00:32:16,320 Und sobald dann jemand die Kontrolle über meine Credentials 637 00:32:16,320 --> 00:32:20,080 erlangt hat diese Person gegebenenfalls die Möglichkeit, 638 00:32:20,080 --> 00:32:22,960 extrem großen Schaden anzurichten und wir haben es ja 639 00:32:22,960 --> 00:32:26,080 jetzt in diesem Wurm gesehen. Man musste am Anfang nur ein 640 00:32:26,080 --> 00:32:29,600 Paket infizieren und hat sich dann entsprechend exponentiell 641 00:32:29,600 --> 00:32:33,360 verbreitet und innerhalb von wirklich sehr kurzer Zeit waren 642 00:32:33,360 --> 00:32:36,960 Hunderte von Projekte betroffen, weil halt alle diese Mantainer 643 00:32:36,960 --> 00:32:39,760 bestimmte Sicherheitsvorkehrungen leider 644 00:32:39,760 --> 00:32:41,640 nicht beachtet haben oder beachten konnten und. 645 00:32:42,240 --> 00:32:43,920 Ja, weil sie die eben auch nicht Pflicht sind. 646 00:32:43,920 --> 00:32:45,400 Und ich finde, das müssen wir jetzt viel mehr irgendwie 647 00:32:45,400 --> 00:32:47,200 machen. Das, das werde ich auch in den 648 00:32:47,200 --> 00:32:49,320 in den Teams, in denen ich arbeite, jetzt versuchen 649 00:32:49,320 --> 00:32:50,760 durchzusetzen, dass wir das als Standard machen. 650 00:32:50,760 --> 00:32:54,160 Ich will gar keine Tokens mehr sehen, gar keine Secrets mehr 651 00:32:54,160 --> 00:32:56,800 sehen, nirgendwo, es hat sich mit einer Identity 652 00:32:56,960 --> 00:33:00,320 authentifiziert zu werden gegenüber allem gegenüber meinem 653 00:33:00,320 --> 00:33:02,720 Git repository, aber auch innerhalb von meinem Git 654 00:33:02,720 --> 00:33:06,880 repository sollen meine, meine, meine cicd Pipelines keine 655 00:33:06,880 --> 00:33:09,240 Secrets mehr haben, mit denen sich gegen meine Cloud Umgebung 656 00:33:09,240 --> 00:33:11,640 oder in mein koboniertes Cluster einloggen, die haben. 657 00:33:11,760 --> 00:33:14,240 Auch eine Identity zu bekommen, das geht mittlerweile über 658 00:33:14,240 --> 00:33:16,160 Trusted Publishing bei vielen Providern. 659 00:33:16,160 --> 00:33:18,560 Da habe ich eben schon gesagt, gibt es eine Trust Relationship 660 00:33:18,560 --> 00:33:23,040 zwischen dem Runner, der meine cicd Pipeline ausführt und npm 661 00:33:23,040 --> 00:33:25,200 oder meinem Cloud Provider und so weiter das läuft über Oidc, 662 00:33:25,200 --> 00:33:28,640 also ein Teil von O aus. Und da wird dann einfach 663 00:33:28,640 --> 00:33:31,680 geguckt, dass die eine Identity bekommen und nur die dürfen dann 664 00:33:31,680 --> 00:33:33,280 auch zugreifen. Da kann ich auch ganz klar 665 00:33:33,280 --> 00:33:35,640 sagen, was haben die für Zugriffsrechte, das Gleiche hat 666 00:33:35,640 --> 00:33:37,760 für alle Deployments und sowas zu passieren. 667 00:33:37,920 --> 00:33:40,960 Also ich will eigentlich selbst gegen eine dev Umgebung auf 668 00:33:40,960 --> 00:33:44,280 meinem Rechner nicht ein einziges Secret, nicht einen 669 00:33:44,280 --> 00:33:47,040 einzigen API und nicht einen einzigen Token mehr sehen. 670 00:33:47,920 --> 00:33:51,080 Ja, ich meine, das hört sich jetzt so einfach an, aber häufig 671 00:33:51,080 --> 00:33:54,280 ist es natürlich so, dass wir auch im Alltag dann vielleicht 672 00:33:54,280 --> 00:33:57,280 den einfachsten Weg gehen, weil wir irgendwie in diesem. 673 00:33:57,960 --> 00:34:01,200 In diesem Spannungsfeld zwischen Produktivität und wir müssen wie 674 00:34:01,200 --> 00:34:04,600 schnell Ergebnisse liefern und dem Thema Security sind, das 675 00:34:04,600 --> 00:34:07,440 heißt, Wir haben auch teilweise so ein bisschen so eine Security 676 00:34:07,440 --> 00:34:09,920 Fatigue und ich meine, man kennt es ja auch aus dem privaten 677 00:34:09,920 --> 00:34:13,600 Umfeld und von sich selber, wenn man jetzt tatsächlich von immer 678 00:34:13,600 --> 00:34:16,760 mehr online Plattformen aufgefordert wird, multifaktor 679 00:34:16,760 --> 00:34:19,840 Authentifizierung einzurichten und dann fragt man sich ja, 680 00:34:19,840 --> 00:34:23,199 warum brauche ich das denn jetzt auf meinem github Account und 681 00:34:23,199 --> 00:34:26,800 dann merkt man tatsächlich okay wenn ich das nicht habe, kann 682 00:34:26,800 --> 00:34:29,199 vielleicht jemand relativ. Schnell über einen einfachen 683 00:34:29,199 --> 00:34:32,719 Token die volle Kontrolle über meinen Account übernehmen, weil 684 00:34:32,719 --> 00:34:35,520 ich dort keine multifaktor Authentifizierung hinterlegt 685 00:34:35,520 --> 00:34:38,239 habe und von daher ist es, glaube ich ganz wichtig, dass 686 00:34:38,239 --> 00:34:42,800 wir da auch alle sagen okay, wir müssen Security da ein bisschen 687 00:34:42,800 --> 00:34:45,840 stärker priorisieren. Ja, und aber auch noch mal. 688 00:34:45,840 --> 00:34:47,440 Das sind natürlich auch 2 verschiedene Dinge. 689 00:34:47,440 --> 00:34:49,480 Ich kann ja durchaus 2 Faktor Authentifizierung auf meinem 690 00:34:49,480 --> 00:34:51,280 Gitter Account haben und wir trotzdem so einen langlebigen 691 00:34:51,280 --> 00:34:53,280 Token erstellen, mit dem ich dann irgendwelche Sachen machen 692 00:34:53,280 --> 00:34:55,440 kann und ich glaube das müssen wir halt vor allem auch noch mal 693 00:34:55,440 --> 00:34:57,840 deaktivieren und irgendwie sagen, es für bestimmte Dinge, 694 00:34:57,840 --> 00:35:00,720 das Macht der Gitter manchmal schon für bestimmte Aktionen auf 695 00:35:00,720 --> 00:35:02,560 der Gitter Plattform fordert es mich dann noch mal auf. 696 00:35:02,560 --> 00:35:04,240 Hey kannst du dafür vielleicht noch mal kurz deinen zweiten 697 00:35:04,240 --> 00:35:09,360 Faktor rausholen und ja. Trotzdem kann ich ja irgendwie 698 00:35:09,360 --> 00:35:11,440 so einen langlebigen Token erstellen, der niemals abläuft 699 00:35:11,440 --> 00:35:13,920 oder irgendwie erst in 2 Jahren abläuft und sowas, aber ich kann 700 00:35:13,920 --> 00:35:16,480 das schon verstehen irgendwie, wir müssen, ich glaube wir 701 00:35:16,480 --> 00:35:18,840 müssen da dann nicht nur so ein Verständnis für schaffen, wie 702 00:35:18,840 --> 00:35:20,840 wir das jetzt mit dieser Podcast Folge versuchen, sondern es muss 703 00:35:20,840 --> 00:35:23,120 auch irgendwie einfacher und convenient sein und da müssen 704 00:35:23,120 --> 00:35:26,240 die Plattformen eben ran, dass es eben ganz einfach ist, dass 705 00:35:26,240 --> 00:35:29,520 man sich da ohne API Key, sondern einfach durch durch den 706 00:35:29,520 --> 00:35:33,760 Login Mechanismus anmelden kann, dass eben diese Tokens auch 707 00:35:33,760 --> 00:35:35,800 quasi nur eine bestimmte Laufzeit bekommen und dass es 708 00:35:35,800 --> 00:35:37,200 mir ein bisschen schwieriger gemacht wird. 709 00:35:37,600 --> 00:35:41,040 Da so einen Token zu kriegen, der so viel darf und dass ich 710 00:35:41,040 --> 00:35:43,120 eigentlich das ist, und das hat der github so ein bisschen 711 00:35:43,120 --> 00:35:44,960 gesagt, dass sie da jetzt noch mal ein extra Augenmerk drauf 712 00:35:44,960 --> 00:35:48,840 legen, dass ich eigentlich über diese diese Trusted Publishing 713 00:35:48,840 --> 00:35:52,560 approaches und so was gehe und in der Cloud mit einer Identität 714 00:35:52,960 --> 00:35:56,120 arbeite, und wir müssen uns natürlich auch Gedanken drüber 715 00:35:56,120 --> 00:35:58,960 machen, wie wir Maintainer von Open Source Projekten, die ja 716 00:35:58,960 --> 00:36:02,480 ganz, ganz viel einfach in ihrer Freizeit und teilweise unbezahlt 717 00:36:02,480 --> 00:36:04,640 oder nur ganz ganz niedrig bezahlt. 718 00:36:06,040 --> 00:36:09,320 Irgendwie so Ultra große Projekte mit ja mit 100 719 00:36:09,320 --> 00:36:12,080 Tausenden von von Downloads, wie wir die vielleicht besser 720 00:36:12,080 --> 00:36:14,040 unterstützen, das hatten wir ja schon mal gesagt, wir haben ja 721 00:36:14,040 --> 00:36:17,680 schon mal eine Folge zu XC utils gemacht, da ging es ja auch so 722 00:36:17,680 --> 00:36:20,480 um dieses dieses Stichwort, irgendwie maintainer Burnout, da 723 00:36:20,480 --> 00:36:23,560 wurde ja auch mit so viel Social Engineering und Druck gearbeitet 724 00:36:23,560 --> 00:36:26,640 auf diesen armen Kleinen, einen Maintainer, der so ein riesen 725 00:36:26,640 --> 00:36:30,400 Linux Paket was ultra wichtig in fast allen Distributionen drin 726 00:36:30,400 --> 00:36:34,080 war Maintaint hat und ich glaube wir müssen uns hier wieder 727 00:36:34,080 --> 00:36:38,240 einmal die Frage stellen. Ob unser Ökosystem nicht 728 00:36:38,240 --> 00:36:41,360 irgendwo systematische Fehler eingebaut hat, die es einfach 729 00:36:41,360 --> 00:36:43,440 sehr anfällig für solche Probleme machen. 730 00:36:44,320 --> 00:36:47,680 Ja, es gibt ja diesen Cartoon, den kennen wahrscheinlich viele 731 00:36:47,680 --> 00:36:52,400 von euch, wo tatsächlich dieses riesige Gerüst von komplexer 732 00:36:52,400 --> 00:36:56,080 Anwendung auf den Schultern von einem kleinen Retainer. 733 00:36:56,560 --> 00:36:59,760 Der eine kleine Komponente im Entaint liegt. 734 00:36:59,840 --> 00:37:02,680 Und tatsächlich ist es ja in der Realität so, wenn man sich 735 00:37:02,680 --> 00:37:05,840 gerade so ein bisschen diesen Dependency Tree anschaut von 736 00:37:05,840 --> 00:37:10,080 vielen der npm Pakete gibt es bestimmte Pakete, die immer. 737 00:37:10,360 --> 00:37:12,720 Und immer wieder als Dependency auftauchen. 738 00:37:12,960 --> 00:37:16,560 Und die sind natürlich der größtmögliche Angriffsvektor, 739 00:37:16,560 --> 00:37:20,480 auch um solche Supply Chain Attacken durchzuführen. 740 00:37:20,640 --> 00:37:23,920 Und da ist es natürlich wichtig zu schauen, okay können wir auch 741 00:37:23,920 --> 00:37:27,360 diesen Maintainern von diesen kritischen Projekten helfen, da 742 00:37:27,360 --> 00:37:29,840 gibt es verschiedene Möglichkeiten, es gibt halt 743 00:37:29,840 --> 00:37:32,720 irgendwie ein Sponsoring, was man vielleicht für ein Gitter 744 00:37:32,720 --> 00:37:35,560 propository für ein Projekt machen kann, man kann natürlich 745 00:37:35,560 --> 00:37:38,760 auch selber sich einbringen, wenn man die Zeit und die 746 00:37:38,760 --> 00:37:41,040 Kompetenzen hat. Aber ich glaube, es ist ganz 747 00:37:41,040 --> 00:37:43,920 wichtig, dass man da auch ein gewisses Bewusstsein für 748 00:37:43,920 --> 00:37:47,920 entwickelt, wie groß auch am Ende die Last auf teilweise 749 00:37:47,920 --> 00:37:50,720 einzelnen liegt, weil man denkt, so immer. 750 00:37:51,160 --> 00:37:52,440 Irgendwie so ein Open Source Projekt. 751 00:37:52,440 --> 00:37:54,240 Da arbeiten immer ganz viele dran. 752 00:37:54,480 --> 00:37:57,840 Aber selbst wenn irgendwie ganz viele Ideen beisteuern, häufig 753 00:37:57,840 --> 00:38:01,600 sind es irgendwie ein 2 Leute, die dann alle diese PRS reviewen 754 00:38:01,600 --> 00:38:04,160 die ganzen Ideen durchgehen müssen und auf denen dann 755 00:38:04,160 --> 00:38:07,760 letzten Endes auch die Last liegt, irgendwie ein stabiles 756 00:38:07,760 --> 00:38:11,400 Produkt bereitzustellen und genau diese Leute brauchen die 757 00:38:11,400 --> 00:38:14,000 Unterstützung, damit halt auch keine menschlichen Fehler 758 00:38:14,000 --> 00:38:16,120 passieren, weil die Leute halt einfach überlastet sind, weil 759 00:38:16,120 --> 00:38:18,880 sie vielleicht auch noch einen Dayjob haben und dann irgendwie 760 00:38:18,880 --> 00:38:21,520 abends noch. Dann die ganzen PRS Reviews, 761 00:38:21,520 --> 00:38:23,840 müssen die halt irgendwelche Leute in ihrem Projekt gestellt 762 00:38:23,840 --> 00:38:26,080 haben und da rutscht dann auch mal schnell was durch. 763 00:38:28,640 --> 00:38:30,600 Okay Fazit Was heißt das denn jetzt? 764 00:38:30,640 --> 00:38:34,800 Wir haben gesagt, ganz klar, 3 konkrete Handlungsempfehlungen, 765 00:38:35,520 --> 00:38:39,520 das eine sofort past Keys 2 Faktor Authentifizierung, also 766 00:38:39,520 --> 00:38:42,240 Fishing secur 2 Faktor Authentifizierung, also nicht 767 00:38:42,240 --> 00:38:45,320 diesen komischen sechsstelligen Zahlencode, den kann man nämlich 768 00:38:45,320 --> 00:38:48,200 fischen, sondern wirklich sowas wie Web own oder past Keys 769 00:38:48,200 --> 00:38:53,440 aktivieren das. Zweitens npmci anstatt npm 770 00:38:53,440 --> 00:38:57,400 install in euren cicd Pipelines verwenden und eigentlich mal 771 00:38:57,400 --> 00:39:00,800 drüber nachdenken, ob man nicht dieses Signor Scripts einführt 772 00:39:01,040 --> 00:39:03,600 und wahrscheinlich am allerwichtigsten versucht 773 00:39:04,080 --> 00:39:05,360 irgendwelche Tokens zu verbannen. 774 00:39:05,360 --> 00:39:08,640 Wir haben es jetzt 100 mal schon gesagt, Trusted Publishing ist 775 00:39:08,640 --> 00:39:12,800 hier das Stichwort, gibt das Mal ein Trusted Publishing plus der 776 00:39:12,800 --> 00:39:17,280 Name von eurer Cicd Plattform und das Mal einführen und 777 00:39:17,280 --> 00:39:18,760 übernehmen. Und. 778 00:39:18,800 --> 00:39:22,080 Und wir haben auch gelernt, dass Sicherheit eine gemeinsame 779 00:39:22,080 --> 00:39:25,120 Verantwortung ist, also sowohl von denen, die diese Plattform 780 00:39:25,120 --> 00:39:29,000 wie NPM anbieten, als auch den Maintainern, die die Pakete dort 781 00:39:29,000 --> 00:39:32,240 veröffentlichen und von uns als Development, die das Ganze 782 00:39:32,240 --> 00:39:35,600 einsetzen. Und nur wenn hier alle Ihre 783 00:39:35,600 --> 00:39:39,040 Aufgabe erledigen, können wir das Ökosystem sicherer machen 784 00:39:39,280 --> 00:39:42,000 und wir haben gesehen, ganz viele arbeiten da jetzt dran, 785 00:39:42,000 --> 00:39:44,200 wir haben auch einige Links in den Shownotes, wo ihr einfach 786 00:39:44,200 --> 00:39:47,520 noch mal reingehen könnt und schauen könnt, was ihr in eurer 787 00:39:47,520 --> 00:39:50,480 Rolle jetzt macht. Machen könnt und was ihr machen 788 00:39:50,480 --> 00:39:54,000 solltet, um halt euren Beitrag zu leisten. 789 00:39:55,360 --> 00:39:58,160 Und noch mal als Abschlussappell alles rotieren. 790 00:39:58,400 --> 00:40:00,400 Wir gehen jetzt einfach mal alle davon aus, dass wir davon 791 00:40:00,400 --> 00:40:01,440 betroffen sind. Es ist auch kein 792 00:40:01,520 --> 00:40:04,600 Wahnsinnsaufwand, mal ein paar Tokens und Secrets zu rotieren, 793 00:40:04,600 --> 00:40:06,160 kann man sich immer daran gewöhnen das ab und zu zu 794 00:40:06,160 --> 00:40:09,840 machen, wachsam bleiben, mal alle Abhängigkeiten prüfen, wie 795 00:40:09,840 --> 00:40:12,040 gesagt, es gibt eine lange Liste von Jfrog, die ist unten in den 796 00:40:12,040 --> 00:40:14,840 Shownotes. Und bitte, bitte, bitte nochmal 797 00:40:14,840 --> 00:40:18,240 der Pell Sicherheit als ganz festen Bestandteil von so einem 798 00:40:18,240 --> 00:40:20,320 Development Prozess begreifen. Ich glaube es hat uns wieder 799 00:40:20,320 --> 00:40:23,280 einmal gezeigt, dass jeder einzelne Developer, jede 800 00:40:23,280 --> 00:40:25,920 einzelne Entwicklerin, jeder einzelne Entwickler betroffen 801 00:40:25,920 --> 00:40:27,920 sein kann, dem man sich einfach so ein Paket auch nur zu der 802 00:40:27,920 --> 00:40:30,640 Laufzeit reinholt und dann vielleicht einen ganz woanders 803 00:40:30,640 --> 00:40:34,360 gespeicherten Token liegt und ist natürlich jetzt irgendwie 804 00:40:34,360 --> 00:40:38,000 eine schwere ernste Folge, wenig Spaß, wenig Gelächter, wenig 805 00:40:38,000 --> 00:40:40,240 Gelächter diese Podcast Folge, aber ich glaube ein ganz 806 00:40:40,240 --> 00:40:43,840 wichtiges Thema und. Wie gesagt, eigentlich hätte man 807 00:40:43,840 --> 00:40:45,520 sich schon vor 2 Wochen wahrscheinlich damit befassen 808 00:40:45,520 --> 00:40:47,320 und darum kümmern müssen, wenn ich es noch nicht getan habe. 809 00:40:47,320 --> 00:40:50,240 Ganz, ganz, ganz, ganz dringend machen und dann geht es auch 810 00:40:50,240 --> 00:40:51,920 wieder weiter und ich glaube da kann man auch mit einem guten 811 00:40:51,920 --> 00:40:53,920 Gewissen, wenn man die ganzen Sachen umgesetzt hat, 812 00:40:54,400 --> 00:40:56,520 weitermachen und denken Ach guck mal, fühlt sich doch auch 813 00:40:56,520 --> 00:40:59,200 irgendwie besser an zu wissen, ich habe hier keine Talkings 814 00:40:59,200 --> 00:41:01,920 rumfliegen, mein Code ist sicher, mein Projekt ist sicher 815 00:41:01,920 --> 00:41:04,880 aufgesetzt. Und von daher hoffen wir auch, 816 00:41:04,880 --> 00:41:07,600 dass euch die Folge weiter gebracht hat, dass ihr ein 817 00:41:07,600 --> 00:41:11,680 bisschen besseres Verständnis für diesen Wurm entwickelt habt, 818 00:41:11,680 --> 00:41:13,680 dass ihr ein bisschen hinter die Kulissen schauen konntet, 819 00:41:13,680 --> 00:41:17,280 gemeinsam mit uns und wenn euch die Folge gefallen hat, dann 820 00:41:17,280 --> 00:41:21,040 lasst uns bitte eine positive Bewertung da auf Spotify oder 821 00:41:21,040 --> 00:41:23,800 Apple Podcast. Wir freuen uns immer sehr und es 822 00:41:23,800 --> 00:41:27,040 hilft natürlich auch, dass der Podcast von anderen gefunden 823 00:41:27,040 --> 00:41:28,560 wird und. Wir freuen uns natürlich auch 824 00:41:28,560 --> 00:41:30,880 sehr, wenn ihr Lust habt, uns einen Kaffee auszugeben. 825 00:41:31,520 --> 00:41:34,640 Da findet ihr einen Link zu bei mir Coffee unten in den 826 00:41:34,640 --> 00:41:36,440 Shownotes zusammen mit allen anderen Links, die wir da für 827 00:41:36,440 --> 00:41:39,160 Euch zusammengetragen haben. Oder wenn ihr sogar vielleicht 828 00:41:39,160 --> 00:41:42,480 zu eurem eigenen Kaffee die Podcast Gebrandete Nerd Tasse 829 00:41:42,480 --> 00:41:44,480 haben wollt. Wir haben einen kleinen Fanshop, 830 00:41:44,520 --> 00:41:46,880 da könnt ihr natürlich auch mal vorbeigucken, links zu allem 831 00:41:46,880 --> 00:41:49,320 gibt es in der Beschreibung und ansonsten gibt es nächsten 832 00:41:49,320 --> 00:41:52,520 Montag eine neue Podcast Folge, denn der To do Cast der 833 00:41:52,520 --> 00:41:55,440 erscheint jede Woche, jeden Montag immer abwechselnd in 834 00:41:55,440 --> 00:41:57,800 einer Themenfolge wie dieser hier oder einer News folge, wo 835 00:41:57,800 --> 00:42:00,800 wir so ein bisschen die News der letzten 2 Wochen zusammentragen. 836 00:42:01,120 --> 00:42:02,800 Hört also auch nächste Woche wieder rein. 837 00:42:03,040 --> 00:42:06,720 Bis dahin, schreibt viel Code, schreibt vor allem sicheren Code 838 00:42:06,720 --> 00:42:09,240 und konfiguriert euer Codeprojekt sicher und bis 839 00:42:09,240 --> 00:42:10,480 nächste Woche. Bis bald. 840 00:42:10,800 --> 00:42:11,280 Bis bald.