BSIMM11 Observes the Cutting Edge of Software Security Initiatives

If you want to improve the security of your software—and you should—then you need the Building Security In Maturity Model (BSIMM), an annual report on the evolution of software security initiatives (SSIs). The latest iteration, BSIMM11, is based on observations of 130 participating companies, primarily in nine industry verticals and spanning multiple geographies.

The BSIMM examines software security activities, or controls, on which organizations are actually spending time and money. This real-world view—actual practices as opposed to someone’s idea of best practices—is reflected in the descriptions written for each of the 121 activities included in the BSIMM11.

Since the BSIMM is completely data-driven, this report is different from any earlier ones. That’s because the world of software security evolves. The changes in BSIMM11 reflect that evolution. Among them:

New software security activities 

BSIMM10 added new activities to reflect the reality that some organizations were working on ways to speed up security to match the speed with which the business delivers functionality to market.

To those, BSIMM11 adds activities for implementing event-driven security testing and publishing risk data for deployable artifacts. Those directly reflect the ongoing DevOps and DevSecOps evolution and its intersection with traditional software security groups.

Don’t just shift left: Shift everywhere

When the BSIMM’s authors began writing about the concept of shifting left around 2006, it was addressing a niche audience. But the term rapidly became a mantra for product vendors and at security conferences, dominating presentations and panel discussions. At the February 2020 RSA conference in San Francisco, you couldn’t get through any of the sessions in the DevSecOps Days track without hearing it multiple times.

And the point is an important one: Don’t wait until the end of the SDLC to start looking for security vulnerabilities.

But the concept was never meant to be taken literally, as in “shift (only) left.”

“What we really meant is more accurately described as shift everywhere—to conduct an activity as quickly as possible, with the highest fidelity, as soon as the artifacts on which that activity depends are made available,” said Sammy Migues, principal scientist at Synopsys and a co-author of the BSIMM since its beginning.

Engineering demands security at speed

Perhaps you could call it moving security to the grassroots. Because while in some organizations tracked in the BSIMM there is only a small, centralized software security group focused primarily on governance, in a growing number of cases engineering teams now perform many of the software security efforts, including CloudSec, ContainerSec, DeploymentSec, ConfigSec, SecTools, OpsSec, and so on.

That is yielding mixed results. Being agile, those teams can perform those activities quickly, which is good, but it can be too fast for management teams to assess the impact on organizational risk. Not so good. Few organizations so far have completely harmonized centralized governance software security efforts and engineering software security efforts into a cohesive, explainable, defensible risk management program.

Still, engineering groups are making it clear that feature velocity is a priority. Security testing tools that run in cadence and invisibly in their toolchains—even free and open source tools—likely have more value today than more thorough commercial tools that create, or appear to create, more friction than benefit. The message: We’d love to have security in our value streams—if you don’t slow us down.

The cloud: Division of responsibility

The advantages of moving to the cloud are well known. It’s cheaper, it makes collaboration of a dispersed workforce easier, and it increases mobility, which is practically mandatory during an extended pandemic.

But using the cloud effectively also means outsourcing to the cloud vendor at least parts of your security architecture, feature provisioning, and other software security practice areas that are traditionally done locally.

As the BSIMM notes, “cloud providers are 100% responsible for providing security software for organizations to use, but the organizations are 100% responsible for software security.”

Digital transformation: Everybody’s doing it

Digital transformation efforts are pervasive, and software security is a key element of it at every level of an organization.

At the executive (SSI) level, the organization must move its technology stacks, processes, and people toward an automate-first strategy.

At the SSG level, the team must reduce analog debt, replacing documents and spreadsheets with governance as code.

At the engineering level, teams must integrate intelligence into their tooling, toolchains, environments, software, and everywhere else.

Security: Getting easier—and more difficult

Foundational software security activities are simultaneously getting easier and harder. Software inventory used to be an Excel spreadsheet with application names. It then became a (mostly out-of-date) configuration management database.

Now organizations need inventories of applications, APIs, microservices, open source, containers, glue code, orchestration code, configurations, source code, binary code, running applications, etc. Automation helps but there are an enormous number of moving parts.

 “Primarily, we see this implemented as a significant acceleration in process automation, in applying some manner of intelligence through sensors to prevent people from becoming process blockers, and in the start of a cultural acceptance that going faster means that not everything (all desired security testing) can be done in-band of the delivery lifecycle,” Migues said.

Your roadmap to a better software security initiative starts here

There is much more detail in BSIMM11, which reports in depth on the 121 activities grouped under 12 practices that are, in turn, grouped under four domains: governance, intelligence, secure software development life cycle (SSDL) touchpoints, and deployment.

In addition to helping an organization start an SSI, the BSIMM also gives them a way to evaluate the maturity of their SSI, from “emerging,” or just starting; to “maturing,” meaning up and running, including some executive support and expectations; to “optimizing,” which describes organizations that are fine-tuning their existing security capabilities to match their risk appetite and right-size their investment for the desired posture.

Wherever organizations are on that journey, the BSIMM provides a roadmap to help them reach their goals.

About the author: Taylor Armerding is an award-winning journalist who has been comvering the field of information security for years.

Copyright 2010 Respective Author at Infosec Island via Infosec Island Latest Articles "https://ift.tt/3m8Ro8E"