Everything-as-Code – Anything Secure?
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 94 | |
| Author | ||
| License | CC Attribution 4.0 International: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/45606 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
FrOSCon 201971 / 94
7
10
12
14
15
16
17
20
22
23
26
27
28
29
30
31
32
33
36
37
38
39
41
44
45
48
52
53
55
56
57
58
60
61
62
64
66
67
74
76
77
78
79
81
83
84
93
00:00
CodeSoftware developerWEBCodeComputer programmingXMLComputer animationLecture/Conference
02:58
Windows XPSpeciesFocus (optics)IMPACT <Programmierumgebung>
05:13
Focus (optics)TelecommunicationFocus (optics)Enterprise architectureInterface (computing)Atomic nucleusContext awarenessCASTComputer animation
06:49
InformationPRINCE2CISSPDerived set (mathematics)Information securitySoftwareComputer animation
07:55
Computer animation
08:47
CodeHTTPContinuous integrationSoftwareRoute of administrationComputer animation
09:29
Continuous integrationCodeAutomationFunctional (mathematics)Military operationContinuous integrationIterationFactorizationComputer animation
11:37
Source codeHöheInstanz <Informatik>Functional (mathematics)SoftwareCodeNormal (geometry)RückkanalLoop (music)Diagram
13:47
MultiplicationMultiplicationFunction (mathematics)Firewall (computing)Physical quantityService (economics)Mobile appOperating systemMainframe computerConfiguration spaceDatabaseKommunikationComputer animation
15:30
MultiplicationPoint cloudSoftwareComputer hardwareAbsolute valueMainframe computerInstanz <Informatik>Point cloudSource codeSoftware testingSoftware repositoryRollback (data management)Configuration spaceWritingComputer animation
17:12
Instanz <Informatik>Direction (geometry)Source codeRoute of administration
18:07
Non-standard analysisInternetVulnerability (computing)WINDOWS <Programm>EmoticonZahlInternetVulnerability (computing)Patch (Unix)MicrosoftSystems <München>Non-standard analysisHacker (term)Computer animation
19:36
WebsiteXMLAMOS <Software>ACCESS <Programm>Component-based software engineeringSQLAuthenticationCodeWeb applicationComputer programmingScripting languageCross-site scriptingDirection (geometry)Software developerComputer animation
22:20
Archaeological field surveyHidden surface determinationCodeTerm (mathematics)Context awarenessComputer animation
23:48
Computer animation
24:38
CodeKooperatives InformationssystemSource codeAPPELL <Programm>BenchmarkSoftware developerControl flowCodeComputer animation
26:16
Process (computing)Stylus (computing)Software developerENABLE <Programm>Computer animation
28:40
Customer relationship managementCodeOptical character recognitionLucidSet (mathematics)Similarity (geometry)Computer animationDiagram
29:35
Sun <Marke>Military operationPasswordDrop (liquid)CodeComputer animation
30:51
Mobile appPoint cloudPriorityPoint cloudWeightInternet service providerPhysical quantityConfiguration spaceRoute of administrationCodeComputer animation
33:28
APPELL <Programm>Computer animation
34:46
EmailWorld Wide WebComa BerenicesSoftware developerXML
35:41
EmailWorld Wide WebComa BerenicesLAMP <Programmpaket>XML
36:24
Adaptive behaviorSoftware developerSet (mathematics)Liste <Informatik>Dynamic rangeComputer animation
43:18
ChecklistWorld Wide WebUMLComputer wormChemical polaritySource codeReverse engineeringDirection (geometry)CompilerSoftwareComputing platformSoftware repositoryPoint cloudConfiguration spaceComputer animation
47:33
EmailopenSUSEXMLComputer animation
Transcript: German(auto-generated)
00:07
Ja, schönen guten Morgen zusammen. Mein Name ist Jan Sudmeier. Ich bin Security-Berater, bin seit ungefähr zehn Jahren im Bereich Datenschutz, Datensicherheit, die letzten Jahre so ein bisschen schwerpunktmäßig eher im Bereich technische und IT-Security unterwegs
00:23
und ich würde euch heute gern was zum Thema Everything as Code, Anything Secure, erzählen. Die Agenda, zum einen vielleicht kurz eine Vorstellung von unserem Unternehmen, dass ihr so ein bisschen einordnen könnt, was wir machen, mit welchen Themen wir uns beschäftigen, welchen Themenbezug wir auch zum Vortragsthema heute haben. Dann geht es ein bisschen um die Evolution der Entwicklungskonzepte in den letzten Jahren,
00:45
was sich an der Stelle getan hat. Ich denke mal, klasse, das Wasserfallmodell für Softwareentwicklung ist nicht mehr Stand der Dinge, das wisst ihr besser als ich, aber auch da hält die Entwicklung nicht an. Hier steht das DevOps in der Agenda, aber natürlich ist auch das nicht das Ende der Evolution, sondern wir reden bei uns auch über DevSecOps, über BisDevSecOps,
01:02
was dann letztendlich so die nächsten Schritte der Weiterentwicklung von Entwicklungsmethoden sind. Natürlich ändert sich auch die Techniklandschaft in Hinblick auf Infrastruktur und Technologien. Da haben wir in den letzten Jahren deutliche Paradigmenwechsel gesehen, teilweise auch das bedingt durch die geänderten Entwicklungsmethoden,
01:22
dass wir heute agil entwickeln, über DevOps reden, bedingt natürlich, dass meine Infrastruktur dieses Tempo mitgeht und da auch entsprechend flexibel ist. Daraus leitet sich so ein bisschen die Frage ab, wenn wir jetzt in den letzten Jahren so viele Paradigmenwechsel erlebt haben und sich die Welt verändert, wie sicher sind wir denn heute noch? Weil auch das Thema Security wird immer komplexer,
01:43
es wandert immer mehr Verantwortung zu Entwicklern, die mittlerweile halt Code für Infrastruktur schreiben und definieren. Die Frage ist, sind wir da auf dem richtigen Weg und wie hat sich die Situation aus der Security-Brille, also so ein bisschen aus meiner Sicht in den letzten Jahren verändert. Natürlich ist auch Security davon betroffen,
02:01
also wir wollen nicht da die ganze Verantwortung Entwicklern oder Betriebsverantwortlichen zuschieben, sondern auch die Security-Branche muss sich natürlich diesen geänderten Rahmenbedingungen anpassen und sowohl tooltechnisch als auch prozessual darauf reagieren. Dann vielleicht so ein kurzer Ausblick, was gibt es denn eigentlich schon an Tools, weil auch da muss man natürlich nicht das Rad neu erfinden.
02:21
Es gibt für viele Dinge eine technische Lösung. Aber inwieweit löst das überhaupt die Probleme, die wir haben als Security-Verantwortliche oder als Entwickler oder Betriebsverantwortliche. Dann noch ein kurzer Ausblick, wie wir das Ganze bei uns in der Praxis wahrnehmen. Wir sind ein Beratungsunternehmen. Das heißt, wir gucken uns die IT-Landschaft von vielen Unternehmen an.
02:42
Und auch da gibt es dann Abweichungen von dem, was vielleicht hier in so einer Forschungseinrichtung Stand der Dinge ist und das, was wir tatsächlich draußen im Alltag sehen. Und dann zum Schluss noch mal ein kurzes Wrap-Up. Was fehlt eigentlich noch, damit wir insgesamt tatsächlich sicherer werden in diesen Zeiten des Wandels.
03:00
Dieses Zitat von John T. Tambers nutzen wir ganz gern zum Einstieg bei uns, weil es eigentlich ganz gut die Realität widerspiegelt, die wir auch bei uns täglich in unseren Projekten sehen. Es gibt nämlich mittlerweile tatsächlich nur noch genau zwei Arten von Unternehmen, diejenigen, die schon gehackt wurden und diejenigen, die es noch nicht wissen. Entweder weil schon jemand in ihrem System drin ist und sie kriegen es nicht mit oder weil sie vielleicht irgendwo
03:20
schon auf der Liste potenziellen Zielliste stehen von Angreifern. Im einfachsten Fall ist das vielleicht ein Script-Kiddy, der nur rumprobiert und dann per Zufall mal eine Infrastruktur zerschießt. Aber auch da ist die die Branche der Cyberkriminellen mittlerweile schon drei Schritte weiter. Ich denke, so der Fall vom Lukas Krankenhaus Neuss aus 2016
03:42
dürfte den meisten bekannt sein, der ist durch die Medien gegangen. Die haben sich in Verschlusstheorahne eingefangen. Ist jetzt nur eins der prominenten Beispiele. Da ist zum Glück gar nicht so viel finanzieller Schaden entstanden. Aber nichtsdestotrotz, wenn ich meinen Krankenhausbetrieb von einem auf den anderen Tag stilllegen muss, weil alle meine OP-Rechner verschlüsselt sind, die vielleicht noch auf Windows XP laufen
04:02
und ich meine Patienten auf der Intensivstation nicht mehr versünftig versorgen kann, weil die Krankenakte nicht mehr zur Verfügung steht, dann ist das halt schon ein sehr ernsthafter Impact. Das ist dann vielleicht noch so ein Fall, wo man sagen kann, ok zumindest weiß ich, dass mich jemand gehackt hat, was mittlerweile aber auch bei diesen Verschlusstheorianern passiert,
04:21
gerade wenn es da um kriminelle Aktivitäten geht, also wo dann wirklich organisierte Kriminalität dahinter steckt. Die gehen nicht mehr hin, schieben mir den Verschlusstheorianer unter und verschlüsseln meinen Mail-Server, sondern die gehen erst mal in mein System, nisten sich da ein, nisten sich auch in den Backups ein und ein halbes Jahr später schlägt der Trojaner zu und auf einmal sind auch meine Backups wertlos,
04:42
weil auch die sind verschlüsselt. Und das ist dann genau dieser zweite Fall der Companies, die vielleicht schon gehackt wurden und einfach gar nicht mitbekommen, dass sie da ja schon längst unterlaufen wurden. Das Ganze setzt sich ja natürlich fort. Wirtschaftsspionage, also auch da ist gerade der deutsche Mittelstand, der dabei ist, sich zu digitalisieren,
05:01
ganz stark im Fokus von Angreifern, die Know-how abziehen, die Konkurrenten ausschalten oder schaden wollen. Und das ist genau unser Anspruch als Carmer's Hack, die den Mittelstandskunden da an der Stelle zu unterstützen, wie sie besser werden können. Wir sind ein relativ junges Unternehmen, letztes Jahr gegründet, ein Stück weit aus der Motivation heraus,
05:22
uns nur um das Thema Security zu kümmern. Der Carsten Marmuller ist mein zweiter Geschäftspartner, der vorne sitzt. Wir sind schon seit einigen Jahren zusammen als Team unterwegs im Bereich Cybersecurity Beratung, haben uns jetzt entschieden, nochmal neu zu gründen, mit reinem Fokus wirklich auf das Thema Security und alles andere auch außen vor lassen,
05:40
weil selbst dieses Thema ist mittlerweile so komplex, dass es da wirklich Spezialisten und spezialisierte Ansätze braucht. Unsere drei Geschäftsbereiche, auf die wir uns fokussieren, sind Advisory, Consulting und Research. So ein bisschen zur Abgrenzung. Advisory ist tatsächlich klassische IT-Security-Strategie-Beratung. So ein bisschen mehr auf Management-Ebene im Mittelstand.
06:02
Consulting, da wird es dann schon technischer. Das heißt, da entwickeln wir konkrete technische Konzepte für Kunden, wie sie ihre Unternehmensarchitektur aufsetzen sollten, wie sie DevSecOps zum Beispiel sauber implementieren sollten. Und im Bereich Research, das ist dann die Schnittstelle auch zu so einer Veranstaltung wie heute, wo wir uns mit neuen Technologien ansetzen,
06:23
auseinandersetzen, um auch das dann nachher in unsere Praxis einfließen zu lassen. Genau, was uns antreibt, wir brennen für das Thema Security. Das ist das, was den Kern unseres Unternehmens bildet. Und wir wollen das Thema Security in die Breite tragen. Wir wollen Awareness dafür schaffen. Wir wollen vor allen Dingen das Entwickler
06:42
auch Spaß an dem Thema bekommen, weil das ist einfach unausweichlich und wollen möglichst viele Leute dafür gewinnen. Genau, ja, schwerpunktmäßig, wie gesagt, sind wir sowohl technisch als auch auf dieser konzeptionellen Management-Beratungsebene unterwegs, haben über 30 Jahre
07:02
Beratungserfahrung in dem Umfeld. Und dieses Know-how wollen wir jetzt gerne weitergeben, auch an junge Kollegen, die Interesse haben, sich in dem Bereich zu betätigen. Genau, ja, Portfolio vielleicht, ohne jetzt im Detail drauf einzugehen. Hier die mittlere Zeile dürfte wahrscheinlich der spannendste Teil sein. Das ist wahrscheinlich das, was die meisten von euch so als Berührungspunkt haben,
07:24
was bei uns dann, wie gesagt, auch in dieser sparte Research läuft. Wir beschäftigen uns damit, wie sich Security-Lösungen automatisieren lassen, wie man das ganze Thema Security agil gestalten kann und mit dem Thema DevSecOps, weil wir gleich sehen werden, sind das halt wirklich Welten, die aufeinanderprallen,
07:41
wo die Entwickler einfach schon drei Schritte weiter sind und Security oft mit den eigenen Konzepten noch ein Stück weit hinterherhängt. Aber das muss integriert werden, damit am Ende halt eine runde, schlüssige Story draus wird. Unsere Mission Security Done Right. Das bedeutet für uns, dass wir das Thema Security ganzheitlich Ende zu Ende angehen,
08:05
dass wir es richtig angehen. Ich habe es eben schon erwähnt, die Security-Welt ist mittlerweile unglaublich komplex. Wir werden gleich noch sehen, wie viele Tools es in dem Bereich gibt. Und auch das ist nur ein kleiner Ausschnitt. Und wenn man das richtig machen will, muss man halt eine sinnvolle Auswahl treffen
08:20
und diese Tools auch miteinander integrieren. Und das ist im Grunde unser Anspruch, den wir, wie gesagt, dem Mittelstand insbesondere näherbringen wollen, weil da sehen wir gerade einfach Riesenlücken. Also Großkonzerne sind häufig ein bisschen besser ausgestellt, die haben Kapazitäten, die haben Know-how. Aber gerade kleinere Unternehmen kämpfen sehr stark damit, diesen Anforderungen, die man in der modernen Welt
08:42
im Hinblick auf Security braucht, einfach gerecht zu werden. Everything is code and code is law. Das ist so ein bisschen der Leitsatz dieses Vortrags auch. Wenn wir uns mal angucken, was sich in den letzten Jahren eigentlich getan hat im Hinblick auf Entwicklungskonzepte.
09:01
Ich glaube, Agile Development brauchen wir nicht darüber reden. Vielleicht sogar einen Schritt davor noch. Klassisch Wasserfall-Modell, also dass ich meine Software plane, dann vielleicht über mehrere Jahre entwickle, teste und irgendwann release. Funktioniert heute einfach nicht mehr. Damit arbeite ich an den Anforderungen meiner Kunden vorbei, weil im schlimmsten Fall stelle ich fest nach drei Jahren,
09:22
dass ich von falschen Prämissen ausgegangen bin, dass mein Produkt gar nicht den Bedarf der Anwender erfüllt oder dass es schlichtweg veraltet ist. Deswegen nächste Stufe war dann Agile Development, also dass ich halt in kürzeren Iterationen entwickle, dass ich Sprints habe, wo ich dann immer neue Features dranschraube,
09:41
aber auch nach jedem Sprint einen MVP habe, der funktioniert und eben nicht mehr über mehrere Jahre ein Produkt entwickle. Mit Continuous Integration kommt dann so ein bisschen der Faktor Automatisierung ins Spiel, der sich dann auch bei Continuous Delivery und Continuous Deployment letztendlich fortsetzt. Also diese drei Konzepte unterscheiden sich aus theoretischer Sicht
10:03
hauptsächlich dadurch, dass ich eine immer stärkere Automatisierung habe. Continuous Deployment ist was, was wir in der Praxis noch nicht so sehen. Ich glaube, da gibt es einige amerikanische Unternehmen, die da deutlich weiter sind, auch deutlich mutiger sind, weil wenn ich jetzt tatsächlich meinen Code automatisiert,
10:22
vielleicht sogar ein bisschen mein Proz-System schiebe und nicht nur ein Testsystem, dann muss ich mich natürlich darauf verlassen, dass der Code sauber ist und die Applikation funktioniert, und zwar sowohl in Funktionaler als auch in nicht Funktionaler, sprich Security-Hinsicht. Also insofern ist es vielleicht gar nicht so schlecht, dass Continuous Deployment jetzt noch nicht in der breiten Masse angekommen ist,
10:41
weil ich glaube, dass die meisten Unternehmen zumindest, wie wir es wahrnehmen, noch gar nicht darauf vorbereitet sind. Nichtsdestotrotz, es gibt einen aktuellen Report von GitLab, da kommen auch gleich noch ein paar Ausschnitte zu. Die haben festgestellt, dass trotzdem schon, ich glaube, 54 Prozent der Unternehmen tatsächlich irgendwo in ihrer Organisation Continuous Deployments einsetzen.
11:02
Ich gehe davon aus, dass das eher Deployments auf Testsysteme sind, weil, wie gesagt, Prot traue ich den meisten Kunden ganz einfach nicht zu. Aber Unternehmen wie Netflix machen es vor. Die haben da keinen Schmerz mit, weil sie wissen, dass ihre CI-CD-Pipeline so sauber ist und ihr Code so sauber ist, dass die tatsächlich in Production deployen.
11:24
Der nächste Schritt ist dann das Thema DevOps. Und das ist eigentlich noch mal so ein kleiner Paradigmenwechsel zu dem, was wir vorher gesehen haben, weil bei DevOps kommt dann, betrifft es nicht mehr nur die Entwickler, jetzt kommt Operations ins Spiel. Das wird dann ganz gern dargestellt als so ein Infinity Loop,
11:41
weil es letztendlich auch ein geschlossener Prozess ist, wo ich eben die Entwicklerseite und die Betriebsseite miteinander vereine. Das Ganze dann idealerweise auch in interdisziplinären Teams. Das heißt, ich habe meinen Betriebsverantwortlichen auch schon im Entwicklungsprozess mit dabei. Ja, und letztendlich durchlaufe ich diese Schleife immer wieder.
12:01
Wenn ich es gut mache, ist auch das zu einem hohen Teil automatisiert, und zwar nicht nur auf der Dev-Seite, dass ich da meine CI-CD-Pipeline automatisiert habe, sondern auch im Betrieb zum Beispiel das Monitoring oder die Generierung von Infrastruktur, also sprich neue Instanzen in meiner Cloud-Umgebung, zum Beispiel automatisiert habe.
12:23
Was an der Stelle dann noch fehlt offensichtlich, ist natürlich das Thema Security. Das ist dann das, was oft als DevSecOps bezeichnet wird. Das ist im Grunde eine Querschnittsfunktion, die unten drunter liegen sollte, weil ich auch da in jeder Phase meines Zyklus das Thema einfließen lassen muss.
12:40
Also angefangen in meiner Planphase, wo ich vielleicht User Stories für meine Software erstelle, wenn ich es da versäume, auch nicht funktionale User Stories für Security-Themen zum Beispiel einfließen zu lassen, dann werden die in der Entwicklung nicht berücksichtigt und sie können auch im Testing nicht berücksichtigt werden, weil wenn ich auf meine User Stories teste und es gibt keine für Security, dann habe ich es unter Umständen übersehen.
13:03
Das Geilste gleich beim Thema Deployment, da kommen wir gleich noch ein bisschen mehr auf die Infrastruktur. Aber auch da muss ich halt gucken, wenn ich meine Infrastruktur als Code beschreibe, dass ich das genauso wie bei normalem Source Code auf Schwachstellen checke. Auch im Betrieb dann das Ganze,
13:21
da ist es sehr wichtig, dass ich ein sauberes Monitoring habe und auch da einen sauberen Rückkanal habe, wenn Schwachstellen auftreten. Und diese Schwachstellen müssen wir natürlich auch wieder in meinen Entwicklungsprozess einfließen, weil wenn es jetzt halt Schwachstellen im Code sind und keine Misskonfigurationen in meinem Podsystem, dann muss das natürlich auch dem Entwickler
13:41
wieder zugetragen werden, damit er im nächsten Release was dagegen tun kann. Auch im Bereich Infrastruktur und Architektur ändert sich so einiges. Ich kenne aus meiner Zeit so im Konzernumfeld noch klassische Multitierarchitekturen,
14:00
die oftmals sehr starr und sehr granular sind, wenn sie damals gut gemacht waren. Das heißt, ich habe meine Frontend Layer, ich habe meine Application Layer, ich habe meine Datenbank. Das Ganze ist hart getrennt, man wisst noch mit der physischen Firewall dazwischen. Ich habe Kommunikation nur von außen nach innen. Das heißt, Frontend darf nur mit Application leden und Application nur mit Database.
14:22
Und da habe ich dann irgendwie ein sehr starres Konstrukt, was mir gefühlt sehr viel Sicherheit bietet, was aber heutzutage einfach nicht mehr funktioniert. Heute haben wir Microservices, die eine Teilfunktion erfüllen und vielleicht gar nicht so genau zu verorten sind. Ist das jetzt ein Frontend Service oder ist das ein Backend Service oder nimmt der vielleicht Funktionen von beidem wahr?
14:42
Ich habe auch keine starren Subnetze mehr, die an einer physischen Firewall hängen, wo ich dann jedes Mal großen Konfigaufwand habe, wenn ich einen Dienst in eine andere Zone umziehen möchte, sondern im Grunde steuere ich das Ganze nur noch über Access Control Lists zwischen den Microservices, die halt vorgeben, wer mit wem reden darf.
15:02
Dann habe ich Container, die ihr eigenes laufwähiges Betriebssystem mitbringen, auch da hatte ich vorher vielleicht mein Golden Image, was in Stein gemeißelt war und in der Schublade lag und was ich für jeden neuen Host als Basis genommen habe. Bei Containern sind wir da deutlich agiler und flexibler und müssen trotzdem sicherstellen,
15:21
dass die Konfiguration dieser sehr kurzlebigen Infrastruktur sicher bleibt. Dann der ganz andere, ganz offensichtliche Wandel ist, das meiste wandert in die Cloud, wobei auch da ist unsere Erfahrung, dass die wenigsten Unternehmen tatsächlich heutzutage Cloud-native denken,
15:40
sondern was viele Unternehmen machen, ist eine Lift-and-Shift-Migration, ziehen erst mal ihre altehergebrachte Architektur und Infrastruktur in die Cloud um und verpassen dadurch aber auch ganz viele Vorteile mitzunehmen, die mir halt eine echte Cloud-Architektur, wenn ich sie von Grund auf neu denke und diesen ganzen alten Ballast mal über Bord werfe, denn bringen würde.
16:02
Das spiegelt sich dann auch weiter, wie diese Cloud-Umgebungen verwaltet werden in der Regel. Ich kenne sehr viele Unternehmen, die tatsächlich dann noch von Hand ihre AWS-Umgebungen konfigurieren, von Hand neue Hosts einrichten und hochziehen, aber auch das ist nicht Cloud-native, sondern wenn ich das zu Ende denke, dann habe ich eben zum Beispiel eine Terraform oder so was,
16:23
womit ich auch meine komplette Cloud-Umgebung und die einzelnen Hosts und Microservices als Quelltext beschreibe. Das hat dann aus Security-Sicht natürlich die Implikation, dass ich, wie eben schon erwähnt, diesen Quelltext genauso behandeln muss wie jeden anderen Quelltext. Das heißt, auch da sollte ich Tests auf dem Quelltext haben.
16:43
Ich sollte den vernünftig in einem Repository ablegen, damit er a, versionierbar ist und ich b, aber halt mich auch immer wieder daraus bedienen kann oder Rollbacks machen kann, wenn ich feststelle, meine Konfiguration ist irgendwo schwach oder fehlerhaft an der Stelle. Das heißt, idealerweise gehe ich gar nicht mehr über die AWS-Konsole und konfiguriere einen einzelnen Host,
17:01
sondern wenn mir da ein Fehler auffällt, dann schmeiße ich ihn weg und lasse mir mit Terraform zum Beispiel einfach eine neue Instanz hochfahren. Das bedingt natürlich, dass Entwickler an der Stelle viel mehr Verantwortung bekommen. Das ist das, was im DevOps-Kontext
17:21
häufig als Shift-Left bezeichnet wird. Auf einmal sind die Entwickler nicht nur für ihren Quelltext verantwortlich, sondern auch für den Quelltext der Infrastruktur beschreibt, wo man vorher sagen konnte, okay, ich habe vielleicht noch so einen Admin, der dann so als zweite Instanz fungiert und selbst wenn meine Applikationen die eine oder andere Schwachstelle hat, idealerweise habe ich dann einen Admin, der das auf andere Weise ein Stück weit wieder abfängt.
17:43
Aber dadurch, dass das jetzt mittlerweile alles integrierte Teams sind, wandert einfach viel mehr Verantwortung in Richtung Entwickler, die eben halt auch diese Konfigurations-Skripte dann jetzt mit beschreiben. Die Frage ist dann natürlich, wie gut sind die Entwickler darauf eingestellt, weil das ist einfach eine ganz andere Rolle
18:01
als das, was man in den letzten Jahren vielleicht gelebt hat und bringt einfach viel mehr Verantwortung mit sich. Das ist so ein relativ aktuelles Beispiel, einfach mal so eine Zahl in den Raum geworfen. Ich weiß nicht, wer von euch kennt Shodan? Okay, das ist schon so die Hälfte, würde ich sagen. Das ist im Grunde eine Suchmaschine,
18:21
mit der ich gezielt nach schwachen IoT-Devices oder ungesicherten Geräten im Internet suchen kann. Das heißt, die scannen ganz bewusst nach IoT-typischen Ports, die sie weltweit erreichen können und gucken, ob die anfällig für bekannte Sicherheitslücken sind oder ob da irgendwie Default-Passwörter drauf sind.
18:42
Und das jetzt so ein schönes Beispiel aus dem Mai. Es gibt halt über Shodan immer noch 1,7 Millionen IoT-Geräte weltweit, die anfällig sind für WannaCry. WannaCry, Verschlüsselungstrojaner, der damals auf Basis von Eternal Blue, also diesem NSA-Hacker-Kit gebaut wurde,
19:00
ist 2017 im Mai so richtig losgetreten, die WannaCry-Welle, obwohl es auch da schon seit März 2017 einen Patch von Microsoft gab. Das heißt, da haben es offensichtlich ziemlich viele Leute verschlafen, ihre Systeme rechtzeitig zu patchen. Aber selbst dann heute, Mai 2019, gibt es halt immer noch 1,7 Millionen IoT-Geräte,
19:21
um die sich offensichtlich niemand kümmert, die wahrscheinlich nicht mehr supportet werden und wo sich auch weder Hersteller noch Entwickler bei den Herstellern oder Betriebsverantwortliche bei den Herstellern gemüßigt sehen, was daran zu ändern an der Situation. Ein weiteres Beispiel,
19:40
und das tut mir so als Security-Experten tatsächlich ein bisschen weh, die OWASP Top Ten. Wer kennt die hier im Raum so als Namen? Ja, es sind, glaube ich, ein paar mehr. Aber allein das ist bezeichnend, weil die OWASP Top Ten, die sollte eigentlich jeder, der irgendwas mit dem Thema Softwareentwicklung oder IT insgesamt zu tun hat, kennen.
20:02
Das ist eine Non-Profit-Organisation, die veröffentlicht regelmäßig die häufigsten oder die Top Ten-Sicherheitslücken, die in Web-Applikationen gefunden werden. Das sind so Themen wie Injection, also zum Beispiel SQL-Injection oder auch generell jeglicher Art von Code-Injection,
20:21
die ich in meiner Web-Applikation haben kann. Das sind Themen wie schwache Authentifizierung oder schwaches Session-Management. Das sind Themen wie Cross-Site-Scripting. Das gibt es ja auch in zwei Flavors, als Stored und als Reflected Cross-Site-Scripting. Aber gerade so eine Stored Cross-Site-Scripting-Attacke, da verlier ich ratzfatz die Admin-Passwörter für mein Backend.
20:44
Das sind wirklich sehr ernstzunehmende Lücken. Und im Grunde sollte wirklich jeder Softwareentwickler diese Themen kennen. Also es gibt von der OWASP auch dazu ganz gute Ressourcen. Es gibt Secure Coding Policies und Guidelines, die genau darauf abzielen, diese Fehler nicht zu machen.
21:01
Es gibt Skripte und Tools von OWASP, um seinen eigenen Code darauf zu testen. Es gibt Labs von OWASP, wo man sich mit dem Thema beschäftigen kann. Was eigentlich die erschreckende Botschaft ist an der Stelle, wenn wir uns die Top 10 von 2013 und von 2017 angucken, die werden so im 4-Jahres-Zyklus ungefähr released.
21:22
Dann sehen wir, dass da vier neue Top 10-Items dazugekommen sind, beziehungsweise eins ist eigentlich so eine Verschmelzung aus zwei anderen Themen. Aber wir reden auch vier Jahre später eigentlich noch über genau die gleichen Themen. Wir reden immer noch über Injection, wir reden immer noch über Cross-Site-Scripting. Wir haben immer noch schwaches Session-Management oder gebrochene Authentifizierungen.
21:43
Und das ist was, was wirklich besorgniserregend ist. Also auf der einen Seite verschieben wir, wie gesagt, sehr viel Verantwortung in Richtung Entwickler und werden da immer agiler und immer schneller. Auf der anderen Seite schaffen wir es aber nicht, diese Basis nachzuschieben, dass die Leute wirklich von Beginn an solche Dinge schon im Kopf haben
22:01
und berücksichtigen können. Das heißt, da muss ein ganz großer Know-How-Transfer stattfinden, sonst wird dieses Delta zwischen Theorie und Wirklichkeit, wie es Security aussehen sollte, immer größer. Ja, und dann wird sich auch in den nächsten Jahren nichts an dieser Situation ändern.
22:21
Das ist, wie gesagt, dieser erwähnte Developer Report, den GitLab kürzlich veröffentlicht hat. Da wurden 4.000 Leute befragt weltweit, also aus ganz verschiedenen Kontexten. Es gibt so ein paar gute Nachrichten. Also zum einen, dass das Thema DevOps zum Beispiel für mehr Transparenz in der Organisation sorgt.
22:41
Da sagen sowohl die Security-Verantwortlichen als auch die Operations-Teams und die Entwickler, dass sie durch solche Konzepte einen Mehrwert haben und mehr sehen, was in der Organisation passiert. Wie gesagt, 45% der Unternehmen geben an, dass sie auch tatsächlich Continuous Deployment schon praktizieren.
23:01
Wie gesagt, würde ich ein bisschen mit Vorbehalt genießen, weil ich gehe mal davon aus, dass es da eher um Deployments in Testsysteme geht. Und die Frage war auch, ob irgendwo in der Organisation sowas eingesetzt wird, nicht ob das jetzt flächendeckend der Fall ist. Am spannendsten ist für mich aber der dritte Punkt. 50% der Unternehmen glauben, sie seien in Sachen Security
23:20
schon ganz gut aufgestellt und stellen Schwachstellen im Kot fest, bevor sie tatsächlich in die Produktion gehen. Die Frage ist, was ist mit den anderen 50%? Also entweder hat sich ja keiner aus der Deckung gewagt oder die Situation ist tatsächlich so, dass in 50% der Unternehmen immer noch signifikant Schwachstellen tatsächlich erst nach Go Live gefunden werden.
23:42
Und das ist was, was wir ändern müssen. Genau, das spiegelt sich dann auch so ein bisschen weit wieder nochmal im gleichen Report, wenn es darum geht, wie die Entwickler denn ihr eigenes Security-Wissen einschätzen. Da gibt es 30%, die sich ganz gut aufgestellt fühlen.
24:03
Das sind auch diejenigen, von denen ich erwarten würde, dass sie Themen wie OWASP kennen und verinnerlichen. Weitere 25% fühlen sich ganz gut aufgestellt. Aber es gibt auch ein Viertel der Befragten an, dass sie tatsächlich sich für das Thema Security nicht gut vorbereitet fühlen.
24:20
Und auch da das Delta, wenn jetzt über 55% angeben, sie wären gut oder sehr gut aufgestellt in dem Bereich, dann ist die Frage, warum ändert sich an den OWASP Top 10 nichts in den letzten Jahren? Also da scheint es tatsächlich eine Lücke zu geben, die noch nicht adäquat arrestiert ist. Deswegen aus meiner Security-Brille
24:42
so ein kleiner Appell an die Entwickler, baut sicheren Code, baut besseren Code, damit wir vielleicht in vier Jahren über andere Top 10-Items reden und es dann zum Beispiel mehr ums Thema Monitoring geht und eben nicht um Schwachstellen, die nach wie vor im Source Code selber zu finden sind.
25:00
Genauso sollten Entwickler eben solche relevanten Guidelines kennen. Also neben OWASP gibt es zum Beispiel von der SIS noch ganz gute Benchmarks. Das Center of Internet Security ist auch so eine Non-Profit-Organisation, aber quasi auch ein De facto-Standard, zumindest in den Security-Kreisen. Muss aber bei den Entwicklern dann genauso bekannt sein. Dann haben wir das Thema Security Automation.
25:23
Die Entwicklungstools sind häufig schon gut durchautomatisiert. Hoffentlich eher das Security am Ende das Problem, was dann so ein bisschen den Flaschenhals darstellt, wenn ich mit meiner Code-Entwicklung fertig bin. Aber auch da müssen Security-Tools in die CI-CD-Pipeline von vornherein mit integriert werden. Und nicht erst am Ende irgendwo eine statische Code-Analyse.
25:42
Das reicht einfach nicht mehr an der Stelle. Und zu guter Letzt, wenn ihr keine nicht-funktionalen, sprich auch Security-Anforderungen zum Beispiel, bekommen von euren Auftraggebern, von euren Projekten, fordert die ein. Weil ansonsten wir leben nicht mehr in einer isolierten Welt, wo jeder nur seins macht. DevSecOps greift ineinander.
26:02
Und wenn wir da nicht von vornherein Hand in Hand gehen und solche Controls auch als User-Stories einfließen lassen, dann fallen sie halt am Ende hinten runter und wir stellen doch erst wieder nach Goal-Life fest, dass da Schwachstellen vorhanden sind. Auch die Security-Branche muss sich natürlich verändern.
26:21
Das Ganze ist keine Einbahnstraße und funktioniert nur, wenn auch wir unseren Beitrag dazu leisten. Reine Perimeter-Security, hatte ich am Anfang schon erwähnt, ist einfach nicht mehr State of the Art und funktioniert nicht. Auch da brauchen wir aus der Security-Welt neue Konzepte, die deutlich flexibler agieren.
26:41
Es gibt da schon ein paar Ansätze, die aber zum Teil noch nicht zu Ende gedacht sind. Und leider kennen auch ich viele Security-Experten, die das Thema immer noch so sehen. Wir sind so das Anhängsel. Nach dem Entwicklungsprozess mache ich meinen Penetration-Test. Nudel da irgendwie nur eine Woche lang rum, habe ein paar Findings, gebe die dem Entwickler zurück,
27:01
der fixt die und dann gehe ich erst live mit dem Produkt. Aber auch das funktioniert halt nicht mehr, wenn ich agil entwickle. Das heißt, da müssen wir dazu hingehen, tatsächlich startische, dynamische Code-Analyse einzusetzen. Das macht im Übrigen einen echten, manuellen Penetration-Test nicht überflüssig, weil auch da habe ich einfach noch mehr Logik,
27:20
die vielleicht nur ein Mensch mit an den Tisch bringen kann, um jetzt auch mal so ein bisschen ausgefallenere Angriffsszenarien mir auszudenken oder verschiedene Schwachstellen zu kombinieren und daraus dann neue Angriffsektoren abzuleiten. Das kriegen die Tools tatsächlich heute noch nicht so gut hin. Nichtsdestotrotz sollte ein Penetration-Test heute eine unterstützende Maßnahme sein,
27:40
der dann vielleicht noch ein-, zweimal im Jahr auf neuen Major-Releases durchgeführt wird. Aber ich kann eben nicht mehr jedes einzelne Deployment durch einen manuellen Penetration-Test jagen. Und da wollen wir als Security auch Enabler werden an der Stelle und eben nicht derjenige sein, der immer hinten nur ausbremst und den Leuten sagt, was sie vorne falsch gemacht haben. Das funktioniert nicht.
28:01
Genauso sind wir natürlich auch in der Verantwortung, diesen Know-How-Transfer zu unterstützen, also die Entwickler aufzuschlauen. Und auch da gibt es leider immer noch viel zu viele Security-Experten, die sich selber als Guru sehen und so ein bisschen Expertenwissen horten. Aber letztendlich muss das von beiden Seiten kommen. Entwicklungen und Betrieb müssen Know-How anfragen, aber wir müssen auch bereit sein,
28:22
sowohl Know-How als auch Verantwortung abzugeben an der Stelle, weil das ist ein Teamsport. Das heißt, wir haben große Herausforderungen, unsere Prozesse, unsere Vorgehensweisen, wie wir in der Vergangenheit gearbeitet haben, anzupassen und eben in diese neue Welt zu transferieren.
28:43
Viele Unternehmen denken jetzt, das ist primär ein technologisches Problem. Das ist leider so der erste Schnellschuss, den man häufig sieht in der Praxis. Wenn wir uns mal angucken, was es zum Beispiel im Atlassian Marketplace gibt zum Thema DevOps oder Dex-HefOps,
29:01
dann ist das eine ganze Menge. Da sind die ganzen großen Namen dabei, die man so kennt. Ich denke mal, jeder von euch findet da so seine Tools wieder, die er in der CI-CD-Pipeline schon drin hat. Dann haben wir auch so ein paar Security-Tools dabei, so ein Sonar-Type zum Beispiel, der mich dann auch bei der Code-Analyse unterstützt. Aber letztendlich, ich habe eine Riesenvielfalt.
29:23
Viele von diesen Tools tun Ähnliches oder tun das Gleiche. Und manchmal ist es gar nicht so leicht, da die richtige Abgrenzung zu finden und die richtige Auswahl zu treffen, wie mir diese Tools denn jetzt helfen in der Praxis. Dann gibt es auch von Suns noch so eine schöne Folie zu dem Thema, die ist jetzt so klein, dass ihr die wahrscheinlich gar nicht lesen könnt.
29:42
Das ist aber eigentlich auch genau die Message. Und zwar spiegelt diese Folie jetzt einfach nur so die bekanntesten Tools wieder, die man im Security-Bereich einsetzen kann in einem DevOps-Kontext. Da habe ich meine Phasen wieder, also Pre-Commit, Commit, Acceptance, Production, Operations.
30:01
Und in jedem dieser Bereiche habe ich eine Vielzahl von Tools, die alle meistens einen sehr speziellen Zweck erfüllen. Da habe ich irgendwie Dependency-Checker. Ich habe Tools, die irgendwie gezielt nach Passwörtern in meinem Source-Code suchen zum Beispiel. Ich habe Tools, die eine Startschekot-Analyse durchführen.
30:23
Aber was tatsächlich das Problem ist, ist die schiere Auswahl. Und die Kunden sind damit oft so überfordert, dass sie sich dann entscheiden, entweder gar nichts einzuführen oder ausschützweise mal ein kleines Tool an der einen oder anderen Stelle in ihren Prozess einfließen zu lassen, aber das Ganze halt eben nicht vollumfänglich integrieren.
30:41
Und dann ist es ein Tropfen aus dem heißen Stein. Wir sind ein bisschen besser dran als vorher. Aber es ist halt keine vernünftige, saubere Ende-zu-Ende-Lösung. Das spiegelt sich dann auch wieder so ein bisschen wieder in dem, was GitLab in ihrer Umfrage herausgefunden hat.
31:01
Ich gehe davon aus, ehrlich gesagt, dass hier vor allen Dingen auch wieder die amerikanischen Unternehmen so ein bisschen überrepräsentiert sind. Also Dependency Scanner haben sehr viele Unternehmen im Einsatz. Das ist schon mal gut, weil das ist auch was, was sich relativ leicht implementieren lässt, dass ich sowohl Abhängigkeiten im Code transparent mache als auch irgendwie Third-Party-Module,
31:21
die vielleicht schon bekannt sind, dass sie Schwachstellen haben, dass ich da einfach die Transparenz habe, die auch rechtzeitig dann updaten oder abschalten zu können, wenn es nicht anders geht. Das Thema Cloud Security würde ich auch so aus der eigenen Erfahrung nicht ganz unterschreiben, dass da 42 Prozent gut aufgestellt sind. Ich meine, es gibt relativ viel von den großen Cloud Service Providern.
31:43
Ich muss mir da gar nicht alles selber zurecht konfigurieren, sondern selbst wenn ich einfach nur das Standard Toolset nutze, was ich da schon bekomme, zum Beispiel für sichere Konfiguration oder für Monitoring, bin ich eigentlich schon sehr gut aufgestellt und habe so die ersten 60 Prozent aus Security-Sicht schon mal abgehakt.
32:01
Genau, Container Security auch da. Wenn ich vorgefertigte Container, vorgeherdete Container nutze, bin ich wahrscheinlich auch schon so weit, dass jetzt 40 Prozent sagen würden, sie wären gut aufgestellt. Danach wird es aber ein bisschen interessanter. Jetzt kommen nämlich die Konzepte oder Applikationen dazu, die ein bisschen mehr Know-how erfordern, um sie zu integrieren.
32:23
Das ist zum Beispiel das Thema startische Code-Analyse oder auch dynamische Code-Analyse, was dann sogar noch ein bisschen mehr sophisticated ist. Ja, da geht es dann darum, wo platziere ich denn so einen Sonar-Type zum Beispiel in meiner Toolchain und vor allen Dingen aber auch, was mache ich mit den Findings? Weil allein davon, dass ich so ein Tool habe, was mir irgendwo Findings ausspuckt, habe ich noch nichts gewonnen.
32:43
Ich muss auch einen vernünftigen Prozess haben, wie ich das dann wiederum zurückschiebe in meine Entwicklungspipeline und vorne wieder als Anforderungen reinkippe. Und auch da brauchen wir wieder den Know-how-Transfer, weil wenn die Entwickler alleine entscheiden,
33:00
welches Feature jetzt Priorität hat, dann fehlt da unter Umständen die Gewichtung, was die Risiken angeht, die ich mir damit einhandle. Das heißt, auch da muss man schauen, wie man gemeinsam einen Rating hinbekommen kann, welche User-Stories jetzt welche Priorität haben soll. Und auch da würde ich jetzt Security-Features nicht zwangsläufig über funktionalen Features gewichten.
33:22
Aber es muss halt in einer Balance sein. Deswegen, um das Ganze zusammenzufassen, wir haben eine Vielzahl an Tools, die es schon gibt. Diese Tools kommen aber meistens entweder nur aus der Entwicklerecke.
33:41
Das heißt, der Security-Experte versteht sie nicht oder sie kommen sehr aus der Security-Experte, sehr aus der Security-Ecke. Und der Entwickler versteht vielleicht gar nicht, was der Mehrwert für ihn ist, was der Mehrwert im Hinblick auf mein gesamtes RIS-Profil ist, sowohl meine Applikation als auch meine Unternehmung vielleicht. Und bei Heben können wir das Ganze nur,
34:00
indem wir uns gemeinsam an den Tisch setzen und überlegen, was sind denn die Anforderungen von beiden Seiten und wie können wir das zusammenbringen. Und mein persönlicher Appell ist auch, an alle, die Interesse am Thema Security haben, bringt euch gerne aktiv ein in die Entwicklung neuer Security-Tools. Weil auch da, wenn da die Security-Experten
34:21
in ihrem Elfenbeintörmchen sitzen und überlegen, was aus ihrer Sicht sinnvoll ist und die Entwickler nicht mit ihren Anforderungen mit am Tisch sitzen, kommen wir auch da zu keinem guten Ergebnis. Dann ist auch da wieder die eine Seite überrepräsentiert. Also es funktioniert letztendlich nur, indem wir gemeinsam überlegen, was fehlt noch und wie bringen wir da die verschiedenen Anforderungen übereinander.
34:47
Genau, das als kurzer Ausblick. Habt ihr Fragen oder Anmerkungen? Ja.
35:02
Ja.
35:28
Ja. Ja. Ja. Genau, was du sagst. Also wie gesagt, ich will da auch gar nicht den Entwicklern den schwarzen Peter zuschieben,
35:41
sondern ich glaube letztendlich haben da bisher beide sehr in ihren Silos gearbeitet und man redet auch oft aneinander vorbei. Also ich kenne es auch umgekehrt, dass der Entwickler mir was erklärt und ich merke, dass bei mir dann erst mal so die Lampen angehen aus Security-Sicht, aber letztendlich muss man halt gucken, was ist so, dass die Schnittmenge,
36:00
dass man ein gesundes Gesamtergebnis hat. Eben. Richtig.
36:38
Ja, absolut. Das ist eigentlich genau der letzte Punkt.
36:41
Also auch bei der Entwicklung wirklich von technischen Security-Lösungen, von Security-Produkten müssen die Entwickler einfach tief mit eingebunden sein und ihre Denkmuster und Vorgehensweise mit einbringen, weil ansonsten funktioniert es in der Praxis nicht und dann ist Security halt auch immer hinten der Flaschenhals und der Verhinderer und das wollen wir nicht sein.
37:46
Also auch da, wir haben so einen gewissen Wildwuchs. Es gibt diverse Tools, also auch so ein Threadfix zum Beispiel generiert ja dann auch aus dem Finding, was du aus deiner Code-Analyse hast, direkt ein Ticket, was vorne wieder reinläuft. Also man muss vielleicht im Einzelfall ein bisschen gucken,
38:02
was für Tools ihr da genau im Einsatz habt, aber meine ganz generelle Empfehlung ist, das muss automatisiert sein. Also wenn dann händisch irgendwelche Listen rauskommen, die ich dann per Mail irgendwem schicke oder auf den Tisch lege, das funktioniert nicht, weil auch das hält meinen Entwicklungsprozess wieder auf. Ja, also wie gesagt, man kann auch so Dinge bauen,
38:28
dass das Ticket dann zum Beispiel kein klassisches Ticket ist, sondern direkt eine User-Story, die vorne reinfließt, die vielleicht unterwegs irgendwie automatisch noch gerated wird gegen meine Security-Controls, die ich so als Liste irgendwo pflege.
38:42
Aber das ist genauso eine der Herausforderungen. Also alle Pipelines sind irgendwie ähnlich. Ich habe immer so die gleichen Prozessschritte und Module. Und doch ist es mittlerweile so Kraut und Rüben, dass man selten das Konzept, was beim einen funktioniert, 100 Prozent auf die andere Pipeline übertragen kann, sondern oft sind es irgendwie 80 Prozent mit gewissen Anpassungen.
39:02
Aber wie gesagt, gerade das Thema Automation ist halt so ein bisschen der Dreh- und Angelpunkt, um das flüssig hinzubekommen und dann auch die Akzeptanz auch wieder von Entwicklern zu haben, dass das ein Mehrwert ist an der Stelle. Ja.
40:32
Ja. Ja.
40:50
Bitte? Explizit nicht, nee.
41:01
Ja.
41:22
Mhm.
41:48
Ja.
42:14
Ja.
42:26
Genau. Also zum einen vielleicht so zu Ihrer ersten Hälfte. Ich glaube, ganz viel ist einfach der Punkt, dass wir mehr aufeinander hören müssen und ein besseres Verständnis dafür auch bekommen müssen, wie die anderen Pipelines. Weil es eben keine andere Seite ist, sondern es ist halt ein Team,
42:42
was in der Vergangenheit sehr isoliert gearbeitet hat, aber jetzt einfach mehr und mehr zusammenwächst. Und ich habe auch viele DevOps-Teams gesehen, wo zumindest dieser Teil schon ganz gut funktioniert zwischen Entwickler und Betrieb. Und dieses Team müssen wir jetzt eben noch erweitern um die Security-Experten. Und der zweite Punkt, ja, es ist ganz viel in Bewegung.
43:01
Es ist sehr viel Dynamik drin. Und das ist aber auch, glaube ich, genau die Aufgabe jetzt von Beratern, eben in diesem Dschungel sowohl der veränderten Konzepte als auch der veränderten Tools zumindest irgendwie ein sinnvolles Set zusammenzustellen. Also ich glaube, es kann auch nicht Sinn der Sache sein, dass wir dann alle Tools, die wir jetzt hier bei Besans gesehen haben,
43:20
zusammen integrieren und sagen, dann sind wir 150% sicher. Sondern es geht darum, eine sinnvolle Auswahl zu treffen. Und auch das wird sich im Laufe der Zeit verändern. Also was, ja.
43:42
Nee, also das wäre jetzt tatsächlich nicht mein Bericht, weil es ein sehr spezielles Feld ist. Also wir würden dann eher tatsächlich fokussieren da, wo Software entwickelt wird. Also wo wir auch den echten Quelltext zur Verfügung haben. Weil Reverse Engineering bringt halt nie das Gleiche, als wenn ich vor dem Compiler den echten Quelltext reingucke. Klar, in manchen Bereichen habe ich keine andere Möglichkeit,
44:02
gerade wenn es irgendwie öffentlicher Dienst ist. Ich nehme an, da geht es wahrscheinlich auch ein bisschen um Chips und so weiter, wo man dann tatsächlich nicht alles zu sehen bekommt. Aber das ist eigentlich aus meiner Sicht mehr so ein Spezialfall. Und die breite Masse der Unternehmen, gerade so im Mittelstand,
44:20
die entwickeln halt Software selber. Oder geben es ganz raus, kaufen irgendwas von der Stange ein. Aber auch da wird niemand den Aufwand betreiben, das komplett zu Reverse Engineering. Also auch da muss ich, glaube ich, so ein bisschen die Verhältnismäßigkeit wahren, das Risiko vielleicht sauber transferieren. Aber sonst werde ich halt auch nie fertig an der Stelle. Aber klar, es gibt diese Anwältungsfelder.
45:44
Das ist auch ein super Einstieger. Gerade Sonar Cube ist meistens das,
46:01
was die Unternehmen so als erstes einführen, wenn sie sich überhaupt mit dem Thema beschäftigen. Dann vielleicht, wie gesagt, noch ergänzt um Dependency Checker. Das ist zwar dann immer noch nicht der Ende-zu-Ende-Prozess, aber es ist ein Schritt in die richtige Richtung. Und besser, als wenn ich mich jetzt erstmal ein Jahr lang einschließe, mir das Gesamtkonzept überlege und bis dahin hat sich meine Tool-Landschaft vielleicht schon komplett verändert. Also gerade Sonar Cube, ja, kann ich auch jedem ans Herz legen.
46:26
Gibt es noch weitere Fragen? Jo. Diverse. Genau. Können wir gleich mal gucken. Hast du einen konkreten Anwendungsfall? Um welche Plattform geht es?
46:41
Was für eine Umgebung? Java. Was für einen Kontext? Cloud oder Docker? Oder ganz allgemein? Also, wie gesagt, da würde ich bei OWAS tatsächlich noch mal schauen. Da gibt es ein paar ganz coole Ressourcen und Tools,
47:02
die du nutzen kannst. Dann bieten auch die Repositories mittlerweile sehr viele Features, die man so aktivieren kann. Was hast du für eine Repository dahinter? Git. Git, ja. Genau, also dann würde ich da mal reingucken, weil die sind auch gerade ganz massiv dabei, ihre Features, die sie quasi als Standard anbieten, auszubauen.
47:24
Und da kann man auch schon einiges erreichen mit Konfiguration. Gut, dann. Vielen Dank für die Aufmerksamkeit.