The BSIMM: Roadmap to Better Software Security

If you’re a human, you should care about software — a lot. Which is why you should care about the Building Security In Maturity Model (BSIMM), an annual report that tracks the evolution of software security.

First a disclaimer: I write for the Synopsys Software Integrity Group, which produces the BSIMM. But I’d write about it anyway — there’s nothing like it out there that offers a free roadmap to better software security.

Which is important because software — those billions of lines of code that look like gibberish to most of us — is behind just about everything made by people.

The BSIMM is especially relevant to organizations that build or assemble the software components that operate the products they sell. The last thing they should want to do is sell a product that isn’t secure. In a digital way, it would be like selling a car without brakes.

But even if you don’t build your own software, everyone in business today is also a software company. You need it to run your organization, market your product, and probably to build your product. You need it to handle your finances, human resources and everything else that once required mountains of paper and rows of file cabinets.

Even if you are “only” a consumer, software is the enabler behind the vast majority of things you use — not only your phone, laptop, tablet, watch and other personal digital devices, but also your vehicle, utility services like water and electricity, your nannycam, your smart appliances, your home security, and more, more, more.

You’ve heard of the Internet of Things (IoT)? It’s rapidly becoming the Internet of Everything (IoE) — about 30 billion connected devices in the world today with billions more being added each year. All those devices, plus the systems and networks they use, function (or malfunction) because of software.

In short, life as we now know it would not be possible without software.

Good, bad and ugly

Most of what it does we like very much — it enables services, entertainment, communication, access to information, and conveniences that most people didn’t dream were possible even a couple of decades ago.

But since it’s designed and built by humans, software isn’t perfect. And as daily headlines remind us, cyber criminals can exploit design flaws, defects, bugs and other weaknesses in software to do things the rest of us don’t like at all — swipe our credit card numbers and banking credentials, steal our identities, invade our privacy and in some cases jeopardize our physical safety by taking control of things like home security systems, vehicles, or implanted medical devices.

So software security is not something that’s just nice to have. It’s crucial to what we now take for granted in modern life, both individually and collectively.

And it’s what makes the BSIMM relevant. The report is not an instruction manual — it doesn’t prescribe what organizations should do or how to do it. But it does track and document what companies are doing now — how they’re spending time and money on software security initiatives (SSI).

This year’s BSIMM, which went public last week, is now in its 11th iteration. It’s based on in-depth observations of the SSIs of 130 participating companies, primarily in 9 verticals including cloud, IoT, independent software vendors, high technology, healthcare, insurance, financial services, financial technology, and retail.

The authors of the BSIMM sometimes refer to it as “a science experiment that escaped the lab” because it is loaded with data points.

This year’s report tracked 121 separate software security “activities” (also called “controls”) grouped under 12 practices that are, in turn, grouped under 4 domains: governance, intelligence, secure software development lifecycle (SSDL), and deployment.

The activities reveal what participating organizations are doing and the types of tools they’re 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.

A measuring stick

But you don’t need to wade through all that detail to benefit. The report is structured so an organization can study what others are doing in the same industry. For that reason, it has also been called a measuring stick for software security.

The primary focus of the BSIMM is right in its name. From the start in 2009, the goal has been to help organizations “build security in” to their software throughout the software development life cycle (SDLC) rather than figuratively bolt it on at the end of that process, when it takes much more time and is much more expensive.

Indeed, the Systems Sciences Institute at IBM reported several years ago that it cost 6 times more to fix a bug found during implementation than to fix one found during design. And that the cost to fix bugs found during testing at the end of the SDLC could be a staggering 15 times more than fixing them during design.

That’s what prompted Cigital (which launched the BSIMM and was acquired by Synopsys in 2016) to push the concept of “shift left” in software development, as in, find and fix bugs and flaws earlier in the SDLC. That phrase has since become a mantra at security conferences.

But this year’s BSIMM makes a major point of refining that phrase. It was never meant to be taken so literally as to mean shift only left.

“What we really meant is more accurately described as ‘shift everywhere’ — to conduct a security control 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.

The report also documents major trends in software security. Among them:

Security initiatives moving to the grassroots

Instead of a centralized group dictating what to do and how to do it, in a growing number of cases it is engineering teams that are organizing and performing security tasks.

That’s changing both the way those tasks are done and the tools being used. The move to bring development, security and operations teams together into DevSecOps has been under way for some time. But it has meant increased pressure on security to keep up with the demand for speed by developers.

As Migues put it, the message from developers is, “We’d love to have security in our value streams if you don’t slow us down.”

So the BSIMM found that development teams are moving to use security testing tools that keep up with them. They opt for free and open source tools over more thorough commercial tools that create, or appear to create, more friction than benefit. That means security tool vendors that can’t meet the need for speed could become obsolete.

Security champions as code

The “security champion” concept — volunteers within development teams trained to become security advocates — is well-established. But it’s now moving away from the personal level, with things like brown bags, one-on-one conversation, email, spreadsheets, dashboards, and an occasional public call out of recalcitrant teams.

Instead, champions are contributing security knowledge directly as code, in the form of toolchain sensors that determine software’s adherence to expectations such as library use, lack of a specific defect, and coding standards.

Cloud cover

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

But using the cloud also means an organization is outsourcing at least parts of its software security practice areas that are traditionally done locally.

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

And more …

There is more — much more — in the BSIMM, which not only reports on the types of security testing tools participating organizations are using to enable their SSIs, but also on how often each security control activity is seen in the current data pool.

And besides providing a “roadmap” to starting an SSI, it gives organizations that have established an SSI a way to evaluate their maturity, from “emerging,” or just starting; to “maturing,” meaning up and running, with some executive support and expectations; to “optimizing,” which describes organizations that are fine-tuning their existing security capabilities to match their risk appetite and their investment in security.

The BSIMM doesn’t claim that doing any or all of this will make your software perfect. Nothing will. But an effective SSI will make it more resilient — a much more difficult target. And cyber attackers, just like criminals everywhere, look for the easiest targets.

Best of all, it’s free and open, available under the Creative Commons Attribution-ShareAlike 3.0 license.

Software is already delivering on what only a few years ago, would have been considered a utopian future. But just like a building, if the construction isn’t secure and the foundation is porous, it won’t stand.

That’s why the BSIMM is both relevant and important.