1
00:00:00,400 --> 00:00:03,360
Stell dir vor, du installierst 
ein offizielles, legitimes 

2
00:00:03,360 --> 00:00:06,160
Package und plötzlich sind deine
Credentials in den Händen von 

3
00:00:06,160 --> 00:00:08,800
Kriminellen. 
Und genau das ist das Perfide an

4
00:00:08,800 --> 00:00:12,000
Supply Chain angriffen. 
In dieser Folge sprechen wir 

5
00:00:12,000 --> 00:00:15,360
darüber, wie Angreifer, 
Maintainer, Bildprozesse oder 

6
00:00:15,360 --> 00:00:19,120
Paketquellen ausnutzen, welche 
Angriffsmuster wie zum Beispiel 

7
00:00:19,120 --> 00:00:21,440
Type Scorting bis hinzu 
kompromittierten Release 

8
00:00:21,440 --> 00:00:24,640
Pipelines existieren und. 
Und was wir als developer oder 

9
00:00:24,640 --> 00:00:28,280
als Unternehmen realistisch 
dagegen tun können und gibt es 

10
00:00:28,280 --> 00:00:31,520
so etwas wie die sichere Supply 
Chain überhaupt noch? 

11
00:00:36,480 --> 00:00:39,760
Hallo zusammen und ganz herzlich
willkommen zu einer ganz neuen 

12
00:00:39,760 --> 00:00:43,360
Folge vom To do Cast, dem 
Developer Podcast auf Deutsch 

13
00:00:43,360 --> 00:00:46,080
mit Malte Lantin. 
Der ist Strategic Solutions 

14
00:00:46,080 --> 00:00:49,040
Engineer bei github. 
Und mit mir Robin, Manuel Thiel.

15
00:00:49,040 --> 00:00:52,600
Ich bin Director für AI und 
Cloud beim E Commerce Software 

16
00:00:52,600 --> 00:00:55,040
Unternehmen Jtl. 
Den Podcast hier machen wir aber

17
00:00:55,040 --> 00:00:57,600
privat in unserer Freizeit 
sprechen wir aber natürlich über

18
00:00:57,600 --> 00:00:59,400
ultrarelevante Themen, die wir 
auch beide so ein bisschen aus 

19
00:00:59,400 --> 00:01:02,720
dem Berufsleben kennen und die 
Developer Welt bewegen und die 

20
00:01:02,720 --> 00:01:05,600
wir aus Kundenprojekten 
diskutieren und ein Thema, was 

21
00:01:05,600 --> 00:01:07,960
wir natürlich gerade auch hier 
in diesem Podcast in den letzten

22
00:01:07,960 --> 00:01:10,560
News folgen und daraus 
resultierend auch viel mit 

23
00:01:10,560 --> 00:01:14,000
unseren. 
Kunden und Mitarbeitenden 

24
00:01:14,000 --> 00:01:18,400
diskutiert haben, ist das Thema 
Supply Chain Attacks. 

25
00:01:18,400 --> 00:01:20,960
Wir haben es immer wieder 
gesehen, wir können uns heute 

26
00:01:20,960 --> 00:01:23,360
fast schon nicht mehr so richtig
darauf verlassen, dass das, was 

27
00:01:23,360 --> 00:01:30,400
wir da über npm Jahren pnpm 
install oder über Python oder 

28
00:01:30,400 --> 00:01:33,600
über New Get Pakete 
installieren, denn wirklich 

29
00:01:33,600 --> 00:01:36,080
eigentlich sicher ist und nicht 
nicht Schadcode ist oder 

30
00:01:36,080 --> 00:01:38,640
vielleicht auch mal sicher war 
und auf einmal zu Schadcode wird

31
00:01:38,880 --> 00:01:40,800
und darüber sprechen wir diese 
Folge. 

32
00:01:41,280 --> 00:01:44,080
Tatsächlich kam der Wunsch 
explizit von euch, die ihr 

33
00:01:44,080 --> 00:01:45,880
zuhört. 
Also wir haben da zahlreiche E 

34
00:01:45,880 --> 00:01:48,000
Mails und Nachrichten bekommen, 
vielleicht noch mal tiefer in 

35
00:01:48,000 --> 00:01:51,080
das Thema einzusteigen und 
gerade diese Interaktion ist 

36
00:01:51,080 --> 00:01:54,760
super wertvoll und eine 
wertvolle Interaktion für uns 

37
00:01:54,760 --> 00:01:57,680
ist natürlich auch wenn ihr uns 
einen Kaffee ausgebt und da 

38
00:01:57,680 --> 00:02:01,360
haben wir zahlreiche von euch 
wieder tief in die Tasche 

39
00:02:01,360 --> 00:02:04,960
gegriffen und uns mit Koffein 
versorgt und zwar haben wir 2 

40
00:02:04,960 --> 00:02:09,680
Kaffee von Felix, 2 Kaffee von 
Nicole und einen Kaffee von 

41
00:02:09,759 --> 00:02:12,320
Matthias. 
Ganz, ganz herzlichen Dank. 

42
00:02:12,800 --> 00:02:15,520
Ja, steigen wir ein ins Thema 
und wie muss man sich das 

43
00:02:15,520 --> 00:02:18,480
vorstellen? 
Ich habe auf einmal lese ich 

44
00:02:18,480 --> 00:02:22,960
irgendwo hier das allerneueste 
axeos Paket ist kompromittiert 

45
00:02:22,960 --> 00:02:25,240
und das muss ich irgendwie aktiv
werden, Leute sprechen darüber 

46
00:02:25,240 --> 00:02:27,120
unter anderem auch in Podcast, 
so wie diesem hier. 

47
00:02:28,000 --> 00:02:30,640
Das ist eigentlich so wie stell 
dir vor, du würdest ein 

48
00:02:30,640 --> 00:02:33,720
Sternerestaurant betreiben und 
ganz plötzlich ändert sich die 

49
00:02:33,720 --> 00:02:37,360
Qualität deiner Speisen, obwohl 
du eigentlich wie immer im 

50
00:02:37,360 --> 00:02:39,600
Großmarkt einkaufst. 
Auch beim gleichen Händler 

51
00:02:39,600 --> 00:02:42,400
dieselben Tomaten und der es dir
vielleicht auch nicht erklären 

52
00:02:42,400 --> 00:02:45,760
kann und der die Tomaten 
vielleicht irgendwo her bezieht,

53
00:02:45,760 --> 00:02:48,160
wo der sich eigentlich auch 
immer sicher ist und irgendwo in

54
00:02:48,160 --> 00:02:50,880
dieser Kette von den Dingen, die
du gar nicht kontrollieren 

55
00:02:50,880 --> 00:02:53,520
kannst. 
Hat sich irgendwas 

56
00:02:53,680 --> 00:02:57,200
reingeschleust, was jetzt auf 
einmal die Qualität einer Speise

57
00:02:57,200 --> 00:03:00,240
nach unten bringt, irgendwelche 
faulen Tomaten oder sowas und so

58
00:03:00,240 --> 00:03:02,800
ein bisschen, so muss man sich 
das vorstellen. 

59
00:03:02,880 --> 00:03:05,920
Wenn ich meine Software baue und
gar nicht jede einzelne Zeile 

60
00:03:05,920 --> 00:03:08,000
Code die dann verwendet wird, 
selber geschrieben ist, sondern 

61
00:03:08,000 --> 00:03:11,920
mir natürlich, wie wir das alle 
machen Hete reingeholt habe über

62
00:03:11,920 --> 00:03:16,960
Pip install, npm install und so 
weiter und plötzlich explodiert 

63
00:03:16,960 --> 00:03:19,600
oder implodiert ja eigentlich 
alles von innen heraus. 

64
00:03:20,080 --> 00:03:22,040
Der gefährlichste Angriff, den 
wir heute eigentlich in der 

65
00:03:22,040 --> 00:03:24,440
Softwareentwicklung haben, ist 
nicht mehr der, der unsere 

66
00:03:24,440 --> 00:03:27,320
Rechner von innen hackt oder 
unsere Firewall umgeht, sondern 

67
00:03:27,320 --> 00:03:30,560
den, den wir uns selber in unser
System installieren. 

68
00:03:30,560 --> 00:03:33,960
Über die Supply Chain und was 
wir dagegen tun können, wie wir 

69
00:03:33,960 --> 00:03:36,200
uns schützen können und ob wir 
uns überhaupt schützen können, 

70
00:03:36,200 --> 00:03:38,720
ist so ein bisschen Thema der 
Folge, doch ich würde sagen, 

71
00:03:38,720 --> 00:03:41,840
bevor wir einsteigen, lass uns 
mal ganz kurz zusammenkratzen, 

72
00:03:42,000 --> 00:03:44,720
was ist denn eigentlich 
überhaupt die Software Supply 

73
00:03:44,720 --> 00:03:47,800
Chain, damit wir hier alles, 
damit wir alle von der gleichen 

74
00:03:47,800 --> 00:03:50,320
Sache reden. 
Ja, und ich glaube, das ist 

75
00:03:50,320 --> 00:03:53,320
wichtig, dass wir das alle 
verstehen und auch die 

76
00:03:53,320 --> 00:03:55,920
entsprechenden Maßnahmen kennen,
weil es ist ja eigentlich 

77
00:03:55,920 --> 00:03:58,360
schlimmer, als du es gerade 
sogar beschrieben hattest. 

78
00:03:58,360 --> 00:04:00,960
Du hast gesagt, okay, dann wird 
die Qualität schlechter in 

79
00:04:00,960 --> 00:04:02,760
deinem Restaurant. 
Nein, die Qualität wird nicht 

80
00:04:02,760 --> 00:04:04,880
schlechter, da sterben 
vielleicht plötzlich Menschen, 

81
00:04:04,880 --> 00:04:08,400
weil dann irgendwie die Zutaten 
vergiftet sind und genauso kann 

82
00:04:08,400 --> 00:04:11,600
es natürlich bei dir sein, wenn 
deine Software Supply Chain 

83
00:04:11,600 --> 00:04:14,480
kompromittiert ist, dass 
irgendwie deine Software selber 

84
00:04:14,800 --> 00:04:18,079
irgendwie zur Malware 
umfunktioniert wird und das 

85
00:04:18,079 --> 00:04:21,240
wollen wir natürlich in. 
In jedem Fall verhindern und du 

86
00:04:21,240 --> 00:04:23,880
hattest gerade gesagt, wir 
schreiben seit vielen Jahren 

87
00:04:23,880 --> 00:04:27,040
nicht mehr jede Zeile Code in 
unserer Applikation selber, 

88
00:04:27,200 --> 00:04:30,080
sondern bauen auf einem ganz 
großen Eco System auf. 

89
00:04:30,320 --> 00:04:34,200
Und dieses gesamte Eco System 
ist die Software Lieferkette, 

90
00:04:34,200 --> 00:04:37,840
also die Software Supply Chain. 
Da gehört natürlich dein eigener

91
00:04:37,840 --> 00:04:40,800
Quellcode dazu, also das was du 
geschrieben hast. 

92
00:04:40,960 --> 00:04:44,720
Aber all die Third Party Pakete 
die du Reinziehst über die von 

93
00:04:44,720 --> 00:04:48,320
dir gerade genannten Package 
Manager oder manuell. 

94
00:04:48,880 --> 00:04:52,160
Einlädst, vielleicht irgendwie 
zugekauft hast und 

95
00:04:52,320 --> 00:04:55,560
dementsprechend gehören dazu 
natürlich auch andere Menschen, 

96
00:04:55,560 --> 00:04:57,280
die an diesen Produkten 
arbeiten. 

97
00:04:57,280 --> 00:04:59,760
Das können Firmen sein, das 
Können Open Source maintainer 

98
00:04:59,760 --> 00:05:04,480
sein, das können diese einsamen 
Hero Maintainer sein, die ganz 

99
00:05:04,480 --> 00:05:07,520
alleine irgendwie so ein ganz 
wichtiges Open Source Paket 

100
00:05:07,680 --> 00:05:10,760
selber über viele Jahre 
maintainen und. 

101
00:05:11,120 --> 00:05:14,520
Und dann entsprechend der 
Community bereitstellen und 

102
00:05:14,520 --> 00:05:17,600
diese Bereitstellung, die läuft 
über Package registrys. 

103
00:05:17,600 --> 00:05:20,080
Wir haben in der Vergangenheit 
ganz oft über Supply Chain 

104
00:05:20,080 --> 00:05:25,120
Security gesprochen, rund um 
npm, was natürlich im Java 

105
00:05:25,120 --> 00:05:29,280
Script und Node ekosystem der 
Package Manager der Wahl 

106
00:05:29,600 --> 00:05:35,200
zumindest heute ist und über den
viele Data Angriffe letzten 

107
00:05:35,200 --> 00:05:39,200
Endes auch verteilt wurden. 
Ich glaube bei diesem Verteilen,

108
00:05:39,200 --> 00:05:42,000
da kann teilweise dann schon das
Problem stattfinden. 

109
00:05:42,000 --> 00:05:44,640
Es ist heute gar nicht mehr 
unbedingt nur so, dass dann die 

110
00:05:44,640 --> 00:05:48,640
Software zur Laufzeit, wenn sie 
ausgeführt wird, diesen 

111
00:05:48,640 --> 00:05:50,800
Schadcode beinhaltet, sondern 
häufig ist es einfach schon, 

112
00:05:50,800 --> 00:05:53,720
dass wir, während wir diese 
Pakete runterladen, diese Pakete

113
00:05:53,720 --> 00:05:58,240
dann über sogenannte Post 
Install Hooks noch weitere Dinge

114
00:05:58,240 --> 00:06:00,560
auf unserer Maschine tun. 
Das ist auch eigentlich erstmal 

115
00:06:00,560 --> 00:06:02,800
so gewollt, es gibt bestimmte 
Pakete, die dann einfach Dateien

116
00:06:02,800 --> 00:06:05,840
vor allem nach B kopieren oder 
bestimmte Dinge vorbereiten. 

117
00:06:06,440 --> 00:06:10,560
Und darüber kommt schon oft 
problematischer Code in unsere 

118
00:06:10,560 --> 00:06:13,280
Produkte quasi gar nicht mehr 
unbedingt in das Produkt, was 

119
00:06:13,280 --> 00:06:15,440
wir am Ende ausliefern, sondern 
auf die Maschinen, auf denen wir

120
00:06:15,440 --> 00:06:17,360
bauen. 
Und damit kommen wir auch schon 

121
00:06:17,360 --> 00:06:20,320
dann zum nächsten Teil der 
Software Supply Chainsen nämlich

122
00:06:20,320 --> 00:06:23,480
auch die Maschinen, auf denen 
wir bauen, das heißt, der ganze 

123
00:06:23,480 --> 00:06:25,840
cicd Prozess. 
Er ist natürlich auch Teil 

124
00:06:26,000 --> 00:06:28,640
unserer Software Supply Chain. 
Glaub alles, was wir darauf tun,

125
00:06:28,640 --> 00:06:31,680
nämlich zum Beispiel das 
Signieren unserer Software, das 

126
00:06:31,680 --> 00:06:34,560
eigentliche Releasen, also den 
Prozess, dann diese, das 

127
00:06:34,560 --> 00:06:36,560
Kompilat irgendwohin zu 
kopieren, in einen 

128
00:06:36,560 --> 00:06:40,120
Dockercontainer zum Beispiel und
den in ein ja vielleicht 

129
00:06:40,120 --> 00:06:43,120
kobiniertes Cluster zu deployen,
sodass diese Version dann live 

130
00:06:43,120 --> 00:06:45,280
ist. 
Aber natürlich auch unsere 

131
00:06:45,280 --> 00:06:48,240
lokalen Developer Maschinen. 
Die sind auch häufig unter 

132
00:06:48,240 --> 00:06:53,560
anderem Ziel dieser Angriffe 
sind genauso wie die Buildserver

133
00:06:53,560 --> 00:06:56,960
natürlich dann sehr relevante 
Dinge, denn da findet man als 

134
00:06:56,960 --> 00:07:02,880
Angreifer häufig Secrets, 
Passwörter, langlebige Tokens, 

135
00:07:03,200 --> 00:07:06,880
private Keys und. 
Und die werden dann oft Ziel 

136
00:07:06,880 --> 00:07:09,040
einer solchen Supply Chain 
Attacke. 

137
00:07:09,200 --> 00:07:11,320
Dadurch, dass ich mir ein Paket 
herunterladen, entweder die 

138
00:07:11,320 --> 00:07:14,680
Software bei mir lokal ausführe 
und beim Ausführen dann 

139
00:07:14,680 --> 00:07:17,400
irgendwas passiert oder sogar 
schon beim Herunterladen dieser 

140
00:07:17,400 --> 00:07:20,240
Pakete. 
Wir haben, das zeigt, wie lang 

141
00:07:20,240 --> 00:07:23,520
diese Lieferkette inzwischen 
geworden ist und wie viele 

142
00:07:23,520 --> 00:07:27,360
Komponenten dort enthalten sind,
die entsprechend angegriffen 

143
00:07:27,360 --> 00:07:30,680
werden können. 
Und jeder dieser Punkte kann 

144
00:07:30,680 --> 00:07:33,440
irgendwie attackiert werden und 
ein Einfallstor für 

145
00:07:33,440 --> 00:07:35,600
entsprechende Schadsoftware 
werden. 

146
00:07:35,760 --> 00:07:38,640
Und wir haben ja in dieser Kette
so ein bisschen so eine 

147
00:07:38,640 --> 00:07:42,240
Vertrauenskette, das heißt? 
Um in deinem Beispiel vom Anfang

148
00:07:42,240 --> 00:07:45,080
zu bleiben, du als 
Restaurantbetreiber vertraust, 

149
00:07:45,080 --> 00:07:48,200
dem Großhändler der Großhändler 
vertraut wiederum seinen 

150
00:07:48,200 --> 00:07:52,600
Lieferanten, und die Vertrauen 
ihren Zulieferern und an allen 

151
00:07:52,600 --> 00:07:56,320
diesen Stellen kann natürlich 
dieses Vertrauen missbraucht 

152
00:07:56,320 --> 00:07:58,600
werden, weil ich vertraue 
vielleicht dir, aber. 

153
00:07:59,080 --> 00:08:02,240
Aber du hast vielleicht gar 
nicht gemerkt, dass dein Produkt

154
00:08:02,240 --> 00:08:05,520
oder dein Teil und deine 
Komponente, die ich verwende, 

155
00:08:05,520 --> 00:08:08,800
irgendwie kompromittiert wurde. 
Das heißt, das ist jetzt auch 

156
00:08:08,800 --> 00:08:11,680
keine böse Absicht, nur weil du 
zum Beispiel jetzt einen 

157
00:08:11,680 --> 00:08:14,280
bestimmten. 
Entainer oder einem bestimmten 

158
00:08:14,280 --> 00:08:18,800
Package vertraust, ist das ja 
jetzt an sich nichts, was 

159
00:08:18,800 --> 00:08:22,880
irgendwie dann Missbrauch des 
Vertrauens ist, sondern 

160
00:08:22,880 --> 00:08:26,000
teilweise werden diese Leute 
natürlich ohne ihr Wissen zum 

161
00:08:26,000 --> 00:08:31,120
Vehikel, um Schadsoftware zu 
verteilen und dementsprechend 

162
00:08:32,240 --> 00:08:34,960
ist. 
Diese ganze Supply Chain, 

163
00:08:35,120 --> 00:08:38,240
eigentlich heute das 
Haupteinfallstor und Supply 

164
00:08:38,240 --> 00:08:42,720
Chain Security Angriffe 
eigentlich der Weg wie heute in 

165
00:08:42,720 --> 00:08:46,560
moderner Software verwundbarer 
Code eingeschleust wird. 

166
00:08:46,720 --> 00:08:49,200
Das heißt, ganz häufig werden 
jetzt nicht so wirklich 

167
00:08:49,200 --> 00:08:54,560
langwierige Angriffsprozesse auf
große Unternehmen durchgeführt, 

168
00:08:54,560 --> 00:08:57,120
wo man dann versuchen muss, 
irgendwie ins Unternehmen zu 

169
00:08:57,120 --> 00:08:58,800
kommen. 
An der Corporate Firewall vorbei

170
00:08:58,800 --> 00:09:01,800
in die Bildsysteme des 
entsprechenden Unternehmens, 

171
00:09:01,800 --> 00:09:05,080
sondern man geht in. 
Viel weiter vorne in der 

172
00:09:05,080 --> 00:09:08,400
Lieferkette rein, wo vielleicht 
die Sicherheitsstandards 

173
00:09:08,400 --> 00:09:11,600
geringer sind, wo man vielleicht
vertrauen ausnutzen kann oder 

174
00:09:11,760 --> 00:09:14,560
einfach Leute überlastet sind. 
Wir haben ja häufig auch über 

175
00:09:14,560 --> 00:09:17,160
die Open Source Maintainer 
gesprochen und dann ist man 

176
00:09:17,160 --> 00:09:20,400
plötzlich bei den ganz großen 
Softwareprodukten angekommen und

177
00:09:20,400 --> 00:09:24,840
bei den Developern, die diese 
bauen und kann dort entsprechend

178
00:09:24,840 --> 00:09:27,720
seine Malware ausführen. 
Und diese Angriffe, die sind 

179
00:09:27,720 --> 00:09:30,800
selten gezielt auf euch. 
Jetzt zum Beispiel, sondern die 

180
00:09:30,800 --> 00:09:33,360
sind dann eher gezielt auf große
Libraries, denen viele Leute 

181
00:09:33,360 --> 00:09:35,920
vertrauen, und dann hofft man 
einfach, dass sich diese 

182
00:09:35,920 --> 00:09:38,200
Angriffe häufig sind das 
irgendwelche Trojaner oder 

183
00:09:38,200 --> 00:09:40,760
irgendwelche Skripte, die 
Secrets sammeln und die dann 

184
00:09:40,760 --> 00:09:42,720
alle zentral auf irgendeinen 
Server pumpen. 

185
00:09:42,840 --> 00:09:44,800
Man hofft dann einfach, dass 
diese Angriffe möglichst 

186
00:09:44,800 --> 00:09:49,120
weitreichend sind und man dort 
dann auch möglichst viel einfach

187
00:09:49,120 --> 00:09:52,040
von möglichst vielen Firmen 
abgreifen kann für. 

188
00:09:52,280 --> 00:09:54,160
Das heißt, es hilft eigentlich 
nicht, sich so ein bisschen 

189
00:09:54,160 --> 00:09:56,000
dahinter zu verstecken, zu 
sagen, ja, ich bin ja gar kein 

190
00:09:56,000 --> 00:09:59,360
spannendes Angriffsziel oder so,
das weiß man gar nicht, weil man

191
00:09:59,360 --> 00:10:01,360
selten hier gezielt angegriffen 
wird. 

192
00:10:01,360 --> 00:10:03,920
Die Pakete werden natürlich 
gezielt angegriffen, aber ihr 

193
00:10:03,920 --> 00:10:07,280
wahrscheinlich eher nichts, ihr 
seid dann eher einfach Opfer von

194
00:10:07,280 --> 00:10:11,440
einem solchen Angriff und so ein
Angriff, der kann ganz viele, 

195
00:10:11,520 --> 00:10:13,800
ganz viele verschiedene Facetten
annehmen, das kann von wirklich 

196
00:10:13,800 --> 00:10:19,680
ganz, ganz simpel zu wirklich. 
Genial trickreich sich gestalten

197
00:10:19,680 --> 00:10:22,160
der simpelste Angriff, würde ich
sagen, ist eigentlich so ein 

198
00:10:22,160 --> 00:10:25,600
bisschen dieses Typo squatting. 
Da hofft man einfach drauf, dass

199
00:10:25,600 --> 00:10:28,400
ihr euch vertippt. 
Das heißt, der Name sieht so 

200
00:10:28,400 --> 00:10:30,560
fast richtig aus. 
Ich will eigentlich Django 

201
00:10:30,560 --> 00:10:33,040
installieren und da gibt es ein 
Paket, das heißt dann aber nicht

202
00:10:33,200 --> 00:10:37,840
DJ A NGO, sondern DAJ NGO und 
das sieht so für so menschliches

203
00:10:37,840 --> 00:10:41,360
Auge häufig sehr sehr ähnlich 
aus, oder ich habe so Unicode 

204
00:10:41,360 --> 00:10:44,640
Zeichen oder minimale Vertipper,
also so Dinge die mir dann beim 

205
00:10:44,640 --> 00:10:46,960
Copy, Pasten oder sowas nicht 
auffallen, oder? 

206
00:10:47,040 --> 00:10:49,840
Und dann habe ich statt das 
Paket, was ich eigentlich haben 

207
00:10:49,840 --> 00:10:52,000
wollte, das kompromittierte 
Paket runtergeladen. 

208
00:10:52,080 --> 00:10:55,160
Und häufig ist es sogar so, dass
dieses kompromittierte Paket 

209
00:10:55,160 --> 00:10:56,840
dann das original Paket noch 
enthält. 

210
00:10:56,840 --> 00:10:59,760
Das heißt, ich merke das gar 
nicht auf den ersten Blick, denn

211
00:10:59,760 --> 00:11:02,920
die Anwendung verhält sich so, 
wie ich das erwarten würde, ich 

212
00:11:02,920 --> 00:11:05,280
habe nur neben dem Paket mir 
noch irgendwie ein bisschen 

213
00:11:05,280 --> 00:11:07,320
Schadsoftware reingeholt, das 
ist so ein bisschen ähnlich, die

214
00:11:08,160 --> 00:11:10,920
ja die billigste Klasse von 
Angreifern, aber auch so ein 

215
00:11:10,920 --> 00:11:13,760
bisschen die spannendste, weil 
man, weil man sich da gerne noch

216
00:11:13,760 --> 00:11:15,440
irgendwie einredet, sagen, ja, 
gut, da musst du halt ein 

217
00:11:15,440 --> 00:11:19,360
bisschen besser aufpassen und 
aber ich glaube, so richtig frei

218
00:11:19,360 --> 00:11:23,320
davon ist ist da niemand. 
Ja, und tatsächlich kann man 

219
00:11:23,320 --> 00:11:26,560
sich vor Tippfehlern vielleicht 
noch schützen, aber am Ende gibt

220
00:11:26,560 --> 00:11:30,240
es natürlich auch viele andere 
Wege dort diese kompromittierten

221
00:11:30,240 --> 00:11:34,080
Pakete einzuschleusen und eine 
andere Variante ist zum Beispiel

222
00:11:34,080 --> 00:11:37,720
Dependency Confusion, das 
bedeutet, ich habe vielleicht 

223
00:11:37,720 --> 00:11:39,600
einen. 
Paket in einer bestimmten 

224
00:11:39,600 --> 00:11:42,520
Version sogar gepinnt. 
Ich habe alles richtig gemacht, 

225
00:11:42,520 --> 00:11:45,280
ich nutze vielleicht sogar mein 
internes Package 

226
00:11:45,280 --> 00:11:48,240
verwaltungssystem, irgendwie ein
Artifactory, was ich selber 

227
00:11:48,240 --> 00:11:53,080
betreibe, um sicherzugehen, dass
dieses Paket geprüft ist und 

228
00:11:53,080 --> 00:11:57,760
keine Malware enthält und dann 
veröffentlicht jemand in einem 

229
00:11:57,840 --> 00:12:03,040
Public in einer Public Registry 
eine neuere Version dieses 

230
00:12:03,040 --> 00:12:06,360
Paketes mit einer höheren 
Versionsnummer und vielleicht 

231
00:12:06,360 --> 00:12:09,480
hast du dann dein. 
Build System so konfiguriert, 

232
00:12:09,480 --> 00:12:11,360
dass immer die neueste Version 
zieht. 

233
00:12:11,520 --> 00:12:14,720
Und weil diese neueste Versionen
noch nicht auf deiner lokalen 

234
00:12:14,720 --> 00:12:17,440
Registry vorhanden sind, gibt es
dann vielleicht irgendwie einen 

235
00:12:17,440 --> 00:12:21,120
Fallback, wo dann wieder die 
Public Registry gewinnt und dann

236
00:12:21,120 --> 00:12:25,200
zieht plötzlich dein Bildprozess
entweder lokal oder in deiner ci

237
00:12:25,200 --> 00:12:27,000
plötzlich dieses kompromittierte
Paket. 

238
00:12:27,000 --> 00:12:30,320
Das heißt, du hast eigentlich 
alles richtig gemacht und am 

239
00:12:30,320 --> 00:12:34,520
Ende landet trotzdem wieder ein 
Paket auf deiner Maschine oder 

240
00:12:34,520 --> 00:12:38,120
im Build System, welches du 
nicht wolltest und hier ist. 

241
00:12:38,320 --> 00:12:41,280
Hast du vielleicht als Developer
nichts falsch gemacht, sondern 

242
00:12:41,440 --> 00:12:44,640
das System, wie es irgendwann 
mal aufgesetzt wurde, vielleicht

243
00:12:44,640 --> 00:12:48,080
von jemand völlig anderem, der 
ursprünglich mal das Repository 

244
00:12:48,080 --> 00:12:51,120
konfiguriert hat oder die CI 
Pipeline gebaut hat? 

245
00:12:52,080 --> 00:12:55,200
Hat dann hier entsprechend 
irgendwie immer latest 

246
00:12:55,200 --> 00:12:58,480
eingetragen und du hast das 
einfach so hingenommen und dann 

247
00:12:58,480 --> 00:13:02,280
hast du plötzlich den irgendwie 
credential Scanner auf deiner 

248
00:13:02,280 --> 00:13:05,760
lokalen Maschine, ohne dass du 
selber überhaupt etwas falsch 

249
00:13:05,760 --> 00:13:08,080
gemacht hast. 
Genau dabei setzen Angreifer 

250
00:13:08,080 --> 00:13:10,880
dann eben drauf, dass es 
fehlkonfigurationen oder zu 

251
00:13:10,880 --> 00:13:14,080
schwammige Konfigurationen in 
eurer Pipeline gibt. 

252
00:13:14,320 --> 00:13:16,320
Aber es kann eben auch 
passieren, dass ihr alles 

253
00:13:16,320 --> 00:13:19,480
korrekt konfiguriert habt und 
nicht den falschen Namen, die 

254
00:13:19,480 --> 00:13:21,680
falsche Quelle oder die falsche 
Version euch irgendwie reinholt.

255
00:13:21,680 --> 00:13:23,400
Das sind ja alles so ein 
bisschen Flüchtigkeitsfehler, 

256
00:13:23,400 --> 00:13:26,960
sondern wirklich die richtige 
Library aus der offiziellen 

257
00:13:26,960 --> 00:13:31,360
Quelle mit einem offiziellen 
Release gezogen habt und sie 

258
00:13:31,360 --> 00:13:34,400
ist. 
Trotzdem bösartig, weil der 

259
00:13:34,400 --> 00:13:36,680
Mantainer kompromittiert wurde. 
Vielleicht das selber gar nicht 

260
00:13:36,680 --> 00:13:40,400
weiß, weil irgendein Publish 
Konto übernommen wurde und dann 

261
00:13:40,400 --> 00:13:43,600
ein schadhaftes Release aus der 
richtigen Quelle, also 

262
00:13:43,600 --> 00:13:47,680
eigentlich aus dieser legitimen 
Vertrauenskette heraus verteilt 

263
00:13:47,680 --> 00:13:50,720
wird und das ist dann besonders 
fies, weil da können wir uns 

264
00:13:50,720 --> 00:13:53,280
fast schon. 
Auch wenn wir alles richtig 

265
00:13:53,280 --> 00:13:56,880
konfiguriert haben, nicht 
wirklich davor schützen, weil 

266
00:13:56,880 --> 00:13:59,520
vor 2 Versionen war das noch 
alles perfekt was wir gemacht 

267
00:13:59,520 --> 00:14:03,000
haben und auf einmal hat jemand 
vielleicht sogar ebenfalls über 

268
00:14:03,000 --> 00:14:06,280
ein Paket den Maintainer 
kompromittiert oder gar nicht 

269
00:14:06,280 --> 00:14:09,840
nur den Maintainer, sondern ein 
weiteres eine transient 

270
00:14:09,840 --> 00:14:12,800
Dependency, also ein weiteres 
Paket, was das Paket dann 

271
00:14:12,800 --> 00:14:15,480
wiederum verwendet, was ich 
eigentlich mit ziehen will und 

272
00:14:15,480 --> 00:14:18,400
da kann ich dann eben nicht mehr
mit ja musst du halt besser 

273
00:14:18,400 --> 00:14:21,520
aufpassen als meine 
Schutzstrategie arbeiten. 

274
00:14:21,720 --> 00:14:25,240
Sondern hier habe ich dann 
wirklich ja nen nen ne 

275
00:14:25,240 --> 00:14:30,000
Schadsoftware über ein 
vertrauenswürdiges Einfallstor 

276
00:14:30,160 --> 00:14:34,560
mir in das System geholt. 
Und genau diese Angriffswege 

277
00:14:34,560 --> 00:14:36,920
wurden ja zuletzt immer häufiger
verwendet. 

278
00:14:36,920 --> 00:14:40,160
Das haben wir bei Shai Hulut 
gesehen, wir haben das bei Axeos

279
00:14:40,160 --> 00:14:45,200
gesehen, wo dann wirklich du 
selber plötzlich jemand warst, 

280
00:14:45,200 --> 00:14:48,080
der diese Schadsoftware weiter 
verteilt hat, weil du dir 

281
00:14:48,080 --> 00:14:50,720
irgendwie ein legitimes Paket 
installiert hast. 

282
00:14:50,720 --> 00:14:53,200
Und dort war halt dieser 
credential Scanner drin, er hat 

283
00:14:53,200 --> 00:14:56,240
sich deine npm credentials 
geschnappt, hat geschaut, ob du 

284
00:14:56,240 --> 00:14:58,360
selber vielleicht ein Paket 
published und plötzlich war in 

285
00:14:58,360 --> 00:15:02,400
deinem Paket dann auch. 
Diese Schadsoftware drin und so 

286
00:15:02,400 --> 00:15:06,640
kann sich etwas natürlich extrem
schnell verbreiten und häufig 

287
00:15:06,640 --> 00:15:11,520
ist wirklich der erste 
Einstiegspunkt so ein metainer 

288
00:15:11,640 --> 00:15:14,560
Credential League, wo einmal 
wirklich Informationen verloren 

289
00:15:14,560 --> 00:15:18,240
gegangen sind und dieses eine 
Paket irgendwie austauschen 

290
00:15:18,240 --> 00:15:20,880
konntest oder halt mit, wie du 
gerade gesagt hast, mit einer 

291
00:15:20,880 --> 00:15:24,080
Dependency versorgen konntest, 
die hier entsprechend 

292
00:15:24,160 --> 00:15:28,720
Schadsoftware einschleust und. 
Und das passiert natürlich jetzt

293
00:15:28,720 --> 00:15:33,400
auch in Zukunft nicht mehr nur 
über menschliche Maintainer, die

294
00:15:33,400 --> 00:15:36,760
irgendwie credentials verlieren,
sondern immer häufiger verwenden

295
00:15:36,760 --> 00:15:39,200
wir natürlich nicht nur 
automatisierte Systeme, sondern 

296
00:15:39,200 --> 00:15:42,960
wir verwenden sogar KI Systeme. 
Und auch da gibt es natürlich 

297
00:15:42,960 --> 00:15:45,680
jetzt schon die ersten Attacken,
die das ausnutzen. 

298
00:15:45,840 --> 00:15:50,640
Wenn zum Beispiel du in deinem 
Repository irgendwie in deiner 

299
00:15:50,760 --> 00:15:53,960
ci irgendwas mit einem KI System
machst, was vielleicht irgendwie

300
00:15:53,960 --> 00:15:58,160
ein Triaging der Issues in dem 
Repository macht oder einen Code

301
00:15:58,160 --> 00:16:00,880
Review macht und dann wird über 
eine prompt Injection Attacke 

302
00:16:01,120 --> 00:16:04,880
dann das KI System dazu gebracht
hier das Package zu 

303
00:16:04,880 --> 00:16:07,960
kompromittieren und da hat am 
Ende nicht mal der. 

304
00:16:07,960 --> 00:16:11,920
Der Mensch selber einen Fehler 
begangen, sondern das KI System 

305
00:16:11,920 --> 00:16:15,200
wurde entsprechend überlistet. 
Natürlich kann man jetzt sagen, 

306
00:16:15,200 --> 00:16:17,120
irgendjemand hat ja dieses 
System ursprünglich 

307
00:16:17,120 --> 00:16:21,520
eingerichtet, aber das sind ja 
teilweise Dinge, die man einfach

308
00:16:21,520 --> 00:16:25,160
vielleicht zu dem Zeitpunkt noch
gar nicht so überblickt und es 

309
00:16:25,160 --> 00:16:27,920
entstehen natürlich gerade durch
diese neuen Technologien auch 

310
00:16:27,920 --> 00:16:30,720
immer neue Angriffsvektoren, die
ausgenutzt werden können. 

311
00:16:31,200 --> 00:16:32,600
Wenn. 
Wenn ich dann so ein Paket 

312
00:16:32,600 --> 00:16:34,880
irgendwie bei mir installiert 
habe, dann kommt diese 

313
00:16:34,880 --> 00:16:38,480
Schadsoftware häufig über diese 
sogenannten Post install Skripte

314
00:16:38,480 --> 00:16:39,320
rein. 
Das ist eigentlich so ein 

315
00:16:39,320 --> 00:16:41,840
bisschen das, was jetzt die 
letzten Angriffe, also sowohl 

316
00:16:42,080 --> 00:16:45,240
diese diese Axios Attacke als 
auch shyho lut und so was dann 

317
00:16:45,240 --> 00:16:49,200
ausgenutzt haben und eigentlich 
ist es ein Unding, dass es 

318
00:16:49,200 --> 00:16:50,400
überhaupt gibt. 
Ich glaube, wenn wir die Zeit 

319
00:16:50,400 --> 00:16:52,680
zurückdrehen könnten, dann würde
man wahrscheinlich sagen lassen,

320
00:16:52,680 --> 00:16:54,400
das hätten wir niemals einführen
dürfen. 

321
00:16:55,160 --> 00:16:57,000
Das ist dann einfach also ein 
Post and Score Script, das 

322
00:16:57,000 --> 00:16:59,040
funktioniert ist. 
Diese Pakete dürfen eben beim 

323
00:16:59,040 --> 00:17:02,080
Installieren auf meiner Maschine
Code ausführen und wenn man sich

324
00:17:02,080 --> 00:17:04,720
das heute so irgendwie anhört, 
nach all diesen Attacken, dann 

325
00:17:04,960 --> 00:17:06,800
fasst man sie ja fast schon an 
den Kopf, dass wir das jemals 

326
00:17:06,800 --> 00:17:09,680
irgendwie erlaubt haben. 
Dabei können natürlich dann 

327
00:17:09,680 --> 00:17:12,119
Dateien abgegriffen werden oder 
es geht eigentlich auch darum, 

328
00:17:12,119 --> 00:17:14,560
dass bestimmte Dinge vielleicht 
nachgeladen werden, also ich 

329
00:17:14,560 --> 00:17:17,119
installiere mir das Paket und 
wenn ich merke, dass ich auf Mac

330
00:17:17,240 --> 00:17:20,000
OS bin, dann lade ich noch mal 
die Mac OS Binary von irgendwas 

331
00:17:20,000 --> 00:17:23,119
nach und dabei können aber 
natürlich auch lokale Systeme. 

332
00:17:23,599 --> 00:17:28,400
Inspiziert werden und dabei dann
gehen diese Skripte oft auf die 

333
00:17:28,400 --> 00:17:30,960
Suche, ob ich nicht irgendwo 
lokal irgendwelche Creidentials 

334
00:17:30,960 --> 00:17:34,440
habe oder verschlüsseln meinen 
Rechner komplett. 

335
00:17:34,440 --> 00:17:36,000
Es kann natürlich auch sein, 
dass ich mir einen Virus oder 

336
00:17:36,000 --> 00:17:38,760
eine Ransomware darüber 
einfange, muss man aber 

337
00:17:38,760 --> 00:17:42,240
ehrlicherweise auch dazu sagen, 
für die Konsistenz diese Post 

338
00:17:42,240 --> 00:17:44,560
install Skripte, die stehen 
natürlich gerade im absoluten 

339
00:17:44,560 --> 00:17:47,520
Fokus, die sind aber nicht der 
gesamte Angriff, das ist nur 

340
00:17:47,520 --> 00:17:50,960
eine von mehreren Türen. 
Dieser Schadcode kann natürlich 

341
00:17:50,960 --> 00:17:52,920
auch beim Import ausgeführt 
werden. 

342
00:17:52,920 --> 00:17:56,680
Also wenn ich die Library in 
meinem Code lade oder vielleicht

343
00:17:56,680 --> 00:17:59,280
auch wirklich erst zur Laufzeit,
oder das ist ein Script, was 

344
00:17:59,280 --> 00:18:01,120
wirklich, was ich beim Bild 
verwende und dann wirklich erst 

345
00:18:01,120 --> 00:18:05,480
beim Bild irgendwie noch Sachen 
ausgeführt werden oder teilweise

346
00:18:05,480 --> 00:18:07,440
dann auch wirklich erst im 
Nachhinein, wenn die wenn die 

347
00:18:07,440 --> 00:18:10,800
wenn die Binary. 
Aktiv wird also, wenn der 

348
00:18:10,800 --> 00:18:13,400
Endnutzer das ganze Ding 
verwendet. 

349
00:18:13,400 --> 00:18:15,280
Das heißt, wenn ich nur auf 
diese Post install Skripte 

350
00:18:15,280 --> 00:18:17,600
schaue, dann fange ich 
wahrscheinlich einen Großteil 

351
00:18:17,600 --> 00:18:21,280
der aktuellen Angriffslandschaft
ab, muss aber ehrlich sagen, 

352
00:18:21,280 --> 00:18:22,960
dann schließe ich nur meine 
Haustür richtig ab. 

353
00:18:22,960 --> 00:18:25,240
Ich muss aber natürlich auch 
gucken, dass keiner durch die 

354
00:18:25,240 --> 00:18:28,960
Fenster oder den Hintereingang 
oder Irgendsowas reinkommt und 

355
00:18:28,960 --> 00:18:32,320
da gibt es noch ein paar andere 
Dinge, auf die ich achten muss, 

356
00:18:32,320 --> 00:18:35,120
aber Post install ist auf jeden 
Fall was, das kann ich in den 

357
00:18:35,120 --> 00:18:37,680
meisten Technologien auch 
mittlerweile abdrehen. 

358
00:18:37,880 --> 00:18:39,480
Wir sprechen gleich noch mal ein
bisschen drüber, wie ich mich 

359
00:18:39,480 --> 00:18:42,200
jetzt eigentlich als Developer 
wirklich aufstellen kann, aber 

360
00:18:42,200 --> 00:18:44,720
das ist zumindest so dieser 
Hook, der jetzt in letzter Zeit 

361
00:18:44,720 --> 00:18:48,080
sehr, sehr stark in den Fokus 
gerückt ist, weil die ganzen 

362
00:18:48,080 --> 00:18:50,800
Skripte, die wir jetzt in der 
Vergangenheit gesehen haben, 

363
00:18:50,800 --> 00:18:55,280
eben darüber aktiviert wurden. 
Und hier sind wir gerade jetzt 

364
00:18:55,280 --> 00:18:58,840
auf der lokalen Developer 
Maschine häufig, und das ist ja 

365
00:18:58,840 --> 00:19:02,200
auch das, was wir tagtäglich 
nutzen, wenn wir Software 

366
00:19:02,200 --> 00:19:04,400
entwickeln. 
Und dort befinden sich natürlich

367
00:19:04,400 --> 00:19:08,800
sehr viele wertvolle Ziele, also
so ein Posting, Sold, Script, du

368
00:19:08,800 --> 00:19:10,800
hast gerade gesagt, kann zum 
Beispiel einen credential 

369
00:19:10,800 --> 00:19:14,720
Scanner ausführen, der kann dann
deine dort Inv Dateien scannen, 

370
00:19:14,720 --> 00:19:19,760
deine ssh Keys auslesen, deine 
Publish Tokens und dort 

371
00:19:19,760 --> 00:19:23,400
entsprechend dann dich auch zu 
einem ungewollten Helfer für. 

372
00:19:23,520 --> 00:19:26,400
Die Verbreitung von weiterer 
Schadsoftware machen oder 

373
00:19:26,400 --> 00:19:30,960
natürlich auch Secrets Clown für
dein Git System oder Deine Cloud

374
00:19:30,960 --> 00:19:33,360
Plattform und dieses dann auch 
ausnutzen. 

375
00:19:33,360 --> 00:19:36,640
Häufig werden diese Cloud 
Plattformen dann für Dinge wie 

376
00:19:36,640 --> 00:19:41,200
Crypto Miner oder Filesharing 
verwendet und da möchtest du ja 

377
00:19:41,200 --> 00:19:43,840
eigentlich natürlich nicht 
Helfershelfer werden, aber das 

378
00:19:43,840 --> 00:19:48,000
liegt natürlich daran. 
Dass gegebenenfalls du diese 

379
00:19:48,000 --> 00:19:50,600
Credentials auf deiner lokalen 
Maschine hast, hatten wir in der

380
00:19:50,600 --> 00:19:52,400
Vergangenheit auch schon 
häufiger darüber gesprochen. 

381
00:19:52,400 --> 00:19:56,440
Wir reden gleich noch mal im 
Detail darüber, was man letzten 

382
00:19:56,440 --> 00:19:59,920
Endes tun kann. 
Aber am Ende ist das so. 

383
00:19:59,920 --> 00:20:03,760
Die lokale Maschine, die du 
selber unter Kontrolle hast. 

384
00:20:03,760 --> 00:20:07,360
Aber dann gibt es auch noch, ja 
natürlich das Bild System, was 

385
00:20:07,360 --> 00:20:10,400
in deinem eigenen 
Softwareentwicklungsprozess 

386
00:20:10,560 --> 00:20:14,000
natürlich auch eine Rolle spielt
und dieses Bild System ist 

387
00:20:14,000 --> 00:20:16,080
vielleicht gar nicht unter 
deiner Kontrolle, wenn wir 

388
00:20:16,880 --> 00:20:19,480
vielleicht ein kleineres Produkt
haben, wo wir irgendwie über so 

389
00:20:19,480 --> 00:20:22,640
einen. 
Def sec Ops Prozess reden wo 

390
00:20:22,640 --> 00:20:25,240
irgendwie man END to End 
Ownership hat, kontrolliert man 

391
00:20:25,240 --> 00:20:28,400
vielleicht das Bildsystem mit, 
aber gerade in größeren 

392
00:20:28,400 --> 00:20:30,960
Unternehmen sind das natürlich 
auch unterschiedliche Personen, 

393
00:20:30,960 --> 00:20:36,080
die diese Dinge aufgebaut haben 
und steuern und dementsprechend 

394
00:20:36,080 --> 00:20:38,720
müssen wir nicht nur auf die 
lokale Maschine schauen, sondern

395
00:20:38,720 --> 00:20:42,400
natürlich auch auf unsere Bild 
und Release Pipeline, die dann 

396
00:20:42,400 --> 00:20:46,960
quasi im nächsten Schritt dann 
nachdem der Anteil der Arbeit 

397
00:20:46,960 --> 00:20:48,960
auf der Developer Maschine 
abgeschlossen wurde. 

398
00:20:49,240 --> 00:20:50,840
Die nächsten Schritte übernimmt 
aber. 

399
00:20:51,360 --> 00:20:53,440
Es kann ja auch einfach sein, 
dass ich irgendwas chippe an 

400
00:20:53,440 --> 00:20:57,160
meine Kunden, was dann dort 
wieder bei denen die Credentials

401
00:20:57,160 --> 00:20:59,720
scannt und so weiter so passiert
es ja auch teilweise bei diesen 

402
00:20:59,720 --> 00:21:02,200
Angriffen, dass dass Exeos an 
sich jetzt ja gar nicht das 

403
00:21:02,200 --> 00:21:04,800
große Angriffsziel ist, sondern 
die Developer von Exeos auch gar

404
00:21:04,800 --> 00:21:07,120
nicht explizit getargelt werden,
sondern dass die auch wieder 

405
00:21:07,120 --> 00:21:10,560
irgendwo etwas verwenden, was 
sie dann an ihre Kunden, also 

406
00:21:10,560 --> 00:21:14,960
die exeos, Userinnen und User. 
Quasi ausrollen und das dann 

407
00:21:14,960 --> 00:21:17,560
dort wieder zu Problemen sorgt. 
Das heißt, diese Kette kann auch

408
00:21:17,560 --> 00:21:19,320
wirklich sehr, sehr lang und 
sehr, sehr verschachtelt sein 

409
00:21:19,320 --> 00:21:22,240
und es kann sein, dass du gar 
nicht weißt, dass du selber 

410
00:21:22,240 --> 00:21:26,240
Schadcode an deine Kundinnen und
Kunden verteilst. 

411
00:21:26,560 --> 00:21:30,800
Ja, und das gefährliche ist ja, 
sobald es dann in diesem Release

412
00:21:30,800 --> 00:21:34,720
Prozess ist. 
Dass auch diese Artefakte, die 

413
00:21:34,720 --> 00:21:37,280
du vielleicht auslieferst oder 
weiter verteilst, dann auch 

414
00:21:37,280 --> 00:21:40,640
entsprechend signiert werden, 
das heißt auch für die Nutzer 

415
00:21:40,720 --> 00:21:44,000
dieser Komponenten sieht das 
ganze alles dann sauber und 

416
00:21:44,000 --> 00:21:46,040
vertrauenswürdig aus, weil wir 
hatten es ja gerade am Anfang 

417
00:21:46,040 --> 00:21:49,600
gesagt, ich vertraue dir, der du
dieses Paket baust und du weißt 

418
00:21:49,600 --> 00:21:52,880
vielleicht gar nicht, dass vor 
deinem oder während deines Bilds

419
00:21:52,880 --> 00:21:56,880
und vor der Signatur. 
Schadsoftware aufgenommen wurde,

420
00:21:56,880 --> 00:22:00,160
und das heißt, ich Krieg von dir
ein absolut legitimes Paket, 

421
00:22:00,160 --> 00:22:03,760
welches von dir signiert wurde. 
Ich kann das quasi bis in deinen

422
00:22:03,760 --> 00:22:06,160
Releaseprozess bis in deinen 
Quellcode nachvollziehen. 

423
00:22:06,480 --> 00:22:10,480
Aber trotzdem kann ich mich 
damit selber infizieren und das 

424
00:22:10,480 --> 00:22:15,880
macht das Ganze natürlich extrem
schwer, auch komplett zu 

425
00:22:15,880 --> 00:22:18,400
unterbinden. 
Und am Ende sind natürlich 

426
00:22:18,400 --> 00:22:22,720
solche Credentialed und Secret 
Diebstähle so das häufigste 

427
00:22:22,720 --> 00:22:24,880
Szenario heute. 
Aber es gibt natürlich auch noch

428
00:22:25,120 --> 00:22:28,800
andere Dinge, die über die 
Software Supply Chain Attacken 

429
00:22:28,800 --> 00:22:31,920
verteilt werden können. 
Und dazu gehören zum Beispiel 

430
00:22:31,920 --> 00:22:34,040
einfach diese, auch diese 
Seitwärtsbewegung. 

431
00:22:34,040 --> 00:22:37,200
Wir hatten gerade schon darüber 
gesprochen, dass man selber ein 

432
00:22:37,200 --> 00:22:40,000
Vehikel wird, um diese 
Schadsoftware weiter zu 

433
00:22:40,000 --> 00:22:42,320
verteilen, und diese 
Schadsoftware kann natürlich 

434
00:22:42,320 --> 00:22:44,280
auch Ransomware sein. 
Wir haben in der Vergangenheit 

435
00:22:44,280 --> 00:22:47,680
ganz oft darüber gesprochen, 
dass irgendwelche Unternehmen 

436
00:22:47,680 --> 00:22:51,040
und Firmen dieses Problem 
hatten, dass ihre ganzen it 

437
00:22:51,040 --> 00:22:52,960
Systeme verschlüsselt wurden und
dann. 

438
00:22:53,240 --> 00:22:57,280
Versucht wurde, Lösegeld zu 
erpressen, das heißt, Secret 

439
00:22:57,280 --> 00:23:00,880
Diebstahl ist meistens nur der 
erste Schritt, um dann in 

440
00:23:00,880 --> 00:23:04,400
weiteren Schritten andere 
Schadsoftware verteilen zu 

441
00:23:04,400 --> 00:23:08,080
können und damit halt auch Geld 
zu verdienen, weil an sich, wenn

442
00:23:08,080 --> 00:23:11,520
ich jetzt nicht unbedingt 
irgendwie deinen oder US oder 

443
00:23:11,520 --> 00:23:15,040
Azure Account ausnutzen kann, 
dann verdiene ich erstmal 

444
00:23:15,040 --> 00:23:17,440
vielleicht damit, dass ich deine
Credentials habe, noch kein 

445
00:23:17,440 --> 00:23:20,160
Geld, aber sobald ich dann bei 
großen Unternehmen, bei 

446
00:23:20,160 --> 00:23:22,560
irgendwelchen Firmen. 
Oder in der öffentlichen 

447
00:23:22,560 --> 00:23:25,600
Verwaltung dann It Systeme 
Verschlüssele und dann dort 

448
00:23:25,600 --> 00:23:29,480
Lösegeld erpresse, kann ich 
natürlich auch entsprechend mit 

449
00:23:29,480 --> 00:23:32,600
diesen Angriffen Geld verdienen 
und ganz häufig sind natürlich 

450
00:23:32,600 --> 00:23:36,080
diese Angriffe nicht nur 
politisch motiviert, sondern 

451
00:23:36,080 --> 00:23:39,600
auch vor allen Dingen von 
Cyberkriminellen hier auch 

452
00:23:39,600 --> 00:23:42,360
finanziell motiviert. 
So, dann schauen wir doch jetzt 

453
00:23:42,360 --> 00:23:44,840
mal die developer Perspektive. 
Also wenn ihr jetzt nicht 

454
00:23:44,840 --> 00:23:47,720
unbedingt Main Tainer oder 
Publisher von solchen Projekten 

455
00:23:47,720 --> 00:23:49,760
seid, sondern wie wir alle 
einfach. 

456
00:23:50,200 --> 00:23:54,320
Über End Pam Install oder 
Konsorten euch Pakete reinholt. 

457
00:23:54,720 --> 00:23:56,640
Was kann ich denn realistisch 
machen? 

458
00:23:56,640 --> 00:23:59,680
Und da muss man schon leider 
sagen, wir haben uns jetzt im 

459
00:23:59,680 --> 00:24:02,440
Rahmen dieser Folge da so ein 
bisschen auch reingefuchst und 

460
00:24:02,440 --> 00:24:06,160
drauf vorbereitet und die kurze 
Wahrheit finde ich, ist so ein 

461
00:24:06,160 --> 00:24:10,240
bisschen ja eigentlich eher 
unangenehm, denn gegen so 

462
00:24:10,720 --> 00:24:13,560
legitime Releases, also nicht 
ich habe mich vertippt oder 

463
00:24:13,560 --> 00:24:16,240
irgendjemand anders hat eine 
neue Version veröffentlicht und 

464
00:24:16,240 --> 00:24:19,520
ich habe nichts gepinnt. 
Und diese legitimen Releases, 

465
00:24:19,520 --> 00:24:22,160
wie wir sie bei bei Exeos in 
diesen ganzen Shiyout Angriffen 

466
00:24:22,160 --> 00:24:26,000
haben, da gibt es jetzt leider 
nicht so dieses eine Ding, was 

467
00:24:26,000 --> 00:24:27,920
ich tun kann. 
Ich kann natürlich so ein 

468
00:24:27,920 --> 00:24:31,280
bisschen so gängigen Best 
Practices folgen, die Bauen oft 

469
00:24:31,280 --> 00:24:35,960
auf so einem Schichtenmodell 
auf, das heißt, a Nummer 1 ist 

470
00:24:35,960 --> 00:24:39,680
ganz klar weniger dependencies, 
um einfach diesen Angriffsvektor

471
00:24:39,680 --> 00:24:42,680
zu minimieren, also ist wirklich
zu fragen, brauche ich überhaupt

472
00:24:42,680 --> 00:24:45,280
ein Exeos. 
Oder kann ich für diesen simplen

473
00:24:45,280 --> 00:24:47,920
http request nicht vielleicht 
auch einfach die eingebauten 

474
00:24:47,920 --> 00:24:51,640
Tools benutzen, die das 
Framework oder die Delibrary, 

475
00:24:51,640 --> 00:24:56,560
die ich verwende, mitbringen? 
Das zweite ist, dass ich viel 

476
00:24:56,560 --> 00:25:00,000
besser kontrollieren muss 
eigentlich, woher ich meine, was

477
00:25:00,000 --> 00:25:02,880
meine Bezugsquellen sind, die 
müssen Reviewbar sein, die 

478
00:25:02,880 --> 00:25:07,280
müssen deterministisch sein. 
Heißt es kann sein, dass es 

479
00:25:07,280 --> 00:25:09,880
darauf hinausläuft, dass ich mir
selber eine zentrale Registry 

480
00:25:09,880 --> 00:25:13,200
irgendwo schaffe, wo ich 
regelmäßig Scans mache oder 

481
00:25:13,440 --> 00:25:17,520
policies unternehmensweit 
ausrolle, wo ich sage, wie in 

482
00:25:17,520 --> 00:25:20,720
unserem Unternehmen Pakete 
überhaupt auf unsere Rechner 

483
00:25:20,720 --> 00:25:23,760
kommen, das eine Menge vor und 
Nachteile ist ein sehr 

484
00:25:23,760 --> 00:25:26,320
kontroverses Thema, sprechen wir
gleich aber noch mal im Detail 

485
00:25:26,320 --> 00:25:29,440
drüber und das nächste ist 
eigentlich, dass ich diesen 

486
00:25:29,440 --> 00:25:32,640
Installationscode einschränke, 
das heißt, dass ich diese ganzen

487
00:25:32,640 --> 00:25:36,080
Post install skripte. 
Idealerweise ganz verbiete oder 

488
00:25:36,080 --> 00:25:37,520
mich zumindest darauf mal 
fokussiere. 

489
00:25:37,520 --> 00:25:40,000
Was ist denn da gut und was ist 
da schlecht? 

490
00:25:40,640 --> 00:25:43,440
Und leider ist die Wahrheit dann
trotzdem so ein bisschen das, 

491
00:25:43,440 --> 00:25:46,000
auch wenn ich das alles gemacht 
habe und das sind so ein 

492
00:25:46,000 --> 00:25:50,800
bisschen die aktuellen 
Empfehlungen von großen Security

493
00:25:50,800 --> 00:25:54,680
Research Vereinigungen, selbst 
wenn ich dem allen Folge, kann 

494
00:25:54,680 --> 00:25:57,320
es trotzdem sein, dass ich mir 
irgendwas einfange und deswegen 

495
00:25:57,320 --> 00:25:59,400
muss ich mich wahrscheinlich 
auch mit der unangenehmen 

496
00:25:59,400 --> 00:26:02,920
Wahrheit auseinandersetzen. 
Dass ich vielleicht gar nicht 

497
00:26:02,920 --> 00:26:07,280
ganz sicher zu 100% verhindern 
kann, dass die Laptops von 

498
00:26:07,280 --> 00:26:10,080
meinen Developer, sage ich mal, 
kompromittiert sind. 

499
00:26:10,320 --> 00:26:12,160
Das heißt, ich muss mich im 
letzten Schritt auch eigentlich 

500
00:26:12,160 --> 00:26:15,280
darum kümmern, dass nichts zu 
finden ist. 

501
00:26:15,280 --> 00:26:18,800
Auf meinen developer Maschinen, 
was so wertvoll ist, dass es 

502
00:26:18,800 --> 00:26:22,680
eine für den für einen Angreifer
wahnsinnig interessant und für 

503
00:26:22,680 --> 00:26:24,640
mich dann eine große Katastrophe
werden könnte. 

504
00:26:25,680 --> 00:26:26,520
Das. 
Dann lass uns mal in die 

505
00:26:26,520 --> 00:26:29,560
einzelnen Themen ein bisschen 
tiefer reingehen und eine der 

506
00:26:29,560 --> 00:26:32,640
Dinge, die du erwähnt hattest, 
die jeder von uns machen kann, 

507
00:26:32,960 --> 00:26:38,080
ist Logfiles verwenden und auf 
bestimmte Hashes und wirklich 

508
00:26:38,080 --> 00:26:41,120
feste Versionen der Packages zu 
pinnen. 

509
00:26:41,280 --> 00:26:45,040
Und das ist natürlich etwas, was
nur begrenzt hilft, wenn man 

510
00:26:45,040 --> 00:26:48,920
davon ausgeht, dass natürlich 
auch der korrekte maintainer 

511
00:26:48,920 --> 00:26:50,800
Account kompromittiert sein 
kann. 

512
00:26:50,880 --> 00:26:53,440
Das heißt, ich habe die richtige
Version. 

513
00:26:53,800 --> 00:26:57,440
Entsprechend, und diese ist auch
entsprechend signiert, aber 

514
00:26:57,440 --> 00:27:02,560
trotzdem kann sie natürlich 
Schadsoftware enthalten, aber 

515
00:27:02,560 --> 00:27:05,120
das heißt nicht, dass ich das 
nicht tun sollte, weil ich 

516
00:27:05,120 --> 00:27:08,800
natürlich andere 
Angriffsvektoren damit abwehren 

517
00:27:08,800 --> 00:27:12,360
kann, zum Beispiel, dass neue 
Versionen released werden, die 

518
00:27:12,360 --> 00:27:16,160
irgendwie Schadsoftware haben, 
oder dass vielleicht aktuelle 

519
00:27:16,160 --> 00:27:19,080
Versionen überschrieben werden. 
Von daher habe ich da auch die 

520
00:27:19,080 --> 00:27:22,560
Möglichkeit, natürlich bei 
vielen dieser Systemen dann. 

521
00:27:22,800 --> 00:27:26,240
Die entsprechenden Hashes zu 
pinnen und damit sicher zu 

522
00:27:26,240 --> 00:27:30,400
gehen, dass ich wirklich eine 
nicht modifizierte Spinery einer

523
00:27:30,400 --> 00:27:33,840
bestimmten Version habe. 
Das heißt, ich muss das tun, 

524
00:27:33,840 --> 00:27:39,280
aber sollte mich halt trotzdem 
nicht 100% sicher fühlen und 

525
00:27:39,280 --> 00:27:42,000
weiterhin die anderen Punkte, 
die wir jetzt mal im Detail 

526
00:27:42,000 --> 00:27:46,200
besprechen werden, weiterhin 
berücksichtigen und dazu gehört 

527
00:27:46,200 --> 00:27:47,480
natürlich auch so ein bisschen 
eine. 

528
00:27:47,880 --> 00:27:52,640
Ein Delay und Holdback bei neuen
Paketversionen. 

529
00:27:53,200 --> 00:27:57,200
Genau das hat damit zu tun, dass
sich, dass die meisten von 

530
00:27:57,200 --> 00:28:01,680
diesen kompromittierten Paketen 
innerhalb von Stunden erkannt 

531
00:28:01,680 --> 00:28:03,280
werden. 
Das heißt, da lädt jetzt jemand 

532
00:28:03,280 --> 00:28:07,800
irgendwas hoch in Nugget oder in
npm, und die Maintainer und die 

533
00:28:07,800 --> 00:28:10,960
Unternehmen hinter diesen 
zentralen Registrys, die sind 

534
00:28:10,960 --> 00:28:15,120
eigentlich relativ gut da drin. 
Diese Angriffe zu erkennen, das 

535
00:28:15,120 --> 00:28:17,440
heißt, üblicherweise 
verschwinden die nach einigen 

536
00:28:17,440 --> 00:28:20,000
Stunden wieder. 
Mit diesem Delay und Holdback 

537
00:28:20,080 --> 00:28:23,080
konfiguriere ich jetzt mein 
lokales System so, dass ich zum 

538
00:28:23,080 --> 00:28:26,480
Beispiel einfach sage, nehmen 
jetzt mal an, ich, ich nutze 

539
00:28:26,800 --> 00:28:30,240
Pnpm in dieser ganzen Java 
Script Welt, was auch absolut 

540
00:28:30,240 --> 00:28:32,560
die Empfehlung hier sein wird, 
das ist auf jeden Fall das 

541
00:28:32,560 --> 00:28:36,400
modernste System neben npm und 
Jahren und auch vor allem das 

542
00:28:36,400 --> 00:28:40,040
was ich am am besten eigentlich 
einstellen und auf diese 

543
00:28:40,040 --> 00:28:42,880
Angriffe vorbereiten kann. 
Dem kann ich zumindest sagen, 

544
00:28:42,880 --> 00:28:45,360
dass es jetzt eine Minimum 
Release Age geben soll. 

545
00:28:45,440 --> 00:28:48,080
Ich könnte zum Beispiel sagen, 
Hey, ich möchte, dass du keine 

546
00:28:48,080 --> 00:28:53,360
Pakete installieren darfst, die 
jünger als 24 oder 48 Stunden 

547
00:28:53,360 --> 00:28:56,960
sind, bedeutet, selbst wenn der 
Mantainer eine neue Version 

548
00:28:56,960 --> 00:29:00,800
hochlädt, kann ich die 
frühestens in 48 Stunden in mein

549
00:29:00,800 --> 00:29:03,280
System rein installieren und 
damit habe ich zumindest schon 

550
00:29:03,520 --> 00:29:04,920
mal so 8085% von diesen 
Angriffen vermieden. 

551
00:29:09,960 --> 00:29:12,440
Das kommt natürlich ein bisschen
mit dem Nachteil, dass es, wenn 

552
00:29:12,440 --> 00:29:16,320
ich jetzt einen ganz wichtigen 
Security Hotfix habe, den auch 

553
00:29:16,320 --> 00:29:19,600
erst nach 48 Stunden bekomme. 
Hier kann ich aber beruhigen, 

554
00:29:19,600 --> 00:29:23,640
man kann dafür natürlich auch 
Ausnahmen definieren, das heißt,

555
00:29:23,640 --> 00:29:27,160
wenn ich jetzt weiß, das ist 
genau ein Paket, von dem ich 

556
00:29:27,160 --> 00:29:29,520
irgend aus irgendeinem Grund 
weiß, dass es ein Security 

557
00:29:29,520 --> 00:29:31,960
Hotfix ist und der ist sauber, 
dann kann ich natürlich sagen, 

558
00:29:31,960 --> 00:29:33,880
den darf ich dann trotzdem 
früher installieren oder der 

559
00:29:33,880 --> 00:29:36,720
Defender bot darf den das schon 
früher vorschlagen oder sowas, 

560
00:29:37,040 --> 00:29:38,320
aber. 
Habe ich kann das generell 

561
00:29:38,320 --> 00:29:42,080
konfigurieren, wenn wir jetzt 
mal auf dieser in dieser npm 

562
00:29:42,080 --> 00:29:43,920
Welt bleiben? 
Ich kann zum Beispiel eine, also

563
00:29:43,920 --> 00:29:47,920
wenn ich in Pnpm verwende, da 
kann ich diese pnpm Workspace 

564
00:29:47,920 --> 00:29:50,680
Punkt jammel Datei anlegen und 
da kann ich zum Beispiel sagen, 

565
00:29:50,680 --> 00:29:53,680
es gibt eine Minimum Release Age
und ich kann das nämlich sagen, 

566
00:29:53,760 --> 00:29:56,560
da exkludiere ich aber Pakete, 
die zum Beispiel aus meiner 

567
00:29:56,560 --> 00:29:59,200
Firma kommen oder eine ganz 
bestimmte Liste kann ich da 

568
00:29:59,200 --> 00:30:01,120
pflegen, das heißt es lohnt sich
absolut so ein. 

569
00:30:01,480 --> 00:30:05,600
Pnpm Workspace yammel Datei 
anzulegen und damit so ein 

570
00:30:05,600 --> 00:30:08,760
bisschen für so einen Delay zu 
sorgen, wenn ihr nicht auf Pnpm 

571
00:30:08,760 --> 00:30:10,720
seid, kann man das auch in der 
Package Chase machen. 

572
00:30:10,720 --> 00:30:12,840
Wir würden aber ganz klar, weil 
wir gleich auch noch ein paar 

573
00:30:12,840 --> 00:30:15,840
andere Sachen eingehen Pnpm 
empfehlen, wenn ihr in dem Java 

574
00:30:15,840 --> 00:30:17,280
Script Eco System unterwegs 
seid. 

575
00:30:17,640 --> 00:30:20,880
Und gerade für Unternehmen 
besteht ja zudem die Möglichkeit

576
00:30:20,880 --> 00:30:24,120
und viele machen das auch, 
bereits eigene Registrys zu 

577
00:30:24,120 --> 00:30:26,160
betreiben. 
Das ist jetzt für vielleicht 

578
00:30:26,160 --> 00:30:29,760
mich als Einzel developer nicht 
wirklich praktikabel, aber 

579
00:30:29,760 --> 00:30:33,280
gerade für Unternehmen nicht nur
eine Möglichkeit, um intern 

580
00:30:33,280 --> 00:30:36,800
eigene Pakete zu publizieren und
eben Unternehmen zu verteilen, 

581
00:30:36,960 --> 00:30:43,680
sondern auch öffentliche Pakete 
quasi als Proxy vorzuhalten und 

582
00:30:43,840 --> 00:30:46,960
dementsprechend immer zwischen 
meinem Bildprozess und der 

583
00:30:46,960 --> 00:30:49,920
Public. 
Registry zu stehen und 

584
00:30:49,920 --> 00:30:53,280
dementsprechend kann ich dann 
genau kontrollieren, welche 

585
00:30:53,280 --> 00:30:56,520
Pakete verwendet werden und ich 
kann da auch halt so ein Delay 

586
00:30:56,520 --> 00:30:59,600
einbauen. 
Ich kann sagen okay diese Pakete

587
00:30:59,600 --> 00:31:02,160
werden dort nur manuell 
aktualisiert, manuell 

588
00:31:02,160 --> 00:31:05,280
hinzugefügt oder es gibt quasi 
ein Pull through, aber das 

589
00:31:05,280 --> 00:31:08,800
vielleicht auch nur mit 
zeitlicher Verzögerung und damit

590
00:31:08,800 --> 00:31:11,280
kann ich dann natürlich 
sicherstellen, dass ich einen 

591
00:31:11,280 --> 00:31:15,360
weiteren quasi sicherheitsriegel
in diese Lieferkette einbaue, 

592
00:31:15,360 --> 00:31:17,560
den ich kontrollieren kann, um 
einfach zu verhindern. 

593
00:31:17,640 --> 00:31:19,920
Verhindern, dass irgendjemand 
aus Versehen in meinem 

594
00:31:19,920 --> 00:31:23,640
Unternehmen hier irgendwelche 
kompromittierten Pakete 

595
00:31:23,640 --> 00:31:26,560
installiert, bedeutet natürlich 
auch, ich muss irgendwo 

596
00:31:26,960 --> 00:31:29,600
sicherstellen, dass die Leute 
nicht aus versehen dann doch 

597
00:31:29,600 --> 00:31:33,000
Pakete von einem öffentlichen 
Mpm ziehen, indem ich das 

598
00:31:33,000 --> 00:31:35,600
vielleicht über die Firewall 
blocke oder ähnliches und nur 

599
00:31:35,600 --> 00:31:39,720
halt meinen Proxy freigebe, was 
auch vielleicht für die 

600
00:31:39,720 --> 00:31:42,640
Developer am Ende nicht die 
beste Developer Experience ist. 

601
00:31:42,640 --> 00:31:43,920
Insbesondere wenn ich 
vielleicht. 

602
00:31:44,480 --> 00:31:46,560
Damit noch nicht so viel 
Erfahrung habe, oder ich benutze

603
00:31:46,560 --> 00:31:49,680
jetzt irgendwelche Coding Agent,
die nicht richtig konfiguriert 

604
00:31:49,680 --> 00:31:52,000
sind und gar nicht wissen, dass 
sie auf meine lokale Registry 

605
00:31:52,000 --> 00:31:54,240
zugreifen sollen. 
Das heißt die benutzen dann 

606
00:31:54,240 --> 00:31:55,920
irgendwelche Pakete, die 
vielleicht bei mir im 

607
00:31:55,920 --> 00:31:59,200
Unternehmen gar nicht verfügbar 
sind und dann renne ich da immer

608
00:31:59,200 --> 00:32:02,800
wieder gegen Wände, das heißt, 
das hat Auswirkungen auf die 

609
00:32:03,040 --> 00:32:07,080
Developer Experience, aber ist 
ja definitiv auch etwas, was die

610
00:32:07,080 --> 00:32:09,440
Sicherheit erhöht und ich 
glaube, man muss da wirklich 

611
00:32:09,440 --> 00:32:12,240
die. 
Die Balance treffen insbesondere

612
00:32:12,480 --> 00:32:16,320
wie man dieses System 
konfiguriert und welche 

613
00:32:16,320 --> 00:32:18,960
Möglichkeiten es dennoch gibt, 
vielleicht in bestimmten 

614
00:32:18,960 --> 00:32:22,560
Bereichen die Public Registrys 
zu verwenden für Pakete, wo man 

615
00:32:22,560 --> 00:32:24,840
vielleicht irgendwie erstmal 
Prototypen baut etc. 

616
00:32:25,320 --> 00:32:27,160
Ich glaube, da habe ich auch 
eine ziemlich starke Meinung zu 

617
00:32:27,160 --> 00:32:30,240
diesen zentralen Registrys. 
Ich würde das auf gar keinen 

618
00:32:30,240 --> 00:32:33,360
Fall so aufsetzen, dass da nur 
freigegebene Pakete drin sind. 

619
00:32:33,360 --> 00:32:36,800
Ich glaube, das schränkt eine 
eine Developer Experience, aber 

620
00:32:36,800 --> 00:32:40,320
auch irgendwo eine. 
Ja, eine eine Kreativität oder 

621
00:32:40,320 --> 00:32:44,960
einen gewissen Innovationsstream
zu sehr ein. 

622
00:32:44,960 --> 00:32:46,520
Also ich würde da gar auf gar 
keinen Fall irgendwie ein 

623
00:32:46,520 --> 00:32:48,560
Ticketsystem bauen, was dann 
jede Library manuell 

624
00:32:48,560 --> 00:32:51,120
freischaltet, sondern wenn man 
das macht, dann so, wie malte 

625
00:32:51,120 --> 00:32:53,480
gerade gesagt hat, er durch so 
ein, man nennt das einen Puls 

626
00:32:53,480 --> 00:32:57,240
through Cash, also dass ich 
quasi meine meine registrys oder

627
00:32:57,240 --> 00:32:59,920
bisschen meine Projekte so 
anweise wieder in der javastrip 

628
00:32:59,920 --> 00:33:04,440
Welt kann ich das über so eine 
npmrc Datei ja machen und sagen,

629
00:33:04,440 --> 00:33:08,080
du holst dir immer was aus 
dieser Registry und auch für für

630
00:33:08,080 --> 00:33:10,440
Python und so was kann ich dann 
so einen Standard upstream dann 

631
00:33:10,440 --> 00:33:13,360
eben irgendwie sagen und in 
dieser Registry die dann 

632
00:33:13,360 --> 00:33:15,600
unternehmensweit ist, da finde 
ich die internen Pakete, aber da

633
00:33:15,600 --> 00:33:18,320
finde ich auch alle öffentlichen
Pakete, aber vielleicht schon 

634
00:33:18,320 --> 00:33:20,960
mit so einem Delay oder so einem
Holdback konfiguriert und 

635
00:33:20,960 --> 00:33:23,360
vielleicht habe ich da auch noch
einen Scanner, der da regelmäßig

636
00:33:23,680 --> 00:33:26,160
drüber geht und er kann 
natürlich dann auch tracken, 

637
00:33:26,160 --> 00:33:28,080
welche Pakete überhaupt 
irgendwie bei mir installiert 

638
00:33:28,080 --> 00:33:31,480
wurden. 
So richtig erzwingen kann ich 

639
00:33:31,480 --> 00:33:33,920
das natürlich nicht, das ist 
halt extrem schwierig. 

640
00:33:34,760 --> 00:33:37,600
Es gibt ein paar Sachen, wo ich 
das kann. 

641
00:33:37,600 --> 00:33:40,720
Ich kann zum Beispiel da 
irgendwie es es gibt Tools über 

642
00:33:40,720 --> 00:33:43,960
alle meine Repositories hinweg 
checken, ob eine Punkt NPMRC 

643
00:33:43,960 --> 00:33:46,960
entsprechend angelegt und 
konfiguriert wird. 

644
00:33:47,280 --> 00:33:51,080
PNPM hat auch sowas wie config 
dependencies, da kann ich dann 

645
00:33:51,080 --> 00:33:55,120
so Konfigurationen und 
Berechtigungen und sowas zentral

646
00:33:55,120 --> 00:33:58,560
in so ein gemeinsames Config 
Paket auslagern und dann muss 

647
00:33:58,560 --> 00:34:01,440
ich eben alle meine Developer 
anweisen dieses config Paket zu 

648
00:34:01,440 --> 00:34:03,640
referenzieren. 
Aber wenn ich sie wirklich, 

649
00:34:03,640 --> 00:34:05,440
wirklich hart im Unternehmen 
umsetzen will, wie du gerade 

650
00:34:05,440 --> 00:34:08,239
gesagt hast, eigentlich nur mit 
Infrastruktur, und das ist dann 

651
00:34:08,239 --> 00:34:09,920
oft schon schwieriger. 
Ich glaube, da geht es eher 

652
00:34:09,920 --> 00:34:14,400
darum, dass die Developer das 
Know How haben und ohnehin die 

653
00:34:14,400 --> 00:34:18,000
Library an oder diese zentral 
Registry anbinden wollen, weil 

654
00:34:18,000 --> 00:34:20,320
sie da auch die 
unternehmensintern Pakete finden

655
00:34:20,719 --> 00:34:23,920
und dann kann man zum Beispiel 
bei Python sagen, dass sie keine

656
00:34:23,920 --> 00:34:26,920
extra ur LS oder sowas erlauben 
wollen, dass man einfach sagt 

657
00:34:26,920 --> 00:34:29,239
okay ich, ich muss um mich 
ohnehin einmal gegen diese 

658
00:34:29,239 --> 00:34:30,560
Library authentifizieren, weil 
das. 

659
00:34:31,000 --> 00:34:33,120
Paket das Projekt baut sonst gar
nicht, braucht die internen 

660
00:34:33,120 --> 00:34:35,840
Pakete und da finde ich auch 
alle anderen Sachen. 

661
00:34:35,840 --> 00:34:38,000
Aber wie gesagt, ich glaube, da 
gibt es so eine richtig schöne 

662
00:34:38,000 --> 00:34:41,280
Lösung, dass man das zentral 
dann alle anderen Pakete packet 

663
00:34:41,280 --> 00:34:44,480
Registry es erlaubt würde nur 
über so Firewall Sachen gehen, 

664
00:34:44,480 --> 00:34:47,639
dass ich sagen kann du darfst 
gar nicht auf npmjs oder irgend 

665
00:34:47,639 --> 00:34:51,199
so was drauf. 
Aber ja weiß ich nicht, ist 

666
00:34:51,199 --> 00:34:52,400
glaube ich nicht so richtig, 
dass. 

667
00:34:53,560 --> 00:34:56,000
Der richtige Weg? 
Ich würde eher sagen, lass uns 

668
00:34:56,000 --> 00:35:00,120
dafür sorgen, dass alle diese 
Punkt NPMRC oder eben respektive

669
00:35:00,120 --> 00:35:03,160
für die anderen Plattformen 
andere Konfigurationsdateien so 

670
00:35:03,160 --> 00:35:05,360
Konfriert haben, dass sie auch 
die zentrale Registry zeigen. 

671
00:35:05,880 --> 00:35:08,120
Aber die darf auf gar keinen 
Fall so ein Innovations bottle 

672
00:35:08,120 --> 00:35:10,000
Lack werden. 
Dann hat sie ja gerade auch noch

673
00:35:10,000 --> 00:35:13,600
gesagt, dass wir unser Posting 
Store entsprechend konfigurieren

674
00:35:13,600 --> 00:35:16,000
sollen. 
Ich glaube ganz pauschal 

675
00:35:16,000 --> 00:35:19,040
deaktivieren führt natürlich 
auch dazu, dass manche Pakete 

676
00:35:19,040 --> 00:35:21,520
einfach nicht mehr sich richtig 
installieren lassen, weil sie 

677
00:35:21,520 --> 00:35:24,960
das immer noch legitim nutzen, 
aber dann muss ich natürlich 

678
00:35:24,960 --> 00:35:28,880
schauen, okay kann ich das so 
konfigurieren, dass es 

679
00:35:28,880 --> 00:35:32,400
vielleicht nur bei bestimmten 
Paketen ausgeführt wird? 

680
00:35:32,920 --> 00:35:35,360
Und weil sonst wird das 
natürlich auch wieder zu Frust, 

681
00:35:35,360 --> 00:35:37,920
wenn ich halt bestimmte Packages
einfach nicht mehr verwenden 

682
00:35:37,920 --> 00:35:41,840
kann, weil diese halt darauf 
ausgelegt sind, dass das Ganze 

683
00:35:42,960 --> 00:35:44,800
konfiguriert ist und 
funktioniert. 

684
00:35:45,040 --> 00:35:47,080
Also von daher muss man da 
vielleicht schauen, dass man da 

685
00:35:47,080 --> 00:35:50,880
ein gewisses Whitelisting 
erlaubt, aber am Ende sind es 

686
00:35:50,880 --> 00:35:55,440
immer diese Balancen zwischen 
Einfachheit und Developer 

687
00:35:55,440 --> 00:35:58,720
Experience und zusätzlicher 
Sicherheit, die ich natürlich 

688
00:35:58,720 --> 00:36:01,040
durch diese Schranken dann 
entsprechend. 

689
00:36:01,280 --> 00:36:04,720
Reinziehen kann. 
Und dazu gehört natürlich auch, 

690
00:36:05,360 --> 00:36:07,680
dass ich mir ganz genau 
überlegen muss, okay, was führe 

691
00:36:07,680 --> 00:36:12,160
ich eigentlich auf meine 
developer Maschine aus und wenn 

692
00:36:12,160 --> 00:36:15,040
wir jetzt darüber reden, dass 
wir keine Post Install Skripte 

693
00:36:15,040 --> 00:36:17,640
mehr erlauben wollen, könnte man
ja auch einen Schritt weiter 

694
00:36:17,640 --> 00:36:20,480
gehen und sagen, ja, eigentlich 
darf ich gar keine Tools 

695
00:36:20,480 --> 00:36:23,360
installieren, die einfach 
irgendwie mit meinen Rechten auf

696
00:36:23,360 --> 00:36:26,160
der auf dem Terminal auf der CI 
ausgeführt werden. 

697
00:36:26,640 --> 00:36:28,800
Ja, das ist wahrscheinlich nicht
falsch. 

698
00:36:29,440 --> 00:36:31,760
Das ist natürlich auch nicht 
realitätsnah, aber vielleicht 

699
00:36:31,760 --> 00:36:34,840
kann dieses Tool ja irgendwie. 
Also ich sollte zumindest mal 

700
00:36:34,840 --> 00:36:36,560
kein komplett 
unvertrauenswürdiges Tool, 

701
00:36:36,560 --> 00:36:39,680
sondern irgendwas was ein 
populäres Tool und dann 

702
00:36:39,680 --> 00:36:42,080
vielleicht mit diesem Delay, das
kann ich mir noch überlegen, ob 

703
00:36:42,080 --> 00:36:44,640
er auf gar keinen Fall mit Admin
Rechten zum Beispiel oder ich 

704
00:36:44,640 --> 00:36:47,480
muss ja nicht alle Tools global 
ausführen, ich kann sie ja 

705
00:36:47,480 --> 00:36:49,440
wirklich nur in die Projekte 
rein installieren, in denen ich 

706
00:36:49,440 --> 00:36:52,320
dann genau dieses Tool brauche, 
wenn sie eben über eine packet 

707
00:36:52,320 --> 00:36:55,440
Registry kommen, die. 
Ich glaube damit auf jeden Fall.

708
00:36:55,560 --> 00:36:59,760
Also diese ganzen CLI Tools, die
muss ich genauso behandeln. 

709
00:37:00,320 --> 00:37:04,400
Und ja, am Ende auch kann ich 
mich, muss ich mich trotzdem 

710
00:37:04,480 --> 00:37:07,720
dann damit abfinden, dass ich 
darüber auch mir Schadsoftware 

711
00:37:07,720 --> 00:37:12,040
reinholen kann, aber ich kann ja
bestimmte Dinge tun, wir haben 

712
00:37:12,040 --> 00:37:14,160
ja gerade darüber gesprochen, 
ich kann Reprovite diese 

713
00:37:14,160 --> 00:37:17,120
Einstellungen machen und sagen, 
Nein, keine Post in Soul Skripte

714
00:37:17,120 --> 00:37:18,760
ich. 
Ich kann zum Beispiel auch wenn 

715
00:37:18,760 --> 00:37:21,360
ich jetzt sage, okay ich kann, 
weil ihr sagt, inzwischen ja 

716
00:37:21,360 --> 00:37:24,880
okay pnpm cool, aber wir haben 
auch noch developer, die nutzen 

717
00:37:24,880 --> 00:37:27,480
aber Jahren oder das normale 
Npm, und da kann ich bestimmte 

718
00:37:27,480 --> 00:37:30,520
Dinge nicht einstellen, auch das
kann ich versuchen zu erzwingen,

719
00:37:30,520 --> 00:37:32,640
zum Beispiel, ich kann zum 
Beispiel in der Package Jason 

720
00:37:32,640 --> 00:37:35,720
von meinem Repo sagen, es gibt 
ein Pre install Script und da 

721
00:37:35,720 --> 00:37:41,720
gibt es das das Pre install 
script npx only allow pnpm, das 

722
00:37:41,720 --> 00:37:43,880
heißt, damit würde ich 
erzwingen, dass alle Leute in 

723
00:37:43,880 --> 00:37:47,640
meinem Projekt Pnpm verwenden. 
Es sind auch Dinge, die kann ich

724
00:37:47,640 --> 00:37:50,480
dann vielleicht über so eine 
Gerätekonfig standardisiert 

725
00:37:50,480 --> 00:37:52,960
ausrollen. 
Oder ich mach mir irgendwas, was

726
00:37:53,440 --> 00:37:56,440
ja sicherstellt, dass alle meine
Repositories in der gleichen 

727
00:37:56,440 --> 00:37:58,240
Konfiguration sind. 
Da gibt es auch Tools, die das 

728
00:37:58,240 --> 00:38:01,360
dieses checken. 
Also es gibt ja Wege drumherum 

729
00:38:01,600 --> 00:38:05,360
und trotzdem ist es mir noch mal
wichtig zu sagen, Hey, am Ende 

730
00:38:05,360 --> 00:38:07,800
so ganz 100% sicher kann man 
sich nicht schützen, es kann ja 

731
00:38:07,800 --> 00:38:09,760
auch sein, dass ich mir ein CLI 
Tool installiert habe, was dann 

732
00:38:09,760 --> 00:38:13,760
irgendwann aufwacht und da 
Schadcode ausführt, obwohl das 

733
00:38:13,760 --> 00:38:17,320
halt lange gut aussah und diese.
Diese, dieses Delay in dieser 

734
00:38:17,320 --> 00:38:19,200
holdback Zeit schon lange rum 
ist. 

735
00:38:19,680 --> 00:38:23,920
Und deswegen würde ich noch mal 
gerne letzten Endes darauf 

736
00:38:23,920 --> 00:38:27,360
aufmerksam machen. 
Ich muss davon ausgehen, dass 

737
00:38:27,360 --> 00:38:31,600
mein developer Rechner 
kompromittiert werden kann, da 

738
00:38:31,600 --> 00:38:36,080
haben keine langlebigen Tokens 
zu liegen, da hat keine Dot 11 

739
00:38:36,080 --> 00:38:41,440
Datei zu liegen mit einem mit 
einem Key zu einem AI Modell 

740
00:38:41,440 --> 00:38:44,640
oder sowas was ich für mehr als 
nur so ein bisschen testen 

741
00:38:44,800 --> 00:38:48,360
verwende und. 
Secrets haben in einem Passwort 

742
00:38:48,360 --> 00:38:52,320
Volt zu liegen, gegen den ich 
mich authentifizieren muss. 

743
00:38:53,280 --> 00:38:55,840
Private Keys, selbst wenn sie 
irgendwo liegen, die gehören in 

744
00:38:55,840 --> 00:38:58,120
einen Passwort Manager, da 
gehört ein Passwort auf den 

745
00:38:58,120 --> 00:39:02,000
private Key und dieser Passwort 
und der Passwort Manager muss 

746
00:39:02,000 --> 00:39:06,080
geschützt sein, es gibt keine, 
es gibt nur kurzlebige O aus 

747
00:39:06,080 --> 00:39:09,000
Tokens die wahrscheinlich dann 
irgendwie wieder interaktiv 

748
00:39:09,000 --> 00:39:12,600
durch eine 2 Faktor Mechanismus.
Aktualisiert werden müssen. 

749
00:39:12,600 --> 00:39:15,760
Auf meinem Rechner muss ich 
davon ausgehen, wenn es ein 

750
00:39:15,760 --> 00:39:18,560
developer Rechner ist. 
Der braucht ohnehin elevated 

751
00:39:18,560 --> 00:39:22,240
Rechte, dass der kompromittiert 
werden kann und wir müssen uns 

752
00:39:22,240 --> 00:39:24,000
an die eigene Nase fassen, das 
hat mir glaube ich auch schon 

753
00:39:24,000 --> 00:39:28,240
mal bei dieser shiho Loot Folge 
gesagt wo dieses diese Scanner 

754
00:39:28,240 --> 00:39:30,880
Tools verwendet die dann auf der
Maschine nach. 

755
00:39:31,920 --> 00:39:34,880
Nach secrets scannen, das kann 
ich selber auch einfach mal 

756
00:39:34,880 --> 00:39:37,160
machen, ohne dass es gerade 
einen Angriff gibt und einfach 

757
00:39:37,160 --> 00:39:40,400
mal schauen, wo habe ich auf 
meiner Maschine Dateien, die da 

758
00:39:40,400 --> 00:39:43,360
eigentlich nicht hingehören, 
denn wir sind heute, wir haben 

759
00:39:43,360 --> 00:39:46,200
keine Dot End Dateien mehr 
irgendwo liegen zu haben, wir 

760
00:39:46,200 --> 00:39:49,920
haben keine unverschlüsselten 
oder nicht passwortgeschützten 

761
00:39:49,920 --> 00:39:52,840
private Keys irgendwo liegen zu 
haben und wenn wir API Keys 

762
00:39:52,840 --> 00:39:55,840
irgendwas brauchen, dann gehören
die in einen in einen Volt, da 

763
00:39:55,840 --> 00:39:58,680
gibt es hashicop Volt zum 
Beispiel oder es gibt auch von 

764
00:39:58,680 --> 00:40:02,680
jedem Cloud Hersteller. 
Was wir wie Azure Key wollt und 

765
00:40:02,680 --> 00:40:05,160
so weiter da haben die drin zu 
liegen und dagegen 

766
00:40:05,160 --> 00:40:07,360
authentifiziere ich mich auch 
nicht mit einem Client ID oder 

767
00:40:07,360 --> 00:40:10,080
einem Client secret, sondern mit
einer Identität. 

768
00:40:10,840 --> 00:40:12,960
Du hast ja gerade gesagt, wir 
müssen eigentlich davon 

769
00:40:12,960 --> 00:40:16,840
ausgehen, dass wir betroffen 
sein können und dementsprechend 

770
00:40:16,840 --> 00:40:21,200
ist natürlich wichtig zu wissen,
ob ihr oder ob euer Produkt 

771
00:40:21,200 --> 00:40:24,320
betroffen ist. 
Und dafür könnt ihr natürlich 

772
00:40:24,320 --> 00:40:27,360
eine Supply Chain Security 
Lösung verwenden. 

773
00:40:27,520 --> 00:40:30,320
Aber ganz wichtig dafür ist, 
dass man natürlich weiß, welche 

774
00:40:30,320 --> 00:40:33,600
Depensies habe ich eigentlich 
und welche Depensies haben diese

775
00:40:33,600 --> 00:40:38,320
wiederum und da hatten wir auch 
schon mal eine Folge zu gemacht 

776
00:40:38,560 --> 00:40:40,760
rund um Software Bill of 
Material zu. 

777
00:40:40,840 --> 00:40:43,840
Ich glaube, das war Folge 103. 
Wer das noch mal nachhören 

778
00:40:43,840 --> 00:40:47,600
möchte, wo dann tatsächlich für 
alle Softwareprodukte, die wir 

779
00:40:47,600 --> 00:40:51,840
bauen, aufgeschlüsselt wird, 
welche Dependencies wir haben 

780
00:40:52,000 --> 00:40:55,440
und dann kann man natürlich dann
auf die nächsten Ebenen runter 

781
00:40:55,440 --> 00:40:58,960
gehen und schauen, was sind 
entsprechend dort die Transitive

782
00:40:58,960 --> 00:41:01,200
Dependencies, also welche 
Dependencies haben meine 

783
00:41:01,200 --> 00:41:03,760
Dependencies und so weiter und 
können das dann entsprechend 

784
00:41:03,760 --> 00:41:06,800
nachvollziehen und. 
Und entweder über unsere 

785
00:41:06,800 --> 00:41:09,840
automatisierte Supply Chain 
Security Lösungen sofort 

786
00:41:09,840 --> 00:41:13,520
alarmiert werden, wenn eine 
unserer Dependencies in unserer 

787
00:41:13,520 --> 00:41:19,120
Lieferkette kompromittiert ist. 
Oder natürlich automatisiert 

788
00:41:19,120 --> 00:41:22,480
auch Updates bestimmter Packages
durchführen lassen. 

789
00:41:23,120 --> 00:41:25,800
Genau, weil das ja noch viel 
schlimmer betroffen zu sein und 

790
00:41:25,800 --> 00:41:27,840
das nicht zu merken. 
Also man braucht ja irgendwie 

791
00:41:27,840 --> 00:41:29,920
eine Möglichkeit, dass wenn 
jetzt die nächste News folge 

792
00:41:29,920 --> 00:41:32,680
gehört und wir sagen okay, jetzt
gibt es das nächste populäre 

793
00:41:32,680 --> 00:41:34,880
Paket, ich nehme jetzt einfach 
mal keine Ahnung, Projekt ich. 

794
00:41:35,160 --> 00:41:37,320
In der Version 123 das ist 
betroffen. 

795
00:41:37,320 --> 00:41:39,360
Ihr hört das hier im Podcast 
oder lest das irgendwo online. 

796
00:41:39,360 --> 00:41:41,560
Ihr braucht natürlich eine 
Möglichkeit rauszufinden, ah 

797
00:41:41,560 --> 00:41:45,000
okay habe ich denn diese Version
in irgendeinem meiner meiner 

798
00:41:45,000 --> 00:41:48,880
Projekte und dafür ist dieser s 
bom dieser Software Build of 

799
00:41:48,880 --> 00:41:52,040
Material elementar. 
Ich glaube, wenn ihr Gitter 

800
00:41:52,040 --> 00:41:55,600
Projekte habt, da gibt es sogar 
irgendwo glaubt es ist in einem 

801
00:41:55,600 --> 00:41:59,040
Paket mit drin, kann man sich 
dann diesen Software Build of 

802
00:41:59,040 --> 00:42:00,720
Material eben runterladen und 
nach genau dieser Versionsnummer

803
00:42:00,720 --> 00:42:03,400
dann auch suchen, aber das ist 
natürlich super wichtig. 

804
00:42:04,280 --> 00:42:05,680
Dass man irgendwie ne 
Möglichkeit überhaupt 

805
00:42:05,680 --> 00:42:08,760
rauszufinden, ob man das Projekt
verwendet, was da betroffen ist.

806
00:42:08,800 --> 00:42:12,080
Und wenn ihr selber nicht nur 
konsumiert, sondern auch 

807
00:42:12,080 --> 00:42:16,080
produziert, sprich ihr published
extern eure Pakete für die 

808
00:42:16,080 --> 00:42:19,160
Nutzung von anderen. 
Das kann im Unternehmen sein, 

809
00:42:19,160 --> 00:42:22,080
das kann aber auch. 
In der Software oder Open Source

810
00:42:22,080 --> 00:42:24,960
Community sein? 
Dann tragt ihr natürlich noch 

811
00:42:24,960 --> 00:42:28,000
zusätzliche Verantwortung für 
die Lieferkette und 

812
00:42:28,000 --> 00:42:30,960
dementsprechend, und das hatten 
wir in diesen ganzen Folgen, um 

813
00:42:30,960 --> 00:42:33,520
shai Hulu auch schon 
angesprochen, müsst ihr 

814
00:42:33,520 --> 00:42:37,200
sicherstellen, dass euer Account
über die entsprechende 

815
00:42:37,200 --> 00:42:41,680
Authentifizierung verfügt, das 
heißt 2 Faktor Authentifizierung

816
00:42:41,920 --> 00:42:47,040
ihr müsst euren Publish Prozess 
so absichern, dass nur legitime.

817
00:42:47,600 --> 00:42:51,440
Ci Pipelines oder ihr selber 
publizieren dürft. 

818
00:42:51,840 --> 00:42:55,200
Ihr solltet natürlich immer mit 
minimalen rechten arbeiten und 

819
00:42:55,680 --> 00:42:58,000
wie du gerade schon gesagt 
hattest, auf deiner Lokalen, die

820
00:42:58,000 --> 00:43:00,680
waren auch paar Maschinen, auf 
keinen Fall langlebige Tokens 

821
00:43:00,680 --> 00:43:04,160
nutzen, die es bei einer 
Kompromittierung der lokalen 

822
00:43:04,160 --> 00:43:08,080
Maschine anderen erlaubt deine 
Packages zu manipulieren zu 

823
00:43:08,080 --> 00:43:11,520
überschreiben, das heißt das 
Schlimmste was passieren kann 

824
00:43:11,520 --> 00:43:15,120
ist mein Publishing Account wird
kompromittiert, mein Github 

825
00:43:15,120 --> 00:43:17,760
Account wo das? 
Open Source Projekt liegt wird 

826
00:43:17,760 --> 00:43:21,120
übernommen und dann, ohne dass 
ich es vielleicht selber merke, 

827
00:43:21,120 --> 00:43:26,160
bin ich derjenige, bei dem diese
Lieferkette entsprechend 

828
00:43:26,320 --> 00:43:29,760
zusammenbricht und 
dementsprechend brauche ich auch

829
00:43:29,760 --> 00:43:32,160
immer die Unterstützung 
eigentlich von anderen. 

830
00:43:32,160 --> 00:43:35,280
Ich sollte nicht irgendwie als 
Single Maintainer arbeiten, 

831
00:43:35,440 --> 00:43:38,000
sondern immer auch mit anderen 
zusammenarbeiten und es hier 

832
00:43:38,000 --> 00:43:41,520
auch dann in meiner 
Konfiguration erzwingen, dass 

833
00:43:41,520 --> 00:43:45,920
zum Beispiel immer 4 Augen 
Prinzip bei Pull request Merges.

834
00:43:46,800 --> 00:43:50,680
Und gerade bei sensiblen 
Änderungen insbesondere intensiv

835
00:43:50,680 --> 00:43:54,000
drauf geschaut wird. 
Ganz häufig versuchen auch Leute

836
00:43:54,000 --> 00:43:56,560
über wir hatten auch darüber 
gesprochen in der Vergangenheit 

837
00:43:56,560 --> 00:43:59,120
über irgendwelche kleineren 
Fixes in deinem Open Source 

838
00:43:59,120 --> 00:44:02,320
Projekt sich dein Vertrauen zu 
erschleichen und dann irgendwann

839
00:44:02,320 --> 00:44:04,800
kommen dann die größeren PR s 
und Du guckst da gar nicht mehr 

840
00:44:04,800 --> 00:44:07,040
so drauf, weil du der Person 
vielleicht schon das Vertrauen 

841
00:44:07,040 --> 00:44:10,960
gegeben hast und dann merkst du 
vielleicht selber den Schadcode 

842
00:44:10,960 --> 00:44:14,080
in dein Projekt mit rein und. 
Und da ist es natürlich 

843
00:44:14,560 --> 00:44:19,320
wichtiger denn je, mit anderen 
zusammenarbeiten und umso 

844
00:44:19,320 --> 00:44:22,480
kritischer dein Paket ist, umso 
gefährlicher ist es, wenn du 

845
00:44:22,720 --> 00:44:24,800
alleine dafür verantwortlich 
bist. 

846
00:44:24,800 --> 00:44:29,760
Weil dann bist du der einzige 
Punkt, der kompromittiert werden

847
00:44:29,760 --> 00:44:32,880
muss, um das Ganze zu übernehmen
und zu missbrauchen. 

848
00:44:33,600 --> 00:44:35,440
Und hier vielleicht an der 
Stelle auch noch mal der Aufruf,

849
00:44:35,600 --> 00:44:39,920
wenn eure Firma eigentlich auf 
23 npm nu Geld. 

850
00:44:40,640 --> 00:44:43,360
Mavin was auch immer Paketen 
aufsetzt, die irgendein armer 

851
00:44:43,840 --> 00:44:46,960
Open Source, Maintainer oder 
Maintainerin da vorne alleine 

852
00:44:47,120 --> 00:44:49,120
betreut, dann denkt doch mal 
drüber nach oder? 

853
00:44:49,120 --> 00:44:51,640
Sprecht das doch mal irgendwie 
an, ob man diese Menschen nicht 

854
00:44:51,640 --> 00:44:53,640
irgendwie entlasten kann und 
entlasten kann man sie in der 

855
00:44:53,640 --> 00:44:56,560
Regel, indem man sie finanziert.
Also ich finde immer noch mal, 

856
00:44:56,720 --> 00:45:00,080
es werden noch immer viel zu 
wenig Open Source Maintainer 

857
00:45:00,160 --> 00:45:02,480
gesponsort, es gibt ja 
mittlerweile über github so ein 

858
00:45:02,720 --> 00:45:05,200
Sponsoring wo ich wirklich nicht
einmal einen Betrag, sondern 

859
00:45:05,200 --> 00:45:08,520
regelmäßig wieso ein eigentlich 
wieso eine Lizenz für einen Open

860
00:45:08,520 --> 00:45:11,680
Source? 
Produkt erwerben kann, indem ich

861
00:45:11,680 --> 00:45:15,560
da regelmäßig und wenn es 100€ 
sind oder sowas im Monat. 

862
00:45:15,560 --> 00:45:19,120
Aber wenn das viele machen, dann
lohnt es sich eben A dieses 

863
00:45:19,120 --> 00:45:21,760
Paket weiter zu maintainen das 
heißt es gibt auch eine gewisse 

864
00:45:21,760 --> 00:45:26,480
Zusage oder Sicherheit, dass 
dieses Produkt auch oder dieses 

865
00:45:26,480 --> 00:45:28,800
diese Library eben auch 
möglichst lange noch noch weiter

866
00:45:28,800 --> 00:45:32,200
überlegt und b ist das auch der 
Nummer 1 Hebel um Maintainer zu 

867
00:45:32,200 --> 00:45:33,680
entlasten, die das dann 
vielleicht mal irgendwann 

868
00:45:33,680 --> 00:45:36,800
Vollzeit machen können und 
weniger anfällig für Social 

869
00:45:36,800 --> 00:45:38,480
Engineering sind. 
Ich mache selber auch viel, 

870
00:45:38,480 --> 00:45:40,960
viel, viel zu wenig, aber. 
Aber es war mir wichtig, das 

871
00:45:40,960 --> 00:45:42,800
hier noch mal zu erwähnen. 
Und jetzt haben wir über diese 

872
00:45:42,800 --> 00:45:46,320
ganzen Maßnahmen gesprochen und 
mal angenommen, ich bin jetzt 

873
00:45:46,320 --> 00:45:49,360
dafür verantwortlich für die 
Developer Plattform in meiner 

874
00:45:49,360 --> 00:45:51,800
Firma und ich gehe jetzt hin und
befolg das alles, das heißt, ich

875
00:45:51,800 --> 00:45:55,120
setze irgendwie meinen eigenen 
Package Manager auf, irgendwie. 

876
00:45:55,600 --> 00:45:59,440
Mit oder meine eigene Registry 
als Proxy konfiguriere die so 

877
00:45:59,440 --> 00:46:02,400
entsprechend, dass meine 
Developer die nutzen können. 

878
00:46:02,480 --> 00:46:05,600
Ich blocke den Zugriff auf 
Public registrys ich mache eine 

879
00:46:05,600 --> 00:46:08,640
Group Policy, die es verbietet 
Post Install Skripte 

880
00:46:08,640 --> 00:46:12,240
auszuführen, ich scanne für 
Secrets, um sicherzustellen, 

881
00:46:12,240 --> 00:46:16,160
dass auf den developer Maschinen
keine Secrets liegen, die dann 

882
00:46:16,160 --> 00:46:19,440
leaken können. 
Das heißt, ich mache eigentlich 

883
00:46:19,520 --> 00:46:23,360
alles richtig, alles irgendwie 
möglichst gut, um mich hier 

884
00:46:23,360 --> 00:46:26,400
abzusichern. 
Für die teuersten Security Tools

885
00:46:26,400 --> 00:46:30,560
ein bin ich dann sicher, also 
alles was wir gerade besprochen 

886
00:46:30,560 --> 00:46:33,440
haben ist jetzt abgehakt, bin 
ich dann auf der sicheren Seite?

887
00:46:34,160 --> 00:46:35,960
Nee, natürlich nicht. 
Hatten wir ja schon ein paar Mal

888
00:46:35,960 --> 00:46:38,440
jetzt hier irgendwie gesagt, 
100%, sicher kannst du gar nicht

889
00:46:38,440 --> 00:46:40,800
sein, du kannst den Blast radius
durch sowas natürlich 

890
00:46:40,800 --> 00:46:43,320
minimieren, aber kann man jetzt 
irgendwie eine randomware 

891
00:46:43,320 --> 00:46:47,240
Attacke dich trifft und alle 
Dateien verschlüsselt sind? 

892
00:46:47,280 --> 00:46:48,920
Jetzt auch nicht viel. 
Kannst du auch nicht viel 

893
00:46:48,920 --> 00:46:51,280
machen, kannst halt dafür 
sorgen, dass du durch gute 

894
00:46:51,280 --> 00:46:53,440
backup Prozesse und sowas das 
alles wieder wiederherstellen 

895
00:46:53,440 --> 00:46:55,280
kannst. 
Ich würde jetzt auf gar keinen 

896
00:46:55,280 --> 00:46:59,000
Fall in Panik verfallen und 
sagen, jetzt wird hier alles 

897
00:46:59,000 --> 00:47:01,280
wirklich abgeschottet und ich 
erlaube jetzt gar kein mehr, 

898
00:47:01,280 --> 00:47:05,520
sogar die npmjs Website oder 
sowas zu zu besuchen. 

899
00:47:06,240 --> 00:47:09,600
Ich glaube man muss schon auch 
irgendwie eine gute Balance 

900
00:47:09,600 --> 00:47:12,120
zwischen dieser Developer 
Experience finden und auch wie 

901
00:47:12,120 --> 00:47:15,120
du gerade gesagt hast, auch, 
dass irgendwie ich. 

902
00:47:15,640 --> 00:47:19,480
Vielleicht einen KI Assistenten 
sauber arbeiten lassen kann, 

903
00:47:19,480 --> 00:47:22,040
dass ich selber hier keine 
Innovation irgendwie hemme, 

904
00:47:22,040 --> 00:47:25,200
indem die Leute resignieren und 
sagen, Ach ja gut, bis das Paket

905
00:47:25,200 --> 00:47:28,320
mal bei uns in der Patch in der 
Package Registry ist oder sowas,

906
00:47:28,960 --> 00:47:31,400
das glaube ich funktioniert ich 
glaube du frustrierst die eine 

907
00:47:31,400 --> 00:47:34,000
Hälfte der Leute und die andere 
Hälfte der Leute machst du 

908
00:47:34,000 --> 00:47:37,880
kreativer im Regelbruch, weil 
das ist dann einfach schlechte 

909
00:47:37,880 --> 00:47:40,960
Security die einfach nur 
einschränkt ohne wirklich zu 

910
00:47:40,960 --> 00:47:43,520
schauen was ist denn sinnvoll 
und was steht denn aber auch 

911
00:47:43,520 --> 00:47:46,160
überhaupt in irgendeinem 
Verhältnis das deswegen glaube 

912
00:47:46,160 --> 00:47:47,720
ich eigentlich schon, dass wir 
hier in dieser Folge einen ganz 

913
00:47:47,720 --> 00:47:50,120
guten Mittelweg gefunden haben 
mit diesem, Hey entforced doch 

914
00:47:50,120 --> 00:47:53,000
mal alle in dieser Java Group 
Welt PNPM zu verwenden und nicht

915
00:47:53,000 --> 00:47:56,760
mehr npm oder Jahren entforced 
mal alle, dass sie über eure 

916
00:47:56,760 --> 00:47:58,800
Registry einen Impuls Group 
Crash haben oder wenn ihr das 

917
00:47:58,880 --> 00:48:03,280
für die falsche Variante haltet,
sorgt zumindest mal dafür, dass 

918
00:48:03,280 --> 00:48:06,960
es dass Pakete default mäßig so 
einen Delay, so einen holdback 

919
00:48:07,120 --> 00:48:09,760
Timer von sagen wir mal 48 
Stunden oder sowas haben. 

920
00:48:09,760 --> 00:48:11,800
Ich glaube man kann da schon 
relativ viel machen, der 

921
00:48:11,800 --> 00:48:13,440
Industrie fehlt es meiner 
Meinung nach noch so ein 

922
00:48:13,440 --> 00:48:16,800
bisschen daran, dass wirklich. 
Ja, zuverlässig, zentral an 

923
00:48:16,800 --> 00:48:19,360
einer Stelle auszurollen. 
Pn PM hat da so ein paar 

924
00:48:19,360 --> 00:48:23,000
Konzepte für wie diese zentrale 
config Registry, aber da muss 

925
00:48:23,000 --> 00:48:25,120
ich auch wirklich dafür sorgen, 
dass alle Projekte das 

926
00:48:25,360 --> 00:48:27,600
einsetzen. 
Bisschen was kann ich vielleicht

927
00:48:27,600 --> 00:48:30,320
auch über sowas wie Device 
Management oder sowas ausrollen,

928
00:48:30,560 --> 00:48:33,040
aber ich glaube es ist wichtig, 
dass eine zentrale Packet 

929
00:48:33,040 --> 00:48:35,080
Registry es nicht irgendwie zum 
Bottle neck wird oder neue 

930
00:48:35,080 --> 00:48:37,600
Pakete ewig dauern oder diese 
ganzen Security Scanner die ich 

931
00:48:37,600 --> 00:48:41,400
habe viel zu viele Warnungen 
werfen, sodass Teams diese 

932
00:48:41,400 --> 00:48:44,080
Alerts einfach nur noch 
wegklicken, ich glaube. 

933
00:48:44,440 --> 00:48:48,880
Die beste Security ist die, bei 
der der sichere Weg auch der 

934
00:48:48,880 --> 00:48:52,880
bequemste Weg ist, weil mir 
einfach viel schon vorher 

935
00:48:52,880 --> 00:48:56,240
eingerichtet wird. 
Es ist natürlich auch eine eine,

936
00:48:56,240 --> 00:48:59,680
eine Schulungsmaßnahme, ich muss
die Awareness schaffen und dann 

937
00:48:59,760 --> 00:49:02,840
darf die aber auch nicht im Weg 
stehen, wenn Leute schnell oder 

938
00:49:02,840 --> 00:49:05,520
innovativ arbeiten möchten. 
Ja, ich glaube. 

939
00:49:05,960 --> 00:49:08,800
Zusammenfassend können wir 
sagen, diese Angriffe, die 

940
00:49:08,800 --> 00:49:12,240
kommen häufig trotzdem immer 
noch bei dir an, weil sie über 

941
00:49:12,240 --> 00:49:15,440
legitime Kanäle kommen, denen du
vertraust. 

942
00:49:15,440 --> 00:49:17,760
Dementsprechend muss man 
wirklich das Bewusstsein dafür 

943
00:49:17,760 --> 00:49:21,800
haben, dass es passieren kann 
und eine einzelne Maßnahme wird 

944
00:49:21,800 --> 00:49:23,920
dort nicht die Lösung sein. 
Du hast gerade noch mal alles 

945
00:49:23,920 --> 00:49:26,800
zusammengefasst, was ich machen 
kann in diesen verschiedenen 

946
00:49:26,800 --> 00:49:30,080
Schichten und umso mehr dieser 
Schichten ich bei mir umgesetzt 

947
00:49:30,080 --> 00:49:34,080
habe und umso geringer ist das 
Risiko und am Ende. 

948
00:49:34,840 --> 00:49:37,440
Bist du nicht gegen alles 
geschützt, aber du kannst halt 

949
00:49:37,680 --> 00:49:41,920
sichergehen, dass nicht dein 
gesamtes Unternehmen lahmgelegt 

950
00:49:41,920 --> 00:49:45,360
wird oder du selber Verteiler 
von Malware bist. 

951
00:49:45,440 --> 00:49:48,560
Und ich glaube, das fasst es 
ganz gut zusammen, dass man da 

952
00:49:48,560 --> 00:49:52,080
diesen diesen Mittelweg finden 
muss zwischen Developer 

953
00:49:52,080 --> 00:49:55,120
Experience und Sicherheit. 
Und ich glaube, das ist etwas, 

954
00:49:55,120 --> 00:49:56,800
was glaube ich, uns beiden 
extrem. 

955
00:49:57,280 --> 00:50:00,240
Wichtig ist, und ich hoffe, 
diese Folge hat euch geholfen, 

956
00:50:00,240 --> 00:50:04,160
da diesen Überblick zu bekommen.
Also was kann man tun, was 

957
00:50:04,160 --> 00:50:09,120
sollte man tun und wie kann man 
sich möglichst gut auch in 

958
00:50:09,120 --> 00:50:12,160
dieser neuen Welt, wo immer 
häufiger diese Dinge passieren, 

959
00:50:12,320 --> 00:50:16,560
gegen diese Risiken absichern. 
Und die Gefahr, die ist Real. 

960
00:50:16,640 --> 00:50:20,080
Also diese Angriffe werden immer
cleverer und man merkt auch, 

961
00:50:20,480 --> 00:50:22,840
dass man diese Lage schon 
deutlich verbessern kann, indem 

962
00:50:22,840 --> 00:50:25,280
man dieses Vertrauen, was wir in
der Vergangenheit blind 

963
00:50:25,280 --> 00:50:28,560
geschenkt haben. 
Nicht mehr genauso blind wie in 

964
00:50:28,560 --> 00:50:32,200
der Vergangenheit verschenkt. 
Aber das Thema ist jetzt 

965
00:50:32,200 --> 00:50:34,720
allgegenwärtig und das ist ja 
der Grund, warum wir diese Folge

966
00:50:34,720 --> 00:50:37,120
gemacht haben, wo ihr uns nach 
unserer Meinung oder unserer 

967
00:50:37,120 --> 00:50:39,680
Sicht auf diese Dinge gefragt 
habt und wie, wie sehr und wie 

968
00:50:39,680 --> 00:50:42,480
restriktiv man da sein sollte. 
Uns interessiert aber auch 

969
00:50:42,480 --> 00:50:45,600
wahnsinnig, was macht ihr denn 
heute in euren Unternehmen 

970
00:50:45,600 --> 00:50:48,760
dagegen, weil ihr habt jetzt 
hier unsere beiden Meinungen 

971
00:50:48,760 --> 00:50:50,720
gehört, wir haben aber auch die 
Weisheit hier nicht mit Löffeln 

972
00:50:50,720 --> 00:50:53,760
gefressen, wir haben uns jetzt 
in der Vorbereitung dieser Folge

973
00:50:53,760 --> 00:50:56,160
natürlich ganz gut. 
Und hoffentlich auch Recht 

974
00:50:56,160 --> 00:50:59,680
umfassend informiert. 
Und trotzdem spiegelt das ja 

975
00:50:59,680 --> 00:51:02,800
nicht immer die Realität ab und 
das könnt ihr auch gerne anonym,

976
00:51:03,040 --> 00:51:04,880
aber auch gerne, wenn ihr 
möchtet, so dass man da noch mal

977
00:51:04,880 --> 00:51:07,680
eine Nachfrage stellen kann. 
In den Kommentaren von der Folge

978
00:51:07,680 --> 00:51:10,400
auf Youtube oder auf Spotify 
oder auch wenn ihr es nicht 

979
00:51:10,400 --> 00:51:12,640
öffentlich machen wollt, gerne 
per E Mail mit den Adresse in 

980
00:51:12,640 --> 00:51:15,240
den in den Show Notes zu. 
Mit uns mal besprechen, weil das

981
00:51:15,240 --> 00:51:16,880
würde uns interessieren. 
Wir haben jetzt hier irgendwie 

982
00:51:16,880 --> 00:51:19,440
so eine, so eine Welt 
aufgezeichnet, die auch weit weg

983
00:51:19,440 --> 00:51:22,560
davon ist, perfekt zu sein, aber
zumindest schon mal erstmal 

984
00:51:22,560 --> 00:51:26,080
glaube ich, ganz gute Maßnahmen 
gegensteuert gegen diese sehr 

985
00:51:26,080 --> 00:51:30,200
sehr akute und reale 
Gefahrenlage, aber wie real ist 

986
00:51:30,200 --> 00:51:31,320
das denn bei euch im 
Unternehmen? 

987
00:51:31,320 --> 00:51:35,280
Macht ihr euch Gedanken dazu, 
ist das Thema präsent, was sind 

988
00:51:35,280 --> 00:51:38,680
eure Maßnahmen dagegen, das 
würde uns einfach wahnsinnig mal

989
00:51:38,680 --> 00:51:40,800
interessieren und mit Sicherheit
auch den Rest der Community. 

990
00:51:41,240 --> 00:51:44,800
Also wenn ihr da euren Beitrag 
zu beisteuern wollt und eure 

991
00:51:44,800 --> 00:51:47,640
Sicht, die Dinge oder eure 
Realität schildern wollt, freuen

992
00:51:47,640 --> 00:51:49,840
wir uns sicherlich alle, wenn 
ihr das in den Kommentaren tut. 

993
00:51:50,480 --> 00:51:53,520
Und wenn euch die Folge weiter 
gebracht hat, lasst natürlich 

994
00:51:53,520 --> 00:51:55,600
gerne eine positive Bewertung 
da. 

995
00:51:55,600 --> 00:51:58,800
Und wenn ihr nach der Folge 
hingeht und die ein oder andere 

996
00:51:58,800 --> 00:52:02,960
Maßnahme umgesetzt habt, dann 
lasst uns das gerne wissen. 

997
00:52:02,960 --> 00:52:05,920
Allgemein freuen wir uns 
natürlich immer über Feedback 

998
00:52:05,920 --> 00:52:09,320
und Austausch mit euch und wie 
wir am Anfang gesagt haben, 

999
00:52:09,320 --> 00:52:11,160
besonders freuen wir uns 
natürlich, wenn ihr uns. 

1000
00:52:11,240 --> 00:52:15,440
Uns einen Kaffee ausgebt über 
bei mir coffee.com könnt ihr 

1001
00:52:15,440 --> 00:52:18,520
dies schnell und einfach tun und
werdet dann auch in einer der 

1002
00:52:18,520 --> 00:52:20,920
nächsten Folgen erwähnt. 
Sonst. 

1003
00:52:21,040 --> 00:52:23,040
Freuen wir uns natürlich drüber,
wenn ihr nächste Woche wieder 

1004
00:52:23,040 --> 00:52:25,280
mit dabei seid. 
Der to do Cast erscheint 

1005
00:52:25,280 --> 00:52:27,920
wöchentlich, jeden Montag gibt 
es eine neue Folge, immer 

1006
00:52:27,920 --> 00:52:31,600
abwechselnd eine News Folge oder
eine Themenfolge wie diese hier 

1007
00:52:32,000 --> 00:52:33,680
und dann schauen wir doch mal, 
ob wir in der nächsten News 

1008
00:52:33,680 --> 00:52:37,480
folge leider vom nächsten 
kompromittierten Paket berichten

1009
00:52:37,480 --> 00:52:40,400
müssen oder ob es uns erspart 
bleibt. 

1010
00:52:40,480 --> 00:52:41,400
Bleibt also dran. 
Dran. 

1011
00:52:41,400 --> 00:52:44,000
Es bleibt spannend. 
Wir kratzen immer alle 2 Wochen 

1012
00:52:44,000 --> 00:52:47,560
die Tech und Developer News, der
irgendwie genau dieser 2 Wochen 

1013
00:52:47,560 --> 00:52:50,320
zusammen oder machen eine 
Themenfolge wie diese hier. 

1014
00:52:50,800 --> 00:52:52,960
Wir freuen uns, wenn ihr bei 
beiden dabei seid, wenn ihr es 

1015
00:52:52,960 --> 00:52:56,640
noch nicht getan habt, abonniert
gerne den Podcast und sonst habt

1016
00:52:56,640 --> 00:53:00,560
eine gute Woche, habt eine gute 
Zeit und schreibt ganz viel 

1017
00:53:00,560 --> 00:53:01,680
Code. 
Bis dann.