Measure and improve your software security initiative using the four key market activity trends observed in the new BSIMM11 report.

If you want to stay current, you have to keep up with what’s trending, no matter if it’s politics, healthcare, education, finance, or entertainment.

Or software security, which in a connected world is behind everything on that list above. Software isn’t just important, it’s essential. The world as we know it wouldn’t function or even exist without it. And the best way to know what’s trending in that vast web of what connects everything is to read the latest Building Security In Maturity Model (BSIMM) report.

The BSIMM, described in an annual report now in its 11^th iteration, tracks the evolution of software security initiatives (SSIs) through observations and data collection from a growing number of companies each year. This year there are 130, primarily in nine verticals including financial services, FinTech, independent software vendors (ISVs), cloud, healthcare, Internet of Things, insurance, and retail. The participants span multiple geographies.

The BSIMM is both a roadmap and a measuring stick for organizations seeking to create or improve their SSIs, not by prescribing a set way to do things but by showing what others are already doing. The best way for companies to determine what’s relevant is to look at what’s happening in their own industry sector.

The report goes into exhaustive detail, which you can read for free here. It’s available to the public under the Creative Commons Attribution-ShareAlike 3.0 license.

You can also read a much shorter primer that provides the highlights of this year’s report.

Download BSIMM11 Digest: The CISO’s Guide to Modern AppSec eBook

This post explores several major trends the BSIMM11 highlights, that we’ll call “market activity.”

What are market activity trends?

First, it’s important to note what market activity trends are not. They aren’t broad market trends that are covered elsewhere in the report. These market trends point to specific smaller actions within larger processes in an SSI. Organizations will likely find it useful to compare them with their own SSIs.

BSIMM11 includes four key market trends.

1. Governance as code

This is not brand new. Previous BSIMMs documented that organizations have been successfully replacing manual governance activities with automated solutions.

One reason for this is the need for speed, otherwise known as feature velocity. Organizations are doing away with the high-friction security activities conducted by the software security group (SSG) out-of-band and at gates. In their place is software-defined lifecycle governance.

Another reason is a people shortage—the “skills gap” has been a factor in the industry for years and continues to grow. Assigning repetitive analysis and procedural tasks to bots, sensors, and other automated tools makes practical sense and is increasingly the way organizations are addressing both that shortage and time management problems.

But while the shift to automation has increased velocity and fluidity across verticals, the BSIMM found that it hasn’t put the control of security standards and policy out of the reach of humans.

That’s because even with automation, a security policy must remain accessible and understandable for an SSI to be effective. And with an increase in engineering-led security teams, engineering and operations groups need to and often do make self-service modifications to policies or add new policies along the way. A successful SSI must provide both the ability for self-service modifications and automated detection of drifts in the policy.

2. Continuous defect discovery

Established trends like continuous integration and testing have rendered the governance checkpoint, or a gate relying on data from a point-in-time scan, obsolete. As BSIMM co-author John Steven put it in a post a year ago, the security gate method meant “create code, stop, test it; compile code, stop, test it; then deploy code (to staging), stop, test it.” That’s no longer compatible with a continuous delivery environment.

BSIMM11 documents that organizations are implementing modern defect-discovery tools, both open source and commercial, and favoring monitoring and continuous reporting approaches. This means defect discovery is no longer slowing development; the focus is on creating resiliency through low-latency and continuous detection loops.

3. Continuous activity: Shift everywhere

Organizations can no longer perform all traditional SDLC security activities in compartmentalized SDLC phases. Instead, security activities are being expanded across all phases as a continuous effort. This is what the BSIMM authors mean when they say that “shift left,” a term they coined more than a decade ago, was never meant to be taken as shift only left, but instead to shift everywhere. That means conducting a security activity as quickly as possible, with the highest fidelity, as soon as the artifacts on which that activity depends are available. In some cases that does mean shift left—to the beginning of the SDLC. But in other cases, it will mean the middle or to the right.

4. Security as resilience and quality

BSIMM11 notes that in some organizations, security is becoming part of quality, which is becoming part of reliability, which is becoming part of resilience—the operational goal for many engineering groups.

This trend has been building for a while. Previous BSIMMs have observed that organizations have been dramatically improving their quality assurance practices over the past several years.

BSIMM11 found that this is still true. Organizations are being more proactive in their efforts to build reliable software by adding activities to the development lifecycle.

Paired with this effort is the adoption of resilience practices, most prevalently in engineering-led initiatives. Software security activities are integral parts of both quality assurance and resilience. Many security testing activities, like SAST and SCA, fit naturally into quality assurance practices.

But engineering groups are making it clear that they want security testing tools that run in cadence and invisibly in their toolchains. In some cases, free and open source tools are currently more valuable in those groups’ processes and culture than more-thorough commercial tools that contribute, or appear to contribute, more friction than value.

That means 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.

Download BSIMM11 Digest: The CISO’s Guide to Modern AppSec eBook