This year’s BSIMM report included findings from 130 organisations, spanning several verticals and geographies, and highlighted four key activity trends.
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 this vast, interconnected web is to read the latest Building Security in Maturity Model (BSIMM) report
The BSIMM, now in its 11th iteration (BSIMM11), tracks the evolution of software security programmes through yearly observations and data collection from a growing number of companies. This year’s report highlighted four key activity trends, as follows:
Governance as code
Automation is not new, and previous BSIMMs have documented that organisations have been successfully replacing manual governance activities with automated solutions for some time.
One reason for this is the need for speed, otherwise known as feature velocity. Organisations are doing away with the high-friction security activities conducted by security teams out-of-band and at gates. In their place is software-defined lifecycle governance.
Another reason is staff 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 organisations are addressing both skills shortage and time management problems.
Continuous defect discovery
Established trends such as continuous integration and testing have rendered the governance checkpoint, or a gate relying on data from a point-in-time scan, obsolete.
BSIMM11 documents that organisations 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.
Continuous activity: shift everywhere
Organisations can no longer perform all traditional application security (AppSec) activities in compartmentalised phases. Instead, security activities are being expanded across all phases of the software development lifecycle (SDLC) as a continuous effort. 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 means “shifting left” – to the beginning of the SDLC. But in other cases, it will mean shifting to the middle or to the right.
Security as resilience and quality
In some organisations, security is becoming part of quality, which is becoming part of reliability, which is becoming part of resilience – the operational goal for many development groups.
This trend has been building for a while. Previous BSIMMs have observed that organisations have been dramatically improving their quality assurance practices over the past several years.
Paired with this effort is the adoption of resilience practices, most prevalently in development-led initiatives. Software security activities are integral parts of both quality assurance and resilience. Many security testing activities, such as static application security testing (SAST) and software composition analysis (SCA), fit naturally into quality assurance practices.
But development groups are making it clear that they want security testing tools that run invisibly and in cadence in their toolchains. In some cases, free and open-source tools are deemed better than commercial tools, which can 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 development teams that have moved on.