Your software can make or break you, which is why you need BSIMM
If you rely on software — and you do — you need BSIMM.
Here’s why. It’s not so much that “software is eating the world,” as venture capitalist, Mosaic creator and Netscape cofounder Marc Andreessen famously wrote in 2011. It’s more that all of us are now consuming — perhaps you could say figuratively eating — software.
It nourishes and sustains just about everything in our lives, both digital and physical. The list is practically endless — energy, finance, communication, entertainment, recreation, healthcare, education, utilities, transportation, appliances, home security, agriculture, and more — all run by software.
Hence the accurate cliché: Every business is a software business.
It’s also why it’s so important that — just as is the case with food — it doesn’t get poisoned. If the software running just about every element of your business, from the critical to the trivial, has vulnerabilities that a cybercriminal can exploit, that nourishment turns malignant. It could undermine your finances, gut your market share, put you in legal jeopardy, even threaten your survival.
And hence the need for BSIMM.
Yes, it’s a weird acronym, but it’s one worth memorizing. The Building Security in Maturity Model is the subject of an annual report, now in its 13th iteration, that helps organizations maximize the pleasure and minimize the pain of a world run by software.
Disclosure: I write for the Synopsys Software Integrity Group, which produces the BSIMM report. But I would write about it anyway. I’ve done so for more than a decade — long before I came to Synopsys.
The way it helps is by documenting how dozens of organizations in multiple industry sectors are improving their software security, which carries more weight than a lecture from a few experts (no matter how well-qualified) at a single cybersecurity company.
Even better, it doesn’t dictate exactly what you should do, either. It just tells you what those companies have done. The latest BSIMM report relies on more than 130 security practitioners in eight verticals explaining in detail (anonymously) their own software security initiatives (SSIs) — what’s working, what isn’t, what’s changing about risks and threats, and how they’re responding to those changes to build trust into their software.
Multiple routes, common destination
That’s why the BSIMM report describes itself as a free “roadmap” to help organizations improve the security of the software products they build, sell, and use — because there is no single, best route to better security. Indeed, the whole idea of a roadmap is to show multiple routes to a destination without dictating which one to take.
The destination is common to all, however, and can be reduced to a sentence or two: Build security into software so it can be trusted. Then do whatever is necessary to maintain that trust. As noted, while BSIMM doesn’t dictate the route any organization takes, it does do assessments that evaluate how an organization has progressed on its journey to that destination — security maturity.
Doing so takes time, money, and staff expertise, of course. The BSIMM report tracks more than 120 “activities” by its participating organizations, including the use of multiple automated testing tools to find defects during the software development life cycle (SDLC), meeting privacy obligations, complying with security standards, and tracking and securing the software component supply chain.
The need for all that should be obvious: Software risks are business risks — potentially existential risks. As daily headlines remind us, if hackers can exploit design flaws, bugs, and other defects in software, they can steal intellectual property, swipe the personal information of employees and customers, raid corporate bank accounts, undermine the physical security of a building, take down the operations of an organization with ransomware attacks, and more.
Also, cybercriminals are forever evolving and improving the ways they attack their targets. So defenses must evolve as well, which is why the BSIMM report is updated annually to reflect the trends in that evolution and the many details involved in building trust into software.
A prime example: One of the top trends noted in BSIMM13 is increased focus on the security of open source software and the software supply chain.
Just a few years ago those were fringe topics in the security community. Now they are top priorities in both the private and public sectors. They are key elements in President Biden’s May 2021 executive order on Improving the Nation’s Cyber Security and multiple federal guidance documents released since then in response to it.
They are top-of-mind for good reason. Third-party software — open source and commercial — is in just about every codebase and comprises the large majority of them, as documented by another Synopsys report, the “Open Source Security and Risk Analysis.”
And an encouraging trend noted by BSIMM13 is that 73% of cybersecurity professionals surveyed have increased their efforts to secure their supply chains. That means if you’re not doing that yet, you should get started.
One way to do so is to use an automated software composition analysis tool, which helps find open source components in a codebase, along with any known defects and licensing conflicts in those components.
Another is the creation and maintenance of a software Bill of Materials (SBOM), which identifies third-party software in codebases so an organization can respond quickly to any new disclosures of vulnerabilities in any of those components.
BSIMM13 found a 30% increase in organizations creating SBOMs, reflecting the increased awareness of software supply chain risks, not to mention the impending requirement (one of the mandates in the Biden EO) that any software products sold to federal agencies must come with an SBOM.
It also found there was a 50% increase in organizations demanding that software vendors meet those kinds of security standards.
Other trends observed in BSIMM13 include
- Moving from “shift left” to “shift everywhere.” While the “shift left” mantra, a term coined by BSIMM in its early years, was meant to encourage organizations to start their security testing earlier in the SDLC, it was never meant to be taken so literally as to mean shift only left. “What we really meant is 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 coauthor of the BSIMM report since it began. Put another way, it means doing the right test at the right time with the help of automated tools like Intelligent Orchestration, which can enable continuous defect discovery during the SDLC that would be impossible to do manually.
- Using smaller, automated checks within the SDLC. This is another element of “shift everywhere,” which helps developers find and fix defects when it takes the least time and money. The Open Web Application Security Project, citing the National Institute of Standards and Technology, IBM, and Gartner, reported several years ago that it can cost 30 to 60 times less to fix an application security vulnerability during the design phase (the beginning of the SDLC) than during production (the end). Talk about an obvious way to fight inflation.
- Learning from your mistakes. Even better than simply fixing software bugs is understanding how the bugs came to be, and then building in ways to prevent them. BSIMM13 found that 70% of participants are setting up what amounts to automated guardrails — policy-as-code that makes sure the only way to write code is the secure way.
- Increasing orchestration for container security. This refers to the use of automation and intelligent orchestration to monitor applications in containers for misconfiguration and noncompliance. BSIMM13 observed an increase of nearly 30% in the “use orchestration for containers and virtualized environments” activity.
Of course, if you’re going to get those and dozens of other tasks done, somebody (more likely a group of somebodies) has to be responsible for getting them done. Hence the need for a software security group (SSG), which can start as small as just one person but generally needs a team to succeed.
The BSIMM13 found that none of the 130 participant organizations had the exact same structure for its SSG, but they had several things in common, including that they are organized to provide software security services and set and verify adherence to policy, and they are structured around managing a team of experts doing software security work across development or engineering organizations.
Most SSGs also cultivate “security champions” — people who aren’t directly part of the security team but who have an interest in software security and are willing to promote it at the team level.
Champions can include developers who build the code, software architects, testers, operations teams, managers, and the executive team — even external vendors who are key links in securing the software supply chain.
The value of doing that is apparent in yet another trend — on average, firms with security champions score an average of 35% better in BSIMM assessments than those without one.
The overall message of every BSIMM report is that security maturity is a journey, not an event (yet another “roadmap” allusion). But the BSIMM participant community can help you start on that journey and get to the destination you want and need faster.
There’s no need to lay down some cash to start either. The complete report is free, available under the Creative Commons Attribution-Share Alike 3.0 License. A copy of this license is here.