BSIMM10 Emphasizes DevOps' Role in Software Security

DevOps has reached a point in its adoption at which it influences the way organizations approach software security. Many businesses have implemented an engineering-led security culture to establish and grow software security efforts, researchers say in the BSIMM10 report.

The Building Security in Maturity Model (BSIMM), now in its 10th edition, is the product of a multiyear study of real-world software security initiatives (SSIs) seen in 122 businesses. Synopsys researchers annually compile the BSIMM report to help organizations develop software maturity programs with insights and guidance from real-world firms across industries.

They call the BSIMM a "measuring stick" for software security. Firms can compare the report's findings to their own projects and gain a better sense of how other organizations are handling the same initiatives. "You can identify your own goals and objectives, then refer to the BSIMM to determine which additional activities make sense for you," according to the report.

Ten years ago, security was a differentiator for highly regulated firms, many of which build a governance-driven software security initiative to drive security across their portfolio, explains Sammy Migues, information security visionary at Synopsys and one of the report's authors.

Now, BSIMM10 shows changes in how companies approach software security. A new wave of engineering culture is driving security efforts from engineering teams. There are two major factors in the shift: First is the convergence of process friction, unpredictable effects on delivery schedules, tense relationships, and more human-intensive processes from current SSIs. Second are demands and pressures from modern software delivery methods like Agile and DevOps. As a result, engineering has begun to prioritize automation over human-driven tasks, experts say. Decisions that used to fall to five-person meetings can be made more quickly with Python.

There are more issues at play when it comes to engineering culture, Migues says. Management has been asking more of development teams over the past few years, and developers have dealt with new languages, security requirements, deployment environments, and other changes. Modern ops teams use new logging and analysis methods; emphasis is on efficiency.

"Anything that represents friction or opaqueness is sort of getting pushed aside," he adds. "If security is too slow for the dev team, the dev team is going to do its own security." The "old school" security team has to learn how to play in the DevOps culture, Migues emphasizes. Developers' natural response to managerial pressure is to deliver more software, and faster.

What This Means for Security Groups
The industry is seeing the rise of an organizational structure that values SSI but doesn't integrate software security groups (SSG) into the process as an assigned group, the BSIMM10 reports. The SSG starts organically, usually within the engineering group. Engineers take on roles like "BuildSec," "ContainerSec," and "DeploymentSec," testing out specific capabilities like operations security or incident response before they form dedicated security-specific divisions.

In the past year, he says, researchers have noticed a rise in software security efforts within engineering organizations as engineers build out their own security capabilities. "They're taking all these little piece parts of security related to software, and they're doing it themselves," says Migues, noting that this often happens outside the view of the central security department.

Security teams have become accustomed to testing software after its completion and deciding then whether the code is strong enough to go into production. In the future, he says, security teams will become part of the application life cycle, or "value stream," to use a DevOps term.

"If you're not part of the value stream, you're going to be ignored," Migues adds. It's not a question of hiring, he explains. It's a matter of security catching up to the DevOps culture. "You aren't going to solve tomorrow's security problems by hiring more security people."

New Additions to the BSIMM
Researchers adjusted the descriptions of several activities, and added three new ones, to the BSIMM so as to reflect what firms are doing to integrate software security. The three activities in BSIMM10 include software-defined life cycle governance, software-assisted monitoring of software-defined asset creation, and automated verification of software-defined infrastructure.

These additions reflect how businesses are working on ways to accelerate security to match the speed of delivering functionality to market. "These are also direct offshoots of this new engineering-driven culture that's sort of dragging security behind it," Migues says. Most organizations don't have a top-down push to build security into development. Instead, pockets of security are happening at the bottom and getting pulled to the top across the dev team.

It's important to understand the difficulty of integrating security into DevOps greatly varies depending on the organization, he continues. Those who are doing DevOps well have homogeneous software portfolios, which gives them an advantage. Netflix, for example, has one application and, consequently, one development culture, Migues explains. "Changing a culture in that kind of homogeneous environment is not that hard," he continues. While the process can certainly take a long time, it's more streamlined to rally everyone around a common goal.

In contrast, a Fortune 500 bank may have thousands of applications and several development teams. A process that works for one application may take years to spread across an entire bank, he adds. Smaller companies also have it easier because they have fewer heterogeneous environments. Fewer tech stacks enable a more seamless process than in larger companies.

Related Content:

Check out The Edge, Dark Reading's new section for features, threat data, and in-depth perspectives. Today's top story: "The 20 Worst Metrics in Cybersecurity."