Executives are overconfident about the sophistication of their DevSecOps automation

Organisations will fail if they rush to security automation without proceduralising earlier DevOps stages

Credit: ID 121088765 © Ravil Sayfullin | Dreamstime.com

Business executives are significantly more optimistic about their organisations’ adoption of DevOps and security-focused DevSecOps practices than development managers and team members, according to an extensive review that also highlights the need for a DevOps foundation before security response automation can even be considered.

Fully 57 percent of C-Suite executives responding to the Puppet State of DevOps Report 2018 said their organisation had automated incident responses, a capability that Puppet warns can only be effectively realised at stage 4 or 5 of the five-stage DevOps transition process.

Team managers and team members were far less optimistic, with just 38 percent and 29 percent, respectively, reporting that their incident responses were automated. Similarly, 54 percent of C-Suite executives said their organisation was automating the configuration of security policies – compared with just 38 percent of team members who said the same.

C-Suite executives were also more optimistic about the maturity of their processes for engaging with the security organisation: 64 percent said security teams are involved in technology design and deployment, while just 39 percent of team members said this was actually happening.

The disconnect is not necessarily a result of executive ignorance, the report warns, but may also be due to “upward communications [that] are often filtered and sanitised, contributing to C-suite optimism.”

Companies need to fight this disparity by using “mutually reinforcing pillars of automation and measurement” that provide an “objective measurement system” to share across the business, the report recommended – while noting that doing so in a meaningful way presents its own share of complexities.

Meaningful automation evolves over time, the report notes, as a self-feedback loop drives the development and refinement of “increasingly high-level abstractions that are more integrated with the rest of your systems. It becomes progressively easier to share automation and deployment patterns.”

Gartner recently included automated security scanning as one of its top ten recommended priorities for CISOs this year, recommending that businesses begin with an open-source software composition analysis, then integrate testing as a part of DevSecOps workflows. This process should be done within developers’ existing tools, and be built around a full application programming interface (API) stack to enable automation across platforms and maturity in security resilience.

Tools to support DevSecOps objectives have been seeing strong adoption, with Australia’s Secure Code Warrior recently securing multi million-dollar VC funding to support its move into the US market and the overall dynamic application security testing (DAST) market expected to grow exponentially in coming years.

Read more: How IoT is putting your home security at risk

Proactive adoption of such tools will help organisations progress upon their DevOps journey faster and sooner – but organisations need to do the groundwork first before they expect any real transformation around security automation.

Stages 0 through 3 of DevOps focus on normalisation, standardisation, and expansion of collaborative frameworks across organisational boundaries. It is only in Stage 4 that automation becomes possible, and in Stage 5 that automation is refined and institutionalised.

Trying to take that step too early is a recipe for disappointment, the Puppet report’s authors warn: “We have seen organisations start with Stage 4 automation [where tasks such as version control usage and automated security policy configurations are seen], without having been through normalisation, standardisation and expansion.”

“These organisations do not achieve success, and we believe it’s because they lack a foundation of collaboration and sharing across team boundaries. That sharing is critical to defining the problems an organisation faces and coming up with solutions that work for all teams.”

“Once you can repeatably deal with account configuration/removal, load balancer configuration changes, security patches and monitoring policy updates, you’re no longer being held back by infrastructure that lags behind changing business and application demands.”

Tags GartnerAPIDevops

Show Comments