Secure SDLC foundations

From SDLC phases to pipeline controls

A secure software development lifecycle puts a security activity in every phase. A CI/CD pipeline is where most of those activities become automatic: the pipeline runs them on every change, records the result, and refuses to continue when one fails. The table maps each phase to what goes wrong, the control that stops it, and where that control runs.

If you need to show compliance, NIST's Secure Software Development Framework (SP 800-218) groups the same practices into four families: PO prepare the organization, PS protect the software, PW produce well-secured software, and RV respond to vulnerabilities. Pipeline settings and pinning cover PS; scanners and review cover PW; scheduled rescans and alerting cover RV.

Threat model: the OWASP Top 10 CI/CD risks

The OWASP Top 10 CI/CD Security Risks list is the clearest threat model for a pipeline. Every control in the platform tutorials answers one of these ten.

The security gates

A gate is a check that stops the pipeline when it fails. The catalog below lists each gate, where it belongs, what should make it fail, and what each platform offers natively. Paid features are marked: GitHub and Azure DevOps sell Secret Protection and Code Security separately, and most GitLab security features need Ultimate.

Gate thresholds and exceptions

A gate that blocks on every medium finding gets disabled within a month. A gate that never blocks is a report. Start with a policy that blocks new, serious, fixable risk and tracks everything else. This is a common starting point; tune it to your risk appetite.

Rules for exceptions

• Gate on new findings. Existing findings go to a backlog with owners, so turning a gate on does not stop all delivery on day one.
• Every exception has an ID, reason, owner and expiry date. Use the scanner's own mechanism so the exception is versioned and reviewed: CodeQL dismissal reasons, GitLab vulnerability dismissal reasons, or a Trivy ignore file.
• Exceptions are reviewed by code owners. Put ignore files under the same code-owner rule as pipeline files.

# Each exception says why, who owns it, and when it stops applying.
vulnerabilities:
  - id: CVE-2026-12345              # example entry
    paths:
      - "usr/lib/libexample.so.3"
    statement: "Not reachable: TLS renegotiation disabled. Owner: @payments-team (SEC-412)"
    expired_at: 2026-12-31

Identity: replace stored secrets with OIDC

The biggest single improvement to most pipelines is removing long-lived cloud credentials. With OpenID Connect workload identity federation, the CI platform signs a short-lived token that describes the job, and the cloud exchanges it for an access token only if the job matches a trust rule you wrote.

1. CI jobRequests an ID tokenThe job asks the platform's OIDC issuer for a signed JWT with a specific audience.
2. CI platformSigns the claimsRepository or project, branch, environment and pipeline go into the token's claims.
3. CI jobPresents it to the cloudEntra ID, AWS STS, Google Cloud or Vault receives the token.
4. CloudChecks the trust ruleIssuer, audience and subject must match the federated credential exactly.
5. CloudReturns a short-lived tokenValid for minutes to an hour. Nothing is stored, so nothing can leak later.

Untrusted input and poisoned pipelines

Anything a contributor controls is untrusted input: the code in a pull request, the pipeline file in that pull request, scripts the pipeline calls, and even the PR title, branch name and commit message. Three attack patterns cover most real incidents.

The same mistake has a different spelling on each platform. On GitHub it is ${{ github.event.pull_request.title }} inside run:. On Azure DevOps it is a macro such as $(System.PullRequest.SourceBranch) inside script:, because macros are substituted into the script text before it runs. On GitLab the shell expands $CI_MERGE_REQUEST_TITLE at run time, which is safe when quoted and dangerous inside eval or a generated script. The platform pages show the fix for each.

Artifact integrity: SBOM, signatures and provenance

Scanning tells you an artifact looked safe when it was built. Integrity controls let the deploy step prove that the artifact it is about to run is that same artifact, built by your pipeline from your source.

SLSA build track levels

Rollout plan

Turning everything on at once floods teams with findings. This order delivers the largest risk reduction first and keeps pipelines green while gates mature.

1. See what you have. Inventory pipelines, stored secrets, service connections and self-hosted runners. Turn on secret scanning with push protection; it has almost no false positives and stops the most common incident.
2. Lock the platform. Set default token permissions to read-only, restrict allowed actions or tasks, protect default branches, and put pipeline files under code owners.
3. Remove stored cloud credentials. Move deploys to OIDC federation and delete the old keys.
4. Add scanners in report-only mode. Run SAST, SCA and IaC scans for two to four weeks, tune rules, and baseline existing findings.
5. Make gates block. Fail pull requests on new critical and fixable high findings, using the threshold table above.
6. Prove integrity. Add SBOM, signing and provenance, verify them at deploy, and schedule rescans.
7. Centralize. Move the security stages into shared templates or policies so every repository inherits them and teams cannot opt out.

References

• OWASP Top 10 CI/CD Security Risks
• NIST SP 800-218, Secure Software Development Framework
• SLSA v1.0 security levels
• Sigstore documentation
• OpenSSF Scorecard
• CycloneDX and SPDX

Next: pick a platform. GitHub Actions · Azure DevOps · GitLab CI/CD