Andrena entwickelt – Der Podcast
Thema: Software Cyber Resilience Act (CRA) Was bedeutet die EU-Verordnung für die Softwareentwicklung?
[Musik spielt]
00:00:03 Sebastian: Was ja schon in unserer allem Sinne sein sollte, ist, dass Software einem gewissen Level an Sicherheit genügen muss oder sollte.
00:00:12 Sebastian: Ich find das Schwachstellenmanagement ist das herausragende Merkmal des CRA.
00:00:19 Sebastian: Wer bis dato kein Betrieb hatte mit 24/7, der ist glaube ich schon ein bisschen im Stress.
[Musik spielt]
[Intro]
00:00:34 Yvonne: Andrena entwickelt. Der Podcast von andrena objects von EntwicklerInnen für EntwicklerInnen.
00:00:41 Max: Willkommen zu dieser Folge andrena entwickelt. Hier ist wieder Max. Ich bin wie immer Softwareentwickler bei andrena. Heute ist der Andi mein Co-Host.
Andi: Hallo Max.
Max: Und wir haben natürlich wieder einen Gast bei uns heute das ist Sebastian. Hi Sebastian.
00:00:59 Sebastian: Hallo Max und Hallo Andi.
00:01:00 Max: Genau. Wir haben uns das Thema vorgenommen, was den HörerInnen vielleicht auch schon mal kürzlich über den Weg gelaufen ist. Das ist der Cyber Resilience Act. Und heute wollen wir erfahren, warum das für uns wichtig ist und was wir darüber wissen sollten. Da kennt sich der Sebastian, glaub ich, ganz gut aus und deswegen möchte ich einfach mal das Wort übergeben. Möchtest du dich kurz vorstellen und uns da in das Thema einführen, Sebastian?
00:01:26 Sebastian: Genau, kann ich sehr gern versuchen. Also mein Name ist Sebastian Frühling, ich bin Teil des andrena Universums mittlerweile seit 2016. Ich komme ursprünglich aus der Robotik, hab also nach meinem Informatikstudium sehr viel mit Kamerarobotern zu tun gehabt. Hatte in dem Umfeld dann auch die Chance zu promovieren und bin nach der Promotion zur andrena gekommen. Bei der andrena bin ich Softwareentwickler im Schwerpunkt und nebenher im Münchner Leitungsteam. Und heute sprechen wir über den Cyber Resilience Act. Der Cyber Resilience Act soll die Security von Softwareprodukten erhöhen, sodass wir innerhalb des EU-Raums auf jeden Fall uns sicherheitstechnisch darauf verlassen können, dass sie einem gewissen Mindeststandard entsprechen.
00:02:13 Max: Das heißt, dass ist ein EU-Gesetz.
00:02:14 Sebastian: Genau ist eine EU-Verordnung, so ist der offizielle Begriff. Es braucht also keine nationale Gesetzgebung, die das Ganze dann noch mal realisiert, sondern tritt so in Kraft beziehungsweise ist schon in Kraft getreten seit 11.12.2024.
00:02:29 Andi: Heißt das, dass die Software, die ich jetzt für meinen Kunden entwickle, schon direkt betroffen ist?
00:03:00 Sebastian: Nein, das heißt es nicht. Also das Ding ist, hätte vielleicht vorhin sagen müssen, ist verabschiedet seit 11.12.2024 . Tatsächlich vollumfänglich in Kraft treten, tut es erst 2027, nämlich am 11.12.2027. Eine kleine Ausnahme gibt es dann für Meldepflichten, die ist zukünftig auch gefordert. Das tritt schon ein bisschen früher in Kraft, nämlich am 11.9.2026. Und bis dahin, also bis Dezember 2027, gilt eine sogenannte Übergangsfrist. Das heißt, noch ist es nicht so tragisch. Erst ab dem 11.12.27 respektive 11.9.26 muss man auf gewisse Dinge achten, muss man die Anforderungen erfüllen.
00:03:19 Max: OK, auf die einzelnen Punkte, da gehen wir bestimmt noch ein gleich, aber grundlegend liegt über all dem eigentlich die Idee, dass du, wenn du Software hast, dann soll sie bitte sicher sein, oder?
00:03:30 Sebastian: Das wäre schön, wenn es so wäre. Der Cyber Resilience Act bezieht sich jetzt erstmal nur auf Produkte mit digitalen Elementen. Das heißt im Schwerpunkt auf wahrscheinlich IOT-Geräte und zum Teil dann gehören auch noch einige reine Softwareprodukte dazu. Vielleicht hilft ein Beispiel. Also ein Beispiel wäre ein smartes Küchengerät, das eben zum Teil über die Cloud oder irgendeinen Cloud Dienst gesteuert werden kann. Ein Beispiel ist ein Browser, eine Netzwerk-Konfigurationssoftware oder Sonstiges. Aber das bezieht sich tatsächlich immer, also der wichtige Teil daran ist, ich brauche ein Produkt, wenn ich kein Produkt habe, dann ist es schon ein bisschen schwieriger und das disqualifiziert dann meiner Meinung zumindest auch einige der Softwareentwicklungen, die da draußen unterwegs sind. Also sowas wie eine reine Webseite, wahrscheinlich sogar die meisten Webshops, so sie denn nicht unverändert in Betrieb genommen werden, würden wahrscheinlich auch nicht unter den CRA fallen.
00:04:34 Max: OK, das heißt, den Disclaimer müssen wahrscheinlich auch gleich machen. Weil wir es schon im Vorgespräch gemerkt haben, dass das Thema ist schwierig und nicht in allen Aspekten ausdefiniert und vor allem noch nicht gerichtlich wahrscheinlich entschieden. Das heißt, wir können ja keine rechtssicheren Auskünfte geben, so nur das Thema irgendwie umreißen und euch neugierig, bisschen neugierig machen auf das Thema, aber solche Fragen müssen wir halt bald stellen - ist jetzt eine Library, die ich entwickle oder bereitstelle, auch davon betroffen? Aber gut, macht ja nichts, wir werden trotzdem was lernen heute glaube ich.
00:05:04 Sebastian: Vielleicht würde ich dazu gerne was ergänzen. Also was ja schon in unserer allem Sinne sein sollte, ist, dass Software per se einem gewissen Level an Sicherheit genügen muss oder sollte, zumindest aber rein rechtlich gesehen und gerade wenn ich mich auf den CRA beziehe, geht das jetzt eben erstmal nur für Produkte mit digitalen Elementen. MIST 2 wird, sobald es dafür eine nationale ich weiß gar nicht wie das dann offiziell heißt, also sobald es ein nationales Gesetz gibt, dass die MIST 2 Richtlinie umsetzt. Das schränkt man noch mal ein bisschen weiter ein. Da sind einige Sektoren, die eben als besonders kritisch angesehen werden werden damit auch noch abgefrühstückt. Aber ich hab bisher noch kein Gesetz, oder Vorschrift gefunden, die das vollumfänglich auf jegliche Software hin ausrollt. Deswegen ist aber beim CRA ist schon wichtig zu wissen, dass es sich primär, also ausschließlich auf Produkte bezieht.
00:05:57 Andi: Was heißt das jetzt eigentlich genau, dass ich betroffen bin? Heißt es jetzt, ich muss Strafen zahlen, worauf muss ich achten, damit ich keine Strafen zahle, wie sieht das aus?
00:06:08 Sebstian Eigentlich fordert der insgesamt so 3 Dinge im Wesentlichen. Das eine ist ein gutes Schwachstellenmanagement. Das erfordert einige Dokumentationen, die vielleicht nicht alle bisher haben, und ansonsten fordert er eben noch das Security. Das ist auch noch gut, dass es dabei ist, dass Security an sich erstmal umgesetzt ist. Ich fasse das ganz gerne als grundlegende Anforderungen zusammen, also da sind so Dinge dabei wie Integrität, Vertrauenlichkeit und Verfügbarkeit, das sind also die typischen Dinge, die. Die, die die Security erstmal fordert. Da gehört aber auch sowas dazu wie Datenminimalismus da gehört was dazu wie die muss die DSGVO einhalten. Ich brauch n sicheren Softwareentwicklungsprozess und so Geschichten, deshalb ich jetzt mal so n bisschen großzügig unter grundlegenden Anforderungen zusammengefasst, weil ich glaube, dass das nicht so sehr die Herausforderung ist. Ich find, das Schwachstellenmanagement ist das herausragende Merkmal des CRA oder vielleicht auch der zukünftigen Security Betrachtungen, die wir hoffentlich irgendwann für alle Software anstreben müssen. Da sind so ein paar Dinge drin, die sind schon auch knackig und andere sind, glaube ich auch vielleicht, wenn ich es manuell mache, einigermaßen knackig, aber kann ich ganz gut mit Tools abfrühstücken und dann muss ich mir halt überlegen, wie groß mein Budget ist und wie komfortabel meine Tools sind. Das wäre glaube ich so im groben Sinn, dass diese 3 Dinge, die aus meiner Sicht sich jetzt zukünftig dann ändern werden in Bezug auf den CRA.Max, wollen wir mit dem Schwachstellenmanagement anfangen?
[Lachen]
00:07:39 Max: Klar.
00:07:41 Sebstian: Genau, also ich fang einfach mal ein bisschen an, über das Schwachstellenmanagement zu sprechen. Ich fass das Recht großzügig unter Schwachstellenmanagement zusammen, insgesamt gehört da natürlich ein bisschen mehr dazu, also im im CRA steht etwas von Meldepflichten, Artikel 14 und das ist für mich ein wesentlicher Teil des Schwachstellenmanagements. Also ich muss zukünftig, wenn ich eine ausnutzbare Schwachstelle, ich glaub so ist der der Wortlaut. Bei mir feststelle oder gemeldet bekomme. Dann muss ich diese weiter melden. Weiter melden. An wen ist erstmal interessant. Der CRA spricht von der Enisa, das ist die Europäische. Software sicherheitskommission, so nenn ich es jetzt mal. Also ich krieg den Namen jetzt nicht nicht konkret zusammen und den CIRT und unter CIRT würde ich jetzt mal das BSI sehen CIRT im Sinne von Computer security incidents response team. Ich seh da jetzt erstmal das BSI als die Ansprechstation, die wir innerhalb von Deutschland haben. Zukünftig müssen nach Bekanntwerden eines schwerwiegenden Sicherheitsvorfalls oder einer ausnutzbaren Schwachstelle muss das gemeldet. Innerhalb von 24 Stunden. Und das nennt sich dann Frühwarnung. Da kann ich also relativ grob erstmal nur angeben, also wie es genau aussehen wird, weiß glaube ich noch keiner. Die Plattform ist meines Wissens noch. Nicht nur ich muss melden, sondern ich muss auch zukünftig eine Adresse angeben, an dem mir andere etwas melden können. Also konkret geht es um Schwachstellen, das heißt, ich muss eine E-Mail Adresse oder eine Webseite zur Verfügung stellen, an die ich mich wenden kann, wenn ich eine Schwachstelle in der jeweiligen Software finde. Und dann muss eben auch entsprechend reagiert werden. Es empfiehlt sich dann schon in Kontakt zu bleiben mit dem jeweiligen Melder, weil ich glaube, es ist immer der beste Weg da den kurzen Dienstweg zu nehmen und das einfach schnell aus der Welt zu räumen, als wenn man dann entsprechend pampig reagiert.
00:10:57 Max: Das ist ja auch nicht die Idee von dem CRA glaube ich sowas im Gegenteil, es sollte möglichst transparent werden, alles.
00:11:03 Sebstian: Genau. Es geht darum, dass die Software in Europa sicherer und besser wird und der CRA adressiert vermutlich ein Sorgenkind. Also es steht auch explizit in der Einleitung drin, dass der CRA insbesondere Produkte mit digitalen Elementen adressiert, weil hier das Security Security Level insgesamt, ich nenne es mal, ausbaufähig ist oft.
00:11:18 Andi: Du hattest jetzt vorhin das Beispiel mit der smarten Küchenmaschine. Heißt es dann in Zukunft steht auf der Packung der Küchenmaschine oder in der Anleitung dann eine E-Mail drauf und dann steht da Meldestelle für Schwachstellen?
00:11:43 Sebastian: Genau, also ob das jetzt konkret so eingeführt ist mit Meldestelle für Schwachstellen, weiß ich nicht. Aber in irgendeiner Form muss zumindest eine Adresse angegeben sein, an die ich mich wenden kann, wenn ich irgendwo eine Schwachstelle finde.
00:11:50 Max: Und diese Schwachstelle muss äußerlich für den Anwender am Produkt in irgendeiner Art Weise erkennbar sein.
00:11:57 Sebastian: Ich weiß nicht, ob man alle Schwachstellen äußerlich erkennt, das glaube ich eher nicht, aber wenn ich eine finde, da muss man natürlich auch gewillt sein zu suchen, so schätze ich das zumindest ein. Also wenn wenn jetzt mir ein Weg auffällt, wie ich aus meinem Ofen heraus an die die anderen nutze von anderen Öfen vielleicht kommen kann oder wie ich andere Öfen fernsteuern kann oder so Geschichten wär das für mich ne Schwachstelle und wenn ich dann nett bin, dann melde ich sie, und darauf hoffen wir ja, und dann müsste auch der entsprechende Hersteller auch entsprechend reagieren.
00:12:32 Andi: Kann ich dann auch als Nutzer irgendwie mir eine Übersicht schaffen über existierende Schwachstellen von Produkten?
00:12:39 Sebastian: Ja, sowas geht. Wenn ich weiß, was in dem jeweiligen Produkt verbaut ist, also insbesondere jetzt in Sachen Bibliotheken. Es gibt Datenbanken, die enthalten bekannte, das ist der wichtige Teil, bekannte Schwachstellen in verschiedenen Bibliotheken und wenn ich jetzt noch weiß, welche Bibliotheken in meinem Produkt verbaut sind. Dann kann ich da ja ein Diff drauf machen und kann einfach schauen, welche Schwachstellen potenziell drin sind. Ich glaube der einfache Weg ist den Hersteller einfach anzuschreiben, der ist zukünftig nämlich auch verpflichtet über bekannte Schwachstellen, also bekannte Schwachstellen, zu dokumentieren. Ich muss es meines Erachtens nicht mitreichen mit dem Produkt deswegen also, aber wenn ihr da nicht fragt, dann kriegt ihr bestimmt auch eine schöne Liste, was denn bisher da ist und vielleicht auch ein paar Tipps, wie man das Ganze dann umgehen kann.
00:13:28 Max: Vorhin hast du noch gesagt, dass es auch um schwerwiegende Sicherheitsvorfälle, glaube ich, geht? Das heißt, auch wenn du ein Produkt benutzt und du hast jetzt keine Lücke entdeckt, aber irgendwas ist vorgefallen, kann das auch dann dazu führen, dass du das, dass du es dem Hersteller über jeden definierten Weg melden kannst.
00:13:56 Sebstian: Also tatsächlich muss man ein bisschen unterscheiden, also der Artikel 14 geht eher vom Unternehmen selbst aus, unser. Dann geht man davon aus, dass das Unternehmen selbst feststellt, wenn ungebetene Gäste auf dem System waren oder dass Daten abgeflossen sind, die nicht hätten abfließen sollen oder was auch immer. Jetzt diese Meldestelle erst mal. Für meines Erachtens ist die primär für Schwachstellen zuständig und die Hoffnung wäre dann, dass der Hersteller selbst oder das Unternehmen, das hinter dem jeweiligen Produkt steht, mitbekommt, wenn in irgendeiner Form Daten unbeabsichtigt abfließen. Insofern, da steht es explizit drin, also in Artikel 14 ist explizit eben für schwerwiegende oder ist explizit von schwerwiegenden Sicherheitsvorfällen die Rede. Für diese Meldestelle ist das jetzt nicht so klar definiert. Ich könnte mir vorstellen, also wenn es dir als Nutzer auffällt, dann kannst du dich natürlich auch an die Meldestelle wenden, ich gehe aber davon aus, dass dann auch der Hersteller, wenn er denn seine Software und seinen Betrieb gut im Griff hat, dass er das dann auch schon mitbekommen hat, dass es da etwas gibt, was es vielleicht näher zu untersuchen lohnt. In Sachen Schwachstellenmanagement, was zukünftig auch noch eine Anforderung ist, ist, dass ich mein Abhängigkeits, meine Abhängigkeiten im Griff habe. Also ich bin verpflichtet, mein Produkt frei von ausnutzbaren Schwachstellen auszuliefern und das bedeutet tatsächlich das, was wir eben hatten. Ich muss dafür sorgen, dass ich weiß, welche Abhängigkeiten habe ich in meiner Software und ich muss dafür sorgen, dass wenn ich das Produkt zusammenbaue, dass dann keine Abhängigkeit keine Schwachstellen in meinen Abhängigkeiten enthalten sind. Ganz interessant. Ich hab mal ich nenn es mal als Hobbyprojekt einfach ein minimales Projektchen mit Springboot aufgesetzt und hab mal versucht rauszubekommen wie groß der Anteil von Fremdcoat in Form von Bibliotheken und eigenem Code tatsächlich ist. Ich fand ganz spannend, dass dann die Aufrufe insgesamt beim Start einer Spring Boot Applikation einer sehr minimalen Spring Boot Applikation, die einfach nur einen springboot Starter Web und Einen springbootstarter Security. Hält also nur die 2 Abhängigkeiten. Dass da am Ende des Tages. Sechstausendsechshundert Funktionen aufgerufen werden und meine minimale Applikation, die nur auf Anfrage ein Jason ausreicht und also ich muss mich authentifizieren mit einer mit mit der Basisauthentifizierung. Ich hab dann also 4 Methoden gebraucht, um das Ding an den. Start zu bringen. Und das wurde ja dann dazu führen, dass das Verhältnis Fremdcoach zu eigenem Code in dieser Applikation. Bei. Ungefähr 1 zu 1500 liegt. Und wenn man das andersrum formuliert, dann habe ich in dieser Applikation also 1500 mal mehr fremdcode als eigenen. Code? Ich finde es ganz spannend, weil das zeigt so ein bisschen, wie wichtig es ist, dass man seine Abhängigkeiten im Griff haben muss. Und ich glaube, auch das führt am Ende dazu, dass man sich besser überlegen wird, welche Abhängigkeiten mir tatsächlich ich mir tatsächlich in mein in mein Produkt reinhole und auf welche Abhängigkeiten ich vielleicht verzichten will.
00:16:50 Max: Da habe ich gleich 2 Gedanken dazu einmal. Natürlich wäre das bei einer echten Applikation, hast du dann halt mehr eigenen Code, vielleicht anwendungscode et cetera, dann verschiebt sich das wahrscheinlich ein bisschen, aber vermutlich. Hast du immer noch bei einem. Bei einer mittelgroßen Anwendung noch genügend Anteil von dem Framework drin, zumindest bei Spring. Und das andere ist na wenn du echt nur so wenig Code hast im Vergleich, dann ist könnte man fast sagen, verzichte auf deine eigene Security, sondern guckt, dass dein Libris Safe sind, weil dort hast du eben 99% der Lücken drin, was nicht heißen soll, dass man sich nicht um selbst und sichern Code kümmern sollte.
00:17:23 Sebastian: Genau, also bei deinem ersten Punkt stimme ich dir. Vollkommen zu ganz klar. Also dieses Beispiel ist bewusst n bisschen übertrieben auch formuliert, und je mehr eigenen Code ich habe, desto mehr verschiebt sich das Verhältnis aber von 1 zu 1500 auf 1 zu 2 ist der Weg allein schon ziemlich weit und meistens ist es ja dann so, dass wenn ich dann mehr eigenen Code habe, dann hole ich mir auch mehr Abhängigkeiten mit rein, das heißt es ändern sich also beide Seiten dieser dieser Gleichung und. Ich also es wäre tatsächlich mal interessant und ich hab auch mal überlegt, ob wir das nicht mal probieren sollen. Einfach auf bekannte Projekte, die wir so haben, das Mal auszuprobieren. Aber ich fürchte, das hättest du nicht viel geführt. Wird. Deswegen haben wir es bisher nicht gemacht. Also es ist tatsächlich eher so ein so ein Rechenbeispiel, ein plakatives Rechenbeispiel, dass es sinnvoll ist, sich um seine Abhängigkeiten zu kümmern, und ich glaube, dafür ist es sehr, sehr gut geeignet.
00:18:13 Andi: Was ich mich da direkt gefragt habe bei dem Beispiel. Spring Boot ist ja Open Source und wird ja viel benutzt. Das heißt von Abilities werden wahrscheinlich auch relativ schnell erkannt und gemeldet. Wenn ich jetzt in so Fällen sage. Das Verhältnis ist mir zu krass, da könnten wir Sicherheitslücken drin sein und ich schreib mal n eigenen, ist da nicht die Wahrscheinlichkeit höher, dass ich meine eigenen Sicherheitslücken einbaue?
00:18:38 Sebastian: Also, ich glaube man sollte gewisse Dinge, insbesondere wenn es um Security geht, sollte man gewisse Dinge nicht selber programmieren, aber man sollte sich gut überlegen, ob sich eine etablierte, vielleicht auch sehr, sehr große Bibliothek tatsächlich rentiert oder ob es nicht eine etwas kleinere etablierte Bibliothek oder ein Teil davon auch schon tut, einfach um diese. Verhältnis n bisschen im Blick zu halten und ich glaube das ist so, wenn man so weit schon kommt und das wird bestimmt. Wenn der CAA oder vielleicht auch andere Security Security Gesetzgebungen sich eher etabliert haben. Dann wird es definitiv kommen, dass sich die des Abhängigkeitsmanagement oder Supply Chain Management kann man ja vielleicht auch sagen, ein bisschen verändern wird.
00:19:20 Andi: Ja, in den letzten Jahren hat man ja auch schon Beispiele gesehen, wie gefährlich eigentlich so Supply Chain Attack sein können. Ich weiß nicht, ob ihr schon von der exe util Spector gehört habt, da hat ein Contributor von einer Linux Library eine Backdoor eingebaut, die dann letztendlich dazu geführt hat, dass man Access bekommt, SSH auf. Einige Maschinen, Root Access und das war ja. Genau, quasi eine Supply Chain Attack. Also er hat halt die übernommen für dieses Projekt hat das Halt Sneaky eingebaut und ja es ist dann nur zufällig aufgefallen, weil irgendjemand seine Datenbank im Benchmark hat und gemerkt hat, dass die Verbindung länger dauert als sonst.
00:20:05 Sebastian: Wow, ja kann vorkommen, ist aber glaube ich jetzt gerade bei den großen Open Source Projekten. Da hab ich zumindest ich die Hoffnung, dass es immer irgendjemand geben wird, dem solche Dinge auffallen würden. Ich glaube, das geht eher bei sehr, sehr kleinen. Vielleicht Open Source Projekten. Also wäre meine Vermutung.
00:20:22 Max: Und schwer wird es wahrscheinlich auch sein, solange das Halt ein gewatschtes Projekt ist. Weil wenn es halt nicht gewahrt ist, dann werden halt die Lücken die es gibt eben nicht mehr gehoben. Und ja, Lücken wird es immer geben und das muss halt hoffentlich nur Updates geben. Man kann dann darauf updaten, aber das war jetzt ein Beispiel aus der aus der Linux Welt glaube ich mit exe du hattest vorhin Spring Boot genannt, wir haben noch gar nicht den Elefanten im Raum angesprochen nodejs. Und NPM Abhängigkeiten der N. Sehr breiter Baum meistens ergeben oder eher tief wahrscheinlich. Da stell ich es mir sehr schwer vor. Dieser Anforderung, dass ich keine ausnutzbaren Sicherheitslücken habe, einzuhalten, also vor allem nicht, wenn ich es irgendwie, wenn ich das irgendwie händisch versuche zu managen, da muss es doch irgendeinen Weg geben für mich als Entwickler oder als Team, dass ich da zurande komme.
00:21:10 Sebastian: Ja, also prinzipiell gibt es ja Tools, also NPM hat ja selber auch n Tool schon inkludiert, mit dem ich einfach feststellen kann, ob es Schwachstellen gibt in also bekannte Schwachstellen. Das ist immer der wichtige Teil, also ne Schwachstelle. Also es gibt bestimmt deutlich mehr Schwachstellen als bekannte Schwachstellen und dann ist noch mal die Frage, ist die jeweilige Schwachstelle, über die wir dann reden, tatsächlich bei mir auch anwend oder Ausnutzbar? Das sind so die 3 Stufen, die man glaube ich im Kopf haben muss, ich glaube es gibt, wenn ich jetzt darüber nachdenke, wie man das mit Tools abdecken kann, dann gibt es irgendwie 2 Strategien. Die eine Strategie Wäre ich bleibe auf meiner Version, solange es eben geht und versuche Sicherheitsupdates irgendwie mitzubekommen und vielleicht selber vielleicht auch automatisiert durchzuführen. Ich find den weg immer n bisschen schwierig, weil das ganz schnell dazu führt, dass man da mit den mit den Updates echt in Schwierigkeiten kommt. Ich persönlich bevorzug es dann eher, dass ich versuche close to the Edge vorzukommen, das heißt ich nehm von allen Bibliotheken die neueste. Version und lass das am besten auch noch automatisiert durchlaufen. Stichwort Renovate also oder auch der wie heißt der von Github, der Dependarbot, das heißt es gibt mittlerweile Tools, die einem das Repository scannen können feststellen können, welche Version im Projekt verwendet werden und auch feststellen können, was die jeweils aktuellste Version wäre und das ist dann glaube ich schon der präferierte Weg, dass man einfach sagt, OK soft. Ware Updates oder Bibliotheksupdates Abhängigkeitsupdates muss ich so oder so machen. Und ich bin dann eher auf der Seite, dass ich sage. Ja, vollautomatisch immer das neueste. Da ist die Wahrscheinlichkeit, dass Schwachstellen drin sind, hoffentlich am geringsten. Also bin da ziemlich rigoros unterwegs und versuch das auch möglichst automatisiert gleich in den Mainboard rein zu mergen. Auch das kann zum Beispiel Renovate vollautomatisch und ich bin großer, also man hört es vielleicht ein bisschen raus, ich bin großer Fan von Renovate, weil der uns so viel Arbeit abnimmt, das ist so.
00:23:05 Andi: Schön, das ist n Open Source Projekt, oder?
00:23:08 Sebastian: Es ist zumindest frei, ob es Open Source ist, bin ich mir jetzt gar nicht sicher, aber es ist n Projekt, ja. Einfach n Dienst, der genau das Macht der einfach er scannt nach Abhängigkeiten und schaut welche Version verwendet wird und schaut ob es dann ne neuere Version zu gibt und das Ganze kann man einfach also. Wir haben ihn. Jeden Morgen lassen wir ihn laufen, dass wir halt, wenn wir dann anfangen zu arbeiten, die ganzen. Also er legt automatisch dann branches an für jedes Update das er findet und wenn dieser Branch automatisch übersetzt und auch die Tests alle besteht, dann wird er gleich reingemergt bei uns. Wenn das nicht der Fall ist, dann wissen wir halt, dass wir noch n paar Branches noch mal manuell nach. Müssen und schauen müssen, warum das nicht vollautomatisch funktioniert. Aber insgesamt ist es glaube ich schon. Ne ganz gute Strategie mein manche werden vielleicht sagen, irgendwie, der ist bekloppt, dass es automatisch rein mergen lässt, aber ich vertrau unserer Testsuite und bis dato hat das echt ganz gut geklappt.
00:24:00 Max: Klingt gut.
00:24:02 Sebastian: Vielleicht noch ein Satz dazu. Also jetzt nur der Testsuite zu vertrauen und nur die neue Version in der Main Branche einzupflegen ist ja der eine Teil. Man muss dann schon auch sicherstellen sicherstellen, dass das am Ende des Tages auch auf Produktion kommt, also es hilft mir nichts, wenn mein Development Branch Top aktuell ist und ich dafür schon Jahre nicht mehr die Leute habe. Dann ist es vielleicht nicht sonderlich hilfreich. Das ist glaube ich auch oft der schwierige Teil dann, dass man aus dem aus, dem aus dem automatischen Update heraus auch eigentlich automatischen Deployment provozieren muss, da muss ich auch ganz ehrlich zugeben, das machen wir tatsächlich auch nicht, sondern wir deployen nur vollautomatisch auf die Stage und von da aus müssen wir dran denken, dass wir den Kram selber weiter rausschieben.
00:24:42 Andi: Wir haben jetzt viel über Abhängigkeiten und Abhängigkeit also Management von Abhängigkeiten gesprochen. Wir hatten aber auch angesprochen, in größeren Projekten geht ja dann das Verhältnis eher in die andere Richtung. Da habe ich dann viel eigenen Code, den ich geschrieben hab, da hab ich ja nicht den Luxus, das oder oft nicht den Luxus, dass der Open Source ist und von einigen Leuten quasi noch mal durchgeschaut wird, sondern ich muss irgendwie selbst drauf achten gibt es da auch coole Tools, die ich verwenden kann. Best Practices, um meinen eigenen Codes abzusichern?
00:25:14 Sebastian: Ja, also, es gibt glaub ich verschiedene Ansichten. Jetzt mal das erste was glaub ich ja nicht zu unterschätzendes Tool ist, obwohl das ganz banal klingt, ist das menschliche Peer Review, also das was ich geschrieben habe zeige ich noch mal jemand anderem oder lass es zumindest von jemand anderem noch mal drüber schauen, da müssen wir n paar Voraussetzungen erfüllt sein. Also ich brauch halt jemanden der entsprechend die Soßen gut genug kennt um einzuschätzen. Um einschätzen zu können, wie mein Code prinzipiell ist und ob das die Anforderungen erfüllt und ob da vielleicht auch irgendwelche Sicherheitslücken drin sind, die Sicherheitslücken bedeutet wieder, wenn ich darauf achten will, muss ich genügend Erfahrung haben, also ich glaube es ist nicht so effektiv, wenn sich 2 sehr junge Kollegen oder 2 sehr unerfahrene Kollegen zusammensetzen, das kann zwar schon mal potenzielle Bugs identifizieren, aber dann braucht man eben auch ne gewisse Seniorität ab einem bestimmten Level, trotzdem halte ich das für sehr sehr erfolgsversprechend. Allein deshalb, weil auch dann das Wissen im Team entsprechend verteilt wird. Und ich glaube, darum geht es ganz viel. Also wenn ich es schaffe, dass wir im Team ein Niveau an Softwareentwicklung etabliert haben, dann bin ich, glaube ich, schon ganz gut unterwegs, wenn ich das nicht habe oder auch nicht haben will, die man auch so ein Peer Review bremst einen ja dann doch auch ganz oft ein und ich muss vielleicht auch auf freie Ressourcen respektive erfahrene Entwickler warten, dann kann man dafür auch verschiedene Tools nehmen. Im einfachsten Fall und ich glaube das mittlerweile überall bekannt ist ja der Sonar Cube, den gibt es in der Community Edition, der findet mir schon ein paar ganz banale Bugs und vielleicht Programmierprobleme. Das allein also wird bestimmt nicht den Anspruch eines Sicherheitstests erfüllen, aber ist schon mal ganz gut, bevor ich gar nichts anderes habe, nehme ich lieber das Ding, da kann man noch ein paar Plugins reinschnallen es gibt auch sowas wie find Bugs, da gibt es eine Security Variante glaube ich dafür, also da gibt es schon ein paar Tools die auch speziell mehr in Richtung Security gucken. Da gibt es auch viele kostenfreie, die bestimmt nicht so mächtig sind wie kostenpflichtige oder vermutlich zumindest nicht so mächtig sind wie die kostenpflichtigen. Aber der Charme daran ist, sie kosten halt nichts, ich muss es einfach nur einbinden und hab die Chance, dass es vielleicht dann besser wird und das vielleicht eine Schwachstelle dann gefunden wird, die ich sonst nicht gesehen hätte, aber wenn man das eben nicht haben will, dann kann man natürlich auch kostenpflichtige Tools verwenden und diesen dann aber gleich relativ an dann richtig tief in die in die Budgetkiste greifen und muss dann einfach schauen, was einem da am meisten zusagt, was jetzt als weitere Variante oder als weiteres Tool auf den Tisch kommt, ist dann sowas wie sowas geht auch. AI basiert also ich kann mir durchaus auch Code Review Tools die auf AI basieren reinholen, ich habe selber keine Erfahrung damit, ich habe nur gehört, dass es echt überraschend ist, wie schnell die Feedback geben können. Jetzt ist die Frage dann, ob das auch entsprechend hochwertig ist, da kann ich aber nicht viel zu sagen. Meine Sorge wäre bei AI Tools, dass mir der Determinismus nicht nicht entsprechend stark genug ist. Ich weiß nicht, ob das jetzt persönliche Paranoia ist aber, ich glaube in Sachen Security würde ich mich dann doch lieber auf deterministische Tools verlassen und das wäre für mich so ein Grund, wo ich noch mal zweimal drüber nachdenken würde, ob ich mir eine AI Tool hole als Feedback oder auch eben ob ich das nicht mache.
00:28:34 Max: Ja, wobei du Determinismus ja auch eine dahingehend hast, dass du weißt, du hast auf jeden Fall eine Sicherheitslücke irgendwo drin ist nur eine Frage der Zeit, wann sie auftaucht oder bekannt wird. Aber ich meine, vielleicht ist es auch schon cool. Du kannst auch irgendwie nen einen Chatbot da einfach mal deinen Code reinfüttern oder du hast sogar ne ID Integration von dem Large Language Language Model, die werden wahrscheinlich auch 80% von dem gefährlichen Code oder verletzbaren Code den du da geschrieben hast dir aufzeigen.
00:29:01 Sebastian: Das kann durchaus sein, aber trotzdem wäre ich da eher auf der Seite, wenn wir schon nach irgendwelchen Dingen suchen, dann fände ich es irgendwie cool, wenn wir da 100% abfrühstrü. 00:29:10 Sprecher 1 Stücken. Also ich bin bei der Stelle, bin ich tatsächlich ein bisschen bisschen vorsichtig, ich bin sonst großer Fan von KI tools, wenn es um Sachen Kreativität geht. In Sachen Security weiß ich nicht. Ob das der Weisheit letzter Schluss ist, muss ich aber auch sagen. Also das ist. 00:29:25 Sprecher 1 Jetzt alles nur. 00:29:26 Sprecher 1 Bauchgefühl. 00:29:27 Sprecher 1 Ich. 00:29:27 Sprecher 1 Hab selber außer von github co Pilot nicht viel ausprobiert.
00:29:31 Andi: Ich muss sagen, dass klingt für mich auch immer so, als ob statische Analyse halt nur n Bruchteil von den wirklichen Sicherheitslücken finden kann. Wir hatten vorhin das Beispiel mit dem Ofen, wo ich irgendwie auf Öfen anderer Nutzer vielleicht zugreifen kann. Das ist ja wahrscheinlich einfach Teil von meiner Fachlichkeit in gewisser Weise, dass ich da irgendeine Art von Authentifizierung drin hab und die halt auch validiere und da würde ich bezweifeln, dass statisch eine, also eine statische Analyse oder AI diese Stellen findet.
00:30:02 Sebastian: Ja, das stimmt. Also man kann ja auch, gab es ja zum Jahreswechsel gab es ja ein Thema mit einem großen Automobilhersteller, da ging es ja dann darum, dass einfach nur im Aktuator war der Heatdump die hebt am Schnittstelle freigeschaltet war und man hat da Kies gefunden und sich dann so Zugriff auf die auf die Daten verschaffen können. Das ist natürlich ne Geschichte, das wird kein Code-Analyse-Tool finden, weil das einfach ne Konfigurationsgeschichte ist. Ich muss halt dafür sorgen, dass auf Prod alle meine Schnittstellen, die ich vielleicht auch nicht so unbedingt auf dem Schirm habe, tatsächlich geschlossen sind. Da hilft es dann und das ist ja auch immer dann, also bei all den den Tools, die wir jetzt hier so angesprochen haben, ist glaube ich am Ende des Tages schon noch mal wie fährt hin und wieder mal einen Pentest machen zu lassen. Ich glaube da kommt noch mal ein bisschen anderer Blick rein und vor allem kommt die Perspektive eben von außen. Also nicht ich bin nicht in meinem eigenen Saft, ich bin mir nicht sicher, dass alles, was wir alles Menschenmögliche gemacht worden ist, sondern vielleicht gibt es irgendwo was an was ich bisher nicht gedacht habe, und das ist dann, glaube ich, schon noch mal sehr hilfreich. Also man kann viel selber machen, aber man sollte trotzdem auch mal noch hin und wieder einen Pentest riskieren und sich dann die Ergebnisse sehr genau anschauen.
00:31:12 Max Wir haben es gesagt, es gibt Möglichkeiten, in die du deine deine Abhängigkeiten gegen gegen Lücken sichern kannst oder herausfindest. Es gibt da irgendwelche CVES, vielleicht steckt aber auch in ja in meinen Bildtools oder in der Infrastruktur, die ich nutze, könnten ja auch Lücken auftauchen, also wahrscheinlich muss ich da auch bisschen aktiv irgendwo mich informieren, gibt es da irgendwie Möglichkeiten oder irgendwie Plattformen, die man im Blick haben sollte oder vielleicht sogar irgendwas abonniert?
00:31:37 Sebastian Also aktuell fällt mir noch nichts ein. In Verbindung mit der Meldeplattform könnte es sein, dass Beispiel solche Informationen zur Verfügung stellt. Zentral. Es gibt ja auch von BSI einen einen RSS FEED, der durchaus einige der Sicherheitslücken schon mal rausspielt. Ich weiß es nicht, ob das erstrebenswert ist, in dieser Liste aufgeführt zu werden, aber das könnte durchaus eine valide Quelle sein. Ich habe es bei mir am HAndi diesen Feed und bin manchmal recht erschrocken, wie viele Meldungen darüber kommen, also da kommen teilweise.Mehr Meldungen als die Tagesschau rausbringt und die Tagesschau ist eigentlich schon ganz gut dabei.Deswegen wäre das vielleicht eine Quelle, wo ich mich aktuell halten kann. Zukünftig sind ja auch die Hersteller angehalten, auch ihre Kunden zu informieren, wenn sie Schwachstellen in ihren Produkten haben beziehungsweise auch dann ein Update-Mechanismus zur Verfügung zu stellen. Das ist jetzt glaube ich für manche Dinge relativ einfach, also wo vielleicht sowas auch schon etabliert ist. Es gibt aber durchaus auch Szenarien, da ist dieser Update Mechanismus schon auch sehr sehr aufwendig und ne Herausforderung für die jeweiligen Hersteller.Aber jetzt, für den Fall würde ich jetzt einfach mal drauf hoffen, dass da einfach n Update kommt und man sich da nicht groß drum kümmern muss, sondern einfach nur auf bitte updaten und fertig
00:32:52 Max Weil wir hatten noch ein drittes Standbein. Also das einen waren eben, was wir jetzt besprochen haben, wie geh ich mit Schwachstellen um, also sehr proaktiv. Auch möglichst häufig releasen ist wahrscheinlich auch hilfreich, wenn du zu lange brauchst, um halt was auszurollen oder überhaupt mal wieder nach Ewigkeiten live zu nehmen, dann kannst du diese Fristen ja kaum einhalten, die da gefordert sind. Aber da war ja noch die Sache mit mit der Dokumentation, was jetzt vielleicht nicht das die Lieblingsbeschäftigung ist eines Entwicklers, eine Entwicklerin, aber zum Teil machen wir das ja auch schon, aber was, was gibt es denn dafür? Änderungen mit dem CRA?
00:33:38 Sebastian Also der CRA fordert von den Herstellern, dass sie zukünftig eine Cyber Risikobeurteilung verfügbar machen. Es steht explizit steht drin in die technische Dokumentation mit aufnehmen müssen. Ich glaube tatsächlich, es gibt viele Teams, die sowas schon machen, aber auch es gibt bestimmt auch viele Teams von denjenigen, die es machen, die es nicht explizit dokumentieren. Das ist glaube ich, schon eine Veränderung, dass es jetzt mit zukünftig mit aufgenommen werden muss. Also ich muss mir Gedanken machen, welche Angriffsvektoren existieren, wie relevant sind die also üblicherweise sagt man dann ja Wahrscheinlichkeit mal Auswirkungen. Rechnet man dann aus und kann dann eben sagen okay will ich den jeweiligen Vektor entsprechend adressieren oder trage ich das Risiko jetzt mal so ganz salopp gesprochen und zukünftig muss das Halt schriftlich festgehalten werden und auf Verlangen der Marktaufsichtsbehörden dann im Zweifelsfall auch rausgereicht werden. Das macht also durchaus Sinn, da zukünftig drauf zu schauen und auch die Cyber Risikobeurteilung, die muss regelmäßig aktualisiert werden, doch das steht explizit im im CRA drin, das macht glaub ich auch Sinn, wenn man in der kontinuierlichen Entwicklung ist. Also wenn ständig neue Features dazu kommen, dann kann das durchaus sein, dass mit den neuen Features eben auch andere Angriffsvektoren auftauchen und dann sollte ich die irgendwo na ja dokumentieren. Wir haben halt aktuell keinen besseren Weg. Schöner wäre es natürlich, wenn ich irgendwie noch so ne Art Security Test hätte, das geht bestimmt für viele Konstellationen, aber manche Dinge sind dann auch sehr sehr sehr aufwendig zu testen, da muss ich aber sagen, na ja gut, ich hab es dokumentiert. Ich hab ne user Story, die User Story ist fertig. Und dann ist das Ding. Also dann nehmen wir zumindest an, dass es im Produkt drin ist. Wenn, dann hat der Pentest da irgendwie einmal drauf, schaut und sagt Nee ist in Ordnung wie es implementiert ist, dann ist man da glaube ich erst mal auf der sicheren Seite, aber das ist das, was an Dokumentation tatsächlich noch dazu kommen wird und es gibt die Konformitätserklärung, das heißt, ich muss tatsächlich auch erklären, inwieweit ich die Anforderungen vom CRA erfülle. Das Gute daran ist, das geht wie mit der CI-Kennzeichnung, die ja auch ganz oft in den Produkten eine Rolle spielt mit einer Selbstbewertung. Also ich muss mich quasi nur einmal hinsetzen, muss das Runterschreiben und hoffentlich muss man dann nicht mehr dokumentieren. Ich glaube, wir tun alle gut daran, die Dokumentation so gering wie möglich zu halten und trotzdem gesetzeskonform unterwegs zu sein. Trotzdem ist es jetzt erstmal. Was sind das so 2 Punkte zumindest die halt einfach erstmal mehr Arbeit verursachen. 00:35:54 Max In dem Zusammenhang höre ich auch auf den die Abkürzung s Bonn wohnst du dazu machst. 00:35:59 Sebastian Du ja Software Bilder mit. 00:36:01 Sebastian Ist die Übersetzung heißt einfach nur welche Abhängigkeiten hab ich in meiner Software? Kann man also könnte man theoretisch auch händisch erstellen, indem ich einfach alle meine Pom XMLS build.gradle oder was auch immer oder Package.json ich durchgehe und die jeweiligen Versionen aufschreibe, das hat nur den Nachteil wenn ich es manuell mache, dass ich halt nur eine Dimension. 00:36:24 Sebastian Bekomme und ganz oft hinter einer Bibliothek ganz, ganz viele andere stehen. Und dann? 00:36:29 Sebastian Sehr, sehr aufwendig deswegen. Ich würde es, wenn man über über ein Tool machen, also cyclo und EX wäre so ein Plugin, dass man einfach einladen kann jetzt auf Java Seite. 00:36:39 Sebastian Und es gibt meines Erachtens noch n zweites Plugin, das mir jetzt nicht einfällt. Das wär mal so, zumindest für die Java Geschichten ist das glaub ich relativ einfach, was dann noch irgendwann mit Reinspielt ist, wenn mein Artefakt, dass ich ausliefere ein Dockercontainer ist, dann müsste man sich ja auch Gedanken machen, welche Abhängigkeiten in diesem Dockercontainer tatsächlich drin vorkommen, deswegen bin ich n bisschen vorsichtig sich nur auf Cyclo und DX zu verlassen. Also es gibt durchaus auch andere Tools jetzt im Open Source Bereich glaube ich. 00:37:08 Sebastian Ist ein Blick auf Trivi vielleicht mal? Es wäre. Es wert, dass man einfach nur schaut. OK, was bringt denn das Ding so raus und ich meine sogar das Trabi auch feststellen kann, ob irgendwie Schwachstellen im jeweiligen Docker Image dann enthalten sind oder eben auch nicht. 00:37:22 Max Diese SBOM muss wahrscheinlich aber auch die Transitabhängigkeit enthalten, oder du sagtest so irgendwie eine Ebene, also wird nicht reichen, oder? 00:37:29 Sebastian Gesetzlich vorgeschrieben ist das nicht. Es gibt einen ziemlich komplizierten Text dazu. Es gibt also, der Gesetzgeber fordert nur bis zu einer bestimmten Ebene, aber prinzipiell diese diese Plugins, die können das meines Erachtens auch komplett auflösen, also den kompletten Baum ähnlich wie NPM, wie man, ob ich jetzt die Bibliotheken runterladen um meine Software einmal zu übersetzen oder ob ich das irgendwo denn in nem Dokument reinschreiben in bestimmten Form ist ja glaube ich auch nicht so viel Unterschied. Deswegen, wär auch noch mal n Grund dafür. Ja, also ich hab vorhin dieses Mini Projektchen erwähnt mit den.Eigentlich nur 2 Abhängigkeiten, aber das sind natürlich meta Pakete und dahinter hängen ich weiß nicht wieviel Abhängigkeit. Und das entsteht einfach schnell. Und da, glaube ich, sollte man sich auch nicht in die Irre führen lassen, dass man sich dann nur auf. Das verlässt was in den jeweiligen Bildtools oder Skripten? Dann steht ja.
00:38:18 Andi Weil Max ist vorhin angesprochen hatte, muss in der SPOM dann auch müssen, da auch dev dependencies drin sein, weil ich mein prinzipiell könnte da ja auch Code generiert werden, zum Beispiel der dann letztendlich in meiner Software enthalten ist, der dann wiederum Sicherheitslücken enthält. Sowas in der Richtung?
00:38:38 Sebastian Die ehrliche Antwort ist, ich weiß es nicht, ich würde es jetzt mal nicht erwarten. Also von Dev dependency ist es zumindest im ganzen Text erstmal nichts zu erkennen. Dev-Dependencies gelten ja normalerweise auch nur dann, also zum Entwicklungszeitpunkt, das heißt entweder auf der Entwicklungskiste oder in meinem CI System jetzt für eine sichere Softwareentwicklung gehört schon irgendwie dazu, dass ich Schwachstellen per se ausschließe und das eben auch in meinen Bildsystemen und in meinem Entwicklungssystem. 00:39:01 Sebastian Aber ich glaube, es ist vom vom CRA selber, diese nicht so detailliert unterwegs. Die sagen einfach nur es muss eine s Bahn zur Verfügung, also erstmal erstellt werden, das ist glaube ich der Wortlaut und auf Nachfrage von Marktaufsichtsbehörden und vielleicht auch von Kunden muss es dann rausgeliefert ausgeliefert werden, aber nur auf persönliche Nachfrage.
00:39:19 Max Frage steht da, was im Format, muss man es ausdrucken in dreifacher Ausfertigung oder?
00:39:24 Sebastian Also was mir spontan, also es gibt fixe Formate, also Recycling DX ist ja eine Möglichkeit, wie das Format definiert ist, wenn ich mich recht entsinne, dann steht zumindest drin, dass der Gesetzgeber es sich vorbehält, das Format individuell anzupassen. Das klingt jetzt so, als würden die alle nachschlagen, das Format ändern, das glaube ich jetzt nicht, aber zumindest behalten sie sich das Recht vor, Einfluss auf das Format zu nehmen, in der Zukunft zumindest. Also ich halte das für sehr unwahrscheinlich.
00:39:49 Max Wir hatten es, glaube ich, noch nicht konkret gesagt, aber es gibt ja dann auch, oder es werden in der CRA auch schon die menschlichen Konsequenzen genannt, wenn man sich nicht an diese Vorgaben hält, die ab dem und dem Datum gelten. Was ist da ungefähr so angedacht?
00:40:03 Sebastian Also der CRA spricht dann von Sanktionen, die eben bei Nichteinhaltung von verschiedene n Konstellationen ja zu Rate gezogen werden. Ich sag mal man muss dann schon mit Millionenbeträgen rechnen oder bis zu 2% vom letztjährigen weltweiten Gesamtumsatz und das sind dann schon ziemlich erschreckende Zahlen, die da im Raum stehen und ich meine aber auch es gibt eine gewisse Abstufung dabei also je nachdem wo man Verfehlungen hat wird es entweder teurer oder billiger Ich glaube insgesamt heißt, die Devise eher, man sollte nach Möglichkeit einfach nicht auffällig, sodass auch die Sanktionen einfach keine Rolle spielen.
00:40:41 Andi Das heißt aber auch, wenn ich es jetzt schaffe, meine Fressen einzuhalten und also selbst wenn ich quasi Schwachstellen habe und die schnell genug fixe, dann ist das auch fein und ich muss keine Millionenbeiträge zahlen?
00:40:51 Sebastian Ja, das wär die Hoffnung. Also wer ich glaube, den Sanktionen sollte man sich jetzt nicht zu sehr dran aufhängen, ich glaub das das Ziel, dass wir zumindest in Europa haben ist, dass wir einigermaßen sichere Softwareprodukte haben und ich also, was man so hört, ist ja auch bei den gesetzlichen Vorgaben. Jetzt sind ja auch die Fristen schon eher knackig für viele, also wenn ich wenn ich gut unterwegs bin, dann lächle ich müde über diese Fristen und sag, das ist überhaupt kein Problem, bin ich aber persisch. 00:41:18 Sebastian Dann sagen wir mal eher grenzwertig unterwegs bin, dann sind diese 2 Jahre, die ja hier eingeräumt werden, schon auch ziemlich knackig. Und was man so hört, ist es ganz oft auch schon ausreichend, dass ich zumindest eine Roadmap habe, die vielleicht auch über die Frist hinaus schon besteht, dann kann man auch schon eine ganze Menge wegdiskutieren. Es geht ja darum, dass wir insgesamt ein hehres Ziel haben und ich glaube, das ist schon ja, so Intrinsisch die Motivation sollten wir irgendwie schon mitbringen. Also wir hätten vielleicht erst noch mal drauf eingehen sollen. Was ist eigentlich ein? Produkt. Das ist, glaube ich, schon noch mal interessant. Also wie definiert sich ein Produkt? Was ich gefunden habe im im CRA ist, dass ein Produkt jetzt erstmal oder ganz oft einen Preis hat. Das fand ich ganz interessant. Also ein Produkt wird über einen Preis definiert und eine Gewinnerzielungsabsicht. Es gibt noch eine alternative Möglichkeit, wie man den Produkt definiert, nämlich dass man entgeltpflichtige Support Leistungen anbietet, das fand ich ganz spannend. Dazu kommt jetzt aber mit der CRA tatsächlich trägt gehört noch dann der Netzanschluss oder die sogenannte Datenfernverarbeitung, gehört damit dazu. Also wenn ich ein Produkt habe, das heißt, ich habe eine Sache, die einen Preis hat, und diese Sache hat ein Netzwerkanschluss. Dann bin ich oder irgendwie auch Einfluss auf das Netzwerk. Dann bin ich mir relativ sicher, dass es dann voll auf den CRA schlägt. Das finde ich ganz spannend. Also das ist so ein eine Definition, da habe ich jetzt auch irgendwie dreimal das ganze Ding durchlesen müssen und mir irgendwie raussuchen müssen, wie das ist. Ich glaube für jemanden, der mit der Juristerei nicht so auf du und du steht, ist das eine ganz eine ganz spannende, ganz spannende Definition, die ich jetzt so ehrlich gesagt nicht erwartet hätte. Man kann aber vielleicht auch sagen, was ich beim CRA so ein bisschen bemängele, dass es nicht nicht die grundlegende ne grundlegende Anforderungsdefinition für alle Softwareprodukte. Irgendwie ist für mich also es ist eingeschränkt auf Produkte und es hat auch ganz ganz viele Dinge die ausgeschlossen sind. Ich verstehe die Ausschlüsse durchaus, aber ich verstehe ehrlich gesagt nicht, warum man für Produkte eine spezielle Verordnung gebaut hat und nicht einfach gesagt hat, jegliche kommerziell genutzte Software oder vielleicht auch nur kommerzielle Software muss bestimmten Anforderungen entsprechen. Ich glaube, das wär viel einfacher für uns alle, weil wir dann auch insgesamt vermutlich die Anzahl an Verordnungen, Richtlinien und Gesetzen irgendwie reduzieren könnten, aber das also ist mir bisher noch nicht klar, was da die Logik dahinter ist, warum man das so so feingranular macht. Wir haben jetzt nur über den CRA gesprochen noch ein paar mehr Sonderverordnungen so nehm ich es einfach mal, die eben auf bestimmte Teilbereiche wirken. Ich nenn jetzt einfach mal Dora wär so etwas digital, Digital, Operational Resilience Act wär also eine andere Richtlinie, die eigentlich ähnlich wie der CRA ist, aber eben für die Finanz- und Versicherungsbranche gilt. Jetzt hätte ich erwartet, dass man eben gesagt, OK, ich leg erst mal Ne Basis wo ich sag OK erstmal ist alles drin und im Zweifelsfall kann ich irgendwas wieder rausdefinieren oder kann besondere Anforderungen für besondere Softwareprodukte oder besondere Branchen noch mal definieren. Da hab ich jetzt noch nichts mitbekommen, dass das tatsächlich so gedacht ist. Und ich glaube, es gibt schon noch n paar sehr eklatante Lücken in der in der Konfiguration oder in der Definition der Einzelnen der einzelnen Vorschriften.
00:44:52 Max Klingt alles interessant, aber trotzdem, Sebastian, hast du jetzt ja noch mal eine Definition für ein Produkt nachgeliefert. Das ist auch gut zu wissen, dass das dann doch in irgendeiner Art und Weise da drin beschrieben steht. Hast du eigentlich hier denkompletten CRA durchgelesen und wie anstrengend war das?
00:45:05 Sebastian Ja, ich fürchte, das gehört n bisschen dazu. Also es sind weiß nicht, es sind 80 Seiten, die kann man sich schon mal durchlesen, die sind auch zum Teil ganz interessant und wenn man es liest, dann muss ich ganz ehrlich sagen, also ich bin so zwischen Entsetzen und Begeisterung dann oft gewesen, ich glaub manche Dinge gehen n bisschen übers Ziel hinaus und sind durchaus herausfordernd und andere Dinge, da denk ich mir dann so, ja das ist eigentlich jetzt nichts Besonderes. Das machen wahrscheinlich die meisten schon, aber das ist dann wahrscheinlich auch die Kunst. Also so ein Gesetz genauso einzustellen, dass es den Sinn erfüllt und nicht über das Ziel hinausschießt, ist vermutlich sehr, sehr schwer. Aber ja, man muss es n paar Mal lesen, ich hab es glaub ich jetzt dreimal gelesen und jedes Mal wieder lese ich irgendwas anderes raus. Also das ist tatsächlich ziemlich faszinierend, da steht halt einfach viel viel drin. Aber es ist aber jetzt nicht so, dass es, also ich glaube, es gibt härtere Gesetzestexte als jetzt dieses Ding, und man kann ja auch den CRA, vielleicht können wir da irgendwo n Link auch hinterlegen, den kann man in allen möglichen Sprachen runterladen, das macht es also dann ziemlich einfach und ziemlich entspannt und ich gebe auch gern zu, ich hab jetzt auch nicht so hundertprozentig detailliert jeden Artikel gelesen, sondern eben nur die, die für mich in irgendeinem Verhältnis zur Software Entwicklung stehen.
00:46:14 Max Das wäre dann auch eine Anschlussfrage. Also CRA runterladen ist vielleicht auch mal interessant, aber was sind so die die ersten Schritte, die du jetzt uns als EntwicklerInnen ans Herz legen würdest? Sebastian, wie sollte ich mich im CRA befassen und vielleicht auch wann?
00:46:29 Sebastian Ich weiß gar nicht, ob ich mich auf den CRA versteifen würde. Also CRA haben wir schon gesagt, geht eigentlich nur für eine Produktentwicklung, also wenn ich an irgendeinem Produkt dran bin, sei es Hardware und Software oder sei es nur Software, dann ist der CAA wahrscheinlich Wand allerdings glaube ich mal eher um es mit dem Management zu diskutieren, welche Punkte denn aus welcher Sicht relevant sind, ich glaube, es macht mehr Sinn, sich ganz allgemein mit Security zu beschäftigen und ich nenne es mal die Hausaufgaben zu berücksichtigen, also welche ganz einfachen Dinge und Tasks kann ich tun, damit meine Software insgesamt ein Stückchen besser wird und im Laufe der Zeit wird man vermutlich dabei auch dann so viel an neuen Erkenntnissen gewinnen und vielleicht auch lernen, dass man daraus schon genügend ableiten kann. Der spannende Punkt, an dem man das mit dem CRA wieder verbindet, ist, dass man es eben entsprechend dokumentiert oder noch viel besser automatisierte Tests erstellt, die gewisse Dinge vollautomatisch prüfen. Ich würde mich also weniger mit dem CRA selbst als vielmehr mit dem Thema Security das Stichwort Security Champion oder etwas in dieser Art würde ich mich glaube ich eher mit beschäftigen. Ich glaube, dass es hilfreicher als als ich jetzt mit dem CRA selbst zu beschäftigen, trotzdem schadet es nicht. Also für alle die die schlecht schlafen können sich den CRA durchaus noch mal unters Kopfkissen legen, das hilft bestimmt. Ja, aber ich glaub also vielleicht noch ein Wort, dann zum CRA ich glaub bei dem CRA kann man ne ganze Menge mit Tooling lösen und das wären dann so die Dinge wo man sich glaub ich auch als Entwickler beschäftigen muss. Wenn ich jetzt an Kunden von uns denke, dann ist es auch ganz oft so, dass die Entwickler die Security viel präsenter haben als die tatsächlich POS oder Produktmanager oder wer auch immer die die Gesamtverantwortung für das Produkt jeweils haben. Das ist zumindest bei uns so runtergekommen. Also die Entwickler waren schon total hibbelig und aufgeregt, so Oh Gott, wir haben nur noch 2 Jahre Zeit und es gibt so viel zu tun und das Management hat immer gesagt ja sorry ich hab aber kein Budget dafür, wir können das jetzt nicht tun und das ist dann glaub ich so der spannende Punkt wo auch der CRA wahrscheinlich hilft. Also jetzt kann man als Entwickler natürlich irgendwie auf den CRA zeigen und sagen Hey guck mal diese und jene Anforderungen, die müssen wir jetzt mal angehen, wir haben da vielleicht gewisse Dinge im Team diskutiert, vielleicht auch irgendwo nicht formal festgehalten und das muss zukünftig eben dokumentiert sein. Und das ist wahrscheinlich dann auch der größte Nutzen von dem CRA. Also ich hab ja jetzt nicht nur positiv von ihm gesprochen. aber das könnte dann schon wieder helfen, dass man einfach auch jetzt von von der Basis her, also von den Entwicklern, die wirklich mit dem Tool zu tun haben und eben auch genau wissen, welche Stärken und Schwächen in den Dingen drin sein könnten, dass man daraus die Kommunikation und das das Gespräch suchen kann und einfach sagen kann, hey, wir haben ja noch ein paar Anforderungen, da müssen wir echt Gas geben, das muss nämlich bis zum, na ja, Dezember 27 muss das eben da sein, und so haben wir das tatsächlich auch kennengelernt. Also das war jetzt dieser CRA Schnelltest kamen n bisschen auch aus dieser Ecke heraus, weil die Entwickler gesagt haben, oh, wir wissen, dass da total viel im Argen ist und dass wir echt viel zu tun haben und von Management Seite kann man ja, aber ich habe keine Budgetfreigabe, es tut mir leid, wir können uns darum nicht kümmern und um das aufzulösen haben wir dann gesagt, Na ja, vielleicht hilft es das erst mal da Transparenz zu schaffen, also die Anforderungen aufzuschreiben, sich anzuschauen, wie stehe ich im Hinblick auf die bestimmten Anforderungen und zukünftig wird sich da jetzt auch was bewegen.
00:50:04 Max Gut, aber die die Hauptarbeit nämlich zusehen, dass man eben frei ist von Sicherheitslücken, die ist ja nicht umsonst. Im Gegenteil, das ist ja wichtig und das heißt, der CRA macht wahrscheinlich mehr Arbeit, aber zum Teil auch sinnvolle Arbeit. Und damit haben wir doch schon was, was wir den ZuhörerInnen an die Hand geben können und ich glaub, wir haben n ganz guten Überblick über die über den Cyber Resilience Act bekommen heute.
00:50:18 Sebastian OK, das freut mich.
00:50:19 Max Herzlichen Dank, Sebastian, für deine Einblicke.
00:50:20 Sebastian Sehr gern.
00:50:21 Max Danke, dass du da warst. Danke auch Andi fürs Co-Hosting.
00:50:25 Andi Gerne.
00:50:26 Max Ich möchte noch kurz ein Call-To-Action an unsere ZuhörerInnen richten, wenn ihr Feedback habt für uns, wenn euch diese Folge gefallen habt, wenn ihr neue Ideen habt, was man mal besprechen könnten, dann meldet euch, schreibt uns eine E-Mail an podcast-feedback@andrena.de und wir sehen uns dann wieder beim nächsten Mal bei andrena entwickelt und bis dahin ciao.
00:50:45 Sebastian Tschüss.
00:50:46 Andi Ciao.
[Musik spielt]