Cloud costs
October 18, 2019
min read

BSIMM10 Study: The Impact of DevOps on Software Security


How do engineering-led security cultures work in practice? Has DevOps culture changed what security does, how it’s done—or both? As an industry, are we getting any better at this?

As co-author of the tenth Building Security in Maturity Model (BSIMM10) study, we set out to answer these and other questions related to how organizations are executing their software initiatives using concrete data pulled from more than 120 recognizable organizations — including Aetna, General Electric, The Home Depot, and Wells Fargo.

The BSIMM study provides a framework for companies seeking to mature their security programs using best-in-class firms as a point of reference. By looking at how those on the front end of security are attacking their problems, BSIMM provides actionable recommendations for others to follow.

This year, one of the most important themes we’ve seen arise — both through the BSIMM data and other research, such as from Gartner — is an increased interest in engineering-led efforts. Put simply, an engineering-led security culture is one of the capabilities associated with an organization’s security initiative, conceived and implemented by folks within the engineering organization rather than a central and separate security team. In other words, engineering and development drive security for the products they develop.

Engineering-led cultures also help drive product-centric models, rather than centralized governance-centric, which has been the norm. Here, again, it’s about moving control to those that are closest to the product itself: engineering and development. This is a significant change from the historical operating model where a central security team pushes requirements and policies to engineering without necessarily having a strong understanding of the product and the customer.

A recent Gartner survey reported that 85% of firms have either adopted (or plan to adopt) a “product-centric” application delivery model. The survey also reports that this model was used for 40% of their work in 2018. Gartner’s Bill Swanton indicated this finding goes hand in hand with the adoption of a more agile DevOps culture. BSIMM10 concludes that engineering-led security initiatives are gaining traction and can be effective, something the survey didn’t observe in prior years. Based on the data we’ve seen, security is getting closer and closer to the front end of product development. Firms can no longer afford to ignore this trend.

Engineering-led security initiatives are changing their firm’s risk management paradigm, from proactive governance through security assurance to resilient delivery pipelines that rapidly respond to continuous security telemetry. They aren’t just “trying something new” in one or two teams. Rather, using techniques at scale across their software and infrastructure portfolios. They’re continuing those behaviors year on year.

This shift to engineering-led efforts is having a material impact on how organizations prioritize security activities. This year’s BSIMM study spells this out, as firms are now focusing more effort on security initiatives that are central to development, such as:

  • Monitor automated asset creation (AM3.3)
  • Automated verification of operational infrastructure security (CMVM3.5)
  • Integrate SW-defined lifecycle governance (SM3.4)

In plain terms, we find firms are:

  • Attempting to get a handle on their attack surface and inventory, particularly in terms of where their responsibilities are increased by self-service IT in the cloud
  • Reducing effort by driving automated compliance to infrastructure security standards
  • Automating as much of the vulnerability discovery process as possible to make risk decisions in real time

In summary, engineering-led security cultures deliver more of their efforts as code and automation, rather than as policy/process documentation. This includes things like organization-specific SAST rules in the build rather than coding standard documents, security features, the enablement of services rather than remediation advice, and so forth.

So, we are getting better at this, and automation is key to that. But with automation comes its own risks. We can’t avoid the “think” steps intrinsic to building and maturing a security initiative with risk-based controls tuned to an organization’s tolerances and to the particular exposure business applications represent. Threat modeling, and other techniques, also work best when driven by humans in a thoughtful risk-based way.

The bottom-line is, as organizations seek to differentiate themselves and operate in a software-centric delivery model, engineering-led cultures will be enablers. I encourage security practitioners to take a few minutes to read the BSIMM study and consider which of these recommendations might be beneficial, now or in the future.

Sign up now

Sign up for our free plan, start building and deploying with Harness, take your software delivery to the next level.

Get a demo

Sign up for a free 14 day trial and take your software development to the next level


Learn intelligent software delivery at your own pace. Step-by-step tutorials, videos, and reference docs to help you deliver customer happiness.

Case studies

Learn intelligent software delivery at your own pace. Step-by-step tutorials, videos, and reference docs to help you deliver customer happiness.

We want to hear from you

Enjoyed reading this blog post or have questions or feedback?
Share your thoughts by creating a new topic in the Harness community forum.

Sign up for our monthly newsletter

Subscribe to our newsletter to receive the latest Harness content in your inbox every month.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.