Interview with Todd Kulesza, User Experience Researcher at Google and John Speed Meyers, Security Data Scientist at Chainguard, a software supply chain developer platform.
This year’s 2022 State of DevOps report by Google Cloud and DORA links a “high-trust, low-blame” culture to emerging security practices. It also correlates how effective security scanning in pre-deployment results in fewer vulnerabilities when code goes into production, and how higher retention and morale is found in companies that successfully integrate security into the CI/CD pipeline.
The 77-page report took input and data from more than 1,350 professionals worldwide, and provides an interface for researchers to visualize the correlations between culture, product development, management, burnout, and more. The annual report was started in 2014 by DevOps Research and Assessment (DORA), which later joined Google Cloud. It’s an academically rigorous research program that’s heard from over 33,000 respondents during the past eight years.
In this interview, the co-authors of the security section of the report, Todd Kulesza, and John Speed Meyers, go over the key findings and then explain how to improve key outcomes and accelerate innovation through a Google-proposed framework, Supply chain Levels for Software Artifacts (SLSA, pronounced “salsa”). John Speed is a security data scientist at Chainguard, which provides a developer platform focused on software supply chain security by default; and Todd is a user experience researcher at Google.
Q: What are the top indicators of successful software product development?
Todd: Being able to deploy on demand, having a lead time for changes measured in days rather than weeks or months, and a change failure rate that’s under fifteen percent. Also, the ability to restore service, ideally in less than an hour. These are tightly correlated. If you are performing well on one of them, it’s likely you will be performing well on all of them. If you struggle on one of them, that seems to cascade downward.
Q: Can you explain what you mean by having “strong continuous integration” between SLSA security practices with organizational and software delivery performance?
John Speed: Continuous integration includes a series of security checks on your code before the code is deployed. The deployment can be very simple, just looking for misspellings in your comments; or it can be looking for security flaws. It ensures that everybody’s code is subject to the same standards and there are no manual extra steps that developers need to take to do their jobs.
Q: Can you explain how SLSA is different from or works in conjunction with Software Bills of Materials (SBOMs)?
Todd: Part of SLSA is about tracking software provenance, which is closely related to SBOMs. You can think of it as a form telling consumers what’s in the services they deployed. So, if there’s a vulnerability in a component you used, this information helps you quickly figure out which of your services need to be patched.
John Speed: The SLSA framework does include an emphasis on the software’s complete list of dependencies and inputs. It doesn’t specifically say you need a SBOM, but the SBOM is consistent with the spirit of SLSA and should integrate nicely.
Q: Your report recognizes some unexpected positive outcomes in top performers, such as low burnout. What other positive outcomes have you seen?
John Speed: Going off the technical track for a moment, we found that a generative culture, which practices cooperation, shared risk and responsibility, learning and improving from failure—that these and other healthy organizational practices are associated with improved software supply chain security.
Todd: On my side, the lower burnout for top performers was a big surprise too, and a good thing to see. We also saw high willingness to recommend that your team is a good place to work. The biggest takeaway I got from that is that enhancing your security posture doesn’t come at the cost of developer happiness. Instead, it seems to be the opposite: as companies improved their supply chain security and automated it, morale went up.
John Speed: I would add that the possible link here is that developers aren’t being pulled away to deal with emergencies as often since they’re addressing their findings in the CI pipeline. So, developers experience fewer instances of their boss approaching out of the blue to fix a new-found vulnerability and your whole day is dashed trying to fix it. Applying SLSA into the CI practice reduces this type of workflow interruption and improves performance gains.
Q: How can developers use the findings to improve their outcomes and become top performers?
John Speed: Go to the SLSA.dev website. It’s an incremental framework. You don’t need to do forty things over the next six months to get improvements. There’s a graduating series of steps that acts as a roadmap for software supply chain integrity and tamper-proof software.
Resources:
- Google Blog introducing the need for SLSA framework
- GitHub SLSA Framework pages and resources
- SLSA.dev – Safeguarding artifact integrity across the software supply chain with applications for first-party, open-source, and vendors.
- Deb’s video interview with DevOps guru, Robert Seacord: Auditing Software Artifacts
