Shift Left

What does it mean to shift left?

The development pipeline typically starts from the left as an idea and ends on the right with shipping software. Thus, when we speak of something “shifting left,” we mean the action or activity taking place earlier in the application development cycle.

The “shift left” philosophy moves a later-stage activity closer to the beginning, often bringing it from deployment or running software toward development. For example, prior to the current culture of unit testing, all testing was done by a QA team just prior to a software system’s release. Having developers write unit tests for code long before it reached a near-final state was an example of testing “shifting left” in the process.

What are the benefits of shifting left?

For the past half-century, software processes and methodologies have emphasized catching errors and vulnerabilities earlier in the cycle, where the costs of correcting them are (presumably) smaller. For example, organizations emphasize architecture and design activities before starting coding, to define what they are building before starting work.

More than the actual change in development process, however, the term “shift left” often suggests a shift in mindset, to establish a culture of active collaboration between all the participants in the software development lifecycle: product owners, developers, managers, testers, operations personnel, stakeholders, and anyone else that is involved. The goal is to bring a sense of ownership (and therefore an intrinsic desire to “do the job right” and build a quality system) to everyone involved, such that the overall result is a stronger and more satisfying outcome.

What are the risks of shifting left?

Two risks of shift left are oversimplification and cultural pushback. 

• Oversimplification: A simple shift in the timeline, moving up testing and/or QA activities, or moving (for example) testing into the development cycle, could eliminate the entire QA/holistic manual testing phase. 
• Cultural pushback: Some organizations are simply resistant to various functions sharing ownership of an outcome the time commitment that comes with collaboration. It’s easier if “security is an IT security thing” or “QA owns testing,” so any attempt to shift left fails before it can make an impact. 

Conversely, as our industry discovered when we tried to push too much architecture and design to the left, some feedback is helpful during the coding cycle. Application quality benefits from iteration cycles within the development, to gain feedback about the system’s current state. If activities are pushed too far to the left, they can force decisions without data. 

Who are the key stakeholders in an effort to shift left?

Several roles can play a role in implementing a shift left transformation. Some are listed below. 

• Executives: As with any organizational transformation, much of the initial work rests with upper management. Executives must state expectations and allocate resources to signal that a “shifted left” mindset is important to the organization. Simply hiring a team to “make it happen” without support is generally a recipe for team failure. 
• Developers: Then much of the work falls to the various groups involved in the shifted-left activity. For example, when organizations shifted testing left into development (and called it unit testing), developers had to build and run unit tests. 
• QA: QA professionals were also impacted because they had to teach developers how to “think like QA” when writing unit tests. 
• A coach: Adding a “coach” can monitor the overall progress made by the organization. This can be an internal individual who is looking for a challenge, or (more often) an external consultant with expertise in making the shift. 

What steps should an enterprise take when looking to shift left?

Shift left is an organizational mindset shift, so companies should establish goals and agree on a process before starting. It’s generally best to start small, generate a “win, and then widen the scope as the organization becomes more comfortable. Typically, this begins with a smaller project with more flexible milestones –by a team that is interested in change and open to new ways of thinking. Executives should be prepared to step in frequently, to clear obstacles or provide additional support to the team – or just to celebrate milestones. 

After the initial “win,” executives should socialize the victory to the rest of the company and roll the new shift out to other projects. In some cases, team members from the original project can act as “consultants.” If an external consultant was used for the first project, that consultant can act in a more consultative capacity rather than 100% “hands-on” on a single project. Executives again should “lean in,” clearing new obstacles and providing resources where necessary, and again celebrating with the teams when milestones are hit. 

Executives can hire or promote new executives that openly embrace and encourage shift left mindset, as well as hiring and/or rewarding those team leaders that also embrace the new shift. After another iteration or two, it will be difficult to find anyone at the company who remembers doing it any differently. 

How does Azul help with the shifting left mindset?

Azul Vulnerability Detection, a feature of Azul Intelligennce Cloud, focuses scarce human effort where vulnerable code is or has been used versus simply present, to help reduce issue backlogs. Intelligence Cloud retains component and code-use history, focusing forensic efforts to determine if vulnerable code was exploited prior to it being known as vulnerable. 

Inefficient prioritization of vulnerabilities and unused code wastes effort, hampers agility, and reduces developer productivity due to constant context switching and unproductive code maintenance tasks. Azul Vulnerability Detection is not another dashboard for 

customers to look at. Users can access data on which components are in use, and vulnerable, using either the product’s API or an intuitive UI. The role of the web UI is to show the information we have and guide customers to the REST API.