1
00:00:00,160 --> 00:00:05,200
Die ovas top 10 bekommen etwa 
alle 4 Jahre ein Update und 2025

2
00:00:05,200 --> 00:00:07,920
ist es wieder so weit. 
Wir schauen uns heute die 2 

3
00:00:07,920 --> 00:00:11,360
neuen Kategorien an Software, 
Supply Chain, Fadiers und 

4
00:00:11,360 --> 00:00:15,400
misshandling of exceptional 
conditions wir analysieren die 

5
00:00:15,400 --> 00:00:18,320
strategische Verschiebung und 
diskutieren, wie sich das auf 

6
00:00:18,320 --> 00:00:21,760
euren Entwickleralltag auswirkt.
Außerdem besprechen wir, wie 

7
00:00:21,760 --> 00:00:24,960
realistisch die Umsetzung bei 
kleinen Teams ist und was das 

8
00:00:24,960 --> 00:00:27,600
für die appsact Zukunft 
allgemein bedeutet. 

9
00:00:27,840 --> 00:00:30,880
Hallo und ganz herzlich 
Willkommen zu einer 

10
00:00:30,880 --> 00:00:35,520
Nigelnagelneuen, ofenfrischen 
Folge vom to do Cast, dem 

11
00:00:35,520 --> 00:00:38,960
deutschen Developer Podcast mit 
Malte Lantin. 

12
00:00:38,960 --> 00:00:40,960
Den habt ihr gerade eben schon 
im Intro gehört, der ist 

13
00:00:40,960 --> 00:00:45,520
Strategic Solutions Engineer bei
Github und mit mir Robin Manuel 

14
00:00:45,520 --> 00:00:49,120
Thiel, Ich bin Direktor für AI 
und Cloud bei dem E Commerce 

15
00:00:49,120 --> 00:00:52,920
Unternehmen Jtl diesen Podcast 
hier machen wir aber privat und 

16
00:00:52,920 --> 00:00:56,640
teilen hier quasi. 
Unsere Erfahrungen aus echten 

17
00:00:56,640 --> 00:00:59,840
Kundenprojekten oder wir das 
diskutieren aktuelle Themen, die

18
00:00:59,840 --> 00:01:04,800
die Developer Welt bewegen oder 
wir Care News zusammen und ein 

19
00:01:04,800 --> 00:01:07,280
ganz dickes Thema, was die 
developer Welt so ein bisschen 

20
00:01:07,280 --> 00:01:10,480
diese Woche bewegt hat, ist wie 
immer das Thema Security. 

21
00:01:10,640 --> 00:01:12,360
Diesmal freuen wir uns aber, 
dass wir nicht über eine 

22
00:01:12,360 --> 00:01:15,920
Security Schwachstelle berichten
müssen, Gott sei Dank, das war 

23
00:01:15,920 --> 00:01:18,240
ja auch dieses Jahr einigermaßen
häufig der Fall. 

24
00:01:18,800 --> 00:01:22,080
Sondern dass wir über ein Update
der overs Top Ten sprechen. 

25
00:01:22,320 --> 00:01:25,920
Aber wie immer gehen wir kurz 
vorher noch durch unsere 

26
00:01:25,920 --> 00:01:28,640
Kaffeeliste, weil wir haben 
wieder zahlreichen Kaffee 

27
00:01:28,640 --> 00:01:32,960
bekommen und wollen natürlich 
auch uns herzlich bedanken. 

28
00:01:32,960 --> 00:01:37,440
Insbesondere starten wir hier 
bei David und David hat uns 3 

29
00:01:37,440 --> 00:01:40,640
Kaffee ausgegeben. 
Außerdem haben wir von Stefan 

30
00:01:40,640 --> 00:01:44,240
einen Kaffee bekommen und von 
Maximilian auch einen Kaffee. 

31
00:01:44,800 --> 00:01:47,600
Ganz, ganz, ganz lieben Dank. 
Das hilft uns durch die kalten 

32
00:01:47,600 --> 00:01:50,720
Wintertage oder wenn man morgens
schon früh aufstehen muss. 

33
00:01:50,720 --> 00:01:54,640
Und es ist noch dunkel draußen, 
dann freuen wir uns auf Kaffee, 

34
00:01:54,640 --> 00:01:56,720
auf den Nacken von der 
Community, wenn auch ihr uns 

35
00:01:56,720 --> 00:01:58,800
einen Kaffee ausgeben wollt, 
freuen wir uns natürlich sehr. 

36
00:01:59,120 --> 00:02:01,840
Findet ihr einen Link zu bei mir
Coffee unten in den Shownotes. 

37
00:02:02,400 --> 00:02:07,040
Und damit starten wir direkt in 
das Thema, und zwar die ovas top

38
00:02:07,120 --> 00:02:10,280
10 und für diejenigen, die sich 
noch nicht mit dem Thema 

39
00:02:10,280 --> 00:02:13,520
auseinandergesetzt haben. 
Ovasp ist eine Foundation, die 

40
00:02:13,520 --> 00:02:17,680
Open Worldwide Application 
Security Project Foundation und 

41
00:02:17,680 --> 00:02:21,520
kümmert sich als non Profit 
darum, die Software Security 

42
00:02:21,520 --> 00:02:25,200
allgemein zu verbessern und sie 
stellt Open Source Tools bereit 

43
00:02:25,200 --> 00:02:29,000
und zahlreiche Initiativen. 
Rund um das Thema Application 

44
00:02:29,000 --> 00:02:33,200
Security und ganz wichtig und 
dafür kennen die meisten diese 

45
00:02:33,200 --> 00:02:37,760
Foundation, ist die Top Ten, und
das sind die größten und 

46
00:02:37,760 --> 00:02:41,280
wichtigsten Bedrohungsszenarien 
und Angriffsvektoren für 

47
00:02:41,280 --> 00:02:45,360
Applikationen zu einer gegebenen
Zeit und dementsprechend werden 

48
00:02:45,360 --> 00:02:48,520
sie auch regelmäßig. 
Aktualisiert und ganz häufig 

49
00:02:48,520 --> 00:02:51,920
wenn wir über Application 
Security sprechen, geht es im 

50
00:02:51,920 --> 00:02:56,080
ersten Schritt darum, zumindest 
diese ovas top 10 abzudecken, 

51
00:02:56,080 --> 00:02:59,280
weil das die häufigsten 
Schwachstellen sind, die auch 

52
00:02:59,280 --> 00:03:01,840
aktuell ausgenutzt werden. 
Und da gibt es ein paar 

53
00:03:01,840 --> 00:03:05,200
Änderungen bei diesen Top 10 und
die wollen wir heute ein 

54
00:03:05,200 --> 00:03:08,400
bisschen zusammenbringen und 
einfach mal ein bisschen im 

55
00:03:08,400 --> 00:03:11,760
Detail schauen, was gibt es da 
neues und als Überraschung für 

56
00:03:11,760 --> 00:03:14,480
mich. 
Es ist nichts mit AI dabei. 

57
00:03:14,480 --> 00:03:16,600
Ich hatte so ein bisschen damit 
gerechnet, dass jetzt auch in 

58
00:03:16,600 --> 00:03:20,480
dieser Folge das AI Thema so ein
bisschen Einzug erhält und wir 

59
00:03:20,480 --> 00:03:23,040
jetzt da irgendwas mit prompt 
injection finden. 

60
00:03:23,040 --> 00:03:27,440
Aber nein, es dreht sich hier 
weiterhin um ganz klassische 

61
00:03:27,440 --> 00:03:30,640
Application Security. 
Oh stimmt, das ist mir ist mir 

62
00:03:30,640 --> 00:03:32,480
gar nicht aufgefallen beim 
Lesen, aber du hast natürlich 

63
00:03:32,480 --> 00:03:35,680
recht, eigentlich würde man auch
denken, dass jetzt wir haben 

64
00:03:35,680 --> 00:03:37,680
auch die letzten Folgen noch 
ganz, ganz viel über die. 

65
00:03:38,160 --> 00:03:41,280
Ja, Security Implikationen von 
Agents und so weiter gesprochen,

66
00:03:41,280 --> 00:03:42,480
dass es da jetzt gar nicht dabei
ist. 

67
00:03:42,480 --> 00:03:45,360
Aber es geht hier wirklich um, 
ja quasi Code, den wir schreiben

68
00:03:45,360 --> 00:03:47,120
und wie malte gerade schon sagt,
das wird auch häufig so als 

69
00:03:47,120 --> 00:03:50,600
Referenzliste einfach 
hinzugezogen, wenn man sie die 

70
00:03:50,600 --> 00:03:53,560
eigene Applikation überprüft 
oder auch wenn man irgendwie 

71
00:03:53,560 --> 00:03:57,280
externe beauftragt, irgendwie so
einen Pen Test zu machen, dann 

72
00:03:57,280 --> 00:04:00,400
wird auch oft zumindest erstmal 
diese Top ten Liste abgearbeitet

73
00:04:00,400 --> 00:04:02,720
und. 
Und die wird immer so etwa alle 

74
00:04:02,720 --> 00:04:05,960
4 Jahre aktualisiert. 
Das letztes Mal war eben im Jahr

75
00:04:05,960 --> 00:04:09,280
2021 und jetzt vor wenigen 
Tagen, am 6. 

76
00:04:09,280 --> 00:04:14,160
November ist der Release 
Candidate von der neuen OVAS top

77
00:04:14,200 --> 00:04:19,200
10 2025 auf dieser Global App 
SEC Conference vorgestellt 

78
00:04:19,200 --> 00:04:22,560
worden und in der Regel heißt 
das auch, dass das quasi die 

79
00:04:22,560 --> 00:04:24,760
fast finale Version ist. 
Also man rechnet da nicht mehr 

80
00:04:24,760 --> 00:04:28,080
mit irgendwelchen großen. 
Änderungen im Ranking oft ist 

81
00:04:28,080 --> 00:04:30,480
das so, dass so ein Release 
Candidate gegenüber der finalen 

82
00:04:30,480 --> 00:04:33,200
Version dann vielleicht noch 
irgendwie ein bisschen die 

83
00:04:33,200 --> 00:04:35,080
Formulierung geschärft wird oder
sowas. 

84
00:04:35,080 --> 00:04:36,880
Aber das Ranking sollte 
irgendwie gleich bleiben. 

85
00:04:37,080 --> 00:04:39,000
Deswegen haben wir gedacht, das 
ist doch irgendwie eine schöne 

86
00:04:39,000 --> 00:04:41,360
Idee, da mal eine Folge 
zuzumachen zu diesem Update. 

87
00:04:42,240 --> 00:04:46,480
Und was sich genau geändert hat 
und was das für uns bedeutet, 

88
00:04:46,640 --> 00:04:49,040
das schauen wir uns heute im 
Detail an. 

89
00:04:49,040 --> 00:04:51,840
Und du hattest gerade gesagt, 
ein paar Dinge sind gleich 

90
00:04:51,840 --> 00:04:54,840
geblieben, einige haben sich 
verändert und einfach noch mal. 

91
00:04:54,840 --> 00:04:57,840
Also re Cap, Wir hatten schon 
mal eine Folge über die gesamten

92
00:04:57,840 --> 00:05:00,680
Overs top ten, aber als re Cap 
haben wir uns überlegt, wir 

93
00:05:00,680 --> 00:05:03,600
gehen einmal noch. 
Die ganze Liste durch, also die 

94
00:05:03,600 --> 00:05:08,640
kompletten 10 und erwähne kurz, 
was sich da verschoben hat, was 

95
00:05:08,640 --> 00:05:11,520
bisher auch auf dem gleichen 
Platz war und was sich jeweils 

96
00:05:11,520 --> 00:05:14,640
hinter den einzelnen Begriffen 
verbirgt. 

97
00:05:14,640 --> 00:05:16,560
Und ich denke mal, wir machen es
vielleicht ein bisschen 

98
00:05:16,560 --> 00:05:19,040
abwechselnd, dann fang du 
einfach mal an und ich mach dann

99
00:05:19,040 --> 00:05:22,160
das zweite. 
Ja, Platz 1 unangefochten 

100
00:05:22,160 --> 00:05:27,680
tatsächlich ist Broken Access 
Control deswegen unangefochtet, 

101
00:05:27,680 --> 00:05:31,200
weil es auch schon im Jahr 2021,
die Platz 1 war. 

102
00:05:31,680 --> 00:05:34,480
Der Platz 1 glaube ich, der 
Platz 1 war da, hat sich also 

103
00:05:34,480 --> 00:05:37,080
nicht so viel geändert und 
darunter versteht man eben 

104
00:05:37,080 --> 00:05:39,040
einfach schwache 
Zugriffskontrollen, die es 

105
00:05:39,040 --> 00:05:43,040
erlauben, Angreifern auf Daten 
oder Funktionen zuzugreifen, auf

106
00:05:43,040 --> 00:05:44,440
die sie keine Berechtigung 
haben. 

107
00:05:44,440 --> 00:05:47,680
Das kann 2 Dimensionen annehmen,
das kann so ein bisschen Social 

108
00:05:47,680 --> 00:05:49,840
Engineering annehmen, dass ich 
wirklich irgendjemandem 

109
00:05:50,160 --> 00:05:52,640
versuche, irgendwie 
aufzuquatschen, dass ich da 

110
00:05:52,640 --> 00:05:54,560
jetzt ganz dringend 
Berechtigungen brauche, also 

111
00:05:54,560 --> 00:05:57,360
dass man jemandem was falsches 
gibt, das können aber auch 

112
00:05:57,360 --> 00:06:00,560
schwache Passwörter, fehlende 2.
Faktor Authentifizierung. 

113
00:06:01,360 --> 00:06:04,400
Das klassische Passwort auf dem 
Posted Zettel auf den Laptop 

114
00:06:04,400 --> 00:06:07,360
geklebt sein und es ist 
eigentlich schon sehr 

115
00:06:07,360 --> 00:06:09,920
alarmierend, dass das nach wie 
vor auf Platz 1 ist, aber eben 

116
00:06:09,920 --> 00:06:13,280
unverändert Broken Access 
Control auf dem ersten Platz. 

117
00:06:13,360 --> 00:06:17,120
Auf Platz 2 haben wir Security 
Miss Configuration und hier 

118
00:06:17,120 --> 00:06:18,640
sehen wir die erste große 
Veränderung. 

119
00:06:18,640 --> 00:06:23,040
Das war 2021 noch auf Platz 5, 
jetzt auf Platz 2 und das 

120
00:06:23,040 --> 00:06:27,040
bedeutet im Wesentlichen, dass 
Systeme falsch konfiguriert sind

121
00:06:27,040 --> 00:06:30,680
und damit ungewollt. 
Lücken geschaffen werden, die 

122
00:06:30,680 --> 00:06:34,880
halt Zugriffe ermöglichen, zum 
Beispiel über offene Ports oder 

123
00:06:34,880 --> 00:06:37,360
nicht geänderte 
Standardpasswörter, werden auch 

124
00:06:37,360 --> 00:06:40,080
in der Vergangenheit mal darüber
gesprochen, dass bestimmte 

125
00:06:40,080 --> 00:06:43,000
Funktionalitäten nicht 
deaktiviert wurden, zum Beispiel

126
00:06:43,000 --> 00:06:45,840
in einem Webserver irgendwelche 
Default configurations. 

127
00:06:46,080 --> 00:06:50,520
Nicht geändert wurden und damit 
Angreifern Zugriff auf meine 

128
00:06:50,520 --> 00:06:53,520
Systeme ermöglicht werden. 
Platz 3 ist ein ganz neuer 

129
00:06:53,520 --> 00:06:54,880
Platz, also eine ganz neue 
Kategorie. 

130
00:06:54,880 --> 00:06:57,280
Die gab es vorher noch nicht in 
der Liste und die kommt dafür 

131
00:06:57,280 --> 00:06:59,840
zumindest die regelmäßigen 
Hörerinnen und Hörer von diesem 

132
00:06:59,840 --> 00:07:04,320
Podcast nicht überraschend. 
Es ist die Software Supply Chain

133
00:07:04,400 --> 00:07:07,280
Failures Kategorie und das sind 
eben Sicherheitsprobleme, die 

134
00:07:07,280 --> 00:07:10,720
entstehen, wenn schädliche oder 
fehlerhafte Komponenten aus 

135
00:07:10,720 --> 00:07:13,680
externen Quellen. 
In unsere eigene Software 

136
00:07:13,680 --> 00:07:18,000
gelangen und spätestens seit dem
großen Chai Hulut Angriff. 

137
00:07:18,000 --> 00:07:20,440
Das ist dieser Wurm, der diese 
NPM Supply Chain, haben wir mal 

138
00:07:20,440 --> 00:07:21,520
eine eigene Folge auch 
zugemacht. 

139
00:07:21,520 --> 00:07:24,560
Wer das Nachhören möchte, quasi 
die ganze npm Welt da in 

140
00:07:24,560 --> 00:07:29,040
Strecken versetzt hat, gibt es 
eigentlich immer mehr Angriffe 

141
00:07:29,040 --> 00:07:31,040
die gar nicht mehr auf mich 
direkt, sondern auf irgendeine 

142
00:07:31,040 --> 00:07:34,720
Software die ich irgendwo 
indirekt verwende passieren und 

143
00:07:34,720 --> 00:07:37,440
deswegen hat es auch diese neue 
Kategorie auf Platz 3 geschafft.

144
00:07:37,840 --> 00:07:40,240
Das schauen wir uns ja gleich 
noch mal im Detail an. 

145
00:07:40,240 --> 00:07:43,840
Aber zunächst Platz 4 
cryptographic fadeers, das war 

146
00:07:43,840 --> 00:07:46,240
auf Platz 2. 
Jetzt auf Platz 4. 

147
00:07:46,240 --> 00:07:48,800
Das heißt nicht, dass das Thema 
weniger wichtig ist, sondern die

148
00:07:48,800 --> 00:07:51,520
anderen sind einfach. 
Relevanter und wichtiger 

149
00:07:51,520 --> 00:07:55,280
geworden und hier geht es darum,
dass wir entweder unsichere, 

150
00:07:55,280 --> 00:07:58,560
veraltete, falsch implementierte
Verschlüsselung verwenden und 

151
00:07:58,560 --> 00:08:02,000
damit natürlich sensible Daten 
für Angreifer zugreifbar. 

152
00:08:02,000 --> 00:08:05,360
Werden eine erfreuliche Sache. 
Auf Platz 5 ist das Thema 

153
00:08:05,360 --> 00:08:08,280
Injection, das bedeutet einfach 
generell, dass Angreifer durch 

154
00:08:08,280 --> 00:08:11,600
irgendwelche manipulierten 
Eingaben schädliche Befehle an 

155
00:08:11,600 --> 00:08:14,720
mich einschleusen können, die 
dann von meinem System 

156
00:08:14,720 --> 00:08:17,200
ausgeführt werden. 
Das prominenteste Beispiel ist 

157
00:08:17,200 --> 00:08:19,520
da wahrscheinlich die SQL 
Injection. 

158
00:08:19,920 --> 00:08:22,400
Wo ich irgendwie in einen 
Suchschlitz statt einem 

159
00:08:22,400 --> 00:08:25,520
eigentlichen Suchwort einen 
ganz, ganz in einen SQL Befehl 

160
00:08:25,520 --> 00:08:27,720
Eintippe, in der Hoffnung, dass 
der einfach so übernommen wird 

161
00:08:27,720 --> 00:08:29,520
vom Server. 
Das ist immer noch auf der 

162
00:08:29,520 --> 00:08:32,000
Liste, ist aber weniger 
geworden, das war im Jahr davor 

163
00:08:32,000 --> 00:08:34,720
eben auf Platz 3 beziehungsweise
in der Version davor nicht im 

164
00:08:34,720 --> 00:08:37,600
Jahr davor, das ist in der 2021 
er Version auf Platz 3. 

165
00:08:37,600 --> 00:08:39,720
Ist jetzt ein bisschen 
runtergerutscht auf Platz 5, 

166
00:08:39,720 --> 00:08:42,360
also nach wie vor relevant, aber
da scheinen wir uns wie 

167
00:08:42,360 --> 00:08:44,400
allgemein als Industrie etwas 
verbessert zu haben, das. 

168
00:08:45,040 --> 00:08:48,080
Auf Platz 6 finden wir jetzt in 
Secure Design. 

169
00:08:48,080 --> 00:08:51,120
Das war vorher auf Platz 4 und 
da geht es einfach um 

170
00:08:51,120 --> 00:08:54,040
Sicherheitslücken, die schon in 
der Architektur und der 

171
00:08:54,040 --> 00:08:56,240
Konzeption der Anwendung 
angelegt sind. 

172
00:08:56,400 --> 00:08:58,640
Das heißt, man hat sich nicht 
Gedanken darüber gemacht, wie 

173
00:08:58,640 --> 00:09:01,440
man die Anwendung entsprechend 
absichert oder hat einfach in 

174
00:09:01,440 --> 00:09:05,120
der Planung bestimmte Dinge 
vergessen, das jetzt auf Platz 

175
00:09:05,120 --> 00:09:07,280
6. 
Unverändert auf Platz 7 sind 

176
00:09:07,280 --> 00:09:10,560
Authentication failiers. 
Das sind Fehler in der die halt 

177
00:09:10,560 --> 00:09:13,760
in der Authentifizierung es mir 
erlauben als Angreifer, dass ich

178
00:09:13,760 --> 00:09:17,200
mich als ein anderer Benutzer 
ausgebe oder dass ich ein Login 

179
00:09:17,200 --> 00:09:20,960
System vielleicht komplett 
umgehen kann, also üblicherweise

180
00:09:20,960 --> 00:09:23,360
falsch konfigurierte 
Authentication Server, falsch 

181
00:09:23,360 --> 00:09:26,320
konfigurierte Ohr auf Protokolle
gibt immer noch Leute die sowas 

182
00:09:26,320 --> 00:09:29,600
selber bauen und wahrscheinlich 
vielleicht sich dann, da diese 

183
00:09:29,600 --> 00:09:32,320
Fehler ein deswegen 
Authentication failiers auf 

184
00:09:32,320 --> 00:09:36,080
Platz 7. 
Auf Platz 8 auch unverändert und

185
00:09:36,080 --> 00:09:38,280
ich komme mir so ein bisschen 
vor, wieso ein Radiomoderator 

186
00:09:38,280 --> 00:09:44,240
oder die Charts vorliest, sehen 
wir Software or data Integrity 

187
00:09:44,240 --> 00:09:48,000
failors, also eine Anwendung 
vertraut ungeprüft auf externe 

188
00:09:48,000 --> 00:09:51,400
und manipulierte Daten und damit
kann ich zum Beispiel Schadcode 

189
00:09:51,400 --> 00:09:55,920
ausführen oder die Anwendung 
manipulieren und damit Zugriff 

190
00:09:55,920 --> 00:09:59,160
auf Informationen erlangen, die 
ich eigentlich nicht bekommen 

191
00:09:59,160 --> 00:10:01,040
sollte. 
Platz 9 ist auch unverändert, 

192
00:10:01,040 --> 00:10:02,160
deswegen gehen wir da auch 
schnell drüber. 

193
00:10:02,160 --> 00:10:05,680
Die Kategorie heißt Logging und 
Alerting Failiers, das ist eben,

194
00:10:05,680 --> 00:10:08,720
wenn Angriffe nicht erkannt oder
gemeldet werden, dann fehlt oft 

195
00:10:08,720 --> 00:10:11,280
die Grundlage für schnelle 
Reaktionen oder eben für eine 

196
00:10:11,440 --> 00:10:15,680
nachfolgende forensische Analyse
von diesem Problem. 

197
00:10:16,000 --> 00:10:18,160
Das kann natürlich dann auch zu 
Sicherheitslücken führen, die 

198
00:10:18,160 --> 00:10:20,640
einfach länger offen sind, weil 
ich sie erst spät bemerke oder 

199
00:10:20,640 --> 00:10:22,360
wenn ich sie bemerke, nicht 
wirklich weiß, wo ich suchen 

200
00:10:22,360 --> 00:10:24,160
muss, deswegen ist das auch 
relevant. 

201
00:10:24,400 --> 00:10:27,840
Und auf Platz 10. 
Und das ist eine neue Kategorie 

202
00:10:27,840 --> 00:10:32,480
in den Top ten ist misshandling 
of exceptional conditions und 

203
00:10:32,480 --> 00:10:35,280
dahinter verbirgt sich 
fehlerhafte Behandlung von 

204
00:10:35,280 --> 00:10:37,880
Fehlersituationen von 
ungewöhnlichen Situationen wir 

205
00:10:37,880 --> 00:10:40,240
alle kennen. 
In der Softwareentwicklung 

206
00:10:40,240 --> 00:10:43,520
Exception Handling, aber das 
wird immer relevanter, weil wir 

207
00:10:43,520 --> 00:10:46,560
natürlich immer mehr auch 
Drittanbietersysteme einbinden 

208
00:10:46,560 --> 00:10:49,520
und auch immer mehr 
Fehlverhalten auftreten kann. 

209
00:10:49,520 --> 00:10:52,800
Und hier geht es darum, dass man
bestimmte Fehlersituationen 

210
00:10:52,800 --> 00:10:56,480
nicht abfängt und damit ein 
Fehlverhalten auslösen kann, was

211
00:10:56,480 --> 00:10:59,360
Angreifern erlaubt, die 
Anwendung zu manipulieren oder 

212
00:10:59,360 --> 00:11:02,320
auf Daten zuzugreifen, und das 
ist eine neue Kategorie, über 

213
00:11:02,320 --> 00:11:05,040
die sprechen wir auch gleich 
noch mal ein bisschen im Detail.

214
00:11:05,320 --> 00:11:07,160
Genau also kann man, glaube ich 
zusammenfassend sagen. 

215
00:11:07,160 --> 00:11:09,680
Also die meisten Sachen, wie wir
die Ovas Top Ten schon kennt, 

216
00:11:09,680 --> 00:11:12,960
der wird jetzt hier bei 50% 
dieser Themen nur gegähnt haben,

217
00:11:13,280 --> 00:11:15,760
aber insgesamt, es gibt 2 neue 
Kategorien, das sind eigentlich 

218
00:11:15,760 --> 00:11:17,720
die spannende Sachen, die wir 
jetzt auch in der Podcast Folge 

219
00:11:17,720 --> 00:11:19,600
uns angucken, nämlich einmal 
Platz 3. 

220
00:11:19,920 --> 00:11:23,440
Die Software Supply Chain 
Failious und den Platz 10, den 

221
00:11:23,440 --> 00:11:27,080
malte gerade vorgelesen hat, 
Misshandling of Exception und 

222
00:11:27,080 --> 00:11:30,160
exceptional conditions und. 
Und es gibt einige wirklich 

223
00:11:30,160 --> 00:11:32,040
bemerkenswerte 
Rankingverschiebungen und 

224
00:11:32,040 --> 00:11:33,240
deswegen noch mal hier als 
Betonung. 

225
00:11:33,240 --> 00:11:36,720
Das ist jetzt nicht einfach nur 
eine neu Nummerierung von dieser

226
00:11:36,720 --> 00:11:39,760
Liste, sondern eigentlich ein 
Spiegel der neuen oder sich 

227
00:11:39,760 --> 00:11:43,160
verändernden 
Bedrohungslandschaft, also so 

228
00:11:43,160 --> 00:11:45,680
ein bisschen kann man daran auch
eigentlich mal ganz kurz sehen, 

229
00:11:45,680 --> 00:11:48,080
was uns so für Security Themen 
die letzten Jahre eigentlich 

230
00:11:48,080 --> 00:11:51,040
begleitet haben, worauf wir 
jetzt heute ein bisschen mehr 

231
00:11:51,920 --> 00:11:53,880
Fokus legen müssen, deswegen 
würde ich sagen, schauen wir uns

232
00:11:53,880 --> 00:11:56,160
doch mal diese Neuzugänge an 
und. 

233
00:11:56,720 --> 00:11:58,960
Weil das ist ja wirklich so ein 
strategischer Schwenk von dieser

234
00:11:58,960 --> 00:12:02,160
Liste und fokussieren uns jetzt 
mal auf Platz 3 und Platz 10 als

235
00:12:02,160 --> 00:12:05,680
quasi Kern der Aktualisierung 
von dieser Liste. 

236
00:12:06,080 --> 00:12:07,120
Genau. 
Du hattest ja vorhin schon ein 

237
00:12:07,120 --> 00:12:10,720
bisschen was gesagt zum Thema 
Software, Supply Chain und dass 

238
00:12:10,720 --> 00:12:14,000
wir das ja in den letzten Folgen
schon auch mehrfach als Thema 

239
00:12:14,000 --> 00:12:18,400
hatten und hiermit dabei handelt
es sich um eine Erweiterung 

240
00:12:18,400 --> 00:12:21,600
einer bisherigen Kategorie 
Wolmirobland outdated 

241
00:12:21,600 --> 00:12:24,680
Components. 
Und jetzt geht es tatsächlich so

242
00:12:24,680 --> 00:12:27,600
ein bisschen um so einen 
Perspektivenwechsel, weil wir 

243
00:12:27,600 --> 00:12:30,640
natürlich in der Vergangenheit 
häufig auf die eigenen 

244
00:12:30,640 --> 00:12:33,120
Komponenten geschaut haben. 
Wir haben ganz viel Software 

245
00:12:33,120 --> 00:12:36,480
selber geschrieben, und wenn ich
sage früher, dann schauen wir da

246
00:12:36,480 --> 00:12:39,840
natürlich 10 und mehr Jahre 
zurück als das ganze Projekt in 

247
00:12:39,840 --> 00:12:43,000
die ins Leben gerufen wurde, und
da wurden natürlich ganz viele 

248
00:12:43,000 --> 00:12:45,600
Bibliotheken auch selber 
geschrieben, oder wir haben aus 

249
00:12:45,600 --> 00:12:50,320
irgendwelchen großen Frameworks,
irgendwie aus der Java net was 

250
00:12:50,320 --> 00:12:52,480
auch immer Welt Bibliotheken 
verwendet, die irgendwie vom 

251
00:12:52,480 --> 00:12:55,280
Anbieter kein. 
Haben und in den letzten Jahren 

252
00:12:55,280 --> 00:12:58,560
ist es ja immer häufiger 
geworden, dass wir diverse 

253
00:12:58,640 --> 00:13:02,360
Drittanbieter Komponenten 
verwenden, die aus der Open 

254
00:13:02,360 --> 00:13:05,280
Source Community kommen oder wie
wir auch letztes Mal besprochen 

255
00:13:05,280 --> 00:13:08,480
haben, aus einem ganz großen 
Fundus, zum Beispiel von mpm 

256
00:13:08,480 --> 00:13:09,360
Packages. 
Genau dabei muss. 

257
00:13:09,760 --> 00:13:12,840
Man jetzt natürlich heute sagen 
auch schon 2021, also in der 

258
00:13:12,840 --> 00:13:15,840
vorherigen Liste waren unter 
dieser Kategorie Audated 

259
00:13:15,840 --> 00:13:18,640
Components auch halt externe 
Pakete, die aber dann oft 

260
00:13:18,640 --> 00:13:21,360
einfach nur in der 
Versionsnummer verwaltet waren, 

261
00:13:21,360 --> 00:13:23,080
das heißt? 
Da ist dann irgendwo eine 

262
00:13:23,080 --> 00:13:25,840
Sicherheitslücke entstanden und 
ich habe die halt, die jahrelang

263
00:13:25,840 --> 00:13:28,960
nicht gepatcht und das wurde 
dann eben da beleuchtet. 

264
00:13:29,280 --> 00:13:32,080
Jetzt merkt man aber, dass die 
neuen Gefahren so eigentlich den

265
00:13:32,080 --> 00:13:37,680
gesamten Prozess vom Erstellen 
über das Verteilen auch und bis 

266
00:13:37,680 --> 00:13:43,640
hin zum Aktualisieren von meiner
Software ja abdecken, wie malte 

267
00:13:43,640 --> 00:13:46,120
schon ganz richtig gerade gesagt
hat, da sind natürlich ganz, 

268
00:13:46,120 --> 00:13:48,560
ganz viele oder viel, viel mehr 
Third Patrick Komponenten als 

269
00:13:48,560 --> 00:13:50,480
früher drin, aber. 
Aber auch hier noch mal der 

270
00:13:50,480 --> 00:13:54,240
Augenmerk, eben nicht nur in 
meinem Code, sondern vielleicht 

271
00:13:54,240 --> 00:13:56,480
auch irgendwo auf dem 
Bildserver, der ein Tool 

272
00:13:56,480 --> 00:14:00,200
verwendet, um irgendwie einen 
Helmchart zu bauen oder weil ich

273
00:14:00,200 --> 00:14:03,200
vielleicht in meiner github 
Action irgendwo ein Tool 

274
00:14:03,200 --> 00:14:05,680
verwende, was ich lange nicht 
geupdatet habe, was dann 

275
00:14:05,680 --> 00:14:09,440
wiederum eine Referenz oder eine
Abhängigkeit auf irgendwas 

276
00:14:09,440 --> 00:14:12,800
anderes hat, wo jetzt versucht 
wurde, dann irgendwie. 

277
00:14:13,360 --> 00:14:15,880
Schadcode einzufügen und so was.
Also wir müssen uns jetzt eben 

278
00:14:15,880 --> 00:14:19,120
nicht mehr nur noch unsere 
eigene Software und dessen Third

279
00:14:19,120 --> 00:14:22,240
Party Libraries angucken, 
sondern die komplette Supply 

280
00:14:22,240 --> 00:14:24,840
Chain und ich glaube, das ist so
ein bisschen hier, dieser große,

281
00:14:24,840 --> 00:14:27,280
diese große Änderung davon, 
deswegen auch diese Umbenennung 

282
00:14:27,280 --> 00:14:30,960
in Supply Chain Failers also es 
kann sein, dass ich die beste 

283
00:14:30,960 --> 00:14:32,960
Software schreibe, aber in der 
Art und Weise, wie ich sie 

284
00:14:32,960 --> 00:14:36,520
Update, wie ich Sie ausliefere, 
der letzten News folge jetzt 

285
00:14:36,520 --> 00:14:38,480
auch das Github zum Beispiel 
jetzt auch gerade hingeht. 

286
00:14:39,240 --> 00:14:41,720
Man diese unveränderbaren 
Releases baut, weil ich da ja 

287
00:14:41,720 --> 00:14:43,960
sonst vielleicht sage, 
vielleicht glaube ich, dass ich 

288
00:14:43,960 --> 00:14:47,440
die Version xy von der Software 
herunterlade, die war auch 

289
00:14:47,440 --> 00:14:51,560
jahrelang war die Version 1 512 
war das genau dieser Code und 

290
00:14:51,560 --> 00:14:55,040
heute ist irgendwie jemandem 
gelungen auf den Feed vom vom 

291
00:14:55,520 --> 00:14:57,480
Herausgeber oder Herausgeberin 
von dieser Software zuzugreifen.

292
00:14:57,480 --> 00:14:59,560
Und auf einmal ist die Version 1
512. 

293
00:15:01,040 --> 00:15:02,960
Zwar noch die mit der gleichen 
Versionsnummer, aber auf einmal 

294
00:15:02,960 --> 00:15:04,960
die mit anderem Code und all so 
Dinge. 

295
00:15:04,960 --> 00:15:06,960
Und wie gesagt, vielleicht nutze
ich den Code ja gar nicht in 

296
00:15:06,960 --> 00:15:09,840
meinem Source Code, sondern 
irgendwo in meiner Supply Chain 

297
00:15:10,000 --> 00:15:12,800
und ich glaube darauf wird hier 
gerade so ein so ein großer 

298
00:15:12,800 --> 00:15:15,840
Fokus drauf gelegt, also auf 
manipulierte Bildprozesse, auf 

299
00:15:15,840 --> 00:15:19,120
unsichere Abhängigkeiten 
irgendwo in meiner gesamten 

300
00:15:19,760 --> 00:15:22,800
Software auslieferungskette. 
Ja, und das finde ich ganz 

301
00:15:22,800 --> 00:15:24,640
interessant. 
Diese Erweiterung, dass es jetzt

302
00:15:24,640 --> 00:15:27,440
nicht nur um wirklich 
Komponenten geht im Sinne von 

303
00:15:27,440 --> 00:15:30,480
Packages, sondern auch wirklich 
Tools, die ich einsetze, 

304
00:15:30,480 --> 00:15:34,400
irgendwo in meinem Prozess oder 
vielleicht auch Drittanbieter 

305
00:15:34,400 --> 00:15:37,040
Komponenten, die ich über AP is 
anbinde, die irgendwie 

306
00:15:37,040 --> 00:15:39,520
manipuliert sein können, wie 
sich die dann meine Anwendung 

307
00:15:39,520 --> 00:15:43,440
verändern, das heißt, alles, was
irgendwie von dritten Teil 

308
00:15:43,440 --> 00:15:46,160
meiner Lieferkette ist und ein 
Teil meiner Software ist, ist 

309
00:15:46,160 --> 00:15:47,600
jetzt die. 
Enthalten. 

310
00:15:47,600 --> 00:15:50,800
Und wir sehen ja, dass 
Anwendungen immer komplexer 

311
00:15:50,800 --> 00:15:53,840
werden und immer mehr dieser 
Abhängigkeiten haben. 

312
00:15:53,840 --> 00:15:56,080
Ich glaube, wir hatten gerade 
auch in einer der letzten Folgen

313
00:15:56,400 --> 00:16:00,160
auch darüber gesprochen, dass 
man hier auch immer mehr Dinge 

314
00:16:00,160 --> 00:16:03,280
aufbaut, die von anderen gebaut 
sind und die sich nicht auch 

315
00:16:03,520 --> 00:16:06,560
nicht nur statisch als Code in 
sein Projekt reinholt, sondern 

316
00:16:06,560 --> 00:16:09,600
teilweise auch dynamisch so 
bestimmte Dinge abgerufen werden

317
00:16:09,600 --> 00:16:13,040
über AP is und damit haben wir 
natürlich eine immer größer 

318
00:16:13,040 --> 00:16:15,880
werdende oder wachsende 
Angriffsfläche und. 

319
00:16:16,160 --> 00:16:20,880
Und damit wird es natürlich auch
immer schwieriger, solche Supply

320
00:16:20,880 --> 00:16:23,840
Chain Schwachstellen zu 
identifizieren, weil wir auch 

321
00:16:23,840 --> 00:16:27,680
nicht mehr einfach nur auf 
klassische Supply Chain Security

322
00:16:27,680 --> 00:16:31,440
Tools zurückgreifen können, die 
irgendwie gucken, welche 

323
00:16:31,440 --> 00:16:33,440
Dependencies habe ich irgendwie 
in meinen. 

324
00:16:33,840 --> 00:16:36,160
In meinem Projekt drin und dann,
wie du gerade gesagt hattest, 

325
00:16:36,160 --> 00:16:38,160
sind irgendwelche Vulnerability 
databases. 

326
00:16:38,160 --> 00:16:41,520
Schaut ob diese vielleicht 
irgendwie outdatet vulnerable 

327
00:16:41,520 --> 00:16:44,320
sind und ich mehr ein Update 
ziehen muss, sondern es gibt 

328
00:16:44,320 --> 00:16:47,520
ganz viele andere Abhängigkeiten
die ich habe und die muss ich 

329
00:16:47,520 --> 00:16:51,440
natürlich mit betrachten. 
Ja, auch den zweiten Neuzugang 

330
00:16:51,440 --> 00:16:52,560
fand ich eigentlich ziemlich 
spannend. 

331
00:16:52,560 --> 00:16:55,960
Also das Thema Misshandling of 
acceptional Conditions und das 

332
00:16:55,960 --> 00:16:59,000
ist jetzt das erste Mal, dass 
eigentlich das Thema Resilienz 

333
00:16:59,000 --> 00:17:02,080
so ein bisschen Einzug in die 
ovas top 10 findet. 

334
00:17:02,600 --> 00:17:05,480
Was meint man damit? 
Damit machen wir eigentlich so 

335
00:17:05,480 --> 00:17:08,640
ein bisschen dieses Prepair to 
Fail, bereite dich darauf vor, 

336
00:17:08,640 --> 00:17:11,720
dass irgendwas schief gehen 
wird, denn in komplexen 

337
00:17:11,720 --> 00:17:14,079
Systemen, wie wir sie heutzutage
bauen, wird immer irgendwas 

338
00:17:14,079 --> 00:17:18,240
passieren und wie du damit 
umgehst, darauf kommt es 

339
00:17:18,240 --> 00:17:20,440
eigentlich an, wir haben ja 
sogar schon mal eine eigene 

340
00:17:20,440 --> 00:17:22,800
Folge zu dem Thema Chaos 
Engineering gemacht, da haben 

341
00:17:22,800 --> 00:17:26,480
wir in Folge 94 mal darüber 
gesprochen, dass manche Firmen 

342
00:17:26,599 --> 00:17:28,280
wie zum Beispiel Netflix, die 
haben das Wissen ins Leben 

343
00:17:28,280 --> 00:17:31,000
gerufen, ganz. 
Quasi konstant sogar die eigenen

344
00:17:31,000 --> 00:17:34,880
Systeme selber manipulieren, 
dass sich ja niemand an den 

345
00:17:34,880 --> 00:17:38,840
Zustand gewöhnt, dass immer 
alles glatt läuft und dadurch so

346
00:17:38,840 --> 00:17:42,240
ein bisschen erzwingen, dass die
Developer von bestimmten 

347
00:17:42,320 --> 00:17:44,720
Subkomponenten quasi von 
vornherein irgendwelche 

348
00:17:44,720 --> 00:17:47,840
Resilienz Features einbauen. 
Und hier kommt es eben darauf 

349
00:17:47,840 --> 00:17:50,200
an, dass die Overs besagt, dass 
es auch eine 

350
00:17:50,200 --> 00:17:53,680
Sicherheitsschwachstelle sein 
kann, wenn ich dein System eben 

351
00:17:53,680 --> 00:17:56,720
durch einen Angriff von außen in
eine bestimmte Fehlersituation 

352
00:17:56,720 --> 00:18:00,560
versetzen kann und es dann an. 
Anders reagiert als es sollte 

353
00:18:01,040 --> 00:18:04,640
und deswegen ganz klar, wie du 
mit so einem mit so einem 

354
00:18:04,640 --> 00:18:07,240
Failure umgehst. 
Das ist wichtig, dass er in 

355
00:18:07,240 --> 00:18:09,400
einem hochkomplexen System 
passiert, ist fast schon nicht 

356
00:18:09,400 --> 00:18:12,320
zu vermeiden und darauf wird es 
hier in diesem neuen Punkt auf 

357
00:18:12,320 --> 00:18:16,320
Platz 10 noch mal einen extra 
Fokus und eine extra augenmerke 

358
00:18:16,320 --> 00:18:18,480
legt. 
Wir gehen dann nachher noch mal 

359
00:18:18,480 --> 00:18:21,200
ein bisschen tiefer drauf ein, 
was das auch für uns als 

360
00:18:21,200 --> 00:18:24,040
Organisation oder als vielleicht
als Firma bedeutet. 

361
00:18:24,040 --> 00:18:28,400
Stichwort Thread Modeling, aber 
ich glaube ganz simpel 

362
00:18:28,560 --> 00:18:31,920
gesprochen lässt sich sagen, wir
bereiten uns auf das Schlimmste 

363
00:18:31,920 --> 00:18:36,960
vor und wir verhindern nicht 
nur, dass dann, wenn etwas 

364
00:18:36,960 --> 00:18:39,360
passiert. 
Unsere Anwendung irgendwie 

365
00:18:39,360 --> 00:18:42,320
angreifbar ist, sondern wir 
gehen irgendwie dreischrittig 

366
00:18:42,320 --> 00:18:44,800
vor. 
Wir investieren in Prävention, 

367
00:18:44,800 --> 00:18:47,360
damit solche Situationen 
möglichst nicht auftreten. 

368
00:18:47,360 --> 00:18:50,800
Wir stellen sicher, dass wir 
erkennen, wenn Fehlverhalten 

369
00:18:50,800 --> 00:18:54,240
auftritt, und dann können wir 
entsprechend darauf reagieren, 

370
00:18:54,240 --> 00:18:59,200
auf diese Fehler, um halt diese 
Probleme abzufangen und sind 

371
00:18:59,200 --> 00:19:01,920
dann halt wirklich aufs 
Schlimmste vorbereitet. 

372
00:19:02,560 --> 00:19:06,160
Ja genau, also ganz klar nicht 
nur diesen Happy Path absichern.

373
00:19:06,440 --> 00:19:08,240
Sondern ganz klar, dass sowas 
wie fehlervermeidung, 

374
00:19:08,240 --> 00:19:10,880
fehlererkennung, Reaktion auf 
Fehler einfach ein integraler 

375
00:19:10,880 --> 00:19:13,880
Teil von meinem Design wird. 
Das heißt, natürlich will ich 

376
00:19:13,880 --> 00:19:16,720
irgendwie vermeiden, dass meine 
Software abstürzt, ich will aber

377
00:19:16,720 --> 00:19:19,520
viel mehr vermeiden, dass wenn 
vielleicht irgendwie eine third 

378
00:19:19,520 --> 00:19:22,800
Komponente nicht mehr erreichbar
ist oder irgendein Teil meiner 

379
00:19:22,800 --> 00:19:25,200
Software unter einer so großen 
Last steht, dass er langsam oder

380
00:19:25,200 --> 00:19:27,160
gar nicht mehr antwortet oder 
meine Software vielleicht sogar 

381
00:19:27,160 --> 00:19:28,640
selber an einer bestimmten 
Stelle crasht. 

382
00:19:29,160 --> 00:19:33,120
Dass sie dann nicht in einen 
Zustand verfällt, in dem sich 

383
00:19:33,120 --> 00:19:36,400
neue Sicherheitslücken auftun. 
Es gibt Anwendungen, die im 

384
00:19:36,400 --> 00:19:39,280
Fehlerfall sehr, sehr chatty 
werden, die dann irgendwie viele

385
00:19:39,280 --> 00:19:42,960
internas oder sogar sensible 
Daten in ihren Logs oder gar in 

386
00:19:42,960 --> 00:19:45,840
ihren Fehlermeldungen 
preisgeben, das ist ganz oft gut

387
00:19:45,840 --> 00:19:48,480
gemeint von den Entwicklerinnen 
und Entwicklern, du willst ja 

388
00:19:48,480 --> 00:19:51,360
vielleicht im Fehlerfall auch 
möglichst viele Informationen 

389
00:19:51,360 --> 00:19:54,400
haben. 
Die du dann wieder nutzen 

390
00:19:54,400 --> 00:19:56,000
kannst, um nachher 
herauszufinden, warum ist das 

391
00:19:56,000 --> 00:19:58,600
passiert, wann ist das passiert,
wie kann ich, wie kann ich das 

392
00:19:58,600 --> 00:20:01,280
für den Zustand möglichst 
schnell wieder wiederherstellen.

393
00:20:01,760 --> 00:20:04,960
Das kann aber auch oft einfach 
ein ungewollter Data League sein

394
00:20:04,960 --> 00:20:08,640
und das finde ich ganz spannend,
weil es gibt ja eine andere, ein

395
00:20:08,640 --> 00:20:13,680
anderer Bereich von diesen ovas 
top ten war ja nämlich genau der

396
00:20:13,680 --> 00:20:16,160
Platz 9, also allein schon der 
vorherige Platz mit diesen 

397
00:20:16,320 --> 00:20:18,680
Logging und alerting failers, wo
es vielleicht auch darum geht, 

398
00:20:18,680 --> 00:20:21,440
dass ich zu wenig logge oder 
vielleicht gar nicht mitbekomme,

399
00:20:21,440 --> 00:20:24,080
wenn ich Zum Beispiel 
angegriffen werde. 

400
00:20:24,400 --> 00:20:26,720
Und hier geht es jetzt darum, 
dass ich natürlich irgendwie in 

401
00:20:26,760 --> 00:20:30,520
einem Fehlerfall ja loggen will,
aber dass dort auch ganz oft 

402
00:20:30,520 --> 00:20:32,320
dann eben zustande kommt, dass 
ich da eben ein bisschen 

403
00:20:32,320 --> 00:20:35,280
überlogge oder dass ich sage, 
ich habe eine Fehlermeldung, die

404
00:20:35,280 --> 00:20:38,640
irgendwo passiert, das ist eine 
interne Fehlermeldung und ich 

405
00:20:38,640 --> 00:20:42,160
gebe die aber über den http 500 
er Fehler vielleicht sogar nach 

406
00:20:42,160 --> 00:20:44,880
draußen weiter und das sind dann
Informationen, die ein Angreifer

407
00:20:44,880 --> 00:20:48,400
wieder verwenden kann um einfach
sensible Daten über mein System 

408
00:20:48,400 --> 00:20:50,680
zu erfahren. 
Und die man sich dann natürlich 

409
00:20:50,680 --> 00:20:52,880
nutzen kann. 
Und deswegen versuchen Angreifer

410
00:20:52,880 --> 00:20:56,760
heute auch vermehrt Anwendungen 
in einen Fehlerzustand zu 

411
00:20:56,760 --> 00:20:59,920
versetzen, in dem vielleicht 
irgendwo von außen einen einen 

412
00:20:59,920 --> 00:21:02,560
Zugang abgeschnitten oder 
vielleicht auch attackiert wird,

413
00:21:02,720 --> 00:21:05,680
um dann zu gucken, wie verhält 
sich dann meine meine Anwendung 

414
00:21:05,680 --> 00:21:08,080
und kann ich da vielleicht 
irgendwie dann sensible 

415
00:21:08,080 --> 00:21:10,560
Informationen mehr daraus 
erhaschen? 

416
00:21:10,960 --> 00:21:12,480
Und. 
Bevor wir jetzt gleich darauf 

417
00:21:12,480 --> 00:21:16,160
eingehen, was das Ganze für uns 
bedeutet, müssen wir glaube ich,

418
00:21:16,160 --> 00:21:19,280
noch einmal ein bisschen 
zurückspringen, weil ich glaube,

419
00:21:19,280 --> 00:21:23,280
vielleicht ist den ovas Top 10 
Nerds unter euch aufgefallen, 

420
00:21:23,280 --> 00:21:27,360
dass ein Punkt, der bisher in 
der Liste war, nämlich Server 

421
00:21:27,360 --> 00:21:30,720
Site request Forgery, jetzt 
plötzlich verschwunden ist. 

422
00:21:30,960 --> 00:21:34,000
Und es ist nicht unwichtig 
geworden, sondern es wurde 

423
00:21:34,000 --> 00:21:39,120
lediglich in einen anderen Punkt
integriert, und zwar in Broken. 

424
00:21:39,600 --> 00:21:43,560
Access Control und vielleicht 
für diejenigen, die denen das 

425
00:21:43,560 --> 00:21:45,640
jetzt nicht sagt. 
Wir mussten auch selber noch mal

426
00:21:45,640 --> 00:21:49,840
nachschlagen, wann und wie das 
Ganze auch vorkommen kann, 

427
00:21:49,920 --> 00:21:53,000
vielleicht ganz kurz das Thema 
Server Side Request Forgery 

428
00:21:53,000 --> 00:21:59,120
bedeutet, dass ich es einem 
System aufzwingen kann, dass es 

429
00:21:59,120 --> 00:22:02,480
mir Zugriff auf Systeme unter 
Systeme gibt, zum Beispiel 

430
00:22:02,480 --> 00:22:04,880
vielleicht einen Storage Account
oder eine Datenbank auf. 

431
00:22:05,160 --> 00:22:07,920
Auf die ich eigentlich keinen 
Zugriff haben sollte. 

432
00:22:07,920 --> 00:22:10,720
Das heißt, ich greife zum 
Beispiel auf eine API zu und 

433
00:22:10,720 --> 00:22:14,640
gebe da bestimmte Informationen 
mit, die am Ende auf der 

434
00:22:14,640 --> 00:22:18,080
Applikationslogik dazu führen, 
dass ich Informationen 

435
00:22:18,080 --> 00:22:21,640
zurückbekomme aus einem dritten 
System, auf das ich 

436
00:22:21,640 --> 00:22:23,360
normalerweise keinen Zugriff 
habe. 

437
00:22:23,360 --> 00:22:27,200
Das heißt, ich habe auf der 
Server Seite dafür gesorgt, dass

438
00:22:27,200 --> 00:22:30,800
mein Request ein anderes System 
geht, aber du hast glaube ich 

439
00:22:30,800 --> 00:22:34,160
noch ein ganz gutes Beispiel, 
was man vielleicht auch aus. 

440
00:22:34,520 --> 00:22:36,800
Den Bereich der Webentwicklung 
gut nachvollziehen kann. 

441
00:22:37,120 --> 00:22:40,080
Ja, ist eine ganz, ganz fiese 
Sache, diese ssrf attacks. 

442
00:22:40,840 --> 00:22:42,360
Einfach ein klassisches 
Beispiel. 

443
00:22:42,360 --> 00:22:44,880
Ich habe selber schon mal 
irgendwie einen aus Versehen 

444
00:22:44,880 --> 00:22:50,240
eingebaut, da kannst du einfach 
meiner API einen JSON schicken, 

445
00:22:50,400 --> 00:22:53,760
über einen über ein user Objekt 
was du updaten konntest und da 

446
00:22:53,760 --> 00:22:56,200
kannst du einfach sagen Hey pass
auf mein Profilbild findest du 

447
00:22:56,200 --> 00:22:58,240
übrigens unter dieser URL, weil 
ich habe einfach gesagt ich habe

448
00:22:58,240 --> 00:23:00,160
gar keine Lust, dass man selber 
irgendwelche Profilbilder bei 

449
00:23:00,160 --> 00:23:02,240
mir hochladen kann, viel zu 
kompliziert wollte ich nicht 

450
00:23:02,240 --> 00:23:04,360
einbauen, kann es einfach 
irgendeine URL angeben und. 

451
00:23:04,360 --> 00:23:06,040
Und dann kann es natürlich 
passieren, dass mir jemand einen

452
00:23:06,040 --> 00:23:09,520
json schickt und aber sagt, EY, 
Mein Profilbild liegt unter http

453
00:23:09,680 --> 00:23:13,880
localhost, port 8080 admin und 
mein Server hätte dann ja 

454
00:23:13,880 --> 00:23:15,800
einfach, wäre dann hingegangen, 
hätte dieses Bild, egal von 

455
00:23:15,800 --> 00:23:18,080
welcher Quelle das ist irgendwie
runtergeladen, also einen Get 

456
00:23:18,080 --> 00:23:20,800
request an diese URL geschickt 
und wenn ich die vorher nicht 

457
00:23:20,800 --> 00:23:24,560
überprüfe, dann wird mein Server
eben der ja vielleicht auf 

458
00:23:24,640 --> 00:23:27,840
localhost Port 8080 Admin 
Zugriff hat mein Client 

459
00:23:27,840 --> 00:23:30,760
natürlich nicht, aber der Server
macht das dann und dann kann man

460
00:23:30,760 --> 00:23:34,440
natürlich dadurch erwirken. 
Dass mein Server irgendwo eine 

461
00:23:34,440 --> 00:23:36,640
Anfrage hinschickt, also weil es
irgendwie als klassisches 

462
00:23:36,640 --> 00:23:41,400
Beispiel in dieser Image URL und
genau das ist nicht weniger 

463
00:23:41,400 --> 00:23:43,680
wichtig geworden, das war 
früher, es war ein eigener 

464
00:23:43,680 --> 00:23:46,240
Punkt, früher auf Platz 10 und 
jetzt ist er eben in Platz 1, 

465
00:23:46,240 --> 00:23:49,720
also in dieses Broken Access 
Control mit Reingeflossen. 

466
00:23:49,720 --> 00:23:52,360
Dieser Platz 1 wurde eh so ein 
bisschen aufgebläht, weil es, 

467
00:23:52,360 --> 00:23:54,120
wie man jetzt dadurch mit diesem
Beispiel vielleicht so ein 

468
00:23:54,120 --> 00:23:56,800
bisschen merkt, nicht nur um 
User Access geht, sondern 

469
00:23:56,800 --> 00:23:58,320
einfach auch darum, dass ich 
den. 

470
00:23:58,840 --> 00:24:00,920
Ja, dass ich einem Server 
irgendwas unterjubeln kann. 

471
00:24:00,920 --> 00:24:03,680
Also ich finde es relativ nah an
so einer SQL Injection, wo ich 

472
00:24:03,680 --> 00:24:06,680
versuche so eine SQL Queery 
mitzugeben, gebe ich halt hier 

473
00:24:06,680 --> 00:24:09,200
irgendwelche Sachen mit oder 
versuche, dass der Server, wenn 

474
00:24:09,200 --> 00:24:11,920
ich rausfinde wie er eh arbeitet
oder welchen Ur Ls erfolgt, 

475
00:24:12,240 --> 00:24:15,200
vielleicht Dinge tut, die der 
Server zwar tun kann, ich selber

476
00:24:15,200 --> 00:24:17,040
aber nicht tun kann. 
Das heißt es ist eigentlich ein 

477
00:24:17,040 --> 00:24:20,880
Spezialfall von so fehlerhafter 
Zugriffskontrolle und sorgt 

478
00:24:20,880 --> 00:24:23,440
eigentlich dafür, dass mein 
Server Requests ausführt, die er

479
00:24:23,840 --> 00:24:27,360
eigentlich in diesem Kontext 
nicht ausführen dürfte. 

480
00:24:28,280 --> 00:24:30,960
Letzten Endes kann man sagen, 
dass jetzt mit der neuen Overs 

481
00:24:30,960 --> 00:24:33,920
top 10 so ein bisschen so ein 
ganzheitlicher Ansatz gefahren 

482
00:24:33,920 --> 00:24:35,760
wird. 
Es wird weniger wirklich auf 

483
00:24:35,760 --> 00:24:40,000
einzelne klassische Security 
Bugs, sondern mehr auf das große

484
00:24:40,000 --> 00:24:42,640
Ganze geschaut, dementsprechend 
werden bestimmte Kategorien 

485
00:24:42,800 --> 00:24:46,640
zusammengelegt und andere 
Kategorien werden etwas 

486
00:24:46,640 --> 00:24:48,400
verbreitert. 
Wir schauen jetzt auf den 

487
00:24:48,400 --> 00:24:50,960
gesamten 
Softwareentwicklungsprozess 

488
00:24:50,960 --> 00:24:53,280
inklusive du hast es gerade 
gesagt, zum Beispiel den 

489
00:24:53,280 --> 00:24:57,360
Buildserver, das Deployment. 
Und wir schauen nicht nur mehr 

490
00:24:57,360 --> 00:25:01,520
auf unseren eigenen Code, 
sondern alles, was im Betrieb 

491
00:25:01,520 --> 00:25:05,600
einer komplexen Applikation 
heute eine Rolle spielt. 

492
00:25:06,160 --> 00:25:07,880
Ja, das war so ein bisschen. 
Vorher war das eigentlich so, 

493
00:25:07,880 --> 00:25:09,880
klassische Bugs, auf die man 
irgendwie gucken konnte, so 

494
00:25:09,880 --> 00:25:12,880
okay. 
Also dieser SQL Injection, das 

495
00:25:12,880 --> 00:25:15,120
war so einer der ganz ganz 
frühen Overs blisten mal 

496
00:25:15,120 --> 00:25:17,240
irgendwann drauf so diese ganz 
klassischen Dinge, die man halt 

497
00:25:17,240 --> 00:25:20,080
irgendwann auch benennen kann, 
die man aber auch ganz gut 

498
00:25:20,080 --> 00:25:23,040
identifizieren kann, wenn man 
sie sieht, die vielleicht auch 

499
00:25:23,040 --> 00:25:25,200
heute eine KI ganz gut 
identifizieren kann. 

500
00:25:25,200 --> 00:25:27,600
Wir haben ja, wir wollen ja 
keine Folge ohne KI machen, 

501
00:25:27,760 --> 00:25:30,120
deswegen möchte ich ja doch noch
mal erwähnen, dass es auch ein 

502
00:25:30,120 --> 00:25:32,440
paar Agenten gibt, die ja 
durchaus in der Lage sind, 

503
00:25:32,440 --> 00:25:34,440
einfach meinen Code nach so. 
Gängigen 

504
00:25:34,440 --> 00:25:36,080
Sicherheitsschwachstellen zu 
überprüfen. 

505
00:25:36,080 --> 00:25:38,600
Und natürlich können das nicht 
nur KI s, sondern auch Menschen 

506
00:25:38,600 --> 00:25:40,720
sein, die das tun, indem man 
diese Listen abarbeitet. 

507
00:25:40,720 --> 00:25:43,040
Und jetzt sehen wir schon, dass 
wir eigentlich immer immer 

508
00:25:43,040 --> 00:25:45,320
weiter rauszoomen und der Fokus 
eigentlich mehr so diesen 

509
00:25:45,320 --> 00:25:50,520
gesamten Software Development 
Lifecycle abdeckt und eigentlich

510
00:25:50,520 --> 00:25:54,800
Kontext statt nur Code, also 
auch betriebsmodelle, und dass 

511
00:25:54,800 --> 00:25:58,080
Dinge von vornherein mit geplant
werden müssen und wie ich auf 

512
00:25:58,080 --> 00:26:00,640
welche Zustandsänderungen 
reagiere. 

513
00:26:01,000 --> 00:26:03,120
Das heißt also aber auch 
irgendwie für mich so ein 

514
00:26:03,120 --> 00:26:07,200
bisschen, dass es auch komplexer
oder komplizierter geworden ist,

515
00:26:07,200 --> 00:26:08,720
sichere Anwendungen zu 
schreiben. 

516
00:26:08,720 --> 00:26:11,800
Wenn das jetzt so diese top 10 
Thread Vektoren sind, die Ovas 

517
00:26:11,800 --> 00:26:15,520
herausgibt, da war das ja früher
vielleicht eine Sache von ein 

518
00:26:15,520 --> 00:26:18,080
paar Stunden, dass ich mich da 
durchwühle und gucke, ob meine 

519
00:26:18,080 --> 00:26:21,760
Anwendungen denen jetzt 
entspricht oder nicht, und heute

520
00:26:21,760 --> 00:26:24,480
muss ich ja viel, viel mehr 
Komponenten machen, also. 

521
00:26:25,400 --> 00:26:27,400
Muss ich mich ja schon irgendwie
fragen, was bedeutet das denn 

522
00:26:27,400 --> 00:26:30,080
jetzt ganz konkret für meine 
tägliche Arbeit oder für die 

523
00:26:30,320 --> 00:26:32,920
Sicherheitsprogramme, die ich 
vielleicht irgendwie meinem 

524
00:26:32,920 --> 00:26:35,880
Unternehmen ausgerufen habe, 
weil das ja doch jetzt irgendwie

525
00:26:35,880 --> 00:26:37,560
nach deutlich mehr Arbeit 
aussieht, die sich ja vielleicht

526
00:26:37,560 --> 00:26:39,600
auch gar nicht mehr jeder 
leisten kann zu tun. 

527
00:26:39,600 --> 00:26:41,520
Und die Frage ist, kann ich mir 
leisten, es mir nicht zu 

528
00:26:41,520 --> 00:26:44,360
leisten, es zu tun, also das 
müssen wir sich ja schon 

529
00:26:44,360 --> 00:26:46,080
eigentlich noch mal angucken, 
was hat das eigentlich für 

530
00:26:46,080 --> 00:26:47,520
Auswirkungen jetzt auf die 
Praxis? 

531
00:26:47,880 --> 00:26:50,760
Dass diese Liste also deutlich 
breiter geworden ist, sie ja gar

532
00:26:50,760 --> 00:26:52,760
nicht länger geworden. 
Aber sie ist auf jeden Fall in 

533
00:26:52,760 --> 00:26:54,720
meiner Wahrnehmung komplizierter
geworden. 

534
00:26:54,880 --> 00:26:57,120
Ja, lass uns das in 2 Teile 
aufteilen. 

535
00:26:57,120 --> 00:26:58,880
Einmal. 
Was bedeutet das für uns als 

536
00:26:58,880 --> 00:27:02,040
Developer, die wir tagtäglich 
Software schreiben, entwickeln 

537
00:27:02,040 --> 00:27:05,200
und was bedeutet das für 
Unternehmen oder allgemein so 

538
00:27:05,200 --> 00:27:10,160
die Security, die wir rund um 
unsere Anwendung stricken und 

539
00:27:10,160 --> 00:27:14,160
vielleicht bei den Sachen, die 
wir als Entwickler uns anschauen

540
00:27:14,160 --> 00:27:17,560
müssen, starten wir am besten 
Mal bei den neuen Kategorien 

541
00:27:17,560 --> 00:27:20,080
oder den. 
Den erweiterten Kategorien und 

542
00:27:20,080 --> 00:27:22,000
wir hatten gerade schon ein 
bisschen länger über Supply 

543
00:27:22,000 --> 00:27:26,160
Chain Security, also Platz 3 in 
der Liste, gesprochen und ich 

544
00:27:26,160 --> 00:27:29,840
glaube, da müssen wir gar nicht 
jetzt so tiefgehend darauf 

545
00:27:29,840 --> 00:27:32,400
eingehen, sondern wir können 
hier auch eigentlich auf unsere 

546
00:27:32,400 --> 00:27:37,800
Folge 133 zu shygo Loot 
verweisen und alle diese Dinge, 

547
00:27:37,800 --> 00:27:40,640
die wir da besprochen haben, 
dass wir sicherstellen müssen, 

548
00:27:40,640 --> 00:27:44,400
dass Drittanbietercode sicher 
ist, dass wir sichergehen, dass 

549
00:27:44,400 --> 00:27:47,200
die Abhängigkeiten, die wir 
reinziehen, tatsächlich. 

550
00:27:47,600 --> 00:27:52,080
Den Code enthalten, der 
vorgegeben hinter einer 

551
00:27:52,080 --> 00:27:53,840
entsprechenden Versionsnummer 
steht. 

552
00:27:54,000 --> 00:27:56,440
Wir müssen checken, welche 
Abhängigkeiten wir eigentlich 

553
00:27:56,440 --> 00:27:59,680
haben, über welchen Package 
Manager, und wir müssen 

554
00:27:59,680 --> 00:28:02,600
natürlich sicherstellen, welche 
Build tools haben wir eigentlich

555
00:28:02,600 --> 00:28:06,400
im Einsatz, also was läuft zum 
Beispiel in unseren Pipelines, 

556
00:28:06,880 --> 00:28:10,160
was läuft und auf unseren 
Jenkins oder in unseren github 

557
00:28:10,160 --> 00:28:14,240
actions letzten Endes, um unsere
Anwendung zu bauen und zu 

558
00:28:14,240 --> 00:28:17,400
Deployen und alle diese Dinge 
müssen wir natürlich im Blick 

559
00:28:17,400 --> 00:28:18,080
auf. 
Unterhalten. 

560
00:28:18,240 --> 00:28:21,240
Ja, eigentlich wird jedes npm 
install oder was auch immer ich 

561
00:28:21,240 --> 00:28:24,120
für Package Manager benutze, 
eine sicherheitskritische 

562
00:28:24,120 --> 00:28:26,280
Entscheidung, die ich treffen 
muss, die ich auch hinterfragen 

563
00:28:26,280 --> 00:28:28,440
muss. 
Ich glaube, wir müssen wegkommen

564
00:28:28,440 --> 00:28:31,600
von dieser Zeit, wo ich einfach 
Sold, Party, Pakete installiere 

565
00:28:31,760 --> 00:28:34,000
und früher hat es vielleicht so 
ein bisschen gereicht, dass ich 

566
00:28:34,000 --> 00:28:36,640
mir mal angeguckt habe, okay, 
was steckt vielleicht mehr als 

567
00:28:36,640 --> 00:28:39,600
einen Mentainer dahinter und 
nutzen das auch andere. 

568
00:28:39,760 --> 00:28:42,800
Und ich mache einmal die Woche 
npm Audit passt schon. 

569
00:28:42,800 --> 00:28:44,440
Ja, so in der Art. 
Genau da muss ich mich wirklich 

570
00:28:44,440 --> 00:28:47,800
fragen. 
Ist das also, ist das nötig und 

571
00:28:48,000 --> 00:28:51,200
wo in meiner Software Supply 
Chain führe ich das dort auf? 

572
00:28:51,200 --> 00:28:53,880
Wie oft wird das Auditiert, da 
gibt es ja auch Automatismen 

573
00:28:53,880 --> 00:28:56,280
mittlerweile zum Glück, die mich
da regelmäßig dran daran 

574
00:28:56,280 --> 00:28:59,360
erinnern, macht es vielleicht 
Sinn, dass ich das Paket auf 

575
00:28:59,360 --> 00:29:02,320
meinem in meiner eigenen 
Registry Zwischenlager und das 

576
00:29:02,320 --> 00:29:04,680
sind ja alles große Fragen, die 
vielleicht und gar nicht alle in

577
00:29:04,680 --> 00:29:07,360
jedem Unternehmen sinnvoll sind,
haben wir wie gesagt ja auch in 

578
00:29:07,360 --> 00:29:10,960
Tiefe in Folge 133 zu diesem 
shyhood Wurm schon besprochen, 

579
00:29:10,960 --> 00:29:12,800
deswegen gehen wir da jetzt 
nicht noch mal drauf rein, aber.

580
00:29:12,920 --> 00:29:14,560
Aber für mich bleibt so ein 
bisschen die Frage, ob das 

581
00:29:14,560 --> 00:29:18,560
eigentlich praktisch, also 
praxisnah ist für jetzt. 

582
00:29:18,880 --> 00:29:21,120
Wenn ich jetzt irgendwie die 
Deutsche Telekom bin, dann kann 

583
00:29:21,120 --> 00:29:23,920
ich mir das bestimmt leisten, da
irgendwie für jedes mpm Paket da

584
00:29:23,920 --> 00:29:27,280
meinen eigenen Feedback mit 
eigenen Pipelines für 

585
00:29:27,280 --> 00:29:30,160
aufzubauen, in eigenen Audits. 
Aber wenn ich jetzt einfach 

586
00:29:30,160 --> 00:29:32,960
irgendwie als Startup ein 
bisschen Code schreibe, dann ist

587
00:29:32,960 --> 00:29:36,400
das ja wahrscheinlich mindestens
mal eine Vollzeitstelle, meine 

588
00:29:36,400 --> 00:29:40,480
ganze meine ganze supply chain. 
Permanent zu überprüfen. 

589
00:29:40,640 --> 00:29:43,680
Ja, ich glaube, ich muss vor 
allen Dingen mir immer 

590
00:29:43,680 --> 00:29:46,800
Bewusstsein, dass das alles auch
Security Entscheidungen sind. 

591
00:29:46,800 --> 00:29:49,840
Ich kann auch dann kostenfreie 
Tools wie irgendwie depender 

592
00:29:49,840 --> 00:29:53,120
Board oder Renovate verwenden, 
um halt sicherzustellen, dass 

593
00:29:53,120 --> 00:29:55,760
meine Pakete immer aktuell sind 
und ich glaube in der 

594
00:29:55,760 --> 00:29:59,360
Kombination zwischen Bewusstsein
und Tools, die ich im Einsatz 

595
00:29:59,360 --> 00:30:02,400
habe, bin ich da schon auf dem 
richtigen Weg, selbst wenn ich 

596
00:30:02,400 --> 00:30:05,520
jetzt nicht das Maximum an 
Security erreichen kann, was 

597
00:30:05,520 --> 00:30:07,840
vielleicht große Konzerne sich 
über eigene. 

598
00:30:08,720 --> 00:30:12,640
Repositories für ihre Packages 
dann leisten können. 

599
00:30:12,960 --> 00:30:14,280
Ein bisschen einfacher finde 
ich, so ein bisschen. 

600
00:30:14,280 --> 00:30:16,400
Wie gehe ich mit dem mit dem 
neuen Platz 10 um, also mit 

601
00:30:16,400 --> 00:30:18,160
diesem Exception Handling hatte 
ich ja vorhin schon so ein 

602
00:30:18,160 --> 00:30:22,240
bisschen das, was erzählt das 
eigentlich ich mir Bewusstsein 

603
00:30:22,240 --> 00:30:24,400
muss, dass jeder Trike Hatch 
Blog auch eine 

604
00:30:24,400 --> 00:30:26,880
Sicherheitsentscheidung ist. 
Und was hat das jetzt denn für 

605
00:30:26,880 --> 00:30:29,480
Auswirkungen und wie hoch 
babbelt denn jetzt vielleicht 

606
00:30:29,480 --> 00:30:32,680
diese Exception, die hier die 
hier schmeiße und. 

607
00:30:32,680 --> 00:30:36,640
Und dass ich mir dann natürlich 
auch beim Logging und bei den 

608
00:30:36,640 --> 00:30:38,720
Fallbacks, die ich dann 
vielleicht auch im Fehlerfall 

609
00:30:38,720 --> 00:30:40,960
gehe, einfach immer wieder diese
Frage stelle. 

610
00:30:40,960 --> 00:30:44,080
Okay Moment mal, ist das, was 
wäre denn, wenn so locker an die

611
00:30:44,080 --> 00:30:46,640
Außenwelt kommt oder was? 
Was bedeutet denn jetzt mein 

612
00:30:46,640 --> 00:30:47,840
Fallback? 
Ist der vielleicht irgendwie 

613
00:30:47,840 --> 00:30:50,960
angreifbar und dass einfach 
fehlerbehandlung so ein 

614
00:30:50,960 --> 00:30:53,080
bisschen? 
Eher von vornherein mitgedacht 

615
00:30:53,080 --> 00:30:55,760
werden, Design Thema sind und 
nicht irgendwie im Nachgang 

616
00:30:55,760 --> 00:30:57,640
herauskommen wie. 
Ja, was ist denn, wenn jetzt 

617
00:30:57,640 --> 00:30:58,880
irgendwie dieser API nicht 
erreichbar ist? 

618
00:30:58,880 --> 00:31:00,800
Wie reagiert er, mein System, 
sondern ich es von vornherein 

619
00:31:00,800 --> 00:31:03,600
immer mitdenke, wenn ich darüber
nachdenke eine API einzubauen, 

620
00:31:03,600 --> 00:31:05,240
denke ich auch darüber nach, was
heißt es, wenn sie nicht 

621
00:31:05,240 --> 00:31:06,880
erreichbar ist? 
Wie reagiert mein System, 

622
00:31:07,440 --> 00:31:12,000
vielleicht schaffe ich irgendwo 
konsistente Arten und weisen, 

623
00:31:12,000 --> 00:31:15,760
wie ich in meiner Firma oder in 
meinem Team Fehler behandle, wie

624
00:31:15,760 --> 00:31:18,400
ich logge, wie ich sicherstelle,
dass in den Logs keine sensiblen

625
00:31:18,400 --> 00:31:21,480
Informationen sind. 
Dass wir wirklich testen, welche

626
00:31:21,480 --> 00:31:25,200
Exceptions bleiben intern und 
welche Bubble vielleicht hoch 

627
00:31:25,200 --> 00:31:27,400
und sind dann irgendwie im Buddy
von so einem 500 er Fehler auf 

628
00:31:27,400 --> 00:31:30,480
einmal zu lesen und ich glaube 
letzten Endes einfach dieses, 

629
00:31:30,720 --> 00:31:34,560
dass wir uns klar werden, Fehler
werden passieren, die Frage ist 

630
00:31:34,720 --> 00:31:37,040
auch nur so ein bisschen wann 
und wie wir damit umgehen und 

631
00:31:37,040 --> 00:31:39,840
dass wir, dass wir dann nicht 
aufgeschmissen oder ganz 

632
00:31:39,840 --> 00:31:43,800
überrascht sind, wenn unser 
System, gerade wenn es komplex 

633
00:31:43,800 --> 00:31:45,040
wird, sich mal fehlerhaft 
verhält. 

634
00:31:45,560 --> 00:31:48,760
Und dann haben wir noch hier als
dritten Punkt insecure Design 

635
00:31:48,760 --> 00:31:52,320
Nummer 6, was auch so ein 
bisschen unsere Überleitung ist 

636
00:31:52,320 --> 00:31:56,320
in die übergeordneten 
Funktionen, weil mit dem Design 

637
00:31:56,320 --> 00:32:01,040
einer Software beschäftigen 
nicht nur sich die einzelnen 

638
00:32:01,040 --> 00:32:03,440
Entwickler, sondern das ist 
meistens ein größeres Team. 

639
00:32:03,440 --> 00:32:05,960
Wir haben dort irgendwelche 
Architekten oder 

640
00:32:05,960 --> 00:32:09,560
Sicherheitsberater mit im Spiel,
die sich gemeinsam die 

641
00:32:09,560 --> 00:32:13,200
Architektur anschauen und es ist
da ganz wichtig natürlich, sich 

642
00:32:13,200 --> 00:32:16,000
zu überlegen. 
Schon beim Design der 

643
00:32:16,000 --> 00:32:18,720
Anwendungsarchitektur. 
Was muss ich dort 

644
00:32:18,720 --> 00:32:21,680
berücksichtigen, damit meine 
Anwendung nachher sicher ist? 

645
00:32:21,680 --> 00:32:24,400
Da kommen dann solche 
Bedrohungsmodellierungen mit 

646
00:32:24,400 --> 00:32:28,080
rein oder threadmodelling und 
all das muss ich im Hinterkopf 

647
00:32:28,080 --> 00:32:31,520
haben, wenn ich die Anwendung 
erstelle am Anfang oder die 

648
00:32:31,520 --> 00:32:34,000
Anwendungsarchitektur am Anfang 
erstelle. 

649
00:32:34,000 --> 00:32:36,960
Und viele Unternehmen haben 
mittlerweile so ein Security by 

650
00:32:36,960 --> 00:32:40,320
Design. 
Konzept als Pflicht eingeführt 

651
00:32:40,400 --> 00:32:43,320
und dann auch ganz viele solche 
Guidelines niedergeschrieben. 

652
00:32:43,320 --> 00:32:45,200
Das heißt, immer wenn ich 
irgendwie eine neue Anwendung 

653
00:32:45,200 --> 00:32:48,160
designe, was muss ich da auf 
jeden Fall in der Architektur 

654
00:32:48,160 --> 00:32:50,360
berücksichtigen? 
Ja, wenn sie niedergeschrieben 

655
00:32:50,360 --> 00:32:52,560
sind, dann ist ja alles gut. 
Dann kann ja nichts passieren. 

656
00:32:54,640 --> 00:32:58,320
Also wie scherzhaft gemeint 
niedergeschrieben heißt auch 

657
00:32:58,320 --> 00:33:00,520
nicht immer, dass sie, dass sie 
befolgt werden, aber. 

658
00:33:00,880 --> 00:33:02,800
Aber Checklisten sind auf jeden 
Fall nicht schlecht. 

659
00:33:03,040 --> 00:33:04,840
Das stimmt, das stimmt auf jeden
Fall besser, als nichts 

660
00:33:04,840 --> 00:33:06,520
niederzuschreiben. 
Auf jeden Fall und auch wenn 

661
00:33:06,520 --> 00:33:08,400
irgendwas niedergeschrieben ist,
kann man es ja trotzdem auch 

662
00:33:08,400 --> 00:33:10,400
wieder. 
Kann man das als Standard 

663
00:33:10,400 --> 00:33:13,440
nehmen, irgendwie in jedem Pull 
request automatisch darauf zu 

664
00:33:13,440 --> 00:33:17,160
verlinken oder darf ich noch mal
KI sagen oder vielleicht sich 

665
00:33:17,160 --> 00:33:20,000
auch irgendwie mal eine KI zu 
schreiben, die einfach guckt, ob

666
00:33:20,000 --> 00:33:22,680
sich jeder Pull request einfach 
kurz abgleicht mit Hey, das ist 

667
00:33:22,680 --> 00:33:25,040
ja da, das ist da dokumentiert 
worden, das ist der 

668
00:33:25,040 --> 00:33:26,800
Codeänderung, die ich hier 
gerade sehe. 

669
00:33:27,400 --> 00:33:30,240
Sich da vielleicht irgendwie 
eine Verletzung von diesen 

670
00:33:30,240 --> 00:33:33,040
Richtlinien. 
Vielmehr heißt das aber 

671
00:33:33,040 --> 00:33:36,320
eigentlich für mich, dass sich 
auch jeder oder jedem 

672
00:33:36,320 --> 00:33:38,720
Unternehmen, die irgendwo in den
Softwareentwicklungsprozess 

673
00:33:38,720 --> 00:33:42,160
eingebunden sind, damit 
beschäftigen müssen, also dass 

674
00:33:42,160 --> 00:33:46,640
auch Product Manager und Product
owner sich mit diesem Thema 

675
00:33:46,880 --> 00:33:50,240
auseinandersetzen müssen, weil 
es jetzt halt wirklich eben von.

676
00:33:50,600 --> 00:33:54,360
Ja, von vornherein bei Design 
mitgedacht werden muss und keine

677
00:33:54,360 --> 00:33:56,480
Ahnung. 
Schickt gerne euren PMS und Po 

678
00:33:56,480 --> 00:33:59,240
ist auch mal diese Folge, weil 
ich glaube das ist jetzt nichts 

679
00:33:59,240 --> 00:34:01,680
mehr was am letzten Ende der 
Entwickler nur entscheiden kann,

680
00:34:01,680 --> 00:34:04,800
wenn er oder sie ein npm Paket 
installiert, sondern was man 

681
00:34:04,800 --> 00:34:06,720
eben von vornherein mit 
Eindenken und natürlich auch mit

682
00:34:06,720 --> 00:34:09,520
einplanen muss, auch in die 
Kapazitätsplanung von so einem 

683
00:34:09,679 --> 00:34:12,800
Team mit einplanen muss, dass 
man auch diese Punkte besonders 

684
00:34:12,800 --> 00:34:14,960
8 gibt. 
Ja, und ganz häufig ist es ja 

685
00:34:14,960 --> 00:34:18,400
so, dass so Security so ein 
bisschen im Nachgang betrachtet 

686
00:34:18,400 --> 00:34:20,000
wird oder? 
Für viele Unternehmen ist das 

687
00:34:20,000 --> 00:34:23,280
ein zusätzliches Investment und 
dann wird man gefragt, ja, ihr 

688
00:34:23,440 --> 00:34:26,159
braucht jetzt so und so viel 
mehr Zeit, um bestimmte Dinge 

689
00:34:26,400 --> 00:34:29,000
vielleicht zusätzlich zu 
implementieren oder bestimmte 

690
00:34:29,000 --> 00:34:33,239
Dinge aktuell zu halten, lohnt 
sich das eigentlich und da finde

691
00:34:33,239 --> 00:34:36,719
ich es ganz spannend, dass 
selbst aus Ovas heraus jetzt so 

692
00:34:36,719 --> 00:34:38,920
ein risikobasierender Ansatz 
reinkommt, dass. 

693
00:34:39,199 --> 00:34:42,480
Der halt solche Entscheidungen 
rund um Security so ein bisschen

694
00:34:42,480 --> 00:34:45,840
an die Geschäftsrisiken koppelt,
was aus meiner Sicht sehr 

695
00:34:45,840 --> 00:34:49,440
sinnvoll ist, weil man damit 
natürlich auch entsprechend dann

696
00:34:49,440 --> 00:34:53,360
die Sensibilisierung in den 
Entscheiderkreisen bekommt, die 

697
00:34:53,360 --> 00:34:56,960
am Ende die Ressourcen zur 
Verfügung stellen und Ressourcen

698
00:34:56,960 --> 00:34:58,880
können sein. 
Einfach, ich bekomme mehr Zeit 

699
00:34:58,880 --> 00:35:01,680
oder wir bekommen zusätzliche 
Leute im Team, die sich mit 

700
00:35:01,680 --> 00:35:04,240
diesen Sicherheitsthemen 
beschäftigen können. 

701
00:35:04,560 --> 00:35:07,120
Und diese Ressourcen bekomme ich
meistens nur, wenn da eine 

702
00:35:07,120 --> 00:35:10,240
konkrete Zahl hinter steht. 
Wenn man weiß, hey, wenn da was 

703
00:35:10,240 --> 00:35:13,760
schief geht, kostet das unser 
Unternehmen so und so viel oder 

704
00:35:13,760 --> 00:35:17,600
kann uns vielleicht sogar in die
Insolvenz führen und ich glaube 

705
00:35:17,600 --> 00:35:20,680
nur wenn das bis oben hin 
verstanden wird im Unternehmen 

706
00:35:20,680 --> 00:35:23,520
bekommt man auch die Zeit und 
Ressourcen dafür. 

707
00:35:24,080 --> 00:35:26,040
Ja, da muss man sich ja einfach 
ganz klar fragen, was ist denn 

708
00:35:26,040 --> 00:35:28,880
meine oder meine Risikotoleranz,
die ich im Unternehmen habe, 

709
00:35:28,880 --> 00:35:30,440
weil. 
Ich werde gerade. 

710
00:35:30,440 --> 00:35:32,720
In die kleinen Unternehmen oder 
in sehr dynamisch schnell 

711
00:35:32,720 --> 00:35:36,240
wachsende Software? 
Lösungen, nicht mich gegen all 

712
00:35:36,240 --> 00:35:39,840
diese Sachen schützen können, 
aber ich muss mir dann natürlich

713
00:35:39,840 --> 00:35:42,360
irgendwie auch die Frage stellen
okay welche Sachen sind dann auf

714
00:35:42,360 --> 00:35:45,120
jeden Fall besonders wichtig für
mich oder für meine Software 

715
00:35:45,120 --> 00:35:47,440
oder was sind denn vielleicht 
auch irgendwie einfache Punkte 

716
00:35:47,440 --> 00:35:50,560
oder so quickwins womit ich 
schon mal so den Großteil davon 

717
00:35:50,560 --> 00:35:53,320
abdecken kann, also klassisches 
Beispiel einfach, dass ich nicht

718
00:35:53,320 --> 00:35:55,280
einfach nicht selber baue, 
selbst wenn es irgendwie 

719
00:35:55,280 --> 00:35:56,640
günstiger wäre. 
Das ist eine sehr sicher 

720
00:35:56,640 --> 00:35:58,560
relevante Sache, das kaufe ich 
immer von irgendeinem Anbieter 

721
00:35:58,560 --> 00:36:01,320
ein, irgendwie so als 
klassisches Beispiel und dass 

722
00:36:01,320 --> 00:36:03,920
man sich dann auch so ein 
bisschen selber natürlich fragt,

723
00:36:03,920 --> 00:36:06,080
wie. 
Kann ich mir das leisten hier 

724
00:36:06,080 --> 00:36:10,240
und da dann im Zweifel so und so
auf einen solchen Angriff zu 

725
00:36:10,240 --> 00:36:13,320
reagieren und das ist oft auch 
eine Entscheidung, die eine 

726
00:36:13,320 --> 00:36:16,240
Entscheidung, die ein Developer 
gar nicht treffen kann, sondern 

727
00:36:16,240 --> 00:36:19,280
das muss natürlich ein 
Management treffen am Ende, und 

728
00:36:19,280 --> 00:36:21,440
dafür ist es, glaube ich, 
wichtig, dass man die mitnimmt 

729
00:36:21,440 --> 00:36:23,680
auf diese Reise und da hilft, 
finde ich das eigentlich eine 

730
00:36:23,680 --> 00:36:24,840
gute Idee, was du gerade gesagt 
hast. 

731
00:36:24,840 --> 00:36:27,760
Malte, das ist eigentlich hilft 
da so, Kennzahlen in Euros 

732
00:36:27,760 --> 00:36:29,040
hinterzuschreiben, das ist 
natürlich. 

733
00:36:29,400 --> 00:36:30,640
Immer. 
Das ist natürlich nicht einfach,

734
00:36:30,640 --> 00:36:32,560
das ist natürlich wahnsinnig 
schwierig, aber dass man zum 

735
00:36:32,560 --> 00:36:34,880
Beispiel irgendwie sagt, diese 
bei dieser Schwachstelle kostet 

736
00:36:34,880 --> 00:36:39,320
das jetzt mein System x Euro, 
wenn sie davon betroffen ist 

737
00:36:39,320 --> 00:36:42,960
oder der Reputationsschaden 
würde y Euro weniger Umsatz 

738
00:36:42,960 --> 00:36:45,360
verursachen, das ist natürlich 
wirklich sehr, sehr schwer, da 

739
00:36:45,360 --> 00:36:48,480
eine Zahlen dazu schreiben. 
Aber das muss ja allein schon 

740
00:36:48,480 --> 00:36:50,680
dann gegen diese Zahl stehen. 
Zum Beispiel, Wir kaufen jetzt 

741
00:36:50,680 --> 00:36:54,320
dieses Tool für so und so viel 
Euro ein, oder wir führen jetzt,

742
00:36:54,560 --> 00:36:57,960
oder wir skalieren jetzt auf 
mehrere Server, um uns vor x 

743
00:36:57,960 --> 00:37:00,440
oder Jemen zu schützen, oder wir
upgraden jetzt hier auf den 

744
00:37:00,440 --> 00:37:03,920
höheren Pricing Tier, damit wir 
privates Netzwerk Features 

745
00:37:03,920 --> 00:37:05,280
irgendwie aktivieren können und 
sowas. 

746
00:37:05,280 --> 00:37:07,080
Das sind natürlich alles 
Entscheidungen wo auch Euros 

747
00:37:07,080 --> 00:37:09,840
hinter stehen, die man dann 
gegenrechnen muss und sollte und

748
00:37:09,840 --> 00:37:13,960
ich glaube da hilft es auch 
gerade dann so Metriken und 

749
00:37:13,960 --> 00:37:16,800
Transparenz zu schaffen, die. 
Sich natürlich auch für eine 

750
00:37:16,800 --> 00:37:19,440
bessere Kommunikation dann zu 
stakeholdern, also zu Management

751
00:37:19,440 --> 00:37:21,960
oder zu Fachbereichen schaffen. 
Und dann müssen wir das 

752
00:37:21,960 --> 00:37:25,680
natürlich auch in unsere 
etablierten Prozesse einbinden. 

753
00:37:25,680 --> 00:37:28,960
Also wir sollten jetzt nicht 
Security im Nachgang irgendwie 

754
00:37:28,960 --> 00:37:32,400
dran flanschen und die fertige 
Anwendung versuchen zu scannen, 

755
00:37:32,400 --> 00:37:36,200
sondern es soll ein Teil unseres
Entwicklungsprozesses sein und 

756
00:37:36,200 --> 00:37:39,520
da spricht man ganz häufig ja 
über Shift Security Left. 

757
00:37:39,520 --> 00:37:42,240
Wir müssen möglichst früh im 
Softwareentwicklungsprozess. 

758
00:37:42,880 --> 00:37:45,920
Entsprechend über Tools unseren 
Developern die Möglichkeit 

759
00:37:45,920 --> 00:37:47,680
geben, sichere Anwendung zu 
schreiben. 

760
00:37:47,680 --> 00:37:50,960
Da kommt irgendwie statische 
Code Analyse ein saas Tool dazu,

761
00:37:51,280 --> 00:37:53,840
wenn wir die Anwendung gebaut 
haben, vielleicht dynamische 

762
00:37:54,640 --> 00:37:57,320
Anwendungssicherheit über ein 
daas Tool und wir hatten auch 

763
00:37:57,320 --> 00:38:00,000
gerade darüber gesprochen, 
Dependency Scanning mit einem 

764
00:38:00,000 --> 00:38:03,520
Tool wie irgendwie renovate oder
depender Board, was ich auch 

765
00:38:03,520 --> 00:38:06,480
kostenfrei nutzen kann und 
dementsprechend habe ich das in 

766
00:38:06,480 --> 00:38:08,800
meinem Prozess verankert und 
damit auch so ein bisschen. 

767
00:38:09,200 --> 00:38:12,800
Kognitive Last weggenommen, weil
ich mir tatsächlich auch als 

768
00:38:12,800 --> 00:38:16,960
Developer jetzt nicht jedes Mal 
immer wieder die Gedanken machen

769
00:38:16,960 --> 00:38:19,560
muss und die einzelnen Schritte 
manuell prüfen muss, sondern das

770
00:38:19,560 --> 00:38:20,800
ist Teil. 
Des 

771
00:38:20,800 --> 00:38:23,280
Softwareentwicklungsprozesses 
der Großteil davon ist 

772
00:38:23,280 --> 00:38:26,000
automatisiert und ich weiß, wenn
irgendwelche Findings 

773
00:38:26,000 --> 00:38:28,960
rauskommen, ist es meine 
Aufgabe, diese Probleme zu 

774
00:38:28,960 --> 00:38:30,960
fixen. 
Aber ich muss jetzt nicht immer 

775
00:38:30,960 --> 00:38:33,600
manuell dran denken okay was ist
jetzt Schritt 1 in der 

776
00:38:33,600 --> 00:38:36,920
Checkliste Schritt 2 Schritt 3, 
sondern die Checkliste wird 

777
00:38:36,920 --> 00:38:39,680
quasi automatisiert 
durchgelaufen und ich muss nur 

778
00:38:39,680 --> 00:38:43,360
die Ergebnisse nachher behandeln
und das ist natürlich dann auch 

779
00:38:43,360 --> 00:38:46,240
ein Teil. 
Der entsprechenden Ausbildung, 

780
00:38:46,240 --> 00:38:49,360
die ich bekommen muss für die 
einzelnen Leute bei uns im 

781
00:38:49,360 --> 00:38:52,200
Entwicklungsteam, also für die 
einzelnen Developer, die wissen 

782
00:38:52,200 --> 00:38:55,760
müssen, worauf muss ich achten 
rund um Application Security, 

783
00:38:56,000 --> 00:38:58,560
vielleicht einfach mal diese 
Podcast Folge empfehlen oder 

784
00:38:58,560 --> 00:39:00,880
eine der anderen Folgen, auf die
wir verwiesen haben. 

785
00:39:00,880 --> 00:39:04,880
Wir haben mal in Folge 57 ein 
bisschen ausführlicher über das 

786
00:39:04,880 --> 00:39:07,120
Thema Application Security 
gesprochen, ist schon ein 

787
00:39:07,120 --> 00:39:09,280
bisschen länger her, ein paar 
Dinge sind vielleicht nicht mehr

788
00:39:09,280 --> 00:39:12,680
topaktuell, aber durchaus noch 
mal als Überblick eine 

789
00:39:12,680 --> 00:39:15,600
Empfehlung. 
Da noch mal zurück zu springen 

790
00:39:15,840 --> 00:39:19,920
und das Ganze dann vielleicht 
einzubetten in ein Security 

791
00:39:19,920 --> 00:39:22,960
Training, was halt nicht nur 
vielleicht einzelne Entwickler 

792
00:39:22,960 --> 00:39:26,440
machen, sondern was dazu führt, 
dass wir auch in jedem 

793
00:39:26,440 --> 00:39:30,240
Entwicklungsteam Security 
Champions ausbilden, auf die 

794
00:39:30,240 --> 00:39:33,520
alle zurückgreifen können, weil 
wenn ich weiß, Robin Manuel ist 

795
00:39:33,520 --> 00:39:36,400
derjenige, der sich mit dem 
Thema Application Security 

796
00:39:36,400 --> 00:39:39,360
auskennt, dann kann ich immer 
wenn ich unsicher bin auf dich 

797
00:39:39,360 --> 00:39:42,080
zu gehen und sagen, hey, ich 
habe jetzt gerade folgendes 

798
00:39:42,080 --> 00:39:44,280
Szenario. 
Und ich bin mir da gerade 

799
00:39:44,280 --> 00:39:46,120
unsicher, welche 
designentscheidung soll ich 

800
00:39:46,120 --> 00:39:49,280
jetzt hier treffen oder ich habe
hier folgendes finding was ist 

801
00:39:49,280 --> 00:39:52,880
denn der in unserem Unternehmen 
etablierte Weg mit einer 

802
00:39:52,880 --> 00:39:55,360
folgenden Schwachstelle 
umzugehen? 

803
00:39:55,360 --> 00:39:59,240
Also wie sollten wir das Ganze 
entsprechend implementieren, 

804
00:39:59,240 --> 00:40:01,920
dass wir dieses Problem nicht 
haben und das ist natürlich 

805
00:40:01,920 --> 00:40:04,480
super sinnvoll, weil wir dann 
nicht allein gelassen werden, 

806
00:40:04,480 --> 00:40:06,600
sondern wir haben die Tools und 
wir haben die Expertinnen und 

807
00:40:06,600 --> 00:40:09,200
Experten im Team. 
Daher würde ich mich aber glaube

808
00:40:09,200 --> 00:40:11,240
ich auch nur so mittelwohl 
mitfühlen, wenn ich dann ja 

809
00:40:11,240 --> 00:40:13,320
jetzt irgendwie der 
weisheitsliste Schluss sein 

810
00:40:13,320 --> 00:40:15,480
muss. 
Also ich finde es auch gut so 

811
00:40:15,480 --> 00:40:17,640
Security Experten zu haben, auf 
der anderen Seite kann man sich 

812
00:40:17,640 --> 00:40:20,280
natürlich auch nicht darauf 
verlassen, weil die natürlich 

813
00:40:20,280 --> 00:40:22,560
auch nicht immer alles wissen 
und auch nicht wahrscheinlich 

814
00:40:22,560 --> 00:40:25,960
gar nicht die Kapazitäten haben,
immer bei allem irgendwie to 

815
00:40:25,960 --> 00:40:28,720
Date zu bleiben und das bringt 
mich auch so ein bisschen so zu 

816
00:40:28,720 --> 00:40:32,400
dieser Frage ist dieser 
ganzheitliche Ansatz da 

817
00:40:32,400 --> 00:40:34,520
irgendwie wirklich praktikabel 
und. 

818
00:40:34,640 --> 00:40:36,960
Oder erzeugt ja nicht auch neue 
Spannungsfelder, wenn ich jetzt 

819
00:40:36,960 --> 00:40:39,920
irgendwie jeden Pull request ich
noch mal mit drüber gucken muss,

820
00:40:39,920 --> 00:40:42,600
weil ich bin ja hier für 
Security verantwortlich oder 

821
00:40:42,600 --> 00:40:46,000
wenn man halt irgendwie das ist 
das überhaupt realistisch, also 

822
00:40:46,000 --> 00:40:48,000
es ist, ist das überhaupt eine, 
habe ich überhaupt eine 

823
00:40:48,000 --> 00:40:50,800
realistische Umsetzbarkeit oder 
eine Chance, irgendwie für 

824
00:40:50,800 --> 00:40:55,680
kleine Teams oder Start ups? 
Ist denn wirklich der Anspruch 

825
00:40:55,680 --> 00:40:58,320
von jetzt in einem kleinen 
Developer Team die komplette 

826
00:40:58,320 --> 00:41:00,920
Supply Chain zu überwachen? 
Ist das nicht auch irgendwie 

827
00:41:00,920 --> 00:41:04,400
überfordernd und? 
Ich kann ja nicht extra jemanden

828
00:41:04,400 --> 00:41:08,000
dafür einstellen, wahrscheinlich
und können so kleinere Teams 

829
00:41:08,000 --> 00:41:11,920
überhaupt pragmatisch 
priorisieren, was sie jetzt von 

830
00:41:11,920 --> 00:41:16,240
dieser Top ten Liste und sowas 
abarbeiten und was sie 

831
00:41:16,240 --> 00:41:19,200
vielleicht irgendwie wo sie das 
Risiko eingehen, das ist für 

832
00:41:19,200 --> 00:41:21,240
mich noch nicht so ganz 
abschließend klar und das ist 

833
00:41:21,240 --> 00:41:24,240
glaube ich eine ja bestimmt eine
Frage, die auch irgendwie die 

834
00:41:24,240 --> 00:41:27,080
Community länger beschäftigt, 
deswegen ist das auch ein Punkt 

835
00:41:27,080 --> 00:41:29,080
wo ich mich freuen würde, wenn 
wenn diejenigen, die jetzt hier 

836
00:41:29,080 --> 00:41:30,840
zuhören dann. 
Da vielleicht eine Meinung zu 

837
00:41:30,840 --> 00:41:32,400
haben oder vielleicht ein 
bisschen spielen können, wie das

838
00:41:32,400 --> 00:41:36,840
bei euch im Unternehmen gelebt 
wird, das ist natürlich auch 

839
00:41:36,840 --> 00:41:38,640
was, wo man auch vorsichtig sein
muss, wo man das überhaupt 

840
00:41:38,640 --> 00:41:42,000
teilen möchte oder darf oder 
kann, weil ich glaube, kein 

841
00:41:42,000 --> 00:41:43,720
Unternehmen stellt sich 
eigentlich hin und sagt Ja bei 

842
00:41:43,720 --> 00:41:45,920
uns, da ist aber eben so 3 
Security aber noch einiges zu 

843
00:41:45,920 --> 00:41:49,280
tun. 
Ich glaube da einfacher kann man

844
00:41:49,280 --> 00:41:52,440
sich nicht auf so eine 
Hackerliste setzen lassen, aber.

845
00:41:52,680 --> 00:41:54,080
Aber vielleicht gibt es ja 
Leute, die das irgendwie 

846
00:41:54,080 --> 00:41:55,840
halbwegs anonym oder sowas 
vielleicht noch mal, die das 

847
00:41:55,840 --> 00:41:57,680
vielleicht gibt es ja positiv. 
Beispiel von Leuten, Hey, wir 

848
00:41:57,680 --> 00:42:00,320
sind ein kleines Team und wir 
schaffen es trotzdem, das zu 

849
00:42:00,320 --> 00:42:03,920
leben, dass es bei uns eine sehr
hohe Priorisierung hat, dieses 

850
00:42:03,920 --> 00:42:06,320
ganze Thema Security, das würde 
mich interessieren, wie ihr das 

851
00:42:06,640 --> 00:42:10,080
umsetzt und was das denn für 
einen Impact auf die auf 

852
00:42:10,080 --> 00:42:14,240
Produktivität von Teams hat und 
ob es da trotzdem so so 

853
00:42:14,240 --> 00:42:16,840
Spannungsfelder im Team dann 
gibt oder dass sich da irgendwie

854
00:42:16,840 --> 00:42:19,400
jemand dann auch darauf ausruht,
weil jemand anders ja für die 

855
00:42:19,400 --> 00:42:21,360
Security verantwortlich ist oder
sowas das. 

856
00:42:21,880 --> 00:42:24,080
Das fände ich mal spannend, wenn
ihr da eine Meinung zu hättet. 

857
00:42:24,240 --> 00:42:25,800
Ja, ich glaube, das ist ein ganz
wichtiger Punkt. 

858
00:42:25,800 --> 00:42:29,600
Man sagt ja immer, so das 
Prinzip von Death, SEC OPS und 

859
00:42:29,600 --> 00:42:32,840
wir sind alle Teil des Security 
Teams, ich glaube, wir müssen 

860
00:42:32,840 --> 00:42:35,600
uns alle Gedanken darüber 
machen, dass die Dinge, die wir 

861
00:42:35,600 --> 00:42:39,240
tagtäglich tun, Security 
Implikationen haben können, und 

862
00:42:39,240 --> 00:42:42,760
ich denke, gerade für kleine 
Teams sollte es dennoch 

863
00:42:42,760 --> 00:42:46,560
irgendwie so ein Mindestmaß auch
an Automatisierung im 

864
00:42:46,560 --> 00:42:49,200
Softwareentwicklungsprozess 
geben, also aus meiner Sicht. 

865
00:42:49,680 --> 00:42:53,920
Ist halt ein SARS Tool, also 
eine starke Code Analyse und ein

866
00:42:53,920 --> 00:42:57,600
Tool um meine Software Supply 
Chain zu überwachen. 

867
00:42:58,400 --> 00:43:02,480
Pflicht also das sollte man auf 
jeden Fall haben, darüber hinaus

868
00:43:02,560 --> 00:43:05,760
muss man diskutieren welche 
Tools man dann vielleicht noch 

869
00:43:05,760 --> 00:43:09,040
reinbringt und wenn man das dann
ergänzt mit diesem Bewusstsein, 

870
00:43:09,200 --> 00:43:12,320
dass jedes zusätzliche Package 
was ich hinzufügen eine 

871
00:43:12,320 --> 00:43:14,960
potenzielle Schwachstelle ist 
oder jedes Tool, was ich 

872
00:43:14,960 --> 00:43:16,800
vielleicht auf meinem Bildserver
laufen lasse und eine 

873
00:43:16,800 --> 00:43:19,520
potenzielle Schwachstelle ist. 
Hat man glaube ich schon ganz 

874
00:43:19,520 --> 00:43:22,640
viel abgedeckt und dazu so ein 
paar Best Practices, die du 

875
00:43:22,640 --> 00:43:25,120
gerade so in so Nebensätzen auch
erwähnt hattest. 

876
00:43:25,120 --> 00:43:28,280
Vielleicht bestimmte Dinge 
einfach zuzukaufen oder als 

877
00:43:28,280 --> 00:43:33,520
Third Party dann doch zu nutzen,
weil sie so komplex sind, dass 

878
00:43:33,520 --> 00:43:36,560
man, wenn man sie selber macht, 
potenziell eigentlich immer 

879
00:43:36,600 --> 00:43:39,280
irgendwo was vergisst. 
Ja, die Frage ist natürlich. 

880
00:43:39,280 --> 00:43:42,480
Auch irgendwie ist das, das ist 
die Tatsache, dass diese Liste 

881
00:43:42,480 --> 00:43:45,000
nicht mehr so konkret ist, und 
das haben wir ganz am Anfang mal

882
00:43:45,000 --> 00:43:46,840
gesagt, dass diese Oberst Pop 
ten so viel breiter wird. 

883
00:43:46,840 --> 00:43:49,760
Ist das nicht einfach ein? 
Zu hoher Abstraktionsgrad für 

884
00:43:49,760 --> 00:43:51,920
Junior Developer das war nämlich
auch so ein bisschen so. 

885
00:43:52,160 --> 00:43:53,840
Früher war das ja viel 
greifbarer. 

886
00:43:53,840 --> 00:43:56,840
Früher haben wir ganz konkrete 
Kategorien irgendwie gehabt, 

887
00:43:56,840 --> 00:44:00,520
keine Ahnung hier Cross Side 
Scripting oder SQL injections, 

888
00:44:00,520 --> 00:44:03,760
da musst du aufpassen und jetzt 
verlangt das ja schon sehr viel 

889
00:44:03,760 --> 00:44:07,040
von allem ab, wenn wir über 
misshandling of exceptional 

890
00:44:07,040 --> 00:44:10,960
conditions irgendwie sprechen 
oder insecure Design und sowas. 

891
00:44:10,960 --> 00:44:14,320
Das ist natürlich auch sehr 
unkonkret, da muss man natürlich

892
00:44:14,320 --> 00:44:17,440
auch schauen, dass man da alle 
ein Team mit an die Hand nimmt. 

893
00:44:17,640 --> 00:44:19,320
Und gerade wenn wir jetzt 
irgendwie sagen, dass eine 

894
00:44:19,320 --> 00:44:22,520
unserer Fazit ist, dass man 
Security von von der Designphase

895
00:44:22,520 --> 00:44:24,720
an Mitdenkt, dann muss man 
natürlich auch alle mitnehmen. 

896
00:44:24,720 --> 00:44:26,240
Und da meine ich jetzt auch 
nicht nur Junior developer, 

897
00:44:26,240 --> 00:44:27,600
sondern vielleicht auch 
irgendwie Leute, die gar nicht 

898
00:44:27,600 --> 00:44:28,720
so tief in diesem Thema drin 
sind. 

899
00:44:28,720 --> 00:44:31,080
Wir haben eben über PM, s oder 
sowas gesprochen, für die es 

900
00:44:31,080 --> 00:44:33,040
natürlich auch wichtig sein 
muss, das zu verstehen, was da 

901
00:44:33,040 --> 00:44:37,040
eigentlich hinter steckt, das 
genau finde ich glaube ich auch 

902
00:44:37,040 --> 00:44:39,000
noch so eine Sache, die jetzt 
durch diese Veränderung von 

903
00:44:39,000 --> 00:44:41,120
dieser Liste zumindest noch mal 
irgendwie einen Impact hat, weil

904
00:44:41,120 --> 00:44:43,360
sie eben ein bisschen 
unkonkreter ist. 

905
00:44:43,880 --> 00:44:46,640
Und natürlich. 
Die Tatsache, dass wir ja auch. 

906
00:44:47,520 --> 00:44:50,720
Wir sagen alle okay wir müssen 
unser System resilient bauen, 

907
00:44:51,200 --> 00:44:53,800
aber das ist auch ganz schwer zu
messen, da muss man ja auch 

908
00:44:53,800 --> 00:44:57,160
irgendwie, also ohne klare KP is
verfällt das Halt zu so einem 

909
00:44:57,160 --> 00:44:59,640
Buzzword, und da gibt es halt 
einfach einen Bedarf an 

910
00:44:59,640 --> 00:45:02,320
irgendwelchen Benchmarks und 
dass ich das regelmäßig teste, 

911
00:45:02,320 --> 00:45:05,040
da möchte ich auch gerne noch 
mal auf die Chaos Engineering 

912
00:45:05,040 --> 00:45:07,040
Folge verweisen, aber auch auf 
die Low Testing Folge, die wir 

913
00:45:07,040 --> 00:45:08,600
mal gemacht haben, da haben wir 
schon mal, nämlich so ein 

914
00:45:08,600 --> 00:45:10,800
bisschen darüber gesprochen, 
dass man eigentlich auch sein 

915
00:45:10,800 --> 00:45:14,240
System immer mal wieder unter 
Stress setzen sollte aus 

916
00:45:14,240 --> 00:45:16,400
verschiedenen Perspektiven dann 
bei diesen beiden folgen. 

917
00:45:17,160 --> 00:45:18,800
Aber ich glaube schon, dass das 
Fragen sind, auch hier, die 

918
00:45:18,800 --> 00:45:21,600
unsere Community in den nächsten
Monaten oder sogar Jahren noch 

919
00:45:21,600 --> 00:45:24,720
weiter begleiten werden. 
Dann lass uns zum Abschluss das 

920
00:45:24,720 --> 00:45:26,560
Ganze noch mal ein bisschen 
zusammenfassen. 

921
00:45:26,560 --> 00:45:31,400
Also was dieses Ovas Top 10 
Update für uns als Development 

922
00:45:31,400 --> 00:45:34,720
Teams bedeutet. 
Und zwar sehen wir da 3 Themen, 

923
00:45:34,720 --> 00:45:38,320
einmal den Perspektivwechsel von
der Fehlerbehebung hinzu, einem 

924
00:45:38,320 --> 00:45:42,800
ganzheitlichen Ansatz und mehr 
proaktiv als reaktiv. 

925
00:45:43,320 --> 00:45:47,200
Dann haben wir auch so neue 
Bereiche wie das ganze Thema 

926
00:45:47,360 --> 00:45:49,920
Software, Supply Chain und 
Resilienz, die wir uns 

927
00:45:49,920 --> 00:45:52,480
anschauen. 
Wir haben immer komplexere 

928
00:45:52,480 --> 00:45:56,360
Systeme und dementsprechend auch
komplexere Risiken und 

929
00:45:56,360 --> 00:46:00,560
dementsprechend kommt hier das 
ganze Thema Appsac besonders zu 

930
00:46:00,560 --> 00:46:04,320
tragen, weil wir natürlich dort 
auch immer mehr Angriffsvektoren

931
00:46:04,320 --> 00:46:07,440
auch sehen. 
Und der dritte Punkt ist, dass 

932
00:46:07,440 --> 00:46:10,760
die Verantwortung auch natürlich
geteilt ist in Zukunft oder auch

933
00:46:10,760 --> 00:46:13,840
heute sein sollte. 
Das heißt, wir alle sind für 

934
00:46:13,840 --> 00:46:17,800
Security verantwortlich, es gibt
nicht nur das Security Team, was

935
00:46:17,800 --> 00:46:22,080
sich mit den Themen beschäftigt,
sondern Security sollte in der 

936
00:46:22,080 --> 00:46:24,920
Ausbildung, in den Prozessen und
der Kultur des Unternehmens eine

937
00:46:24,920 --> 00:46:28,040
wichtige Rolle spielen und 
dementsprechend über alle diese 

938
00:46:28,040 --> 00:46:31,040
Aspekte hinweg auch Pflicht 
werden. 

939
00:46:31,360 --> 00:46:32,880
Genau. 
Ich glaube das Security Team ist

940
00:46:32,880 --> 00:46:34,080
nach wie vor super wichtig, 
aber. 

941
00:46:34,440 --> 00:46:37,760
Aber das ist dafür da, eben 
diese Kultur über die ganze 

942
00:46:37,760 --> 00:46:41,640
Company am besten hinweg zu 
schaffen und klare Vorgaben zu 

943
00:46:41,640 --> 00:46:44,600
machen und dabei zu helfen, dass
wir uns dahin zu entwickeln. 

944
00:46:44,600 --> 00:46:48,200
Ich sehe dieses Overs Top 10 
Update zum Beispiel als als 

945
00:46:48,200 --> 00:46:50,600
Riesenchance, also natürlich 
einmal als Chance, die 

946
00:46:50,600 --> 00:46:54,560
Einzelnen, die eigenen Prozesse,
Tools, wissensstände auch. 

947
00:46:54,840 --> 00:46:57,600
Kritisch zu überprüfen, aber 
auch als Chance, so die 

948
00:46:57,600 --> 00:47:00,640
Sicherheitskultur 
weiterzuentwickeln. 

949
00:47:00,640 --> 00:47:03,000
Und ich glaube, das ist was, das
sehe ich schon bei so einem 

950
00:47:03,000 --> 00:47:04,720
Security Team mal. 
Irgendjemand muss für diesen 

951
00:47:05,040 --> 00:47:07,760
Culture Shift ja auch 
verantwortlich sein und den 

952
00:47:07,760 --> 00:47:11,200
Treiben und da auch die 
Vorweggehen und die Expertise 

953
00:47:11,200 --> 00:47:13,880
aufbauen und das finde ich so 
eine coole Chance, dass man sich

954
00:47:13,880 --> 00:47:15,760
das jetzt irgendwie noch mal 
nimmt und sagt, Hey guck mal. 

955
00:47:16,000 --> 00:47:17,960
Hier hat sich jetzt mehr oder 
weniger offiziell so ein 

956
00:47:17,960 --> 00:47:19,760
bisschen die 
Bedrohungslandschaft verändert. 

957
00:47:20,000 --> 00:47:22,640
Wir müssen das ganzheitlich 
machen, es gibt bestimmt auch 

958
00:47:22,640 --> 00:47:24,960
tolle Teams, die das schon 
machen und bestimmt auch Teams, 

959
00:47:24,960 --> 00:47:27,560
wo es dann auch ein bisschen 
Bedarf gibt, weil es ist nichts,

960
00:47:27,560 --> 00:47:30,000
wo ich einfach Code oder Binary 
über den Sound schmeiße ins 

961
00:47:30,000 --> 00:47:33,360
Security Team irgendwas abcheckt
und ich glaube da kann man, wenn

962
00:47:33,360 --> 00:47:37,120
man jetzt so eine Kultur richtig
aufbauen und sich dann auch für 

963
00:47:37,360 --> 00:47:41,120
die nächste overs top 10, die 
wir dann die ihr dann in diesem 

964
00:47:41,360 --> 00:47:43,760
dem To do Cast im Jahr 2029 
hört. 

965
00:47:45,120 --> 00:47:47,040
Wenn wir die da besprechen. 
Wir haben diese 

966
00:47:47,040 --> 00:47:48,960
Sicherheitskultur aufgebaut, 
dann ist es wahrscheinlich auch 

967
00:47:49,280 --> 00:47:51,800
deutlich einfacher, auf eine 
veränderte Bedrohungslage zu 

968
00:47:51,800 --> 00:47:54,280
reagieren, weil man ja ohnehin 
Security schon in allen 

969
00:47:54,280 --> 00:47:57,120
Bereichen mitdenkt. 
Ja, und am Anfang sah es so aus,

970
00:47:57,120 --> 00:48:00,160
als gibt es gar nicht so viele 
Änderungen, aber letzten Endes 

971
00:48:00,160 --> 00:48:02,520
war es doch so viel Stoff, dass 
wir hier über eine 

972
00:48:02,520 --> 00:48:05,120
Dreiviertelstunde uns zu dem 
Thema ausgetauscht haben. 

973
00:48:05,120 --> 00:48:08,160
Ich fand es wieder extrem 
spannend, da tiefer reinzugehen 

974
00:48:08,320 --> 00:48:11,400
und ich hoffe, euch hat die 
Folge genauso gut gefallen wie 

975
00:48:11,400 --> 00:48:14,960
mir jetzt nach dem aufnehmen. 
Und falls das so ist, lasst uns 

976
00:48:14,960 --> 00:48:16,640
gerne eine positive Bewertung 
da. 

977
00:48:16,640 --> 00:48:20,320
Das könnt ihr auf Apple Podcast 
oder Spotify machen und wir 

978
00:48:20,320 --> 00:48:23,600
freuen uns natürlich auch immer 
über eine positive Bewertung 

979
00:48:23,600 --> 00:48:26,080
über den Daumen nach oben auf 
Youtube oder vielleicht ein 

980
00:48:26,080 --> 00:48:27,840
Abonnement, falls ihr uns dort 
hört, wir. 

981
00:48:28,240 --> 00:48:32,080
Freuen uns natürlich auch immer 
über Kaffee, also freuen uns 

982
00:48:32,080 --> 00:48:33,680
sehr, wenn ihr uns da einen 
Kaffee ausgeben möchtet. 

983
00:48:33,680 --> 00:48:37,200
Findet ihr einen Link zu bei mir
Coffee unten in den Shownotes 

984
00:48:37,200 --> 00:48:39,040
oder wenn ihr zu eurem eigenen 
Coffee. 

985
00:48:39,520 --> 00:48:42,040
Die passende Nerd Tasse haben 
wollt, dann schaut auch gern in 

986
00:48:42,040 --> 00:48:45,080
unserem kleinen Fanshop vorbei. 
Links zu allem, was wir 

987
00:48:45,080 --> 00:48:47,160
besprochen haben und so auch den
Sachen findet ihr natürlich 

988
00:48:47,160 --> 00:48:50,160
unten und bis dahin bleibt uns 
eigentlich gar nicht mehr viel 

989
00:48:50,160 --> 00:48:53,080
zu sagen, als bis nächste Woche,
wir hören uns nächsten Montag zu

990
00:48:53,080 --> 00:48:56,720
einer neuen Folge wieder, bis 
dahin schreibt viel sicheren 

991
00:48:56,720 --> 00:48:58,840
Code, das ist glaube ich ganz 
wichtig, das ist das Call to 

992
00:48:58,840 --> 00:49:02,880
Action von dieser Folge schaut 
euch diese overs top 10 mal an, 

993
00:49:03,600 --> 00:49:06,480
wir verlinken auch einen einen 
Blog Post der das ganze ganz gut

994
00:49:06,480 --> 00:49:07,680
noch mal irgendwie 
zusammenfasst. 

995
00:49:08,360 --> 00:49:10,640
Wenn man jetzt irgendwie dem 
Chef nicht die ganze 45 Minuten 

996
00:49:10,640 --> 00:49:12,160
folge hier schicken will, ist 
dann das war irgendwie eine 

997
00:49:12,160 --> 00:49:14,000
kurze Zusammenfassung, aber 
schickt auch gern die Folge 

998
00:49:14,000 --> 00:49:15,600
weiter. 
Freuen wir uns auch und 

999
00:49:15,600 --> 00:49:18,240
ansonsten bis bald bis nächste 
Woche hat eine gute Zeit. 

1000
00:49:18,840 --> 00:49:19,440
Bis dann.