An der DEVOPS Conference habe ich über ein Thema gesprochen, das seit über zwei Jahrzehnten im Mittelpunkt meiner Arbeit steht: Wie man die Architektur für Continuous Delivery gestaltet. Dieser Vortrag behandelt den kaputten Wertstrom, den ich in den meisten Unternehmen sehe, warum Produktdenken wichtiger ist als Projektdenken, die Wissenschaft hinter der Software-Delivery-Performance und wie Platform Engineering es Organisationen ermöglicht, DevOps durch digitale Fabriken zu skalieren.
Am State of DevOps in der Schweiz 2023 Event habe ich gemeinsam mit Adrian Kosmaczewski von VSHN die neuesten Erkenntnisse zur DevOps-Adoption im Schweizer Markt präsentiert. Adrian teilte vier Jahre Umfragedaten, während ich mich darauf konzentrierte, wie man DevOps durch Platform Engineering und das Konzept der digitalen Fabrik erfolgreich skalieren kann. Diese Veranstaltung brachte DevOps-Fachleute vor Ort und virtuell zu Präsentationen und einer lebhaften Podiumsdiskussion zusammen.
Nach elf Sessions, in denen wir eine komplette DevSecOps-Pipeline mit GitHub aufgebaut haben — Software Composition Analysis, License Compliance, SAST, Container Scanning, Secret Detection, DAST, Pull Requests, Scheduled Pipelines und Vulnerability Management — schliessen Patrick Steger und ich die Serie mit unseren Empfehlungen ab. Was auf GitHub funktioniert, wo die Lücken sind und was wir jedem mitgeben würden, der die gleiche Pipeline bauen will.
Über zehn Sessions haben wir Security-Checks in eine GitHub-Actions-Pipeline verdrahtet, die auf jedem Commit und jedem Pull Request feuert. Das deckt den Code ab, an dem wir aktiv arbeiten. Es deckt nicht den Code ab, der bereits in Produktion läuft, während Researcher laufend neue CVEs in den Libraries finden, die er nutzt. In Teil 11 der GitHub DevSecOps Serie bauen Patrick Steger und ich einen Scheduled Workflow, der den Production-Branch erneut scannt — und stossen dabei auf eine GitHub-Limitierung, die man von Anfang an kennen sollte.
In den vorherigen neun Sessions haben Patrick Steger und ich eine GitHub DevSecOps-Pipeline gebaut mit Build, SCA, License Compliance, SAST, Container Scanning, Secret Detection und DAST. Alles nützlich — aber nur dann, wenn sie tatsächlich läuft, bevor Code in main landet, und nur dann, wenn der Merge blockiert wird, sobald etwas Ernstes auftaucht. In Teil 10 verdrahten wir dieses Gate mit Pull Requests und Branch Protection Rules.
Wir haben in den letzten acht Sessions Scanner in unsere GitHub DevSecOps Pipeline eingebaut — SCA, SAST, Container Scanning, Secret Detection, DAST. Die Scanner produzieren jetzt einen kontinuierlichen Strom von Findings, und die Frage lautet: Wo managen wir sie? In Teil 9 schauen Patrick Steger und ich uns das eingebaute Vulnerability Management von GitHub an — den Security Tab — und benennen, was funktioniert und was fehlt.
Begleiten Sie Eveline Oehrlich und Romano Roth bei der Diskussion, ob DevOps tot ist.
Transkript # Narrator 00:02 Sie hören den Humans of DevOps Podcast, einen Podcast, der darauf ausgerichtet ist, die Menschen im DevOps-Umfeld durch Fähigkeiten, Wissen, Ideen und Lernen weiterzubringen – das SKIL-Framework.
Nach sieben Sessions statischer Analyse — SCA, License Compliance, SAST, Container Scanning, Secret Detection — wechseln Patrick Steger und ich auf die dynamische Seite der Pipeline. In Teil 8 ergänzen wir Dynamic Application Security Testing in unserer GitHub-Actions-Pipeline. DAST startet die Anwendung und greift sie dann an. GitHub liefert das nicht out of the box, also bauen wir eine Community-Action auf Basis von OWASP ZAP ein — und sind ehrlich, wo dieser Ansatz für Enterprise-Use an Grenzen stösst.
In Episode 88 von DevTalk spreche ich mit Kerry W. Lothrop über den Stand von DevOps.
Originalbeitrag: DevTalk 88: Romano Roth
Alle wollen DevOps machen. Aber warum? Welche Probleme versuchen wir zu lösen?
Einen Schritt zurücktreten # Gemeinsam treten wir einen Schritt zurück und betrachten das grosse Ganze. Statt direkt in Tools und Praktiken einzusteigen, untersuchen wir die Systeme und Wertströme, die moderner Softwareauslieferung zugrunde liegen.
API-Keys, Tokens und Passwörter rutschen nach wie vor regelmässig in Repositories — manchmal aus Versehen, manchmal weil Entwickler es ehrlich nicht besser wussten. In Teil 7 unserer GitHub DevSecOps Serie schalten Patrick Steger und ich GitHubs eingebautes Secret Scanning ein, definieren ein eigenes Pattern, probieren Push Protection aus und schauen offen hin, wo die Funktion liefert und wo sie noch nicht hält, was sie verspricht.
Wir haben die GitHub-Actions-Pipeline in fünf Sessions aufgebaut: Projekt-Grundlagen, Software Composition Analysis, License Compliance und Static Application Security Testing. Die nächste Schicht ist Container Scanning — die Suche nach Schwachstellen im Docker-Image, das wir ausliefern, nicht nur im Source, den wir geschrieben haben. In Teil 6 unserer Serie teilen Patrick Steger und ich die Arbeit in zwei GitHub-Actions-Sub-Workflows auf: einer baut das Image und pusht es in die Registry, der andere zieht es zurück und lässt Trivy darauf laufen.
