By Nima Dezhkam and Rohit Sethi
Steve, the application security expert, walks into a room of his company’s senior developers. He projects a carefully prepared PowerPoint presentation onto a screen. Steve begins his presentation, “Security in the Software Development Life Cycle”, by articulating the business case for integrating security earlier into the development process. Nobody in the room disagrees with this basic premise. Next, Steve outlines a process diagram which shows six distinct gating steps to embed security into the SDLC. He goes on to detail each step, noticing minor looks of concern starting to appear on the developers’ faces. The first step is threat modeling, he explains, which aims to catch security issues early. Over the next year the corporate security team will mandate threat modeling at the design stage for all applications deemed to be high-risk.
The mood changes. Developers begin barraging him with questions and concerns:
- “ like the idea behind this but I’m a bit concerned about adding another security activity to the pipeline. As it is, we’re already struggling to keep up with other priorities. How do we get business buy-in for this”
- “I totally agree where this is going. I think we owe it to our users to have considered security from the start. When it comes to implementation, I’m not sure how this will play out”
- “Our team manages mature applications. We don’t have much new exposure. Maybe this shouldn’t apply to us.”
- “Steve, our team runs very agile, we don’t have a design phase. I think you mean this for people with more waterfall-style development practices.”
Steve breaks a sweat. He anticipated some pushback, but surely developers understand that getting security in earlier is a good thing. Why is there so much resistance? Steve didn’t really involve the developers ahead of time while building his plan; he assumed they’d be happy to hear about a positive change.
The Problem
You know that adopting security early is the most effective and cheapest method to building secure software. The security world is loaded with prescriptive & descriptive methodologies for integrating security into the Software Development Life Cycle, such as Open SAMM.
Then there is the challenge of actually doing it. Getting management buy-in, it turns out, is not always the most significant challenge.
Getting the right technology is not the most significant challenge.
Finding the right technology is not the most significant challenge.
The most significant challenge is often the trying to push out a standardized process across the company without buy-in from developers.
“Culture is Process”
Jeff Patton postulates that “Process is culture” when trying to determine how to integrate User Experience in agile development. If we extend this to security, it’s clear why so many Secure SDLC efforts face resistance at the grassroots level: external agents (application security groups and/or consultants) are trying to push enterprise-wide processes which are culturally congruent with some teams but not others. How can you force a team that doesn’t have a “design” phase to build a “design security review” gating process? If a team tends to put immense value in up-front planning then a testing-heavy approach may backfire. If a team has been spending years building and honing a rigorous risk analysis process, then telling them to adopt yet another process that effectively does the same thing will surely encounter strong resistance.
In our experience security organizations often fail to recognize that in order for secure SDLC efforts to succeed, they need to extend beyond forcing standard process across the enterprise: they need to mesh with the unique development cultures of individual teams.
We’ve seen this scenario play out at several companies. Financial institutions, in particular, tend to favor a standard Secure SDLC approach which is clearly geared to monolithic waterfall processes even while many divisions within their company are moving towards lean/agile approaches. These process changes sometimes succeed in being “officially adopted” but usually without the grassroots buy-in of some, if not most, development groups. Faced with the prospect of culturally-incongruent process change thrust upon them, development teams often grow cynical of enterprise application security initiative. While the developers almost always fundamentally agree that protecting client confidential and/or integral data is important, they don’t agree with the methods recommended by the application security experts. Progress on SDLC security initiatives slow to a grinding halt.
In a future post we’ll share some practices that we’ve observed to successfully embed security into disparate software development cultures.
What’s your experience with rolling out a standard secure SDLC process across the enterprise?