This post is part of a series on DevSecOps and CI/CD security. Check out the overview for context and links to the rest of the series.
This post focuses on DevSecOps strategy, covering:
Strategic Landscape
DevSecOps is about releasing secure-enough software at the pace of the business. There’s no “golden DevSecOps path”, owing to several factors:
- Strategic: organizations vary widely on risk tolerance, business pressures, and process maturity
- Technical: tech stacks vary within and across organizations, and each component in a tech stack has security implications
- Human: differences in engineering team size and structure; differences in security awareness and training across engineers
While there’s no “golden path”, a healthy DevSecOps culture emphasizes:
- Tight collaboration and continuous feedback between security and engineering teams
- Heavy automation using infrastructure-as-code and security-as-code tools
- Robust testing of applications and infrastructure, including layered security tests
Why Shift Left
The security community has been talking about shifting left for years. Why? Traditional, manual security processes are simply too slow for a CI/CD world of rapid software releases.
In a traditional waterfall SDLC (software development lifecycle), penetration testing or code review often serves as a pre-release gate. Penetration testing and code review remain important ways to find vulnerabilities.
However, this takes security engineers a few weeks for complex software; add developer time to understand and mitigate the discovered vulnerabilities, and you’re looking at weeks or months. For software shops practicing CI/CD, fresh code can be deployed to production multiple times a day.
To resolve this tension, security shifts left in the SDLC and becomes an increasingly-automated part of software delivery. This cuts costs: it’s cheaper to fix security defects earlier in the SDLC rather than in nearly-completed software (or worse, after a breach).
Baking security into the SDLC yields more resilient, higher-quality software compared with trying to bolt it on at the end. It’s also less stressful for everyone involved – no more late nights or weekends fixing vulnerabilities to meet a release schedule!
People-Process-Culture
Apply these principles to foster a healthy DevSecOps program and culture.
De-silo security and DevOps: security staff should partner with DevOps teams throughout the SDLC.
- Work together on requirements, architecture, implementation, testing, and deployment.
- Translate high-level security and compliance requirements into tech-stack-specific tools, templates, guidance, and other forms of support that make it easier to build secure software.
- Share standups between developers and security people.
Hire well-rounded engineers: hire security engineers with backgrounds in software development or systems/network/cloud engineering. It’s easier to train a well-rounded engineer in security than to train a security specialist in software development. Security engineers with a full-stack skillset connect easily with non-security engineers, and build with an eye toward developer ease-of-use.
Get management buy-in: cybersecurity is a boardroom topic. Management sets the cultural tone on security and provides hiring and purchasing authority. Management support is key for any successful security program, including DevSecOps.
Recruit security champions: for organizations with independent or loosely-coupled engineering teams, scale security by building relationships with at least one non-security senior technical person on each team. Recruit them as security champions. This person:
- Provides security guidance to their team.
- Passes feedback on security tools and CI/CD integrations between security people and their fellow engineers.
- Drives security automation within their team.
Embrace iteration: DevSecOps is a continuous journey, not a target state.
- Integrate security tools with the development environment and CI/CD pipeline.
- Continually gather and enact developer feedback on these integrations.
- Improve incrementally on false positive filtering, tool selection/tuning, testing coverage, metric collection, and issue tracker integrations.
Thanks for reading! If you enjoyed this, check out the next post on DevSecOps technical strategy.