Let’s address the elephant in the room – “shift left” hasn’t had the impact on our software security as many of us expected it to have. While it does have much merit and has influenced security in an indispensable way, I argue that “shift left” should be viewed as a tactic in a larger management strategy rather than a comprehensive solution to solve application security woes. Just as software development is a very complicated process with many layers, “shift left” should not be viewed as a straightforward, linear effort. This blog post will review the success, concerns, and potential of “shift left” and how we can “restart” the process by applying it a little differently.
What Is “Shift Left”?
“Shift left” is a relatively new security approach that calls for beginning application security processes at the earliest, “left” side of the development cycle, which is the phase of creation. There are different ways to describe the software development lifecycle and its elements, but a commonly agreed-upon way of breaking this down begins with a plan, then moves into coding, building, testing, releasing, deploying, operating, and finally monitoring. The far-left side of this process is the “creation” phase, and the far-right side is the “operation” realm where things are actually installed and used. “Shift left” defines the different ways of moving actions to the leftmost side, to be worked on by developers.
Processes that can be “moved to the left” include testing, which is commonly implemented as the first “shift left” effort. Testing helps organizations tackle problems from the earliest stages – when they plan, create, and code. Tackling the problem at its earliest stage makes it significantly more likely that when you get to the stage of operating, you will encounter fewer problems, they will be easier to fix, and less expensive.
What Does “Shift Left” Get Right?
Fixing problems from the earliest stages increases your chances of avoiding mistakes, making sure that the software gets to production, and implementing quick and accurate fixes to any problems from the people who wrote the code and are responsible for running it. A successful example of “shift left” is containerization and other types of packaging, which became relevant when Kubernetes emerged. “Shift left” enabled us to understand that when a software artifact is properly packaged, it can make the follow-up steps in deploying, running, and monitoring it a lot easier. Automation combined with containerization and software artifact packaging allows us to streamline the entire deployment operation very effectively. Another “shift left” success story is attribution – “shift left” enabled us to initiate and amplify the conversation about code owners, enabling the engineering organization to identify the developers behind the code and making processes more streamlined for developers themselves. Developers want to write good code, and “shift left” pushed this conversation with security to the forefront without being antagonistic.
“Shift Left” Security Testing Challenges
Although it has already been fully adapted, security testing has had varying levels of impact. Testing alone requires a level of skill or engineering maturity that may be an obstacle for some organizations, which may not reap the full benefits of having a full testing suite. In fact, in most engineering organizations there is still a mitigation control function since developer-based testing isn’t trusted as the only source of truth. Organizations understand that they need a QA function to be the challenger of testing tools and to act as the final quality assurance and control function of the results.
“Shift Left” Security Remediation Challenges
Security tools provide you with many alerts that are challenging to make sense of, prioritize and act on. What are developers supposed to triage and try to mitigate? It doesn’t help that developers can still release and move forward in the engineering process without responding to what the security testing is telling them. Many tests are more like “synthetic” blockers rather than real blockers – developers can challenge these blocks in the workflow and will find a workaround in order to refrain from fixing them.
For those alerts that are classified as critical to mitigate, security does not have the capacity to triage those issues for developers. On the other end, developers may lack the knowledge to do the triage themselves. Developers are not security professionals and can’t be expected to understand the meaning and context behind the code. This combination of not being able to do the triage independently combined with the sheer volume of alerts generates friction between developers and security teams, making it more difficult to collaborate as pushback against these testing tools and the process itself grows.
Actionable Tips for Implementing Code Security With “Shift Left”
I’ve put together some basic principles that can help in the mitigation journey and create a healthier code security culture. We can all agree that vulnerabilities must be fixed, but “shift left” fails to recognize that this is a process and not something that can happen overnight. Engineers should not be expected or asked to fix every problem as it is generated, at the drop of a hat. If we start with baby steps, we understand that there are some things that are just easier to shift to the left. This will serve as the first, fundamental step in a true journey into shifting problem mitigation left, along with developing a healthier culture where developers feel responsible for the codes that they write.
My first basic suggestion is to admit that a real shift can happen only when R&D decides it should. Security isn’t the one to make the fix, so in order to convince developers to do so we have to give them business context into each problem to show its urgency, or just ask nicely. We have to get to a point where the R&D organization decides, of their own volition, to pull security activities to the left. As security professionals, we must focus on efforts that bring value to other teams and should propose an agenda that contributes to R&D efforts. This means playing inside their playground and not bringing in other tools or new portals and demanding that they use them.
As the organization scales, risk resistance is built bottom up, but also top down – with management. Make sure that managers give their teams enough resources to tackle security issues, and that developers are not interested in creating artifacts with problems.
In order to begin “shifting left” in a sustainable and scalable way, organizations should push the adoption of attribution from the get-go. This means knowing what each artifact is, what it’s made up of, and what its business function is, so that we can support prioritization and improve the effort required for an alert. If there is a critical alert, we know exactly if it’s going to be taken care of or not. When you have properly done your homework and have an asset inventory in which each artifact is assigned a security and remediation policy, organizations can eliminate endless discussions and excessive time spent on triage. “Shift left” can live up to what it is intended to be only when developers truly build their security lifecycle into their workflows. As security professionals, we need to help them do so.