Not long ago, the term “shift left” entered the lexicon of application security. A concept which promised to catch security and fix issues earlier in the development process, save time, money and improve the application security posture. Today, however, despite many vendors wrapping their new (and old) App Sec solutions with this label, and many enterprises trying to “shift” their security programs to the “left” aka the development teams, it hasn’t really proved to be the panacea that everyone had thought (or hoped) it would be. Let us explore why.
The opening shot
In pure marketing terms, the “shift” in “shift-left” is a bad start. It implies there is a burden or responsibility that now has to be shifted to someone else. What responsibility? To make sure the applications being developed are secure, of course. And to whom are we shifting this responsibility? Why the development teams, of course. They write the code, they should own the security implications of how the code would behave in production. Logical, but when this is positioned as a burden or responsibility that has to be shifted, we are already creating a negative image of this problem that needs to be owned and addressed by someone else. So right off the bat we have created an adversarial situation between the development and the InfoSec teams. And today, despite the best of intentions and solutions at our disposal, we see this manifest as conflicts between the dev and InfoSec over where the lines are, finding and resolving AppSec issues.
Late as it may be, the marketing around this otherwise promising concept could use some work.
The sitting ducks
The dev teams really are at the receiving end of a bargain that they are unable or unwilling to fulfill in this equation. The average application developer is likely to know more about CSS than a CSRF. Now consider the best tools we have at our disposal today with IDE plugins that identify vulnerable dependencies as the developer includes them in his project. Let us assume that these tools point out to our developer that the library call he just used has an CSRF vulnerability. We expect this person to not only understand what CSRF is in the context of security but also to find out the options for the library that he can no longer use.
Bad or naive vulnerability prioritization techniques make this problem even worse. CVSS scores give little insight into the true exploitability or weaponization of the vulnerability. If the developer is asked to take a call or abide by a policy based on an arbitrary CVSS score or prioritization based on say “number of calls to vulnerable code” (yes, some top shelf solutions use this technique to prioritize) to fix these issues, then they are either going to exclude critical vulnerabilities or spend an inordinate amount of time addressing non-issue. Or worse, both.
Halting dev pipelines and communicating with InfoSec team for guidance add delays which are an anathema in our break-neck Agile development teams of today. The dread of being up against a sprint deadline with a bunch of vulnerable dependencies that you have no clue on what to do about, is something that shouldn’t be wished on any developer. Yet this is the reality of putting dev teams charge of remediating security issues. However, more often than not, the show goes on, mostly as exceptions sought by Engineering VPs to punt the problems to the next release and into the scrum backlog. And this is where the promise of shift-left is broken.
Again, this is not to discount the responsibilities of developers in writing better, more secure code. Engineering leaders should try to enforce these standards as much as possible and make the developers more aware of application security and how to identify and remediate vulnerabilities. However, the assumption that a new IDE plugin with inline vulnerability detection will suddenly empower dev teams to write secure code is a reach.
The hapless gatekeepers
The ProdSec/InfoSec teams sitting on the other side have their own woes. They have the mandate of making sure applications delivered by engineering teams are invulnerable. However, even the best of the solutions out there will exacerbate the situation by asking for too much access to code repositories and worse, in some cases physically move code out of the enterprise firewall for scans (Github Apps! gulp!).
Even if the gatekeepers manage to get visibility into each new checkin, PR or repository that gets created, they are still dealing with the same issues of bad VM prioritization. A mountain of vulnerabilities in the backlog, a ton of emails back and forth with the dev teams and then helplessly watch and pray as the new release gets shipped with a bunch of critical vulnerabilities to be address later of course.
A new hope
Daunting as it may seem, the problem is not insurmountable. “Shift-left” (or its more polished replacement) can actually work. We just need to arrange and adapt our existing tools in a way that helps “share” this responsibility rather than “shift” it. Here is a prescription:
- Better prioritization is a must and should be based on external and internal factors that affect risk. Fewer issues to address means more likely they will be addressed in the upcoming release.
- Alert fatigue should be kept to a minimum. Tools and InfoSec teams should communicate directly to the developer with proper context over modern and dev friendly channels like Slack, MS Teams, Github Issues.
- Stop sharing code and credentials with SaaS scanning tools. You are just adding another link in your supply chain. Do not assume your security solutions are secure themselves.
- Stricter policies to control bad code getting in. Give InfoSec teams the power to stop, reject, revert commits based on agreed policies. This will make them more responsible for not only securing the applications but also for any additional time that it takes to do so.
- ..everything. Fewer people needing to look at issues, press buttons, send approvals the better.
“Share-left” is beginning to sound a lot better, isn’t it?
