Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Application Security

9/19/2019
04:15 PM
Connect Directly
Twitter
LinkedIn
Google+
RSS
E-Mail
50%
50%

BSIMM10 Emphasizes DevOps' Role in Software Security

The latest model, with insights from 122 firms, shows DevOps adoption is far enough along to influence how companies approach 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."

Kelly Sheridan is the Staff Editor at Dark Reading, where she focuses on cybersecurity news and analysis. She is a business technology journalist who previously reported for InformationWeek, where she covered Microsoft, and Insurance & Technology, where she covered financial ... View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
How to Think Like a Hacker
Dr. Giovanni Vigna, Chief Technology Officer at Lastline,  10/10/2019
7 SMB Security Tips That Will Keep Your Company Safe
Steve Zurier, Contributing Writer,  10/11/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
7 Threats & Disruptive Forces Changing the Face of Cybersecurity
This Dark Reading Tech Digest gives an in-depth look at the biggest emerging threats and disruptive forces that are changing the face of cybersecurity today.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-17666
PUBLISHED: 2019-10-17
rtl_p2p_noa_ie in drivers/net/wireless/realtek/rtlwifi/ps.c in the Linux kernel through 5.3.6 lacks a certain upper-bound check, leading to a buffer overflow.
CVE-2019-17607
PUBLISHED: 2019-10-16
HongCMS 3.0.0 has XSS via the install/index.php servername parameter.
CVE-2019-17608
PUBLISHED: 2019-10-16
HongCMS 3.0.0 has XSS via the install/index.php dbname parameter.
CVE-2019-17609
PUBLISHED: 2019-10-16
HongCMS 3.0.0 has XSS via the install/index.php dbusername parameter.
CVE-2019-17610
PUBLISHED: 2019-10-16
HongCMS 3.0.0 has XSS via the install/index.php dbpassword parameter.