Secure SDLC & DevSecOps
Most teams treat security as a final inspection: build the software, then hand it to a security team for a review right before launch. This almost always fails. By the time the reviewer finds a flaw, the deadline is here, so the flaw ships anyway, or the review gets skipped to "save time". The modern answer is to build security in, not bolt it on — make security a property of how you build software, not a gate at the end.
Let me define the two key terms up front. The SDLC (Software Development Life Cycle) is the sequence of stages software passes through: plan → design → code → build → test → deploy → operate. DevSecOps is the practice of weaving security activities into every one of those stages, automated and continuous, so security is everyone's job rather than one team's last-minute checkpoint. The "Sec" sits literally inside "DevOps" on purpose: a separate final security gate becomes a bottleneck, and bottlenecks get bypassed under deadline pressure.
9.1 Why this matters — the 2025 numbers
The economics are stark. The IBM Cost of a Data Breach 2025 report put the global average breach at $4.44M (down 9% from 2024 — the first drop in years, credited to faster AI-driven detection), but the US average hit a record $10.22M. The average breach took 241 days to identify and contain. A widely-cited IBM/NIST figure says a flaw fixed at design time costs roughly 100x less than the same flaw fixed in production.
A new 2025 risk is "Shadow AI" — employees using unsanctioned AI tools (a term meaning AI used without company approval or controls). It was a factor in 20% of breaches and added ~$670K in cost; 97% of AI-related breaches happened in organisations with no AI access controls.
9.2 Shift left — and shift everywhere
"Shift left" means moving security activities earlier (toward the left) on the SDLC timeline — catch problems in design and code, not in production. But design-time review can't catch a deployment misconfiguration or a runtime bug, so modern teams also "shift right": monitor the running app in production. The combination is sometimes called "shift everywhere".
PLAN DESIGN CODE BUILD/CI TEST DEPLOY OPERATE
| | | | | | |
risk threat secure-IDE SAST/SCA DAST signing runtime
reqs model SAST/SCA secrets IAST attest. monitor
(STRIDE) pre-commit IaC scan admission WAF/SBOM
watch
<-------------- SHIFT LEFT --------------||--- SHIFT RIGHT --->
9.3 Threat modeling in design
Threat modeling is a structured discussion, done during architecture and before code, asking "what could go wrong?". The most common framework is Microsoft's STRIDE, where each letter is a category of threat that maps to a defensive property:
| STRIDE threat | Plain meaning | Property you want |
|---|---|---|
| Spoofing | Pretending to be someone else | Authentication |
| Tampering | Altering data or code | Integrity |
| Repudiation | Denying you did an action | Non-repudiation (logging) |
| Information disclosure | Leaking private data | Confidentiality |
| Denial of service | Making the system unavailable | Availability |
| Elevation of privilege | Gaining rights you shouldn't have | Authorization |
A lightweight version is Adam Shostack's four questions: What are we building? What can go wrong? What are we going to do about it? Did we do a good job? Make it collaborative — developers know the code, product managers know the business context, security knows the threats. The output is a list of threats where each one has a mitigation, an owner, and a tracking ticket, not a brainstorm that evaporates. Re-run it when the architecture changes. Tools: OWASP Threat Dragon, Microsoft Threat Modeling Tool, IriusRisk.
9.4 The four scanner types — know them cold
These four automated scanners each see a different angle. None alone is enough; use them layered.
| Type | What it scans | When | False positives |
|---|---|---|---|
| SAST (Static App Security Testing) | Your source code at rest (SQLi, XSS patterns) | On PR / build | High (15–60%) |
| SCA (Software Composition Analysis) | Third-party dependencies vs CVE databases | On PR / build / continuous | Low (2–10%) |
| DAST (Dynamic App Security Testing) | The running app, attacked from outside | In staging | Low–medium |
| IAST (Interactive App Security Testing) | Running app, instrumented from inside | During tests | Very low (heavy setup) |
A CVE (Common Vulnerabilities and Exposures) is a public catalogue entry for a known flaw. SCA has low false positives because it does exact version matching, not pattern guessing — it's your supply-chain frontline (Dependabot, Snyk, Trivy, OWASP Dependency-Check). SAST has high false positives because it infers bugs from code patterns. The classic free DAST tool is OWASP ZAP.
9.5 CI/CD gate strategy — block the few, warn the many
CI/CD means Continuous Integration / Continuous Delivery — the automated pipeline that tests and ships every code change. The critical nuance: don't fail the build on everything. If a low-severity finding blocks a release, developers learn to disable or bypass the scanner. Best practice: BLOCK only on Critical/High severity (and confirmed, reachable findings); WARN, track, but don't block on Medium/Low. Aggressively tune out false positives, or you get alert fatigue and developers stop trusting the tool.
9.6 Secrets scanning
A secret is a credential like an API key, password, or token. gitleaks is the de-facto open-source scanner — a single Go binary with 700+ regex patterns (AWS AKIA..., Stripe sk_live_..., GitHub ghp_...). GitGuardian's 2026 report found 28.65M secrets leaked on public GitHub in 2025. Defend in depth across three layers:
- Pre-commit hook (
gitleaks protect) — blocks the secret locally before it's ever committed. Best user experience. - CI job on push/PR — a backstop in case someone skips the hook.
- Platform protection (GitHub Push Protection) — blocks supported secret types before they leave the machine.
9.7 Software supply chain security — the hottest 2025 topic
Your software is mostly other people's software. Supply-chain attacks more than doubled in 2025; Sonatype found 454,600+ new malicious packages that year. The OWASP Top 10 2025 (OWASP = a respected nonprofit publishing security guidance) added a brand-new category A03: Software Supply Chain Failures — the highest incidence rate (5.19%) but very low CVE coverage, meaning attacks outrun scanner signatures. Three incidents teach three distinct lessons:
- Log4Shell (CVE-2021-44228, Dec 2021)
- A trivially-exploitable remote-code-execution flaw (CVSS 10.0) in the ubiquitous Log4j logging library, dormant since 2013. Organisations with no inventory spent weeks just finding where Log4j was. Lesson: you can't fix what you can't find — you need an SBOM.
- SolarWinds / SUNBURST (2020)
- Attackers compromised the build server. The SUNSPOT malware watched for the compiler and swapped source files at compile time, so malicious code got legitimately signed and shipped to ~18,000 customers via a trusted update. Lesson: signing a build doesn't help if the build itself is compromised — defend the pipeline and signing keys as hard as production.
- xz-utils (CVE-2024-3094, Mar 2024)
- A backdoor (CVSS 10.0) giving SSH remote access, slipped into a critical compression library by a patient attacker who spent ~2–3 years social-engineering their way to co-maintainer of an under-resourced project. Caught by luck — a Microsoft engineer noticed 500ms of extra SSH latency — before it reached stable distributions. Lesson: single-maintainer open-source projects are a national-security-grade attack surface; trust itself is exploitable.
--ignore-scripts, and lockfiles.9.8 The modern supply-chain toolkit
- SBOM (Software Bill of Materials)
- A machine-readable inventory of every component in your software (formats: SPDX, CycloneDX). Answers "what's in my software?" — generate one automatically per build. It does not prove the software was built from the code you think.
- SLSA ("salsa", Supply-chain Levels for Software Artifacts)
- A graduated framework for build provenance (a verifiable record of how an artifact was built). L1 = provenance exists; L2 = signed provenance from a hosted build service; L3 = hardened, tamper-resistant build. SLSA 1.2 shipped in late 2025. Pragmatic target: Level 2 — achievable in 1–2 days on GitHub Actions or GitLab CI, and it stops most common attacks.
- Sigstore
- Free keyless artifact signing using short-lived certificates tied to your identity — no long-lived signing key to steal, directly addressing the SolarWinds key-theft problem. Components: cosign (signing), Fulcio (CA), Rekor (transparency log).
- Pinning
- Lock exact dependency versions via lockfiles (
package-lock.json,go.sum), and pin GitHub Actions to a commit SHA, not a tag — tags are mutable and a frequent attack vector.
Regulatory drivers: US Executive Order 14028 (2021) started federal SBOM requirements. The EU Cyber Resilience Act entered force Dec 2024 — by 11 Sept 2026 you must report actively-exploited vulnerabilities within 24 hours, and by Dec 2027 full secure-by-design, SBOM, and vuln-handling obligations apply to products sold in the EU. Practical takeaway: have SBOMs and a vuln-management process before Sept 2026. Verification checklists: OWASP ASVS 5.0 (May 2025); maturity models: SAMM v2 and DSOMM.
9.9 Culture — guardrails, not gatekeepers
This is the part teams get wrong. Three ideas matter most:
- Security Champions — embed a developer on each team as the security point of contact. This scales a tiny central security team across many dev teams. Critical rule: champions are advisors, not approvers. Make them an approval step and you recreate the bottleneck.
- Paved roads / golden paths (Netflix/Google/Spotify language) — provide a secure-by-default supported way to build and ship: templates, a golden pipeline, pre-hardened base images. The secure path must be the easiest path. Netflix reports >90% of engineers stay on the paved road because it's easier, not because it's mandated.
- Guardrails vs gates — a gate is a manual approval that blocks (a bottleneck that breeds shadow workarounds); a guardrail is automated and embedded, redirecting toward safe paths without blocking velocity. Reserve hard gates for the few truly critical checks. Encode policy as code with Open Policy Agent or Terraform Sentinel so it's reviewable and auditable.
9.10 Metrics — make security measurable
MTTR (Mean Time To Remediate) is the average time from discovering a vulnerability to having the fix deployed. Always segment by severity — the all-severity average hides the signal. Common 2025 SLA targets: Critical <7 days, High <30, Medium <90, Low <180. Track also MTTD (time to detect), % of builds passing gates, % of repos covered by scanning, and escape rate (vulns reaching prod).
Common mistakes
- Treating DevSecOps as a tool purchase rather than a way of working.
- Failing the build on low-severity findings, so developers disable the scanner.
- "Removing" a secret from a commit but never rotating the key.
- No dependency inventory / SBOM (the Log4Shell scramble).
- Trusting a signature without trusting the build (SolarWinds).
- Turning security champions into approvers (recreates the bottleneck).
- Ignoring transitive (indirect) dependencies and pinning to mutable tags.
- Running untrusted post-install scripts; security review only at the end.
Best practices — a "day one" checklist for a dev team
- Enable Dependabot/SCA plus GitHub secret scanning and push protection.
- Add gitleaks as a pre-commit hook and a CI job.
- Run SAST on PRs, blocking on Critical/High only.
- Generate a CycloneDX SBOM automatically in CI.
- Pin GitHub Actions to commit SHAs and commit lockfiles.
- Threat-model every new feature with the four questions.
- Set MTTR SLAs by severity and verify fixes before closing.
- Appoint a security champion (advisor) and build a paved-road pipeline template.
- Target SLSA Level 2 and adopt Sigstore for artifact signing.