Der nachfolgende Text wurden mit KI erstellt und kann Fehler enthalten. Fehler gefunden? Bei GitHub editieren
Herzlich Willkommen zu einer weiteren Episode von Software-Architektur im Stream.
Dieses Mal live von der BED-Con mit Jochen.
Möchtest du dich kurz vorstellen?
Ja, mein Name ist Jochen Mader.
Ich bin Principal Engineer bei der HiveMQ GmbH, wo ich primär im Bereich IoT, Industrial Automation und dergleichen unterwegs bin und wir dort unseren Broker bauen und ich mich mit Themen von Softwareentwicklung bis Security täglich auseinandersetze.
Wir reden ja heute über das Thema Supply Chain Security.
Darüber hattest du auch gerade im Vortrag gehalten.
Ich hätte mich auch irgendwie reingesetzt.
Und so eine Frage, die sich jetzt irgendwie erstmal aufdrängt ist, was zum Teufel ist denn überhaupt eine Supply Chain?
Eine Supply Chain, also auf Deutsch Lieferkette für die Zuhörer, ist effektiv der Pfad, den ein Artefakt, eine Bibliothek oder dergleichen nimmt, bis es irgendwo in Produktion läuft und aktiv ist.
Wir reden hier von einer Bibliothek, die aus Abhängigkeit in eine Komponente gezogen wird.
Die Komponente wird in einen Container verpackt.
Der Container wird in die Infrastruktur geschoben und läuft dann dort.
Oder ich beziehe ein komplettes Binary und lasse es auf meiner lokalen Kiste laufen.
Auch das ist eine Lieferkette.
Also effektiv, ich habe irgendwo einen Upstream, von dem Komponenten oder Teile kommen, die ich dann in irgendeiner Form weiter verwurschte und irgendwo kommen sie dann und werden in Betrieb genommen.
Was für alle Softwareentwickler typischerweise tun.
Warum interessiert mich das?
Welche Arten von Angriffen gibt es denn da?
Da gibt es in letzter Zeit einige sehr gute Beispiele über Supply Chain Angriffe.
Der bekannteste war das XZ.
Das war ein Angriff auf die Person an sich.
Da haben wir gesehen, wie gut Open Source mit so etwas umgehen kann.
Das prominenteste sind wahrscheinlich so Attacken wie SolarWinds oder auch vor einigen Jahren die Attacken, wo über komprimierte NPM-Pakete von Upstream-Repositoren übernommen wurde oder kompromittiert wurde.
Ein Bitcoin-Miner eingeschleust wurde und plötzlich läuft ein Bitcoin-Miner im Browser mit.
Oder auch andere Angriffe, die da zurückgezogen werden.
Also irgendwo wird etwas manipuliert.
Ich ziehe es mir in mein Projekt mit rein, verwende es und habe dadurch entweder eine Lücke aufgemacht oder eine Funktion mit reingebracht, die ich nicht will.
Genau.
Und ich glaube gerade diese Sache mit den NPM-Abhängigkeiten, das ist ja etwas, was wahrscheinlich in der Softwareentwicklung tatsächlich für sehr viele Leute sehr relevant ist.
Wie soll ich sagen, diese XZ-Attacke, da ging es ja darum, Open-SSH zu kompromittieren.
Hat das eine Konsequenz für mich?
Hast du daraus selber gesagt, okay cool, ich mache etwas anders oder das ist hilfreich an irgendeiner Stelle?
Also für mich hat das Thema nochmal an Brisanz gewonnen.
Für mich war, muss ich ehrlich sagen, XZ eher ein Hebel, dieses Thema noch ein paar Leuten mit Gewalt in den Kopf zu pressen.
Es ist ja simpel einfach so, was sich zeigt, wir sind Software-Ingenieure heutzutage und es ist ein Segen für uns.
Wir haben sehr viele gute Implementierungen, Kryptografie, Netzwerktechnologien, Algorithmik und sowas, die wir als Bibliotheken uns reinziehen können.
Das ist ein sicheres Verfahren, als das Ganze mit selber zu bauen.
Jetzt ist es aber so, wenn eine Supply-Chain-Attacke passiert, wir denken immer, erwischt jetzt irgendjemand anderes.
Aber es ist zum Beispiel eine komplette Bibliothek kompromittiert.
Es ist nicht nur das Ziel, also wenn wir jetzt eine gerichtete Attacke an dem Punkt hatten, was betroffen ist, sondern viele andere auch.
Ich habe auch zum Beispiel das Beispiel mit Stuxnet gebraucht.
Es war ein gezielter Angriff auf den Iran, der dort durchgeführt wurde.
Stuxnet ist aber jetzt raus.
Die Lücken, die es ausgenutzt hat, sind raus und Siemens verzeichnet immer noch Angriffe auf die Infrastruktur, die damit gemacht werden, die überhaupt nichts damit zu tun hatten, was das ursprüngliche Ziel war.
Wenn eine Bibliothek oder eine Komponente upstream kompromittiert wird, sind alle Verwender betroffen.
Auch LXZ mit SSH.
Mag sein, dass es gezielt war als Betriebsspionage, aber es ist SSH kompromittiert.
Wir reden hier nicht davon, dass wir quasi nur bei diesem Ziel, sondern alle.
Wenn wir überlegen, wo wir SSH überall einsetzen, von unseren Verbindungen zu GitHub, wenn wir Repositories klonen oder updaten, bis hin zu Interaktionen mit der Cloud-Infrastruktur, alles SSH.
Natürlich sind wir betroffen.
Ja, weil du jetzt gerade diese beiden Beispiele nanntest, also vielleicht kurz zu Stuxnet.
Ich glaube, bei Stuxnet war es ja so, dass mehrere Zero-Day-Exploits, also nicht öffentlich bekannte Sicherheitslücken von Windows und von dem entsprechenden Siemens-Industrial-Zeug genutzt worden sind.
Das, was du jetzt sagst, ist, wenn ich das draußen habe, wenn man durch Analyse dieses Kurs herausfinden kann, dass man diese Probleme hat, dann kann man das auch ausnützen für andere Sachen, was eine Auswirkung ist.
Bei dem Exe ist es nach meinem Wissensstand so, dass eben diese Bibliothek Exe attackiert worden ist, die gar keine echte Abhängigkeit darstellt zu SSH, sondern irgendwelche Leute haben das zusammengebaut.
Ich glaube, du weißt es wahrscheinlich besser als ich, mit Systemdio oder so.
Die Frage, die ich mir jetzt stelle, und sorry, ich habe dich da vorher nicht gefragt, also wenn es so ist, dass diese Bibliothek, die kompromittiert ist, Exe, keine wirkliche Abhängigkeit von OpenSSH ist, kann ich dann überhaupt sowas mit Supply-Chain-Sicherheit versuchen zu lösen?
Das Problem ist, da bin ich jetzt auf dünnem Eis, weil Exe ein C-Ökosystem ist.
Ich bin ein primärer Java-Entwecker.
Wenn ich jetzt von der Java-Welt ausgehe, ich habe das Problem, wenn ich anfange, Dinge als Shadow zu bauen, das heißt also, wo ich sie shade und mit reinziehe, oder wenn ich sie zusammenkombiniere, dann sehe ich die Bibliothek nicht mehr.
Solange allerdings, wenn wir in der Java-Welt kurz bleiben, wir ein JAR haben, habe ich etwas, das überprüfbar ist.
Ich habe die Prüfsumme.
Im Zweifelsfall habe ich Zugriff auf die offiziellen Signaturen.
Ich kann überprüfen, ob die zu dieser Prüfsumme passen.
Solche Geschichten sind dann absolut möglich.
Aber die Java-Welt ist da transparenter, weil ich die Abhängigkeiten eigentlich fast immer sichtbar habe.
Ich muss mich echt anstrengen, dass die nicht da sind.
Die C-Welt ist da fieser, bei den Dingen, die dort möglich sind.
Okay.
Was also bedeutet, und ich glaube, das war auch ein wichtiger Punkt in deinem Talk, wir verlinken auch nachher noch die Folien in den Show Notes, ein wichtiger Punkt in deinem Talk war halt genau diese Geschichte mit der Verifizierbarkeit, dass man also sagt, okay, tatsächlich hat wer auch immer diese Änderung gemacht und es ist wirklich diese Änderung, die dazu geführt hat, dass dieses Binary entstanden ist und dadurch kann ich irgendwie diesen Attacken bis zu einem gewissen Maße halt sozusagen entgegentreten.
Jetzt könnte man ja sagen, also Abhängigkeiten sind ja sowieso einer von den Sachen in der Softwarearchitektur, die so ein bisschen doof sind, man könnte ja jetzt sagen, die Strategie dagegen ist, Abhängigkeit minimieren.
Das ist eine gute Strategie.
Das habe ich auch im Talk nochmal angesprochen.
Es ist zu hinterfragen, brauche ich diese Abhängigkeit wirklich, sich bewusst machen, was ziehe ich mir und warum ziehe ich es mir.
Das ist zum Beispiel, wir haben jetzt auch gerade den Fall, wir arbeiten mit einem neuen Edge-Produkt, ich muss wahnsinnig viele neue Bibliotheken mit Anschauung mit reinbringen und die erste Frage, die wir da ganz oft stellen, das ist, wie sieht die Maintenance der Bibliothek aus, können wir den Erstellern der Bibliothek in irgendeiner Form vertrauen.
Das heißt, wir beobachten, wir schauen uns sehr genau an, was wir reinziehen, weil wir am Ende wieder, wie gesagt, wir liefern dann ein kommerzielles Produkt aus, wir liefern ja das, was wir damit einbauen, eben mit aus.
Und das hat einen sehr starken Einfluss halt auch auf das, wie groß auch die Angriffsfläche ist, die man hat.
Also umso weniger Bibliotheken man natürlich da drin hat, umso besser.
Aber, und das ist halt auch das andere, ich habe vorhin auch das Beispiel gemacht, das ist so ein Segen, dass wir halt so Bibliotheken mit Kryptografie oder dergleichen erziehen können und sowas.
Ich habe halt in Diskussionen letztes Jahr dann plötzlich gehört von den Leuten zu sagen, ja bei uns im Unternehmen, wir bauen das Zeug selber.
Und das ist vollkommener Wahnsinn, weil ich beteilige mich als guten Ingenieur, ich würde mir im Leben nicht zutrauen, irgendwelche asymmetrischen Verschlüsselungsverfahren selber fehlerfrei zu implementieren.
Man muss halt wirklich, wie gesagt, Hirn einschalten, pragmatisch bleiben, so brauche ich jetzt diese Helperbibliothek, die mir irgendwelche einzelnen Helper halt macht, wirklich im Projekt?
Vielleicht nicht, aber Bouncy Castle ist nicht diskutabel.
Also das, was mir Bouncy Castle, also die Kryptobibliothek liefert und sowas, will ich nicht selbst, sondern werde ich nicht selbst.
Und da ist die Community viel besser daran.
Genau, weil also die korrekte Implementierung dieser Algorithmen ist eben nicht trivial.
Ich muss gestehen, bei dem Teil in dem Talk, ich fand die Aussage, wir bauen alles selber halt auch naiv, aus meiner Perspektive, weil, also ich habe hier jetzt einen Rechner vor mir sitzen, das ist halt eine Windows-Maschine, da ist ein Webbrowser drauf und irgendwelche anderen Sachen.
Ich vermute, die Anzahl der EntwicklerInnen, die daran gearbeitet haben und die Anzahl der Produkte, die jetzt da drauf gehen, die Anzahl der EntwicklerInnen sind sicher im fünfstelligen Bereich und die Anzahl der Produkte wahrscheinlich im vierstelligen Bereich.
Und wir sitzen halt eh in Abhängigkeiten und ich kann nicht alles selber bauen.
Ich kann nicht sagen, ich baue einen Computer und dann baue ich ein Betriebssystem drauf und so.
Und das ist ja auch noch, wir haben jetzt gerade immer nur über die Open-Source-Externfähigkeit, das ist ja auch im Unternehmen.
Also das ist ja auch so, wie ich noch im Consulting war und mehr mit den großen Konzernen zu tun hatte und sowas.
Das sind ja viele Bibliotheken auch innerhalb des Unternehmens, die ich als Abhängigkeit ziehe.
Wenn ich irgendwelche, zum Beispiel archaischen Soap-Integrationen, die immer noch im Umlauf sind und sowas, die will keiner neu schreiben.
Da gibt es ein Team, das das normal maintained und mir bereitstellt.
Interaktionen mit Mainframe-Systemen und dergleichen.
Es ist tatsächlich, ich vertraue gerne Menschen, von denen ich weiß, das ist ihr Job, die wissen, was sie da tun.
Oder einer großen Community, die Aufmerksamkeit an dem Ding dran ist und sowas.
Und dann delegiere ich auch dieses Vertrauen, weil ich halt sage, okay, man sollte auch selber seine Grenzen kennen.
Und ich weiß ganz genau, wo meine liegen.
Und dann ziehe ich mir da lieber die Dependency.
Genau.
Ich glaube, in diesem Bereich von Dependencies ist gerade sowas wie S-Bombs eine wichtige Technologie.
Magst du was dazu sagen?
S-Bombs?
Okay, vielleicht kurz zur Erklärung, was ein S-Bomb ist.
Genau, das war die Frage.
Ein S-Bomb ist ein Software Bill of Materials.
Also das ist quasi ein Rezept.
Also das ist eigentlich die schönste Beschreibung, die es gibt.
Das ist ein Rezept, das mir sagt, was steckt denn in der Software alles drin.
Und im Zweifelsfall sind da genug Informationen dabei, die mir sagen, wie wurde das Ganze denn dann zusammengestellt.
Warum S-Bombs?
Also jetzt als Software Engineer ist es jetzt nicht unbedingt notwendig, die S-Bombs zu ziehen.
Also wenn man JDK verwendet zum Beispiel, okay.
Aber ich ziehe meine Bibliotheken, die sind signiert und sowas.
Aber wenn ich jetzt zum Beispiel, wie in unserem Fall, wir haben ein Closed Source Produkt.
Und ich liebe das Produkt an einem Kunden.
Der Kunde weiß, es ist in Java gebaut.
Das heißt, wir haben alle die Log4J Vulnerability, die letzten zwei Jahre schon fast hier mitbekommen.
Die Kunden wollen wissen, bin ich betroffen?
Weil ganz ehrlich, ich würde auch niemals blind einem Provider vertrauen.
Auch wenn wir gut sind, da zu sagen, hey, wir sind nicht beperfektet oder hier ist ein Fix für das Ganze.
Zuallererst ist meine Infrastruktur und auch blindes Vertrauen setzen ist doof.
Jetzt habe ich einen Scanner und dieser Scanner konsumiert einen S-Bomb.
Und weiß jetzt zum Beispiel, Hyphen Queue in Version XY läuft auf meinen Systemen drauf.
Ich checke mal, was sind denn die Dependencies, die dieses Projekt verwendet.
Und dann sehe ich da aufploppen irgendwas.
Log4J nicht, aber es ploppert irgendwas auf, das sagt, da ist diese Dependency und da ist der folgende Non-CVE dafür da.
Dann hat im Zweifelsfall, kriegen wir einen wütenden Anruf oder eine Mitigation wird bereits vorgemacht, weil klar ist, dieser CVE wird auf diese Art und Weise ausgenutzt.
Wir können sofort reagieren.
Und das ist das, was die S-Bomb ist.
Die S-Bomb ist wirklich für die Downstream, also für die, die das Ding dann laufen lassen, zu sagen, okay, dieses Stück Software hat diese ganzen Komponenten.
Ich weiß das erst und das kann ich jetzt einem System füttern, Security Scanner oder sonst irgendwas, der dann basierend darauf sagt, wir haben hier ein Problem.
Okay, und das bedeutet jetzt, wenn ich jetzt sage, ich baue ein Stück Software, weiß ich nicht, einen E-Commerce Shop oder so, dann sollte ich für alle Systeme, die ich habe, einen S-Bomb haben und ich sollte ein Ding haben, was sich das anguckt und sagt, hey, du hast halt folgende Probleme und dann sollte ich sinnvollerweise reagieren, um das zu patchen.
Nicht ganz.
Okay.
Also nehmen wir genau das Beispiel im E-Commerce System.
Im E-Commerce System bist du selber Konsument.
Du gibst dir das nicht jetzt an den Kunden, weil der Kunde benutzt dir das, du bist der Betreiber.
Du hast eine Dependency-Liste.
Also Hive from Q zum Beispiel.
Genau.
Also wenn ich jetzt selber zum Beispiel mal bei uns schauen soll, ich habe ein Gradle-Build, wir haben unsere Renovate und die Dependent-Botlaufe, die uns sagen, was abzudaten ist.
Wir reden jetzt davon, das Produkt ist fertig und verlässt meine Hände.
Ich betreibe es auch nicht selber, sondern ich gebe es jetzt an den Kunden möglich weiter.
Die installieren das bei sich.
Die brauchen das S-Bomb.
Wir selbst haben ja die komplette Build-Pipeline in der Hand und wir kriegen die Informationen mit unseren eigenen Security-Scannern sofort geliefert.
Was also bedeutet, aber wenn ich jetzt Hive from Q benutze, würde das bedeuten, ich sollte halt von euch einen S-Bomb bekommen und sollte einen Mechanismus haben, der jetzt sagt, wenn dort ein Problem existiert, kriege ich das mit in euren Abhängigkeiten und ich kann dann reagieren.
Also wahrscheinlich eben ein Update von euch installieren und das sollte ich wahrscheinlich für alle Software machen, die ich so bei mir im Einsatz habe.
Genau.
Große Unternehmen machen das schon mit Software-Inventarisierung und wir haben auch immer die Anforderungen.
Also wir haben jetzt nicht S-Bomb, wir liefern andere Formate mit raus, wo quasi alle Dependencies mit Checksum und Lizenz halt drinnen stehen und das wird dort in die Systeme einfach reingezogen und die Systeme können dann ausweisen.
Zum einen wollen die wissen, was für Lizenzen.
Es ist nämlich ein zweiter Aspekt vom S-Bomb.
Es geht ja nicht nur darum zu sagen, okay, ich weiß, was drin ist, ich weiß, darf das auch da drin sein.
Habe ich zum Beispiel irgendwelche Lizenzmischungen mit GPL oder dergleichen, die nicht da sein dürfen?
Das ist nämlich auch etwas, was über einen S-Bomb abgeht.
Also ein S-Bomb hat mehr Funktionen als ausschließlich eben den Teil mit der Sicherheit.
Genau und das hattest du im Talk auch gesagt und das Problem mit GPL ist eben, dass die GPL-Lizenz sagt, wenn ich jemandem die Software in die Hand gebe, muss ich auch den Source-Code ausliefern und das wäre jetzt für euch als Close-Source-Produkt irgendwie suboptimal und deswegen dürft ihr eben in eurem Produkt keine GPL-lizenzierten Software haben, was also bedeutet, dass ihr das dann irgendwie entsprechenden NS-Bombs sozusagen abhandelt.
Wie soll ich sagen?
Ich hatte jetzt die Vermutung, also ich baue jetzt meine Anwendung mit irgendwas, da sind irgendwie auch diese Abhängigkeiten drin, dann muss ich wahrscheinlich irgendwie im Rahmen dieses Build-Prozesses diese S-Bombs von den anderen Produkten, also muss ich irgendwie auch eine S-Bomb sinnvollerweise erzeugen als Teil von dem Build-Prozess, damit ich eben mit meiner E-Commerce-Anwendung zum Beispiel sagen kann, ich selber habe folgende Abhängigkeit und wenn jetzt ein Problem da ist, dann kriege ich das halt mit und kann entsprechend agieren.
Wie gesagt, wenn du die E-Commerce-Anwendung selber baust, würde ich keine S-Bomb bauen.
Sondern, was mache ich dann?
Also wie kriege ich das hin, dass ich saubere Dependencies habe?
Okay, da müssen wir kurz anders ansetzen.
Jetzt nehmen wir wirklich den Fall, du baust deine eigene Software, du hast ein kleines Team, zwei, drei Entwicklerinnen, die da noch mit drin sind und ihr liefert halt das Teil, sagen wir mal, irgendeine Container-Runtime oder irgendetwas in der Gelegenheit.
Wie würde man das machen, damit es zum einen supply chain-sicher ist und halt auch security-abdeckt?
Das Erste ist, wir haben gesagt, es gibt Signaturen, dann baue ich da draus.
Das resultierende Artefakt signiere ich.
Wenn ein Container rauskommt, signiere ich den Container und ich erlaube der Infrastruktur, nur Container auszuführen, die so signiert sind.
Lass uns das kurz einmal detaillierter diskutieren.
Also das hat, glaube ich, zwei Auswirkungen.
Die eine Auswirkung ist, in der Laufzeitumgebung, wenn jetzt jemand das System komprometiert, Kubernetes komprometiert, kann der dort keine Container ausführen, die nicht aus meinem Bildsystem kommen, sodass eben die Angriffsfläche reduziert wird.
Also der ist trotzdem in einer blöden Situation, aber ich habe halt das reduziert.
Die Geschichte mit dem, also was ich aus deinem Talk gelernt habe, ist, dass Git kein richtiges User-Konzept hat.
Genau.
Deswegen will ich halt die Komets eigentlich signieren.
Das heißt, ich sage halt nicht, ich habe halt meinen eigenen Schlüssel, ich signiere das dann mit Kryptografisch, dann weiß ich das eben tatsächlich der Ebat, dass er kometet hat.
Warum interessiert mich das denn, wenn ich intern Software entwickle?
Also, jetzt muss ich auf die Bad Player kommen.
In der IT ist es so, wir haben sehr aggressive Recruiting-Strategien.
Also wir haben ja auch, wenn wir jetzt sehen, zum Beispiel jetzt, dass ich Arbeit in Startups, die meistens durch den Hyper-Growth gehen, das heißt, also jetzt aktuell bin ich als Nummer 40 eingestiegen, deswegen habe ich jetzt bei über 200 Leuten.
Ich war vorher schon bei Startups, da sind wir auch von 20 Leuten auf 300, 400 Leute gestiegen.
Zusätzlich recruten wir weltweit.
Gleichzeitig ist es so, Betriebsspionage ist ein Riesenthema in der IT.
Vor allem umso interessanter, umso näher man an Fertigung dran ist, umso näher man an vitaler Infrastruktur dran ist, umso interessanter wird es, dass jemand versucht reinzukommen in das Projekt.
Und das heißt, es ist nicht mehr monetär, das kann einfach sein, dass es staatlich finanzierte Angriffe sind und so was.
Oder halt auch bei XE vermutet man ja auch, dass da eine staatliche Entität dahinter steckt, die das halt mit motiviert hat.
Das ist das Problem, wir haben halt auch schon Fälle erlebt, wir haben Leute rekrutiert, die Leute bekommen Zugriff auf die Repositories, die wir haben und verschwinden nach drei, vier Tagen, ghosten uns.
Das ist zum Beispiel mit US-Entwicklern, das habe ich alles schon mal erlebt.
Jetzt ist es das Problem, dass wir in Git, dadurch, dass es kein Benutzerkonzept gibt, GitHub hat ein Benutzerkonzept, Git als Protokoll kennt keinen User, es kennt nur Metadaten.
Diese Person kann sich, wenn sie es sich schlau anstellt, vor allem in einem vertrauensvolleren Umfeld, sehr schnell einfach Commits irgendwo unterschummeln, wo andere Namen drinstehen.
Das kann ich nicht nachvollziehen.
Das heißt, wenn ich jetzt nachvollziehen will, ich habe jetzt jemanden rein, der war eine Woche oder zwei hier, verschwindet dann.
Woher zum Henker weiß ich, was in dieser Zeit passiert ist?
Ich kann es in Git nicht nachvollziehen.
Das heißt, oder jetzt auch bei XE, bei XE reden wir davon, dass dort zwei, drei Committer eben mit drin waren, die diese schadhaften Dinge mit reingetan haben.
Wir können es nicht nachvollziehen, weil ich weiß, XE nicht quasi die Verifikation gemacht hat.
Das heißt, wir haben jetzt diesen Blob und eigentlich muss man jetzt das komplette Projekt durchreviewen, um zu sehen, wurden irgendwelche Dependencies neu mit reingeschmuggelt, wurden irgendwelche versteckten Operationen mit reingemacht, die unsere bestimmten Bedingungen auslösen.
Wenn ich wirklich ein durchgängiges Signieren meiner Commits in den Repositories habe, gibt es diese Chance nicht.
Und ich kann es ja auch entforschen.
Ich kann verbieten in GitHub, dass ich sage, dass irgendwelche Commits reinkommen, die nicht signiert sind.
Und dann wird es viel, viel einfacher halt, solche Dinge schneller zu finden.
Und es geht wirklich darum, es ist ein Problem, das muss man halt auch einfach so sagen, dass Menschen aus aller Welt anstellen, die wir auch persönlich gar nicht kennen, was oft der Fall ist, besteht dieses Risiko.
Und das kann man in der heutigen Zeit einfach auch nicht mehr wegleugnen.
Ja, oder ich könnte ja geschickter sein.
Ihr stellt mich ein und ich sage, und ich mache halt irgendwie ein Commit mit deinem Namen.
Und dann ist das halt irgendwo geschickt versteckt.
Also gerade, wenn man sich halt XE anguckt, da sind ja die Angriffsvektoren in den Testdaten versteckt.
Also kann ich ja versuchen, ähnlich geschickt zu sein.
Und dann findet ihr das halt nie raus.
Wenn ich aber hingegen halt diesen Schlüssel halt habe, dann ist halt irgendwie klar, okay, der Eberth hat es gemacht.
Und der ist jetzt irgendwie weg.
Und irgendwie war der komisch.
Und dann gucken wir halt irgendwie nach, was er nun wieder gemacht hat.
Und dann ist es halt etwas einfacher, das mitzubekommen.
Was also bedeutet, dass diese Signaturgeschichte halt dann einen Vorteil hat.
Und ich fand es halt tatsächlich beeindruckend.
Du hattest halt gesagt, nicht?
Sauronatmordor.com kann ich da einfach reinschreiben.
Und niemand kontrolliert das jemals, ob das nun tatsächlich die Person war.
Ja, das ist tatsächlich das, was ich auch schade finde.
Mir fällt halt immer wieder auf, dass sich halt die Menschen, die mit dem Zeug arbeiten, oft viel zu wenig halt auch mit ihren alltäglichsten Instrumenten beschäftigen.
Weil es ist schon wichtig, dass man halt auch versteht.
Also ich komme halt ursprünglich noch, ich habe noch mit CVS angefangen und bin dann halt auf Subversion rüber und so.
Das sind halt Konzepte, da waren User-Konzepte halt mit drinnen.
Und man kommt dann aus dieser Welt und ich muss dann auch erst mal für mich neu lernen.
Ich habe es aber einfach auch nicht realisiert.
Bis ich irgendwann gemerkt habe, so Moment mal, ich kann ja einfach hier die Parameter ändern und dann bin ich komplett jemand anders.
Das ist ein Lernen und es ist wichtig, dass man sich mit diesen Sachen auseinandersetzt.
Weil das sind halt auch einfach die einfachsten Sachen und unser tägliches Werkzeug eigentlich.
Genau.
Und du hast da halt im Talk verschiedene Werkzeuge vorgestellt.
Da kann man das sozusagen im Detail nochmal irgendwie nachschauen.
Wenn wir bei…
So, was also jetzt bedeutet, sozusagen nochmal einen Schritt zurück, der Grund, warum wir jetzt signieren wollen, ist einmal, weil wir die signierten Container dann eben dadurch den Angriffsfaktor in der Produktion reduzieren und das andere ist eigentlich eine Absicherung gegen Menschen, die Zugang zum Source Code System haben und da signiere ich dann eben die entsprechenden Commits, um dafür zu sorgen, dass eben tatsächlich dort nur Menschen etwas haben, eher Commiten, was eben sozusagen geantwortet wird.
Ich würde es sogar noch vereinfachen.
Das komplette Konzept eines sicheren Supply-Chains ist, ich weiß zu jedem Zeitpunkt, wer, wann, was, wo.
Also ich kann sagen, wenn ich die Supply-Chain rückwärts gehe, ich habe ein Artefakt in der Hand, ich habe jetzt einen Container in der Hand, ich gehe auf die Signatur, über die Signatur kriege ich heraus, okay, das ist diese Version von dieser Person signiert.
Ich kann ins Git-Repository runtergehen, weil zum Beispiel in unseren Containern grundsätzlich immer der Commit-Hash mit rein, als Tag mit reingesetzt, also Tag oder Label, entschuldige, ich spreche gerade, weiß ich nicht, als Tag oder Label mit drin, das heißt also, ich kann jetzt sagen, okay, ich habe diesen, der ist von, jetzt kann ich da zurückgehen, dann sehe ich, okay, das ist dieser Stand im Repository und habe von dort die komplette Historie.
Das Ziel ist, dass ich wirklich, Git ist bereits Teil der Lieferkette, das ist der Anfang, dass ich wirklich von hinten nach vorne und von vorne nach hinten zu jedem Zeitpunkt zurückschlüsse ziehen kann, was es ist und ich mir sicher sein kann, dass das, was ich lese, auch richtig ist.
Mein Gefühl ist, ich bin ja auch kein Sicherheitsmensch, meine Daumenregel über Sicherheit ist halt, ich muss mir erst mal Gedanken darüber machen, was Angriffsvektoren sind und in welcher Situation ich bin.
Ihr baut zum Beispiel eine zentrale Infrastruktur, die ist halt bei irgendwelchen, du hattest gesagt, Industrieunternehmen im Einsatz, das heißt, euer Zeug könnte zum Beispiel das Ziel tatsächlich von sowas wie Stuxnet theoretisch sein, was irgendwie bedeutet, dass ihr eine bestimmte Art von Sicherheitsmechanismen machen müsst, um eben dagegen irgendwie abgesichert zu sein.
Ein E-Commerce-Shop ist anders, das heißt also, ein E-Commerce-Shop wird vermutlich nicht das Ziel von Stuxnet-Attacken sein, Stuxnet-artigen Attacken, also das Besondere da ist ja eben tatsächlich, dass wahrscheinlich Geheimdienste da etwas gemacht haben, weil einfach der Aufwand, der da reingeflossen ist, halt auf dieser Ebene ist und das ist bei Xerion ähnlich.
Deswegen finde ich es wichtig, zu verstehen, die Maßnahmen, die ich ergreife, unter welchen Bedingungen ergreife ich die und da hätte ich jetzt eben einmal gesehen, okay, ein Mensch tritt halt aus der Firma aus, ich bin mir nicht sicher, was der bei uns angerichtet hat, ich will das versuchen nachzuverfolgen, ich mache Committee-Git-Commits und das andere ist, jemand kompromittiert meine Laufzeitumgebung und ich möchte halt irgendwie nachvollziehen, ich möchte absichern, dass dort eben nichts anderes laufen kann und das scheinen die beiden Angriffsfaktoren zu sein, die ich halt mit diesem Signieren und diesem Vervollständigen sozusagen abfrühstücken kann.
Wenn man jetzt nochmal, der E-Commerce-Shop, wenn man da jetzt nochmal hinschaut zum Beispiel, ich würde den E-Commerce-Shop jetzt eher zum Beispiel auch als Downstream bezeichnen und zwar bist du, wenn du den jetzt wirklich baust, bist du Nutznießer einer funktionierenden Supply Chain.
Gehen wir mal zum Beispiel erstmal aus, die Attacken, die es halt schon vor Jahren gab, den NPM und halt auch andere, es tut mir leid, dass ich immer wieder NPM sage, es gibt genügend andere Ökosysteme, das Beispiel, das das gerade herauslockt, aber die Go-Welt war genauso anfänglich, die Python-Welt, da haben wir die gleichen Probleme gehabt, das ist jetzt nicht NPM-spezifisch, aber jetzt gehen wir mal einfach mal her und sagen, okay, warum wäre es jetzt für dich gut, wenn die Packages, die du bekommst, signiert sind?
Ich habe vorhin das Beispiel zum Beispiel mal gebracht, feindliche Repository-Übernahmen, die in GitHub passieren durch Social Engineering, teilweise werden die auch verkauft, es gab Grumpy Developers, die halt ihre Repositories verkauft haben und was dann halt passiert, es wurden irgendwann Artefakte released, diese Artefakte waren noch safe, die wurden mit einem Key signiert, sind in die Repository rein, du ziehst diese Version, jetzt kannst du dir sicher sein, okay, jetzt hat jemand das Repository übernommen.
Normalerweise kriegen die Leute die Schlüssel nicht in die Hand für die Signatur, normalerweise, kommen wir gleich noch drauf.
Das heißt, die neuen Artefakte haben plötzlich eine neue Signatur, sind mit einem anderen Schlüssel, jetzt sollten eigentlich alle roten Lichter angehen, wenn man in der Bildpipeline hochgeht, plus die Sicherheits-Tools, die man hat, die Pandabot und so, die können jetzt sagen, hey, diese Version, die neue Version ist nicht gut, lass sie nicht rein und das andere ist, wenn jemand versucht ist zu sagen, die Version zu ersetzen, was die meisten Repositories, also Artefakt-Repositories nicht zulassen, ist die Signatur anders.
Das heißt, was immer diese Person versucht hat durch das Kompromittieren, weil wie gesagt, nicht du bist das Ziel, wahrscheinlich viele andere sind das Ziel, aber du bekommst zumindest die Meldung, hey, ist fishy, ich kann das gerade nicht mehr bauen, das funktioniert nicht mit dem, was da eigentlich drinsteht.
Genau, das war eine Sache, die in deinem Talk sehr konkret war, du hast eben diese Abhängigkeiten, ich glaube, es war bei GitHub Actions, da hast du nicht gesagt, ich möchte halt diese GitHub Action in dieser Version, also Version 4.3.7 oder sowas, sondern du hast halt den SHA-Hash-Wert von der Version genommen, die Commit-ID, genau, was also dann bedeutet, dass, wenn jemand jetzt tatsächlich das Repository übernimmt, dass du dagegen abgesichert bist.
Genau.
So und das fand ich halt auch nochmal sozusagen eine spannende Sache, das ist eine relativ kleine Sache, aber sorgt eben dafür, dass eben das, was du gesagt hast, dass also jemand so einen Repository übernimmt, dass ich dagegen halt abgesichert bin, wäre also noch ein Angriffsvektor, gegen den ich mich absichern kann, aber da eben, indem ich diese kryptographischen Verfahren passiv nutze, also ich muss ja nicht selber die Artefakte signieren, sondern wenn ich halt etwas Opens rausstelle, dann sollte ich das tun, damit meine Leute, die halt das nutzen, entsprechend vorbereitet sind und die Daumenregel wäre halt, schreib nicht Versionen rein, sondern schreib eben solche.
Man muss sich halt klar machen, was bei vielen einfach nicht wirklich drin ist und sowas, ich kann Tags verschieben, also das ist ja, das ist, habe ich oft genug gemacht, wenn ich Releases kaputt gemacht habe, was mir halt leider auch passiert oder sowas, da habe ich fünf Releases gemacht, habe immer irgendwas vergessen, weil es nicht automatisiert war und habe dann halt fünfmal meinen Release Tag verschoben, dass der dann an der richtigen Stelle halt stand.
Die Commit-ID ist eineindeutig, ich kann das nicht mehr reproduzieren und dann eben den gleichen Inhalt bekommen und das gleiche ist auch mit Docker- oder OCI-Tags in Containern.
Ich gebe immer gerne das Beispiel, das sind alles flexible Tags, also wenn ich zum Beispiel einen Eclipse Timurin in Version 21 ziehe, dann ist das nur, ist die einzige Garantie, die ich habe oder was mir Timurin verspricht, wenn du dieses Tag ziehst, hast du immer den aktuellsten Linux-Unterbau plus einen 21er JDK, dass das Ding aber regelmäßig neu gebaut wird mit aktuellen dependencies, aber immer unter dem Timurin 21er Tag drinnen hängt.
Das kriegt man erst raus, wenn man irgendwann merkt, okay, ich habe Deltas, wenn ich das gleiche, wenn ich in ein paar Stunden das gleiche Image ziehe, sind die anders und das muss man sich verinnerlichen.
Solche Tags sind nicht den Stein gemeißelt, die sind flexibel und so werden sie auch genutzt.
Das ist auch Best Practice, was man so macht, aber man muss es halt verstehen.
Genau, du sagtest gerade, du hast Releases kaputt gemacht.
Das ist ein, wie wir alle glaube ich, das ist aber eine gute Überleitung zu dem nächsten Thema, was man diskutieren könnte.
Du hattest vorgestellt, JRelease und ReleaseDraft heißen die beiden Werkzeuge, die machen Releases.
Was bedeutet das und warum sollte ich das tun?
Was hat das mit Sicherheit zu tun?
Lieferketten leben grundsätzlich von der Automatisierung.
Die Automatisierung muss so früh wie möglich einsetzen.
Wenn ich ein Artefakt erzeuge, möchte ich es auch reproduzierbar erzeugen.
Es gibt noch einen Fortgeschrittenepunkt mit reproducible builds, aber es geht in der Pipeline noch schief.
Ich möchte das gleiche Artefakt noch mal erzeugen können.
Das kann ich nur, wenn ich sage, ich habe einen Ablauf, den ich komplett reproduzieren kann.
Das zweite ist der Geschwindigkeitsaspekt.
Ich habe den Talk heute mit dem Hintergrund gegeben, wenn es um Bibliotheken geht, die nicht oft geupdatet werden.
Wenn ich zum Beispiel in den Automatisierungsbereich gehe, im SCADA-Umfeld, ich kämpfe mit, wir benutzen Java-Bibliotheken, die drei, vier, fünf Jahre alt sind.
Das ist kein schlechtes Zeichen.
Wir benutzen Standards, die in den 90ern definiert wurden.
Die sind nun mal fertig, da gibt es nichts mehr zu ändern.
Jetzt ist es aber so, dass trotzdem einige von denen transitive Dependencies, also Abhängigkeiten mit reinziehen.
Wenn dort jetzt eine Lücke drin ist, wenn da jetzt ein Problem drin ist, wie reagiert die Entwicklerin, die die Library bereitstellt?
In den meisten Fällen, ich habe das Ding vor drei Jahren mal released, wie war denn das?
Und dann geht die Forschung los.
Man sitzt die nächsten Stunden, die wahrscheinlich wertvoll sind, weil in der Zwischenzeit ein Exploit unterwegs ist, das rauszukriegen.
Plus, wenn ich jetzt mal etwas größer denke, ich bin jetzt in einem Team mit sieben, acht Leuten, das übliche, faszinierende Szenario, die vier Hauptleute, die das ganze Ding geschrieben haben, sind nicht da.
Es ist nur noch eine Junior-Entwicklerin da, die gerade letzte Woche angefangen hat.
Sie updatet jetzt die Dependency und jetzt muss sie die Bibliothek noch releasen.
Meine Meinung ist, jedes Stück Bibliothek, das ich bereitstelle oder Komponente, die ein Downstream-Konsumenten hat, muss automatisiert sein und jedes Teammitglied von Product Management bis hin zu Junior-EntwicklerInnen oder sonst irgendetwas muss diesen Release-Schalter betätigen können, ohne dass da ein großes Hexenwerk dahinter steckt.
Genau, was also bedeutet, dass eben die Geschwindigkeit der Reaktion, glaube ich, dadurch, das ist halt der wesentliche Punkt.
Du hattest es ja gerade eben gesagt, wie soll ich sagen, Classical Releases sind so ein bisschen ein Klassiker, wo man Fehler macht, mein Gefühl, weil man es eben, du so richtig sagst, ja nicht so häufig macht und das automatisieren macht tatsächlich viel Sinn.
Es darf nicht wahr sein, von YouTube, interessanter Handel, er schreibt, wie häufig ist sowas, ich weiß nicht, worauf er oder sie sich da bezieht, das größere Problem zum Umgekehrten, wenn man nicht schnell genug auf eine Version updatet, wo irgendwo ein CV gefixt wurde.
Ich bin nicht sicher, was halt los ist.
Ich glaube, da geht es um das Update-Delay, also ich glaube, ich verstehe die Frage.
Es geht wahrscheinlich einfach darum, wie lange es halt oft dauert, dass dann auch alles geupdatet wird.
Und da muss ich tatsächlich sagen, das teile ich nicht ganz in den Bereichen, in denen ich unterwegs bin.
Das ist normalerweise so, dass sehr, sehr schnell geupdatet wird, insbesondere wenn CVs im Spiel sind.
Ich habe das bei Lock4J gesehen, ich habe noch nie gesehen, dass Dinge so schnell upgadatet und ausgerollt wurden, aber es stimmt durchaus, es gibt immer wieder, auch in Unternehmen, also das ist vor allen Dingen Unternehmen, die älteren Software-Entwicklungsphilosophien anhängen, die panische Angst davor haben, also wenn ich jetzt überlege, das ist auch der Bias, den ich momentan habe, ich lebe in einer Welt, wo alles automatisiert wird.
Wir haben immer bis von Infrastruktur über Terraform bis Ausrollen und alles und sowas, das ist bei uns alles halt automatisiert, also wenn ich eine neue Version ausrollen will, dann ist das meistens ein Commit und das Ding rollt durch.
Wenn ich jetzt in Unternehmen reingehe, die halt einfach die letzten zehn Jahre verpennt haben, was leider viele große Unternehmen halt auch getan haben, dann ist es so, dass dort die Releases im Halbjahr getaktet werden und die einfach auch keinen Pfad haben, das so schnell zu machen.
Das entschuldigt es nicht, aber es erklärt es.
Also das ist auch das, worum ich immer sage, mit Automatisierung und auch, ich bin auch der Meinung, dass jedes Stück Software, das in einem Live-Betrieb ist, implizit continuous deployment ready ist, weil in so einem Fall muss eigentlich deployed werden, aber dann kommen halt die Unternehmen, die es nicht können, weil die einfach sagen so, geht nicht.
Und das ist vielleicht ein guter Hinweis, also dass man dadurch eigentlich irgendwie Security problemmäßig einführt und ich muss auch gestehen, also eine interessante Frage, die man hier stellen kann, ist, es gibt so bestimmte Sachen, also Geldautomaten fallen mir ein oder auch irgendwie die Maschinen an einem Laufband, Quatsch, an einer Produktionsstraße, wo es halt schwierig ist, diese Updates on the fly zu machen, was ja eigentlich impliziert, nachdem wir halt über diese Release-Werkzeuge gesprochen haben, dass das halt gute Ziele sind für Cyber-Attacken.
Ja.
Genau.
Ja, und im Fertigungsumfeld ist das tatsächlich auch ein Problem, also da reden wir halt auch ein bisschen davon.
Also wenn ich jetzt gerade gucke, wir haben zum Beispiel gerade für unseren Edge, haben wir eine Ankopplung an die S7-Module von Siemens, das waren die, die von Stuxnet attackiert wurden und diese Module sind von 1996, die sind noch bis 2033, werden die aktiv supported von Siemens.
Die Software kriegen wir nur noch zum Laufen mit Windows VMs, die halt auf Windows 7 laufen, weil die Software auch so alt ist und nicht mehr gepflegt wird.
Das heißt also, das ist tatsächlich ein gravierendes Problem und da muss man halt, und da ist halt leider dann, den Drops muss man lutschen, da muss Security auf anderen Wegen halt gebracht werden, man muss sich mit solchen Angriffsszenarien anders auseinandersetzen.
Cloud-Welt tickt da natürlich vollkommen anders und da erwarte ich, das ist auch die Grunderwartung, dass das vollautomatisiert ist.
Genau, vor einiger Zeit ist ja auch die legendäre Stellenanzeige von der Bahn, war es glaube ich, die… Windows 3.11-Verwirkung.
Ja, großartig.
Genau, für Windows 3.11-Menschen.
Okay, es darf nicht wahr sein, hat geschrieben, vielen Dank für die Antwort, das klang jetzt etwas aggressiv, aber ich war wirklich interessiert an Statistiken.
Ich glaube, die Folgefrage oder der Folgehinweis ist dann, gibt bessere Info darüber, was halt gemeint ist.
Soll ich lieber Commit-Hashes fixen oder immer auf Latest-Pointen?
Also, ich glaube, der Punkt ist halt, also ich verstehe das so, wenn ich jetzt irgendwie reinschreibe, ich habe diese Dependency mit diesem Commit-Hash, dann habe ich halt Schwierigkeiten, aktuell zu bleiben, während wenn ich sage, ich habe irgendwie das Letzte oder, du hast es ja selber gesagt, also die Eclipse-Java-Version wird dann ständig geupdatet, das ist ja ein Feature möglicherweise.
Das es schon gibt, also das mit dem Latest, also Latest ist toxisch, weil Latest ist wieder fluent.
Also ich muss eigentlich zu jedem Zeitpunkt wissen, was ich im Betrieb habe, aber die Frage kam nämlich auch aus dem Publikum und die Antwort ist ganz einfach, Dependabot kann es.
Dependabot kann… Ach so.
Also, wenn man die Commit-Hashes drin hat, das ist für mich jetzt erstmal zu sagen, ich bin gefeilt dagegen, dass das Repository, dass da irgendein Schmarrn passiert.
Dependabot, wenn ich aktiviere, analysiert die Git-Action und sagt mir, okay, er kennt den Git-Hash, schaut, okay, das ist dieses Tag, oh, es gibt ein aktuelleres Tag, magst du nicht updaten?
Also man kann das… Unter der Voraussetzung, dass es eben ein Problem gibt.
Ich glaube, Dependabot sagt das nur, wenn es ein Problem gibt, oder?
Dependabot macht grundsätzlich Aussagen über neue Versionen, das kommt davon, wie man einstellt.
Also das kann man alles konfigurieren, aber bei CVEs springt das auf jeden Fall an, aber zum Beispiel, ich habe mir halt auch angewöhnt, ich bin immer in einem Rennen nach vorne.
Also ich versuche Bibliotheken, weil das andere Problem, das ja auch noch ist und sowas, wer mal längerfristig an Projekten gearbeitet hat, wenn man Bibliotheken zu lange nicht updatet und dann plötzlich ein CVE kommt.
Viele Bibliotheken sind nicht lustig, was Semantic Versioning angeht, das heißt, wenn ich nicht konstant am Updaten bin meiner Bibliotheken und ich plötzlich einen großen Sprung mache, wo ich zum Beispiel Änderungen von zwei Jahren reinziehen muss, weil ein CVE halt in der aktuellen Version gefixt ist, habe ich in den meisten Fällen größere Probleme.
Das heißt, mein Ziel ist eigentlich, dass ich konsequent die Versionen updatee.
Also ich mache fast jede Woche einen Run durch die gesamten Projekte, um zu sehen, wo kann man hochdrehen.
Da gibt es so ein paar Kandidaten, wo man vorsichtig sein muss.
Also Netty ist da so ein Kandidat, großartige Bibliothek, aber die verstecken halt manchmal in einem Patch Release Dinge, wo einem die halbe Infra um die Ohren fliegt.
Aber grundsätzlich ist das Teil eigentlich der Grundprojekt-Maintenance zu schauen, dass die Bibliotheken weiterlaufen.
Ja und umgekehrt, also wir diskutieren ja jetzt sehr stark über diesen Sicherheits-Impact, aber ich glaube ein anderer Punkt, warum man Abhängigkeiten ja auch aktiv managen will, ist, damit man eben dasselbe Ding bekommt und nicht plötzlich irgendwie Fehler reinbekommt, weil die Abhängigkeit sich schweigend geändert hat.
Das versuchen wir genau auszuschließen, das ist ja genau das.
Und das erreichst du ja dadurch, dass du halt irgendwie sagst, okay, ich habe diesen manuellen Prozess und ich gehe da halt irgendwie durch und gucke halt nach, was sind die Änderungen beziehungsweise Tool unterstützt.
Und da wäre halt eine mögliche Antwort auf diese Frage von, es darf nicht wahr sein.
Eine mögliche Antwort wäre also, ich will das sowieso aktiv managen, damit ich irgendwie eher konservativ bin und eben die Software, die halt garantiert funktioniert, nicht unabsichtlich durch etwas ersetze, was eben dann nicht funktioniert.
Genau, das finde ich ist eine gute Sache.
Das mit dem Signieren haben wir schon diskutiert.
Du hattest jetzt gesagt, dass man das mit diesen YubiKeys macht, magst du das kurz erläutern?
Was ist das?
Warum will man das benutzen?
Also da vielleicht jetzt auch noch, ich habe zwei Signierpfade, zwei Signaturpfade erklärt.
Also bloß kurz, also für die, für die es interessiert, guckt euch Sixdoor an, also die Slides von TalkBand auch noch hochgeladen, dieses Ökosystem, das ist der eine Pfade, das ist der niederschwellige, wo ich fast nichts dafür tun muss, um gültige, gut sicheres Signaturen zu bekommen.
Ich bin jetzt schon deutlich länger dabei, auch beim Signieren von meinen Artefakten und alles und nutze halt GPG relativ aktiv.
So, jetzt ist da für mich das und sowas, so ein GPG-Schlüssel hat mehrere Eigenschaften, der kann zum Signieren verwendet werden, ich kann aber auch SSH-Schlüssel und alles ableiten, also ich habe mehr Nutzen.
Und jetzt kommen wir dann zum YubiKey.
Das eine ist, ich habe kein gutes Gefühl, wenn ich meine Signaturschlüssel auf dem Rechner habe.
Es liegt einfach daran, die Signaturschlüssel können in den meisten Fällen relativ einfach verwendet werden.
Ich habe, es gibt so viel von Keyloggern bis irgendwelche, ich installiere mir irgendwann Schmarrn mit rein, probiere ein Shell-Skript aus, das kann allen möglichen Schmarrn machen.
Wenn ich meinen Schlüssel zum Signieren ausschließlich auf dem YubiKey habe, YubiKey hat einen Schalter, mit dem ich die Signatur aktiviere und wenn ich diesen YubiKey abziehe, passiert auch überhaupt nichts mehr.
Plus, der YubiKey meiner ist eingestellt, man gibt den Pin dreimal falsch ein und dann ist der Schrott.
Also ich, dann kann ich ihn auch nicht mehr wiederherstellen.
Das heißt, ich habe halt eine zusätzliche Sicherheit dafür.
Es ist immer noch besser, seinen GPG-Schlüssel lokal auf dem Rechner zu haben, als gar keinen zu haben.
Aber die gesteigerte Sicherheit ist jetzt zum Beispiel mein Laptop.
In dem Moment, ich kann meinen Laptop hier, den kann ich jetzt hier im Raum liegen lassen, gehe raus, ich habe meinen YubiKey mit weggepackt, kann niemand was mit anfangen.
Und ich habe halt den Mehrnutzen noch mit, weil ich bin ein fauler Mensch, ich bin ja auch der Meinung, dass Sicherheit angenehm sein muss.
Ich habe meine Token-Generatoren mit drauf, meine SSH-Schlüssel, ich schließe das Ding halt an, ich kann damit halt alle meine Aktionen machen und wenn ich es abziehe, ist es halt essig.
Kann niemand was damit anfangen.
Was kostet so ein Ding?
Boah, die gehen bei 20 Euro los, es kommt auch immer darauf an, was man als will.
Also da kann man sehr weit nach oben gehen mit Zahlanschlüssen, es gibt jetzt die neuen mit biometrischen Schutz, also Fingerabdruckscanner mit drin ist.
Ich bin auch, also ich werde nicht bezahlt von YubiKey, das muss ich nur betonen, aber wir haben jetzt einige Varianten der Keys durch und YubiKey und mir geht es immer noch darum, einfach, ich will ein einfach zu nutzendes Ökosystem.
Sie haben das Stabilste von allem und auch das, was die liefern, funktioniert halt.
Wir haben mit anderen Keys einfach massiv Ärger gehabt mit der Funktionsweise.
Und was mache ich, wenn das Ding kaputt geht?
Das ist auch eine gute Frage.
Es gibt zwei Strategien.
Es gibt die ultimativ sichere Strategie, die ist zu sagen, ich erzeuge meinen GPG-Schlüssel auf dem YubiKey.
Stirbt der YubiKey, ist mein Schlüssel weg, für immer.
Ich werde nie wieder diesen Schlüssel zurückbekommen.
Es gibt Strategien, die man da machen kann, es ist aber alles deutlich involvierter.
Ich mache das so, ich habe einen separaten Rechner, auf dem habe ich mein TPG Key erzeugt.
Ich lasse den da aber auch nicht drauf.
Zum Beispiel, ich habe das mit einer Linux-Hotboot-USB-Stick gemacht.
Ich habe den auf eine Blu-ray gebrannt, mit einem Schlüssel Volumen und weggeräumt.
Sollte mein YubiKey draufgehen, kann ich den reproduzieren.
Was eben bedeutet, das ist ja eigentlich auch in gewisser Weise ein Kompromiss, den du jetzt eingehst und das ist genau diese Abwägung.
Das heißt, wenn jetzt jemand diese Blu-ray klaut, gibt es halt ein Problem und da nimmst du eben an, dass das nicht passieren wird.
Ich bin ein Mensch, ich versuche meine Risiken richtig abzuwärts.
Wenn jemand in mein Haus einbricht, mein alles durchwühlt, um an diese eine DVD ranzukommen, dann habe ich ein anderes Problem.
Wir reden ja auch die ganze Zeit davon, es ist eine allgemeine Bedrohungslage, wo wir auch oft kollateralschädend sind.
Du hast einen Hauptangreifer und die anderen werden einfach mit erwischt.
Das ist nun mal so, dass die wenigsten Attacken wirklich komplett gerichtet sind.
Natürlich gibt es die auch und ich werde auch nicht als Person angegriffen.
Das heißt, ich gehe jetzt davon aus, dass mein Haus oder mein Büro nicht das Angriffsziel ist, sondern dass das Leute, die irgendwo sitzen, versuchen, meine Maschine anzugreifen von außen.
Und eben random sagen und sozusagen eher so Schrottschuss-Sachen machen und nicht so gezielt etwas tun.
Als du das im Talk gesagt hattest, kam bei mir wieder genau diese Geschichte mit den Angriffsfaktoren.
Du nimmst an, dass nicht ein Geheimdienst kommt und sagt, der Jochen Mahler, das ist jetzt unser Ziel.
Dagegen sichern wir uns irgendwie nicht ab.
Und das ist, glaube ich, ein ganz wichtiger Punkt.
Und das ist, glaube ich, auch für mich ein total wichtiger Architekturpunkt.
Das ist ja auch mit den Qualitäten so ein Thema.
Ich muss irgendwie wissen, was ich bauen will, was meine Constraints sind, damit ich das richtig umsetzen kann.
Und die Geschichte mit dem Bitcoin-Minern haben wir auch schon gesagt.
Es kam dann nach dem Talk noch jemand und hatte gesagt, als Junior-Entwicklerin will man eigentlich sich um dieses ganze Thema nicht mehr kümmern.
Wie weit sind wir denn davon entfernt, dass man sich darum nicht mehr kümmern muss?
Ich muss dich korrigieren.
Er hat nicht gesagt, er will sich nicht darum kümmern, aber er weiß als Junior-Entwickler nicht, wo er anfangen soll.
Also er hat ja ganz konkret auch gesagt, jetzt fange ich da irgendwie an.
Er hat sich selber auch als Junior bezahlt.
Wie kriege ich da meinen Einstieg?
Zum einen sage ich, okay, Junior-Entwicklerinnen haben eh schon das Problem, wahnsinnig viel Zeug, das da auf einen Einbringer und Softwareentwicklung zu lernen, von Architekturkonzepten, Threading und sonstigem.
Da ist natürlich jetzt, sich um das Außenrum zu kümmern, weniger Priorität.
Man kämpft mit ganz anderen Sachen.
Das ist auch fair.
Also man kann nicht erwarten, dass ein Mensch jetzt anfängt zu arbeiten und alles beherrscht.
Ich sehe da Leute wie dich, mich, uns alle, alle, die irgendwo Senior Aufwärts sind, die Senior Staff, Principal, sonstiges im Titel haben, die sehe ich in der Verantwortung.
Erstens, das Interesse zu wecken, dass man sich die Dinge, mit denen man arbeitet, genauer anschaut und zum anderen halt auch Wert darauf zu legen, dass das getan wird.
Also wenn ich jetzt gucke, wir sind in vielen Ökosystemen wirklich sehr, sehr weit.
Also ich habe zum Beispiel, ich habe mehrere Jahre Go gemacht.
Wir haben dort den Wechsel vom alten System, das hinten und vorn keine Sicherheit geboten hat, zu Go-Mods, die deutlich sicherer sind, die viel, viel mehr halt auch liefern halt in der Sicherheit quasi, was ich mitziehe.
NPM hat sich deutlich verändert.
Die Java-Welt ist seit 20 Jahren schon an einem sehr guten Punkt, eben mit Maven Central, mit den Regeln, die da drin sind, mit den Signaturen, die da mit drin sind.
Oft reicht es, die Leute darauf hinzuweisen, hey, wenn du das tust, gibt es diese Gefahr.
Du bist in diesem Punkt sicher.
Pass bitte auf, dass du nichts tust, was davon abweicht.
Das ist oft schon die Information, die reicht.
Und dann ist es meistens so, wir sind Engineers, dass dann die Neugier halt auch kommt und man sich die Sachen auch anschaut.
Zumindest das ist meine Erfahrung in den Teams, wo ich dann so erkläre, wie sieht denn eigentlich die Security bei einem Gradle oder bei einem Maven Build eigentlich aus, wenn ich dort mit den Defensives arbeite.
Aber wie fange ich jetzt an?
Also was wäre aus deiner Sicht das, was am wichtigsten, am notwendigsten ist?
Das Signieren, also du hast gesprochen über das Signieren, glaube ich, das ist halt ein Thema.
Du hast gesprochen über diese Geschichte mit den Releases, was wir vorher diskutiert haben.
Wir haben gerade eben über S-Bombs und Abhängigkeiten und so was gesprochen.
Worauf sollte ich mich fokussieren oder wo ist der erste Ansatz, den ich halt wählen sollte?
Also wie gesagt, der erste Ansatz ist und bleibt bei mir Git.
Also das ist das Erste, was jeder Engineer verstehen muss, dass das die Sicherheit ist.
Dann kommt es aufs Ökosystem an.
Aber okay, also lass uns da kurz verweilen.
Das überrascht mich jetzt, weil du sagtest halt, also ich habe immer noch im Hinterkopf nicht so ein typisches generisches Projekt, also für mich so ein E-Commerce-Shop oder so.
Damit sichere ich mich ja in Anführungsstrichen nur dagegen ab, dass halt ein interner Mensch böse ist und ich später herausfinden will, was er überhaupt gemacht hat.
Ist das echt mein größtes Problem?
Ist der E-Commerce-Shop das letzte Projekt, das du in deinem Leben machst?
Also ich hoffe nicht, aber wer weiß.
Es geht darum, sich einfache Dinge anzugewöhnen und zur zweiten Natur zu machen.
Ich habe das Signieren gelernt, als ich in einem größeren Open-Source-Projekt zum Committer wurde.
Damals bin ich bei der Eclipse Foundation Member geworden und musste anfangen, alle meine Arbeiten zu signieren, weil mit der Signatur, die ich dort in Git hinterlasse, halt auch eine Abnahme passiert ist.
Damit habe ich auch gesagt, okay, ich gebe alle Rechte an meinem Code an euch ab.
Seitdem habe ich mir angewöhnt, alles zu signieren.
Ich habe einfach gesagt, das ist ja kein Problem.
Ich habe immer meinen Ubiquitor mit dabei.
Dieser Tapper stört mich nicht.
Ich habe die Hürde, die Initiale zu überlegen.
Wie ich signieren möchte, habe ich schon genommen.
Und ab dem Zeitpunkt ist alles, was ich auf Git mache, habe ich signiert.
Alles.
Es wird zur zweiten Natur.
Du hast recht, jetzt in einem E-Commerce-Shop wird es im ersten Moment wahrscheinlich nicht so viel bringen.
Oder werden wir auch mal einen Bad Player ausschießen.
Ich weiß nicht mal mehr, wie viele Projekte ich in meinem Leben gebaut und gemacht habe.
Und es geht darum, dass das Best Practices sind.
Das sind einfach Dinge, die ich mir angewöhne und ab dem Zeitpunkt immer tue.
Also wie Testschöpfen, die Verlockungen dort ausmachen?
Zum Beispiel.
Auf diesem Level sehe ich das, weil in dem Moment, wo man nicht mehr darüber diskutieren muss und das zu erklären muss, in dem Moment, wo es die Mehrzahl auch macht und auch die Leute realisieren, ist es ja gar nicht so schwer.
Ab dem Zeitpunkt habe ich ja schon mal das Grundniveau der Sicherheit erhöht, weil ich die Nachvollziehbarkeit erhöht habe.
Und dann in den Ökosystemen ist es wichtig.
Ich bin schon der Meinung, Juniors haben das halt nicht im Blick, weil es einfach andere Probleme sind, mit denen sie kämpfen.
Aber es sollte schon irgendwo – und das war auch zum Beispiel bei uns das Lustige, als wir das für die Cloud gemacht haben.
Da habe ich unser UI-Team gefragt und ein grinsender Kollege hat gesagt, hey, ich habe noch gesehen, was du da in der Cloud machst.
Das habe ich schon lange gebaut.
Dann hat er den NPM auch schon, die Signaturverifikation und alles aktiviert gehabt und war effektiv auf dem gleichen Level wie wir.
Und das ist halt das, was dann… Genau.
Also ich glaube, ein wichtiger Punkt ist da auch, um es so zu wiederholen, geht halt eben nicht ernsthaft ein Benutzerkonzept, sodass da so ein bisschen das auch etwas ist, was, glaube ich, diese Lücke halt führt.
Okay.
Also ich signiere halt, das ist ein Schritt, den ich halt unternehmen sollte.
Was sollte ich denn als Nächstes tun?
Naja, wie gesagt, das, was ich auch im Talk gesagt habe, automatisiert alles das, was ihr braucht, um das Zeug schnellstmöglich rauszukriegen.
Also die Release-Automatisierung, die halt häufig übersehen wird, glaube ich.
Dann sind wir schon wieder bei einer Signatur.
Die Artefakte, das heißt eine Bibliothek, ein Binary und Container.
Da auch nochmal kurz erwähnt, Sixdoor-Ökosystem.
Einfach hingehen, angucken, ist super.
Sicherstellen, dass das alles passiert ist.
Weil es ist ja so, in deinem Beispiel ist es so, klar, kleines Team, aber in den meisten Fällen ist es so, ich habe Teambrüche.
Also ich habe irgendwo etwas, wo ich an ein anderes Team weitergebe.
Und wir Entwickler stehen ganz, ganz am Anfang der Kette normalerweise.
Wir bauen die Software.
Und was das halt ist, das ist, umso weiter das für sich von uns wegbewegt, umso weniger Einfluss haben wir auf das.
Wir wissen ja auch gar nicht, wie es betrieben wird.
Das kann sein, dass SAEs noch drei Testsysteme oder sonst irgendetwas haben.
Wir müssen den anderen die Sachen in die Hand geben, dass die die Möglichkeit haben, mit unserer Software umzugehen, nachzuvollziehen, was ist.
Und im Zweifelsfall sogar den Weg zu uns zurückfinden, um uns Informationen zu liefern.
Und von daher ist ja das quasi, sich dieses Signieren zur zweiten Natur zu machen.
Und es ist halt sehr niederschwellig.
Es sind einfachste Tuchs, die wir mittlerweile haben, wo wir das herstellen können.
Das sehe ich halt so als das Minimale.
Und das ist relativ gut zu machen.
Und dann sind wir fertig?
Supply Chain technisch, ja.
Weil die Supply Chain hat die primäre Aufgabe, die Nachvollziehbarkeit zu gewährstellen.
Weil was du wahrscheinlich hast, das ist dann Security Scanning und sowas.
Die setzen aber da auf.
Die Supply Chain ist erstmal nur Transparenz sorgen, dafür sorgen, dass ich dir Vertrauen kann und dass ich alles habe an Informationen, was eine andere Person, ein anderes Tool braucht, um Sicherheitsmängel zu identifizieren.
Und tatsächlich ist das, was du gerade eben kurz gesagt hast, das, was mich so ein bisschen wundert.
Weil ich hatte jetzt erwartet, dass Supply Chain Security insbesondere bedeutet, ich habe einen Mechanismus, der sagt, okay, ich ziehe mir irgendwas rein.
Und nicht also das ja NPM genannt.
Ich glaube, NPM ist insbesondere deswegen ein Beispiel, weil offensichtlich ein triviales JavaScript-Projekt bereits eine Vielzahl an Abhängigkeiten hat.
Und das ist ja, wie bei Java-Projekten mit dem Zeuge Maven Central ist einfach die Anzeige geringer.
Weil das historisch irgendwie so gewachsen ist, so jedenfalls mein Eindruck.
Das heißt, also ich habe jetzt eine Vielzahl von Abhängigkeiten in NPM.
Ich weiß gar nicht, was da drin ist.
Und jetzt ist meine Hauptherausforderung, hätte ich erwartet, dass ich das halt irgendwie manage.
Und das erschlage ich halt durch SBOMs und durch Security Scanning.
Und ich glaube, korrigiere mich, dass das in dem Talk nicht erwähnt.
Oder?
Das hat mich überrascht.
Ich kann dir aber ein Beispiel bringen, wo dich eine funktionierende Supply Chain unterstützt.
Und da ist mein Lieblingsbeispiel die Zusammenarbeit zwischen Harbor und SigStore.
Gehen wir mal so aus, wir erzeugen jetzt ein Docker-Image.
Ich habe das jetzt selber signiert.
Das kommt von der Entwicklung und ich schiebe es in Harbor.
Harbor ist Projektgetrieben.
Das heißt, es kann Images zwischen Projekten hin und her.
Erste Regel ist, Harbor ist aware, dass SigStore Sachen da sind und sagt zum Beispiel, okay, das ist das eingehende Projekt.
Und das da hinten ist das Projekt, aus dem die Kubernetes Cluster später die Sachen ziehen.
Ich ziehe das da rüber und aus diesem Projekt darf nur gezogen, also ich ziehe es rüber und ziehe es nur rüber, wenn die Entwicklersignatur dran ist.
Erster Schritt geschafft.
Jetzt ist es da drin.
Jetzt läuft Trivy durch.
Trivy ist ein Security Scanner, der auf Container runtergeht.
Sagt, das Ding ist sauber.
Harbor hat jetzt zwei Regeln.
Das Ding darf nur raus, wenn keine Non-CVs drin sind und wenn es von den Entwicklern signiert ist.
Die Signaturnummer kennen wir jetzt.
Der Kubernetes Cluster zieht.
Jetzt sind wir fertig.
Nein.
Trivy scannt weiter.
Trivy weiß, der Container wurde gepullt.
Nach einer gewissen Zeit, zwei, drei, vier, fünf, sechs Wochen später, taucht ein CVE in der verwendeten Bibliothek auf.
Wir haben in der Zwischenzeit nichts daran gemacht.
Entwickler haben es verpennt.
Wir haben jetzt eine unsichere Version.
In dem Moment sagt Trivi, in diesem Container ist ein CVE.
Wir können jetzt dann direkt in Kubernetes schauen, leuchtet dieser Container irgendwo.
Das ist das, wo wir sagen, das nutzt jetzt.
Jetzt können wir sagen, wir bekamen die Container-Signatur.
Das ist der Container mit dieser Version.
Der muss sofort erst entweder wieder abgeschaltet oder ich gehe zu den Entwicklern und sage, ich brauche eine neue Version.
Dafür brauche ich doch auch so eine S-Form oder ein ähnliches Ding.
In dem Container ist diese Software mit diesen Libraries.
Das Log4J-Beispiel würde jetzt sagen, in dem Container ist Java und in dem Java ist Log4J.
Das ist genau der Punkt, wo das dann auch noch mit reingreift.
Was bedeutet, ich muss dann so eine S-Form liefern und das wäre ein weiteres Thema, was ich eigentlich machen müsste oder irgendetwas, damit Trivy das halt umkannt?
Nicht zwingend.
Es ist in meiner Pipeline, wenn ich in der Pipeline sowas wie Trivy zum Beispiel, ich habe auch das Beispiel mit SIFT gebracht, das ist eine Alternative.
Also kurz erklären.
S-Forms können auf zwei Wegen erzeugt werden.
Ich kann sie aus dem Bild heraus erzeugen oder von externen über einen Scan erzeugen.
Das ist das, was SIFT macht.
Und wenn so ein Tool wie Trivy reingeht und sowas, das kann natürlich alles halt auch an der Stelle durchanalysieren.
Ich kann auch vorher schon tatsächlich direkt aktiv S-Form hochladen.
Tatsächlich die bessere und saubere Variante ist aber nicht zwingend erforderlich, weil das ist ja ein Security-Scanner.
Und die Security-Scanner können selber reingehen und die Sachen halt identifizieren und sich dann eine Information entlanghalten.
Es ist ein zusätzlicher Mechanismus, den man nutzen kann, den halt auch diese Tools jetzt immer weiter bieten.
Also Sneak zum Beispiel sehe ich jetzt auch gerade, da bin ich gerade mal experimentieren mit.
Aber grundsätzlich ist das halt das, der wichtige Aspekt ist jetzt nicht diese Einzahlung, sondern zu sagen, es ist durchgehend, ich habe all diese Signaturen.
Wenn was passiert, kann ich jetzt SAE sagen, schaltet das Ding ab, es ist zu gefährlich, das zu betreiben.
Oder ich kann zurück zu den Engineers sagen, bewertet bitte den Fehler und liefert eine neue Version.
Und dafür ist dann das Release wieder im Vortrag.
Es darf nicht wahr sein, hat noch eine Frage gestellt.
Und zwar hat er gefragt, wie ist Jochens Meinung zu Formal Methods, also Theory Improver und so weiter?
Formal Methods sind eine Softwareentwicklung drin.
Habe ich noch nie verwendet, muss ich tatsächlich sagen.
Also wenn es jetzt wirklich die Verifikation angeht, es gibt verschiedene Prozesse.
Also wenn es zum Beispiel jetzt auch, es gibt jetzt ein Secure-Prozess von Microsoft, der in der Automobilbranche und auch in der Raumfahrt und sowas hat genutzt wird, wäre wahrscheinlich cool.
Ich hatte noch keine Bewirkungspunkte damit.
Aber was mache ich da?
Was sagt dieser Prozess?
Also ich würde mal eher sagen, da bin ich jetzt auf wahnsinnig dünnen Eis.
Ich habe mich nur sehr peripher mit diesen Sachen beschäftigt.
Ich weiß, dass die sehr, sehr aufwendig sind, weil sie mehrere Überprüfungsschritte mit vor sind für verschiedene Operationen und auch, glaube ich, mehr als zum Beispiel so ein einfacher Pull-Request.
Vielleicht kann uns, wer da gerade im Chat schreibt, auch nochmal schreiben, ein bisschen was daraus.
Ich muss sagen, da bin ich halt tatsächlich.
Wir haben sehr viel halt von den aktiven Codescannern, die es für das Java gibt, direkt mit im Betrieb von Google.
Wie heißt denn?
Also ich muss halt gestehen, ich bin halt über, also ich hatte sowas wie Formal Methods abgespeichert und ich beweise halt, dass zum Beispiel ein Kryptografie-Algorithmus tatsächlich korrekt ist bzw. überprüfe halt, ob meine Implementierung halt in Ordnung ist.
Und das hatte ich für mich halt verbucht unter, damit sichere ich mich ab, wenn ich Fehler in der Implementierung habe von solchen sehr anspruchsvollen Algorithmen, was eben bedeutet, dass in der Breite, also wir reden ja über ganz andere Dinge, nicht?
Wir reden ja darüber, dass halt irgendjemand in irgendeinem C-Code ein Waffenoverflow produziert hat und das sorgt halt für irgendwelche Dinge oder Nächsteilbeitragen und die sind einfach auf einer anderen Ebene.
Aber keine Ahnung, ist halt ein bisschen die Frage, was da genau passiert.
Ich meine mit den Formal Methoden, also das ist zum Beispiel, was ein Beispiel ist, was halt einfach auch eben mathematisch mit abgebildet sind.
Das ist zum Beispiel der Schutz der Anwendung vor Race Conditions, vor Waffenoverflows mithilfe des Typsystems, das was Rust macht, was auch zum Beispiel sowas wie Ponylang, glaube ich, als fast Erste schon mitgemacht hatte.
Das ist das eine und dann die andere Verifikation mit den Algorithmen und sowas.
Da ist auch das Grundproblem.
Ich meine, da ist, glaube ich, so, Elastic sind das so das beste Beispiel, weil die haben ja ihren eigenen Konsensalgorithmus implementiert für die ganze Katastrophe in frühen Elastic-Versionen.
Also da kann ich immer, wer den Namen Kyle Kingsbury mal googelt und sich seine Talks anschaut, das ist, also wie er dieses Ding hat.
Und er hat ja auch seine eigene Dokumentationsseite bei Elastic, wo die schwächen dieses Algorithmus.
Und das ist halt auch das, wir haben heutzutage mit Raft und mit Paxos zwei, die verifiziert sind.
Ich glaube, es gibt noch ein bisschen mehr, aber das ist halt, die sind halt wirklich sau algorithmisch verifiziert.
Genau, das ist so theoretisch und mathematisch.
Also der, das darf doch nicht wahr sein, hat geschrieben, ich weiß auch nicht so viel darüber bin, aber ich bin großer Freund davon, viel über Typen zu beweisen.
Genau.
War neugierig, wie die Meinung aus der anderen Richtung ist.
Jetzt muss ich aber leider ins Meeting.
Genau.
Aber da kann man dazu sagen, dann war man schon richtig.
Es gibt eine formale Verifikation von Algorithmen, dafür gibt es auch einen eigenen Sinn.
Habe ja auch einen Kollegen, der sich sehr intensiv mit solchen Sachen beschäftigt, weil wir ja selber sehr mit Verteilung arbeiten.
Das passiert aber auch auf einer anderen Ebene, weil das ist tatsächlich die Richtigkeit eines Algorithmus zu beweisen.
Wenn es um Entwicklungsmethodik gibt, da gibt es ein Typen-System.
Ich bin ein großer Fan von guten Typen-Systemen.
Ich verlasse mich sehr gern darauf, wenn ich sagen kann, okay, das Typen-System nimmt mir diese Hirnarbeit ab, bestimmte Fehler einfach zu loszuwerden.
Genau, und das ist ja auch genau die Idee von dem Typen-System, dass das jemand eine bestimmte Art von Fehlern halt irgendwie eliminiert.
Und da gibt es ja irgendwie diese Rust-versus-C-Geschichte.
Ich habe heute Morgen halt genau die angefangenen YouTube-Videos zu gucken, wo der Dinosaurier darüber spricht.
Was würdest du den Leuten noch mit auf den Weg geben?
Oder hatten wir das schon?
Nö.
Also, was ich einfach sagen möchte, das ist, was mir sehr, sehr aufgefallen ist, das ist, wir sind mittlerweile echt in einem guten Zustand, was das Tooling angeht, angekommen.
Und es ist nicht schwer, eine gute Basis für eine Supply-Chain aufzubauen.
Die Leute schrecken, wenn ich die Diskussionen des letzten Jahres also sehe, die ich halt nach Talks und so gehabt habe, viele Leute sind erstmal so für die Supply-Chain, dieses Monster-Wort erschlagen.
Und dann zeigt man ihnen so diese einzelnen Komponenten und ich sage, das sind ja nur ein paar Zahlen Code, die ich am Ende des Tages brauche.
Das ist ein bisschen Hirneinschalten, ein paar Zahlen Code mit rein, dann ist das Automatisierung.
Ich habe es immer.
Und das ist so etwas, das mir überrascht.
Es ist nicht so schlimm, wie es sich anhört.
Und das Zweite, was ich gerne mitgeben möchte, das ist, dass eben genau wegen dieser Frage, wegen Junior-Entwicklerinnen, es ist die Aufgabe von Seniors, auf solche Sachen hinzuweisen.
Es ist nicht die Aufgabe der Seniors, der Klugscheißer vom Herrn zu sein.
Unsere Aufgabe ist auch nicht, auch ich als Prinzip, die Aufgabe, alles zu wissen und besser zu sein.
Es ist, ich muss kritisch sein.
Ich muss einfach gucken, denken die Leute an solche nicht-funktionalen Aspekte, die einfach wichtig sind für Softwareentwicklung.
Und das ist meine Aufgabe.
Und von jedem, der Senior-Titel aufwärts hat, erwarte ich, dass ich sage, das ist auch das, was ich auch in Interviews frage.
Also muss ich auch ganz ehrlich sein.
Senior-Position bedeutet, ich erwarte, dass jemand auch ein bisschen was über die Sicherheit und die Mechanismen seines Ökosystems weiß.
Genau.
Vielen Dank.
Und ich verlinke noch dein LinkedIn-Profil und dein Mastodon-Account.
Sehr gut.
Und wenn noch irgendwelche Fragen sind, hat das ja extra darauf hingewiesen.
Also wenn ein Feedback oder so ist, bist du da halt prinzipiell erreichbar und antwortest auch sehr gerne.
Gut, dann würde ich sagen, haben wir es soweit, oder?
Ja, vielen Dank.
Ich danke.
Und wir haben morgen den Talk über Sprache.
Ich muss mal kurz den Titel tatsächlich nachgucken.
Sprache schafft Wirklichkeit mit Friederike Sternberg.
Das ist auf Basis von dem Talk, den sie heute gehalten hat.
Ich war leider in Jochen’s Talk parodiert.
Und ich freue mich darauf, weil wir ja diese Episode hatten, wo wir vom Java-Forum Stuttgart Leute gefragt haben, was ist eigentlich der wichtigste Skill in IT?
Was ist der wichtigste Skill in IT?
Der wichtigste Skill in IT?
Neugier.
Okay, interessant.
Ich glaube, den haben wir nämlich wirklich nicht.
Wir hatten halt, glaube ich, mit rund 80 Prozent so Soft-Skillige Sachen.
Und ganz viel haben wir mit Kommunikation gesagt.
Aber also deswegen gute Ergänzung.
Und das ist so ein bisschen etwas, wo wir uns tatsächlich mal mit Kommunikation beschäftigen können und halt schauen können, wie eben Begriffe dann eine bestimmte Realität bilden.
Morgen um 10 Uhr auch etwas außerhalb der sonst üblichen Einfahrt.
Vielen Dank.
Schöne Konferenz noch und bis dahin, würde ich sagen.
Vielen Dank.
Ciao.