Mehr Sicherheit, weniger Freiheit? Wie NIS2 & CRA die IT verändern

Voiceover: Hallo und herzlich willkommen bei Digital Future, dem Podcast zu Technologie

Voiceover: und Unternehmenskultur.

Voiceover: Mein Name ist Wolfgang Schoch und ich bin Agile Coach bei InnoVex.

Voiceover: Ich habe aber auch schon ein paar andere Sachen gemacht und so die IT-Branche

Voiceover: aus verschiedenen Blickwinkeln kennengelernt.

Voiceover: Zum Beispiel als Softwareentwickler, als Experte für Suchtechnologie oder im Vertrieb.

Voiceover: Ich freue mich, euch in jeder Folge des Podcasts eine Kollegin oder einen Kollegen

Voiceover: vorzustellen und mich mit ihr oder ihm über das jeweilige Fachgebiet zu unterhalten.

Voiceover: So bekommt ihr einen Einblick in unseren technologischen und unternehmenskulturellen Alltag.

Voiceover: In der heutigen Folge spreche ich wieder einmal mit meinem Kollegen Clemens Hübner.

Voiceover: Ihr kennt ihn vielleicht schon aus unseren anderen Gesprächen über Security-Themen hier im Podcast.

Voiceover: Clemens ist Security Engineer und erlebt und liebt das Thema.

Voiceover: Heute sprechen wir über Regulierungen in diesem Bereich. Denn im InnoVex Newsletter

Voiceover: vom Mai 2025, da wurde Clemens die folgende Frage gestellt.

Voiceover: Bremst die zunehmende Regulierung durch Richtlinien und Verordnungen wie die

Voiceover: Network and Information Systems Directive oder der Cyber Resilience Act die

Voiceover: Softwareentwicklung aus?

Voiceover: Und die Frage, die lasse ich mir von Clemens heute ganz ausführlich beantworten.

Voiceover: Wir sprechen natürlich auch darüber, was sich hinter diesen Richtlinien und

Voiceover: Verordnungen verbirgt.

Voiceover: Und jetzt wünsche ich euch viel Spaß beim Zuhören.

Wolfgang: Hallo Clemens, ich habe gerade schon überlegt, das wievielte Mal du schon zu

Wolfgang: Gast bist hier im Podcast.

Wolfgang: Ich glaube das dritte oder das vierte Mal.

Clemens: Ich glaube, es ist das dritte.

Wolfgang: Ja. Das dritte Mal. Ich freue mich auf jeden Fall riesig, weil es macht immer

Wolfgang: mega viel Spaß, mit dir zu quatschen.

Wolfgang: Und so deine Expertise, so der Bereich Security, der ist ja auch super spannend,

Wolfgang: weil ich meine, wenn man sich irgendwie so Technik-News durchliest oder auch

Wolfgang: so ganz normale News, da ist ja fast jede Woche irgendwas Großes, Dickes dabei.

Wolfgang: Da wurden wieder irgendwelche Daten veröffentlicht, da wurde irgendwas geklaut

Wolfgang: an Daten und das fühlt sich für mich als Bürger immer unangenehm an,

Wolfgang: vor allem wenn so meine eigenen Daten betroffen sind und deswegen finde ich

Wolfgang: es schön, wenn wir da ein bisschen drüber sprechen können.

Wolfgang: Clemens, für alle, die den ganzen Katalog an Folgen noch nicht komplett durchgehört

Wolfgang: haben und deswegen dich vielleicht auch noch nicht kennen, kannst du dich bitte

Wolfgang: mal ganz kurz vorstellen?

Wolfgang: Wer bist du? Wie lange arbeitest du schon bei Innovex? Und was machst du eigentlich

Wolfgang: bei uns, wenn du nicht gerade hier im Podcast bist?

Clemens: Ja, sehr gerne. Danke dir, Wolfgang. Danke auch für die Einladung,

Clemens: dass ich nochmal da sein darf.

Clemens: Genau, ich bin Clemens. Ich bin hier bei InnoVex Software Security Engineer

Clemens: jetzt schon seit sieben Jahren.

Clemens: Das heißt, ich begleite unsere Entwicklungsprojekte aus einer Security Perspektive,

Clemens: schaue, dass das, was wir für unsere Kunden entwickeln und betreiben,

Clemens: auch immer angemessen sicher ist und habe in der Vergangenheit viel in Entwicklungsteams

Clemens: mitgearbeitet, teilweise auch mitentwickelt. entwickelt.

Clemens: In letzter Zeit bin ich auch viel beratend tätig für unsere eigenen Projekte,

Clemens: aber eben auch für Kunden, die sagen, wir würden auch gerne so sichere Software

Clemens: entwickeln. Was brauche ich dafür?

Clemens: Deswegen berate ich da viel, gebe Trainings, teile mein Wissen.

Clemens: Das ist, was ich gerade so mache.

Wolfgang: Ja, und eine Sache hast du gerade unterschlagen. Du bist nämlich auch im aktuellen

Wolfgang: neu überarbeiteten Newsletter von InnoVex als InnoVexpert dabei und ich habe

Wolfgang: mir hier mal was rausgeschrieben.

Wolfgang: Da gab es eine Frage an dich, ich weiß nicht, ob die ein bisschen provokant formuliert war,

Wolfgang: aber die Frage, die lautete sinngemäß, bremsen Regulierungen wie beispielsweise

Wolfgang: die Network and Information Systems Directive, kurz NIST II oder der Cyber Resilience Act, kurz CRA,

Wolfgang: die Softwareentwicklung aus?

Wolfgang: Und da hast du ein langes Statement und eine Einschätzung abgegeben.

Wolfgang: Ich habe mal das durchgelesen.

Wolfgang: Kannst du vielleicht nochmal jetzt ganz kurz hier für alle, die zuhören, darauf antworten?

Clemens: Ja, gerne. Genau, also der NIST-2 oder auch der Cyber Resilience Act,

Clemens: das sind ja so Themen, die gerade viele Unternehmen beschäftigen.

Clemens: Viele kommen zu uns, kommen zu mir und sagen, was müssen wir da jetzt eigentlich genau machen?

Clemens: Und man hört auch oft irgendwie so Panikmache, ja, jetzt wird uns alles todreguliert,

Clemens: wir können quasi keine Software mehr entwickeln, das wirft uns total zurück.

Clemens: Und deswegen haben wir das da im Newsletter mal aufgegriffen.

Clemens: Genau, die Antwort, die ich da gegeben habe, wenn ich mich richtig erinnere,

Clemens: war, nee, es wird uns nicht komplett ausbremsen.

Clemens: Also es sind beides Regulatorik von der EU, mit denen sich Unternehmen beschäftigen müssen.

Clemens: Mindest zwei, fast alle Unternehmen müssen sich da mal auf den Prüfstand stellen

Clemens: und schauen, ob sie da drunter fallen.

Clemens: Bei CAA geht es dann wirklich um Unternehmen, die Produkte mit digitalen Elementen entwickeln.

Clemens: Das ist dann ein bisschen kleiner von der Menge vielleicht.

Clemens: Aber sich das mal anzuschauen, das ist für alle verpflichtend und für viele

Clemens: kommen dann da halt auch entsprechend Aktivitäten an.

Clemens: Aber den positiven Take, den ich im Newsletter da bringen wollte und den ich

Clemens: auch weiterhin glaube, ist, dass uns das eben nicht ausbremsen wird,

Clemens: sondern dass ich das als Chance verstehen würde. Chance, warum?

Clemens: Weil die Sachen, die da gefordert werden, sind größtenteils auf jeden Fall sinnvolle

Clemens: Sachen und Unternehmen, Teams, die schon irgendwie sichere Software entwickeln,

Clemens: die werden damit auch nicht so viele Probleme haben.

Clemens: Und die, bei denen da noch mehr zu tun ist, die werden dadurch halt das erste

Clemens: Mal vielleicht gezwungen,

Clemens: sich damit nochmal mehr auseinanderzusetzen, aber haben dann am Ende halt auch

Clemens: sichere Entwicklungsprozesse, sichere Infrastruktur, sichere Produkte und können davon profitieren.

Clemens: Und am Ende sind das ja Sachen, die nicht einfach aus Spaß an der Freude irgendwie

Clemens: reguliert werden, sondern weil es einen Mehrwert hat für die Produkte,

Clemens: für die Verbraucher, vielleicht auch für unsere gemeinsame Infrastruktur,

Clemens: für unsere Gesellschaft.

Clemens: Und deswegen sind das Sachen, die auf jeden Fall einen Mehrwert haben.

Wolfgang: Es ist also nicht so, dass hier irgendwelche in Anführungszeichen Fantasieregulierungen

Wolfgang: jetzt so von der EU durchgedrückt werden.

Wolfgang: Es gibt ja oft Menschen, die immer so ein bisschen vorsichtig sind,

Wolfgang: wenn was reguliert wird.

Wolfgang: Und da kommen oft ja auch so absurde Beispiele wie, ja, die EU,

Wolfgang: die hat ja auch reguliert, wie eine Banane aussehen muss und das ist komplett

Wolfgang: nicht nachvollziehbar.

Wolfgang: Und bei den beiden Themen, und ich meine, es gibt ja noch viel mehr Regulierung,

Wolfgang: es gibt ja auch so diesen KI-Act, über den ich neulich mal gesprochen habe.

Wolfgang: Aber bei den beiden Sachen jetzt sagst du schon, dass das vernünftige Dinge

Wolfgang: sind, die da drinstehen.

Clemens: Ja, größtenteils auf jeden Fall. Es gibt so ein paar Sachen,

Clemens: die sind auf jeden Fall erstmal schwierig oder nicht trivial umzusetzen.

Clemens: Sonst würden es ja auch schon alle machen. Also zum Beispiel,

Clemens: wenn du ein Produkt neu auf den

Clemens: Markt bringst, dann musst du eine Schwachstellenfreiheit gewährleisten.

Clemens: Und jeder, der schon mal irgendwie eine größere Software mit mehreren Komponenten

Clemens: entwickelt hat, der weiß, wie viele Abhängigkeiten man da drin hat und wie kompliziert

Clemens: es vielleicht auch werden kann.

Clemens: Am Ende ist das Problem halt auch einfach, dass diese Regulatorik auch noch

Clemens: nicht so 100 Prozent spezifisch und 100 Prozent genau ist und man im Zweifel

Clemens: auch erst noch mit der Zeit sehen wird, wie das genau umgesetzt werden muss.

Clemens: Vielleicht auch erst ein paar Urteile braucht, bis man weiß,

Clemens: was das jetzt genau bedeutet und was genau erforderlich ist.

Clemens: Deswegen ist da eine gewisse Verunsicherung auf jeden Fall schon da.

Wolfgang: Ja, also ich persönlich bin eigentlich ein Fan, was so Regulierungen und vielleicht

Wolfgang: auch so Standards und so angeht.

Wolfgang: Ich glaube nämlich, manche Leute, die argumentieren ja immer mit diesem ominösen,

Wolfgang: gesunden Menschenverstand, den es meiner Meinung nach nicht gibt,

Wolfgang: aber der cool wäre, wenn er existieren würde.

Wolfgang: Ich glaube, dass so Regulierungen auch durchaus einfach so eine gute Richtschnur sind.

Wolfgang: Um sich jetzt auch mit Themen zu beschäftigen, weil vielleicht gibt es einfach

Wolfgang: Themen, die total wertvoll und wichtig sind und vielleicht fehlt aber in manchen

Wolfgang: Unternehmen halt dann auch so die Expertise, um damit überhaupt umgehen zu können.

Wolfgang: Vielleicht fehlt auch die Expertise, um das überhaupt zu erkennen.

Wolfgang: Und für mich als User, für mich als Bürger ist es natürlich schon gut,

Wolfgang: wenn die ganzen Unternehmen, die da draußen irgendwelche digitalen Dienstleistungen

Wolfgang: und Produkte anbieten, wenn es da einen gewissen Standard gibt und gewisse Vorgaben

Wolfgang: gibt, wie da auch mit Daten umgegangen wird.

Wolfgang: Denn ich hatte es ja am Anfang schon gesagt, ich lese irgendwie wirklich fast

Wolfgang: jeden Tag, zumindest jede Woche, dass irgendwo Daten abgeflossen sind und irgendwo geklaut wurden.

Wolfgang: Und das fühlt sich schon ganz schön schlecht an, wenn es halt so die eigenen

Wolfgang: Daten sind und vor allem, wenn es irgendwelche relevanten Personendaten sind

Wolfgang: oder vielleicht auch Bankdaten etc. Das fühlt sich einfach nicht gut an.

Wolfgang: Und insofern finde ich es prinzipiell auch positiv.

Wolfgang: Und ich finde, so ein Beispiel ist irgendwie, als man damals in Deutschland

Wolfgang: so ganz wahnsinnig war und die Gurtpflicht im Auto eingeführt hat.

Wolfgang: Man kann sich so alte Dokumentationen und Reportagen anschauen.

Wolfgang: Da sind die Leute also wirklich auf die Barrikaden gegangen.

Wolfgang: Da haben die gesagt, hey, das ist eine Bevormundung und das ist schlecht.

Wolfgang: Und es gab auch Leute, die gesagt haben, davon wird man krank oder unfruchtbar

Wolfgang: oder irgendwas anderes und stellt sich jetzt aber viele Jahrzehnte später raus,

Wolfgang: das war eigentlich eine gute Sache,

Wolfgang: denn es sind einfach viel weniger Menschen gestorben und ich glaube,

Wolfgang: manche Automobilhersteller haben es sich vielleicht dann auch mal so vorgenommen

Wolfgang: und haben da nicht nur das absolute Minimum vielleicht eingebaut in so ein Auto,

Wolfgang: sondern haben sich vielleicht überlegt, wie kann das Ding noch bequemer sein.

Wolfgang: So Autos haben ja auch so einen verstellbaren Gurt und vielleicht noch andere

Wolfgang: Sachen oder so einen schönen, nervigen Gurtpiepser, der einen dran erinnert.

Wolfgang: Und letztendlich weiß ich nicht. Ich weiß nicht, ob sich heute viele Menschen

Wolfgang: darüber beschweren, dass es Anschnallgurte in Autos gibt.

Clemens: Ich denke nicht. Und ein aktuelleres Beispiel ist ja zum Beispiel auch die Datenschutzgrundverordnung.

Clemens: Als die damals eingeführt wurde, da war ja auch eine ähnliche Panik,

Clemens: sage ich mal, von Unternehmen, von der Öffentlichkeit, die gesagt haben, was bedeutet das jetzt?

Clemens: Hier wird das reguliert. Da gehen uns reihenweise irgendwie Unternehmen,

Clemens: Pleite, das können wir nicht umsetzen und so.

Clemens: Und jetzt im Nachgang, glaube ich, muss man da so ein bisschen drüber schmunzeln

Clemens: und schätzt auf der anderen Seite halt, was uns das als Standard gebracht hat

Clemens: hinsichtlich von Datenschutz, was ja ein Grundrecht ist in Europa.

Clemens: Und da ähnliche Situationen am Anfang, große Verunsicherung, große Fragezeichen.

Clemens: Man hat aber trotzdem den Weg gefunden, damit umzugehen und hat am Ende halt

Clemens: jetzt auch einfach Anwendungen, Systeme, Verarbeitungen, die für den Verbraucher,

Clemens: für uns alle irgendwie sinnvoll sind.

Wolfgang: Ja, nicht nur sinnvoll. Ich finde es großartig. Also gerade Datenschutzgrundverordnung.

Wolfgang: Das eine war ja damals, die meisten sich aufgeregt haben.

Wolfgang: Die haben ja auch irgendwie behauptet oder so kam es zumindest in den Medien

Wolfgang: rüber. Jetzt ist plötzlich diese Datenschutzgrundverordnung da.

Wolfgang: Es wurde immer so ein bisschen verschwiegen, dass die schon ein paar Jahre vorher angekündigt wurde.

Wolfgang: Und die meisten haben sich vielleicht nicht darum gekümmert.

Wolfgang: Aber heute finde ich es als Bürger großartig, denn wenn ich heute mir mal irgendwelche

Wolfgang: News aus den USA anschaue, was da mit Daten gemacht wird, wo du als Bürgerin

Wolfgang: oder Bürger irgendwie keine Chance hast,

Wolfgang: da irgendwas dagegen zu tun, Da finde ich es schon ganz gut,

Wolfgang: hier in Europa zu leben und zu wissen, dass viele Dinge ja einfach nicht möglich sind für Unternehmen,

Wolfgang: sondern dass ich als Bürger halt ja so die Macht habe über meine eigenen Daten

Wolfgang: und auch entscheiden kann, was damit geschieht.

Wolfgang: Und ich verstehe natürlich auch, dass es so ein paar Tech-Bros da draußen gibt,

Wolfgang: die sagen, das ist der Untergang unserer Digitalwirtschaft, weil man darf ja gar nichts mehr.

Wolfgang: Aber da möchte ich immer gerne antworten, ja zum Glück. Dann seid doch bitte

Wolfgang: kreativ und sucht euch ein Geschäftsmodell, das funktioniert. Genau.

Clemens: Und weil du gerade sagst, damals war das Geschrei groß, weil das so plötzlich gekommen ist.

Clemens: Ich ahne, dass das ähnlich beim Cyber Resilience Act auch laufen wird.

Clemens: Der Act selber ist jetzt schon in Kraft getreten. Es gelten jetzt aber noch

Clemens: Übergangsfristen und Ende 2027 gilt der dann wirklich für alle Produkte.

Clemens: Aber es genügt halt jetzt nicht, sich eben bis dahin Zeit zu lassen,

Clemens: weil viele Sachen, die das Cyber Resilience Act halt fordert,

Clemens: schon während der Entwicklung geschehen müssen.

Clemens: Das heißt, diese lange Frist von irgendwie über drei Jahren,

Clemens: die es da jetzt gab, zwischen Inkrafttreten und dann wirklich voller Anwendung,

Clemens: die ist schon auch sinnvoll, weil Unternehmen sich darauf einstellen können und auch müssen,

Clemens: ihre Entwicklungsprozesse so darauf auszurichten.

Wolfgang: Ja, finde ich auch absolut sinnvoll, dass es solche Übergangsfristen gibt,

Wolfgang: denn wenn du jetzt wirklich in einem sehr, sehr kurzen Zeitraum sowas implementieren musst,

Wolfgang: dann können sich das viele halt auch gar nicht leisten, weil sowas natürlich

Wolfgang: teuer ist, weil du da Zeit reinstecken musst und vielleicht ein kleines Unternehmen

Wolfgang: hat vielleicht auch gar nicht genügend Leute oder vielleicht auch gar nicht die richtigen Leute.

Wolfgang: Und vielleicht kommen wir jetzt auch so ein bisschen auf dich rüber, Clemens.

Wolfgang: Man braucht nämlich Menschen mit der richtigen Erfahrung, mit dem richtigen

Wolfgang: Wissen, um solche Dinge überhaupt implementieren zu können.

Wolfgang: Denn wenn man halt keine Ahnung hat von Security-Themen, kann man sich sicherlich

Wolfgang: ja so einen Cyber-Resilience-Act durchlesen und versteht dann nicht so richtig viel.

Clemens: Ja, und vor allem die große Gefahr, die ich sehe,

Clemens: ist, dass man vielleicht die Hälfte versteht und dann umsetzt oder sich noch

Clemens: mit mehr Google-Arbeit dann irgendwie schon erschließt, was man da machen kann,

Clemens: aber dann halt wirklich nur blind genau das umsetzt,

Clemens: was man da herausgefunden hat.

Clemens: Und dann mag das dem CAA vielleicht genügen, aber vielleicht bindet man sich

Clemens: da so viele Klötze ans Bein, dass es einen am Ende wirklich mehr hindert.

Clemens: Oder man verpasst es eben, dass man die Möglichkeiten, die man über den Cyber

Clemens: Resilience Act, über die bloße Compliance damit heben kann, dass man die liegen lässt.

Clemens: Weil am Ende ist ein sicheres Produkt halt auch einfach ein qualitativ hochwertiges

Clemens: Produkt und etwas, das das eigene Geschäftsmodell.

Wolfgang: Die eigene Marke stärken kann.

Clemens: Das Vertrauen von den Verbrauchern, von den Konsumenten. Und deswegen ist das

Clemens: was, was man jetzt nicht nur rein aus dem Cyber Resilience Act Hintergrund machen

Clemens: sollte, sondern eben auch aus dem grundsätzlichen Gedanken.

Clemens: Und viele Sachen, die ich in den letzten Jahren schon mit Unternehmen irgendwie

Clemens: hinsichtlich sicherer Softwareentwicklung gemacht habe, die haben die ja schon

Clemens: aus dieser intrinsischen Motivation raus gemacht, dass das einfach sinnvoll ist.

Clemens: Und jetzt finden sie sich im Cyber Resilience Act auch wieder und dann kann man da eben.

Wolfgang: Und genau das ist meiner Meinung nach ein ganz, ganz wichtiger Punkt.

Wolfgang: Ich glaube, wenn du solche Auflagen oder solche Regeln hast,

Wolfgang: die du erfüllen musst, dann hast du halt verschiedene Möglichkeiten.

Wolfgang: Die einfache, vielleicht so der in Anführungszeichen naive Ansatz ist,

Wolfgang: ich schaue, was ich tun muss, damit ich überall ein grünes Häkchen dran bekomme.

Wolfgang: Hier ist eine Vorgabe, okay, die ist erfüllt.

Wolfgang: Aber ich muss dazu ja nicht unbedingt alles verstehen.

Wolfgang: Also das kann ich vielleicht ganz gut einfach abarbeiten mit einer Checkliste

Wolfgang: und ich glaube, je näher so eine Frist rückt, desto mehr solche Checklisten

Wolfgang: wird es im Internet geben. So war es bei der DSGVO damals auch.

Wolfgang: Also ich betreibe privat so ein paar kleine Webseiten, so ein Blog und ein Podcast und so weiter.

Wolfgang: Und da gab es auch so Checklisten, was musst du machen, dass deine Website oder

Wolfgang: dein WordPress-Blog, dass der hier alle Vorlagen oder alle Auflagen halt erfüllt.

Wolfgang: Aber da musste man gar nicht verstehen, was die DSGVO eigentlich bedeutet.

Wolfgang: Und für viele Leute war das, glaube ich, auch ausreichend. Aber ich glaube,

Wolfgang: wenn man was in Anführungszeichen richtig gut machen möchte,

Wolfgang: dann ist es einfach essentiell, dass man solche Dinge auch versteht und auch

Wolfgang: so die Grundlagen versteht, die Hintergründe versteht.

Wolfgang: Denn wenn ich jetzt ein neues Produkt schaffen möchte, dann ist es halt einfach

Wolfgang: richtig gut und auch ein Vorteil vielleicht gegenüber anderen Anbietern auf

Wolfgang: dem Markt, wenn ich so eine Thematik durchdrungen habe.

Wolfgang: Und so eine große Herausforderung, die ich so die letzten fünf oder zehn Jahre

Wolfgang: generell in der Softwareentwicklung sehe, ist, dass es immer mehr solche Metathemen

Wolfgang: gibt. Als ich angefangen habe, war Softwareentwicklung halt echt noch was Einfaches.

Wolfgang: Da hat man halt ein bisschen programmiert und hat gehofft, dass das im Internet

Wolfgang: Explorer einigermaßen gerendert wird.

Wolfgang: Und das war tatsächlich so. Und dann kamen aber immer mehr Themen dazu.

Wolfgang: Dann sowas wie Security kam als Thema dazu.

Wolfgang: Dann auch so moderne Deployments kamen irgendwie als Thema dazu.

Wolfgang: Ich meine, heute hast du dann irgendwelche Kubernetes-Plattformen.

Wolfgang: Da hatte ich neulich mit Maximilian im Podcast drüber gesprochen.

Wolfgang: Das sind Themen, die hatten wir aber vor 15 Jahren noch nicht so.

Wolfgang: Also zu meiner Zeit damals, da hatten wir halt ein paar Root-Server und da lief ein Tomcat drauf.

Wolfgang: Und ich kannte mich damals immer so ein bisschen schon mit Linux aus.

Wolfgang: Ich war halt dann so der Admin.

Wolfgang: Also DevOps gab es da auch noch nicht so in der Form, zumindest in meinen Projekten.

Wolfgang: Und ich habe halt dann mit SCP irgendwas hochgeladen, habe es deployed und das

Wolfgang: war dann die Produktivmaschine.

Wolfgang: Und es kamen immer mehr solche Metathemen irgendwie dazu. Auch KI ist ein Riesending

Wolfgang: oder so diese ganze Analytics-Geschichte kam ganz viel dazu und du hast immer

Wolfgang: mehr Spezialisierung gebraucht.

Wolfgang: Und das macht halt alles generell viel, viel, viel komplexer.

Wolfgang: Und Security ist halt auch ein Thema. Aber letztendlich brauchst du halt,

Wolfgang: wenn du eine gewisse Komplexität in deinem Produkt hast, dedizierte Leute,

Wolfgang: die sich damit auskennen.

Wolfgang: Weil wenn du halt einfach deine fünf Leute im Entwicklungsteam hast,

Wolfgang: es ist auch ein bisschen utopisch, finde ich, dass dann halt jede Person alles wissen muss.

Wolfgang: Das ist schwierig. Ich kenne mich jetzt vielleicht voll gut mit Backend-Entwicklung aus.

Wolfgang: Ich kenne mich jetzt aber auch noch mit KI aus. Ich kenne mich mit Security

Wolfgang: aus. Ich kenne mich mit Kubernetes aus.

Wolfgang: Also irgendwann finde ich es halt auch mal so dieses mentale Limit irgendwo

Wolfgang: erreicht, dass du nur noch oberflächlich irgendwo drin stecken kannst.

Clemens: Absolut.

Wolfgang: Und das ist praktisch, dass man natürlich so Experten hat wie dich.

Wolfgang: Du bist ja Security Software Engineer, wenn ich es mal richtig gemerkt habe.

Clemens: Andersrum.

Wolfgang: Software Security Engineer oder Engineer Security Software?

Clemens: Wir nehmen alles.

Wolfgang: Du bist letztendlich drei in eins. Du bist Engineer, du bist Software-Profi und Security-Profi.

Wolfgang: Also das ist wie eine Kinderüberraschung, aber in der Softwareentwicklung.

Wolfgang: Und Clemens, wenn ich dich heute schon hier habe und wir dieses spannende Thema

Wolfgang: da haben, da würde ich gerne mal mit dir so exemplarisch ein bisschen drüber

Wolfgang: sprechen, was du eigentlich beruflich machst.

Wolfgang: Wenn du jetzt Unternehmen oder Kunden von uns berätst und zwar darin,

Wolfgang: wie man jetzt so diese Sicherheit reinbekommt ins Produkt,

Wolfgang: vor allem auch im Hinblick auf solche Sachen wie jetzt NIST 2 oder diesen CAA.

Clemens: Ja, sehr gerne. Vielleicht machen wir das mal an einem ganz konkreten Beispiel

Clemens: von einem Unternehmen, das mich vor zwei Jahren oder so her haben die mich kontaktiert.

Clemens: Die haben mich irgendwie auf ein Meetup sprechen gehört. Da habe ich über ein

Clemens: Tool gesprochen, ein Testing-Tool für Security und meinten, sie würden das gerne einbauen.

Clemens: Sie haben aber noch so ein paar Fragen, ob ich sie dabei beraten kann.

Clemens: Dann habe ich gesagt, ja klar, finde ich ein gutes Tool.

Clemens: Ich komme mal vorbei. Und dann haben wir uns mal hingesetzt und haben darüber

Clemens: gesprochen und ich habe so gesehen, ja,

Clemens: das Tool wäre schon sinnvoll, aber sie haben so ein paar andere Hürden noch

Clemens: in ihrer Entwicklung generell, die es irgendwie schwierig macht,

Clemens: das irgendwie zum Beispiel in eine Pipeline einzubauen, weil die Pipelines schon

Clemens: irgendwie nicht so sinnvoll laufen. Oder,

Clemens: Produkt gar nicht so gut testbar ist. Und dann sind wir da so ein bisschen weiter

Clemens: drüber gegangen, haben so über verschiedene Sachen gesprochen und dann habe

Clemens: ich mal so die Frage gestellt, wollen wir mal einen Schritt zurücktreten und

Clemens: uns quasi mal so den Entwicklungsprozess generell anschauen?

Clemens: Wo steht der denn da Security-technisch?

Clemens: Und da haben sie sich dann drauf eingelassen und wir haben das nach so einem

Clemens: Reifegrad-Modell, das ich ganz wertvoll finde, Ovaspsum.

Clemens: Gemacht und dieses Reifegrad-Modell, das gibt einem eben die Möglichkeit,

Clemens: so die eigenen Softwareentwicklungsprozesse in verschiedene Reifegrade einzuteilen.

Clemens: Und das haben wir mal gemacht und haben uns eben angeschaut,

Clemens: wo stehen wir denn in den verschiedenen Sachen, wo stehen wir beim Design der

Clemens: Software, wo stehen wir beim Testen der Software, wo stehen wir beim eigentlichen Coding,

Clemens: wo stehen wir beim Betrieb und haben da mal so einen Überblick gewonnen und

Clemens: haben dann zum Beispiel gesehen, naja, vielleicht ist das Testen von der Software

Clemens: gerade gar nicht das dringlichste Problem, weil wir haben da schon so ein paar

Clemens: andere Maßnahmen, auf die konzentrieren wir uns mal, dieses neue Tool,

Clemens: vielleicht brauchen wir das gerade gar nicht.

Clemens: Spoiler, wir haben es immer noch nicht erfolgreich in allen Produkten eingesetzt,

Clemens: weil andere Sachen wichtiger waren.

Clemens: Sondern uns ist zum Beispiel wichtiger, dass wir zum Beispiel erstmal Threat

Clemens: Modeling in allen Teams etablieren.

Clemens: Dass wir erstmal ein Bewusstsein schaffen in den Teams, dass wir Trainings machen,

Clemens: dass wir uns überlegen, was haben wir eigentlich für einen Schutzbedarf,

Clemens: was haben wir für Anforderungen an die Security.

Clemens: Solche Sachen waren zum Beispiel erstmal wichtiger. Und dann haben wir es eben

Clemens: geschafft von so einer grundsätzlichen Idee, die ja richtig war,

Clemens: die auch gut war, so ein Tool einzubauen, eben so den,

Clemens: einen ganzheitlicheren Überblick zu gewinnen und uns dann eben eine Roadmap

Clemens: zu überlegen, wie können wir von hier aus jetzt weitermachen,

Clemens: was sind die nächsten Schritte, wen brauchen wir dafür, welche Beteiligten gibt es dabei,

Clemens: und arbeiten von da an jetzt eben weiter daran.

Wolfgang: Das heißt, das war erstmal so eine Art Bestandsaufnahme und gleichzeitig aber

Wolfgang: auch so eine Art Sensibilisierung für das Thema.

Clemens: Ja, Sensibilisierung jetzt zumindest

Clemens: mit den Menschen, mit denen ich diese Bestandsaufnahme gemacht habe.

Clemens: Das war jetzt in dem Fall quasi so der Abteilungsleiter und auch so der Security

Clemens: verantwortlich von dieser Abteilung.

Clemens: Die haben so eine Handvoll von Teams, die alle irgendwie Web-Anwendungen bauen

Clemens: und die waren an sich schon sensibilisiert.

Clemens: Aber die haben damit halt auch nochmal so die Bandbreite der Möglichkeiten und

Clemens: der Notwendigkeiten auch gesehen und haben da auch nochmal so ein Gefühl dafür

Clemens: bekommen, wo stehen wir denn eigentlich in unterschiedlichen Bereichen?

Clemens: Wo kriegen wir vielleicht schnell Verbesserungen erzielt und wo ist es schwieriger?

Clemens: Und dann war der zweite Schritt, das auch eben entsprechend die Teams zu tragen,

Clemens: die zu sensibilisieren.

Clemens: Wir haben da auch Trainings gehalten, wir haben da Workshops gemacht,

Clemens: wir unterstützen die bei verschiedenen Implementierungsfragen beim Betrieb und

Clemens: konnten da dann eben so an verschiedenen Punkten ansetzen.

Clemens: Weil was du vorhin gesagt hast, ist natürlich auch absolut richtig,

Clemens: der einzelne Entwickler, die einzelne Entwicklerin,

Clemens: die kann sich nicht um alles kümmern, deswegen ist jetzt Trainings und Awareness

Clemens: auch nicht das Allheilmittel, mit dem man alles löst, sondern man muss sich

Clemens: halt zum Beispiel auch darum kümmern,

Clemens: hat man überhaupt die Prozesse, die es den Menschen möglich machen.

Clemens: Sich möglichst leichtgewichtig mit Security zu beschäftigen und dass die Prozesse

Clemens: ihnen überhaupt ermöglichen, Security richtig zu machen.

Clemens: Oder die passenden Tools einsetzen, damit sie das möglichst automatisiert machen

Clemens: können oder Funktionen zentral zur Verfügung zu stellen,

Clemens: Beratung zentral zur Verfügung zu stellen, damit man das eben nicht in jedem

Clemens: einzelnen Produkt oder noch schlimmer in jedem einzelnen Kopf machen muss.

Wolfgang: Hast du da ein Beispiel für diese Prozessthematik? Ich kann das noch nicht so

Wolfgang: hundertprozentig greifen.

Clemens: Also ein Beispiel war da zum Beispiel, wie gehen wir mit unserer Supply Chain Security um.

Clemens: Also wir haben Web-Anwendungen, da sind ein Haufen Abhängigkeiten drinnen und ein Riesenthema,

Clemens: das kennt man ja auch aus den einschlägigen Medien, sind halt Angriffe über

Clemens: irgendwelche Libraries, die gehackt wurden oder die Schwachstellen haben.

Clemens: Ich glaube, die meisten erinnern sich, wo sie waren, als Log4Shell zum Beispiel

Clemens: damals war. Das war so ein einschneidendes Erlebnis.

Clemens: Und das ist eben auch so ein Punkt, mit dem man sich systematisch beschäftigen kann.

Clemens: Was können wir denn an Tools zur Verfügung stellen, damit man eben nicht jeden

Clemens: Tag Händelstückte-Dependencies durchgehen muss, sondern das irgendwie in einem

Clemens: einheitlichen Tool sehen kann.

Clemens: Wie schaffen wir es da, irgendwie eine Kontinuität reinzubringen,

Clemens: dass man sich da regelmäßig mit beschäftigt?

Clemens: Wie schaffen wir es, dass wir die Updates sinnvoll machen können,

Clemens: dass man vielleicht nicht erst, wenn eine Lücke kommt, auf die nächste Version

Clemens: hochgeht und dann auf einmal irgendwie zwei Majors überspringen muss,

Clemens: sondern da kontinuierlich dran arbeitet,

Clemens: da die Prozesse und die Tool-Unterstützung hat, damit das geht.

Clemens: Das ist zum Beispiel so ein Beispiel, wo man von der einzelnen Verantwortung

Clemens: eines Entwicklers oder eines Teams hingehen möchte, dass man eben übergreifende

Clemens: Lösungen und Prozesse anbietet.

Wolfgang: Ja, das finde ich gut. Das Problem ist halt immer, wenn so eine Sache in einer

Wolfgang: Person hängt, dann hast du halt immer auch so ein Nadelöhr einfach.

Wolfgang: Weil die eine Person ist vielleicht nicht da, die eine Person kündigt vielleicht,

Wolfgang: die eine Person hat vielleicht aber auch im Alltag super viel Stress.

Wolfgang: Und wenn du super viel Stress hast, was leider immer mal vorkommt,

Wolfgang: dann fällt ja immer irgendwas hinten runter.

Wolfgang: Und leider sind es ja oft die Dinge, wo man nicht so ganz direkt für den Alltag braucht.

Wolfgang: Vielleicht sowas wie Security-Checks oder Dokumentation oder andere Dinge,

Wolfgang: die man halt später noch machen kann.

Wolfgang: Und wenn es halt an einer Person hängt, ja, das hast du halt immer das Problem,

Wolfgang: also so Automatisierung, dass man solche Libraries automatisch durchprüft,

Wolfgang: irgendwie einmal pro Tag, das ist natürlich eine praktische Sache dann.

Wolfgang: Und diese Schulung und Weiterbildung, die du da auch anbietest oder auch durchführst,

Wolfgang: wie wird denn da dann bei den Leuten so eine Awareness geschaffen für das Thema? Genau.

Clemens: Das machen wir je nach konkreter Zielgruppe.

Clemens: Also wir haben Trainings, die jetzt wirklich rein auf Awareness abzielen.

Clemens: Die sind dann zum Beispiel auch für Product Owner oder für fachliche Verantwortliche

Clemens: irgendwie geeignet, damit die überhaupt mal ein Gefühl bekommen,

Clemens: warum machen wir das eigentlich? Was hat das für eine Bedeutung?

Clemens: Was bedeutet Security für uns? auch ein gemeinsames Verständnis schaffen,

Clemens: was wollen wir eigentlich schützen, was hat das für einen Wert für uns,

Clemens: wenn wir uns mit diesen Themen beschäftigen.

Clemens: Aber wir haben auch wirklich technische Trainings gemacht mit den EntwicklerInnen,

Clemens: wo es darum geht, wie können wir denn jetzt in dieser Sprache genau sicher entwickeln,

Clemens: was sind denn da Schwachstellen, auf die wir achten müssen.

Clemens: Wir haben Trainings gemacht zum Testen auf Security, was gibt es da für Tools,

Clemens: was gibt es auch für manuelle Möglichkeiten oder halbautomatische Möglichkeiten,

Clemens: das zu machen. wie greifen die ineinander?

Clemens: Oder wir haben auch so Workshops zu Threat Modeling zum Beispiel gemacht.

Clemens: Da haben wir ja auch schon mal im Podcast drüber gesprochen.

Clemens: Wer da tiefer reingehen möchte, der sei die Folge empfohlen.

Clemens: Aber ein wichtiges Thema beim Threat Modeling ist halt eben das,

Clemens: was kann denn genau schief gehen?

Clemens: Und da tun sich halt EntwicklerInnen gerade am Anfang oft schwer.

Clemens: Deswegen hilft es da, wenn man da eben einen Experten, eine Expertin dabei hat,

Clemens: die solche Workshops dann eben anleitet.

Clemens: Auch das haben wir da gemacht.

Wolfgang: Ja, macht ihr wahrscheinlich dann auch solche so Praxisbeispiele, oder?

Clemens: Genau, also gerade bei den technischen Trainings versuchen wir halt,

Clemens: dass die Leute auch mal selber hacken dürfen, dass sie verstehen,

Clemens: was diese Schwachstelle jetzt genau bedeutet, wie man sie ausnutzt.

Clemens: Und da gibt es dann auch immer wieder so Aha-Effekte, wo man dann denkt,

Clemens: ah, das muss ich jetzt bei uns aber auch mal ausprobieren, ob das da eigentlich.

Wolfgang: Also dann lernt man auch, dass es so keine gute Idee ist, irgendwelche vom User

Wolfgang: eingegebenen Strings direkt in so ein SQL-Statement reinzustecken.

Wolfgang: Ganz genau. Die Klassiker.

Wolfgang: Ja, sehr, sehr spannend. Ich könnte mir vorstellen, dass das dann aber auch

Wolfgang: eine ganz spannende Argumentationsgrundlage für den Entwicklungsalltag ist und

Wolfgang: zwar im Hinblick auf so Aufwendet, die es gibt.

Wolfgang: Ich kenne das aus Projekten aus der Vergangenheit, dass oftmals so die Diskussion

Wolfgang: zwischen so einem Entwicklungsteam und zwischen den Product Ownern,

Wolfgang: was so Aufwände angeht, teilweise schwierig war, weil so jetzt ganz vereinfacht

Wolfgang: und auch sehr Stereotyp möchte halt so der Product Owner alles sehr billig haben, mit wenig Aufwand.

Wolfgang: Und das Team möchte dann vielleicht hier noch eine Dokumentation schreiben und

Wolfgang: Testing und jetzt vielleicht zusätzlich noch sich Gedanken über Security machen

Wolfgang: und vielleicht zusätzlich noch so ein bisschen Threat Modeling machen,

Wolfgang: was ja alles Zeit kostet, alles gut investiert.

Wolfgang: Aber ich habe in der Vergangenheit oft erlebt, dass das teilweise schwierig

Wolfgang: ist in so einer Argumentation,

Wolfgang: weil vielleicht jemand aus dem PO-Spektrum da nicht das Verständnis hat im Detail

Wolfgang: für solche eher technischen Dinge, sondern eher so die Brille vielleicht auf

Wolfgang: hat und dann so sagt, ja, die Software soll halt gut sein.

Wolfgang: Und warum müsst ihr jetzt vielleicht noch zusätzlich das und das und das machen?

Wolfgang: Ihr seid doch alle sehr erfahrene Leute hier im Bereich der Softwareentwicklung.

Wolfgang: Helfen da solche Workshops, um hier die Leute so ein bisschen aufs gleiche Level

Wolfgang: zu bringen und vielleicht beiden so oder als beiden Gruppen von Menschen so

Wolfgang: das Verständnis so ein bisschen näher zusammenzubringen?

Clemens: Ja, also ich glaube, die Beobachtung ist sehr richtig. Genau,

Clemens: dass es da irgendwie auf den ersten Blick unterschiedliche Erwartungen an eine Software gibt.

Clemens: Aber was du auch sagst, der Product Owner will gute Software.

Clemens: Genau das wollen die Entwickler ja auch. Sie haben nur einfach unterschiedliche

Clemens: Vorstellungen, was genau gut jetzt bedeutet.

Clemens: Und da ist es dann eben genau hilfreich, wenn man irgendwie so ein gemeinsames

Clemens: Verständnis schafft in Trainings. Es ist aber auch hilfreich,

Clemens: zum Beispiel wenn man durch eine externe Instanz ein bisschen vorgegeben bekommt,

Clemens: was dieses Gut bedeutet.

Clemens: Und da sind wir dann zum Beispiel wieder beim CAA, dass der halt jetzt eben

Clemens: so eine Baseline setzt, wo man eben nicht drunter fallen darf,

Clemens: was eben als gute, als sichere Software angesehen wird.

Clemens: Das heißt, ich hoffe da auch so ein bisschen auf eine Argumentationsgrundlage

Clemens: für Entwicklende, aber auch für alle anderen, die eben schon jetzt das Bewusstsein

Clemens: haben, dass das eben hilft, dabei die Notwendigkeit von solchen Security-Maßnahmen durchzuführen.

Wolfgang: Was steht denn da so drin im CA? Hast du da zwei, drei Beispiele vielleicht,

Wolfgang: was da für Baselines drin sind? Also eine Sache habe ich vorhin schon gesagt.

Clemens: Dass man sich irgendwie um Schwachstellenfreiheit kümmern muss und auch insgesamt

Clemens: so ein Schwachstellenmanagement haben muss, also sich damit auseinandersetzen muss.

Clemens: Was habe ich denn für Schwachstellen in meinem Produkt? Zum Beispiel auch so

Clemens: transitive Abhängigkeiten, also transitive Schwachstellen in meinen Abhängigkeiten und so.

Clemens: Geht aber auch so darum, dass man sich halt grundsätzlich mal Gedanken macht,

Clemens: Was habe ich denn für Risiken, für IT-Security-Risiken in meinem Produkt?

Clemens: Also was dann auch wieder so in die Threat-Modeling-Richtung geht.

Clemens: Gegen was muss ich mich genau schützen? Das ist meine Angriffsoberfläche.

Clemens: Das sind so zwei Beispiele, die der Cyber Resilience Act zum Beispiel fordert.

Wolfgang: Und das wären jetzt aber auch Themen, wo du jetzt quasi bei Kunden halt einfach

Wolfgang: mithilfst, um jetzt so eine Analyse auch durchzuführen mit den Kunden.

Clemens: Genau, das sind Sachen, die haben wir auch vor dem Cyber Resilience Act schon als sinnvoll erachtet.

Clemens: Und das würde ich auch allen Unternehmen, die jetzt vom Cyber Resilience Act

Clemens: nicht direkt betroffen sind, empfehlen, dass sie sich mit sowas beschäftigen

Clemens: und was zum Beispiel auch das Reifegrad-Modell, mit dem ich da gerne arbeite,

Clemens: vorschlägt in den verschiedenen Levels, dass man sich eben um solche Sachen auch Gedanken macht.

Wolfgang: Wo ist für dich so der Unterschied, wenn du auf der einen Seite jetzt vielleicht

Wolfgang: jemanden begleitest bei einem ganz neuen Projekt, also so richtig Greenfield,

Wolfgang: wir haben eine Vision im Kopf, aber wir haben noch keine Zeile Code geschrieben versus,

Wolfgang: oh, wir haben ja schon was gut abgehangen, entwickeln hier schon seit sieben

Wolfgang: Jahren an unserem Produkt, das ist auf dem Markt, das ist etabliert,

Wolfgang: aber Security, da haben wir jetzt vielleicht noch nicht explizit so extrem viel gemacht.

Wolfgang: Aber hey, jetzt kommen diese neuen Acts, da müssen wir fit dafür sein.

Clemens: Ja,

Clemens: bei einem bestehenden Projekt geht es natürlich erst mal um eine Bestandsaufnahme.

Clemens: Da muss man natürlich erst mal schauen, wo stehen wir gerade schon,

Clemens: was haben wir schon, was brauchen wir noch, was ist die Roadmap für die nächsten Schritte.

Clemens: Das kann man sich bei einem neuen Projekt natürlich sparen.

Clemens: Es ist allerdings tatsächlich selten, dass das Security von Anfang an so wirklich

Clemens: als First Class in Projekten benutzt wird. Also das heißt meistens,

Clemens: dass man doch eher in dem, wir haben schon irgendwas und lass mal hier dran,

Clemens: dran aufsetzen. Und das ist ja auch okay.

Clemens: Also es gibt gewisse Sachen, die sind deutlich leichter, wenn man sie von Anfang an bedenkt.

Clemens: Und da kann ich auch nur empfehlen, dass man das macht.

Clemens: Es gibt aber auch sicher Sachen, die, das ist völlig okay, wenn man das erst

Clemens: quasi macht, wenn man den MVP schon abgeschlossen hat.

Clemens: Dann danach drauf aufbaut. Was sich für mich in den letzten Jahren auch immer

Clemens: mehr herausstellt, ist halt, dass es hilft, wenn man so diese Produktebene oder

Clemens: die konkrete Anwendungsebene verlässt und meine Ebene höher schaut.

Clemens: Und das ist das, was ich auch gerne versuche eben bei Kunden zu machen,

Clemens: dass man eben schaut, okay, wir haben jetzt hier eine einzelne Anwendung,

Clemens: da könnte man jetzt ein Pentest machen oder ein Audit machen oder sich anschauen,

Clemens: was da bisher schon an Dokumentationen existiert.

Clemens: Nachhaltiger ist es aber halt, wenn man eine Ebene drüber schaut,

Clemens: wenn das ein Unternehmen ist, das eben nicht nur diese eine Software entwickelt,

Clemens: sondern vielleicht mehrere.

Clemens: Was kann man denn da einheitlich regeln? Was haben wir denn an einheitlichen Vorgaben?

Clemens: Was haben wir an einheitlichen Einschränkungen, die vielleicht die Teams zurzeit

Clemens: daran hindern, sichere Software zu machen?

Clemens: Also so ein bisschen mehr auf eine Organisation zu schauen, wo man die Möglichkeit hat,

Clemens: eben auch auf einer übergreifenden Tool-Ebene, an übergreifenden Services,

Clemens: an übergreifenden Prozessen, auch an Rahmenbedingungen, an Leitlinien,

Clemens: die man vorgibt, damit sich eben nicht jedes Team selber wieder überlegen muss,

Clemens: was heißt denn jetzt eigentlich genau, sichere Softwareentwicklung,

Clemens: was müssen wir denn da jetzt alles machen,

Clemens: dass man das halt versucht irgendwie zentral zu regeln, vorzugeben,

Clemens: einfach um auch diesen Mental Load von den einzelnen Teams zu nehmen.

Clemens: Das finde ich gerade sehr, sehr wichtig und sehr spannend.

Wolfgang: Gibt es deiner Erfahrung nach auch so Fälle, die sehr verzwickt sind,

Wolfgang: wo man sagen könnte, huiuiui, da gibt es aber noch viel zu tun?

Clemens: Ja, am Ende ist das immer dann der Fall, wenn aus irgendwelchen technischen

Clemens: oder prozessualen Fragen kulturelle Fragen werden.

Clemens: Und da kannst du mir bestimmt auch beipflichten, da bist du ja auch Experte von,

Clemens: irgendwie eine Unternehmenskultur zu verstehen und zu verändern,

Clemens: das ist nochmal ein deutlich schwieriges Unterfangen, als jetzt einfach nur

Clemens: ein neues Tool einzuführen.

Clemens: Aber es hängt natürlich irgendwie zusammen.

Clemens: Und am Ende lassen sich viele so übergreifende Security-Fragestellungen und

Clemens: Prozesse halt nur einführen, wenn man auch die entsprechende Kultur versteht

Clemens: und es damit ermöglicht.

Clemens: Alignt und in Einklang bringt.

Wolfgang: Ja, absolut. Also ich sage es immer wieder gerne. Ich habe noch nie erlebt,

Wolfgang: dass ein Projekt gescheitert ist, weil die Technologie zu schlecht war oder nicht ausreichend war.

Wolfgang: Ich habe aber schon einige Projekte beim Scheitern, das hätte ich fast gesagt

Wolfgang: begleitet, erlebt, weil es eben kulturell nicht funktioniert hat oder halt einfach

Wolfgang: im Miteinander nicht funktioniert hat.

Wolfgang: Und ich finde im gesamten Bereich Softwareentwicklung, Auch wenn wir heute immer

Wolfgang: ganz viel über KIs sprechen, ist der menschliche Faktor immer noch der entscheidende

Wolfgang: und gerade so dieses Kulturelle.

Wolfgang: Und das stelle ich mir auch sehr, sehr interessant vor, denn du kannst ein Audit

Wolfgang: machen, du kannst in der Build-Pipeline noch ein paar Module irgendwie reinklickern,

Wolfgang: die jetzt so deine ganzen Libraries scannen.

Wolfgang: Du kannst irgendwie noch vielleicht eine statische Code-Analyse einbauen und

Wolfgang: noch viele, viele andere Dinge tun, um hier wirklich Fakten zu generieren und

Wolfgang: auch vielleicht ganz numerisch sicherzustellen, dass hier gewisse Dinge erfüllt werden.

Wolfgang: Aber so der kulturelle Wandel, vor allem wenn du jetzt vielleicht schon eher

Wolfgang: eine sehr gesetzte Entwicklungstruppe hast irgendwie,

Wolfgang: die vielleicht auch nicht so den Sinn erkennt, diese Leute zu motivieren und

Wolfgang: so weit zu bringen, dass sie das gut finden,

Wolfgang: das stelle ich mal schon als eine Herausforderung im Einzelfall vor.

Clemens: Und deswegen ist es halt auch so schwierig, wenn man jetzt irgendwelche CAA-Checklisten

Clemens: nimmt und sagt, die nutzen wir jetzt und dann erfüllen wir das.

Clemens: Man muss halt immer schauen, wie genau kann man das jetzt für die eigene Kultur

Clemens: und das eigene Entwicklungsgefüge passend umsetzen.

Clemens: Und bei einem Unternehmen, wo man vielleicht sehr prozessual getrieben arbeitet

Clemens: und top-down irgendwie vorgibt, wie was zu tun ist, Da muss man Sachen halt

Clemens: einfach ganz anders regeln als bei Teams, die super selbstorganisiert sind,

Clemens: es gewohnt sind, dass sie eigentlich alles so machen dürfen,

Clemens: wie sie wollen, wo man ihnen halt einfach losere Leitplanken,

Clemens: die sie vielleicht mitbestimmen dürfen, geben muss oder einfach nur Tools zur

Clemens: Verfügung stellt, die sie nutzen können.

Clemens: Wenn sie aber eigene Tools nutzen wollen, die das gleiche Ziel verfolgen,

Clemens: dann ist das vielleicht auch okay.

Clemens: So muss man halt immer für jede Organisation die passenden Maßnahmen finden.

Wolfgang: Ja, also Checklisten an sich finde ich großartig. Ich nutze auch privat sehr viele Checklisten.

Wolfgang: Ich finde aber, eine Checkliste kann nur dann richtig gut funktionieren, wenn du sie verstehst.

Wolfgang: Wenn du nicht nur drauf siehst, was für Items sind und ich hake die jetzt ab,

Wolfgang: sondern wenn du verstehst, warum die Sachen da draufstehen, dann ist eine Checkliste

Wolfgang: wirklich, wirklich großartig.

Wolfgang: Vor allem so im fortgeschrittenen Alter, ich gucke jetzt eher mich an,

Wolfgang: da vergisst man auch mal gerne was, also da gucke ich auch mich selbst an und

Wolfgang: da bin ich ganz froh, wenn es auf der Checkliste drauf ist,

Wolfgang: aber ich hatte auch Projekte, da standen dann so Sachen auf der Checkliste wie

Wolfgang: es muss Dokumentation geben und du brauchst eine Testabdeckung von 80% und da

Wolfgang: haben Leute dann halt Tests geschrieben für so Getter und Setter,

Wolfgang: was da komplett sinnlos war,

Wolfgang: aber die Testabdeckung war immer schön weit oben und in den Projekten war das

Wolfgang: Management auch super happy, weil man irgendwie mal gehört hat,

Wolfgang: dass es gut ist, wenn es 80% ist. Warum auch immer.

Wolfgang: Und ich glaube, da ist halt so das Verständnis wichtig. Machst du da in deiner

Wolfgang: Arbeit auch in dem Bereich irgendwas, also in diesem kulturellen Bereich?

Clemens: Zwangsläufig immer so ein bisschen. Leider halt ohne, dass ich da der große

Clemens: Experte bin oder dass ich da halt irgendwie die theoretischen Backgrounds so gut kenne.

Clemens: Das lerne ich dann immer so on the fly oder tausche mich da mit Leuten aus,

Clemens: die da vielleicht schon mehr gemacht haben. Aber ich merke immer mehr,

Clemens: dass das nicht voneinander zu trennen ist und dass das immer miteinander zu tun hat.

Clemens: Also gerade wenn man jetzt eben nicht auf einer einzelnen Zeile Code irgendwie

Clemens: sicherstellen möchte, dass jetzt hier kein Cross-Site-Scripting ist,

Clemens: sondern man eben auf eine Team-Ebene, auf eine Organisationsebene gehen möchte,

Clemens: dann muss man das eigentlich gemeinsam denken und dann kriegt man da mit der

Clemens: Zeit auch so ein bisschen Gespür dafür,

Clemens: wie man die Teams hier mitnehmen muss.

Clemens: Entwickler, Entwicklerinnen sind ja meistens einfach zu schlau,

Clemens: wenn man ihnen was vorschreibt, was sie nicht mögen und nicht verstehen,

Clemens: dann finden sie immer einen Weg drum rum.

Clemens: Das heißt, da viel zu erklären und zu verstehen, warum jetzt vielleicht was

Clemens: gerade für die wirklich nicht so gut funktioniert, da hilft es mir halt auch,

Clemens: dass ich aus einer Entwicklungsvergangenheit komme, selber irgendwie entwickelt habe.

Clemens: Ja, das gehört da auf jeden Fall zusammen.

Wolfgang: Ja, und ich finde, hier passt halt so dieser ein ganz ursprüngliches Scrum-Gedanke

Wolfgang: irgendwie rein, denn ganz ursprünglich hat man ja mal gedacht,

Wolfgang: es wäre großartig, wenn man ein Team hat und in dem Team sind alle Leute drin, die was beitragen.

Wolfgang: Also nicht nur die Leute, die jetzt irgendwie Code schreiben,

Wolfgang: sondern vielleicht auch noch die Kollegin aus dem Sales-Team,

Wolfgang: der Kollege aus dem Marketing, sodass alle Leute, die irgendwas beitragen,

Wolfgang: quasi so zusammen im Büro sitzen und sich laufend auch austauschen können und

Wolfgang: auch gemeinsam so dieses,

Wolfgang: Verständnis entwickeln können, weil ich glaube, letztendlich ist es doch genau das.

Wolfgang: Also was so Abkürzungen angeht, was du gerade erwähnt hast, bin ich auch sehr, sehr gut drin.

Wolfgang: Also wenn mir was keinen Spaß gemacht hat, ich habe immer versucht oder einen

Wolfgang: Weg gefunden, den man jetzt vielleicht irgendwie umschiffen kann, elegant.

Wolfgang: Aber ich glaube, der Punkt ist halt echt dieses Verständnis.

Wolfgang: Wenn ich wirklich das Verständnis habe, hey, ich entwickle hier ein cooles Produkt

Wolfgang: und ich möchte, dass das einfach super gut ist in jedem Aspekt.

Wolfgang: Ich möchte, dass du schnell bist und ich möchte, dass du sicher bist und dass

Wolfgang: es eine coole Dokumentation hat, weil die wichtig ist, dann gehe ich da halt

Wolfgang: auch mit einem ganz anderen, wie sagt man das so schön, Mindset dran. Guter Begriff, ja.

Wolfgang: Aber letztendlich ist es das. Ich finde, wenn ich zur Arbeit gehe und ich verstehe

Wolfgang: meine Arbeit als, oh, ich kann jetzt heute acht Stunden lang irgendwie Code

Wolfgang: schreiben und mir ist es egal, was damit passiert.

Wolfgang: Ich achte halt darauf, dass mein Code gut ist nach meinem eigenen Standard.

Wolfgang: Das ist halt nochmal was anderes, wie wenn ich halt wirklich so den Blick fürs

Wolfgang: Ganze habe und sage, mit meinen Leuten im Team hier mache ich was Cooles irgendwie.

Wolfgang: Und das ist die hohe Kunst, glaube ich.

Wolfgang: Ich glaube, wenn wir da nochmal so bei dem Thema Europa sind,

Wolfgang: da hatten wir vorhin schon drüber gesprochen.

Wolfgang: Ich glaube, da haben wir bei uns vielleicht auch noch so den Vorteil,

Wolfgang: dass wir nicht so eine krasse Higher-and-Fire-Kultur bei uns in der Branche

Wolfgang: haben, wie man es aktuell in den USA sieht, wo dann auch Leute entlassen werden,

Wolfgang: wo es dann in großen Unternehmen auch momentan so Scorings gibt, wo gesagt wird,

Wolfgang: okay, schau mal, das ist deine Leistung.

Wolfgang: Wenn du jetzt noch bis zum nächsten Monat hier ein paar Punkte mehr erreichst

Wolfgang: durch irgendwas, was du tust, dann bleibst du bei uns, ansonsten wirst du entlassen.

Wolfgang: Ich glaube, da ist die Motivation nochmal eine ganz andere einfach.

Clemens: Ja, total. Also, ja, kann man auch nur schwer vorstellen oder ausmalen,

Clemens: wenn man das auf Security übertragen möchte.

Clemens: Ja, fände ich eine ganz gefährliche Idee, wenn man jetzt irgendwie Schwachstellen

Clemens: pro Mitarbeiter irgendwie zählt und dann versucht, da herauszufinden,

Clemens: wer jetzt sicher einen Code schreibt oder nicht. Ich glaube,

Clemens: das führt auch in die falsche Richtung.

Wolfgang: Absolut, ja. Ja. Wenn man jetzt irgendeinen digitalen Service anbietet,

Wolfgang: ein digitales Produkt und vielleicht das Thema Security bisher stiefmütterlich behandelt hat.

Wolfgang: Und ich kann mir vorstellen, dass das bei vielen Unternehmen der Fall ist,

Wolfgang: weil es vielleicht ein Thema ist, was einzelne Leute im Team einfach so vielleicht

Wolfgang: mitgetragen haben. Leute, die sich dafür interessieren, so wie du ja auch.

Wolfgang: Du hast dich da auch schon immer so dafür interessiert und hast in deinen Projekten

Wolfgang: ja auch immer so aus Eigeninitiative oder aus Lust daran einfach so ein bisschen gepusht.

Wolfgang: Aber wenn man da noch nicht wirklich systematisch mit unterwegs ist und jetzt

Wolfgang: auch mal drüber nachdenkt, hui, 2027 gibt es diese neuen Regularien, ich muss da fit werden.

Wolfgang: Ich meine, die einfachste Idee wäre natürlich jetzt, dich anzurufen und sagen,

Wolfgang: hey, servus Clemens, Kannst du mal kurz vorbeikommen und uns da mal auf Herz

Wolfgang: und Nieren untersuchen und vielleicht mal so ein Security-TÜV bei uns machen

Wolfgang: und mal gucken, ob wir da eine Plakette bekommen?

Clemens: Könnte klappen, ja.

Wolfgang: Kannst du offiziell so Plaketten ausstellen?

Clemens: Ich klebe überall was drauf, wenn es gewünscht ist.

Clemens: Also das machen wir natürlich nicht. Also irgendwie zertifizieren machen wir

Clemens: nicht. Ist aber auch nicht nötig an der Stelle.

Clemens: Genau, also das bieten wir tatsächlich an, dass wir halt solche Assessments

Clemens: machen, dass wir uns die Prozesse anschauen.

Clemens: Jetzt natürlich aktuell auch vor dem Hintergrund CAA, aber wie ich schon gesagt

Clemens: habe, ist auch so sinnvoll und wertvoll.

Clemens: Und ich würde das auch nicht darauf beschränken, eben auf diese reine Konformität

Clemens: und Compliance da, sondern mir schauen, wo habe ich vielleicht sonst noch Stellen,

Clemens: wo es werthaltig ist, wenn ich mich mit beschäftige.

Clemens: Und dann ist eben das Wichtige, dass man nicht nur so eine Ist-Aufnahme macht,

Clemens: sondern was wir dann auch immer gleich machen, halt eine Roadmap.

Clemens: Also was sind jetzt die konkreten Sachen? Was brauchen wir dafür?

Clemens: Was ist eine grobe Zeitleiste? Wen müssen wir damit an Bord holen?

Clemens: Was sind die nächsten Schritte, die ihr machen müsst, damit ihr hier vorbeizutzt?

Wolfgang: Wie funktioniert sowas in der Praxis? Ist das so ein Tagesseminar oder Workshop

Wolfgang: oder ist das was Längerfristiges, eine längerefristige Begleitung?

Clemens: Also das grundsätzliche Assessment, das machen wir in so einem nicht ganz Tagesworkshop,

Clemens: je nachdem wie umfangreich die Organisation ist, die man sich anschauen muss,

Clemens: so vier, fünf Stunden lang da normalerweise, wo man sich eben die unterschiedlichen

Clemens: Felder der Softwareentwicklung anschaut und überlegt, was haben wir hier schon, was wäre noch sinnvoll.

Clemens: Da ist eben dieses Greifegrad-Modell ganz wertvoll für, weil es da gleich so

Clemens: einen standardisierten Rahmen gibt, mit dem man auch ganz gut gegenüber anderen

Clemens: argumentieren kann, warum das jetzt ein guter Rahmen ist.

Clemens: Und von dem Ausgehen man dann eben ableiten kann, was sind die nächsten Schritte.

Clemens: Das ist dann erstmal so das Assessment und das Ergebnis des Assessments.

Clemens: Und dann je nachdem, wie fit die Unternehmen sind und wo sie nochmal genau Unterstützung

Clemens: brauchen, ob das eher im Schulungsbereich ist oder jetzt eben beim Formulieren

Clemens: von irgendwelchen Prozessen oder beim Einführen von Tools oder so,

Clemens: unterstützen wir dann auch längerfristig, wenn es gewünscht ist,

Clemens: damit wir dann da eben eine kontinuierliche Entwicklung haben und die Prozesse

Clemens: dann nachhaltig verbessern.

Wolfgang: Hast du vielleicht noch ein paar so Low-Hanging-Fruits für alle da draußen,

Wolfgang: mit denen man so generell das Bewusstsein für Security oder generell die Security

Wolfgang: in der Softwareentwicklung erhöhen kann?

Wolfgang: Also gibt es da so Dinge, wo du sagst, also die vier Sachen,

Wolfgang: die fünf Sachen, würde ich mir auf jeden Fall mal anschauen,

Wolfgang: die braucht man eigentlich immer, unabhängig davon, wie man vorgeht.

Wolfgang: Aber da muss man auf jeden Fall.

Clemens: Also was man auf jeden Fall immer machen sollte, egal was für ein Produkt und

Clemens: wie komplex und wie wichtig das ist, ist wirklich ein Threadmodeling,

Clemens: da bin ich großer Fan von.

Clemens: Ich kann es jetzt nicht wirklich als Low-Hanging-Fruit bezeichnen,

Clemens: weil es schon einen gewissen Aufwand bedeutet.

Clemens: Also wenn du jetzt irgendwie an eine Checkbox gedacht hast, die man irgendwo

Clemens: anklickt und dann ist man sicher, da sowas kann ich jetzt da nicht liefern.

Clemens: Aber so Threadmodeling ist auf jeden Fall was, was halt super wertvoll ist,

Clemens: gerade so als Einstiegsaktivität für ein Team, um sich mal mit verschiedenen

Clemens: Sachen zu beschäftigen. haben wir ja in der letzten Folge diskutiert.

Wolfgang: Genau, die verlinke ich natürlich auch, die Folge zum Threat Modeling.

Clemens: Genau, das ist so ein sehr, sehr guter Einstieg, dann sich mit dem Thema Supply

Clemens: Chain Security auseinanderzusetzen, da Sachen zu automatisieren,

Clemens: ist auf jeden Fall was, was super wertvoll ist.

Clemens: Dann, was ich auch sehr wichtig für den Anfang finde, ist wirklich Awareness

Clemens: Trainings für alle, die auch jetzt an der Entwicklung nicht direkt beteiligt

Clemens: sind, dass die eben an Bord sind, dass die das verstanden haben.

Clemens: Wir haben da sehr gute Erfahrungen damit gemacht, solche Leute auch wirklich

Clemens: mal selber Sachen hacken zu lassen. Da haben die zum einen viel Spaß dran.

Clemens: Sie kommen da auch weiter, als man auf den ersten Blick denken sollte bei irgendwie

Clemens: jemanden, der ein Product Owner ist und vielleicht gar nicht so viel technischen Hintergrund hat.

Clemens: Kommt man da trotzdem mit den richtigen Tools und den richtigen Anwendungen super weiter.

Clemens: Das sind so Sachen, mit denen man gut anfangen kann.

Clemens: Dann sich im Bereich Entwicklung zu überlegen, was für Sachen können wir hier

Clemens: automatisieren, damit sie reproduzierbar wären, also das Thema CICD ist für uns oft völlig klar,

Clemens: manche sind da noch nicht so weit, das ist da so ein erster Schritt,

Clemens: der nicht nur aus einer Security-Perspektive super wertvoll ist,

Clemens: sondern natürlich auch aus anderen Quantitätszielen heraus, das wären so die

Clemens: ersten Schritte, an die ich denken würde, wenn...

Clemens: Sonst nicht weiß, was dein Produkt so macht.

Wolfgang: Also Automatisierung, CI, CD, finde ich auch unheimlich wertvoll.

Wolfgang: Ich hatte das in meiner Anfangszeit nicht. Ich habe das alles manuell gemacht

Wolfgang: und das war echt eine Katastrophe.

Wolfgang: Da habe ich auch mal aus Versehen irgendwie so eine Testsoftware aufs Produktivsystem

Wolfgang: gespielt, weil die verschiedenen Systeme, die unterschieden sich damals halt

Wolfgang: nur in IPs, die ich in so einer Textdatei drinstehen hatte.

Wolfgang: Schon, weiß nicht, 20 Jahre her oder so. Aber das war eine sehr, sehr wilde Zeit.

Wolfgang: Und es gab für Linux mal für Gnome, glaube ich, gab es mal so einen Terminal-Emulator,

Wolfgang: der hieß Terminator. Kennst du den noch?

Wolfgang: Ich weiß nicht. Da konnte man so Splitscreen machen. Das heißt,

Wolfgang: du hast dann so einen 8er-Splitscreen gehabt, konntest dich auf 8 Servern parallel

Wolfgang: einloggen. Die gleichen Kommandos. Die gleichen Kommandos.

Wolfgang: Ja, damit habe ich auch viel gearbeitet, auch produktiv.

Wolfgang: Und da ist nie was passiert und das wundert mich heute immer noch.

Clemens: Das Bestes Feature in meiner Shell ist, dass man die Hintergrundfarbe ändern

Clemens: kann, je nachdem auf welchem System man gerade ist.

Clemens: Also wenn du auf Prod irgendwie eingeloggt bist, dass dann der Hintergrund rot

Clemens: wird, dann hat man nämlich gleich noch so den Blick da drauf,

Clemens: wo man eigentlich gerade was macht.

Wolfgang: Ja, aber vielleicht ist auch sowas super spannend in so einem Security-Training,

Wolfgang: so kleine Lifehacks, denn vielleicht noch ein kleiner Schwank aus der Vergangenheit.

Wolfgang: Ich habe mal bei einer anderen Firma gearbeitet, war nicht hier bei Inovex.

Wolfgang: Da haben wir für einen sehr, sehr großen Kunden gearbeitet und da haben wir

Wolfgang: so ein CMS-System gehabt.

Wolfgang: Und da gab es auch ein Live-System und ein Test-System und so ein Pre-Production-System

Wolfgang: und die sahen aber alle gleich aus im Bäcker.

Wolfgang: Und am Live-System durften wir nie was machen, da durften nur die Kunden daran

Wolfgang: arbeiten, weil da auch sehr viele User immer drauf waren.

Wolfgang: Wir durften an den anderen arbeiten, bis der eine Kollege mal leider am falschen

Wolfgang: System an so DNS-Einstellungen gedreht hat und das dann so, ich sag mal,

Wolfgang: zu Primetime ausgefallen ist.

Wolfgang: Und ich habe selten den Menschen so viel schwitzen gesehen und am nächsten Tag

Wolfgang: haben wir das dann auch so gemacht, dass dieses Produktivsystem rot war.

Wolfgang: Also absoluter Lifehack hier für Produktivsysteme.

Wolfgang: Clemens, das war sehr spannend, kurzweilig wie immer,

Wolfgang: und ich glaube, das ganze Thema ist halt einfach nicht nur super wichtig,

Wolfgang: weil es jetzt eine neue Regularie ist, sondern ich glaube, das ist einfach wichtig,

Wolfgang: weil Daten einfach unglaublich wertvoll sind und es kann einem Unternehmen halt

Wolfgang: auch wirklich das Genick brechen, wenn da irgendwas mit wertvollen Kundendaten

Wolfgang: passiert und die irgendwo abfließen.

Wolfgang: Das kann wirklich schlimm sein einfach und kann letztendlich auch dein Ende bedeuten.

Wolfgang: Und ich als User, ich fühle mich auch besser, wenn ich weiß,

Wolfgang: dass die Firmen, denen ich meine Daten anvertraue, dass die halt da einfach

Wolfgang: auch sich Mühe geben und das Thema ernst nehmen vor allem.

Clemens: Ja, und deswegen bringt der Cyber Resilience Act da eben zurecht nochmal ein

Clemens: bisschen Bewegung rein.

Clemens: Ich kann jedem nur raten, sich damit mal zu beschäftigen.

Clemens: Wir verlinken da in den Shownotes auch nochmal, was Intervex dazu schon so publiziert

Clemens: hat, würde ich vorschlagen.

Clemens: Dann hat man da einen Einstiegspunkt, wenn man da mal nachlesen möchte.

Clemens: Und selbst wenn man nicht direkt drunter fällt aus irgendwelchen Gründen,

Clemens: sind die Sachen trotzdem wirklich absolute Best Practice.

Clemens: Ich kann es jedem nur raten, sich damit zu beschäftigen.

Wolfgang: Kann ich mich nur anschließen, Clemens. Clemens, vielen Dank für deinen dritten Besuch hier im Podcast.

Wolfgang: Ich sage mal so, das wird nicht der letzte gewesen sein.

Clemens: Ich hoffe, das war mir eine Freude.

Wolfgang: Security ist ein wildes Thema. Es wird nicht langweilig. Auf gar keinen Fall.

Wolfgang: Ja, mir war es auch eine Freude und ich sage mal, Clemens, bis bald.

Clemens: Bis bald.

Voiceover: Das war das Gespräch mit Clemens. Ich hoffe, es hat euch Spaß gemacht.

Voiceover: Wenn ihr Feedback habt, dann erreicht ihr mich per E-Mail unter podcast.innovex.de.

Voiceover: Wir hören uns in der nächsten Folge wieder. Bis dahin wünsche ich euch viel Spaß und eine gute Zeit.