You can debate—in fact there is some ongoing debate—whether it’s possible to measure overall cybersecurity in the business world.
But there should be no debate that it is possible to measure one of cybersecurity’s chief components: software security. The BSIMM (Building Security In Maturity Model), a one-of-a-kind observational model built from real-world data by the Synopsys Software Integrity Group, has been making that possible for more than a decade. Nearly 200 companies can now attest to its usefulness as a management tool.
Indeed, with the release of BSIMM10 this week, there are now 119 data points in that measurement. That is the number of individual activities (you can think of them as controls) the BSIMM observational model has gathered across the software security initiatives (SSIs) of 122 organizations, primarily in eight industry verticals: cloud, internet of things (IoT), independent software vendors (ISV), high technology, healthcare, insurance, financial services and retail.
Not that every activity is mandatory for every firm, or even recommended. It is up to individual organizations to decide for themselves which activities will help them achieve the right software security posture across their application portfolio.
That’s because, from the beginning, the goal of the BSIMM has been to observe and report, not dictate or direct. It makes it clear up front that it is a “measuring stick” for software security that includes some “how to” guidance culled from 10 years of direct experience, but it doesn’t try to be a one-size-fits-all “what to do” guide. That journey is personal for every organization.
Instead, the BSIMM functions as a “what’s happening now” guide. The activities are grouped under 12 practices that are, in turn, grouped under four domains: governance, intelligence, SSDL (secure software development lifecycle) 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 has been 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.
BSIMM reports are free to download, licensed under the Creative Commons Attribution-ShareAlike 3.0 license.
All of which can take any firm a long way toward knowing how to measure and improve its software security. Also scattered through the practices are references to specific types of tooling to improve security. They include those for automation, multiple types of software analysis, fuzz testing and penetration testing.
An ongoing evolution
The BSIMM is an annual exercise, in part because software security practices continue to evolve—rapidly. This year’s report, authored by Sammy Migues, principal scientist, and Michael Ware, managing principal, both at Synopsys; and John Steven, former senior member, technical, at Synopsys and now CTO at ZeroNorth, is an example of that. This year’s report notes two significant evolutionary changes:
DevOps’ impact:The BSIMM10 data show that the DevOps movement, along with growth in CI/CD tooling and digital transformation, is affecting the way firms approach software security.
So BSIMM10 has updated activity descriptions to reflect these changes. It also adds three new activities to reflect how firms are working to make sure “building security in” to software development doesn’t slow it down.
The new activities focus on automation, first because it is replacing much slower human- and document-driven application lifecycle management processes.
But second, while automation fulfills the need for speed, it needs oversight. So two other activities focus on monitoring automated creation of virtual assets and making sure those assets adhere to security expectations, not only when they are created but also over the long term.
Engineering taking a driver’s seat: SSI culture is changing—there is a new wave of engineering-led software security efforts originating bottom-up in development and operations teams rather than top-down from a centralized software security group (SSG).
The report reflects that, noting that the change is “in response to both the demands of modern software delivery practices such as Agile and DevOps as well as undesirable friction with existing SSIs.”
The engineering-driven cultures “prioritize speed and automation, prototyping controls incrementally and building on the existing tools and techniques that already drive software delivery.”
Despite the different and sometimes competing priorities and approaches of the top-down and bottom-up cultures, sometimes they both exist within the same organization. “Aligning them while maintaining a single coherent SSI direction will require a concerted effort by all stakeholders,” the report says. As in, it’s important to play nicely together.
Migues, who has been an author of the BSIMM report since the beginning, said he sees this culture shift as likely to create some turmoil over the next several years. But ultimately, he said, “it will be a good thing.”
“Although it’s adversarial, it’s not the end of the world,” he said. “We have no idea how developers will be developing code in five years, so to imagine how it’s going to look then is foolishness. But ultimately, the [software security] ship is going to go truer, better and faster.”
Three stages of maturity
Besides those changes, the BSIMM10 data reinforce an encouraging trend seen from the start—when organizations put in the time and energy, their SSIs “grow up.” They mature, as intended. This is clear enough in the data to prompt this year’s report to define three phases of SSI maturity—emerging, maturing and optimizing.
The three stages essentially reflect the labels. An “emerging” SSI is just starting. A team has been “tasked with booting a new SSI from scratch or formalizing nascent or ad hoc security activities into a holistic strategy,” the report says.
The initial strategy will include some foundational activities, there will be some money and staff to support it, and it “might have a roadmap for the next 12 to 24 months of its evolution.”
But leaders of a new SSI tend to struggle to get both people and budget “and might use compliance requirements or other executive mandates as the initial drivers to continue adding activities,” the report says.
“Maturing” means an SSI is up and running, with some executive support and expectations, but still has a way to go. It’s working to cover more of the firm’s technology stacks, software portfolio and engineering teams.
But—and this is key—boosting the maturity of an SSI doesn’t necessarily come down to “do more activities” and then “do even more activities.” Instead, it can mean adding fewer activities while working on the depth, breadth, and cost-effectiveness of ongoing activities.
“Optimizing” describes organizations that are fine-tuning their existing security capabilities to match their risk appetite and to make sure their investment yields the desired posture. As the report puts it, using the BSIMM as a management tool provides a “clear view into operational expectations and associated metrics, [how firms are] adapting to technology change drivers and demonstrating business value as a differentiator. The SSI leader optimizing the program might also be undergoing an evolution from technology executive to business enabler.”
Room for growth
Obviously, given that there is now a decade’s worth of BSIMM reports, the project itself has gained some maturity. And Migues hopes for more, steady growth. While the number of verticals continues to increase—retail was added just last year—he said he would like to see others in the mix—automotive, energy and hospitality firms, for example.
He also noted that while there is a healthcare vertical, “currently, it kind of mashes together big research, big pharma and the corner drug store.”
Since the BSIMM doesn’t include any vertical in its annual report until there are at least nine participants (to preserve anonymity), it would take that many or more of a subgroup like big pharma within the healthcare vertical to break it out on its own.
“It would be great to have enough companies to have some differentiation,” Migues said.
Beyond that, he said the entire community benefits when more firms participate. “We want to see the community grow,” he said. “It’s already a tight-knit group that uses the BSIMM as a management tool. So, if this is as big as it gets, the world will still be a better place, but it could be even better.”
“We know that hundreds of other firms are using the BSIMM every day, but we’re not learning from them and they’re not learning from us.”