Hallo und herzlich willkommen zu einer neuen Folge vom Podcast Software Testing. Heute wieder mit einer Folge von der OOP 2024 in München. Bei mir zu Gast heute Nils Göde. Ich habe mit ihm über Security Audits gesprochen. Im Prinzip geht es darum, Security nicht dann erst am Schirm zu haben, wenn alles zu spät ist und es knallt, sondern schon frühzeitig das Thema Security im Entwicklungsprozess mitzudenken. Wie wir das machen können, was es dafür braucht und
welche Fallstricke es gibt, hört ihr gleich in der kommenden Folge. Viel Spaß dabei. Hallo Nils, schön, dass du da bist. Ja, vielen Dank. Freut mich, dass du mich eingeladen hast. Ja, weil du ja auch ein ganz spannendes Thema hast. Ich habe mir das im Vorfeld angeschaut. Wir sind ja hier auf der OOP 2024, wieder mal alle zusammen. Man kann sich angucken, man kann miteinander reden. Das ist hervorragend. Ja, schöne Sache. Viele Netzwerkmöglichkeiten
hier, das genieße ich auch total. Und ich habe mir im Vorfeld also die Abstracts angeschaut auch und da ist mir bei dir, der Titel war super genial, Ignorieren bis es knallt. Und da fühlte ich mich so richtig abgeholt. Es geht ja um das Thema Security und wenn ich so bei meinen Kunden, Klienten schaue, die machen Security dann, wenn sie es müssen, regulatorisch irgendwann und das wird dann so ein bisschen Alibi mäßig gemacht oder halt erst dann, wenn es wirklich knallt. Und
deswegen habe ich mich da total verstanden gefühlt und über das Thema können wir mal sprechen. Wie kann man denn das besser machen? Da kommen wir auf jeden Fall zu, aber ich finde auch, das ist auf jeden Fall schon mal ein großer Widerspruch. Also was wir feststellen ist, auf der einen Seite finden alle super relevant. Es braucht nicht viel Zeit, jemanden zu überzeugen, dass das Thema Security irgendwie Bedeutung hat oder wichtig ist für
einen selbst. Gleichzeitig sehen wir aber in der Praxis doch viele Probleme, die dann doch in den Systemen noch existieren. Es scheint also nicht ganz so einfach und straightforward zu sein, sich dem Thema anzunehmen. Und wir versuchen eben oder haben jetzt mit diesem Vortrag auf der OP versucht, so ein bisschen diesen Konflikt aufzulösen und einen Weg zu skizzieren, wie es dann vielleicht doch funktionieren kann. Wie kommt es denn dazu, dass so viele das so
wegignorieren? Ich glaube, ein großer Teil davon ist, dass es einfach unglaublich schwierig ist, sich dem Thema zu widmen. Weil ja, natürlich, wenn in den News der neuste größte Hack beschrieben wird, dann sind alle erst mal aufgescheucht und es ist eine hohe Awareness für das Thema da. Wenn man dann aber ins Doing kommt, stellt sich ja unmittelbar die Frage, okay, was heißt denn das für uns? Sind wir auch betroffen? Wir hatten die Lock-for-Shale-Lücke vor einigen Monaten. Das
konnte man noch relativ einfach prüfen, ob man davon betroffen ist oder nicht. Aber es gibt ja viele Probleme, die sind dann doch etwas komplexer und es lässt sich nicht so einfach entscheiden, betrifft es uns auch? Haben wir dort ein Problem? Und deswegen auch in unserem Vortrag ganz bewusst haben wir zwei Perspektiven mal angeschaut. Also einmal die aus dem Entwicklungsteam. Das sind ja diejenigen, die letzten Endes diese Findings dann doch auf sehr detaillierter Codebene
nachvollziehen müssen. Und wir zeigen viele Beispiele und man sieht, es ist nicht sehr befriedigend, sich da durchzuwühlen. Es gibt False Positives wie bei allen anderen Analysen, aber gerade im Security-Bereich noch mehr, würde ich mal behaupten. Dann gibt es Dinge, die sind einfach nicht einfach zu beantworten, weil so ein lokaler Code-Kontext, ich schaue hier in meine eine Datei, hilft dann manchmal doch nicht, weil nehmen wir mal an, da kommen irgendwie Werte aus
irgendeiner .ini-Datei, werden sie gelesen, eins unserer Beispiele. Dann stellt sich natürlich die Frage, okay, wer kann denn da Werte reinschreiben? Und das sehe ich dem Code halt nicht an. Deswegen ist es sehr teuer, auch da diese Findings zu analysieren. Und ich glaube, das verzögert es halt und stellt sich relativ schnell Ernüchterung ein. Man kommt nicht so richtig voran mit diesem kleinteiligen Durchschauen der Findings, die da so gefunden werden.
Das finde ich, hast du da vielleicht noch ein anderes Beispiel? Das mit der .ini-Datei ist für mich total nachvollziehbar. Also klar, man liest das da, aber man weiß gar nicht, wo das daherkommt. Das betrifft ja dann einfach auch die Organisation vielleicht rundherum. Genau, man kommt sehr schnell zu dem Thema, dass man auch die IT-Infrastruktur, die Rollenkonzepte, organisatorische Dinge und so mit berücksichtigen muss. Das heißt, es liegt schon nahe, das Ganze
ein bisschen größer zu betrachten. Es lässt sich eben nicht nur auf Code-Ebene beantworten. Ja, bitte. Genau. Auf der anderen Seite, also wir haben ja bewusst dann auch nochmal die Management-Seite reingebracht. Die hat natürlich ein berechtigtes Interesse daran, dass das System so sicher wie möglich ist. Und gerade wenn sie auch von externen Auflagen bekommen, von Behörden oder Guidelines, die ihnen auferlegt werden, dann stellt sich natürlich schon die Frage, wie steht es drum?
Und dann wiederum stellen wir auch oft fest, dann kommt es doch auf die Zahlen an. Die interessieren sich doch für die Findings und denen ist dann auch egal, ob das ein Falls-Positive ist oder nicht. Die wollen einfach so etwas nicht sehen. Ja, ich glaube, das ist schon ein interessantes Spannungsfeld. Wenn ich mir Entwicklungsteams auch anschaue, die so vor sich hin programmieren, gerade in Magie, da ist man dann häufig so
Feature-getrieben auch. Ja, du musst dieses just, dieses just, dieses noch hier und das muss gleich raus und Iteration und Sprint, blablabla. Das muss alles fertig werden. Und so wie du sagst, bei diesen Security-Themen gerade im Entwicklungsumfeld, da fehlt dann einfach auch ein bisschen die Klarheit, was getan werden muss. So wie du sagst, die Komplexität und ich glaube, auf Klarheit folgt Handlung. Wenn ich die nicht habe, vermeide ich das
und mache lieber die Sachen, wo ich weiß, was ich zu tun habe. Wie kann man denn uns das jetzt annähern, dass wir das ein bisschen gelöst bekommen? Genau, also das, was nicht funktioniert, um es nochmal zusammenzufassen, ist dieses Ad-Hoc-Attention für das Thema Security. Es passiert was, alle sind aufgescheucht, man macht so ein paar Sachen und dann ist die Attention wieder weg. Das funktioniert erfahrungsgemäß nicht.
Und was wir eben vorschlagen, nicht nur für Security-Themen, auch für alle Qualitätsthemen allgemein, ist eben diese kontinuierliche Auseinandersetzung mit dem Thema. Weil da wissen wir tatsächlich auch, dass es in der Praxis funktioniert. Wir begleiten ja auch viele Teams in ihrer
Entwicklung durch Retrospektiven zu Security, aber auch anderen Qualitätsthemen. Und da stellen wir schon fest, wenn man es schafft, über die Zeit sich mit einer gewissen Attention dem Thema zu nähern, dann schafft man es zwar nicht kurzfristig, alle Probleme loszuwerden, aber mittelfristig stellt sich halt ein positiver Trend ein. Und das darf man einfach nicht unterschätzen. Man hat schon viel erreicht, wenn man es schafft, einfach mal die Probleme
zu stoppen. In dem Sinne, es wird nicht schlimmer. Also das ist so die erste Ausbauschluffe des Ganzen. Und wenn man es dann noch schafft, kontinuierlich besser zu werden, dann ist man eigentlich total auf dem richtigen Weg. Und das heißt, alle unsere Methodiken, die wir bewerben und die wir empfehlen, zielen eben darauf ab. Versucht kontinuierlich das Thema zu adressieren. Versucht es auch möglichst gut in eure normale Entwicklung und gerade
den Entwicklungsprozess zu integrieren. Denn völlig verständlich, die Features sind immer prominenter. Also ich habe noch kein Team getroffen, das ist dann okay, wir haben gerade keine Features, dann machen wir jetzt andere Sachen. Die sind eh immer da. Deswegen geht es eigentlich um einen smarten Weg, diese Qualitätsthemen und auch die Security-Themen
damit zu verknüpfen. Wie kann ich mir das vorstellen? Ich denke mal, wenn ich jetzt in ein Team gehe und sage, eine Retrospektive kommt raus, wir müssen das begleitend uns anschauen. Dann sagen alle, ja, müssen wir. Und wenn es dann heißt, wer macht es jetzt und wie, dann denkst du, oh, keine Ahnung. Wie kann man sich denn dann dem annähern, dass man da so Methoden oder welche kann man dafür nutzen?
Ja, also ich glaube, ein wichtiger Punkt ist auf jeden Fall Transparenz. Ich habe gestern mit jemandem gesprochen, der sagt, er ist in so einem querschnittlichen Security-Team, er kommt dann in die Teams rein und legt ihnen eine Liste von Problemen vor. Das ist schon ein sehr schwieriges Setting, weil es ist unglaublich unfair für die Teams, wenn irgendwann jemand kommt und so eine Liste auspackt und sagt, hey, das haben wir bei euch gefunden.
Deswegen ist es wichtig, dass die Teams auch vorher schon wissen, hey, worauf wird eigentlich geschaut? Wo können wir vorher schon nachschauen, ob wir die Anforderungen diesbezüglich erfüllen oder nicht? Also so ein Tool, wo alle wissen, okay, da sind die Checks und wenn da irgendwas anschlägt, dann wird das in der Retro angesprochen. Also das ist meine Grundvoraussetzung, dass man so ein gemeinsames Verständnis hat.
Also sagst du, dass auch Tools, die das dann auch regelmäßig schon mitprüfen, also quasi die auch mit zu integrieren? Alles, was per Tool prüfbar ist, sollte man diesbezüglich auch prüfen, sofern es natürlich relevant ist. Also es gibt viele Checks, die in irgendeinem Kontext keinen Sinn machen, die sollte man natürlich deaktivieren. Aber andernfalls sollten die Sachen einfach aktiviert sein und ein gemeinsames Verständnis dafür da sein. Und dann vielleicht der allergrößte
Hebel. Gott sei Dank, die meisten Teams arbeiten ja mittlerweile mit so was wie einem GitLab oder GitHub, wo es dann Merge-Requests, Pull-Requests gibt. Und das ist ein super Ort, um sich dort zu integrieren. Denn das ist der Ort, wo letzten Endes so eine Art, ja, kleines Qualitäts-Türchen, ich spreche nicht vom Quality-Gate, sondern von so einem Qualitäts-Türchen ist, wo dann ein Review stattfindet. Und wenn man es schafft, dort die Information hinzubringen, da sind
drei neue Findings im Bereich Security. Dann hat man eigentlich eine sehr gute Stelle, wo eh jede Änderung dran vorbeikommt, wo auch ein menschlicher Reviewer vielleicht sehr dankbar ist, wenn das Tool vorher schon was gefunden hat, weil dann kann ich mir die Zeit erstmal sparen. Bei uns gibt es zum Beispiel die Regel, solange die Tools irgendwelche Findings berichten, geht da kein menschlicher Reviewer dran. Also die Grundvoraussetzung
ist erstmal, dass die Tools nichts finden diesbezüglich. Und dann, genau, und diese Integration ist halt unglaublich wertvoll, weil da hat man es mit einer sehr niedrigen Schwelle, also ich muss nicht auf irgendein anderes Tool schauen, ich muss nicht irgendwelche statischen HTML-Reports aus irgendeinem Verzeichnis aufrufen, sondern ich habe eh den Ort, wo
irgendjemand diese Änderung approven muss und sagt, das ist okay. Und wenn man es schafft, dort die Information reinzubringen, dann funktioniert das auch mit wenig Overhead, unserer Erfahrung nach. Jetzt ist es ja bei Tools, also gerade wenn es um so statische Analysen auch geht oder sowas, was quasi vorweg da schon mitlaufen kann, wenn ich das einschalte, dann erschlägt das ja häufig einen, wenn man so den Alt-Code da mal durchrechnet, da denkt man, mein Gott,
das ist ja alles verloren. Also am besten, wir machen den Laden dicht. Hast du da einen Tipp, wie man da rangehen kann, um das dann auch mal im Team dann irgendwie die Landung sanft zu machen? Ja, auf jeden Fall. Das ist ja die Situation, mit der wir eigentlich immer konfrontiert sind. Und siebenstellige Findingszahlen sind jetzt auch nichts Ungewöhnliches für uns. Die Kunst ist, und das klingt erstmal blöd, aber die Kunst ist zu sagen, wir akzeptieren
mal den Status Quo. So ist es jetzt. Da ziehen wir mal eine Baseline, heißt es bei uns dann auch im Werkzeug, die ziehen wir mal ein. Und wie vorhin schon gesagt, das Ziel ist dann erstmal nicht schlechter zu werden. Wir haben ja 7.100.000 Findings, okay, aber es sollten nicht mehr sein bei der nächsten Retrospektive. Und es wird sehr, sehr lange dauern, bis man die weggearbeitet hat. Also diese Idee von, mein System ist frei von Problemen,
das ist in der Praxis eher nicht umsetzbar. Aber wenn man es schafft, das dann umzukehren und kontinuierlich neue Sachen zu vermeiden, alte auszubauen, dann hat man einen positiven Trend. Und das wirkt unglaublich motivierend, weil irgendwann tritt diese absolute Zahl in den Hintergrund. Und dieser Trend ist eigentlich das, worauf man schaut und sagt, hey, wir haben es wieder geschafft. Hat wieder gut geklappt. Alle Pfeile zeigen nach oben,
sozusagen. Ja, das finde ich total, total schön, weil das ist auch ein Ansatz, den ich so, auch bei solchen Tools immer total schön finde, wenn man eher auf den Trend schaut, gerade wenn man sowas Altes hat und nicht auf so absolute Zahlen. Also auch bei Coverage oder solche Sachen. Ich finde, so absolute Werte kann man machen, kann man aber auch lassen. Aber zu sehen, wie ist die Entwicklung im bestehenden, im modifizierten Code, im neuen? Wie gehe ich
damit dann um? Das finde ich eine schöne Sache und entspannt, glaube ich, auch. Ja, ich glaube, was man unbedingt vermeiden sollte, sind solche Aufräumaktionen. Also das sehen wir ja auch, dass jemand versucht, dann eben alles wegzuarbeiten. Und jetzt nehmen wir uns mal drei Wochen Zeit, machen keine Features mehr. Es führt nur zu Frustration, weil es kommen einfach keine neuen Features. Das ist schon klar, die fehlen. Aber es ist ja auch immer so,
durch die mutmaßliche Korrektur kommen auch neue Probleme rein. Und dann hat man einen sehr schlechten Standpunkt, das noch zu argumentieren, wenn durch die Aufräumaktion sogar noch neue Probleme reingekommen sind. Also sowas nicht. Wir empfehlen da tatsächlich eher die Zeltplatzregel. Verlasse den Zeltplatz immer etwas sauberer, als du ihn vorgefunden hast. Kann man hervorragend
übertragen. Also wenn du eine Methode oder eine Datei bearbeitest, dort Code änderst, dann nimm das doch als Gelegenheit, die Probleme dort vielleicht zu adressieren. Weil dann bist du eh drin. Du hast es gelesen, du hast es verstanden. Es muss durch den Test, es muss durch das Review. Also warum nicht dann einfach zwei, drei Probleme wegräumen, die eh da in dem Kontext sind? Das macht total Sinn. Also ich denke auch,
das ist so eine Aufräumaktion. Das sieht man ja immer wieder. Na, da gibt es dann so, das wird dann so ein Hardening-Sprint oder so irgendwie gepackt oder so. Wir machen jetzt alles besser. Es ist eigentlich, hat ja keiner Bock drauf. Ja, das kommt noch dazu. Also keiner Bock. Und zum anderen, ich muss ja, wenn ich auch da reingehe in Code, muss ich ja total aufpassen, ich ändere nichts an der Funktionalität. Das heißt, ich muss auf meine Regressionstests nochmal
genau gucken. Die braucht man auch. Stabiles Netz von den Regressionstests. Genau, das ist nicht ohne. Also so ein Ding. Wie sieht es denn aus? Ich denke immer so, wenn ich an Security denke, häufig ja an so Hacker-Minds. Also ich hatte mal einen Kollegen, der hat dann immer so sein Linux-Notebook aufgeklappt und hat dann so herumgetippt. Und wenn er Ups gesagt hat, dann war irgendwas, war was Schlimmes passiert bei ihm. Hat er irgendwas kaputt gemacht. Der
hatte ja total ein nerdiges Spezialwissen, muss ich sagen. Was brauche ich denn als Entwickler oder in einem Team an Spezialwissen zu dem Thema Security, zu diesen ganzen Lücken oder so? Wird mir das gut aufbereitet oder muss ich irgendwo noch nachschlagen? Brauche ich irgendwie eine Schulung dazu oder wie? Ich glaube, Schulung kommt dem am nächsten. Ich glaube, was man nochmal klar sagen muss ist, wir sind ja jetzt auch nicht die Security-Experten, die jedes Detail dort
kennen. Unser Thema ist ja Zukunftssicherheit, Qualität von Software-Systemen. Da spielt Security eine Rolle. Aber wir sind nicht diejenigen, die das im vollen Umfang bedienen, das Thema. Und gleiches würde ich jetzt mal für die Entwicklungsteams ansetzen. Ein gewisses Grundwissen ist, glaube ich, gut und hilfreich. Ich würde aber nicht erwarten, dass das jetzt
alle Security-Experten sind, die jedes Detail kennen. Ich meine, dafür gibt es dann noch sowas wie einen Pen-Test oder so, was auch grundsätzlich eine gute Idee ist, der dann nochmal andere Sachen abfängt. Aber so ein solides Grundwissen, gerade was so Code-Level-Sachen angeht, ist schon hilfreich und wichtig. Und da ist unsere Erfahrung gerade auch nochmal durch Reviews und auch Retrospektiven. Das ist ein super Forum, um diesen Wissensaustausch zu
leisten. Denn es gibt ja meist ein, zwei Personen im Team, die haben sich da schon Gedanken darüber gemacht. Die wissen, was das Thema ist. Und dann kann man mit so einer Retrospektive, wenn man da so mal zwei, drei exemplarische Findings aufblättert und sagt, hey, was ist denn hier los? Warum ist das ein Problem? Betrifft uns das? Und wie wollen wir
uns in Zukunft adressieren? Dann hat man schon einen enormen Wissensaustausch. Und ich würde fast sagen, wenn man das noch mit ein bisschen Dokumentation unterstützt, so zu den Best Practices und die Coding-Guidelines vielleicht noch um so einen Bereich Security erweitert, dann ist eigentlich schon eine solide Basis da. Jetzt ist es ja bei Security oder bei diesem ganzen nicht-funktionalen Bereich. Also ich
kenne einige Teams, die stellen sich das so vor. Das steht dann in der User-Story drinnen als Akzeptanzgrippe, irgendein Security-Ziel oder so irgendwas. Oder wie bei Performance, dass man das dann da irgendwo mit reinwurschtelt. Und dann ist das so eine einmalige Geschichte, die taucht dann auf und da wird dann irgendwie abgearbeitet. Das wollen wir ja jetzt hier nicht. Du hast ja auch gesagt, das muss ich in den Prozess integrieren. Wie kann ich denn jetzt als Team, wenn ich da so
eine Awareness schaffen will, da loslegen, dass ich mir da mehr Gedanken dazu mache? Was würdest du den Hörerinnen und Hörern da so mitgeben? Wie kann man da so reinstarten in das Thema? Ja, vermutlich wird es irgendeine Art von Kick-Off-Initierungen brauchen, um das Thema einfach allgemein mal auf die Agenda zu bringen. Und dann ist es schon,
ich würde tatsächlich mit dem Tool starten, weil dieses Thema ist so vielfältig. Natürlich, man kann jetzt auch top-down überlegen, okay, welche Aspekte von Security sind für uns die relevantesten. Aber wenn man eh schon ein Tool im Einsatz hat, viele davon haben schon eine gewisse Anzahl von Checks im Bereich Security. Das würde ich mal als Ausgangsbasis nehmen. Und dann, je nachdem, welche Applikationen man hat, lohnt sich vielleicht auch mal ein Blick auf die
Guidelines. So eine OWASP Top 10 oder so betrifft viele Applikationen. Vielleicht kann man das mal zum Anlass nehmen. Nimmt sowas mal her und schaut mal, okay, mit den Tools, die wir haben, was davon können wir denn abdecken? Was können wir nicht abdecken? Gibt es vielleicht ein zweites Tool, was uns die Lücken schließen kann? Da kommen wir auch wieder zu TeamScale als Integrationsplattform, weil wir verfolgen das Ziel, eben dann diese Infos an einem Ort zu bündeln, damit man eben
nicht nachher fünf verschiedene Tools an fünf verschiedenen Orten anschauen muss. Genau. Und dann geht es darum, sich, wie gesagt, durch Retrospektiven so Schritt für Schritt voran arbeiten. Da werden Prüfungen sein, wo man sagt, okay, in unserem Kontext nie relevant. Dann muss einfach die Konfiguration geändert werden. Der Check ist aus in unserem Fall und die Findings tauchen nicht mehr auf. Es mag Checks geben, die grundsätzlich relevant sind, wo es aber einzelne
Findings gibt, die doch nicht relevant sind. Im Vortrag habe ich das Beispiel Passwörter im Code, im Produktivcode ja. Wir sehen aber auch Passwörter im Testcode zum Beispiel. Das ist halt ein diskussionswürdiges Thema. Kann man so oder so sehen, aber da muss ein Team sich mit auseinandersetzen. Und so hangelt man sich durch und kommt dann idealerweise zu einer guten Konfiguration, also Konfiguration der Tools, aber auch entsprechenden Guidelines drüber, die einem
dann erlauben, das auch kontinuierlich wirklich zu leben und vor allen Dingen mit wenig Aufwand. Ich glaube, das ist immer der wichtige Aspekt dabei. Es darf nicht zu viel Zusatzaufwand erzeugen, sondern es muss relativ gut integriert sein. Ich glaube, das ist auch das A und O. Wenn man so Feature-getrieben ist, dann will man sich jetzt auch nicht so massiv die Zeit dafür nehmen. Das muss quasi auf der Spur mitlaufen können. Und ich glaube, auch bei der Security gibt es ja immer
wieder so ein bisschen ein Trade-off auch hin zu, wie komfortabel ist etwas gestaltet. Also, wenn du gerade Passwörter ansprichst, es gibt ja oft dann so diese, wir brauchen da so Test-User oder sowas. Und die schlagen dann manchmal an, weil die auch irgendwie alle zwei Monate ihre Passwort wechseln müssen, weil das da irgendwie so Organisationsvorgaben sind. Und da hat man dann immer so ein bisschen ein Ding, wie sicher mache ich meine Test-Infrastruktur trotzdem? Oder
wie passe ich es an oder wie komfortabel habe ich es dann? Ja, das ist ein Trade-off und sehr spannend, dass du das ansprichst, weil wir merken, dass viele sich dessen nicht bewusst sind und das nicht zu Ende diskutiert haben. Wo möchte ich eigentlich sein zwischen Sicherheit und Komfort, wie du es genannt hast? Also typisches Beispiel der Geldautomat, der würde viel smarter funktionieren, wenn ich keine PIN eingeben muss. Dann wäre er komfortabler, wäre aber natürlich nicht mehr so
sicher, wie er vorher ist. Und das trifft eben auch auf die allermeisten Software-Systeme zu. Und vielleicht bei so einem initialen Treffen ist es gut, sich dessen mal bewusst zu werden, wo wollen wir eigentlich sein? Und das ist ein Trade-off. Also ich meine, 100 Prozent Sicherheit gibt es eh nicht, aber man kann diesen Schieberegler schon verschieben, also Richtung Sicherheit oder Richtung Komfort eben. Ihr habt ja als Unternehmen, ihr seid ja da auch sehr breit und sehr viel
unterwegs und könnt den Markt auch gut einschätzen. Merkt ihr durch solche Vorkommnisse wie Log4J, dass sich da noch wirklich was tut in den Teams? Dass dann wirklich auch so ein bisschen, also außer dem Management, dass dann vielleicht mal kurz kopflos rumrutscht. Dass sich dann auch wirklich nachhaltig was ändert in den Entwicklungsteams? Kriegt ihr das mit? Ja, ich glaube schon. Also das ist gerade auch ein sehr gutes Beispiel, weil da ist wirklich viel
passiert. Zum einen bei unseren Kunden, die Teamscale einsetzen, haben wir dann doch sehr stark gemerkt, okay, es hat irgendwie eine Relevanz für alle. Jeder ist bemüht, dann auch zu verstehen, wo liegt das Problem und wie können wir uns schützen? Also das hat an der Stelle schon funktioniert. Das ist ja ein gutes Zeichen, dass es besser wird mit der Zeit. Genau, aber das wie gesagt, das hat dann immer noch so ein bisschen diesen Charakter, dieses Ad-Hoc-Vorgehens. Jetzt
ist gerade mal ein großes Problem, wir kümmern uns alle drum. Aber ich glaube, in der einen oder anderen Situation haben wir es geschafft, das zu nutzen, um dann halt ein angemessenes Level an Attention für das Thema Security zu etablieren bei den Teams. Ja, es entsteht ja ein Momentum
dadurch und das kann man natürlich dann auf die Straße bringen und integrieren. Was ich auch noch mal sagen muss ist, wenn wir unsere Einmalanalysen, also Software Audits machen für Systeme und auf ihre Zukunftssicherheit allgemein analysieren, ist Security ein Thema und es gibt eben viele dieser Audits, wo das dann doch ein relevantes Thema ist, also eine nennenswerte Herausforderung
für deren Zukunft. Und Erfahrung ist, wenn wir sowas auflegen, dann ist schon ein großes Bewusstsein da, hey, da müssen wir was tun, weil teilweise sind es echt gravierende Sicherheitsmängel, die wir da finden. Und dann ist meist allen Beteiligten auch klar, okay, da müssen wir auch kontinuierlich was tun, damit das eben nicht wieder passiert. Und Vorteil ist, wir sind ja auf allen Ebenen unterwegs, also in so einem Audit. Wir sprechen mit dem Entwicklungsteam, wir sprechen mit
Architektinnen, wir sprechen aber auch mit dem Management. Das heißt, wir haben die Chance, auf allen Ebenen so ein Thema zu platzieren. Und unsere Herausforderung an der Stelle ist, von der Technik, von Low-Level-Code-Findings das alles zu abstrahieren und dann zu übergeordneten Herausforderungen zusammenzubauen. Aber ich behaupte mal, das gelingt uns einigermaßen gut, sodass wir es schaffen, dann so ein Thema da auch zu verankern in so einem Unternehmen.
Ja, ich glaube, da ist noch ein ganz spannender Punkt, nämlich auch bei diesen ganzen Security-Dingen, auch bei statischer Analyse, was da so rauskommt oder wenn ich das irgendwie prüfe und finde da irgendwo einen Mangel, dass das ja Sachen sind, die ich auf die Zukunft einzahle, dass das nicht genutzt wird, dass das keinen Fehler bringt. Aber im Moment sind die ja einfach nur schlummernde
Schläfer sozusagen, die noch nicht genutzt werden, im besten Fall. Und das ist, glaube ich, mit argumentativ auch immer noch ein bisschen, dass man das auch unterfüttern muss, dass das ein Problem werden kann, mit einer Wahrscheinlichkeit wird, aber vielleicht jetzt noch gar nicht ist. Ja, wobei der Teil ist gar nicht so einfach zu beantworten. Ich glaube, da müssen wir wieder sagen, da sind wir nicht die Experten für. Ich würde mal nicht davon ausgehen, dass diese Lügen
alle nicht ausgenutzt werden. Es gibt bestimmt einzelne Beispiele, die schon auf irgendeine Art und Weise genutzt werden, ohne dass es jetzt zum Super-GAU kommt. Ich meine, es geht ja nicht immer darum, die Systeme komplett lahmzulegen. Manche sind ja auch froh, wenn sie einfach massenweise Daten da absaugen können, ohne dass es irgendjemandem auffällt. Da wäre ich vorsichtig. Das formulieren wir auch immer bewusst vorsichtig. Unserer Kenntnis nach ist bisher nichts passiert,
aber wissen tun wir es natürlich nicht. Ja, da ist wahrscheinlich die Dunkelziffer auch sehr groß. Das kriegt man vielleicht gar nicht so mit. Die wollen natürlich auch nicht, dass das publik wird. Super. Nils, vielen lieben Dank für diese Einsichten, Einblicke in das Thema Security Audit und wie man sich dem nähern kann. Sehr spannend, da habe ich wieder etwas gelernt. Da freue ich mich auch immer darüber. Ich wünsche dir ganz viel Spaß hier noch bei der OOP. Ja, vielen Dank, gleichfalls.
Und freue mich aufs Wiedersehen. Sehr schön. Bis bald. Untertitel der Amara.org-Community