Guides

DevSecOps Security Pipeline (SAST, SCA, Secrets)

By Ravindra Bagale, Cyber Security trainer · LinkedIn · Published: 29 September 2026 · Last updated: 30 September 2026

DevSecOps means building security checks into the same pipeline that builds and deploys software: SAST on your code, SCA on dependencies, secret scanning, image/IaC checks where relevant, and controlled deploys with audit trails — so “we will harden later” stops being the default.

Commit → SAST → SCA → Secrets → Image/IaC → Deploy (audited)
Broken pipe = “ship hope”
Keys in CI variables = incident queue

What do I need before this guide?

• Supply chain companion: SBOM, dependency risk and secret leaks.
• Vuln prioritisation: Vulnerability management CVE/KEV.
• Optional API tests in CI mindset: Secure REST APIs / OWASP API.

What belongs in a beginner-safe pipeline?

Practical gates (tool names vary; concepts transfer):

1. Secret scanning — stop AKIA… / tokens at push or PR time.
2. SCA — known CVEs in libraries; pin lockfiles.
3. SAST — risky code patterns (injection sinks, unsafe deserialization themes) without turning CI into a red-team course.
4. Unit/integration security tests — authz cases for APIs you own.
5. Image scan — OS and library CVEs in containers you build.
6. IaC scan — open security groups, public buckets (high-level misconfig).
7. Deploy controls — environment protection rules, dual approval for prod.

Educational warning: run scanners against your repos and images. Pointing aggressive scanners or exploit frameworks at third-party sites is out of scope and often illegal.

Real incident: Codecov (2021) — pipeline trust themes

Public reporting on the Codecov 2021 bash uploader compromise described attackers altering a widely used CI helper so that CI secrets could be exfiltrated from customer pipelines. Blue-team lesson: the pipeline is part of your production attack surface. Third-party build steps need pinning, verification, least privilege, and monitoring for odd egress.

Takeaways (vertical):

1. What happened — trusted CI component abuse with secret-exposure themes in public analyses.
2. What went wrong (theme) — over-trust in mutable third-party scripts plus powerful CI credentials.
3. Care-take — pin actions/orb/versions; verify checksums when vendors publish them.
4. Care-take — CI roles get minimum cloud permissions; prefer OIDC federation.
5. Care-take — alert on unexpected outbound traffic from build agents.
6. Bonus parallel — SolarWinds 2020 reminds us build systems are crown jewels for nation-state and commodity actors alike.

Red Team vs Blue Team (awareness only)

Red Team — what attackers try

• Steal CI tokens from logs, pull requests, or compromised developer laptops.
• Modify build scripts to ship trojans (supply-chain theme).
• Abuse over-broad deploy keys to production.
• Tamper with mutable tags like latest or floating action versions.

Blue Team — defend, detect, respond

• Branch protection + required reviews + status checks that actually block merge.
• Pin tools; generate SBOMs; sign artefacts when your org is ready.
• Rotate credentials on a schedule and on every suspected leak — revoke first.
• Separate build and deploy roles; prod deploy needs human approval.
• Monitor for unexpected workflow file changes.

How do I build the pipeline step by step?

Step 1 — Harden the source

1. MFA on GitHub/GitLab/Bitbucket org owners.
2. Protect main: no direct push; require PR + green checks.
3. Restrict who can edit workflow files if your platform supports it.

Step 2 — Add secret and dependency gates

1. Enable platform secret scanning + a local pre-commit hook for developers.
2. Commit lockfiles; run SCA on PRs; fail fixable criticals on release branches.
3. Generate an SBOM artefact per release and store it beside the build.

Step 3 — Add SAST and authz tests

1. Start with a maintained SAST engine in CI; triage suppressions with expiry dates.
2. Add automated tests that user A cannot read user B’s objects (API apps).
3. Keep false-positive debt visible — ignored findings rot culture.

Step 4 — Secure the build agents

1. Ephemeral runners when possible; patch persistent ones.
2. No long-lived cloud access keys in variables if OIDC works.
3. Egress allow-lists for package registries you actually need.

Step 5 — Image / IaC before prod

1. Scan images you build; block known criticals with available fixes.
2. Scan Terraform/CloudFormation/Kubernetes YAML for obvious public exposure.
3. Promote by digest, not by mutable tag alone.

Step 6 — Deploy with audit and practice

1. Environment protection: required reviewers for prod.
2. Ticket link in the release notes.
3. Tabletop: “CI secret leaked — revoke cloud keys, rotate registry creds, review deploys in the last 24h (IST labelled).”
4. Only experiment on pipelines that deploy to accounts you own.

Minimal PR checklist (copy into your team wiki)

1. Secrets scan clean?
2. SCA criticals addressed or risk-accepted with expiry?
3. SAST new highs triaged?
4. Image/IaC scan attached?
5. Prod approval named human?

What “shift left” actually means here

1. Catch secret leaks and dependency CVEs before merge — cheaper than prod IR.
2. It does not mean dumping every scanner on day one until developers mute Slack.
3. Start with secret scan + lockfile SCA + branch protection; add SAST once triage owners exist.
4. Security partners write suppressions with expiry dates, not eternal # nosec folklore.
5. Prod still needs runtime controls (WAF-ish edge, EDR, IAM) — pipeline is necessary, not sufficient.

Care-take — culture that keeps gates honest

1. Security findings get owners in the same sprint board as features.
2. Break-glass deploy still logs who/when/why.
3. Third-party GitHub Actions: prefer verified creators; pin full commit SHAs when risk is high.
4. Never embed production secrets in fork PRs from outsiders.
5. Measure mean time to remediate pipeline-blocker vulns.
6. After Codecov-style news: inventory every CI secret your org stores.

How do I fix common DevSecOps mistakes?

Ghabru naka 😅 — these are the usual ones: