Shifting Left for Secure Application Development
Have you embraced a ‘shift left’ approach to application development yet? The chances are that the rapidly growing application economy will already be driving a DevOps culture within your organisation, where agility is king: development teams are expected to deliver the goods to ever diminishing deadlines to meet market demand and keep prices down. Unfortunately, the end result can all too often be delivered at a high cost in terms of security. Applications that move through the delivery chain with unseen security issues in place risk becoming an overriding design debt that must be paid, with interest added at every stage of the process, when that code goes into production. Shifting secure thinking all the way left to the very start of the development process provides a positive impact as far as return on investment is concerned and helps mitigate the all too obvious risks of insecure applications to the enterprise, the customer-base and the bottom line.
Application vulnerabilities will remain a major attack vector while development and security are siloed
A shift left mantra resonates with anyone who takes security seriously for a number of very good reasons, not least because by including developers in the security responsibility loop as early in the development process as possible it removes the overheads of traditional siloed thinking. This is proactive thinking in action, rather than an inefficient and costly reactive approach to security where code is created by the developers, then handed off to operations and once deployed security gets bolted on by a completely separate team. It doesn’t take a genius to realise that application vulnerabilities will continue to exist in, for want of a better term, ‘bad code’ until and unless these silos are dismantled. Which is why DevOps has been such a powerful force, and why DevSecOps is now becoming increasingly accepted as essential for any forward-thinking organisation. By shifting the secure thinking as far left as possible in the software lifecycle, risk mitigation is part of everyone’s job description and becomes baked into development culture.
Overcoming the agile development testing cadence issue
Of course, there’s always the small matter of achieving developer buy-in for a shift left to secure thinking environment to overcome. Truth be told, no developer sets out to build an insecure application and if there is a better way to approach things so that the risk of such an outcome is reduced there should be few complaints. Especially if this can be done in such a way as to ensure developers are left feeling empowered and responsible for testing, rather than being burdened with yet another task to shoehorn into an already tight schedule. Which means understanding that developers aren’t security people, so security testing tools need to be adapted to fit seamlessly into the continuous integration/continuous delivery toolchain. Shifting left is all about embedding the testing team into the development team and by so doing empowering developers to be testers and testers to be developers. Doing so successfully creates a culture of prevention rather than one of detection, and in turn makes the whole lifecycle more secure, more efficient and cheaper as there should be far fewer late-stage revisions required. The core concept of accelerating the time from development to deployment that an agile environment demands is met, and this shifting left of security testing saves money while producing a safer end product for good measure!
Automation and integration are key to a successful shift left
It’s important not to get too carried away with the notion that a shift left to security testing is some kind of silver bullet, a panacea for all the application security risk that exists out there. Chasing some mythical security perfection where there are zero vulnerabilities is less likely to result in a truly agile development environment, and more likely to result in what you might call analysis paralysis. What it can do, however, is help to mitigate the security risk while at the same time reducing delivery time and cost. Key to achieving this is AI; no not that AI but rather the double-whammy of automation and integration. Human error is generally accepted as being at the heart of many of the security issues that we see with code, and more often than not time constraints put on developers play into this. It’s understandable to assume that adding a requirement for more testing will put further pressure on already time-constrained coders. Yet automated tools, integrated into the development toolchain so these testing tools can be launched within a familiar toolset such as Jenkins, Jira, Snow etc, with the results consumed by those same toolsets automatically, makes it a no-brainer really. The concept of continuous integration isn’t alien to developers, and rather than breeding contempt this familiarity should help bring acceptance within the development environment.
Avoid playing the blame game, continuous improvement is as important as continuous integration
Properly implemented, a shift left approach to secure application development testing promotes independence within the various teams throughout the process. Which isn’t the same as advocating a siloed environment, but rather ensuring one where everybody feels responsible for the security of the application. That responsibility shouldn’t be viewed as a millstone of guilt around the neck of the development team either, but rather a chance to learn and improve which is the exact opposite by allowing erroneous coding where those failings are corrected by another team later in the operational process. Yes, security testing of this sort will inevitably sometimes point back to something a developer has got wrong, but as long as this is viewed through the lens of continuous improvement and not punishment then most will see that growing into a full stack developer team is the desired outcome.
Visibility and understanding risk are key to all security and shifting left during the development process is another step nearer to achieving this 'full stack' nirvana for reducing the application attack surface. The more secure the application, so the better the return on investment; from reducing development inefficiencies through to increasing user satisfaction.
More information about our web application security solution?
About the author:
Davey Winder is a veteran security journalist with three decades under his belt. The only three-time winner of the BT Security Journalist of the Year award, he was presented with the Enigma Award for a 'lifetime contribution to IT security journalism' in 2011. Currently contributing to Digital Health, Forbes, Infosecurity, PC Pro, SC Magazine and The Times (via Raconteur Special Reports) you can catch up with all his latest writings at www.happygeek.com