Shift Everywhere When it Comes to Software Security Initiatives

Shift Everywhere With Software Security Initiatives

October 1, 2020

Synopsys Software Security Expert Taylor Armerding unpacks the highlights from this year’s BSIMM11 report and examines best practices across all security verticals.

By Taylor Armerding

BSIMM11 gathers research on software security activities from real-life firms to create a guide to help you navigate your software security initiative.

The Building Security In Maturity Model (BSIMM) — the annual report on the evolution of software security initiatives (SSIs) — is gaining some maturity itself. The latest report, which went public in September, is the 11th iteration.

Some things haven’t changed. The fundamental goal remains what it was at the start, more than a decade ago. As the authors frequently put it, this “science experiment that escaped the lab” is designed to help organisations navigate the often-treacherous path of developing an effective SSI and provide a free tool they can use to measure an SSI once it’s created.

But to achieve that goal, the BSIMM team has to assimilate and understand a lot of change, and that gets harder each year. So the BSIMM has grown up considerably. From an initial pool of just nine organisations and 110 activities in 2009, it has now tracked the evolution of software security through detailed observations of 211 organisations in multiple verticals and includes 121 observed activities.

In doing so, it established a reputation as the best available tool to measure software security initiatives, but not by prescribing a set way to do things. The BSIMM is primarily a “what’s happening now” guide. This year’s report is based on observations of 130 participating companies, primarily in nine verticals and spanning multiple geographies.

That’s up from 122 participants, primarily in eight verticals, last year. And the change is more significant than simply adding eight firms — there were 27 added and 19 removed to keep the data pool fresh.

The BSIMM examines activities on which organisations are actually spending time and money. This real-world view — actual practices as opposed to someone’s idea of best practices — is reflected in the descriptions written for each of the 121 software security control activities included in the BSIMM11. It also directs the addition of new activities reliably observed in organisations.

By now, you should have heard of the BSIMM, especially if you are involved in software security. Maybe you’ve even downloaded a copy — it’s always been free and open. Under the Creative Commons Attribution-ShareAlike 3.0 license, data is published publicly each year, and many organisations use the BSIMM internally.

Key Takeaways

Since the BSIMM is completely data-driven, this report is different from any you might have read in the past. That’s because the world of software security evolves. The changes in BSIMM11 reflect that evolution.

New software security activities

BSIMM10 added new activities to reflect the reality that some organisations were working on ways to speed up security to match the speed with which the business delivers functionality to market. To those, BSIMM11 adds activities for implementing event-driven security testing and publishing risk data for deployable artifacts. Those directly reflect the ongoing DevOps and DevSecOps evolution and its intersection with traditional software security groups.

A new definition

A key BSIMM term — software security group (SSG) — has been refined to acknowledge an evolution in software security leadership. Rather than implying that the group is always centralised in corporate, the definition now specifically acknowledges that it might be a federated collection of people in corporate, engineering, and perhaps elsewhere. Indeed, this year’s report observed that organisations with governance-led security efforts and engineering-led security efforts are equally able to use the BSIMM to improve their capabilities.
A new vertical: For the first time, the BSIMM includes the financial technology vertical — independent software vendors (ISVs) that make software specifically for the financial services firms — as a separate group.

Don’t just shift left: Shift everywhere

When Cigital began writing about the concept of shifting left around 2006, it was addressing a niche audience. But the term rapidly became a mantra for product vendors and at security conferences, dominating presentations and panel discussions. At the February 2020 RSA conference in San Francisco, you couldn’t get through any of the sessions in the DevSecOps Days track without hearing it multiple times.

And the point is an important one. According to Synopsys Principal Scientist and co-author of the BSIMM Sammy Migues says don’t wait until the end of the SDLC to start looking for security vulnerabilities. The concept was never meant to be taken literally, as in only shift left –

“What we really meant is more accurately described as shift everywhere, to conduct an activity as quickly as possible, with the highest fidelity, as soon as the artifacts on which that activity depends are made available. For example, do DAST as soon as you have running code, and do configuration reviews as soon as you have defined or running environments, and collect composition analysis events from production agents that show dependencies dynamically incorporated into running systems as soon as you have deployed code. Sometimes, that’s to the left of where you’re doing some things today, but often it’s to the right, maybe all the way out in production,” says Migues.

Engineering demands security at speed

Perhaps you could call it the democratisation of security — making the means for success available to everyone. In some organisations tracked in the BSIMM, there is only a small centralised software security group focused primarily on governance. However, in a growing number of cases, engineering teams perform many of the software security efforts, with people responsible for CloudSec, ContainerSec, DeploymentSec, ConfigSec, SecTools, OpsSec, and so on.

That is yielding mixed results. Being agile, those teams can perform those activities quickly, which is good, but it can be too fast for management teams to assess the impact on organisational risk. Not so good. Very few organisations have completely harmonised centralised governance software security efforts and engineering software security efforts into a cohesive, explainable, defensible risk management program.

Still, engineering groups are making it clear that feature velocity is a priority. That means security testing tools that run in cadence and invisibly in their toolchains — even free and open source tools — likely have more value today than more thorough commercial tools that create, or appear to create, more friction than benefit. The message: We’d love to have security in our value streams — if you don’t slow us down.

Finally, in some organisations, security is becoming part of quality, which is becoming part of reliability, which is becoming part of resilience, which is becoming the operational goal for many engineering groups.

“Software security leaders who speak only the language of ‘penetrate and patch’ will soon be ‘patched’ out of the value stream by engineering teams that have moved on,” says Migues.

Champions as code

Traditional software security champions — security advocates from within or assigned to development teams — tended to function on a more personal level: brown bags, person-to-person conversation, email, spreadsheets, dashboards, and an occasional public call out of recalcitrant teams.

That is morphing into champions contributing security knowledge directly as code, in the form of toolchain sensors to determine software’s adherence to expectations (e.g., library use, lack of a certain defect, coding standards), pre-approved configurations and configuration checkers (e.g., for containers), reusable security libraries, and so on.

They are establishing “structural” security, so to speak. If developers write their code within a secure structure, they will build more secure software.

The Cloud: Division of responsibility

The advantages of moving to the cloud are heavily promoted, and therefore well known. It’s cheaper, it makes collaboration of a dispersed workforce easier, and it increases mobility — team members can work from anywhere, which is practically mandatory during an extended pandemic.

But using the cloud effectively also means outsourcing to the cloud vendor at least parts of your security architecture, feature provisioning, and other software security practice areas that are traditionally done locally.

And as noted in the BSIMM, “cloud providers are 100% responsible for providing security software for organisations to use, but the organisations are 100% responsible for software security. Organisations that weren’t doing software security well in their private data centers are likely not doing software security well in the cloud either”.

Digital transformation: Everybody’s doing it

Digital transformation efforts are pervasive, and the reality is that software security is a key element of it at every level of an organisation. At the executive (SSI) level, the organisation must move its technology stacks, processes, and people toward an automate-first strategy. At the SSG level, the team must reduce analog debt, replacing documents and spreadsheets with governance as code.

At the engineering level, teams must integrate intelligence into their tooling, toolchains, environments, software, and everywhere else.

Beyond those highlights, foundational software security activities are simultaneously getting easier and harder. Software inventory used to be an Excel spreadsheet with application names. It then became a (mostly out-of-date) configuration management database.

Now organisations need inventories of applications, APIs, micro-services, open source, containers, glue code, orchestration code, configurations, source code, binary code, running applications, and so on. Automation helps but there are an enormous number of moving parts.

As Migues argues, “Threat modeling is also getting easier to federate and harder to know when to do it. Patching is getting easier in some cases (one container vs. 100 applications) and harder in some cases; knowing who owns all the stuff that comprises the CI/CD toolchains, glue code, homegrown tools, and so on”.

There are other large trends in the industry that deserve attention. “In particular, and anecdotally, the current world and political climate has caused significant changes in software security process, technology, and resourcing,” says Migues.

According to Migues, one example is the significant slowdown in hiring in many organisations, and a mandate to get both this year’s and next year’s goals done with the existing staff and technology.

“Primarily, we see this implemented as a significant acceleration in process automation, in applying some manner of intelligence through sensors to prevent people from becoming process blockers, and in the start of a cultural acceptance that going faster means that not everything (all desired security testing) can be done in-band of the delivery lifecycle,” says Migues.

There is more — much more — detail in BSIMM11, which reports in depth on activities grouped under 12 practices that are, in turn, grouped under four domains: governance, intelligence, secure software development life cycle (SSDL) touch points, and deployment.

The activities show what participating organisations are doing and the types of tools they are 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 organisation — 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.

In addition to helping an organisation start an SSI, the BSIMM also gives them a way to evaluate the maturity of their SSI, from “emerging,” or just starting; to “maturing,” meaning up and running, including some executive support and expectations; to “optimising,” which describes organisations that are fine-tuning their existing security capabilities to match their risk appetite and right-size their investment for the desired posture.

Wherever organisations are on that journey, the BSIMM provides a roadmap to help them reach their goals.

(Ed. Featured image by Pixabay. To access the full report, click here.)

Facebooktwitterredditlinkedin

Leave a Reply

Your email address will not be published. Required fields are marked *