Shifting Left with Security
There’s been a lot of talk lately on Shift Left Testing, which is undoubtedly useful as a DevOps practice. There seems to be less talk on Shift Left Security, which surprises me.
Shifting Left, is a methodology of bringing historically late-stage processes earlier in the development cycle, like shifting left on a Gantt chart in an old waterfall-style release. Shift Left Testing fits well into the mantra, “test early, test often.”
Shifting left with security, therefore, means bringing security reviews, security planning, and security testing earlier in the development and product release cycle. As a component of a healthy DevOps strategy, I believe that Shift Left Security would dramatically improve application security and reduce vulnerabilities.
An obvious question to ask is: why? Why would doing security reviews sooner improve the overall security, particularly if the code is still in flux?
I see two answers to this question. The first, is simply that conducting security reviews sooner provides more time to correct any security flaws before they’re exposed. A review at the eleventh hour, when the project is already over scope and over budget, is too easy to ignore. At that stage, it’s tempting to log security issues as bugs to be prioritized in the backlog and addressed at a later date. Obviously, this increases the risk that security flaws will be shipped in production, even over the reservations of security engineers.
But secondly, and I think more importantly, we’re conditioning engineers to treat security as an afterthought. By conducting security reviews as a final checkoff item as the release is going out the door, we’re subconsciously communicating that security is a task rather than an attribute. In other words, we’re saying that secure apps are “secured” instead of saying that secure apps are “built securely.”
This subtle distinction has, to my mind, a big impact. First, it means that engineers aren’t learning about security and fixing issues in the moment, where they’re most likely to build habits around secure coding. When we treat security as an after-effect, we’re adding it in as a feature on top of work that the engineer previously considered finished.
Additionally, we’re losing the opportunity to fundamentally and structurally build our apps with a security-first mindset. And this, I think, is the real flaw. Secure applications are planned, not happenstance, and they’re fundamentally built on the whiteboard, not with a late-stage checklist.