Why the pipeline is the control point

What DevSecOps changes

In a traditional release, security is a review at the end: a scan or a penetration test after the work is “done”. Findings arrive when the people who wrote the code have moved on, and fixing them means reopening finished work.

DevSecOps puts the checks inside the delivery process. The pipeline is the one path every change takes from a developer’s laptop to production, so it is the natural place to enforce rules that apply to every change. Nobody has to remember to run a scanner: the pipeline runs it, and the merge waits for the answer.

That is the idea behind the whole course: the pipeline is the control point.

The stages, and what belongs in each

Each check runs at the earliest stage where it works reliably. A secret can be caught before it is committed; a missing security header can only be seen once the app is running.

A gate blocks; a report informs

There are two ways to wire in a check:

• A gate fails the build. The change cannot merge or deploy until the finding is fixed or explicitly accepted.
• A report records findings without stopping anything.

A gate forces a decision on every finding. A report does not, and reports nobody has to act on stop being read. When a check matters, make it a gate. Reports are still useful for things you are measuring but not yet enforcing, such as a new rule set you are trialling.

Keeping a gate trusted

Gates fail in one predictable way. They fire too often on things that do not matter, people learn to click past them, and eventually someone switches them off. Three habits prevent that:

1. Gate on new findings, not the backlog. Record the existing findings as a baseline and block only what a change introduces. Fix the baseline on a schedule.
2. Start narrow. Block on high and critical severity, or on a short list of rules you are sure about. Widen it once the team trusts it.
3. Make exceptions explicit. An accepted risk is written down in the repository with a reason, an owner and an expiry date, and is reviewed like code. A finding is never silenced by deleting the check.

A useful measure of a gate’s health is its override rate: how often people bypass or suppress it. A rising rate means the gate is too noisy, not that the team is careless.

Pipeline output is evidence

Every pipeline run leaves records: which commit was built, which checks ran, what they found and who approved the deploy. Kept and retained, those records answer the questions an assessor asks.

• NIST SP 800-218, the Secure Software Development Framework (SSDF), groups practices into four families: prepare the organization (PO), protect the software (PS), produce well-secured software (PW) and respond to vulnerabilities (RV). Repository rules and signing support PS; review, SAST and testing support PW; dependency scanning and rescans support RV.
• NIST SP 800-53 Rev. 5, the catalogue behind FedRAMP: developer testing (SA-11), vulnerability scanning (RA-5), flaw remediation (SI-2), configuration settings (CM-6) and least privilege (AC-6) all leave pipeline evidence.
• NIST SP 800-171, the requirements behind CMMC Level 2, maps the same way through configuration management, access control and audit.
• DoD Enterprise DevSecOps guidance and DISA STIGs describe the same pipeline-as-control-point model and the hardening baselines artifacts are checked against.

A pipeline does not make a system compliant on its own; compliance also covers people, process and the environment. What a pipeline does is produce the same evidence every time, automatically, instead of someone assembling it by hand before an assessment.

# List workflow files in a repository
gh api repos/OWNER/REPO/contents/.github/workflows --jq '.[].name'

# Print one of them
gh api repos/OWNER/REPO/contents/.github/workflows/ci.yml \
  --jq '.content' | base64 -d