To succeed in today’s competitive environment, organizations need to aggressively cultivate innovation, velocity and economy: innovation to continue to delight customers with new offers, velocity to get there before competitors and economy to protect margins.
In order to meet these imperatives, organizations have reinvented the way they create and manage application development and deployment, not to mention the runtime platforms that they run on.
The phrase “shift left security” seems to come with a full complement of broad statements and untested assumptions. The one I see most often is “developers don’t care about security.” This is demonstrably false.
Developers think a lot about software quality. When security is a key component of quality, they intrinsically care about security.
Shift Left Security: The Three T’s
Everyone wants to write good code, it’s just that sometimes the definition of “good” isn’t as clear as it could be. Developers also need to be productive – organizations need to get from great idea to delighted customer as quickly as possible. So developers want to write good code, create great software and hit the next sprint.
If your strategy for shifting security left comes only with added responsibility, it’s unlikely to improve developer productivity, joy or flow. To avoid cognitive overload and developer burnout, the shift needs to be accompanied by what I’m going to refer to as “The three T’s.”
- Training
- Tools
- Teamwork
Training
Training is essential to enable developers to benefit from introducing security testing and practices early in the software development lifecycle.
Simply providing a dev team with a spreadsheet of discovered vulnerabilities, without the context needed to fix the identified issues and prevent them from reoccurring in the next feature implementation, is going to harm productivity, not help it.
Most developers are “lifelong learners,” but they don’t get the opportunity to learn secure coding and vulnerability remediation on the job. Fortunately, there are plenty of training courses available in a variety of formats to provide the skills and expertise your teams need to continuously improve application security posture.
Tools
While tools are not the full answer, the right tools in the right form-factor can make the difference between simply wanting to improve security and actually implementing a successful security practice.
As development methodologies, application architectures and runtime environments evolve, the attack surface area evolves alongside them. Cloud platforms, infrastructure-as-code and programming languages that rely heavily on packages with nested software modules all provide opportunities to introduce vulnerabilities into an application.
However, it’s unrealistic to expect developers to become experts in AWS IAM policies, Kubernetes API admission control, Terraform best practices, and every NodeJS package their application uses, and still write great code with flow and joy. They need tools that provide automated expertise that can slot into their existing workflows and provide usable feedback as part of the software development process.
Teamwork
While we’re supposed to leave the best until last, the reality is often that we leave the hardest until last. Teamwork – or really, collaboration, which sadly doesn’t begin with a “T” – is the keystone of shifting left, but it can also be the most challenging piece.
While process and tools can be changed with comparative ease, mindsets and behaviors are harder to adjust. And without increased collaboration between security and development teams, much of the value of injecting security earlier into the software delivery lifecycle will be lost.
Shifting left doesn’t mean that the development team should have a heavy new burden of complete responsibility for all security laid upon them. Nor can it mean that the security team should come in and dictate new procedures, controls and technology within the build and deploy pipeline.
While Mark Zukerberg might encourage you to “move fast and break things,” a better mantra for shifting security left might be to “move fast but don’t get hacked.” Taking these two seemingly oppositional principles as your collaboration charter might give you a good place to start.
With this north star, the natural problem-solving nature of IT professionals can come to the forefront. Sharing responsibility for both security and velocity between teams is both a central DevOps theme and a powerful motivator of collaboration.
Conclusion
With the right knowledge and tools in place, and with a shared imperative to accelerate the delivery of secure software, you significantly improve your chances of creating secure, high-quality software, and of hitting those sprint dates. You may even find your teams enjoy it.
You can learn more about the proper tools in our on-demand digital summit, Cloud Native Security Live.