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.
Structure Workflows Hierarchically#
The first thing we would recommend is to structure your workflows top-down. Build a main pipeline workflow that orchestrates smaller, single-purpose workflows — one for Build, one for SCA, one for SAST, and so on. Each sub-workflow does one thing well, and the main pipeline composes them. This is much easier to maintain over time than one giant YAML file. When something breaks or needs to change, you fix it in one small workflow and every pipeline that consumes it picks up the fix.
Define Branches and Schedules Explicitly#
You need to be explicit about which workflow runs on which branch. You can — and often should — have different pipelines for different branches. And you must schedule your pipelines. Here is why: your pipeline normally only runs when something changes, but the application sitting in production does not change every day. New vulnerabilities are disclosed daily. Without a scheduled pipeline you will never re-scan production code, and you will never catch the vulnerabilities that surfaced after the last commit. Setting the default branch in GitHub is straightforward — Settings, General, default branch — but the scheduled pipeline is what keeps production protected.
Pull Requests as the Security Gate#
Pull Requests work well for surfacing newly introduced security issues. Wire your security workflows into every PR, and define a review and approval process for what happens when a critical vulnerability shows up. Combine that with branch protection rules to actually enforce it. In Settings → Branches you can define a rule (we use * to apply it to all branches) that requires reviews, status checks, and whatever else you need before a merge can happen. Without branch protection, all your PR gating is theatre.
Security-Review Marketplace Actions#
This one matters in confidential and enterprise contexts. Anything you pull from the GitHub Marketplace is community-provided code running inside your pipeline with access to your secrets and source. Review what you are using. In the best case, fork it into your own repository and manage it from there so you control updates and can audit changes. Treat marketplace actions like any other third-party dependency — because that is what they are.
Secret Management: Use Azure Key Vault#
For secrets, the GitHub secret store is the baseline. It works. But if you want a better solution, use Azure Key Vault. The integration is excellent and you get advanced management capabilities — rotation, access policies, audit logs — that the built-in store does not provide. Other key vaults work too, but the Azure integration stands out.
You Will Have to Choose Your Security Tools#
Unlike GitLab, GitHub does not ship a default set of security scanners. That means you have to evaluate and pick what fits your stack. The upside is freedom; the downside is the work. Our previous episodes walked through specific candidates for SCA, SAST, Container Scanning, Secret Detection, and DAST — start there if you want a shortlist.
When you get to DAST specifically, customize the scanner configuration. An uncustomized DAST scan barely scratches the surface. Without authentication, crawl rules, and input definitions, the scanner cannot exercise the application meaningfully and the benefit is very limited.
The Vulnerability Management Gap#
Even a small Java project produces a lot of findings. Managing those findings is essential. GitHub’s Vulnerability Management is okay — you can work with it — but there is a real gap: you cannot create your own findings. If your pen-tester finds a vulnerability that the automated scanners did not, you cannot record it in GitHub’s Vulnerability Management. That limits the platform significantly. Our recommendation, unfortunately, is to plan for an external Vulnerability Management tool.
Bring a Security Expert into the Team#
Like with GitLab, our final recommendation is the same: add a security expert to the team. You will have a lot of findings, you have to configure each tool correctly, and you have to make sense of what comes out. That requires expertise. Without it, the pipeline either drowns the team in noise or quietly lets real issues through.
Key Takeaways#
Compose small workflows into big ones. A main pipeline that orchestrates focused sub-workflows (Build, SCA, SAST, etc.) is far easier to maintain than one monolithic YAML.
Schedule pipelines to protect production code. Code in production stops getting scanned the day commits stop. Scheduled runs keep it covered against newly disclosed vulnerabilities.
Pull Requests plus branch protection are your gate. PRs surface issues; branch protection rules enforce that the gate is actually closed.
Marketplace actions are third-party code. Review them, ideally fork into your own repo and manage updates yourself — especially in enterprise contexts.
Use Azure Key Vault for serious secret management. GitHub’s built-in secret store works; Azure Key Vault integrates cleanly and gives you the management capabilities you eventually need.
GitHub Vulnerability Management has a real gap. You cannot add your own findings. Plan for an external Vulnerability Management tool, and bring a security expert onto the team.