If you’re in business today, no matter what your “core” product or service is, you are almost certainly a software company. It is nearly impossible to run a business without it.
That means you should know about the Building Security In Maturity Model—better, and more conveniently, known as the BSIMM.
The BSIMM, documented in an annual report now in its 10th iteration, provides a roadmap to better software security through detailed, sophisticated analysis of companies that have a software security initiative (SSI).
It has been, since the start, a “measuring stick” for software security—a science experiment that escaped the lab. It is freely available under the Creative Commons license. And for those not familiar with it, it is important to make clear what it is not. It is not a directive—not a “must do” or a “one-size-fits-all how to.”
As the latest report, BSIMM10, puts it, “We like to say we visited a neighborhood to see what was happening and observed that ‘there are robot vacuum cleaners in X of the Y houses we visited.’”
The BSIMM does not say, "'all houses must have robot vacuum cleaners,’ ‘robots are the only acceptable kind of vacuum cleaners,’ ‘vacuum cleaners must be used every day,’ or any other value judgement. Instead, it simply observes and reports the current state of a software security program.”
For BSIMM10, those observations have yielded data and analysis from 122 organizations, mainly in eight industry verticals: cloud, internet of things (IoT), independent software vendors (ISV), high technology, healthcare, insurance, financial services and retail.
Since every organization is different, the benefit to them is that instead of dictating what any single organization should do, the BSIMM lets its readers see what others in their field are already doing, and what might work best for them.
The data are collected on 119 “activities” grouped under 12 “practices” that fall under four “domains”: Governance, Intelligence, SSDL (secure software development lifecycle) Touchpoints and Deployment.
And while those data are not used to declare that any company’s SSI is more “mature” than another, they do point to the collective maturity of those initiatives in industry verticals. With BSIMM10, there are three levels of maturity:
- An “emerging” SSI means the organization is booting it from scratch or formalizing nascent or ad hoc security activities into a holistic strategy. An emerging SSI has defined its initial strategy, implemented foundational activities, acquired some resources and might have a roadmap for the next 12 to 24 months of its evolution.
- A “maturing” SSI means the organization has an existing or emerging software security approach connected to executive expectations for managing software security risk and is progressing toward scaling security capabilities—working to cover a greater percentage of its technology stacks, software portfolio and engineering teams (in-house and supply chain).
- An “optimizing” SSI is one where the organization is fine-tuning and evolving its existing security capabilities (often with a risk-driven approach), having a clear view into operational expectations and associated metrics, adapting to technology change drivers and demonstrating business value as a differentiator.
The high watermark diagram below illustrates how frequently activities are observed in emerging, maturing and optimizing firms participating in the study. Activities designated as level are the ones that are most commonly observed—those designated as level three activities, as you might expect, are the ones that are less so. This diagram acts as a proxy for maturity overall, but can also be broken down by industry vertical, which then shows maturity and growth differences between industries.
It is clear that most organizations measured with the BSIMM have a strong understanding of foundational security activities. But some verticals collectively do more than others in various areas for a variety of reasons.
Some of the results are what you would expect. It is no surprise that in highly regulated industries, such as financial services, there is a spike around compliance and policy, as opposed to ISVs or IoT for instance.
In some industries, specific activities are more common for legal reasons relating to regulations, statutes and contracts. In others, customer expectation and preference, along with privacy expectations, may drive particular activities.
Another way to look at this is that different verticals carry out different security activities based on their different perceptions of risk, which is reflected in their high-water mark diagrams.
We don’t compare the maturity of individual SSIs from different verticals, such as healthcare company X and insurance company Y. That would be like comparing apples to oranges. But we can say that a group of firms within a specific industry vertical all do things that seem to be collectively important throughout that vertical.
One thing that does not change is that change is a constant. Software security evolves. And the BSIMM observes and tracks that evolution.
One new development noted in BSIMM10 is a substantial cultural shift within SSIs, in the form of a wave of engineering-led software security efforts originating bottom-up in the development and operations teams rather than top-down from a centralized software security group. Engineering-led security culture has shown itself to be a means of establishing and growing meaningful software security efforts in some organizations, whereas it struggled to do so even just a few years ago.
Another trend reflected in the BSIMM data is that the DevOps movement, along with the increased adoption of continuous integration and continuous development (CI/CD) tooling and digital transformation, is affecting the way firms approach software security for their software portfolios.
As DevOps culture and CI/CD toolchains intersect with cloud deployments, we’re realizing this is indeed a game changer in software security. We don’t yet understand the full impact, as the dust is still settling around this new phase in the evolution of these technologies and strategies.
Perhaps the next iteration of the BSIMM will shed more light on what organizations are doing to secure the cloud-native deployments coming from their DevOps and DevSecOps cultures.
