1 00:00:01,980 --> 00:00:05,890 Hey. Hi zusammen und herzlich 2 00:00:05,900 --> 00:00:10,080 Willkommen zu einer neuen Folge vom to Cast, dem Podcast für 3 00:00:10,090 --> 00:00:17,850 Entwickler und Entwicklerinnen SCASASTDASTIAST. 4 00:00:18,170 --> 00:00:20,910 Heute sind eine ganze Menge Abkürzungen hier in unseren 5 00:00:20,920 --> 00:00:24,820 Notizen, von denen ich noch nie gehört habe und das macht mir 6 00:00:24,830 --> 00:00:27,630 ein bisschen Sorge, denn malte du hast den Titel gewählt. 7 00:00:27,640 --> 00:00:32,060 Für diese Folge und der heißt Application Security ist meine 8 00:00:32,070 --> 00:00:34,960 Anmeldung unsicher. Woher kommt dieser Titel? 9 00:00:35,030 --> 00:00:38,770 Woher kommt dieses Thema hol uns doch mal kurz ab, ob deine 10 00:00:38,780 --> 00:00:42,630 Anwendungen sicher oder unsicher sind, kann ich dir nicht sagen 11 00:00:42,640 --> 00:00:45,610 und ich glaube, das ist die große Gefahr, dass du selber 12 00:00:45,620 --> 00:00:47,850 nicht weißt, ob deine Anwendung sicher sind. 13 00:00:47,900 --> 00:00:50,640 Du hoffst es zwar, aber kannst du sicher sein. 14 00:00:51,380 --> 00:00:54,070 Das weiß ich nicht, aber da können die richtigen Tools bei 15 00:00:54,080 --> 00:00:56,010 helfen. Ich beschäftige mich mit diesem 16 00:00:56,020 --> 00:00:59,850 Thema Application Security seit einiger Zeit, da ich in meinem 17 00:00:59,860 --> 00:01:03,120 Job bei github im Moment sehr viel mit dem Thema Application 18 00:01:03,130 --> 00:01:06,850 Security zu tun habe, damit vielen Kunden genau über diese 19 00:01:06,860 --> 00:01:08,800 Themen auch Rede. Und ich dachte, es ist 20 00:01:08,810 --> 00:01:13,770 vielleicht ein Thema, über das viele Leute aktuell reden und wo 21 00:01:13,780 --> 00:01:16,620 man vielleicht auch die Hintergründe zu diesen 22 00:01:16,630 --> 00:01:19,020 Abkürzungen, die du gerade genannt hast, einfach mal besser 23 00:01:19,030 --> 00:01:21,610 verstehen möchte und dementsprechend dachte ich wir. 24 00:01:21,680 --> 00:01:24,540 Wir schauen heute mal was kann ich machen, um meine eigene 25 00:01:24,550 --> 00:01:28,060 Anwendung sicher zu machen und herauszufinden, ob ich 26 00:01:28,110 --> 00:01:31,240 vielleicht verwundbarkeiten in meiner Anwendung hab, ob meine 27 00:01:31,250 --> 00:01:34,960 Anwendung alles Security Best Practices erfüllt und welche 28 00:01:34,970 --> 00:01:38,280 Arten von Tools mit dabei helfen können, genau dieses Wissen zu 29 00:01:38,290 --> 00:01:40,660 bekommen und da gibt es natürlich verschiedene 30 00:01:40,670 --> 00:01:44,360 Kategorien, in die ich mal reinschauen kann und häufig 31 00:01:44,370 --> 00:01:49,100 fangen Developer ja dann an, auf ihren eigenen Code zu schauen, 32 00:01:49,210 --> 00:01:51,350 sprechen mit Kolleginnen und Kollegen darüber. 33 00:01:51,690 --> 00:01:54,830 Wie kann ich meinen Code entsprechend sicher machen? 34 00:01:54,840 --> 00:01:56,970 Und da hatten wir in der Vergangenheit schon mal über das 35 00:01:56,980 --> 00:02:01,780 Thema Oberst Top Ten gesprochen und das hilft mir dann schon 36 00:02:01,790 --> 00:02:04,950 mal, wenn ich dort mich eingelesen habe meinen eigenen 37 00:02:04,960 --> 00:02:06,620 Code. Gegen die üblichen Angriffs 38 00:02:06,630 --> 00:02:10,310 Sektoren abzusichern. Dafür brauche ich natürlich das 39 00:02:10,320 --> 00:02:12,670 Wissen und ich brauche die Kolleginnen und Kollegen, die 40 00:02:12,680 --> 00:02:15,350 mir helfen, in den entsprechenden Code Reviews 41 00:02:15,360 --> 00:02:19,970 genau diese Dinge abzuklopfen und da wäre es natürlich super, 42 00:02:19,980 --> 00:02:23,190 wenn man da auch Tools hätte, die mir genau in diesen 43 00:02:23,200 --> 00:02:27,200 Bereichen helfen und das Ganze automatisiert durchführen und 44 00:02:27,210 --> 00:02:30,880 damit kommen wir jetzt in den Bereich der Security Tools, mit 45 00:02:30,890 --> 00:02:36,570 denen viele einsteigen und das sind die SAS t sast Tools, das 46 00:02:36,580 --> 00:02:39,260 ist static application security testing. 47 00:02:39,630 --> 00:02:42,990 Und da gibt es eine Reihe von Tools, die mir helfen, meinen 48 00:02:43,000 --> 00:02:46,700 eigenen Sourcecode zu scannen auf übliche Wunder Abilities 49 00:02:46,710 --> 00:02:51,810 wäre das nochmal. Nachhören möchte die Folge mit 50 00:02:51,820 --> 00:02:54,330 der owasp top ten. Das ist so eine Top ten Liste, 51 00:02:54,340 --> 00:02:58,610 auf die man seine Anwendungen prüfen sollte, was Security 52 00:02:58,620 --> 00:03:01,890 flaws und so Common Security flaws angeht, war Folge 30 von 53 00:03:01,900 --> 00:03:05,510 unserem Podcast. Und auch 2 Folgen davor, nämlich 54 00:03:05,520 --> 00:03:09,740 folge 2928 wo über die J Sicherheitslücke Look for Shell 55 00:03:10,200 --> 00:03:13,190 und darüber den Fall Color JS und Fake JS gesprochen haben. 56 00:03:13,200 --> 00:03:15,790 Das könnte spannend sein. Wer sich für das Thema generell 57 00:03:15,800 --> 00:03:18,780 interessiert. Wir hatten das Thema Security ja 58 00:03:18,790 --> 00:03:22,680 schon häufiger in unserem Podcast, deswegen freue ich 59 00:03:22,690 --> 00:03:25,420 mich, dass wir wissen D einsteigen und ein paar Tools 60 00:03:25,430 --> 00:03:29,700 vorstellt, mit denen ich quasi nicht nur diese diese Liste 61 00:03:29,710 --> 00:03:32,320 durchgehen kann, sondern dass sie auch wirklich testen kann. 62 00:03:32,330 --> 00:03:34,160 Wahrscheinlich automatisiert testen kann. 63 00:03:34,900 --> 00:03:37,930 Was ist denn überhaupt Static application Security Testing 64 00:03:37,940 --> 00:03:42,420 oder was ist denn generell statisches Testing und kannst du 65 00:03:42,430 --> 00:03:45,570 vielleicht kurz mal abholen? Static application security 66 00:03:45,580 --> 00:03:49,790 testing tools und Tools, die meine Anwendung auf Basis des 67 00:03:49,800 --> 00:03:53,450 Quellcodes testen. Das heißt, ich habe ein Tool, 68 00:03:53,460 --> 00:03:56,310 das sich in der Regel entweder lokal auf meiner Maschine 69 00:03:56,320 --> 00:04:00,280 ausführen kann oder im Rahmen meiner CI Pipelines laufen lasse 70 00:04:00,580 --> 00:04:03,950 und dieses Tool scannt meinen Sourcecode mithilfe von 71 00:04:03,960 --> 00:04:09,840 bestimmten Patterns und Queries. Auf übliche oder häufige 72 00:04:09,890 --> 00:04:12,720 Verwundbarkeiten im Code das können so einfache Sachen sein 73 00:04:12,730 --> 00:04:17,660 wie sequence, Action oder Cross Side Scripting Attacken für die 74 00:04:17,750 --> 00:04:19,779 meine Anwendung anfällig sein kann. 75 00:04:20,230 --> 00:04:24,520 Dieses statische Scanning funktioniert wunderbar, wenn ich 76 00:04:24,530 --> 00:04:28,970 den Code meiner Anwendung verfügbar hab ne Anwendung wird. 77 00:04:29,750 --> 00:04:34,160 Über den kompletten Source Code gescannt, was natürlich vor und 78 00:04:34,170 --> 00:04:37,430 Nachteile hat, das heißt, es werden auch nicht erreichbare 79 00:04:37,470 --> 00:04:39,950 Bereiche des Quellcodes gescannt, das heißt, während der 80 00:04:39,960 --> 00:04:43,000 Ausführung würde eine potenzielle Verwundbarkeit in 81 00:04:43,010 --> 00:04:45,560 diesem nicht erreichbaren Bereich kein Problem darstellen, 82 00:04:45,570 --> 00:04:47,460 aber diese werden auch mitgescannt. 83 00:04:47,500 --> 00:04:50,210 Das heißt, ich kann komplett durch meine Anwendung durch 84 00:04:50,220 --> 00:04:54,060 Scannen und kann das während der Entwicklung tun und das ist 85 00:04:54,070 --> 00:04:56,130 natürlich super, weil ich es relativ früh im 86 00:04:56,140 --> 00:04:59,400 Entwicklungszyklus machen kann. Das heißt, meine Anwendung ist 87 00:04:59,410 --> 00:05:02,770 an dieser Stelle. Noch gar nicht tatsächlich 88 00:05:02,780 --> 00:05:05,640 irgendwo im Betrieb, sondern während der Entwicklungszeit 89 00:05:05,700 --> 00:05:09,250 kann ich automatisiert auf genau diese Kriterien prüfen, die wir 90 00:05:09,260 --> 00:05:11,810 auch schon in der Vergangenheit diskutiert haben. 91 00:05:11,850 --> 00:05:14,120 Alles natürlich streiten darüber, ob man nicht erreichbar 92 00:05:14,130 --> 00:05:16,170 n Code überhaupt in seinem Produkt haben möchte oder 93 00:05:16,180 --> 00:05:17,430 sollte. Aber generell ist es nicht 94 00:05:17,440 --> 00:05:20,030 verkehrt. Das heißt aber, dass hier nicht 95 00:05:20,040 --> 00:05:21,920 nur dependencies oder irgendwas gescannt werden. 96 00:05:21,930 --> 00:05:24,400 Ja, hier wird nicht irgendwie geschaut benutze ich vielleicht 97 00:05:24,410 --> 00:05:27,000 irgendeine Party Library, eine bekannte Sicherheitslücke und 98 00:05:27,010 --> 00:05:30,430 hier werden wirklich Coding Patterns von meinen 99 00:05:30,440 --> 00:05:31,650 Entwicklerinnen und Entwicklern angeschaut. 100 00:05:32,910 --> 00:05:35,480 Und wie gesagt ich schau mal, das ist vielleicht ein Fehler, 101 00:05:35,490 --> 00:05:38,450 der häufig gemacht wird oder hast du hier checkst du gar 102 00:05:38,460 --> 00:05:41,480 nicht, ob da ne SQL Injection vielleicht möglich ist oder hier 103 00:05:41,490 --> 00:05:44,820 vertraust du einfach irgend ne user Input irgendwo ohne 104 00:05:44,830 --> 00:05:48,180 irgendwelche Checks, oder hier gibt es irgendwie ein Part den 105 00:05:48,190 --> 00:05:51,800 du einfach offen lässt oder hier gibts ne PI, die nicht 106 00:05:51,810 --> 00:05:55,120 abgesichert ist oder hier machst du vielleicht auch einen Unsafe 107 00:05:55,190 --> 00:05:58,560 Call, weil du reflection benutzt oder was auch immer? 108 00:05:58,840 --> 00:06:01,240 Solche Dinge werden dort getestet ja, das heißt ich lade 109 00:06:01,250 --> 00:06:04,250 irgendwo in South hin. Oder vielleicht lokalen Tool? 110 00:06:04,260 --> 00:06:07,910 Was meinen Sourcecode scannt auf diese ja eigentlich antipatterns 111 00:06:07,920 --> 00:06:12,990 versteh ich genau das Thema dependencies, da kommen wir 112 00:06:13,000 --> 00:06:14,610 nachher nochmal zu. Das ist ein separates Thema, 113 00:06:14,620 --> 00:06:18,200 hier reden wir tatsächlich über den selbstgeschriebenen Code, 114 00:06:18,210 --> 00:06:20,890 den Code, den du und deine Kolleginnen und Kollegen 115 00:06:20,900 --> 00:06:23,530 geschrieben haben. Der letzten Endes von diesem 116 00:06:23,570 --> 00:06:27,600 Tool gescannt wird. Auf Basis von Security Best 117 00:06:27,610 --> 00:06:31,870 Practices und dort dieses Security Best Practices in. 118 00:06:32,940 --> 00:06:35,590 Bestimmten Patterns hinterlegt oder einen bestimmten Queries je 119 00:06:35,600 --> 00:06:39,820 nach Technologie hinterlegt wird meine Anwendung dann auf diese 120 00:06:40,090 --> 00:06:44,930 hin untersucht. Das hat den Vorteil, dass ich 121 00:06:44,940 --> 00:06:49,090 hier extrem zuverlässig genau auf diese Pattern scannen kann, 122 00:06:49,310 --> 00:06:53,870 hat aber auch gegebenenfalls den Nachteil, dass wir da relativ 123 00:06:53,880 --> 00:06:57,260 viele Positive bekommen können, weil wir da natürlich nicht 124 00:06:58,070 --> 00:07:01,380 qualifiziert in die Anwendung und in die Ausführung der 125 00:07:01,390 --> 00:07:05,380 Anwendung reinschauen, sondern wirklich nur mit ganz groben 126 00:07:05,390 --> 00:07:09,360 Mustern oder Queries arbeiten, die sehr generisch sind und da 127 00:07:09,400 --> 00:07:12,320 kann ich natürlich relativ viel Beifang bekommen und muss dann 128 00:07:12,330 --> 00:07:14,780 letzten Endes als Developer durch alle diese findings. 129 00:07:14,850 --> 00:07:17,950 Durchgehen und schauen ist das etwas, was wirklich eine Gefahr 130 00:07:17,960 --> 00:07:21,330 darstellt oder ist das etwas, was vielleicht gar nicht ein 131 00:07:21,340 --> 00:07:23,060 Problem darstellt? Das hängt natürlich ein bisschen 132 00:07:23,070 --> 00:07:24,850 von Tool ab. Manche Tools haben mehr false 133 00:07:24,860 --> 00:07:28,460 Positives, manche weniger. Aber grundsätzlich lässt sich 134 00:07:28,470 --> 00:07:32,950 sagen bei dieser statischen Analyse habe ich häufig auch mit 135 00:07:32,960 --> 00:07:34,830 vielen Volks Positives zu kämpfen. 136 00:07:35,340 --> 00:07:37,660 Das ist aber ein Zweifel, was ich mir nur einmal irgendwie 137 00:07:37,670 --> 00:07:39,510 machen muss und dann zentrale verwalten. 138 00:07:39,520 --> 00:07:43,030 Ne also ich kenne da so ein bisschen so Security Scanning 139 00:07:43,040 --> 00:07:46,030 Tools, die dann schauen, wo ich in meinen Repository vielleicht 140 00:07:46,040 --> 00:07:49,390 versehentlich eingesteckt. Aber wenn es dann falls Positive 141 00:07:49,400 --> 00:07:53,220 gibt, also die, die guten Tools haben alle irgendwo ne zentral 142 00:07:53,230 --> 00:07:56,160 gemanagte Verwaltung, wo ich dann einmal zentral sage Nein, 143 00:07:56,170 --> 00:08:00,240 in dieser Datei in Zeile 15 - 17 das ist nur ein Test n testkey 144 00:08:00,250 --> 00:08:03,230 oder irgendwas ist da eingecheckt is und so kenne ich 145 00:08:03,240 --> 00:08:05,210 das auch von diesen Tools. Ich habe selber in einem Projekt 146 00:08:05,220 --> 00:08:08,800 mal mit Sonar Cloud gearbeitet, das fällt ja unter dem unter. 147 00:08:08,810 --> 00:08:11,720 Die Kategorie Statische Analyse dann und dort war es zumindest 148 00:08:11,730 --> 00:08:15,450 so, dass ein zentrales Dashboard gab, wo dann diese diese Dinge 149 00:08:15,460 --> 00:08:17,220 gepflegt wurden. Unter anderem auch technische 150 00:08:17,230 --> 00:08:19,990 Schulden gemessen wurden. Das war sehr wichtig. 151 00:08:20,760 --> 00:08:24,320 Und dort konnte man dann aber quasi an einer Stelle zentral 152 00:08:24,520 --> 00:08:27,630 sowohl erstmal regeln für das Projekt legen festlegen ist 153 00:08:27,640 --> 00:08:30,840 generell für alle meine Projekte oder für dieses Projekt dann 154 00:08:30,850 --> 00:08:34,150 aber in Ordnung und aber auch diese Findings Flaggen, in dem 155 00:08:34,159 --> 00:08:37,250 man sagen könnte ja, weiß ich. Mache ich aber eine Ausnahme aus 156 00:08:37,260 --> 00:08:41,990 den Gründen und dann wird quasi diese Informationen an alle 157 00:08:42,030 --> 00:08:45,050 Decks verteilt, die dieses Tool vielleicht lokal laufen lassen 158 00:08:45,340 --> 00:08:48,030 oder wenn ich das Tool nur im Rahmen der Pipeline ablaufen 159 00:08:48,040 --> 00:08:50,750 lasse, dann zieht sich sowieso noch einmal die Informationen 160 00:08:50,990 --> 00:08:54,010 und diese Findings kommen nicht jedes Mal wieder hoch, sondern 161 00:08:54,080 --> 00:08:56,690 ne wenn ich als zentral gemanagt habe, kann ich natürlich sagen, 162 00:08:56,700 --> 00:08:59,550 dass nur neue Findings hoch babbeln sollen. 163 00:09:00,260 --> 00:09:04,540 Und also ich hab ich hab die Erfahrung gemacht, dass schon 164 00:09:04,930 --> 00:09:07,800 die Qualität drastisch verbessert, natürlich deutlich 165 00:09:07,810 --> 00:09:11,190 verbessert die Geschwindigkeit nicht ab, weil natürlich am 166 00:09:11,200 --> 00:09:14,490 Anfang erst mal viele Findings wahrscheinlich anfallen, die man 167 00:09:14,500 --> 00:09:18,880 einmal durcharbeiten muss. Und diese Dinger hat Tage sehr 168 00:09:18,890 --> 00:09:21,930 picky, sind aber wenn ich mich drauf einlasse, die Qualität 169 00:09:21,940 --> 00:09:24,700 meines Codes aber auch sehr, sehr, sehr, sehr gut werden kann 170 00:09:25,250 --> 00:09:26,790 bisschen abhängig davon wahrscheinlich, welche 171 00:09:26,800 --> 00:09:30,050 Programmiersprache ich verwende und wie viele Peter und regeln 172 00:09:30,060 --> 00:09:33,120 diese Tools dann mitbringen? Aber ich sag mal so, die 173 00:09:33,130 --> 00:09:35,920 gängigsten Sprachen also wir haben damals eingesetzt bei dem 174 00:09:35,930 --> 00:09:40,960 Projekt oder machen diesen Sommer habe ich wisconsins sehr 175 00:09:40,970 --> 00:09:43,720 gut und soweit ich weiß kommt sogar aus der Java Welt, das 176 00:09:43,730 --> 00:09:46,180 heißt, da wird wahrscheinlich sehr wichtig sein genau das 177 00:09:46,190 --> 00:09:48,600 hängt dann von der Sprache und Technologie ab, die du 178 00:09:48,610 --> 00:09:51,620 verwendest wenn du irgendwelche neuen oder einer 179 00:09:51,630 --> 00:09:54,400 Nischentechnologien verwendest, funktionieren solche Tools 180 00:09:54,410 --> 00:09:58,640 natürlich nicht so gut und tatsächlich auch wie diese Tools 181 00:09:58,650 --> 00:10:02,180 zu handeln sind und wie viele positive sie haben, hängt auch 182 00:10:02,190 --> 00:10:05,380 ein bisschen vom Tool ab. Manche Tools konzentrieren sich 183 00:10:05,390 --> 00:10:09,060 ausschließlich auf den Bereich Security, manche Tools ergänzen 184 00:10:09,070 --> 00:10:14,530 das noch um solche Themen wie und wie Codes, Mels oder Linking 185 00:10:14,540 --> 00:10:17,990 oder andere Best Practices hängt ein bisschen davon ab, welchen 186 00:10:18,270 --> 00:10:21,740 welches Tool man für welchen Use Case dort einführt und die guten 187 00:10:21,750 --> 00:10:25,180 Tools, die lassen sich natürlich auch in den ganzen Pool request 188 00:10:25,190 --> 00:10:28,880 Flow einbinden und scannen auch letzten Endes nur auf die 189 00:10:28,890 --> 00:10:32,120 Deltas, die ich dann in meinem Feature Branch in meinem Pool 190 00:10:32,130 --> 00:10:35,820 request habe und ich als Developer bekomme dann letzten 191 00:10:35,830 --> 00:10:39,140 Endes auch nur die Findings. Die entweder sich auf meinen 192 00:10:39,150 --> 00:10:43,600 Code beziehen oder wo ich durch meinen Code jetzt zum ersten Mal 193 00:10:43,610 --> 00:10:47,460 anderen Code aufrufe der letzten Endes nobility mit sich bringt. 194 00:10:47,470 --> 00:10:49,880 Das heißt ich hab den zwar nicht selber geschrieben hat n Kollege 195 00:10:49,890 --> 00:10:52,920 geschrieben und durch meinen Code dieser Code jetzt 196 00:10:52,930 --> 00:10:56,270 aufgerufen und wird dadurch zur Gefahr und die guten Tools 197 00:10:56,530 --> 00:11:00,970 bilden natürlich so ne Art Ablauf Graph und wissen, dass 198 00:11:01,220 --> 00:11:04,440 diese Funktion jetzt aufgerufen wird, durch zum Beispiel den 199 00:11:04,450 --> 00:11:07,370 Code den ich geschrieben habe und sagen mir das dann Impuls. 200 00:11:07,750 --> 00:11:10,010 Und geben wir im Idealfall auch noch Informationen? 201 00:11:10,640 --> 00:11:12,950 Warum das eine Gefahr ist und wie ich dieses Problem fixen 202 00:11:12,960 --> 00:11:16,430 kann und das fällt unter diesen ganzen Themenbereich Shift 203 00:11:16,440 --> 00:11:19,630 Security Left, das heißt, Wir wollen in unseren Software 204 00:11:19,640 --> 00:11:23,400 Development Lifecycle möglichst früh, also auf der linken Seite 205 00:11:23,670 --> 00:11:28,430 solche Security Tests durchführen, damit zum einen wir 206 00:11:28,440 --> 00:11:32,190 als Developer diese Probleme möglichst früh erkennen und auch 207 00:11:32,200 --> 00:11:35,160 fixen können und letzten Endes das ganze nie wirklich zu einem 208 00:11:35,170 --> 00:11:38,910 Problem wird, zum Beispiel in der Produktionsphase oder 209 00:11:38,920 --> 00:11:41,630 vielleicht sogar die Produktion verzögert. 210 00:11:41,700 --> 00:11:44,270 Weil wir vielleicht das Testing erst relativ am Ende machen, 211 00:11:44,280 --> 00:11:46,340 wenn die ganze Anwendung fertiggestellt ist und dann das 212 00:11:46,350 --> 00:11:49,440 Security Team einmal draufschaut und wir dann die entsprechenden 213 00:11:49,450 --> 00:11:52,140 Probleme finden, ja Shift Security Left ist glaube ich so 214 00:11:52,150 --> 00:11:55,020 n Termin muss mal kurz erklären, weil man irgendwie oft hört. 215 00:11:55,030 --> 00:12:00,700 In der in der Branche. Das wird schon gesagt davon oder 216 00:12:00,710 --> 00:12:04,270 heißt es, dass man sich sehr früh um das Thema Security 217 00:12:04,280 --> 00:12:06,560 kümmert und Left eben weil n Zeitstrahl ist. 218 00:12:06,570 --> 00:12:10,850 Man kennt ja schon mal diesen, ich wär so gesehen hab ich die 219 00:12:10,860 --> 00:12:14,860 einfach mal unten als Link in die von den Podcast, dass dann 220 00:12:14,870 --> 00:12:17,930 so ein Zeitstrahl der links anfängt, dann halt irgendwann so 221 00:12:17,940 --> 00:12:20,460 ne so, ne Loop macht was dann so n bisschen diese agilen 222 00:12:20,470 --> 00:12:23,660 Iterationen sein soll und da möchte man natürlich möglichst 223 00:12:23,670 --> 00:12:25,280 früh in diesem Zeitstrahl die Verantwortung. 224 00:12:27,140 --> 00:12:30,300 In dem Fall auf die Entwicklerinnen legen und da 225 00:12:30,880 --> 00:12:34,240 nicht quasi erst ganz am Ende, wenn das Produkt fertig gebaut 226 00:12:34,250 --> 00:12:37,450 und gechipt ist, auf solche Security Mobility dies testen, 227 00:12:37,490 --> 00:12:41,360 weil es dann häufig zu spät ist, das noch ohne großen 228 00:12:41,370 --> 00:12:46,390 zeitverzögerungs Aufwand zu fixen, sondern möglichst früh 229 00:12:46,400 --> 00:12:49,620 wie gesagt am besten direkt, wenn ich den Code schreiben, 230 00:12:49,630 --> 00:12:51,690 vielleicht sogar auch im Rahmen von einem automatisierten 231 00:12:51,700 --> 00:12:55,620 Preview direkt zu sagen Ey, da hast du Code geschrieben, den 232 00:12:55,630 --> 00:12:58,320 den du gerade. In Form eines Podcasts 233 00:12:58,330 --> 00:13:01,980 vorschlägst, der potenziell unsicher ist, genau und dadurch 234 00:13:01,990 --> 00:13:06,440 haben wir entsprechende Findings, die im Kontext gegeben 235 00:13:06,450 --> 00:13:08,570 werden, also während du wirklich noch an deinem Feature 236 00:13:08,580 --> 00:13:13,120 arbeitest, die für dich relevant sind und die entsprechend auch 237 00:13:13,130 --> 00:13:16,740 mit den entsprechenden Hinweisen kommen, die dir helfen dieses 238 00:13:16,750 --> 00:13:20,640 Problem dann auch zu adressieren und dementsprechend sehr früh in 239 00:13:20,650 --> 00:13:22,660 der Entwicklung gefixt werden können. 240 00:13:22,890 --> 00:13:26,880 Man sagt generell umso später ein Sicherheitsproblem in dem 241 00:13:26,890 --> 00:13:28,520 Lebenszyklus der Applikation gefunden wird. 242 00:13:28,590 --> 00:13:32,030 Umso teurer wird es am Ende, wenn ich als Developer, das, 243 00:13:32,220 --> 00:13:35,320 während ich an diesem Feature arbeite, schnell fixen kann, ist 244 00:13:35,330 --> 00:13:39,810 es sehr günstig, wenn das Ganze erst nachdem die ganze Software 245 00:13:39,820 --> 00:13:42,590 fertiggestellt ist, gefunden wird, wird schon komplizierter. 246 00:13:42,600 --> 00:13:44,560 Wir müssen halt dann nochmal gezielt bestimmte Dinge 247 00:13:44,570 --> 00:13:47,910 überarbeiten, wenn es nachher erst in Produktion auftaucht, 248 00:13:47,920 --> 00:13:51,550 ist es natürlich das große größtmögliche Desaster, was 249 00:13:51,560 --> 00:13:54,790 natürlich immense Kosten für einen selber und für das 250 00:13:54,800 --> 00:13:58,050 Unternehmen mitbringen kann. Das heißt die statische 251 00:13:58,060 --> 00:14:00,200 Codeanalyse. Befindet sehr früh in der 252 00:14:00,210 --> 00:14:02,780 Entwicklung statt. Natürlich können wir auch auf 253 00:14:02,790 --> 00:14:05,860 unserer gesamten Codebase scannen, aber im Idealfall mache 254 00:14:05,870 --> 00:14:08,420 ich das Ganze möglichst früh schon während der 255 00:14:08,430 --> 00:14:10,450 Entwicklungsphase. Jetzt steht hier noch ein paar 256 00:14:10,460 --> 00:14:13,200 andere Begriffe aus auf dem Zettel, also SAST hab ich 257 00:14:13,210 --> 00:14:14,690 verstanden. Static application security 258 00:14:14,700 --> 00:14:18,010 testing statische Codeanalyse bin ich ganz froh, das habe ich 259 00:14:18,020 --> 00:14:19,240 zumindest schon mal gehört, habe ich schon eingesetzt. 260 00:14:19,250 --> 00:14:24,060 Wahrscheinlich jetzt auch das, was man am ich am schnellsten in 261 00:14:24,070 --> 00:14:25,180 so einem Projekt integriert bekommt. 262 00:14:25,190 --> 00:14:28,270 Man sucht sich irgendein Anbieter aus und setzt auf 263 00:14:28,810 --> 00:14:31,340 konfiguriert und wenn ich das Halt automatisiert in Form 264 00:14:31,350 --> 00:14:34,580 meiner oder meines. Ulrich Reviews anwenden kann, 265 00:14:34,590 --> 00:14:36,100 ist eigentlich immer gleich, was ich. 266 00:14:36,680 --> 00:14:39,440 Das ist immer sehr schnell starten kann, wie gesagt, aus 267 00:14:39,450 --> 00:14:42,580 der Erfahrung beim ersten Mal einsetzen, klar kommen ganz 268 00:14:42,590 --> 00:14:46,070 viele Findings, aber wenn man dann einmal bearbeitet hat, habe 269 00:14:46,080 --> 00:14:48,400 ich glaube ich, ein guter hochqualitativen Code zu 270 00:14:48,410 --> 00:14:50,560 schreiben. Jetzt stehen aber noch andere 271 00:14:50,570 --> 00:14:56,720 Begriffe wie DAST und IST was heißt denn damit auf sich genau 272 00:14:56,730 --> 00:15:01,530 fangen wir mit DAST Dust an. Das ist dynamisches Application 273 00:15:01,540 --> 00:15:05,900 Security Testing. Da nehmen wir eine lauffähige 274 00:15:05,910 --> 00:15:09,780 Applikation und testen diese Applikationen durch 275 00:15:09,790 --> 00:15:12,880 entsprechenden Input. Das heißt, es kann Input sein, 276 00:15:12,890 --> 00:15:17,510 der automatisiert durch das Tool über automatisch generierten 277 00:15:17,830 --> 00:15:19,960 User Input erzeugt wird. Das heißt. 278 00:15:20,080 --> 00:15:22,670 Die Anwendung geht dann durchschaut wo gibts input, 279 00:15:22,680 --> 00:15:25,630 Felder zum Beispiel in einer Web Applikation oder in einer 280 00:15:25,640 --> 00:15:29,810 Desktop Applikation und versucht dann dort durch entsprechende 281 00:15:29,820 --> 00:15:33,590 Eingaben dann Security wollen Abilities zu finden. 282 00:15:33,930 --> 00:15:36,840 Typisches Beispiel sind wieder actions. 283 00:15:37,030 --> 00:15:40,470 Aber das kann natürlich auch bei Web Applikationen über eine 284 00:15:40,480 --> 00:15:45,540 Modifikation der UL sein UL Parameter und gerade für 285 00:15:45,550 --> 00:15:48,220 Webapplikationen sehr praktisch kann ich natürlich auch den 286 00:15:48,230 --> 00:15:51,950 gesamten Network Traffic. Abfangen, mitschneiden und damit 287 00:15:51,960 --> 00:15:56,490 kann dieses Application Security Testing Tool letzten Endes auch 288 00:15:56,500 --> 00:15:59,280 sehen, wie mein Frontend mit der Backend kommuniziert, wie welche 289 00:15:59,290 --> 00:16:02,390 Informationen dort fließen und kann dann versuchen, diese 290 00:16:02,550 --> 00:16:05,280 Informationen zu modifizieren, genauso wie ein potentieller 291 00:16:05,650 --> 00:16:10,200 Angreifer das tun kann und kann natürlich dann jenseits der 292 00:16:10,210 --> 00:16:12,560 Eingaben, die über das User Interface möglich sind, 293 00:16:12,570 --> 00:16:16,810 versuchen, Inputs zu liefern, die zu einer wunderbar bility 294 00:16:16,820 --> 00:16:21,360 oder einer Ausnutzung einer Variability in meiner Backend 295 00:16:21,370 --> 00:16:25,180 Applikationen führen können. Das heißt häufig ist das 296 00:16:25,190 --> 00:16:29,340 Aufsetzen eines solchen Dust Tools so, dass entweder das Tool 297 00:16:30,570 --> 00:16:34,500 Anwendungen. Passt Spider wie in Web 298 00:16:34,510 --> 00:16:36,470 Applikationen? Wir haben das ja häufig bei 299 00:16:36,570 --> 00:16:39,480 irgendwelchen Search Engines, die klettern dann einmal durch 300 00:16:39,490 --> 00:16:41,750 meine Applikation durch folgenden allen Links und 301 00:16:41,760 --> 00:16:44,960 schauen wo gibts input, Felder und dann wird entsprechende 302 00:16:44,970 --> 00:16:47,410 Datenbank aufgebaut, wo diese Eingaben erfolgen können und 303 00:16:47,420 --> 00:16:49,760 dann legt das Tool los und spielt halt. 304 00:16:49,770 --> 00:16:53,850 Eingaben in diese Eingaben Felder und gleichzeitig können 305 00:16:53,860 --> 00:16:57,180 wir einen Proxy zwischen unserer Frontend, unser Backend bei 306 00:16:57,190 --> 00:17:00,120 einer Applikation hängen, um den entsprechenden Traffic 307 00:17:00,130 --> 00:17:03,340 mitzuschneiden, um dann nachher auch auf dieser Netzwerkebene. 308 00:17:03,690 --> 00:17:06,579 Eingaben an das Backend zu schicken und damit versuchen, 309 00:17:06,780 --> 00:17:10,710 potenzielle Sicherheitslücken zu identifizieren, dann natürlich 310 00:17:10,720 --> 00:17:15,430 diese Anwendung als closed Box oder Black Box betrachtet wird 311 00:17:15,440 --> 00:17:18,930 und das Tool keinerlei Wissen über unseren Anwendungscode hat 312 00:17:18,940 --> 00:17:22,119 und auch keinerlei Wissen darüber hat, was letzten Endes 313 00:17:22,130 --> 00:17:25,500 unsere Anwendungen in Sinne der Businesslogik tut, kann es 314 00:17:25,540 --> 00:17:28,410 natürlich dazu führen, dass wir auch hier häufig Positives 315 00:17:28,710 --> 00:17:33,210 bekommen, weil irgendeine Eingabe generiert wird, die dann 316 00:17:33,260 --> 00:17:34,620 zu einem Fehler in meiner Applikation führt. 317 00:17:35,960 --> 00:17:39,440 Und dann werde ich als Developer darauf aufmerksam gemacht, sehe, 318 00:17:39,450 --> 00:17:41,220 dass dort ein Fehlverhalten vorliegt. 319 00:17:41,230 --> 00:17:44,080 Aber ist es wirklich eine Security rabilität also ist es 320 00:17:44,090 --> 00:17:47,180 ein Sicherheitsproblem? Kann ich damit zum Beispiel 321 00:17:47,510 --> 00:17:50,640 Daten aus der Datenbank auslesen oder wenn ich irgendwelche 322 00:17:50,650 --> 00:17:53,780 bösartigen Daten dort eingebe, führt das einfach nur zu einer 323 00:17:54,050 --> 00:17:56,980 Fehlermeldung in der Applikation, was nicht schön 324 00:17:56,990 --> 00:18:01,450 ist, aber nicht kritisch und von daher muss man bei diesen Tools 325 00:18:01,460 --> 00:18:04,060 auch nachher auch noch mal wirklich im Detail durch alles 326 00:18:04,070 --> 00:18:06,530 durchgehen und schauen, welche User Eingaben aber es gibt 327 00:18:06,540 --> 00:18:08,430 einen. Wirklich ein sehr gutes Gefühl, 328 00:18:08,440 --> 00:18:11,820 in welche Bereiche man schauen muss und wo ist potentiell zu 329 00:18:11,830 --> 00:18:15,860 Eingaben kommt und natürlich gegenüber einer manuellen 330 00:18:15,910 --> 00:18:18,200 Testvariante, wo ich genau diese Angriffsvektoren manuell 331 00:18:18,210 --> 00:18:23,140 händisch teste, ist es natürlich absolut automatisiert. 332 00:18:23,430 --> 00:18:27,040 Wir haben extrem große Anzahl von Angriffsvektoren, die dann 333 00:18:27,050 --> 00:18:30,160 automatisiert durchgeführt werden können, und ich bekomme 334 00:18:30,170 --> 00:18:32,520 am Ende einen Test report kann dann genau sehen, an welchen 335 00:18:32,530 --> 00:18:34,070 Bereichen ich nochmal nachschärfen muss. 336 00:18:34,080 --> 00:18:39,260 Nachteil ist hier. Auf der anderen Seite, dass die 337 00:18:39,270 --> 00:18:42,120 Anwendung funktionsfähig lauffähig sein muss und dieses 338 00:18:42,130 --> 00:18:45,010 Testing dementsprechend relativ spät in der 339 00:18:45,020 --> 00:18:45,860 Anwendungsentwicklung stattfindet. 340 00:18:45,870 --> 00:18:49,500 Das heißt, ich muss zumindest meinen, in sich geschlossenen 341 00:18:49,510 --> 00:18:52,970 Service irgendwie lauffähig haben, um so ein Tool darauf 342 00:18:52,980 --> 00:18:55,850 loslassen zu können und ich kann jetzt nicht während der 343 00:18:55,860 --> 00:19:00,060 Entwicklung schon meinen Sourcecode nutzen, um dort zu 344 00:19:00,070 --> 00:19:03,160 einem dynamisches Applications Security Testing zu machen. 345 00:19:03,170 --> 00:19:06,200 Ja gut aber je nachdem, wie dynamisch ich wie agil nicht 346 00:19:06,210 --> 00:19:10,300 dynamisch ich entwickeln. Es ist vielleicht ohnehin mein 347 00:19:10,310 --> 00:19:13,650 Ziel, möglichst früh ein Minimum valuable product irgendwas 348 00:19:13,660 --> 00:19:15,710 kleines Lauffähiges zu haben, sich dann immer wieder 349 00:19:15,720 --> 00:19:19,010 erweitere, daher kann ich natürlich nicht so früh wie 350 00:19:19,020 --> 00:19:21,750 schicke Analyse, aber ja und mein Ziel sollte generell 351 00:19:21,760 --> 00:19:24,530 möglichst früh irgendwas lauffähiges irgendwas kippbare s 352 00:19:24,540 --> 00:19:28,520 zu haben und das dann zu testen. Spannend finde ich aber auch, 353 00:19:28,530 --> 00:19:32,360 dass automatisiert läuft, ne, das heißt, das bedeutet ja auch 354 00:19:32,560 --> 00:19:35,600 ich muss ja fast schon machen, weil natürlich jeder Angreifer 355 00:19:35,610 --> 00:19:37,940 wenn das voll automatisiert ist theoretisch einfach gegen meine 356 00:19:37,950 --> 00:19:39,960 Applikation laufen lassen. Also ich kann mir irgendeine 357 00:19:39,970 --> 00:19:43,000 Webseite draußen jetzt raussuchen Tool nehmen und sagen 358 00:19:43,110 --> 00:19:45,700 OK liebes Tool klick mal auf alle Links geht mein alle 359 00:19:45,710 --> 00:19:48,300 Eingabemasken irgendwie election und überall wo du durchkommst 360 00:19:48,340 --> 00:19:51,600 keine Fehler bekommst sag mal Bescheid, dann weiß ich dann 361 00:19:51,610 --> 00:19:54,480 weiß ich nicht wo die Mobilität von anderen Tools sind ne also 362 00:19:54,490 --> 00:19:57,260 das ist, wenn ich da bin ich wenn Blackbox Test und nichts 363 00:19:57,270 --> 00:20:00,040 über die über die den Code wissen muss. 364 00:20:01,020 --> 00:20:02,980 Dann kann das ja jeder auch gegen meine Anmeldung machen, 365 00:20:02,990 --> 00:20:05,910 das weil ich allein in dem Moment, wo ich mir dessen 366 00:20:05,920 --> 00:20:08,780 bewusst werde führt eigentlich kein Weg vorbei sein, zumindest 367 00:20:08,790 --> 00:20:13,650 mal auszumisten auszuführen. Am besten natürlich auch wieder 368 00:20:13,690 --> 00:20:17,650 ständig. Aber zumindest irgendwie hin und 369 00:20:17,660 --> 00:20:20,900 wieder im großen Release, wenn neue Features dazu kommen oder 370 00:20:20,910 --> 00:20:24,720 was weiß ich genau und solche Tools sind auch relativ einfach 371 00:20:24,730 --> 00:20:28,000 einzusetzen, wenn ich solche webapplikationen schreibe. 372 00:20:28,010 --> 00:20:33,420 Weniger einfach wird es dann, wenn ich Applikationen hab, wo 373 00:20:33,430 --> 00:20:36,810 das Tool nicht automatisch alle user Interfaces passen kann 374 00:20:36,820 --> 00:20:39,740 gucken kann, wo es Nutzereingaben gibt es besonders 375 00:20:39,780 --> 00:20:43,360 herausfordernd natürlich mit mobile Apps, weil ich da mit 376 00:20:43,370 --> 00:20:45,900 Emulatoren arbeiten muss mit physikalischen Endgeräten. 377 00:20:47,710 --> 00:20:50,750 Und genau diese Automatismen dort nicht ganz so einfach 378 00:20:50,760 --> 00:20:54,730 durchführen kann also je nachdem welche Art von Applikationen ich 379 00:20:54,860 --> 00:20:59,270 entwickele, ist es einfacher, so ein dynamisches Analyse Tool 380 00:20:59,280 --> 00:21:02,440 einzusetzen oder schwieriger, aber immer wenn ich im Bereich 381 00:21:02,480 --> 00:21:05,940 Web Applikationen unterwegs bin, sollte ich eigentlich schauen, 382 00:21:05,950 --> 00:21:09,730 dass ich so ein Tool möglichst früh möglichst automatisiert in 383 00:21:09,740 --> 00:21:13,090 meine Softwareentwicklung einbinde haben wir da was wir 384 00:21:13,100 --> 00:21:15,630 nennen können kennst du da irgendwie ein cooles Tool? 385 00:21:15,680 --> 00:21:20,560 Lass mich nicht lügen? Sepp ist eines der bekanntesten, 386 00:21:20,570 --> 00:21:23,260 was auch noch auf unserer Todoliste steht dann packen wir 387 00:21:23,270 --> 00:21:26,060 das auf jeden Fall mal unten in die Shownotes und hoffen, dass 388 00:21:26,070 --> 00:21:27,840 wir wirklich bald eine Podcast Folge nachliefern können. 389 00:21:29,770 --> 00:21:32,560 Aber dann ist da auf jeden Fall was was, was ihr euch schon mal 390 00:21:32,570 --> 00:21:35,770 anschauen könnt, wenn ihr jetzt gesagt was er sagt, ergibt 391 00:21:35,780 --> 00:21:38,970 absolut Sinn, wir müssen sofort auch so Tests einführen, dann 392 00:21:38,980 --> 00:21:42,050 Overs Sepp, befinden wir uns noch in den Show Notes? 393 00:21:42,820 --> 00:21:47,610 Und dann hattest du vorher noch dieses IAST genannt ja, auch 394 00:21:47,620 --> 00:21:49,360 nur, weil du auf die Liste gepackt hast, nicht weil ich 395 00:21:49,370 --> 00:21:52,860 davon irgendwie ahnung hätte genau das ist etwas was ein 396 00:21:52,870 --> 00:21:56,550 bisschen neuer ist, ein bisschen aus dem Bereich zwischen 397 00:21:56,560 --> 00:22:00,050 statischer und dynamischer Code. Analyse Integration Application 398 00:22:00,060 --> 00:22:05,550 Security Testing dafür steht IST dort habe ich mit dem Wissen des 399 00:22:05,560 --> 00:22:09,200 Source Codes die Möglichkeit, meiner Anwendung auszuführen, 400 00:22:09,210 --> 00:22:12,820 das funktioniert am besten mit Sprachen, die eigene Runtime 401 00:22:12,830 --> 00:22:14,880 mitbringen. Dann kann sich das Security 402 00:22:14,890 --> 00:22:18,390 Testing Tool entsprechend in diese Runtime einhängen und dann 403 00:22:18,610 --> 00:22:21,520 mit dem Wissen des Anwendungscodes eine 404 00:22:21,530 --> 00:22:28,970 automatisierte Testsuite laufen lassen, die auf Basis von User 405 00:22:29,250 --> 00:22:31,830 Eingaben oder einem Agent passiert. 406 00:22:31,870 --> 00:22:34,340 Das heißt, ich kann dort bestimmte Dinge automatisieren, 407 00:22:34,350 --> 00:22:40,520 wie es in der dynamischen Analyse möglich ist, aber mit 408 00:22:40,530 --> 00:22:43,050 Wissen des Quellcodes, das heißt, ich habe Tool was letzten 409 00:22:43,060 --> 00:22:46,940 Endes in die Code Execution. Ich reinschauen kann und dann 410 00:22:47,280 --> 00:22:51,660 ein bisschen beide Welten auch miteinander kombinieren kann, da 411 00:22:51,670 --> 00:22:55,020 ist dementsprechend noch ein jüngerer Bereich, der versucht, 412 00:22:55,240 --> 00:22:59,420 die Vorteile der dynamischen Applikationsanalyse mit den 413 00:22:59,460 --> 00:23:03,810 Vorteilen der statischen Code Analyse zu kombinieren, wenn das 414 00:23:03,860 --> 00:23:07,630 interessiert gerne mal auf youtube nach IST suchen. 415 00:23:07,640 --> 00:23:10,290 Dort gibt es einige Videos, die einem einen tieferen Einblick 416 00:23:10,300 --> 00:23:13,050 auch in dieses Thema bieten. Das ist ganz spannend. 417 00:23:13,060 --> 00:23:15,080 Das also ist natürlich nicht genau dasselbe. 418 00:23:15,500 --> 00:23:18,680 Ich n bisschen aus der Container Security und Communities Welt, 419 00:23:19,090 --> 00:23:22,690 wo es auch Tools gibt, die man ins ins eigene Cluster rein 420 00:23:22,700 --> 00:23:25,240 installieren kann, die dann die dort laufenden Container und 421 00:23:25,250 --> 00:23:28,860 Applikationen Monitoren. Ob die sich verdächtig 422 00:23:28,870 --> 00:23:31,460 verhalten, das finde ich gar nicht so n bisschen in diese 423 00:23:31,470 --> 00:23:35,420 Richtung, dass ich sage ich ich beobachte überwache ne 424 00:23:35,430 --> 00:23:38,300 Anwendung. In dem Fall von EST jetzt sogar 425 00:23:38,310 --> 00:23:40,610 mit Kenntnis vom Coder drin läuft. 426 00:23:40,620 --> 00:23:43,380 Das ist bei diesen Container Scanning Tools nicht so, aber 427 00:23:43,390 --> 00:23:46,140 wenn jetzt der Container da monatelang rum. 428 00:23:46,310 --> 00:23:49,250 Und auf einmal anfängt, sich mit der internen Qualitäts API zu 429 00:23:49,260 --> 00:23:53,200 reden oder Irgendsowas. Und das kommt dann kann das 430 00:23:53,210 --> 00:23:55,650 sein, dass du diesen Scannern auch verdächtig vorkommt und 431 00:23:55,660 --> 00:23:58,330 die, die dann auch irgendwie melden, oder auch die dann diese 432 00:23:58,340 --> 00:24:00,780 Container Quarantäne nehmen können und sowas und das finde 433 00:24:00,790 --> 00:24:05,350 ich immer ganz spannend, wenn es so diese Runtime Verständnis 434 00:24:05,360 --> 00:24:07,910 dieser Runtime in dem Fall Klarheit absolvierte, konnte in 435 00:24:08,140 --> 00:24:11,570 dem Fall natürlich Application Runtime, aber dann verständnisse 436 00:24:11,580 --> 00:24:14,000 Tools, die davon Verständnis mitbringen, das überwachen und 437 00:24:14,010 --> 00:24:18,030 darauf so educated Decisions treffen können, dass dann 438 00:24:18,040 --> 00:24:21,200 meistens so die Königsklasse und dieses Verschmelzen von diesen 439 00:24:21,210 --> 00:24:24,410 beiden Welten. Die letzte Kategorie von Tools, 440 00:24:24,420 --> 00:24:28,030 über die wir heute noch sprechen wollen, ist Software Composition 441 00:24:28,040 --> 00:24:32,670 Analysis oder SCA und das sind genau die Tools, die du ganz am 442 00:24:32,680 --> 00:24:34,750 Anfang schon mal kurz angesprochen hattest, nämlich 443 00:24:34,760 --> 00:24:38,450 die Tools, die deine Dependencies untersuchen, auf 444 00:24:38,460 --> 00:24:41,460 Bekannte von Abilities sprich hier gehts nicht mehr um den 445 00:24:41,470 --> 00:24:44,790 Code, den wir beide schreiben, sondern um den Code den andere 446 00:24:44,800 --> 00:24:49,250 geschrieben haben, den andere Paketiert haben, die wir in Form 447 00:24:49,440 --> 00:24:51,760 von Open Source Libraries oder irgendwelchen Packages 448 00:24:51,770 --> 00:24:55,740 verwenden. Und mittlerweile sind natürlich 449 00:24:55,750 --> 00:24:59,080 die meisten Anwendungen auf Basis solcher Open Source 450 00:24:59,090 --> 00:25:04,300 Technologien gebaut je nach Quelle irgendwie zwischen 7080% 451 00:25:04,310 --> 00:25:08,750 des Anwendungscodes ist mittlerweile auf Basis von Open 452 00:25:08,760 --> 00:25:11,380 Source Code entwickelt. Und dann nutze ich natürlich 453 00:25:11,430 --> 00:25:15,580 diverse Package Manager und Libraries, die aus der Community 454 00:25:15,590 --> 00:25:19,760 oder von anderen geschrieben werden und solche SCA Tools 455 00:25:19,770 --> 00:25:23,600 helfen mir dann auf bekannte Wunder Abilities in meinen 456 00:25:23,610 --> 00:25:26,490 Dependencies. Aufmerksam zu werden, das heißt, 457 00:25:26,500 --> 00:25:31,200 das Tool schaut sich an, welche Dependencies ich verwende da je 458 00:25:31,210 --> 00:25:34,600 nach Technologie gibt es meistens dort einen eine Datei, 459 00:25:34,610 --> 00:25:37,710 in der Halt die entsprechenden Dependencies für meine 460 00:25:37,720 --> 00:25:40,880 Anwendungen hinterlegt sind. Diese Datei wird untersucht und 461 00:25:40,890 --> 00:25:45,490 auf Basis einer von Ability Database, wie wir sie zum 462 00:25:45,500 --> 00:25:49,300 Beispiel auf github finden. Kann dann das Tool mich auf 463 00:25:49,310 --> 00:25:52,500 Wunder bitis in den von mir verwendeten Libraries und 464 00:25:52,510 --> 00:25:56,240 Packages in der entsprechenden Version aufmerksam machen kann. 465 00:25:56,510 --> 00:25:58,950 Dann auch direkt Informationen geben, auf welche Version ich 466 00:25:58,960 --> 00:26:01,790 upgraden müsste, wenn es mittlerweile eine Version gibt, 467 00:26:01,840 --> 00:26:06,070 die entsprechend gefixt ist und damit kann ich meine Software 468 00:26:06,080 --> 00:26:10,190 Supply Chain absichern, weil ich nutze natürlich andere Tools und 469 00:26:10,200 --> 00:26:13,030 möchte sichergehen, dass die Tools, die ich verwende oder die 470 00:26:13,040 --> 00:26:16,140 Libres, die ich verwende, zumindest keine bekannten Wunder 471 00:26:16,150 --> 00:26:19,970 Abilities hat und das ist natürlich eine gewisse Schwäche 472 00:26:20,530 --> 00:26:24,030 dieses Ansatzes, dass ich natürlich nicht oder nie 473 00:26:24,040 --> 00:26:27,030 hundertprozentig sicher sein kann, dass diese Dependencies, 474 00:26:27,040 --> 00:26:28,760 die ich verwende, keine Wohnung abilities. 475 00:26:28,830 --> 00:26:31,740 Haben aber ich kann zumindest sichergehen, dass ich keine 476 00:26:31,900 --> 00:26:34,510 Dependencies verwendet. Die Bekannte wurden Abilities 477 00:26:34,520 --> 00:26:37,550 haben und damit habe ich aber glaube ich schon mal einen 478 00:26:37,560 --> 00:26:41,700 großen Sicherheitsgewinn in der Verwendung solcher Libraries und 479 00:26:41,800 --> 00:26:44,210 diese Sachen sind mittlerweile sehr einfach einzusetzen. 480 00:26:44,220 --> 00:26:46,110 Da gibt es diverse Tools am Markt. 481 00:26:46,120 --> 00:26:50,030 Das bekannteste Glaube ich ist auf github die Pandaboard, aber 482 00:26:50,040 --> 00:26:54,200 die funktioniert auch mit anderen Plattformen jenseits von 483 00:26:54,240 --> 00:26:57,570 github, nutzt aber immer die entsprechende Woite Database auf 484 00:26:57,580 --> 00:27:01,640 github. Und kann dort von mir als 485 00:27:01,650 --> 00:27:04,530 Developer eingesetzt werden, auch lokal auf meiner Maschine, 486 00:27:04,950 --> 00:27:08,770 um Halt zu schauen sind die Dependencies, die ich verwende. 487 00:27:08,870 --> 00:27:11,510 Frei von Bekannten wollen Abilities. 488 00:27:11,550 --> 00:27:13,480 Ich kann vielleicht davon ausgehen, dass alle Party 489 00:27:13,490 --> 00:27:17,040 dependency ich dich benutze generell frei von Variability 490 00:27:17,050 --> 00:27:19,840 sind von bekannten ja, aber das kann ich ja bei meinem eigenen 491 00:27:19,850 --> 00:27:22,220 Code auch nicht, wenn ich da keine Analysen fahren, selbst 492 00:27:22,230 --> 00:27:24,900 wenn ich statische Code Analyse mache, kann ich auch nicht 493 00:27:24,910 --> 00:27:28,320 hundert Prozent sicher sein, dass da diesen Tools nichts 494 00:27:28,330 --> 00:27:30,980 durchgerutscht ist finde ich das ein vertretbares Risiko. 495 00:27:31,540 --> 00:27:36,030 Auch nochmal Probst, auf jeden Fall an Independent Board nutzen 496 00:27:36,040 --> 00:27:40,770 auch und der stellt mir sogar Pull Requests automatisch, wo er 497 00:27:40,780 --> 00:27:42,670 dann diese Versionsnummer hoch zählt. 498 00:27:42,680 --> 00:27:46,160 Das heißt, das ist wirklich also da wirklich niemand mehr eine 499 00:27:46,170 --> 00:27:48,390 Ausrede auf einer veralteten Version zu sein? 500 00:27:48,400 --> 00:27:51,880 Dann ist es meine Ausrede, dass ich keine anständigen Tests habe 501 00:27:51,890 --> 00:27:55,470 und die sollte mir unangenehm sein diese Ausrede denn wenn ich 502 00:27:55,480 --> 00:27:57,610 gute testabdeckung habe, dann kann ich ja diesen 503 00:27:57,620 --> 00:28:00,280 automatisierten Request Depended, stellt mit der neuen 504 00:28:00,290 --> 00:28:03,510 Version Nummer einfach. Einmal durchtesten, wenn es nach 505 00:28:03,520 --> 00:28:05,280 wie vor Grün sind, kann ich ja mehr oder weniger automatisiert 506 00:28:05,290 --> 00:28:10,540 fast schon rein Märchen also das Problem sehe ich eigentlich als 507 00:28:10,550 --> 00:28:12,810 gelöst an mit so Tools wie die Pendler bot. 508 00:28:13,960 --> 00:28:18,290 Man muss dann halt nutzen. Eine gewisse Schwäche hat man 509 00:28:18,300 --> 00:28:21,570 natürlich mit solchen Tools, weil mir diese Tools natürlich 510 00:28:21,580 --> 00:28:26,030 nicht natürlich nicht sagen, ob ich die verwundbaren 511 00:28:26,480 --> 00:28:31,170 Methodenaufrufe oder Komponenten einer Library auch wirklich 512 00:28:31,180 --> 00:28:33,230 verwende. Ich glaube, ein gutes Beispiel 513 00:28:33,240 --> 00:28:38,210 ist log for J was wir auch schon diskutiert haben, dass natürlich 514 00:28:38,460 --> 00:28:41,410 eine große Sicherheitslücke darstellen konnte. 515 00:28:41,420 --> 00:28:44,930 Aber je nachdem wie ich diese Library eingesetzt habe. 516 00:28:45,850 --> 00:28:48,760 Könnte es auch sein, dass meine Anwendung trotzdem weiterhin 517 00:28:48,770 --> 00:28:51,040 sicher ist? Natürlich fahre ich sicher, wenn 518 00:28:51,050 --> 00:28:53,980 ein Upgrade gibt, was für mich nicht ein Breaking Change 519 00:28:53,990 --> 00:28:57,030 bedeutet, wenn ich dann trotzdem diese Bibliothek auf die neueste 520 00:28:57,040 --> 00:29:00,300 Version bringe, auch wenn ich diese potenziell verwundbare 521 00:29:00,310 --> 00:29:03,750 Funktion nicht verwende, aber nur weil ich jetzt eine 522 00:29:03,760 --> 00:29:07,650 Vulnerability zum Beispiel durch die Board in meine Dependencies 523 00:29:07,850 --> 00:29:10,120 angezeigt bekomme heißt es nicht, dass sofort meine 524 00:29:10,130 --> 00:29:12,860 Anwendung unsicher ist, sondern ich muss vielleicht auch noch 525 00:29:12,870 --> 00:29:15,400 mal in die Details gucken. In die Dokumentation in. 526 00:29:15,820 --> 00:29:19,850 Der entsprechenden Datenbank, ob letzten Endes die Dinge, die 527 00:29:19,860 --> 00:29:22,620 dort gefunden wurden, in dieser Bibliothek auch wirklich Dinge 528 00:29:22,630 --> 00:29:25,690 sind, die ich verwende, um dann zu wissen, ob durch diese 529 00:29:25,700 --> 00:29:29,170 Dependency auch wirklich meine Anwendung potentiell verwundbar 530 00:29:29,180 --> 00:29:32,810 ist, aber wie du gesagt hast meistens ist der Aufwand die 531 00:29:32,820 --> 00:29:36,190 neueste Version, die dort einen fix mitbringt, einfach mal zu 532 00:29:36,200 --> 00:29:39,160 testen, nicht allzu groß. Von daher gibt es kaum Ausreden, 533 00:29:39,170 --> 00:29:42,930 dass zumindest automatisiert mitlaufen zu lassen und dann 534 00:29:42,940 --> 00:29:45,840 möglichst schnell auf die neueste Version zu gehen, auch 535 00:29:45,850 --> 00:29:48,940 wenn man vielleicht diese. Verwundbarkeit in der eigenen 536 00:29:48,950 --> 00:29:50,610 Anwendung gar nicht ausnutzen könnt. 537 00:29:51,250 --> 00:29:54,720 Ja, spannend also Security immer n, bisschen so leidiges Thema, 538 00:29:54,730 --> 00:29:57,620 aber man merkt schon auch irgendwie innerhalb der letzten 539 00:29:57,630 --> 00:30:00,480 Jahre, wenn sich so ein bisschen die die Tech News anschaut, dass 540 00:30:00,490 --> 00:30:03,820 ein immer wichtigeres Thema wird und dann ist doch cool, wenn s 541 00:30:03,830 --> 00:30:06,760 Tools gibt, die uns so ein bisschen die Arbeit abnehmen und 542 00:30:06,770 --> 00:30:09,840 das ist für uns ein bisschen leichter machen also ich fand 543 00:30:09,850 --> 00:30:13,820 das so immer cool, dass mir soeben nicht nur wie gesagt hat 544 00:30:13,830 --> 00:30:16,800 meine Schwächen, sondern auch n bisschen Smells und Technical 545 00:30:16,810 --> 00:30:20,540 debt und sowas aufgezeichnet oder so zu Gamification. 546 00:30:20,550 --> 00:30:22,680 Mäßiger Sicht Lust hatte diesen Score. 547 00:30:22,960 --> 00:30:25,490 Nach oben zu treiben, und ich glaube, das wird super. 548 00:30:25,500 --> 00:30:30,550 Es wird immer wichtiger, gerade weil Angriffe auf Software nicht 549 00:30:30,560 --> 00:30:32,720 weniger spannend oder interessant werden oder 550 00:30:32,730 --> 00:30:34,750 attraktiv werden für potentielle Angreifer. 551 00:30:35,400 --> 00:30:38,250 Und ich habe auf jeden Fall gelernt, wir haben.ca gehabt. 552 00:30:38,260 --> 00:30:41,830 Software Composition Analysis haben wir gerade darüber 553 00:30:41,840 --> 00:30:45,390 gesprochen ich n bisschen was meine Supply Chain woher kommen 554 00:30:45,400 --> 00:30:48,810 denn eigentlich meine ganzen Dependencies und sind diese 555 00:30:48,820 --> 00:30:52,240 verwundbar? Dann SAST static application 556 00:30:52,250 --> 00:30:54,760 security testing. Statische Code Analyse der 557 00:30:54,770 --> 00:30:57,510 Quellcode, den ich geschrieben habe, wird automatisiert 558 00:30:57,520 --> 00:31:01,080 gescannt auf irgendwelche Anti patterns, dann das ganze als 559 00:31:01,090 --> 00:31:03,440 dynamische Codeanalyse fand ich sehr spannend hattest du 560 00:31:03,450 --> 00:31:04,050 erzählt? Es gibt Tools. 561 00:31:04,060 --> 00:31:06,530 Die automatische Anwendung durchgehen, schauen, ob 562 00:31:06,540 --> 00:31:09,530 irgendwelche die auf Button klicken, gucken, ob irgendwelche 563 00:31:09,540 --> 00:31:12,000 Eingaben Felder gibt, wo sie vielleicht auch Attacken 564 00:31:12,010 --> 00:31:15,010 hinschicken können. Während meiner wäre eine 565 00:31:15,020 --> 00:31:17,860 Anwendung läuft und dann die Vermischung beider Welten n 566 00:31:17,870 --> 00:31:22,000 bisschen mit IRST oder IAST Integration Application Security 567 00:31:22,010 --> 00:31:24,170 Testing. Oder wirklich auch mit der 568 00:31:24,180 --> 00:31:27,310 Verständnis von der Runtime und Verständnis von meinem Code zur 569 00:31:27,320 --> 00:31:30,150 Laufzeit überprüft wird, ob meine Anwendungen verwundbar 570 00:31:30,160 --> 00:31:33,460 sind. Also auf jeden Fall was also ich 571 00:31:33,470 --> 00:31:38,010 glaub ne Gute infolge auch mal ein bisschen nachschlagen kann. 572 00:31:38,400 --> 00:31:40,840 Wir versuchen auch relativ viel von dem Content nochmal unten in 573 00:31:40,850 --> 00:31:44,480 die in die Shows zu packen. Ich habe auf jeden Fall n 574 00:31:44,490 --> 00:31:49,310 Hausaufgaben mitgenommen für meine Projekte, diese zumindest 575 00:31:49,320 --> 00:31:51,400 mal zu untersuchen, ob wir nicht das eine oder andere noch in 576 00:31:51,410 --> 00:31:54,970 unsere automatisierte Pipeline mit aufnehmen sollten und da 577 00:31:54,980 --> 00:31:58,350 gibt es mittlerweile extrem viele Tools am Markt und du hast 578 00:31:58,360 --> 00:32:00,910 gerade schon einen Hersteller genannt Sona. 579 00:32:00,920 --> 00:32:04,570 Da gibt es auch noch andere mit. Check Marks mit sneak mit 580 00:32:04,850 --> 00:32:08,820 Advanced Security das heißt, der Markt wächst immer weiter, und 581 00:32:08,890 --> 00:32:11,240 wir merken auch einfach in unserem Alltag, dass das Thema 582 00:32:11,250 --> 00:32:13,780 absolut heiß ist, dass immer mehr unternehmen sich wirklich 583 00:32:13,790 --> 00:32:18,140 dort weiterentwickeln wollen, weil natürlich die Angriffe 584 00:32:18,150 --> 00:32:20,900 immer mehr zunehmen. Hackerangriffe werden immer 585 00:32:20,910 --> 00:32:23,120 häufiger, und da möchte ich natürlich meine Anwendung 586 00:32:23,170 --> 00:32:26,940 bestmöglich absichern, von daher schaut euch auf jeden Fall die 587 00:32:26,950 --> 00:32:29,960 verschiedenen Bereiche an und schaut euch an, welches Tool am 588 00:32:29,970 --> 00:32:34,860 besten in euren Dev ops. Protest reinpasst mittlerweile 589 00:32:34,870 --> 00:32:38,140 spricht man ja eigentlich fast kaum noch über DVB, sondern über 590 00:32:38,150 --> 00:32:42,700 d sec OPS also wie kriegt ihr den Security Teil in eure 591 00:32:42,710 --> 00:32:46,380 Anwendungsentwicklung rein, möglichst automatisiert und 592 00:32:46,390 --> 00:32:48,520 schaut euch da mal die verschiedenen Tools an, auf 593 00:32:48,530 --> 00:32:52,130 jeden Fall extrem heißes Thema im Moment und wir packen da auch 594 00:32:52,140 --> 00:32:54,840 die entsprechenden Informationen nochmal in die Shownotes rein 595 00:32:54,850 --> 00:32:57,980 werde ich auf jeden Fall mit meinem Team bei meinen Kaffee 596 00:32:57,990 --> 00:33:02,200 mal besprechen. Apropos Kaffee wenn ihr Lust 597 00:33:02,210 --> 00:33:03,880 habt, uns einen Kaffee zu spendieren. 598 00:33:04,450 --> 00:33:07,260 Sagte er. Das war ne coole Folge, ich hab 599 00:33:07,270 --> 00:33:09,890 was gelernt. Ich gebe den beiden Jungs meinen 600 00:33:09,900 --> 00:33:13,370 Kaffee aus, dann freuen wir uns aber sehr drüber könnt ihr 601 00:33:13,380 --> 00:33:16,320 machen über den Link unten in den Shownotes, da haben wir so n 602 00:33:16,330 --> 00:33:22,220 bei mir coffee Link. Wenn ihr da n Flat White da 603 00:33:22,230 --> 00:33:24,880 lassen wollt, dann freuen wir uns da sehr drüber. 604 00:33:25,490 --> 00:33:28,300 Außerdem freuen wir uns über Bewertungen und Sternchen auf 605 00:33:28,310 --> 00:33:31,620 den gängigen Podcast. Plattformen wie Apple Podcasts 606 00:33:31,630 --> 00:33:34,620 oder Spotify. Wer dieser Podcast also gefallen 607 00:33:34,630 --> 00:33:38,900 hat, dann hört gerne ab und zu mal rein alle 2 Wochen erscheint 608 00:33:38,990 --> 00:33:41,550 eine neue Folge und wir freuen uns natürlich immer, wenn ihr 609 00:33:41,560 --> 00:33:44,220 auch irgendwo Feedback hinterlasst sowie auch wenn ihr 610 00:33:44,230 --> 00:33:46,730 uns privat Feedback hinterlassen wollt ihr das ist ein bisschen 611 00:33:46,740 --> 00:33:48,940 länger, ist allgemeines Feedback zur Folge? 612 00:33:49,450 --> 00:33:53,760 Das passt vielleicht irgendwie ne n Kommentar auf itunes, dann 613 00:33:53,770 --> 00:33:56,700 findet ihr auch immer eine Email, wo wir uns gerne auch ne 614 00:33:56,710 --> 00:33:58,710 Mail hinschicken könnt. Auch für Themenvorschläge oder 615 00:33:58,720 --> 00:34:02,130 allgemeine Diskussionen mit uns. Auch da freuen wir uns immer 616 00:34:02,140 --> 00:34:06,120 sehr, von daher würde ich sagen wir hören uns in 2 Wochen wieder 617 00:34:06,640 --> 00:34:10,330 alles gute und schreibt viel Code bis bald ciao.