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.
What GitHub Is#
GitHub is a distributed development platform where you host source code and build your development pipelines. It was acquired by Microsoft in 2018 and is one of the largest developer platforms in the world, with roughly 83 million developers and 28 million repositories. We will compare GitLab and GitHub directly at the end of this series. For now, we focus only on GitHub.
What a DevSecOps Pipeline Has to Do#
Products evolve continuously. The DevSecOps cycle — plan, code, build, test, deploy, release, operate, monitor — is what your platform has to support end to end. Before talking about specific tools, you have to be precise about three terms that get mixed up constantly: continuous integration, continuous delivery, and continuous deployment.
Continuous Integration#
The developer commits code. The CI server picks it up, builds it, runs static code analysis, runs static security analysis, and executes the unit tests and some integration tests. The output is a deployable artifact. Security testing is part of CI from the start — not a separate gate at the end.
Feedback time matters more than people realize. If the loop takes hours, the developer has already moved on by the time the result arrives. The cost of context switching wipes out the value of catching the issue early. We are talking minutes, not hours.
Continuous Delivery#
The deployable artifact is automatically deployed to a staging environment that mirrors production. There you run additional automated tests and, if you want them, manual ones. The deployment is automated; the release is a separate decision.
Continuous Deployment#
Continuous deployment goes one step further. After staging, the artifact is automatically deployed to production. A second set of automated tests runs there. If they fail, you immediately roll back to the last stable version. There is no manual gate.
In many organizations, that last step is intentionally not automated — security or compliance procedures require a formal manual trigger. That is fine, but it means you are doing continuous delivery, not continuous deployment. Be honest about which one you run.
The Continuous Delivery Pipeline#
CI/CD on its own is not enough. A real pipeline includes continuous exploration (ideation and backlog management) at the front and release on demand (enabling features in production via toggles) at the back. The full thing is called the continuous delivery pipeline. In any mature pipeline you will see many tools wired together; the work is not picking the tools, it is integrating them so they actually run on every commit.
What GitHub Promises and What You Actually Get#
GitHub promises a single platform that covers everything. Reality is more nuanced: GitHub gives you very nice integration points, but you will replace some inadequate parts and pull in third-party tools for several steps. There is no GitHub-provided default for every security task — for SCA, SAST, container scanning, and others, you pick from the Marketplace.
Why We Do This#
Fixing a security issue early is dramatically cheaper than fixing it after release. If a penetration test finds a problem after the product is in production, you may have to take it offline, lose revenue, and rerun the entire chain — code, build, test, deploy. Compare that to catching the issue while the developer is still working on the same piece of code, when context is fresh and the fix takes minutes. The economics make the case on their own.
The Pipeline We Will Build with GitHub#
The next sessions will cover, in order: setting up the project with build and unit testing, software composition analysis, license compliance, static application security testing, container scanning, secret detection, merge requests as a security gate, dynamic application security testing, and scheduled pipelines. The final session will give recommendations and lessons learned from the whole journey.
Key Takeaways#
GitHub is a starting point, not a complete DevSecOps platform. You get strong integration points and a marketplace; you do not get a default tool for every security task. Plan for third-party pieces.
Use CI, CD, and continuous deployment with precision. Continuous integration ends with a tested artifact. Continuous delivery deploys to staging. Continuous deployment deploys to production. The trade-offs are different — call them by their right names.
Feedback in minutes is the design constraint. If the pipeline takes hours, the developer has already moved on and the early-detection benefit is lost. Optimize relentlessly for fast feedback.
A manual production gate is fine — just call it continuous delivery. Many companies cannot fully automate the production step due to compliance. That is a legitimate choice, not a failure of DevOps.
Catching security issues early is dramatically cheaper. A vulnerability found in production can mean taking the system offline. The same vulnerability found at commit time costs minutes of developer attention.
The work is integration, not tool selection. The Marketplace has plenty of tools. Wiring them into a pipeline that runs on every commit, with reliable feedback to the developer, is the real engineering effort.