#161: State of DevOps 2022

This episode, I wanted to take a quick look at the 2022 edition of the State of DevOps Report.

I've talked a number of times about the State of DevOps report. I originally introduced it back in episode 13, and last year I devoted seven episodes, 120-126, to a deep-dive into the 2021 edition.

Or listen at:

Published: Wed, 18 Jan 2023 16:16:53 GMT

Links

Transcript

Hi. This episode, I wanted to take a quick look at the 2022 edition of the State of DevOps Report.

I've talked a number of times about the State of DevOps report. I originally introduced it back in episode 13, and last year I devoted seven episodes, 120-126, to a deep-dive into the 2021 edition.

If you've not listened to those episodes, let's do a quick recap on DevOps and the State of DevOps report.

Devops. I really like the Microsoft definition:

"A compound of development (Dev) and operations (Ops), DevOps is the union of people, process, and technology to continually provide value to customers."

It's a marriage of traditionally opposing forces, innovation and change from development and stability and limiting change from operations. It's focussed on the business outcomes that needs a mix of the two disciplines.

The State of DevOps report is now in its eighth year of reporting on over 33,000 professionals worldwide. Produced by the DORA team (DevOps Research and Assessment), it is the longest running academic, rigorous research investigation of its kind. It provides clear evidence on the benefits of DevOps and its practices. For me, it helps to justify the why of investing time and effort in the DevOps. But even if you're not using DevOps, many of these practices are universal. So even if you're not officially doing DevOps, they can provide benefit.

The report is available from Google for the price of your contact details. And as always, I recommend taking the time to download and review. I'll include a link in the show notes.

Given how much of a deep dive I did last year, I'm only going to talk about the report's focus on Security in the Supply Chain.

In the last report, 2021, the importance of Security within the Software Supply Chain was highlighted.

This year, there has been enhanced focus on it, with specific questions being put to responders to really understand how organisations feel and are reacting to the risk.

I talked about Supply Chain Security in episode 110, but as a brief recap, Supply Chain Security aims to protect all supply routes into an organisation, a growing favourite with attackers. This is nothing new. Attacking an army supply route is generally considered a better tactic than squaring up with their armed forces face-to-face.

In recent years, however, it seems to have gained popularity with cyber-criminals and gangs. As organisations have made their boundaries better protected, the attacker's effort shifts to the unprotected supply chain, potentially using them like Trojan horses to sneak in past the defenders.

This was highlighted by the SolarWinds breach in December 2020. Attackers gained access to SolarWinds, then used their trusted access to gain further access into many of their customers. Very much the Trojan Horse on an automated scale.

While a few years ago, Supply Chain wouldn't have been high on many people's priority lists, however, since some very high profile attacks, such as the SolarWinds breach, it is now one of the major topics in security - if not at the board or even stakeholder level.

And as such, this year, the survey features a series of questions regarding Supply Chain Security. From the report:

"we focus on two initiatives: Supply Chain Levels for Software Artifacts (SLSA, pronounced "salsa"), and the NIST Secure Software Development Framework (SSDF). Each offers a range of defensive measures to make sure that attackers can't tamper with software production processes and sail past network defenders via malicious software updates.

But how widely used are the software supply chain security practices associated with SLSA and SSDF? Which practices need help driving adoption, and which are already in widespread use? To date, there were no systematic answers to these questions. By surveying hundreds of software professionals about their use of practices associated with supply chain security, we provide some early answers."

The report cites four key findings from this work:

  1. Adoption has already begun - organisations have already started to take actions and strategies recognised by SLSA and SSDF.
  2. Healthier cultures have a head start - organisations with high trust blameless cultures appear to be doing much better than their counterparts.
  3. There's a key integration point - and that is the automation process, like continuous integration.
  4. It provides unexpected benefits - the report highlights a correlation with low team burnout.

The report actually found that 81% of respondents agreed with this statement:

"We have ongoing efforts to monitor information coming from public sources regarding possible vulnerabilities in the software we use and its third party components"

Which I have to admit to being happily surprised by. Many more organisations are actively doing something about the risk rather than just talking about it. And that is really good to see.

Also, interestingly, the report found only minor effects on Software Delivery performance when adopting the additional security practices. This is useful evidence for situations where security practices are being held off for fear of productivity grinding to a halt.

This finding doesn't surprise me. I would expect any environment with the maturity to be performing security testing, to also have the maturity to automate much of the process, greatly reducing any friction to the development team and thus any opposition to its adoption when developer time is finite.

Software developers would generally want to do the right thing. Thus, we should be removing barriers to doing that and making it easy - rather than it being a priority decision against the latest greatest feature or hitting a project deadline.

If anything, the report draws a correlation between the positive effects of security work relying on the capabilities of automation practices like continuous integration. Again, supporting the theory that if you make it easy and frictionless, then it will get done.

The only other insight I wanted to pull from the report was its drivers of Organisational Performance.

Besides security. The report found the following predictors to be key to Organisational Performance:

  • A high trust, low blame culture, that generative culture, as described by the Western organisation Culture Topology, which I discussed in episode 125
  • Focus on reliability, such as the Site Reliability Engineering practice I discussed in episode 126.
  • And the use of cloud, something that I introduced back in episode 9.

This is a similar message and consistent with the report when I reviewed it last year, so I'll provide links to some of those episodes that go into greater depth in the show notes.

Thank you for taking the time to listen to this episode. I look forward to speaking to you again next week.