SLSA and Developer Productivity Meet in 2023

As cyberattacks rise, software organizations must proactively reduce vulnerabilities and ‘shift left’ to harden their entire software delivery life cycle (SDLC). However, most organizations cannot afford to have their security measures negatively impact developer productivity. As businesses transition to the cloud, many are left perplexed about finding the balance between security and delivering features at speed. Supply chain levels for software artifacts (SLSA) attempts to reconcile ongoing security risks with a “security framework, a checklist of standards and controls to prevent tampering, improve integrity and secure packages and infrastructure in your projects, businesses or enterprises.”

This article explores why businesses should consider SLSA, how the framework offers a tangible and achievable approach to security and what it means for developer productivity.

How SLSA Works

Like any new or emerging trend in the ever-complex and tool-heavy software supply chain, SLSA needs to be concretely defined and understood by IT teams. The car manufacturing industry provides a good analogy for understanding SLSA. Car manufacturers have detailed artifacts and inventory on how to build a car. This helps in the case of a recall because the dealership knows who bought the car, what part is defective, what year it was made and the serial number of the part. The dealer can dial down to the details of where to replace the part and how many cars require repairs.

In the software industry, SLSA helps track the dependencies that make up the software artifacts in the supply chain. This is accomplished through the framework’s guidelines for incrementally hardening infrastructure and increasing assurance using industry best practices. Similar to the car manufacturing industry, SLSA ultimately provides an approach for keeping track of all touchpoints along the SLDC and from where (or who) each touchpoint came.

This approach differs from testing software during the build phase, and a single technology or platform does not exist to get developers to the highest level of SLSA compliance. Instead, SLSA offers a framework to follow to achieve different up to four possible levels of compliance.

Developer Productivity and Security at Odds

To get started with SLSA, the team or organization needs to examine its supply chain process and technology stack to determine how to meet the requirements for level one SLSA. From there, the organization or team can look at what is required to advance to the second level and so on.

The challenge is that many companies don’t understand their current tech stack and will need to partake in a discovery journey of what may be missing to accomplish level one. For many, it may take a crawl, walk, run approach.

The other consideration is when there are challenges within people and processes. Whoever is driving SLSA needs to get to a higher level of process through the SLSA framework without impacting developer productivity. Most organizations can’t afford to slow down on delivering new features to the customer. If anything, they want to move faster to drive revenue and growth while retaining existing customers. But at the same time, they can’t allow themselves to be vulnerable to bad actors who want to gain control of their data, customer data or source code.

Finding the Balance

In summary, I believe the following three things are what organizations need to address most in the next year when it comes to security best practices:

1. SLSA – With SLSA, teams can establish, verify and maintain the trust of the software supply chain.
2. Shift left security – If security is not addressed early in the development process, organizations can suffer revenue loss, a diminished brand reputation and heavy fines. However, the shift left approach has the potential to positively impact speed and engineering productivity.
3. Developer productivity – Security and developer productivity don’t have to be completely at odds. There are many other ways that developer productivity can foster developer joy. For example, organizations should focus on DevOps KPIs like reducing test feedback times and improving the consistency and reliability of builds. Engineering teams can also make sure the right people are alerted based on code changes and can clear information to reviewers about what needs a review.

In the next year, I expect to see a rising conversation around this movement to maintain developer productivity while simultaneously tracking the prominence and position of the supply chain and increasing security. The leveled approach to SLSA aims to solve many of these challenges, but organizations need to prepare for the time and investment it will take to reach the highest level of assurance.

Avatar photo

Gilbert Martin

Gilbert Martin is a VP of Customer Experience & Solution Engineering at Opsera (www.opsera.io). In his current position, Gilbert is responsible for the company’s growth and sustainability; he oversees Customer Experience and Solution Architecture, focusing on maintaining and providing the best customer experience and the management of customer software delivery to accelerate their speed to market. Gilbert has spent the past 20 years as a professional across several key technical domains, including Cloud Platform Engineering, Systems Architecture, large-scale deployments, and security. He looks forward to working with thriving companies across Silicon Valley.

gilbert-martin has 1 posts and counting.See all posts by gilbert-martin