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
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
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Commentary
How SolarWinds Busted Up Our Assumptions About Code Signing
Dr. Jethro Beekman, Technical Director,  3/3/2021
News
'ObliqueRAT' Now Hides Behind Images on Compromised Websites
Jai Vijayan, Contributing Writer,  3/2/2021
News
Attackers Turn Struggling Software Projects Into Trojan Horses
Robert Lemos, Contributing Writer,  2/26/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win an Amazon Gift Card! Click Here
Latest Comment: George has not accepted that the technology age has come to an end.
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-28466
PUBLISHED: 2021-03-07
This affects all versions of package github.com/nats-io/nats-server/server. Untrusted accounts are able to crash the server using configs that represent a service export/import cycles. Disclaimer from the maintainers: Running a NATS service which is exposed to untrusted users presents a heightened r...
CVE-2021-27364
PUBLISHED: 2021-03-07
An issue was discovered in the Linux kernel through 5.11.3. drivers/scsi/scsi_transport_iscsi.c is adversely affected by the ability of an unprivileged user to craft Netlink messages.
CVE-2021-27365
PUBLISHED: 2021-03-07
An issue was discovered in the Linux kernel through 5.11.3. Certain iSCSI data structures do not have appropriate length constraints or checks, and can exceed the PAGE_SIZE value. An unprivileged user can send a Netlink message that is associated with iSCSI, and has a length up to the maximum length...
CVE-2021-27363
PUBLISHED: 2021-03-07
An issue was discovered in the Linux kernel through 5.11.3. A kernel pointer leak can be used to determine the address of the iscsi_transport structure. When an iSCSI transport is registered with the iSCSI subsystem, the transport's handle is available to unprivileged users via the sysfs file system...
CVE-2021-26294
PUBLISHED: 2021-03-07
An issue was discovered in AfterLogic Aurora through 7.7.9 and WebMail Pro through 7.7.9. They allow directory traversal to read files (such as a data/settings/settings.xml file containing admin panel credentials), as demonstrated by dav/server.php/files/personal/%2e%2e when using the caldav_public_...