In 2008, Synopsys embarked on a new mission to measure real-world software security practices. Insights were ascertained through in-person interviews with nine executives pioneering software security initiatives (SSIs) within their respective organizations. This year, over a decade later, the industry study and benchmarking tool, the ‘Building Security in Maturity Model (BSIMM)’, is now in its eleventh iteration and offers observations made from across 130 different companies in various industry verticals. During this time, two distinct security cultures became apparent within the community: one driven by corporate groups and the other by those in engineering leadership roles.
Yet, irrespective of their origins, SSIs have historically coalesced under the aegis of a single, committed software security group (SSG) in charge of implementing and maturing a firm’s software security practices. That is, nearly all SSIs today are governance-led, regardless of whether the SSI genesis was the executive team or the architecture team. SSGs practice proactive risk management through assurance-based activities, resulting in the creation of “rules that people must follow” and “expectations software must meet” (e.g., policy, standards, checkpoints, sensors). This has almost always resulted in a defined process that includes prescriptive testing at various times in the lifecycle and checkpoints where engineering processes might be derailed.
The limits of a governance-led culture
While centralized governance approaches have worked well enough in the past for some firms, the demands on modern software cycles have since evolved considerably, requiring security cultures to adapt alongside. Notably, the convergence of software development and operations, or DevOps, as well as Agile practices have significantly increased delivery cadence to the point some firms are able to deliver new features in in just a matter of days and in some cases hours. As modern organizations endeavor to meet market pressure, this is a welcome advancement. Unfortunately, it is one that centralized governance approaches often struggles to keep up with effectively.
Depending only on ‘point-in-time’ techniques to run tests can introduce friction in addition to unpredictable set-backs to delivery schedules when defects surface and teams are brought back to the drawing table. Moreover, the human-intensive processes that exist within this traditional model leaves substantial room for human error.
The engineering movement
It is no wonder then that of late, engineering teams have emerged to address these concerns. Indeed, the BSIMM11 study has witnessed this change, seeing a rising number of SSIs report through technology groups or to the Chief Technology Officer (CTO); 20 and 21 of the 130 companies, respectively. These same organizations have also seen a transformation of internal talent, with many teams now recruiting experts of cloud and orchestration security to be champions in their DevOps or DevSecOps programs. In this way, facilitating a synergy between the security and development teams. The goal, now, is to achieve secure application functionality throughout the value stream in the aim of greater software resiliency.
The gradual shift towards an engineering-led approach is materialized in a number of emerging activity trends. The most pertinent of which is the substitution of human-intensive processes with automation. To put it differently, rather than having to manually assess technologies for adherence to policies, activities are now codified and automatically monitored helping to speed up security to match the cadence of the software delivery process.
Nevertheless, it is important to note that despite greater automation, many organizations maintain human-readability of its security standards and policies. BSIMM11 has seen this condition as being fundamental to the success and effectiveness of security initiatives. As Peter Drucker once said about metrics, “you can’t manage what you can’t measure,” with governance, “you can’t automate what you can’t understand.”
With this rise in automation and the alignment of security with DevOps culture, CI/CD instrumentation and orchestration has progressively become the new norm. BSIMM11 has captured this too in the extension of activities in implementing event-driven security testing and publishing risk data for deployable artifacts. In other words, organizations are now recognizing the achievability of a swift and software-defined approach to software security. More recently, this approach has expanded to defect discovery tools and usage.
In fact, more firms in this year’s report are implementing modern defect discovery tools, both open source and commercial, and favor continuous reporting as well as remediation. There has been a paradigm shift in understanding away from the idealistic belief that software can eventually be deployed with little to no vulnerabilities, to the realistic acceptance that security defects will likely and consistently crop up. By sanctioning a continuous detect-plan-respond loop, some organizations are realizing they can achieve low-latency and software resilience.
The oversimplification of ‘Shift Left’
Security activities can no longer be compartmentalized into distinct phases but must ‘shift everywhere’ to where the software asset resides. Fortunately, it seems organizations are beginning to adopt this philosophy as ‘continuous activity’ becomes a growing trend.
Of course, all these steps may easily be understood to fall under the wider phenomenon of ‘shift left’, or the implementation of security into the early stages of software development. While there is some truth to the statement, the industry has generally oversimplified the concept.
The idea of ‘shift left’ was not to encourage the application of security testing at the earliest stage possible but to fortify a more comprehensive approach. In addition to conducting tests early, there should also be tests at every phase throughout the software lifecycle - not just in the beginning. As soon as the relevant artifact or process is available, the activity should be immediately conducted. This could be to the left, but also further right in the software lifecycle when delivery artifacts are instantiated at runtime (e.g. containerized environments).
A balance between governance and engineering driven approaches
The infusion of engineering-led initiatives has no doubt facilitated a more efficient means of securing software as security activities have become self-service and software-defined. However, organizations should endeavor to find an appropriate balance with governance-led strategies as both routes bring their own sets of strengths as well as weaknesses in securing software at development speed and enterprise scale. By converging the two and collaborating on “governance as code” techniques, organizations may just bring to fruition the optimal solution for their own unique software security journey.
Mike Ware, BSIMM11 Co-Author and Senior Director of Technology, Synopsys