DevSecOps success takes people, not just technology
Want DevSecOps? Here are some tips to get your development, security, and operations teams communicating effectively and working toward a single purpose.
DevSecOps is very much about technology: tools, automation, processes.
But it is also about people. It is people, after all, who create and operate the technology that brings software into being and runs it.
It is also people—spread across three teams that historically worked independently and frequently viewed one another with suspicion—who have to collaborate if DevSecOps is going to work.
A number of its practitioners have pointed out that the DevSecOps cultural shift is still underway. Some organizations are already doing it better than others, nurturing a culture in which development, security, and operations aren’t really separate teams. Instead, they are all on the same team with the same goal: Produce secure, high-quality software faster. They just have different roles to play in achieving that.
It is not a direct parallel, but nobody would argue that offense, defense, and special-teams units in football are on “different” teams. They just have different roles to play to accomplish a shared goal: Win the game.
With software, while Development may have focused primarily on speed, Security on security, and Operations on quality, the goal now is for those roles to overlap in an environment of teamwork, coordination, agility, and shared responsibility.
As noted, some organizations are more mature than others in reaping the benefits of DevSecOps without the negatives of constant clashes among the teams. How do they do it? Here are a few key pillars of success:
Peace, love, and understanding
OK, you could pull “love” out of that old ’70s hippie slogan. DevSecOps doesn’t have to be warm and fuzzy. And you should probably put “understanding” at the front, since understanding will lead to both peace and productivity.
It is also a great place to start because the most common complaint from any of these teams is that the other teams don’t “understand.”
Security teams complain that developers don’t understand security. Developers complain that security people don’t understand what they do, and the pressures they face.
They’re both right.
Tanya Janca said as much at RSA 2019, in a talk titled “Security Learns to Sprint: DevSecOps,” when she declared that soft skills, or interpersonal skills, are just as important as tech skills.
Janca, founder, security trainer, and coach at SheHacksPurple.dev and OWASP Ottawa leader, said what other DevSecOps evangelists have been preaching for some time: “Change the way we make software so that the easiest way to do something is also the most secure way.”
She might have substituted “fastest and cheapest” for “easiest,” since that remains the major sticking point between Dev and Sec.
Janca cited Ponemon Institute Research that found the cost of fixing a quality or security defect during coding is about $80. It rises to $240 to fix a defect found during build, $960 during QA and testing, and a staggering $7,600 during production.
Yet security is still perceived as a hurdle to overcome on the way to more features and functionality, and a drag on the speed of delivery.
Indeed, “culture” was a major theme at the RSA 2020 DevSecOps Days event. At a panel discussion titled “DevSecOps and Disruption,” the participants agreed that putting development, security, and operations teams together was not so much a technical problem as it was a human problem. (Their conclusion aligned nicely with the overall theme of this year’s conference: the “Human Element.”)
“Dev, Sec, and Ops hate each other because they don’t understand or talk to one another,” said Sean Davis, chief transformational officer at Equifax. He added that if the leaders of those teams bring people to the table and make it “psychologically safe” for them to speak, that will give their teams “an opportunity to succeed.”
Automate, automate
To address the (perceived) lack of understanding between the development, security, and operations teams, one thing the security team needs to do is automate.
Manual security testing cannot keep up with the current pace of software development. But security teams that seek out solutions to automate testing show an understanding of modern development practices.
For example, the majority of the code in modern applications—frequently more than 90%—is not so much written as assembled from third-party and open-source components, APIs, and libraries, sometimes with multiple dependencies. Tracking these components by hand is difficult; cross-referencing them to vulnerability databases is even harder. But a good software composition analysis (SCA) tool can automatically find known vulnerabilities in all open source components, their dependencies, their dependencies’ dependencies, and so on, uncovering security issues that could be lurking in a codebase multiple layers deep.
And security automation is growing. Last year’s 10th iteration of the BSIMM (Building Security In Maturity Model) report described three new activities that reflect how firms are working to match the speed of software security to the speed at which their business delivers functionality to market:
- Integrate software-defined lifecycle governance, which replaces traditional human- and document-driven processes with automation that drives application lifecycle management processes.
- Monitor automated asset creation, which helps maintain awareness of the virtual assets being created by engineering teams.
- Automate verification of operational infrastructure security, which helps ensure that virtual assets adhere to security expectations not only when created, but long term.
We are the champions
Security teams can’t do it all. They are vastly outnumbered. Some estimates are that in a DevSecOps environment, there is just one Security team member for every 10 people in Ops and 100 in Development.
So, what better way to give security a numerical boost and bridge the understanding gap between Dev and Sec than to create “security champions” within the development team? Who better to understand development than … a developer?
Creating a security champions program is a growing and useful trend, especially because the idea is not to force it on anybody. Champions are volunteers who are looking to build their skill set and make themselves more marketable. It is a step up the career ladder.
So they volunteer for advanced software security training that helps them help others on their team—developers, testers, and architects. Security champions can usually communicate more effectively with them than a security “outsider.”
The idea is that when somebody on the team has a question or is struggling to fix a vulnerability, a champion can come in as both a mentor and a peer.
Shift left, right, and center
The term “shift left” has become a major buzz phrase in security during the past decade. The idea is to start security testing at the beginning of the software development life cycle (SDLC) instead of waiting until the end when bugs and other defects are, as noted above, much more time-consuming and expensive to fix.
But as Sammy Migues has said multiple times, shifting left shouldn’t imply that every other step in the SDLC is less important.
Migues, principal scientist at Synopsys and a co-author of the BSIMM report since the beginning, said he began talking about shifting left in 2011 but that he “never really meant it to be a single action. What I meant was that SSIs [software security initiatives] needed to adopt a culture and philosophy of doing the right testing as soon as you have enough of an artifact to test.”
Which also means testing at the speed of development.
That is also the way DevSecOps can, and should, work.
