In the previous nine sessions Patrick Steger and I built a GitHub DevSecOps pipeline with build, SCA, License Compliance, SAST, Container Scanning, Secret Detection and DAST. All useful — but only if it actually runs before code lands in main, and only if the merge is blocked when something serious shows up. In Part 10 we wire that gate together with Pull Requests and Branch Protection rules.
After we finished the GitLab DevSecOps series, Patrick changed jobs — and his new team is on GitHub. The problem is the same: no security checks during development. The platform is different. In Part 1 of our GitHub DevSecOps series, we cover what GitHub is, the CI/CD vocabulary you have to share before any pipeline conversation works, and the shape of the DevSecOps pipeline we will build over the next sessions.
In the previous nine sessions Patrick Steger and I built a GitLab DevSecOps pipeline that runs SAST, secret detection, software composition analysis, container scanning and DAST. Useful — but only if it actually catches issues before they reach the default branch. In Part 10 we close that loop: we wire the pipeline into Merge Requests so every change is scanned, the deltas against the default branch are visible, and approvals are required when new high or critical vulnerabilities appear.
Everything we have done in the GitLab DevSecOps pipeline so far has been static — analysis of source code, dependencies, containers and configuration. In Part 8, Patrick Steger and I cross the line into Continuous Delivery and add Dynamic Application Security Testing. DAST means we deploy the application, start it, and then attack it from the outside with an automated penetration testing tool. GitLab ships this capability out of the box, powered by OWASP ZAP.
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.
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.
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.
