Sergey Nivens - Fotolia
Information security has traditionally played the Aaron Burr to software development's Alexander Hamilton, the Hatfield to its McCoy.
Developers and security folks have viewed each other as enemies for a long time, said Dave Hatter, a software engineer turned cybersecurity consultant.
"As an application developer, I usually saw the security team as a giant impediment slowing me down, reducing my productivity and coming up with -- what seemed to me at the time -- ridiculous controls," Hatter said.
But Hatter and other experts say times are changing, as the constantly evolving threat landscape gives rise to a DevSecOps model that makes application security a DevOps priority rather than an afterthought.
"In the past 18 months or so, I've seen a shift with developers more open to guidance from security," consultant Michael Cobb said, noting that tutorials and literature aimed at coders increasingly reference security concerns. "We have a ways to go, but it is getting better."
In the DevSecOps model, security practitioners are involved from the design stage onward, rather than trying to make an application secure after its functionality is set. Proponents, like Hatter and Cobb, say this leads to safer software across the board because continuous testing and improvement counterbalance emerging threats. But a DevSecOps shop is rarely built in a day, they cautioned. A recent survey by Enterprise Strategy Group found that, while 55% of IT and cybersecurity professionals said they have incorporated some degree of security into DevOps workflows, just 33% reported involving security teams from a new project's inception. To execute a successful, meaningful shift to DevSecOps, security leaders and practitioners must consider culture, processes, tools and skill sets.
"There is enormous opportunity here to see huge productivity gains, as well as massive improvements in the security and quality of code," Hatter said. "It's the right thing to do, but it can be difficult to get there."
'A light touch'
Thanks largely to a growing number of sophisticated, high-profile cyberattacks, Hatter said there has never been a better time to work at the intersection of security and software development. Nevertheless, he added that many developers are traditionally focused on project deadlines, feature functionality and product time to market, so they still don't fully appreciate the importance of application security. That means security pros trying to make the case for DevSecOps often have their work cut out for them.
"It's a tough position to be in because a lot of developers just don't want to hear it," he said, adding that security teams should start with a "light touch" when integrating with the software side. Ideally, they will tactfully raise awareness about the importance of baking security into applications "without insulting the developers or downplaying the value they provide in getting working software delivered."
Cobb -- who works with enterprises transitioning to the DevSecOps model -- agreed that tone and delivery matter.
"In my experience, it needs to be introduced delicately," he said. "Security needs to take the approach of 'We're here to help' -- not 'We're here to tell you how you've been doing it incorrectly.'"
Avoiding heavy-handedness helps minimize inevitable organizational growing pains. DevSecOps typically sells itself once the security team has built trust and developers see their involvement ultimately leads to better code and applications, Cobb said.
"Developers love solving problems, like 'How are we going to make this request for this particular data more secure?'" he added. "I have found they quickly embrace it."
A risk-based security strategy
While DevSecOps creates a new normal for developers, it also means a cultural shift for many security practitioners.
"I think a lot of security people get too focused on wanting to block everything," Hatter said. "You've got to mitigate the most likely risks and not try to solve every problem under the sun."
No organization can completely protect itself from every possible threat, while still bringing products to market in a timely fashion, he continued, and an overzealous approach just serves to constrain, slow and frustrate developers.
Instead, the DevSecOps model calls for a context-driven, risk-based security strategy that prioritizes problems that pose a significant threat to critical organizational assets. This framework seeks to mitigate -- not eliminate -- risk. In addition to better protecting the business, pragmatic and strategic risk-based recommendations also tend to resonate with programmers, Hatter said.
"You say, 'We're on the same team; we're allies here. I want to help you produce the best software as fast as possible that's also secure so we don't go out of business when something horrific happens,'" he said.
Frederick "Flee" Lee, CISO at payroll, benefits and HR software company Gusto, said reframing security's mandate to reflect DevSecOps values can also profoundly improve satisfaction among practitioners.
"It definitely wears you down emotionally to constantly feel like the enforcer or the person slowing everyone else down," said Lee, who previously held cybersecurity roles at Bank of America, Square and Twilio. "With this shift toward DevSecOps, your security professionals are seen as the helpers -- a team that empowers developers to move faster by helping them build things the right way first."
Cobb added, however, that building things "the right way first" requires additional time during the design and development phases -- a reality that, to his frustration, still doesn't always play well with upper management. At one financial organization where he consults, for example, Cobb said the DevSecOps team recently got pushback from senior managers due to a weeklong security-related delay of a new feature's release.
"Developers are picking up that they need to write things securely, but that is not always being recognized by upper management," he said. "They don't say, 'Wow, this is a great new feature with rock-solid security' -- that's not a main selling point. I think DevSecOps still needs more sponsorship higher up."
"DevSecOps has expanded the security role quite dramatically -- it's almost an extra skill set," Cobb said. "You're such a valuable member of the team if you can talk one to one with a developer as they walk you through their code and understand the flow."
While experts say security pros don't need to write code themselves, they should get comfortable looking over developers' shoulders to assess, test and address security vulnerabilities at every stage in a project's lifecycle.
"Let's say they're using a tool such as Terraform, a coding language that allows you to standardize infrastructure as code," Lee said. "Your security team understands Terraform, and they're working alongside DevOps to make sure the default infrastructure is already secure."
This workflow theoretically gives programmers more freedom and agility to experiment as they go, without having to submit their code for a separate security review after completion. In another example, Lee said security pros might help build a secure golden image container template on which the development team can improvise.
"They can add their own extra sauce," he said. "Think of it as multiple chefs working on a meal together."
The plethora of educational resources available today -- vendor training materials, free online courses, YouTube tutorials, formal graduate programs -- makes it relatively easy to learn DevSecOps skills, according to Hatter. He cautioned, however, that there is no substitute for hands-on experience.
"Try to work on some projects, even if they're just hobbyist-type things," he advised. "I've been teaching programming at a local college for a long time, and there's no way to really get good at it without doing it."
As an emerging discipline in an industry already struggling with a labor shortage, the DevSecOps model will likely present a wealth of professional opportunities for motivated security pros, Hatter added.
"There just aren't that many people currently with that experience," he said. "In many cases, companies are going to have to build these people."