A funny thing happened as IT embraced DevOps and broke down longstanding silos between teams: Many organizations created new silos in their place, around security.
“We found through our research that DevOps and security teams are already operating in silos, and the rush to the cloud is exacerbating this disconnect,” says Pete Cheslock, senior director at Threat Stack. “Teams are increasingly isolated, and they’re facing a steep learning curve.”
This is why you’re increasingly hearing the term DevSecOps. You’re forgiven if you’re skeptical of buzzwords: The term reflects that security teams exist on a lonely island in too many companies. This isn’t necessarily a new silo, just one that became more pronounced as other teams began working more closely together.
As Red Hat security strategist Kirsten Newcomer told us previously, “Security teams have historically been isolated from development teams – and each team has developed deep expertise in different areas of IT.”
That isolation is why DevSecOps is not a mere buzzword, but a critical culture shift in the age of cloud, containers, and increasing pressure to deploy, deploy, deploy.
[ Want DevOps advice from other CIOs? See our comprehensive resource, DevOps: The IT Leader's Guide. ]
“What’s needed are programs that enable organizations to securely leverage modern infrastructure and DevOps, without straining security teams or operations performance,” Cheslock says. “To reduce risk without taxing resources, DevOps principles need to be applied to security practices too.”
Enter DevSecOps, which intends to do just that. We asked Cheslock and other IT and security leaders for their advice on really getting your team on board, which is easier said than done: Your team can be forgiven for a bit of buzzword cynicism, too. Read on for six strategies for getting everyone to buy into DevSecOps.
Make it about people first, tools second
Let’s start with perhaps the biggest roadblock to DevSecOps buy-in. Tools do matter, just as they did in earlier phases of the DevOps era. But dropping some security and testing technologies into your software pipeline and declaring “We’re DevSecOps!” will do little to bring people truly on board. It’s more a matter of culture than technology – and that needs to be driven by your people.
“DevSecOps is not about tools,” says Mike Kail, CTO and co-founder at CYBRIC. “It’s about establishing the culture where the security team is a collaborative member of the software development life cycle and CI/CD pipeline.”
You’ll commonly hear that a healthy security culture depends upon everyone in the organizations treating security as their responsibility, even if it’s not written in their job description.
But if that happened naturally, we wouldn’t be writing this article: Just as developer and operations teams were often working with conflicting direction or performance incentives in the past, security can also get stuck chasing goals that are misaligned with the rest of the team.
“We need shared goals across teams in order to encourage collaboration,” Cheslock advises.
A straightforward example: If developers are under constant pressure to ship their code, they may see security as an impediment to meeting their objectives. We’ll dig into this in more depth, but suffice it to say that’s going to hinder DevSecOps buy-in. Various functional teams need to understand how their particular goals align with and benefit one another.
“The development mindset needs to see the value in adding security in lieu of delivery expectations,” says Lucky Johnson, ESM senior architect at AHEAD. “Getting the team to understand the core responsibility of each other and how each can benefit from the other is a key success factor.”
Empower security pros to help lead culture change
Sam Bisbee, CSO at Threat Stack, offers a key strategy for encouraging different functions within the same team better understand each other and work together toward a healthy DevSecOps culture: Let security help lead that process.
But he also stresses the importance of his fellow security pros understanding how others in the organization understand them.
“As a security professional, you must realize that most non-security professionals have either had no experience or generally negative experiences with security teams,” Bisbee explains. “You will have to start building the bridges yourself.”
[ Are you speaking the wrong language? See How to talk to normal people about security. ]
If there’s friction between operations and security, for example, Bisbee advises his security peers to take the first steps toward alleviating it: Try using the processes and tools Ops already has in place, for example, and offer clear statements of value when suggesting a change.
Getting people on board with DevSecOps also gets easier when different areas of IT find common ground.
“For example, both security and operations dislike it when people log into production servers, just for different reasons: availability and performance versus security and compliance,” Bisbee says. “Security teams also shouldn’t be afraid to jump in and help with the occasional availability incident to build trust and mutual respect.”
Kail offers related advice when it comes to bridging gaps between development and security.
“To start the transformation, the security team needs to be internally aligned around the strategy for implementing security testing into the SDLC, and then meet with the development team to present that framework,” Kail says. Again, understand what different teams care about. “It’s important to articulate the fact that this won’t be disruptive to developer velocity and that they will only have to change behavior if there are any vulnerabilities to remediate.”
Consider “security champions” on product teams
While there’s truth in the idealistic vision that security should be everyone’s responsibility, that pie-in-sky goal can also create a mindset where everyone assumes someone else is taking care of it. So consider making some individuals more responsible than others, and not limiting this greater responsibility to your actual security team.
Take the “security champion” model, in which specific members of different application teams take on a security leadership role. Here’s how The Open Web Application Security Project (OWASP) defines the role:
- “Security Champions are active members of a team that may help to make decisions about when to engage the Security Team.”
- “Act as the ‘voice’ of security for the given product or team.”
- “Assist in the triage of security bugs for their team or area.”
Security pro Alexander Antukh, head of product security at Opera Software, even created a Security Champions Playbook, available via Github, which gives anyone a good starting point for doing something similar in their own organization.
