After eleven sessions building a full DevSecOps pipeline with GitHub — covering Software Composition Analysis, License Compliance, SAST, Container Scanning, Secret Detection, DAST, Pull Requests, Scheduled Pipelines, and Vulnerability Management — Patrick Steger and I close the series with our recommendations. What works on GitHub, where the gaps are, and what we would tell anyone setting out to build the same pipeline.
Across ten sessions we wired security checks into a GitHub Actions pipeline that fires on every commit and every Pull Request. That covers code we are actively changing. It does not cover the code that is already running in production while researchers keep finding new CVEs in the libraries it uses. In Part 11 of the GitHub DevSecOps series, Patrick Steger and I add a scheduled workflow that re-scans the production branch — and we run straight into a GitHub limitation worth knowing about up front.
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 seven sessions of static analysis — SCA, license compliance, SAST, container scanning, secret detection — Patrick Steger and I move into the dynamic side of the pipeline. In Part 8 we add Dynamic Application Security Testing to our GitHub Actions pipeline. DAST runs the application and then attacks it. GitHub does not ship this out of the box, so we wire in a community action built on OWASP ZAP — and we are honest about where that approach falls short for enterprise use.
We have built up the GitHub Actions pipeline through five sessions: the project basics, software composition analysis, license compliance, and static application security testing. The next layer is container scanning — looking for vulnerabilities inside the Docker image we ship, not just in the source we wrote. In Part 6 of our series, Patrick Steger and I split the work into two GitHub Actions sub-workflows: one builds the image and pushes it to the registry, the other pulls it back and runs Trivy on it.
GitHub does not ship a license scanner out of the box, and when we went looking in the marketplace, none of the existing actions did what we needed. So we built our own with a colleague from Microsoft and published it. In Part 4 of our GitHub DevSecOps series, Patrick Steger and I plug that License Finder action into our Spring Boot pipeline, configure which licenses are acceptable, and show how to surface the results inside GitHub.
Before we plug security tools into anything, we need a repository, a pipeline, and a working build. In Part 2 of our GitHub DevSecOps series, Patrick Steger and I create a private GitHub repo for a small Java Spring Boot service, enable GitHub Actions, and wire up a two-workflow pipeline that compiles the code and runs the unit tests. This is the skeleton everything else in the series hangs on.
