Report: Security and development teams need to ‘embrace’ new roles in DevSecOps

For sustainable, long-term application security, both developers and information security professionals must embrace their new roles created by DevSecOps.

We’re a long way from simply turning a knob or clicking on a button to produce secure software.

But given the increasing need for speed in software development, things are moving in that direction, at least incrementally. DevSecOps, which integrates application security practices into the DevOps process, is a trend that is well underway. Modern organizations are relying increasingly on automation rather than manual testing to help development teams find and fix security defects, from design flaws to bugs.

Along with that comes an incremental shift in who is using or overseeing application security testing (AST) tools, from information security teams to development teams.

Sponsorships Available

Sponsorships Available

Sponsorships Available

That doesn’t mean “automation” is equivalent to “autonomous.” Producing secure software in DevSecOps still requires multiple application security tools to conduct multiple kinds of testing throughout the software development life cycle (SDLC). Modern tools include static, dynamic, and interactive application security testing; software composition analysis (SCA), designed to find and evaluate open source code used in applications; and penetration testing.

It also takes more than clicking on a button to use those tools effectively. It requires involvement by skilled humans. And there is a shortage of those humans.

AppSec skills gap is a stumbling block

A recent report, sponsored by Synopsys and conducted by 451 Research, titled Designing a Modern Application Security Program, found that “at most organizations, there are more application developers than there are information security professionals.”

Beyond that, the report said, “having information security professionals running point-in-time scans and attempting to advise developers on their code is a difficult proposition even when information security teams have coding expertise—which, in most cases, they don’t.”

That skills gap is significant, since software is the engine for everything online, from networks to systems to applications. It is not just that, as Netscape co-founder Marc Andreessen wrote in 2011, “software is eating the world.” It’s that software is powering the world.

And as has been said numerous times, any company that has an online presence and relies on any technology is also a software company.

DevSecOps and the application security skills gap

Bottom line: Software is everywhere and in everything, which makes it the biggest and most attractive attack surface in the world. Which ought to make the security of software a top priority for any organization.

But how does an organization close the gap between the skills it needs to produce secure software and the skills it actually has?

Bring on DevSecOps, enabled partly by a “new wave of engineering culture,” as described in BSIMM10, the 10th annual Building Security In Maturity Model report by data scientists at Synopsys, released in October.

The BSIMM10 report found that modern software security efforts are “emerging from engineering teams,” driven in part by “demands and pressures from modern software delivery practices, such as Agile and DevOps. The result is engineering groups placing more emphasis on automation as opposed to human-driven tasks.”

And as the 451 Research report put it, “the most direct approach is to integrate tools such as SAST directly into popular integrated development environments. For example, a SAST plug-in can check code on each save and limit the scope of scans to the code being worked on, representing a fairly-low-inhibitor approach to identifying security problems without derailing coding efforts.”

The goal is the same, but the means are evolving

So while application security remains a goal, the view of it and how to achieve it is evolving under DevSecOps.

“Emerging engineering-driven groups tend to view security as an enabler of software features and code quality,” the BSIMM10 report said.

Is that a good thing? The jury is still somewhat out. BSIMM10 described the move toward engineering-driven software security initiatives (SSIs) and away from a “top-down” governance approach with rules that teams must follow for proactive risk management. As the report noted, the move means that “software-defined sensors and checkpoints are replacing human discretion, conversations, and risk decisions that should involve multiple stakeholders.”

“Many application lifecycle processes are moving faster whether they’re ready to or not. And, perhaps most importantly, all this software security effort is frequently happening independently from the experience and lessons learned [from] a centralized SSG [software security group],” the report said.

New application security roles in DevSecOps

On the other hand, the DevSecOps evolution could lead to both development teams and InfoSec teams doing more of what they do best.

The 451 Research report noted that “security professionals are judged by their ability not only to resolve incidents but also to prevent them; developers, by their ability to release defect-free code that addresses business requirements quickly.”

The report also noted the trend that, over four years, “though information security has remained the primary user [of AST tools], that group’s use of AST has shrunk from 57% to 42%. Application development’s use of AST, by contrast, has risen over the same period from 23% to 31%.”

The transfer of certain application security testing responsibilities from InfoSec to development teams, the report said, “carries with it more complexity, better and more realistic coverage, and thus a greater need for coordination.”

“It is only through the coordination of both teams’ motivations and activities that an organization can build a sustainable long-term application security discipline into its culture.”

InfoSec teams that don’t “embrace” their evolving role in DevSecOps, as the 451 Research report put it, could find themselves undermining sustainable, long-term application security.

Andrew van der Stock, senior principal consultant at Synopsys, said InfoSec teams that refuse to be a part of the DevOps process “are already frozen out. We made a mistake in the 1970s of thinking we were auditors, when we are absolutely not auditors,” he said.

“We need to help build secure solutions, and that means being an SME [subject matter expert] to help teams design better solutions and interpret automated tool results. That’s already a movement that is about a decade old. Anyone not already on this train will be irrelevant in the next few years.”