Hardcodierte Passwörter und API-Keys sind nach wie vor einer der häufigsten Wege, auf denen Credentials nach aussen gelangen. Sie werden versehentlich committet, bleiben für immer in der Git-History und tauchen meist erst dann auf, wenn sie schon ausgenutzt werden. In Teil 7 unserer GitLab DevSecOps Serie ergänzen Patrick Steger und ich die bestehende Pipeline um Secret Detection — eine Zeile YAML — und schauen dann ehrlich hin: Was findet GitLeaks tatsächlich, was übersieht es still, und was tun wir damit?
Wir haben SAST, Secret Detection und Software Composition Analysis bereits in die GitLab-Pipeline integriert. Diese Checks decken Quellcode und Dependencies ab — aber das Artefakt, das wir tatsächlich ausliefern, ist ein Container-Image. Betriebssystem-Pakete, das Base-Image und alles, was im Lauf des Builds hineinkopiert wird, können eigene Schwachstellen mitbringen. In Teil 6 unserer Serie ergänzen Patrick Steger und ich die Pipeline um Container Scanning, bauen ein Docker-Image aus dem zuvor kompilierten Jar und schicken es durch Trivy und Grype.
Software Composition Analysis kümmert sich um die Bibliotheken, die du einbindest. Aber was ist mit dem Code, den dein Team selbst schreibt? Genau dafür ist Static Application Security Testing da. In Teil 5 unserer GitLab DevSecOps Serie integrieren Patrick Steger und ich SAST in die Pipeline, bauen ein paar realistische Schwachstellen in unser Spring-Boot-Beispiel ein und schauen zu, wie GitLab sie aufgreift.
Du lieferst eine Java-Anwendung aus, die von Spring Boot abhängt, das wiederum von dutzenden weiteren Bibliotheken abhängt — jede mit ihrer eigenen Lizenz. Und die meisten Teams können dir nicht sagen, welche Lizenzen das eigentlich sind. In Teil 4 unserer GitLab DevSecOps Serie ergänzen Patrick Steger und ich die Pipeline um License Compliance, sodass diese Frage bei jedem Commit automatisch beantwortet wird. Die gute Nachricht: Mit GitLab Ultimate ist das eine Template-Zeile.
Dein Code ist der kleine Teil. Die Libraries, die du reinziehst, sind der grosse Teil — und genau dort steckt der Grossteil deiner CVEs. In Teil 3 der GitLab DevSecOps Serie bauen Patrick Steger und ich eine kleine Spring-Boot-Demo auf, hängen sie in eine GitLab-Pipeline und ergänzen anschliessend Software Composition Analysis mit einer einzigen Include-Zeile.
Bevor wir irgendwelche Security-Checks nach links verschieben können, brauchen wir ein Projekt, ein Repository und eine Pipeline, die tatsächlich etwas baut. In Teil 2 unserer GitLab DevSecOps Serie loggen sich Patrick Steger und ich in GitLab ein, legen ein neues .NET-Core-Projekt aus einem Template an und schauen uns die .gitlab-ci.yml an, die GitLab automatisch für uns generiert — inklusive Build- und Test-Job, die das Fundament für alles werden, was wir später ergänzen.
Warum wird Security immer noch am Ende des Entwicklungsprozesses angeflanscht — und wie können wir sie nach vorn verschieben, ohne die Teams auszubremsen? In Teil 1 unserer GitLab DevSecOps Serie legen Patrick Steger und ich die Grundlage: Was GitLab ist, was Shift Left wirklich bedeutet und welche CI/CD-Konzepte man verstanden haben muss, bevor man eine DevSecOps-Pipeline bauen kann, die in der Praxis funktioniert.
Wie stellt man sicher, dass die eigene Organisation nicht mit zu vielen Projekten, zu vielen Ideen und zu wenig Fokus überlastet wird? Und wie stellt man sicher, dass man das Richtige baut? Genau dafür gibt es Epics. In diesem Video erkläre ich das Konzept der Epics, zeige ein konkretes Beispiel und erläutere, warum Epics deutlich effektiver sind als traditionelle Projekte.
Hast du dich jemals gefragt, was “DevOps Engineers” eigentlich tun? Was bedeutet “DevOps” überhaupt? Dieser Blogbeitrag soll das Konzept von DevOps erklären und den Wert aufzeigen, den es einer Organisation bringt.
In den letzten Jahren habe ich zu jeder einzelnen Aktivität im SAFe DevOps Health Radar einen Deep-Dive veröffentlicht. Dieser Beitrag ist die Tour rund um den Radar: eine einzige Seite, die Sie durch alle vier Aspekte und alle sechzehn Stages führt, mit dem Originalvideo zu jeder Aktivität und einem Link zum vollständigen Artikel. Nutzen Sie ihn als Karte — um Ihren Einstiegspunkt zu finden, um ihn mit Ihrem Team zu teilen oder um zu bewerten, wo Sie heute stehen und wohin Sie als nächstes wollen.
Release on Demand ist der letzte Schritt in der SAFe for DevOps Continuous Delivery Pipeline, und es ist der Schritt, der alles zusammenführt. In diesem Video erkläre ich, wie Release on Demand funktioniert, warum die Trennung von Deployment und Release so wirkungsvoll ist und wie die gesamte Pipeline Organisationen befähigt, das Richtige richtig zu bauen.
Feature Toggles sind eines dieser Konzepte, die auf den ersten Blick einfach klingen, aber in der Praxis enormes Potenzial entfalten. In dieser Session des DevOps Meetup Zürich spreche ich gemeinsam mit Ben Rometsch, dem Gründer von Flagsmith, über das Was, Warum und Wie von Feature Toggles. Wir behandeln die grundlegenden CI/CD-Konzepte, die Feature Toggles notwendig machen, den Unterschied zwischen Deployment und Release, und wie moderne Feature-Flagging-Plattformen progressive Rollouts, User-Segmentierung und A/B Testing ermöglichen.
