BSIMM 10: DevOps is changing how software teams approach security
DevOps is transforming how software teams handle security. That’s just one of the key takeaways from BSIMM 10, the newest version of an annual analysis by Synopsys of security activities at more than 100 companies.
BSIMM 10 authors Sammy Migues, John Steven, and Mike Ware wrote:
“The BSIMM data show DevOps adoption is now far enough along to affect the way we approach software security as an industry.”
The data in the 92-page report also indicates that an engineering-led security culture is becoming a means for establishing and growing meaningful software security efforts in some organizations.
Jim Routh, head of enterprise information risk management at financial services company MassMutual, said in a statement:
“The current BSIMM data reflect how many organizations are adapting their approaches to address the new dynamics of modern development and deployment practices, such as shorter release cycles, increased use of automation, and software-defined infrastructure.”
Synopsys launched BSIMM—the Building Security in Maturity Model—in 2008 as a measuring stick for software security. The number of companies participating in the project has increased with time, reaching 122 this year. Among the companies currently participating are Aetna, Bank of America, Cisco, Fidelity, Johnson & Johnson, PayPal, and Verizon.
BSIMM 10 includes 119 activities that any organization can implement to improve the security of its software. Three of those activities were added this year to reflect the impact of DevSecOps on security, and some suggestions from previous years were updated to reflect how how modern DevOps organizations are implementing them.
Here’s how DevOps is changing how development teams approach application security.
[ Get up to speed fast on the state of app sec and risk with TechBeacon’s new guide, based on the 2019 Application Security Risk Report. ]
Opening the floodgates
DevOps is affecting software security because it is accelerating software development. “In DevOps, everything is happening much faster,” said Caroline Wong, vice president of security strategy at Cobalt Labs, a penetration testing company in San Francisco.
With traditional waterfall development methods, security practitioners could insert gates into the development process that could not be passed until certain requirements were met. Now software is being developed so quickly that there’s no longer enough time to insert those gates.
“So what’s happening is there’s a lot more focus on automation. As software is being developed, security controls are automatically being included at the same time.”
Matt Trevors, technical manager at the CERT Division of the Software Engineering Institute of Carnegie Mellon University, added, “I’m not surprised BSIMM found the tangible connection between DevOps and security, because with old-style waterfall, you could have an 18-month project and not find out you have an issue until month 16.”
If you did the same project using DevOps, he added, you’re likely to get that feedback quicker and take action much sooner.
DevOps is influencing security in many ways, particularly in securing containers, said Dan Hubbard, CEO of Lacework, a provider of cloud security solutions. “We see automation of items like vulnerability scanning on containers in build and runtime.”
Engineer-led security culture
BSIMM 10 also revealed that an engineer-led security culture is starting to take hold in some organizations. Development teams can no longer tolerate the friction created by a top-down approach to security.
“We are now seeing bottom-up changes that are forcing executive-level governance programs to change the way organizations do security,” Migues, principal scientist at Synopsys and one of the report’s three authors, said. “Almost every way they did business before has had to go through its own digital transformation to catch up with what DevOps is doing in the name of resilience and automation.”
Engineering-led teams are making these changes, among others:
- Downloading and integrating their own security tools
- Spinning up cloud infrastructure and virtual assets as they need them
- Following policy on use of open-source software in applications, but routinely downloading dozens or hundreds of other open-source packages to build and manage software and processes.
These groups recognize the need to have security standards but tend to prefer “governance as code” as opposed to having an approach that consists of manual steps with human review, the report said.
“This tends to result in engineers building security features and frameworks into architectures, automating defect discovery techniques within a software delivery pipeline, and treating security defects like any other defect.”
Traditional human-driven security decisions are modeled into a software-defined workflow as opposed to written into a document and then implemented in a separate risk workflow that’s handled outside of engineering, the report said.
In this type of culture, the traditional gates and risk decisions don’t go away. They’re just implemented differently, and they usually have different goals when compared to those of governance-driven groups.
[ Take a deep-dive with our Application Security Trends and Tools Guide, which includes our 2019 App Sec Buyer’s Guide. ]
A maturity model matures
The activities show the common ground shared by the companies in the project, as well as variations in the software security initiatives of the companies that make them unique.
They also describe the work of 7,900 software security professionals who are guiding and maximizing the security efforts of nearly 470,000 developers working on more than 173,000 applications in eight verticals: cloud, Internet of Things, independent software vendors, high technology, healthcare, insurance, financial services, and retail.
As a tool that constantly evolves to reflect the experiences of hundreds of software security groups around the world, the BSIMM and its community are “invaluable resources, whether you’re just beginning your journey, looking to optimize your program, or grappling with new challenges,” said Synopsys’ Migues.
Carnegie Mellon’s Trevors said the initiatives, domains, practices, and activities in BSIMM largely map to those in the CERT resiliency management model.
“Any effort to do a data-driven model that shows companies how to build software with security in mind is A-plus in my book.”
While engineer-led initiatives are beginning to take hold in organizations, this type of culture still has a long way to go, said Jeff Williams, CTO and co-founder of Contrast Security, a maker of self-protecting software solutions.
“A lot of people take ‘shift left’ to mean we should take the legacy tools that are used for security and push them to developers so they can do their own security. The problem is those tools were built for experts. Developers don’t have the skills to run those tools.”
Developers will mostly just ignore or turn off the deep-dive security tools when they can, he added.
Embedding an engineering mindset into DevSecOps is like any other cultural change. BSIMM classifies itself as a “maturity model” because its creators believe that improving software security almost always means changing how organizations work, a process that takes time: