Chapter 6: Integrating Infosec into the Delivery Lifecycle
The Problem with Traditional Security
DevOps is arguably poorly named — it ignores testing, product management, and information security. The original goal was to eliminate “throwing work over the wall,” but this behavior occurs wherever different functions in the software delivery value stream don’t work together effectively.
Current state of infosec teams:
- Typical ratio: 1 infosec person per 10 infrastructure people per 100 developers
- Usually only involved at the end of the software delivery lifecycle
- When security issues are found late, changes are painful and expensive
- Many developers are ignorant of common security risks (OWASP Top 10)
Result: Security becomes a bottleneck. Taking systems from “dev complete” to live is delayed by security/compliance reviews that take months.
Shifting Left on Security
“Shifting left” = integrating security into the software delivery process instead of making it a separate downstream phase.
What Shifting Left Entails
- Security reviews for all major features — conducted in a way that does NOT slow development
- Infosec integrated throughout the lifecycle:
- Infosec experts contribute to application design
- Attend and provide feedback at demos
- Ensure security features are tested in automated test suites
- Easy-to-consume security resources for developers:
- Preapproved libraries, packages, toolchains, processes available on demand
- Makes it easy to do the right thing without security expertise
The Shift in Security Team’s Role
From: Security teams do security reviews themselves
To: Security teams give developers the means to build security in
Why this works:
- Far easier to ensure people building software do the right thing than to inspect nearly-complete systems with architectural problems
- When deployments are frequent, security teams simply don’t have capacity to review each deployment
Research Findings
Building security into software delivery:
- Improves delivery performance (positively impacts CD)
- Improves security quality — high performers spend 50% less time remediating security issues than low performers
The counterintuitive finding: integrating security into daily work doesn’t slow delivery — it accelerates it.
Case Study: Federal Government (18F and cloud.gov)
Federal information systems must comply with FISMA → NIST Risk Management Framework → 325 controls for a moderate-impact system.
Traditional approach: Security process begins only after “dev complete” → takes months to over a year.
18F’s solution: cloud.gov (PaaS based on Cloud Foundry on AWS) — handles 269 of 325 required controls at the platform level. Systems hosted on cloud.gov can go from dev complete to live in weeks, not months.
This demonstrates that compliance constraints can be embedded in platform-level infrastructure, not left to each team to implement individually.
The Rugged DevOps Movement
Names for security-integrated DevOps:
- DevSecOps (coined by Topo Pal, Capital One; Shannon Lietz, Intuit)
- Rugged DevOps (Josh Corman and James Wickett)
The Rugged Manifesto key ideas:
- “I am rugged and, more importantly, my code is rugged”
- “I recognize that my code will be used in ways I cannot anticipate, in ways it was not designed, and for longer than it was ever intended”
- “I recognize that my code will be attacked by talented and persistent adversaries”
- Being rugged is everyone’s responsibility, not just the security team’s
Key Principle
Security is not a gate that work must pass through. It’s a shared responsibility embedded in the daily work of every engineer and enabled by security teams who provide tools, training, and support rather than gatekeeping.