A developer pushes a one-line fix at 4:40 on a Friday afternoon. Eleven minutes later it is running in production, and no person looked at it after the code review. In a continuous deployment shop that is normal, and it means the only security checks the change passes through are the ones written into the pipeline.
On the CompTIA Security+ SY0-801 exam, pipelines and workflows sit under objective 4.6, which expects you to apply automation and orchestration to secure operations in a given scenario. This lesson covers the SecOps side of that objective: what CI/CD is, which security checks belong in a pipeline and where, how to protect the pipeline itself, and how APIs and webhooks wire security tools into workflows that carry an alert from detection to response.
CI/CD sends every code change through the same automated stages to production
Continuous integration (CI) means developers merge small changes into a shared branch often, and every merge triggers an automated build and test run. Problems surface within minutes of the change that caused them instead of weeks later.
CD has two meanings that differ by one step. Continuous delivery keeps every change that passes the pipeline ready to release, and a person decides when it goes to production. Continuous deployment removes that decision: every change that passes all stages goes to production automatically, and teams that work this way may ship dozens of times a day.
That speed changes how security has to work. A review held once before a quarterly release can't keep up with twenty deployments a day, so the checks move into the pipeline and run on every change. This is often called shifting left, because the checks move earlier in development, where flaws are cheaper to fix. A developer told about a SQL injection flaw ten minutes after writing it fixes it in ten more; the same flaw found in production needs an emergency change and possibly an incident response.
The pipeline also becomes part of the attack surface. It holds credentials for source control, artifact registries and production, and whatever it builds is trusted by everything downstream.
On the exam, a scenario about catching flaws "before code reaches production" or "on every commit" points to security checks in the CI/CD pipeline. When a question contrasts delivery with deployment, the difference is whether a person approves the release.
Each security gate in the pipeline catches a different kind of mistake
A gate is a pipeline stage that can stop a build. Each of these checks catches something the others miss:
| Check | What it examines | Typical finding |
|---|---|---|
| SAST (static application security testing) | Your own source code, without running it | User input concatenated into a SQL query |
| Dependency scanning (software composition analysis) | Third-party libraries and their versions | A library version with a critical CVE |
| Secrets scanning | Files and commit history | A cloud access key in a config file |
| IaC scanning | Infrastructure templates | SSH open to 0.0.0.0/0 in a security group |
| Container image scanning | Packages inside images | An outdated OpenSSL in the base image |
| DAST (dynamic testing) | The running app in a test environment | An API route that answers without authentication |
The order follows cost and what each check needs. Secrets scanning and SAST take seconds to minutes and run on every commit and pull request. Image scanning runs after the build. DAST needs a deployed application, so it runs against staging. Dependency scanning often produces a software bill of materials (SBOM), a list of every component in the build, which lets a team answer "are we affected?" within minutes when the next library vulnerability is announced.
Secrets scanning has to read history, not just the latest files. A key committed and then deleted in the next commit is still in the repository and still valid, so the fix is to revoke and rotate it, not only to remove the line.
Signed artifacts close the loop. After the gates pass, the pipeline signs what it built, such as a container image or installer, and the deployment system verifies the signature before running anything. An image built by hand or altered in the registry has no valid signature and is refused. Frameworks such as SLSA (Supply-chain Levels for Software Artifacts) extend this with signed provenance recording which source and which pipeline produced each artifact. Code signing, static analysis and secrets scanning each get fuller treatment in the application security section.
Gates need tuning to stay useful. Teams usually fail the build on new critical and high findings that have a fix available, report the rest, and track every exception with an owner and an expiry date. A gate that blocks on hundreds of false positives teaches developers to work around it.