Enterprises embrace devsecops practices against supply chain attacks

For enterprise security professionals alarmed about the rising number of supply chain attacks, a report released this week by Google and supply chain security firm Chainguard has good news: Devsecops best practices are becoming more and more common.

The recent prevalence of supply chain attacks—most notably the SolarWinds attack, which affected numerous large companies in 2021—has brought the topic into  prominence. The Google-Chainguard report, though, found that many supply chain security practices recommended by the major frameworks are already in place among software developers, based on an ongoing “snowball” survey of 33,000 such developers over the past eight years.

There are two major frameworks for addressing software supply chain development issues, which are those that stem from the complex nature of modern software development—many projects include open source components, licensed libraries, and contributions from numerous developers and various third parties.

Two major security frameworks aim at supply chain attacks

One major security framework is Supply-chain Levels for Software Artifacts, a Google-backed standard, and the other is the NIST’s Secure Software Development Framework. Both enumerate a number of best practices for software development, including two-person review of software changes, protected source code platforms, and dependency tracking.

“The interesting thing is that a lot of these practices, according to the survey, are actually relatively established,” said John Speed Meyers, one of the report’s authors and a security data scientist at Chainguard. “A lot of the practices in there, 50% of the respondents said that they were established.”

The most common of those practices, according to Google user experience researcher Todd Kulesza—another author of the report—is CI/CD (continuous integration/continuous development), which is a method of rapidly delivering applications and updates by leveraging automation at different stages of development.

“It’s one of the key enablers for supply chain security,” he said.  “It’s a backstop – [developers] know that the same vulnerability scanners, et centera, are all going to be run against all their code.”

Moreover, the report found that a healthier culture in software development teams was a predictor of fewer security incidents and better software delivery. Higher-trust cultures—where developers felt comfortable reporting problems and confident that their reports would bring action – were much more likely to produce more secure software and retain good developers.

“Sometimes, cultural arguments can feel really fluffy,” said Speed Meyers. “What is nice about some of these … culture ideas is that they actually lead to concrete standards and practices.”

Kulesza echoed that emphasis on high-trust, collaborative culture in software working groups, which the report refers to as “generative” culture, as opposed to rules-based “bureaucratic” or power-focused cultures. He said that practices like after-action reports for development incidents and preset standards for work led to better outcomes across the board.

“One way to think about this is that if there is a security vulnerability that an engineer realizes has made it into production, you don’t want to be in an organization where that engineer worries about bringing that problem to light,” he said.