BSIMM11 gathers research on software security activities from real-life firms to create a guide to help you navigate your software security initiative.

The Building Security In Maturity Model (BSIMM)—the annual report on the evolution of software security initiatives (SSIs)—is gaining some maturity itself. The latest report, which went public this week, is the 11^th iteration.

Some things haven’t changed. The fundamental goal remains what it was at the start, more than a decade ago. As the authors frequently put it, this “science experiment that escaped the lab” is designed to help organizations navigate the often-treacherous path of developing an effective SSI and provide a free tool they can use to measure an SSI once it’s created.

But to achieve that goal, the BSIMM team has to assimilate and understand a lot of change, and that gets harder each year. So the BSIMM has grown up considerably. From an initial pool of just nine organizations and 110 activities in 2009, it has now tracked the evolution of software security through detailed observations of 211 organizations in multiple verticals and includes 121 observed activities.

In doing so, it established a reputation as the best available tool to measure software security initiatives, but not by prescribing a set way to do things. The BSIMM is primarily a “what’s happening now” guide. This year’s report is based on observations of 130 participating companies, primarily in nine verticals and spanning multiple geographies.

That’s up from 122 participants, primarily in eight verticals, last year. And the change is more significant than simply adding eight firms—there were 27 added and 19 removed to keep the data pool fresh.

The BSIMM examines activities 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 software security control activities included in the BSIMM11. It also directs the addition of new activities reliably observed in organizations.

By now, you should have heard of the BSIMM, especially if you are involved in software security. Maybe you’ve even downloaded a copy—it’s always been free and open. Under the Creative Commons Attribution-ShareAlike 3.0 license, data is published publicly each year, and many organizations use the BSIMM internally.

BSIMM11: What’s new this year?

And now it’s time to get a new copy because BSIMM11 is available. And since the BSIMM is completely data-driven, this report is different from any you might have read in the past. That’s because the world of software security evolves. The changes in BSIMM11 reflect that evolution. Among the changes:

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

•  A new definition: A key BSIMM term—software security group (SSG)—has been refined to acknowledge an evolution in software security leadership. Rather than implying that the group is always centralized in corporate, the definition now specifically acknowledges that it might be a federated collection of people in corporate, engineering, and perhaps elsewhere.

Indeed, this year’s report observed that organizations with governance-led security efforts and engineering-led security efforts are equally able to use the BSIMM to improve their capabilities.

• A new vertical: For the first time, the BSIMM includes the financial technology vertical—independent software vendors (ISVs) that make software specifically for the financial services firms—as a separate group.

Other key messages of the BSIMM11 include:

Don’t just shift left: Shift everywhere

When Cigital 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.

“For example, do DAST as soon as you have running code, and do configuration reviews as soon as you have defined or running environments, and collect composition analysis events from production agents that show dependencies dynamically incorporated into running systems as soon as you have deployed code,” he said.

“Sometimes, that’s to the left of where you’re doing some things today, but often it’s to the right, maybe all the way out in production.”

Engineering demands security at speed

Perhaps you could call it the democratization of security—making the means for success available to everyone. In some organizations tracked in the BSIMM, there is only a small centralized software security group focused primarily on governance. However, in a growing number of cases, engineering teams perform many of the software security efforts, with people responsible for 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. Very few organizations 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. That means 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.

Finally, in some organizations, security is becoming part of quality, which is becoming part of reliability, which is becoming part of resilience, which is becoming the operational goal for many engineering groups.

“Software security leaders who speak only the language of ‘penetrate and patch’ will soon be ‘patched’ out of the value stream by engineering teams that have moved on,” Migues said.

Champions as code

Traditional software security champions—security advocates from within or assigned to development teams—tended to function on a more personal level: brown bags, person-to-person conversation, email, spreadsheets, dashboards, and an occasional public call out of recalcitrant teams.

That is morphing into champions contributing security knowledge directly as code, in the form of toolchain sensors to determine software’s adherence to expectations (e.g., library use, lack of a certain defect, coding standards), pre-approved configurations and configuration checkers (e.g., for containers), reusable security libraries, and so on.

They are establishing “structural” security, so to speak. If developers write their code within a secure structure, they will build more secure software.

The cloud: Division of responsibility

The advantages of moving to the cloud are heavily promoted, and therefore well known. It’s cheaper, it makes collaboration of a dispersed workforce easier, and it increases mobility—team members can work from anywhere, 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.

And as noted in the BSIMM, “cloud providers are 100% responsible for providing security software for organizations to use, but the organizations are 100% responsible for software security.”

“Organizations that weren’t doing software security well in their private data centers are likely not doing software security well in the cloud either.”

Digital transformation: Everybody’s doing it

Digital transformation efforts are pervasive, and the reality is that 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

Beyond those highlights, 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, and so on. Automation helps but there are an enormous number of moving parts.

As Migues put it, “threat modeling is also getting easier (to federate) and harder (to know when to do it). Patching is getting easier in some cases (one container vs. 100 applications) and harder in some cases (knowing who owns all the stuff that comprises the CI/CD toolchains, glue code, homegrown tools, and so on).”

There are other large trends in the industry that deserve attention. “In particular, and anecdotally, the current world and political climate has caused significant changes in software security process, technology, and resourcing,” Migues said.

One example is the significant slowdown in hiring in many organizations, and a mandate to get both this year’s and next year’s goals done with the existing staff and technology.

“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 more—much more—detail in BSIMM11, which reports in depth on activities grouped under 12 practices that are, in turn, grouped under four domains: governance, intelligence, secure software development life cycle (SSDL) touchpoints, and deployment.

The activities show what participating organizations are doing and the types of tools they are using to enable their SSIs. Perhaps more importantly, the BSIMM shows how often each activity is seen in the current data pool. That allows any organization—those participating and those that aren’t—to see what is useful, or perhaps not useful, for others in their industry and across all verticals.

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.

Ready to improve your software security initiative?