It’s time for engineering teams to own DevSecOps

The biggest factor impacting the evolution of application security is the speed at which technology changes. Much of this is due to widespread consumerisation – people expect new technologies and updates to become available rapidly because they expect a seamless consumer experience.

This trend, combined with the broader introduction of software-as-a-service (SaaS), has led to quick, iterative development cycles in which changes are made to software weekly, daily, and even hourly. Traditional application security practices can’t keep up with the pace. This is where DevSecOps comes in.

DevSecOps is a mindset and way of working within the application security field in which security is a part of everyone’s job, not just one team. It helps security scale at the same rate of change as new development cycles while elevating the importance of security to that of more traditional business success metrics, such as product availability or quality.

However, companies have historically struggled to implement DevSecOps within their organisations. One of the most persistent barriers is that it can be a big cultural shift for technology teams and often involves a change in tooling. But when done right, DevSecOps can have a significant impact on strengthening application security. And while it may seem counterintuitive, the best strategy is to make DevSecOps the responsibility of engineering – not security.

What makes DevSecOps so hard to adopt?

Recent cyber security incidents such as Log4j and SolarWinds showed executive leadership teams that they can no longer afford to keep security in a silo. Instead, they must make it foundational to the company’s strategy from the boardroom to the software development centre.

Overnight, the Log4j flaw became an issue for thousands of companies using the Log4j open source logging framework in their software. Although the vulnerability was patched before threat actors could cause major damage, it exposed how much is still unknown about the many pieces of software that are part of a wide range of systems.

And although the SolarWinds attack affected supply chains, it points to a similar visibility issue: too many companies don’t fully understand the scope of their software operations or how their code impacts their overall threat profile, providing opportunity for cyber criminals to target back-end infrastructure tools and other unmonitored vulnerabilities.

DevSecOps can be difficult to implement because it involves a mindset shift for security teams, engineers and developers. Code scanning – one common approach implemented as part of DevSecOps – can often flag false positives. This, in turn, creates unnecessary work for developers and can lead to them not wanting to follow the proper security procedures for checking in their code.

Meanwhile, security teams often struggle with a perceived loss of control. Companies need to find a better mechanism for integrating automation with human expertise to embed security within the development process without slowing operations or minimising the company’s overall security posture.

How can companies implement DevSecOps?

Implementing DevSecOps starts with understanding the company culture and how developers operate. Because of their current incentive structure, many engineering teams focus on facilitating product availability and quality, but security also directly impacts these business metrics. When companies limit security to the security team and delegate all other development work to engineering, they miss out on the opportunity to facilitate truly productive collaboration.

If organisations want their developers to bake security into their everyday work, they first need to understand their developers’ processes, pain points and motivations. Answering these questions can help teams better integrate security into the DevOps process to work for their developers, not against them.

It also points to why DevSecOps need to become the responsibility of the engineering team. Ensuring that engineering has a voice in the DevSecOps process gives them a sense of ownership over security and allows them to choose the tools that will perform best within their specific environment.

Putting accountability within engineering is the key shift to adopting a DevSecOps mindset.

What’s next?

The speed at which technology evolves will only continue to accelerate. As a result, organisations must prioritise visibility into application security to keep up with these changes.

The volume is already increasing around how companies can improve their visibility to understand where to deploy resources to strengthen their security posture – and that volume will only amplify over time. Is a software bill of materials (SBOM) the answer? If so, what is the best way for that SBOM to be created and published?

Ultimately, application security is about doing what is right for customers. If companies are creating and releasing unsecured products, it harms their business reputation and customers. DevSecOps embeds security into the core of business success so that companies can do right by their end-users and themselves. To increase the adoption of DevSecOps across an organisation, companies should put the security onus on the teams that build their solutions.

Mandy Andress is chief information security officer at Elastic, an enterprise search company, and has more than 25 years’ experience in information risk management and security.