Hard-coded passwords and API keys are still one of the most common ways credentials leak. They get committed by accident, stay in the git history forever, and only show up when someone is already exploiting them. In Part 7 of our GitLab DevSecOps series, Patrick Steger and I add Secret Detection to the same pipeline we have been growing — one line of YAML — and then look at what GitLeaks actually finds, what it quietly misses, and what to do about it.
We have already wired SAST, secret detection, and software composition analysis into the GitLab pipeline. Those checks cover the source code and its dependencies — but the artifact we actually ship is a container image. Operating system packages, the base image, and everything copied in along the way can carry vulnerabilities of their own. In Part 6 of our series, Patrick Steger and I add container scanning to the pipeline, build a Docker image from the jar we compiled earlier, and push it through Trivy and Grype.
Software composition analysis takes care of the libraries you pull in. But what about the code your own team writes? That is where Static Application Security Testing comes in. In Part 5 of our GitLab DevSecOps series, Patrick Steger and I add SAST to the pipeline, plant a few realistic vulnerabilities in our Spring Boot sample, and watch GitLab pick them up.
You ship a Java application that depends on Spring Boot, which depends on dozens of other libraries, each with its own license — and most teams cannot tell you what those licenses actually are. In Part 4 of our GitLab DevSecOps series, Patrick Steger and I add license compliance to the pipeline so the question is answered automatically on every commit. The good news: with GitLab Ultimate, this is one template line away.
Your code is the small part. The libraries you pull in are the big part — and that is where most of your CVEs live. In Part 3 of the GitLab DevSecOps series, Patrick Steger and I bring up a tiny Spring Boot demo, wire it into a GitLab pipeline, and then add Software Composition Analysis with a single include line.
Before we can shift any security checks left, we need a project, a repository, and a pipeline that actually builds something. In Part 2 of our GitLab DevSecOps series, Patrick Steger and I log into GitLab, create a new .NET Core project from a template, and look at the .gitlab-ci.yml file that GitLab generates for us — including the build and test jobs that will become the foundation for everything we add later.
Why does security still get bolted on at the end of the development process, and how do we move it earlier without slowing teams down? In Part 1 of our GitLab DevSecOps series, Patrick Steger and I set the stage: what GitLab is, what shifting security left really means, and which CI/CD concepts you have to understand before you can build a DevSecOps pipeline that actually works.
How do you make sure your organization is not overloaded with too many projects, too many ideas, and too little focus? And how do you ensure you are building the right thing? This is exactly what epics are for. In this video, I walk through the concept of epics, show you a concrete example, and explain why epics are far more effective than traditional projects.
Have you ever wondered what “DevOps Engineers” actually do? What does “DevOps” even mean actually? This blog post aims to explain the concept of DevOps and the value that it
Over the past few years I have published a deep-dive on every single activity in the SAFe DevOps Health Radar. This post is the round-the-radar tour: a single page that walks you through all four aspects and all sixteen stages, with the original video for each and a link to the full article. Use it as a map — to find your starting point, to share with your team, or to assess where you are today and where you want to go next.
Release on Demand is the final step in the SAFe for DevOps continuous delivery pipeline, and it is the step that ties everything together. In this video, I walk through how Release on Demand works, why separating deployment from release is so powerful, and how the whole pipeline enables organizations to build the right thing right.
Feature toggles are one of those concepts that sound simple on the surface but unlock enormous power in practice. In this DevOps Meetup Zurich session, I team up with Ben Rometsch, founder of Flagsmith, to explain the what, why, and how of feature toggles. We cover the foundational concepts of CI/CD that make feature toggles necessary, the difference between deployment and release, and how modern feature flagging platforms enable progressive rollouts, user segmentation, and A/B testing.
