9.5. Development Ecosystem Security
💡 First Principle: The development ecosystem — code repositories, CI/CD pipelines, build servers, artifact registries, and development workstations — is infrastructure that builds infrastructure. Compromising the build pipeline is more valuable to an attacker than compromising any single production system, because a single poisoned build can distribute malicious code to every customer through a trusted update channel. The SolarWinds attack demonstrated this: compromising the build system gave attackers access to 18,000 organizations through a single vector.
Securing the development ecosystem is fundamentally different from securing production — developers need flexibility and speed, while security requires control and verification. The tension between velocity and security is the central design challenge, and the solution is automation: security checks that run as fast as the pipeline and block insecure code without requiring manual intervention.
Why this matters: CI/CD pipeline security, secret management in code repositories, and the distinction between pre-commit and post-commit security checks are increasingly tested. The exam expects you to understand where in the pipeline different security controls should be placed.
⚠️ Common Misconception: "DevSecOps means security reviews happen at the end of each sprint." DevSecOps integrates security throughout the development lifecycle — not as a gate at the end. Security requirements are defined alongside functional requirements. Threat modeling occurs during design. SAST runs on every commit. SCA runs on every build. DAST runs in staging. Security is not a phase — it is a continuous activity embedded in every stage.
