BSIMM: The roadmap to building trust into software — faster
We are apparently about midway through software’s consumption of the world.
It was 2011 when Marc Andreessen, coauthor of Mosaic and cofounder of Netscape, famously said “software is eating the world.”
Then just last year Alfred Chuang, cofounder of BEA Systems (sold in 2008 to Oracle) and now general partner with Race Capital, declared that by 2030 software will have long since eaten the world. As he put it, “In 2030, software is the world.”
Chuang also predicted that the world’s largest organizations in every industry — education, finance, food, healthcare, hospitals, entertainment and more — will all be software companies.
Which seems like not much of a prediction at all. It’s already true. Virtually every company that does business outside its own neighborhood (probably even those that stay in their neighborhoods) is a software company. If you’re in business, you need software to 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.
But whether the world is already eaten or only half-eaten, the point is that software — those billions of lines of code that read like gibberish to most mortals — is in just about everything and runs just about everything. Indeed, most tech experts no longer call the ubiquitous connected devices throughout the world the Internet of Things (IoT). It is more accurately called the Internet of Everything (IoE).
Which is why the Building Security In Maturity Model (BSIMM) is so important. Among the hundreds of information technology acronyms (believe me, I know — I have pages of them), the BSIMM should be among those at the top of your list. The subject of an annual report now in its 12th iteration (released today), it is a self-described roadmap to help organizations improve the security of the software that runs their enterprises. And it is free, available under the Creative Commons Attribution-ShareAlike 3.0 license.(Disclosure: I write for the Synopsys Software Integrity Group, which produces the BSIMM report.)
The need for that kind of roadmap should be obvious. While software has brought efficiencies, conveniences, and connections that seemed unimaginable a couple of decades ago, it has also brought risks. Software isn’t perfect — nothing is — and as daily headlines remind us, if hackers can exploit design flaws, bugs, and other weaknesses in software, they can 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.
And the exponential growth of the IoT means the attack surface for hackers is expanding just as fast. From a “mere” 7 billion IoT devices in 2018, there are an estimated 35.8 billion this year, and some forecasts are for that to grow to 41.6 billion by 2025.
All of which means insecure software is a business risk — potentially an existential risk. And if you’re in business you need to make (and keep) that software secure enough for you and your customers to trust it.
The BSIMM report helps organizations build trust into their software, not by dictating what to do but by documenting what dozens of organizations in multiple industries are already doing — how they’re spending time and money on software security initiatives (SSI). The report leaves it up to organizations to decide what’s the best way to reach the maturity destination. Indeed, the whole idea of a roadmap is to show multiple routes to a destination without dictating the one you should take.
The BSIMM, launched in 2008 by a team of consultants, researchers, and data experts from what is now the Synopsys Software Integrity Group, started with just nine participating companies. This year there are 128 participants from verticals including financial services, FinTech, independent software vendors, IoT, healthcare, and technology.
Within those 128 companies are nearly 3,000 software security group (SSG) members. An SSG is an internal group responsible for software security.
This year’s report tracked 122 separate software security “activities” grouped under 12 practices that are, in turn, grouped under 4 domains: governance, intelligence, secure software development life cycle (SSDL) touchpoints, and deployment.
The activities document the types of tools participant organizations are using to enable their SSIs, and how often each activity is seen in the current data pool. That allows any organization — not just participants — to see what is useful, or perhaps not useful, for others in their industry and across all verticals. It also shows what activities are the most common and which ones are evidence that an organization’s SSI is maturing.
For that reason, it has also been called a measuring stick for software security.
Cheaper and faster
The overall focus of the BSIMM is right in its name. From the start, 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.
The Systems Sciences Institute at IBM reported several years ago that it cost six times more to fix a bug found during implementation (at the end) than to fix one found during design (the beginning). 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.
Meanwhile, there has been an exponential increase in software deployments over the past decade, from once every week, month, or quarter to thousands per day at larger organizations. Facebook, on the Android platform alone, has between 50,000 and 60,000 software builds each day. Amazon reportedly deploys new software to production every second. If you don’t have your calculator handy, that’s 86,400 every day.
That puts developers under enormous pressure to complete software projects more quickly, which makes them much less willing to fix defects at the end of the SDLC, when it takes so much more time and money.
So, no surprise, the pressure is now on SSGs to make sure software security testing keeps up with development. Sammy Migues, principal scientist at Synopsys and a coauthor of the BSIMM report from the beginning, said last year that the message from developers is, “We’d love to have security in our value streams if you don’t slow us down.”
And BSIMM12 documents the major ways that more mature organizations are working to meet that demand. They include:
A move from prescribers to partners
SSGs are shifting from mandating software security behaviors to becoming partners with developers — providing resources, staff, and knowledge to DevOps practices to contribute directly to security efforts.
Those efforts include significant increases in the use of application containers and orchestration (configuring code to orchestrate “the right test at the right time”) to support security goals.
Code as regulator
The previous two BSIMM reports documented a move from manual, human-driven (and much slower) governance of software testing to automation. BSIMM12 observations show the expansion of that trend. Instead of the security team issuing directives, those directives or policy requirements are automated through code that ensures that the only way developers are allowed to do something is the secure way.
As Migues once described it, “You don’t let the kids build a campfire in every room of the house if they want to cook a hot dog. They have to use the stove— the safe way.”
Constant defect discovery
BSIMM12 data indicate that more firms are using continuous monitoring and reporting rather than point-in-time defect discovery. That initially requires additional human effort, which may explain the observed growth in satellites (a group, sometimes also called security champions, organized and leveraged by an SSG).
Jacob Ewers, associate managing consultant with the Synopsys Software Integrity Group and a coauthor of BSIMM12, said those specific trends reflect one of the more significant overall trends — the move from manual to automation.
“The heavy, manual, lock-step processes that were the backbone of SSIs are being decomposed into smaller, faster gates deployed across the life cycle,” he said. “We see PII [personally identifiable information] obligations that used to involve time-consuming inspection and review being managed in code. It is encouraging to see the transformation of activities to solve problems rapidly and at scale.”
Finally, the BSIMM offers several recommendations that, once again, are aimed at helping each organization figure out how best to improve its security. They include:
- Use security testing telemetry whenever possible. Gather data on what testing was performed and what problems were discovered to help improve your software development lifecycle or governance processes.
- Automate! Governance-as-code will move security practices and compliance from manual to automated, which is more consistent, repeatable, and faster.
- Create a comprehensive software inventory, also known as a software Bill of Materials, including open source and third-party code. In its 2020 Magic Quadrant for Application Security Testing, Gartner predicted that “by 2024, the provision of a detailed, regularly updated software Bill of Materials by software vendors will be a non-negotiable requirement for at least half of enterprise software buyers, up from less than 5% in 2019.”
None of this will happen overnight, of course. Building trust in your software is a journey, not an event. But the BSIMM can get you started on that journey and help get you to the destination faster.