Further Reading: DevSecOps and the Secure Pipeline

Curated, annotated resources to deepen this chapter. Each entry notes which learning path it serves most (🛡️ SOC, 🏗️ Engineer, 📋 GRC, 📜 Cert) and its citation tier. Start with the suggested order; you do not need to read everything before Chapter 32.

Suggested order

  1. Read the NIST Secure Software Development Framework (SSDF, SP 800-218) overview to see the authoritative shape of "build security into the SDLC" — this is the standard your secure-pipeline standard maps to.
  2. Read the SLSA specification's introduction and levels to ground pipeline integrity and provenance.
  3. Browse the OWASP DevSecOps Guideline for the practical "where does each scan go" view.
  4. Skim CISA's guidance on securing the software supply chain to connect SolarWinds to policy.
  5. Keep the OWASP Top 10 (Vulnerable & Outdated Components, A06) nearby as the reason SCA and container scanning exist.

Standards & primary documents (Tier 1)

  • NIST SP 800-218, Secure Software Development Framework (SSDF). 🏗️📋📜 The canonical U.S. standard for integrating security into the SDLC, organized into practices (Prepare the Organization, Protect Software, Produce Well-Secured Software, Respond to Vulnerabilities). This is the framework your Meridian secure-pipeline standard is mapped to; read it as the authoritative version of this whole chapter.
  • SLSA — Supply-chain Levels for Software Artifacts (slsa.dev). 🏗️📜 The framework that defines escalating levels of build integrity and provenance. The control set behind §31.4 and the provenance.builder check; the direct answer to "how do you prove how an artifact was built?"
  • OWASP, DevSecOps Guideline and DevSecOps Maturity Model (DSOMM). 🏗️ The open-source practical map of where each security activity belongs in the pipeline and how to mature a program over time. The hands-on companion to NIST's higher-level SSDF.
  • OWASP Top 10 — A06: Vulnerable and Outdated Components. 🏗️📜 The category that SCA and container image scanning exist to address; read it to see the dependency-risk problem from the appsec side (extends Chapter 12).
  • CISA, Securing the Software Supply Chain guidance and SBOM resources. 📋🏗️ Government guidance, much of it post-SolarWinds, on supply-chain integrity, SBOMs, and provenance — the policy framing that connects this chapter to Chapter 29.
  • NIST SP 800-53 / SP 800-161, supply-chain and system-integrity control families. 📋 The control catalogs that include software integrity, provenance, and supply-chain risk controls an auditor will map your pipeline to.

Books and long-form (Tier 1 / Tier 2)

  • Kim, G., Humble, J., Debois, P., & Willis, J., The DevOps Handbook. 🏗️ The foundational text on the DevOps practices that DevSecOps extends — value-stream thinking, fast feedback, and "you build it, you run it." Read the sections on automated testing and deployment pipelines as the substrate security plugs into. (Tier 1 for DevOps practice; security is an extension you add.)
  • Bird, J., DevSecOps (and related O'Reilly reports). 🏗️📋 Practical treatments of folding security into CI/CD — gating strategy, tool placement, and the cultural change. Useful for the "how to roll it out without developers revolting" problem that Case Study 1 dwells on. (Tier 2: practitioner guidance, useful but opinionated.)
  • Anderson, R., Security Engineering (3rd ed.), chapters on software security and assurance. 🏗️ The rigorous, skeptical view of why software assurance is hard and what actually changes outcomes; pairs well with the limits of scanning discussed in §31.3.

Free online & talks (Tier 1 / Tier 2)

  • The post-incident analyses of SolarWinds / Sunburst (vendor and government write-ups). 🛡️🏗️ Read at least one detailed technical retrospective with the §31.4 lens from Case Study 2: where was the compromise (build, not source), and which control would have prevented or detected it. (Tier 1 for the public facts; the control-counterfactual framing is this chapter's.)
  • Open Policy Agent (OPA) / Rego documentation (openpolicyagent.org). 🏗️ The most common policy-as-code engine and language; the §31.5 deploy gate and the lab exercise use its style. Work through the tutorial to write your own deny-by-default policy.
  • Sigstore / cosign documentation (sigstore.dev). 🏗️ A widely adopted, free toolchain for signing and verifying artifacts (especially container images) and generating provenance — the practical implementation of §31.4's signing and provenance controls.
  • The 2021 U.S. Executive Order on Improving the Nation's Cybersecurity (EO 14028) software-supply-chain sections. 📋📜 The policy response to SolarWinds that pushed SBOMs and secure-development practices into federal procurement; useful GRC context for why these controls are becoming requirements, not options.

Tools to explore (in your own lab only)

  • A SAST/SCA/secrets/IaC scanner in a sandbox pipeline. 🏗️ Wire one open-source scanner of each type into a CI for a project you own, set a severity gate, and watch it pass/fail on a deliberately introduced flaw. The §31.3 machinery becomes concrete in an afternoon.
  • opa eval with a deny-by-default deploy policy. 🏗️ Reproduce the §31.5 policy: write a rule that denies a JSON "deployment" unless signed is true and critical_vulns is empty, then add deny_reasons and watch the policy explain itself.
  • A container image scanner on an old base image. 🏗️ Scan an image built on a six-month-old base layer and count the known vulnerabilities you inherited for free — the §31.3 argument for rebuilding regularly, demonstrated.

⚖️ Authorization & Ethics reminder: Scanners, policy engines, and signing tools are defensive, but pipeline access and credentials are powerful. Apply all of this only to pipelines, repositories, and infrastructure you own or are explicitly authorized to work on. A build pipeline is crown-jewel infrastructure (Case Study 2) — treat access to one accordingly (Chapter 39 revisits the ethics).