 Also, wenn ich zwischendurch weglaufe und bei Bühne hin und her renne, ist genau mein Ding und ihr mich nicht mehr hört, müsst ihr winken oder schreien oder sowas, weil das Mikro nur hier steht. Genau, ansonsten, ich heiß Christian, ich wollte ein bisschen was erzählen, wie man sich so seinen Alltag als Effizienter-Entwickler ein bisschen einfacher gestalten kann. Aber der Software-Entwickler kommt eigentlich nicht aus der Ops-Ecke, das heißt, ich habe meistens mehr so einen Drang dazu, auch Sachen zu automatisieren, ein bisschen auf Sicherheit zu achten und diese ganze DevOps-Bewegungen, die liefen mir ganz gut rein. Es gibt Leute, die zum Teil auch hier im Raum sitzen, die auch schon sich darüber beschwert haben, dass ich meistens eine sehr gute Laune habe und sie darin störe, eine schlechte Laune zu haben. Und ganz wichtig, wenn ihr Fragen habt, ruft gerne rein, wenn ich euch nicht sehe, das blende ziemlich hier, ansonsten hebt die Hand, der, ich glaube er heißt auch Christian, rennt dann irgendwie rum mit Mikrofonen, ansonsten könnt ihr auch die Frage schreien und ich wiederhole sie nochmal schnell für alle. Genau und vielleicht darf ich mal kurz eine Frage stellen, ich finde es ganz super, dass wir wieder hier alle zusammensitzen und man hat nur in seinen Monitor eine Frage gestellt oder in seine Kamera, wer von euch entwickelt, denn es ist Software. Okay, und wer von euch verwaltet die Versionen von irgendwelchen Dependencies? Okay cool, es überschneidet sich glaube ich ziemlich, was ganz gut ist. Genau, moderne Software-Entwicklung, wie es dir alle läuft so, dass man eigentlich nichts mehr von Null ausbaut, sondern es ist eigentlich total hip Sachen wieder zu verwenden. Das heißt, entweder haben andere Leute schon Dinge gebaut, ich nehme mal ganz gerne als Beispiel so ein HTTP-Cline zum Beispiel, die das vielleicht schon besser können. Zumindest als ich, vielleicht könnt ihr das alle gut, vielleicht benutze ich einen HTTP-Cline, den jemand von euch maintained oder so könnte sein. Man kann aber auch Teile und Funktionen von eigener Software wieder verwenden in einem anderen Projekt zum Beispiel. Ich werde paar mal von Projekten sprechen, ob das dann ein Tool oder ein Projekt oder sonst wie es, ich glaube es kommt meistens raus. Genau, aber ich glaube mittlerweile eben läuft sehr viel drauf raus, dass man sehr viele Sachen versucht wieder zu verwenden, aus meistens Zeitgründen. Ihr kennt das alle, es gibt Feature-Druck oder so was, oder Backdruck und nicht ein, mach mal schön, okay, oder mach mal alles selber, muss man eigentlich dann machen. So, in moderner Softwareentwicklung oder modernen Programmiersprachen gibt es dafür meistens Paketmanager, der ihm erlauben irgendwelche Bibliotheken einfacher zu verwalten und so diesen ganzen Product-Lifecycle, wie das so neu Deutsch heißt, irgendwie ein bisschen das seinen Griff zu kriegen. Sind viele Java-Entwickler hier? Die Beispiele sind möglicherweise mit Java, aber ich glaube, man kann das transportieren, wenn man schon ein bisschen Software entwickelt hat auf die anderen Paketmanager oder so was, oder Software-Lifecycle und so weiter, Manager. Ich habe mir erlaubt, Docker mit aufzuführen, es ist jetzt kein so klassisches Dependency-Management-Tool. Es gibt aber eben, ihr kennt das alle selber, ihr macht so ein Docker-Bild oder Docker-Run und habt irgendeine Docker-File, dann gibt es ein Basis-Image und ihr ladet das halbe Internet runter und vertraut einfach drauf, dass das irgendwie magischerweise funktioniert und euer Projekt nicht komplett in die Tonne wirft. Und im Beispiel nachher wird man auch ein Beispiel aus Docker sehen und deswegen ist das irgendwie ganz praktisch. Wer von euch macht Docker-Images, Container, Kubernetes, sowas in die Richtung? Vielleicht doch viel der Infrastructure as Code, Terraform, Ansible. Ich habe mal ein Beispielhaft eines halbwegs übersichtlichen Liste rausgekramt, die halt so ein modernes JavaScript-Tool oder Front-End ist, hat jetzt keinen Anspruch auf irgendeine Vollständigkeit oder sowas, das ist aus einem echten Projekt übernommen. Und ich habe mal einen solchen Teil davon rausgegriffen, eine Dependency, die man sich damit in sein Projekt installieren kann, das heißt, ihr checkt das Git-Report aus davon und macht sowas wie NPM install und bekommt sowas wie File-Loader, was auch immer das tut. Und ihr schreibt das aber in eurem Projekt fest, ich möchte File-Loader benutzen, weil dann kann ich Funktionen aus dieser Bibliothek verwenden. Und was, glaube ich, auch so ein Best Practice ist, ist natürlich auch die Software davon festzuschreiben. Das heißt, ich weiß, ich will File-Loader in der Version 6.2.0 zum Beispiel in diesem Projekt raus verwenden. Natürlich mit der Intention zu sagen, ich weiß genau, welche Funktionen und Methoden und so weiter da drin sind, die ich verwenden kann, dass auch keine gestrichen wurden in der Zwischenzeit, bitte. Ich wiederhole mal, die Frage ist, sollte man eine 6 oder eine 6.2.6.2.0, wie strikt sollte man das Ganze angeben? Ja, das ist jetzt die Frage. Ich glaube, du kriegst keine so richtige Antwort. Wenn man das sehr granular macht, also sagt, ich möchte 6.2.0 verwenden und keinen Patch, dann kriegst du nach einem Tool, mit dem du das zumindest handeln kannst, halbwegs. Ich persönlich würde es immer möglichst strikt halten, weil dann hast du halt zu jedem Zeitpunkt, kannst du an deiner Versionierung halt nachvollziehen, in dem Fall an seiner Git-Historie oder sowas. Wann wurde welche Version benutzt und muss net in irgendeinem alten Buildlock oder das Artifakt auspacken und gucken. Was habe ich denn am 23.05. letztes Jahr für ein Artifakt deployet? Habe ich das überhaupt noch das Paket? Und was war da denn für eine File-Loader-Version drin? Und dazu kommt noch, das Git ist ja irgendwo auch so eine Art, ein Entwickler unterschreibt quasi mit seiner Commit-Message und mit seinem Sign-in dafür, dass er dafür Code geändert hat. Das heißt, wenn er eine Bibliothek geändert hat, steht irgendwo hoffentlich im Kommentar auch, warum das passiert ist. Deswegen meine Hoffnung wäre, dass möglichst viele Leute das sehr, sehr granular machen und einfach hart auf eine Version festschreiben. Ich habe aber auch schon Projekte gesehen, wo man eben sagt, ich möchte eine 6er-Version von File-Loader oder eine 620. Ich erzähle nachher was für ein Beispiel, wo sowas in die Hose gehen kann oder aus einem Beispiel. Genau, jetzt ist es eine Liste, da steht einfach eine Liste von Dependencies drin, die man aktiv für sein Projekt benutzen möchte. Jetzt kommen in diesen Dingern verpackt oder noch transitiv herangezogen, noch viele, viele andere Dependencies mit. Das heißt, ihr ladet nicht möglicherweise nicht nur diese Dependencies, sondern auch noch so einen ganzen Zoo aus anderen Dependencies, von denen ihr gar nicht wisst, dass sie existieren. Bei Java sieht es ganz ein bisschen oder bei Melven in dem Fall ist das Ganze noch ein bisschen aufwendiger. Und zwar gibt es dafür immer so ein Namespace. Bei NPM ist es so, dass es quasi eine globale Registry gibt. Ist der Name schon vergeben, könnt ihr da keinen Artifakt mit dem gleichen Namen hin pushen. Bei Java ist es ein bisschen anders. Ihr habt Namespace oder eine Gruppe, wenn man so will. Dann habt ihr den Namen. Das heißt, in dem Fall wäre das ein Jackson-Data bind. Was das macht, ist total irrelevant. Das macht so ein XML und JSON-Parsing, typischerweise so Webclients, aber das ist jetzt für den Inhalt hier nicht wichtig. Dann habt ihr eine Version. Und dazu habt ihr auch noch so einen Scope. Das heißt, in dem Fall ist es compile. Ich brauche das zur compile-Zeit, muss dieses Artifakt vorliegen. Es gibt Bibliotheken, die müssen z.B. nur zur Laufzeit vorliegen. Es gibt Bibliotheken, das sieht man ganz unten rechts, die braucht man nur für Tests. Und typischerweise geht man dann in so modernen dependency-Manager hin und sagt, ich möchte z.B. nachher in mein Produktivpaket auch diese Testdependencies gar nicht mehr drin haben. Und vielleicht kann man da auch so ein bisschen, ich sage mal, ein bisschen weniger konservativ an die Versionierung rangehen, dass man sagt, ja, für Testswecke und für lokales Entwicklungs-Sanario ist mir nicht so wichtig, ob das jetzt eine 6.2, 6.3, 6.5 ist. Könnte in die Hose gehen natürlich wiederum, wenn man dann später in Produktionen eine Version hat, mit der man nicht getestet hat oder so. Genau. Und was man hier sieht, bei Java oder in dem Fall bei Maven, gibt es bei Gradle aber auch, ist es eben so vererbungsgetrieben. Das heißt, wenn ihr hier seht, ganz oben seht ihr sowas wie, da ist so ein Plus, hofft man, man erkennt das wahrscheinlich von hinten. Das sind quasi die auf der ersten Ebene, wo nur ein Plus davor steht, eine Einrückung, das sind die Fakte, die ich mir aktiv in meine Konfigurationsdatei reingeschrieben habe. Das heißt, wo ich gesagt habe, ich möchte z.B. zweite Zeile gerne Spring Boot Starter Security. Das ist im Java-Umfeld was, mit dem man so Lock-in-Masten und so was machen kann und so ACLs, AirBug und so was. Und ich möchte auch die Testbibliothek dazu und ich möchte die Webbibliothek und so weiter. Genau. Wenn man das ändern muss, sieht es manchmal auch so aus, sondern man kommt sich so vor, weil es kann durchaus passieren, dass man eine Schwachstelle z.B. hat in irgendein so nativ verschachtelten Abhängigkeit, die man selber nie irgendwie konfiguriert hat, von der man vielleicht gar nicht weiß, was sie da ist. Da kommt man relativ schnell im Bedrängnis, wenn man das nicht schon allein das Anzeigen und Erkennen von Schwachstellen, die man sich schon über so einen Dependency-Manager reingezogen hat oder über Bibliotheken, die irgendjemand im Internet veröffentlicht hat, alleine das zu erkennen, kann man eigentlich händisch gar nicht mehr machen. Also in dem konkreten Fall zeigt gleich eine Demo-App, da habe ich glaube ich fünf oder sechs Dependencies aktiv eingetragen und wenn ihr die baut, ladet ihr aus dem Internet fast 100 Dependencies runter, die eben irgendwie transitiv, also nachgelagert von diesen verschiedenen Dependencies gefordert sind. Genau, so was ist denn jetzt grundlegend das Problem bei diesem ganzen Dependency-Management für Elefants? Einmal eben die Menge, bestell fünf, krieg hundert, dann gibt es Abhängigkeiten, die das ganze Dependency-Management in sich nochmal ein bisschen schwerer machen, das ist vielleicht bei Java noch ein Tick wichtiger, das zu beachten als woanders. Also wenn man sich vorstellt zum Beispiel, ich habe eine Bibliothek A, die bringt selbst noch eine Abhängigkeit auf eine Bibliothek B mit, B einer auf C und C hat vielleicht eine Abhängigkeit zu A, das heißt ihr bildet da so ein Kreis und dann habt ihr möglicherweise so ganz ekelhafte Abhängigkeiten, die sich dann dummerweise meistens zur Laufzeit zeigen. Wenn es im Test sich zeigt, dann merkt ihr das ja einfach so, da braucht ihr keinen Tool für, dann geht euer Test einfach in die Hose. Wenn es in Prott funktioniert oder passiert, idealerweise dann Sonntag-Nachmittags, wenn kein Mensch arbeitet bei euch, das ist natürlich irgendwie arg ungeschickt. Konfigurationen an sich ist immer so eine Sache, dass man da möglichst auch eine einheitliche Linie findet. Wenn ihr mit mehreren Leuten an einem Stück Software arbeitet, müsst ihr das halt irgendwo so konfigurieren, dass auch jeder andere damit in dem Team was anfangen kann. Bei Open Source Software ist es genau, und es ist wahrscheinlich noch ein größeres Problem, weil ihr in einem viel größeren Teilnehmerkreis vielleicht habt, die in euer Projekt kontributen wollen. Und wenn ihr das sauber strukturiert, die ganze Konfiguration von irgendwelchen Abhängigkeiten, es ist natürlich leichter auch für andere Leute zu verstehen, was habt ihr da getan und wie kann ich mich da beteiligen. Classpath Management, auch eine ganz große Nummer, vor allem bei Java, wenn ihr mehrere Bibliotheken habt, die auf die gleiche Bibliothek referenzieren, aber vielleicht auf verschiedene Versionen. Je nachdem was ihr für ein Tool benutzt, kann das aufgelöst werden oder eben nicht. Und das Problem ist, wenn ihr dann mehrere Versionen einer Library in eurem Classpath habt, der zur Laufzeit geladen wird, kann es passieren, dass zum Beispiel eine Version A eine Methode schon gar nicht mehr hat, die ihr aber an der Stelle, wo Version B benutzt werden soll, also wenn man in Version 2 hat irgendeine Methode abgeschafft, die Version 1 benutzt oder mitgebracht hat und euer Tool oder eine Abhängigkeit benutzt die Methode aus Version 1 und das andere Tool aus 2. Und dann kann es passieren, dass diese Methode nachher in eurem Produktionssystem gar nicht vorhanden ist, auf magische Weise. Vertrauen ist ein Riesenproblem, weil ihr ladet letztendlich Sachen aus dem Internet runter. Wenn man so große Dinger benutzt, wie Spring, wo man halt irgendwie 50 Bibliotheken aus einer einzigen, die man selber eigentlich wollte, bekommt, haben die Leute bei VMW in dem Fall das hoffentlich richtig kuratiert und nicht irgendwas genommen. Aber es gibt einfach da auch Pakete, da merkt ihr irgendwann, wenn es tatsächlich einen Back gibt, liest man so aus den Issus raus, die Leute haben eine Person, die dieses Ding betreibt und das halbe Internet benutzt dieses Tool. Das ist natürlich ein Riesenvertrauensproblem. Und Abhängigkeiten und so weiter und worum wir uns heute kümmern wollen, ist Versionierung und Updates. Und es geht schon nur alleine, diese kleine Facette-Versionierung ist schon ein Riesenthema in größeren Projekten. Wenn ihr mal 100 Dependencies habt, die ihr aktiv in euer Projekt geschrieben habt, wo ihr selbst feststellen müsst, welche Version wird denn gerade verwendet in welchem Zustand oder in welchem Scope? Und wo bin ich gerade? Bin ich im Test? Bin ich im Pot? Wie stelle ich fest, dass meine Produktionssoftware, die ich nachher irgendwie gebaut habe, immer noch die gleichen Dependencies verwendet, wie meine Tests. Und man kann das relativ leicht auch gut kaputt machen. Dann ist eben die Frage, wie werden Versionen konfiguriert? Es gibt meistens mehrere Varianten, dass man irgendwo eine Liste führt und nimmt Variablen und so weiter. Und das müsste man am besten an einer Stelle auch gerade ziehen oder auf eine Art konfigurieren, weil sonst bist du eben bei mehreren Maintenern ruckzuck an dem Problem, dass das einfach nicht mehr wartbar ist. Und dann ist immer eine ganz große Frage und uns vorhin Richtung Commit Message schon gehört, wer ist denn dafür verantwortlich? Ihr habt vorhin alle die Hand gehoben, finde ich super. Es gibt Firmen, da ist es nicht so. Da gibt es wenige Personen, die dafür verantwortlich sind, zum Beispiel sich um die Versionierung zu kümmern. Aus dem einfachen Grund, dass es sehr komplex ist, wenn verschiedene Entwickler alle auf verschiedenen Versionen entwickeln und das nachher alles in so ein Mainline-Branch werfen. Und da geht halt ruckzuck auch mal eine Version kaputt. Deswegen macht es Sinn, sowas auch automatisiert irgendwie abzufrüchtigen. Und dann gibt es so die grundlegende Frage, warum will man denn überhaupt Updates machen, die man sich immer so ein bisschen im Hinterkopf behalten muss? Security ist wahrscheinlich ein riesen Treiber. Ihr habt vielleicht vor Weihnachten, hat vielleicht das CEO bei euch angerufen und gesagt, hey, haben wir da Lock4J? Und dann habt ihr wahrscheinlich gesagt, oh ja, aber wir haben so eine alte Version, die hat die Schwachstelle noch gar nicht. Kann man Glück haben, wenn man keine Updates macht, ideal ist das natürlich nicht. Genau, aus Sicherheitsgründen werden ganz, ganz schnell ganz viele Updates gemacht. Es gibt aber noch andere Gründe, weswegen man natürlich seine Software updating will und einen relativ modernen Stack haben will. Das heißt, alle dependencies auf einem einigermaßen neuen Stand und der eine ist Performance, weil natürlich Leute auch ja an diesen Libraries arbeiten. Und die machen das ja auch nicht, weil sie Spaß macht, sondern weil sie damit was bezwecken wollen. Das heißt, entweder bringen sie euch neue Features, neue Funktionen, neue Methoden oder sie machen vielleicht die Performance besser. Und wenn ihr zum Beispiel so ein HDDP Client habt, der client-seitig 50% Ressourcen einsparen kann, dann kann das bei einer großen App einen riesen Haufen Ressourcen ausmachen. Und vielleicht will man deswegen relativ modern bleiben und meistens wird die Performance besser, weil die Leute ja auch immer mehr testen. Und dann gibt es eben diesen Killer, warum man manchmal keine Updates machen will. Das ist eben, wenn Methoden oder Funktionen gestrichen werden. In Java heißt es deprecated, weiß man wie das Warners heißt, man kann sich sehr herleiten. Letztendlich ist es so, wenn eine Version 1 eine bestimmte Methode hat und man möchte die perspektivisch entfernen als Maintainer, weil man zum Beispiel sagt, ich brauche die Methode nicht mehr, ich habe zwei andere Methoden, die zusammen das Gleiche machen und die finde ich technisch irgendwie besser ausgründen. Dann schreibt man in eine Version 2 typischerweise so was dran, wie hier deprecated, dann kriegen die Entwickler eine Warnung beim Bauen und die sagt zum Beispiel, Achtung, nächste Version fällt das Ding raus. Habt ihr bestimmt alle schon gesehen. Und dann hat man die Möglichkeit das auszubauen. Und jetzt kommt das Problem, wenn man das dann verschiebt, weil man sagt, ah ne, da kommt die Methode raus, das lassen wir lieber, wenn dann eine der anderen Punkte kommt. Und zum Beispiel, jemand sagt ja, Moment mal hier, Version 4 Security und so, mach mal Update, dann steht ihr da und merkt, ah, in Version 3 ist was rausgefallen, jetzt muss ich erstmal den Aufwand da reinstecken, das so zu implementieren, dass ich diese Methode auch ersetzen kann. Ja, weil sonst steht ihr da und ein Teil von eurem Code funktioniert einfach nicht mehr, weil ja eure Funktion fehlt. Dann seid ihr vielleicht sicher, deploy dürft es trotzdem nicht wahrscheinlich. Und was ich empfehlen würde, im ersten Schritt wäre eine Form von Tooling, die euch darauf aufmerksam macht, dass ihr ein Sicherheitsproblem in einer Bibliothek habt. Mit dem einfachen Grund, bevor ihr überhaupt anfangen solltet, Updates zu machen, solltet ihr dringend wissen, was davon ist unsicher. Aber es gibt richtig gehende Kampagnen, die sich an öffentliche Apps oder sowas richten, die halt einfach, ihr kennt es vielleicht schon seit Jahren, ihr macht emittet einen neuen Server bei Hetzner oder sonst wo, startet den, guckt ins Log, was so im Audit steht oder so und innerhalb von 2 Minuten hast du 500 Logins oder Loginversuche, wo Leute versuchen mit Route und ohne Passwort in deinen SSR-Dimen reinzukommen. Und sowas gibt es aber auch auf einer höheren Ebene, dass Leute tatsächlich hingehen mit irgendwelchen Scanners wie Burp oder Zap oder sowas, einfach jeden Endpunkt, der neu im Internet auftaucht, direkt scannen und gucken, gibt es da Standardschwachstellen. Und sobald ihr eben so eine bekannte Schwachstelle habt, beispielsweise so etwas wie Log4j, wird knallhart versucht, nach wenigen Sekunden, quasi wenn das bekannt wird, das auszunutzen. Und ihr müsst da am Ball bleiben, dass ihr merkt, A, Achtung, Schwachstelle, die Schwachstelle ist bekannt geworden. Und ihr müsst sie schneller patchen als irgendein Angreifer mir, die irgendwie ausnutzt. Und ich habe mal so ein paar Tools, die so Sicherheitsgans machen, aufgeschrieben. Dependency Check mag ich persönlich sehr gerne. In der Overspondation ist Open Source, der Maintainer oder die Maintainer reagieren extrem schnell, die sind meistens innerhalb von einem halben Tag, wenn ihr dann Issue stellt, auch dabei das zu fixen oder euch was zu erklären. Es gibt aber auch konventionelle Tools, GitLab und Snook und X-Ray und Dependerboard von GitHub. Die meisten davon sind für Open Source Produkte gratis und machen eben eine Prüfung auf bekannte Sicherheitslücken, wie schon gesagt. Und ich persönlich würde empfehlen, das ganze regelmäßig zu machen. Wir machen das typischerweise nachts in unserem Nightly-Bild, vielleicht aber auch und auf jeden Fall irgendwie automatisiert. Weil kein Mensch kann das händeln, wenn es einen Entwickler morgens macht, kostet unnötig Zeit. Es ist wahrscheinlich schneller automatisiert, als dass man das zweimal von Hand ausgeführt und geprüft hat. Man kann es aber auch nicht vergessen, wenn dieser eine Entwickler, erkennt es vielleicht, es gibt den einen Entwickler, der solche Sachen macht, der ist dann mal krank und hat Urlaub und keiner weiß, dass das Ding irgendwie kaputt ist. Und zack, hast du sechs Wochen alte Sicherheitslücken, weil keiner da war, der es gemacht hat. Genau. Und die schwierigste Sache an dieser ganzen Nummer ist nicht, Schwachstellen zu finden, sondern sie zu fixen. Und zwar nett, dass sich jemand hinstellt und sagt, ja, Lock4J214 hat eine Schwachstelle. Ich benutze zwei, was 17, was am Schluss der entgültige fix war. Sondern die Frage an deine Org, an deine Firma, an dein Team, wer macht das und wann. Und da kann ich euch leider nicht mithelfen. Das müsst ihr halt für euer Team selber rausfinden oder für eure Org. Vielleicht habt ihr da irgendwie Sicherheitsstrukturen, je nachdem wie groß der Laden ist, bei Open Source Tools genauso. Und jetzt würde ich gerne auch so einen Punkt kommen, nämlich, dass man das Ganze nicht manuell machen muss, sondern automatisieren kann. Damit es ein Tooling gibt, was euch quasi zumindest mal den Aufwand abnimmt, zu sagen, hey Chef, guck mal, da gibt es ein Update. Patch Lock4J217 mit ChangeLock, direkt als PoolRequest, weil letztendlich macht ihr als Entwickler ja nix anderes. Ihr macht eure Maven-Pom auf, also eure Konfigurations-Satei oder Package Jason oder sowas, oder weiß nicht, wie es bei PIP heißt oder Partner heißt und schreibt da einfach eine neuere Version rein. Mit einer CommitMessage, die besagt, warum habe ich ein Upgrade gemacht? Und das kann ja heißen, ich möchte mal wieder die nächste Version benutzen, damit wir am Ball bleiben oder eben, hey, hier CVE Link, es gibt eine gravierende Sicherheitslücke, wir brauchen dieses Update. Genau, und wenn ihr das automatisiert habt und dann vielleicht, kommen wir vielleicht auch noch dazu, das Ganze auch noch automatisch merken könnt, dann braucht ihr euch eigentlich auf diese Basissachen, wie habe ich überhaupt die neueste Version, gar keine Gedanken mehr zu machen, und seid einfach fertig und könnt tatsächlich die coolen Sachen machen, wie Features entwickeln oder was auch immer ihr cool findet bei der Software-Entwicklung. Genau, so, wie updaten wir denn? Ja, das ist nochmal so der Painful-Manuelle-Prozess. Es gibt so ein Beispiel in Java, so ein Versions-Plugin, und das könnt ihr eingeben, und sagen, hey, zeig mal für was gibt es alles Updates, und jetzt kommt dieser Spaß in Maven oder Java. Ihr habt ihr halt irgendwie, ich weiß nicht, das sind 20 Bibliotheken, die ein Update haben, die habt ihr alle nie in eurer Config-Datei gehabt, weil die wolltet ihr gar nicht haben, die kamen halt irgendwo gratis mit. So, könnt ihr vergessen, das irgendwie zu updaten, von Hand. Es gibt Frameworks, die bieten sowas an, dass sie so eine Outdated-Liste machen, und es gibt welche, die bieten an, alle Updates zu machen, die es gibt. Es gibt sogar welche, die können das nach Security-Relevanz. So, jetzt müsst ihr trotzdem noch so ein bisschen Shell-Magie und CI-Magie aus dem Rum machen, dass das auch noch automatisch passiert, und dann habt ihr alles in einem Update, und wenn dieser Pull-Request-Merch-Request kaputt geht, müsst ihr doch von Hand alles machen, auch ein bisschen doof. Und ist es weiterhin die Frage, wer macht denn das? Wenn ich es nicht automatisiert habe, bin ich wieder bei diesem von Hand-Ding. Und einfacher ist es eben, das automatisiert und regelmäßig zu tun, und ich zeige euch mal kurz, wie man das mit GitHub machen kann. Ah, und jemand hat vorhin GitHub nicht aufgemacht. So, jetzt, genau, das ist eine App, die habe ich mal für einen Security Workshop gebaut, ist auch gar nicht wichtig, was da alles drin ist. Die ist auf jeden Fall sehr, sehr gut, und auch schon gut abgehangen, und die ist richtig kaputt, die ist mit Absicht auch richtig kaputt. Und da drin, ich zeige es einmal kurz, sind ein paar Dependencies, das ist so dieses Beispiel, das ich vorhin auch gezeigt habe. Es sind so 4, 5 Spring Boot, also Java, aber wenn ihr sowas wie Package also benutzt, ist wahrscheinlich der Transfer relativ einfach. Bibliotheken, die einfach modern sind, da gibt es irgendwo anders eine Version von, und dann gibt es eine Struts-Bibliothek, das ist einfach, das ist so ein Web-MVC-Ding, mit dem man Frontends bauen kann, wenn ihr mal was von, jetzt fällt mir der Name nicht ein, von diesem amerikanischen Schufa-Protor gehört habt, was vor paar Jahren mal Equifax, vor paar Jahren mal gehackt wurde, mit 10 Milliarden Kundendaten, Kundendaten, die nicht wussten, dass sie Kunden sind, das kam mit dieser Struts-Version rein. Es ist auf jeden Fall, was da will man automatisiert, ein ganz großes, rotes Ausrufezeichen mit, hey, benutzt diese Version bitte nicht, und eigentlich danach auch ein Benutz-Lieber-Diese, weil die fix das Problem. Und vielleicht sogar ein Auto-Merch, das heißt ihr merkt morgens, oh, heute Nacht wurde meine Software neu deployed, so Continuous Delivery vom Pull-Request bis zum Protz-System am liebsten, und ich muss mich gar nicht mehr um die Schwachstelle kümmern, weil sobald der Patch rauskommt, läuft er quasi nach 10 Minuten in Protz. Oder ja, ich weiß, es ist utropisch, bei gewachsenen Projekten 10 Minuten Pipeline zu haben, was haben wir halt mal 2 Stunden oder so was. Genau, und jetzt habt ihr vielleicht eben schon gesehen, man bekommt von GitHub eine Anzeige mit, Achtung, guck mal, ich hoffe, man kann das von hinten sehen, wir haben in deinem Produkt oder in deinen Dependencies Schwachstellen gefunden. Und technisch gesehen hat nicht GitHub die gefunden, sondern GitHub hat eine öffentlich verfügbare Liste genommen und geguckt, bei der beim NIST gibt es diese Schwachstellenliste und hat geguckt, guck mal, der Mensch hat folgende Struts-Version zum Beispiel verwendet, welche CVS oder Schwachstellen die bekannt sind, gibt es denn dafür? Und jetzt könnte man sagen, diesen Hinweis, den sieht nur der Ohner von diesem Projekt. Das heißt, Angreifer können den erzählen, das ist eigentlich ganz safe, oder? Das lachen schon die Ersten. Wenn ihr einen Fork macht von meinem Repo, dann seid ihr der Ohner von dem Fork, spätestens dann seht ihr es auch, es ist jetzt aber nicht weiter schlimm, weil die Schwachstelle, die ist so alt und so dämlich zu haben, weil sie schon lange gefixt haben. Und wenn ihr GitHub benutzt und macht jetzt ein neues Projekt, das ist das Ding seit zwei Jahren oder sowas gehört, die Pendebot zu GitHub selbst und ist hier voll integriert, dann ist standardmäßig auch diese Benachrichtigung an. Das heißt, ihr kriegt hier Alerts, ihr kriegt die auch per E-Mail, wenn ihr der Ohner seid an eure GitHub-E-Mail, wenn ihr in ein Open-Source oder auch ein privates Projekt macht, bekommt ihr diese Alerts. Und die Pendebot kann euch auch automatisch Pull Requests dafür stellen. Und beispielhaft wäre hier so einer. Das heißt, er möchte zum Beispiel sagen, nimm diese kaputte Struts-Version und benutze bitte lieber die 2530. Und jetzt gibt es einen kleinen Nachteil noch. Die Pendebot ist eine Third-Party-App in GitHub. Das heißt wieder so, ihr müsst ihr vertrauen. Man könnte sagen, die Pendebot gehört zu GitHub, wenn ihr die Pendebot mehr vertraut, könnt ihr euren Code nicht bei GitHub hinlegen oder sowas, oder eure Keys vor allem. Der Code in der Open-Source ist egal, wo er liegt, aber natürlich eure Deploy-Keys, wenn ihr das irgendwo nachher in irgendein System reinschmeißen wollt, vielleicht auf AWS zugreifen oder sowas, oder irgendwo her Daten runterladen oder sowas, Monitoring ansprechen. Ein Nachteil davon an dieser Third-Party-App-Lösung, die Pendebot ist, ihr könnt dieser App keine Credentials übergeben. Außer, sie sind irgendwie im Code verstrickt. Und das heißt, dass ihr damit eben keine integrativen Tests oder Regressions-Tests machen könnt, falls ihr dafür Credentials oder Secrets braucht. Das heißt, ich bin großer Fan davon. Ich push Code, egal wie klein. Es gibt irgendwie automatische Tests gegen die Datenbank oder gegen Drittsysteme. Und das Ding wird irgendwo hochgefahren tatsächlich, echt. Und irgendwo integriert, damit ich da schon sehe, gibt es da Probleme. Und sowas geht mit die Pendebot halt leider nicht. Genau, set. Okay. Aber es ist, wenn ihr irgendwas vor eurer Software machen wollt, die bei GitHub läuft, das hier ist die einfachste Variante. Einfach anschalten, wo das ist schon an. Pull Request angucken, gibt es automatisch und gratis. Man kann das konfigurieren, um ein bisschen mehr Einstellungen zu haben in so einer Pendebot-Jammel. Die könnt ihr mit in euer Projekt reinlegen, wo ihr zum Beispiel sagt, welche Bibliotheken ihr gerne auf welche Version maximal das Update bekommen wollt. Ich zeige das nachher bei Renovate. Da kann man ein bisschen mehr managen, aber es geht in die Pendebot immer mehr. Das eine gehört zu GitHub, das andere gehört zu White Source oder sowas. Jemand macht ein Tool und alle anderen, die so ein ähnliches Tool haben, die kopieren die coolen Sachen. Von daher ist das ganz cool. Es gibt das Ganze auch als Code. Das heißt, man kann sich es runterladen und in einem eigenen Repo mit einem GitHub-Actions oder so etwas, oder GitLab-Runner, oder CircleCI, was auch immer ihr wollt, selber hosten. Einfach eben aus dieser Vertrauensfrage, weil dann habt ihr nicht mehr dieses Vertrauensproblem gegen die Pendebot als Third-Party-Service. Aber dann kann man auch Renovate benutzen, weil der ist einfach besser. Genau, Renovate ist so ähnlich gestartet, wie die Pendebot. Irgendwelche Leute haben sich den ausgedacht und fanden das ziemlich cool. Und White Source als ein Hersteller von Sicherheitssoftware hat das Ding einfach aufgekauft und vertreibt es zum Teil auch in seiner Enterprise-Version oder in seiner ganzen Bundles, wo ihr Security checks und Pull Request und alle möglichen Scans und so bekommen könnt. Der kann eben auch dependencies erkennen, neue Versionen finden. Er muss ja irgendwo her, wenn er sich letztendlich und als dummer Abarbeiter von Code erkennen können, woher weiß ich denn jetzt, ob es für diese dependency, die ihr in eurem Projekt habt, ein Update gibt. Also Beispiel gibt es Spring 2615, wenn da steht 2614. Oder gibt es, was ist denn die neueste Spring-Version, wenn da steht 1.5. Irgendwas. Macht euch einen Merk-Request, verwaltet den auch. Das heißt, jedes Mal, wenn die Pendebot zum Beispiel über ein Scheduler läuft, die ihr gestellt habt, zum Beispiel, wenn sich bei euch am Projekt was geändert hat, möchtet ihr ja auf dem neuesten Stand diese Änderung testen. Weil nur dann könnt ihr sicher sein oder relativ sicher sein, dass das ganze nachher auch in einem Produktionssystem funktioniert oder in einem nachgelagerten System. Und meiner Meinung nach ist es sehr einfach automatisierbar. Das sind nämlich zwei Files, die man da konfigurieren muss. Und dann ist das Ding schon fertig. Und dann ist der Deprocated Code oder da kann man auch das Update rein und dann läuft das Deprocated Code. Renovate, also die Frage war, erkennt man da Deprocated Code in Bibliotheken, nehme ich an? Nein, Renovate kann auch kein Security-Scan machen. Der kann tatsächlich nur gucken, was ist die neueste Version. Oder eine neuere, dann kannst du das ein bisschen einstellen, komme ich nachher noch zu, welche Abstufung es da gibt. Das ist das Deprocated Code Internals. Da ist quasi die Hoffnung, einfach zu sagen, ich bleibe an der neuesten Stelle und hoffe, dass alles funktioniert. Und danach musst du halt selber darauf vertrauen, dass deine Tests idealerweise all deine Pfade durch die verschiedenen Software abdeckt, um zu sehen, funktioniert das Ganze noch. Das Ganze unterstützt Docker, Golang, Java, Node, Python, PHP, Ruby und noch mehr. Unterstützt auch Terraform. Also wenn ihr so etwas macht, wie Infrastructure as Code, wo ihr z.B. wisst, ich möchte auf meinem Test-System Version sowieso von diesem Docker-Container haben und auf meinem Prozsystem diese Version, vielleicht auch die gleiche, und ihr habt dafür ein Terraform-File oder ein Ansible-File, dann macht das Ding euch auch ein Pull-Request, also Renovate stellt euch auch ein Pull-Request, wenn ihr feststellt, es gibt bei Docker Hub eine neue Version davon. Also wenn ihr Beispiel sagt, es gibt ein Pull-15 und es gibt eine Elf-016, dann stellt euch Renovate auch ein Pull-Request, der eben diese Version ändert. Das ist ganz cool. Das kann die Panda-Bot auch. Renovate unterstützt ein paar mehr Frameworks, also ich muss ein paar aufgezählt, Helmcharts kann man updaten, Kubernetes-Ressourcen kann man updaten, es gibt noch viel mehr, guckt euch einfach mal an, am liebsten. Wie kann man es laufen lassen, der einfachste Weg ist, man kann nun nach, man kann das auch als NPM-Tool lokal laufen lassen, also wie mit NPM-Install und wie auch immer man das dann macht, wenn man JavaScript kann. Man kann, wenn man GitLab-CI verwendet, kann man einen eigenen Runner dafür installieren und Widesource als Hersteller bietet auch eine GitLab und eine GitHub Integration an. Wo ihr auch als Third-Party-App so wie bei die Panda-Bot im GitHub das Ding quasi einfach per Klick auf euer Repo zulassen könnt bleiben, welche Rechte das Ding hat. Ich habe mal zwei Apps gebaut und würde euch die einmal zeigen. Die eine ist die gleiche App wie vorhin, wo ich einfach eine sehr kaputte alte App genommen habe und mal sehen wollte, wie viele Updates kriege ich denn und wie sind die konfigurierbar. Ich würde euch zuerst diesen Runner sagt man manchmal oder den eigentlichen Bot agenterweise, was das tun soll, macht es natürlich nicht, es arbeitet nur Befehle ab. Einmal kurz zeigen. Ich habe GitLab-CI genommen, weil es sehr einfach zu verstehen ist, ihr könnt es genauso gut in GitHub Actions Jenkins mit einem Scheduler auf irgendeiner Linux-VM oder wo ihr das halt machen wollt ausführen. Das ist einfach nur ein Skriptbefehl. Was letztendlich passiert und was die essentiellen Werte sind, benutze dieses Docker-Image, was vom Hersteller hergestellt wird und bereitgestellt wird und führe folgendes Binary aus, das heißt Renovate. Das ist alles. Dann geht das Ding quasi her in diesem Repo und sucht diese config.js und hier wird es ein bisschen interessanter, weil hier kann man nämlich festlegen, an welchen Stellen nach neuem Code oder neuen Libraries gesucht wird und sich eigene Registries und Repositories angeben. Das heißt, wenn eure Firma Nexos Artifactory oder so was hat, wo ihr irgendwelche Artifakte hochladet, die ihr gebaut habt, dann könnt ihr die hier drüber auch abfragen und da sehen, habe ich da was Neues. Das ist vor allem interessant, wenn ihr eine App baut oder eine Lib und die in verschiedenen anderen Projekten auch benutzt. Dann müsst ihr irgendwie 50 Teams anfangen, einen Update zu machen, wenn sie am Ball bleiben wollen und die neuen Features haben wollen und hiermit kriegst du das quasi gratis und automatisch und kann eben auch mit Passwort dann umgehen, weil du zum Beispiel sagst, okay, hier ist dein Username und das injecterst du hier in dein Schedule rein und dann funktioniert das ganze Ding. Ich kann euch nachher auch die Folien und die Links irgendwie zukommen und dann könnt ihr das selbst updateen. In dem Fall ist es nämlich dieses GitLab CI File, wo eben die Version von diesem Docker Container drin stand. Das heißt, da bleibt ihr immer am Ball und da sieht man auch schon so einen Unterschied. Man könnte bei Docker einfach Latest verwenden und sagen, okay, ich habe immer die neueste Version. Da könnt ihr aber nie nachvollziehen, wann zumindest dieser Change passiert ist. Oder ein Älteres benutzt, weil er noch ein Container gecached hatte oder so was und lauf ich die ganze Zeit mit einer Version 15, weil die halt irgendwo bei meinem lokalen Docker-Deme noch im Cache liegt. Und dann gibt es noch ein Haufen andere Einstellungen, so ein paar habe ich später nochmal rausgepickt, deswegen springe ich da jetzt mal kurz drüber. Der wichtigste ist wahrscheinlich, ihr braucht ein Git Author, weil Renovate oder dieses Skript stellt einen Pool-Request oder Merch-Request, je nachdem, in dem Fall wird es dann nachher dieses. Ich habe das am Anfang einfach mal auskommentiert beim ersten Komet. Und dann kommt noch so ein Haufen andere Config. Und was dieses Skript braucht, was ist hier in den Variablen letztendlich für dieses Schedule dann braucht, Variablen sind zwei Keys. Einmal ist es der Renovate Token. Das ist ein Api-Key, der muss Schreibrechte haben auf allen Repositories, die ihr quasi renovieren oder für die ihr Pool-Request stellen müsst. Ganz klar, sonst kann er keine Pool-Request stellen, vielleicht auch keine Merchen. Und dann gibt es ein GitHub-Token, der muss gar nichts können. Aber GitHub hat so die Vorgabe, wenn du in GitHub irgendwie was öffentliche Info aus der Api abrufen willst, musst du es mit einem User passieren. Und dieser User muss eben ein Api-Key ausstellen. Warum GitHub? The Panda Board verbindet sich mit GitHub, mit einem öffentlichen Registry oder von Open Source Zeug und sucht dann in GitHub die Release Notes. Und ihr kriegt dafür eben an diesen Pool-Request als Kommentar dran, warum habe ich das Ganze denn gemacht? Was euch dann nachher, wenn ihr überlegt, soll ich das jetzt merken oder in meinen Mailern Branch mit reinbringen, das natürlich viel einfacher macht und spart wieder Zeit, weil ich gar nicht gucken muss. Hat sich jetzt bei Spring 2, 6, irgendwas was geändert, muss ich das googeln, und dann sind wir natürlich bei der Security-Ebene. Natürlich sollte das ein Token sein, der auch wirklich nur diese Rechte hat. Ja, ganz klar. Je weniger irgendein Token kann, desto weniger Problem ist es, wenn das Ding irgendwo geheitcheckt wird. Genau. Und dann, wenn das Ding das erste Mal gegen sich selbst quasi läuft, gibt es einen Onboarding-Merch-Request. Damit trägt sich Renovate quasi in das Zielrepo, in dem Fall er selbst oder sie selbst oder er selbst, wenn da jemand drauf steht, ein und sagt dir quasi als Kommentar, Achtung, ich habe erkannt, in diesem Repo gibt es GitLabCI, da werde ich in Zukunft Updates machen. Ja. Und dann kriegt man unten noch so ein What-to-Expect und er sagt hier Achtung, ich möchte hier Renovate auf Version 2912, als das Ding damals gelaufen ist, dieser Onboarding-Merch-Request, war das die aktuellste, die ein Update vorschlagen. Ja, und dieser Pull-Request, das ist noch nicht das Update, sondern er macht quasi die Basiskonfiguration und der schreibt hier in dieses Repo rein so ein Snippet und das passiert quasi in jedem Repo, das er renovieren wollte, bei diesem Onboarding-Merch-Request. Und dann ist die Idee, dass man in dieser Konfig, in dem jeweiligen Repo einstellen kann, in welcher Variante updaten möchte oder welche Lips. Ich zeig es gleich an der anderen App, da sieht man ein bisschen mehr als hier und das hier war es quasi schon. Das heißt dieser, dieses Skript wird sich selbst updateen oder das eigene Repo und wird immer mehrere Updates vorschlagen, nämlich eine Minor und eine Major und das kann man auch konfigurieren. Im Fall von Renovate würde ich einfach empfehlen, aus den letzten, keine Ahnung, 2, 3 Jahren, wo wir das benutzen, bleibt einfach auf der modernsten Version, die unterstützt die meisten Sprachen und die meisten Features im Zweifelsfall geht nur der Renovate Run kaputt. Und ihr habt dann keine Updates und habt ihr vielleicht hoffentlich alerting oder so. Genau. Da waren wir schon. Da waren wir auch schon. Genau. Und dann ist es die eigentliche App, ist die von vorhin, eine sehr gute, sehr sichere App, mit uralen Schwachstellen von 2013. Und wie gesagt hier, ich kann ein Pipeline-Schedule hier drin ist am Anfang ein erster Security-Check, wie ich vorhin gesagt habe, der erst mal zeigt, was ist denn hier alles kaputt. Wie gesagt, finde ich persönlich wichtiger, als automatische Updates zu machen, zur Entscheidung, was möchte ich updaten, auf jeden Fall erst mal zu merken, wo habe ich denn gravierende Schwachstellen, vielleicht. Genau. Wenn ich jetzt hier so ein Onboarding-Merch-Request gegen mache, gegen dieses Repo, dann sehe ich schon ein bisschen mehr als eben. Und zwar wird hier wieder gesucht, das müsste man von hinten sehen. Was habe ich denn da drin alles gefunden? Und ich habe ein Dockerfile eingetütet, ich habe ein GitLab-CI-Hammel eingetütet, wo die Images für die GitLab-Runner, also wo CI passiert und die Bills passieren, updated wird. Und ich habe eine POM gefunden, weil ich hier Maven, also das ist quasi die Standardkonfiguration für Artefakte und Dependencies von Maven, in dem Fall von Java. Und das hier ist ziemlich standard. Und dann gibt es eben hier eben diesen Word to expect, schon mal so eine Art Vorauswahl. Wenn du Renovate für dieses Ding anschaltest, für diese App bekommst du wahrscheinlich folgende Updates vorgeschlagen. Und hier sieht man auch wieder, es gibt einen Vorschlag für ein Docker Update 11.0.13, also innerhalb der gleichen aktuellen Version, aber auch eine latest Version. Und hier muss man nachher mit der Konfig ein bisschen aufpassen, weil wenn ihr eine Java 11 App habt, d.h. in dem Fall dieser OpenJDK-11.irgendwas Container und baut den plötzlich mit einer Java 18, weil es da gerade HIP war, könnte es sein, dass das nicht so gut für eure App ist. Es könnte sein, dass es funktioniert und dass ihr nachher komisches Verhalten habt in Produktion. Das hier ist aber auch was, wenn ihr sowas in Terraform habt, zum Beispiel. Es ist natürlich immer ein Riesending, ein Major Update zu machen. Grundlegend auch bei Software, wenn ihr ein Artefakt habt, sind Major Updates ja auch meistens die, wo man Breaking Changes drin versteckt. Und dann kann man auch Einstellungen machen, zum Beispiel, dass man pro Stunde nur so und so viele Request stellt oder so und so viele Branches eröffnet. Das ist einfach in den meisten Firmen ein Kostenfaktor. Wenn ihr in der Cloud seid und Renovate macht euch 500 Poolrequests auf oder Branches und da läuft überall CI los, könnte es sein, dass am nächsten Tag das Controlling bei euch vor der Tür steht und die glühende Kreditkarte hochhält und sagt hier, was da los. Weil wenn ihr viele Tests habt und ich liebe viel in der Cloud, oder wenn ihr das auf dem Blech habt im Rechenzentrum merkt, wundert ihr euch, warum kann ich keine Bills mehr machen? Weil alle Run-out oder alle Build Agents sind gescheduled, um diesen ganzen Kram herabzuarbeiten. Und wenn ihr 100 Poolrequests habt, sollten eigentlich sobald einer gemirkt wird, alle anderen 99 erstmal auf diesen neuen Stand aufbauen und rebased werden, weil geht letztendlich, weil nur dann kriegt ihr bei all den anderen Krams aus eurem ganzen CI-Kramp, aus eurem ganzen Qualitäts-Check-Mechanismus. Weil sonst habt ihr irgendwie so ein zusammengematschtes Zeug, wo keine Version zu einer anderen passt, möglicherweise. Und alle Pipelines sind grün und dann werden alle gemirkt und es ist einfach komplett tief rot und ihr könnt wieder von vorne anfangen von Hand. Genau, wie das dann läuft, ist relativ wurscht. Man kann auch ausprobieren. So sieht ein Poolrequest aus. Wir haben da so ein Sicherheits-Check drin. Und der erste Poolrequest, den ich aus der Liste gepickt habe, ist einfach, da hat quasi der, muss ich den Poolrequest suchen, der Dependency-Check. Für meine App einen Poolrequest gemacht, da steht hier drin, was für ein Update ist hier drin. Wie alt ist das Update? Was ist so ein paar Kennzahlen oder so, was ist der eigentliche Change? Und das ist das, was ihr von Hand machen müsstet, was so ein Riesen-Pain ist im Vergleich zu, man kriegt es geschenkt, man kriegt eine neue Version. Gibt es eine neue Version? Ist es die 7.1 oder die 7.1.2 oder so was? Und das ist halt so ein manueller Aufwand, den kann man sich einfach sparen. Und dann kann man hier so ein bisschen Zeug konfigurieren. Das kann man auch global machen. Ich zeige gleich noch ein paar Beispiele. Ich muss ein bisschen bei allen Zeug. Was man hier noch sieht, was eben ganz cool ist, man kriegt Release Notes, sofern es die bei GitHub gibt. Also, das ist dafür braucht man diesen GitHub-Apike. Da wird quasi nachgeschaut, was ist denn in diesem Update drin, damit euch die Entscheidung leichter ist, möchte ich es merken. Oder möchte ich das Auto merken, da guckt keiner in die Release Notes rein. Genau, dann gibt es ein Haufen Updates, habe ich schon gesagt. Okay, dann, wenn ihr diese ganzen Updates habt und vielleicht noch so zwei Sätze zur Konfiguration von dem ganzen Gerät, es gibt zwei Arten, das Ding zu betreiben. Eine ist, ein globales Renovate-Repro zu haben, das Zugriff auf alle eure Projekte hat. Dann habt ihr einen Scheduler und könnt besser feststellen, wie viele Pull Request möchte ich gleichzeitig bei welchem Projekt haben und das Ganze global steuern. Wenn ihr admin in eurer org seid oder das admin-Team das machen möchte, kann man sowas auch für alle anderen Teams machen. Da kann eine admin-Team Credentials für alle möglichen Repositories, Registries eintragen, kann sich ein Scheduler aussehen, wann es für sie gut ist, dass die ganzen Jobs laufen und so weiter. Der Nachteil ist, wenn euch dieser Apike flöten geht, der hat Zugriff auf alle Projekte. Die Alternative ist, was Renovate selbst macht, ist sich selbst updaten und das, also quasi rechte Seite, das kann man auch in jedem einzelnen Projekt machen, weil diesen Renovate-Job und sich selbst steuern. Das kann man auch für jedes einzelne, das könnte man auch in dem App-Projekt machen. Das ist dann cool, wenn ihr zum Beispiel öffentliche Repos habt, weil da möchtet ihr nicht, wenn ihr ein Render mit dem Granularer zu steuern. Ich habe mal doch so die wichtigsten, meiner Meinung nach oder verbreiteten Config-Dinger rausgesucht, Config-Möglichkeiten, ich glaube noch 5 Minuten hau ich die kurz runter. Ein Hind wäre was, was grundlegend super interessant ist, SchemaStore.org. Hat mit Renovate wenig zu tun, aber bei SchemaStore.org gibt es die Schematah oder die verschiedenen Jason Flavors für alle möglichen Programmiersprachen und Tools, die ihr bekommt in eurer IDE zum Beispiel. Also, dass ihr zum Beispiel Renovate so was wie Base Branches nur Base tippen müsst, sondern kriegt ihr einen Vorschlag, du möchtest Base Branches verwenden und direkt richtig eingerückt und irgendwie richtige Synthes und so. Super gut. Genau, hier geht es nur darum, wann möchte ich rebasen, also sprich, wann kann ich auf einen neuen, neue Version aufsetzen und diese ganzen Konfigurationen, die führt Renovate bei jedem Run aus. Das ist ja um, weiß ich nicht, drei nach oder sowas. Und prüft wieder alle die Pull Request, die er gestellt hat, für das Zielrepo und sagt, ah, da hat sich was getan, er zieht sich den, den, quasi den Branch, gegen den er die Pull Request stellen soll und sagt, okay, der hat sich irgendwas verändert, ich rebase mal alle und lasse sie nochmal laufen. Dass ihr eben auf dem aktuellen Stand das Update angeboten bekommt. Dann gibt es Package Rules, da könnt ihr einfach so Untergruppen und das möchte ich zum Beispiel immer automatisch merken. Ich möchte für jeden dieses Separate Major Miner in der Mitte sagt sowas aus, wie ich möchte immer nur die größte Version haben. Es ist mir egal, ob es noch eine Miner Version gibt. Wenn eine Major da ist, möchte ich für die das haben. Ich möchte bestimmte Versionen per Regex exkludieren oder inkludieren. Dann eben die Frage, möchte ich das haben. Und das sage ich quasi, ist mir alles egal, ich mache da irgendwelche Abstriche. Versionen erlauben, zum Beispiel wir hatten früher mal den Deal, dass wir gesagt haben, bei GitLab, beim Betreiben hier Infrastructure ist Code, wir benutzen nie die 0.0 Version, weil die war immer irgendwie kaputt am Anfang. Verzögerung, super spannend. Ihr könnt quasi sagen, ich möchte das Update immer haben, zum Beispiel bei UA Pasa, jemand Credentials von NPM Registry gefunden hat und Melvier auf ein Paket gepackt hat und das released hat als neue Version. Was passiert ist, Leute, die automatisch bei uns auch schnelle Updates hatten, die haben Instant, dass quasi das Paket kommt, the next renovate run, der baut euch das in euer Tool ein. Und alle Entwickler, die zufällig danach sagen, ha, NPM install ist das. Und NPM erlaubt sich zum Beispiel, ich glaube bis zu drei Tage lang ein Paket zurückzuziehen, wenn sich sehr viele Leute darüber beschweren, dass es technisch einfach schlecht ist und Abstürze gibt. Aber renovate kann nur upgrade und kein Downgrade. Genau, fast fertig. Auto Merge, sparten Haufen Zeit. Wir haben für uns rausgefunden, man muss das, einfach wir machen das mit Package Rules, wir sagen zum Beispiel von anderen Teams gebaut wurde oder auch kuratiert wurde, das Merchandir automatisch. Da sind wir sicher, das funktioniert, wenn denn unsere ganzen Tests auch grün sind. Natürlich mein erstes Go-to Ding. Grundlegend ist es so, ich vertraue meinen Tests. Wenn ein anderer Entwickler mir manuell ein Update schickt, gucke ich ja auch nur, ist der Test grün und nett. Ich muss das mal alles von Hand testen. In dem Moment, wo ich von Hand Tests mache, und hier gibt es natürlich eben einen Scope, dass man sagt, bestimmte Items habe ich schon gesagt, oder zum Beispiel wir merchen Patches in einem Projekt, dass wir komplett von Anfang an gebaut haben, merchen wir alle Patches automatisch und rollen die auch direkt nach Produktionen aus. Also so was wie Spring Boot 2.6.3 auf 2.6.4, das passiert irgendwann nachzuläuft morgens im Brott. Gesetz hat voraus, wenn es kaputt geht. Dann kann man in der Commit Message noch rumfuschen, dass man sagt, das muss ein gewisses Format haben, da müssen gewisse Inhalte rein. Es bleibt leider immer noch die Frage, sobald es nicht ein Auto Merch ist und es kann einem leider niemand abnehmen, es gibt keine Silver Bullet dafür, wer ist der Verantwortliche, wer macht das bei euch? Aber derjenige hat zumindest den ganzen händischen Aufwand vorher, um rauszufinden, und dann wie ich schon gesagt habe, wie oft will man updaten, das soll ich auch selbst überlassen. Jede Major, wäre vielleicht ganz gut, dass man halbwegs am Ball bleibt, keine Breaking Changes auslässt, die einem nachher, wenn man schnell updaten muss, irgendwie auf Deutsch in den Arsch peißen. Und was macht man mit Continuous Delivery? Kann man Updates ungesehen nach Brott ausrollen? Es ist auch so eine gewisse Frage, wie weit vertraut ihr euren Tests, wie weit vertrauen eure Produktmanager in ihrer Kultur mal zu sagen, ja, es ging jetzt leider in die Hose. Wir müssen jetzt nochmal zurück. Ansonsten noch kurz ein Fazit, bitte macht irgendwie Updates. Es ist keine Lösung, im Dezember gesagt zu haben, oh, wir haben Lock for J1, da ist noch nichts passiert. Es gilt erst ab zwei, gut, dass wir keinen Update gemacht haben. Wenigstens Security Updates sollte man auf jeden Fall immer machen und auch immer zeitnah. Und benutzt Automatisierung, macht euch das Leben leichter. Wenn ihr das zweimal gemacht habt, ist es oft schneller, einmal automatisiert. Selbst wenn man eine Woche braucht, einen fünf Minuten Job zu automatisieren, unabhängig auch von Updates und Tests, ist es wenigstens immer gleich richtig oder immer gleich falsch. Man hat das ja, der eine Typ sagt, das braucht man nicht automatisieren, da brauche ich fünf Minuten für jede Woche. Bisher krank ist, oder besser ein Unfall hat, oder kündigt. Und dann seid ihr froh, ihr habt eine Automatisierung, da kann auch jeder neue Entwickler nachlesen, Moment folgende Schritte werden da immer wieder gemacht. Da kann keiner Schritt drei vergessen. Ansonsten bedanke ich mich, wenn ihr Fragen habt und die Zeit reicht immer, aber ich habe schon zweimal ein Papier mit Zahlen hochgehoben bekommen. Auch gerne nachher, ich bin den ganzen Abend da. Ansonsten, wenn ihr Feedback habt, schreibt mir gerne Mail oder irgendwie Twitter oder das andere Gerät. Dankeschön. Dann danke dir, wir haben noch sieben Minuten Zeit für Fragen. Die Frage ist, hatte ich schon Probleme mit False Positives bei Renovate. Ich weiß nicht genau, wo. Aber wahrscheinlich nicht. Du weißt wahrscheinlich auch nicht mal, an welcher Stelle, oder? Okay. Kann ich gerade nicht sagen, müsste ich nachher suchen, wenn du noch Zeit hast. Oder müssen wir irgendwie zusammen nochmal drübergehen über die ganzen? Nein. Also, möglicherweise bei dem Sicherheitsscannerzeug, da gibt es viele False Positives tatsächlich, dass ihr zum Beispiel, was haben wir denn letztens gehabt? Sagen wir mal, ihr habt irgendeine Version einer Java Bibliothek. Und da gibt es in Zusammenspiel mit irgendwas anderem eine Schwachstelle. Und der Dependency Scanner meckert euch das an. Sagt ihr, guck mal, das ist kaputt, das willst du fixen. Und du guckst da rein und siehst Moment. Da steht aber dabei, dafür musst du irgendeinen komischen Mail-Server von Java verwenden, damit es oder SMTP verwenden oder XML verwenden. Und du hast aber zum Beispiel das Garnet, du benutzt kein Mail, du hast JSON überall. Dann betrifft dich das vielleicht gar nicht. Und dann könntest du ein False Positives exkluden oder früher hieß es mal Whitelisten erlauben, dass der Scanner dich jedes Mal drauf aufmerksam macht, obwohl du weißt, es ist mir egal, das stört mich jetzt nicht. Vielleicht gibt es auch keinen Patch, weil jeder sagt Moment, Apache James, das ist der komische Email-Server von Java, den nutzt kein Mensch. Da brauche ich nicht woanders die Sicherheitslücke zu fixen, weil sie da drin auftaucht, aber irgendwie hier zugeordnet wird bei meiner Bibliothek. Also grundlegend. Und mit den Positives habe ich in Renovate noch nicht gesehen. Ich wüsste da nicht, wie oder warum. Was Renovate manchmal macht, wenn man dieses Stability-Days verwendet und ihr benutzt Docker, es gibt sehr viele Hersteller, die verbreiten Docker-Container und die benutzen immer den gleichen Tag. Beispiel OpenJDK 11.0.15, davon gibt es jede Woche eine neue Version mit dem neuen Basiskontainer. Wenn ihr fünf Tage Stability-Days habt und Montags wird das Ding released und Sonntags hat Renovate euch gestellt, macht er ihn Montags wieder zu. Weil er sieht, das Rental Release ist noch keine fünf Tage alt. Der Timestamp ist noch zu neu. Das kann so ein bisschen schmerzhaft sein, aber dann kann man eben wieder hingehen und sagen, für bestimmte Pakete kann ich es eben separat überschreiben. Da muss man dann halt leider durch, genauso wie bei Schwachstellen, da muss man einmal Tabula Rasa macht und sagt, ich habe jetzt alle Updates. Ein Punkt noch, den mir eingefallen ist, so als Learning vielleicht noch ist, ich habe vorhin mal gezeigt, dass man in Renovate einstellen kann, für welche anderen Projekte oder das eigene Projekt, so als Target, Renovate benutzt werden soll. Wenn man da nichts hinterlegt, macht Renovate diesen onboarding Pull Request gegen alle Projekte, die er sieht. Also alles, wo der Apike funktioniert. Und wir haben das in einer Firma, wo ich vielleicht mal Arbeit habe oder noch Arbeit gemacht, wo ich viel durfte, weil beim ersten Rundspiel nimmst du deinen eigenen User und machst deinen apike für einen Projekt. Und dann gab es am nächsten Tag ein bisschen Ärger, aber wir haben irgendwie in 80 Projekten diesen onboarding Pull Request gemacht und überall sind Pipelands losgelaufen. Und die Leute haben sich gewundert, warum wir, was das jetzt soll, dass wir ihnen sagen, guck mal, ihr habt folgende Schwachstellen oder ihr habt ein sauberes Setup, was eure Rechte angeht, dann ist auch okay. Noch jemand? Ansonsten, ja. Warten wir kurz. Du kriegst ein Mikro. Kann man das auch nutzen, Renovate, um das zu dokumentieren. Also dann ist Zustand, aber wenn ich das jetzt einführen würde, dann weiß ich genau, ich habe es vielleicht, also 50 Security Problems, die ich nicht sofort fixen kann. Kann ich das vielleicht irgendwas machen, das Ergebnis pushe ich in Confluence, dass man zumindest mal den Istand dokumentieren kann und dann eben handeln zu können. Also Renovate ist das Tool, das nur die Updates vorschlägt, unabhängig davon, ob es eine Security Issue gibt. So was wie dependency check oder SNCC oder GitLab, der Security-Part von GitLab oder JFrog oder sonst wie die ganzen Tools, auch die Pendeboard, die können reagieren, wenn der Schwachstelle da ist. Die geben den Moment im Standard, in ihrem Job was es alles kaputt. Es gibt aber auch welche davon, zum Beispiel SNCC kann automatisch pro Schwachstelle per Click auch einen Pull Request machen. Also es kann das nur für Open Source gratis und sonst musst du halt die Bezahlversion kaufen. Deswegen habe ich es jetzt mal runterfallen lassen, aber es gibt Tooling des Kandes. Ich bin mir bei dependency check sicher, ob der das kann, so was gegen Gira zu integrieren. Aber prinzipiell müsstest du ja nur irgendwie einen Github-Issue machen. Den gibt es als XML, als HTML und so weiter. Ich kann das auch noch mal in der Box mal zeigen. Führt jetzt wahrscheinlich für den Rest zu weit oder von der Zeit her auch ein bisschen los. Da könnte man einfach ein Paar da drüber laufen lassen und sagen, okay, für jedes Item aus dieser Liste schreibe ein Gira-Ticket oder ein Redman-Ticket oder ein Github-Issue und schreibe rein, folgende Schwachstelle wurde gefunden. Name, CVE-Nummer, auch irgendwie später vielleicht auch eine Auswertung fahren. Aber grundlegend würde ich immer empfehlen, wenn man weiß, dass es sowas gibt, macht mal so ein Security Scan. Und wenn ihr das nur auf dem ausgecheckten Repo bei euch auf der Kiste macht, weil wenn man nicht regelmäßig updated, eigentlich immer Findings dabei, die man zumindest mal überlegen sollte, die zu fixen, und es ist meistens lernt man auch was dabei. Die Reports von den ganzen Tools, die sind super cool, die schreiben meistens noch nicht nur den Eintrag aus der CVE-Datenbank, vom NIST, sondern auch noch eine Liste von Blockposts, die jemand dazu geschrieben hat. Und bei diesem Equifax-Ding, z.B. bei Struts, ist die Liste halt sehr lange inklusive Links zu ExploitDB, wo ihr direkt so Proof-of-Concept-Python Snippets bekommt, mit denen ihr mal kurz euren eigenen Shop kaputt machen könnt. Hoffentlich nicht im Pod. Eine letzte kurze Frage. Dann ist weniger eine Frage, weil wir setzen auch dependency-Check ein. Mittlerweile gibt es seit letztes Jahr dependency-Track, das ist ein etwas anderer Ansatz, vor allem wenn ich dann mehrere Projekte habe, wo ich die Information konsolidieren möchte, und dann habe ich dort auch einen kleinen Workflow drin, um dann zu vermerken, ist es relevant, Risk-Acceptance, eine entsprechende Suppression. Also das ist nur eine kleine Ergänzung. Genau, man kann die Ergänzung noch breit treten. dependency-Track ist letztendlich so eine zentrale Verwaltung, wo die verschiedenen dependency-Check-Tools, die ihr laufen lasst, auch hinreporten können. Das heißt, wenn ihr zum Beispiel eine zentrale Sicherheitsorganisation habt, dann können die dependency-Track für jedes Projekt auch nachvollziehen. Was gibt es da alles? Was sind für Suppressions eben drin? Also das, was man früher als White List bezeichnet hat, in politisch unkorekt. Und warum ist das da drin? Ihr könnt das aber jeweils auch am Projekt. Suppressions kann man auch an den Projekten selbst steuern. Und da habt ihr wieder dieses mega starke Tool mit Message. Ich habe folgendes Update kategorisch, oder diese Sicherheitslücke kategorisch gestrichen aus unserem Tool bis zum Zeitpunkt X, oder für immer. Aber ich unterschreibe dafür in meinem guten Namen und meinem Git-Account und schreibe rein warum. Genau, aber es ist super cool, weil man eben dann zentral auch so eine Liste hat, welche unsere 800 Apps in einer riesigen Firma hat, denn zum Beispiel Lockfortale 214. Genau. Dann danke für den vorderen Nr. Kräftinger, bis dann. Danke.