The move to Agile and DevSecOps development processes has fostered a lot of attention on the need to shift security testing left in the development cycle. And this is absolutely a pivot in the right direction. Moving security testing into the realm of the developer makes security testing faster, easier, more effective, and less expensive. However, it’s important not to lose sight of the fact that effective application security secures software throughout its entire lifecycle – from inception to production or, put another way, from prevent to respond. Application security should be considered and conducted from the planning phase through to the development phase, on to the testing phase and right into production. In fact, rather than talking about securing the software development lifecycle, we should focus on securing the software lifecycle.

You Need Both Locked Doors and a Police Dept

The secure lifecycle, or prevent-to-respond, idea applies in the real world as well. With security in the physical world, you need to understand basic safety measures and implement best practices – lock your doors, understand where the exits are and have a fire escape plan, put kids in nonflammable pajamas, etc. But that doesn’t mean you can disable your smoke alarms or disband your local police department. With real-world security, just as with software security, you need to focus on the whole lifecycle – from plan and educate to prevent and respond.

The More Things Change, the More They Are Vulnerable

Why do we need to secure every stage of the software lifecycle? Why do we need to focus on both preventing and responding? Because producing record numbers of applications at a breakneck pace is a high-risk endeavor. With the speed of today's development cycles – and the speed with which software changes and the threat landscape evolves – it would be foolish to assume that code will always be 100 percent vulnerability-free after the development phase, or that code in production doesn’t need to be tested. In their recent report, Incorporate Application Security Throughout the Application Life Cycle, Gartner points out that “risks to applications stem from a variety of causes, such as:

• Unsecured application design and configuration.
• Vulnerabilities in the application code and use of vulnerable third-party components and libraries.
• Ineffective security controls and unpatched vulnerabilities at runtime.

It’s important to realize that vulnerabilities stem from different sources and will emerge at every stage of the software lifecycle. For instance, in many cases, vulnerabilities will be discovered in applications you already have in production. If you are able to block attacks on vulnerabilities, you can avoid downtime and fix during planned updates. In the end, neglecting software security in any stage will expose you to risk.

Look Left and Right

Shifting security left in the real world involves things like developing a fire escape plan. In the software security world, it involves threat modeling before any coding even starts, educating and coaching developers on secure coding practices and then enabling them to test for security as they are coding.

Shifting security right in the real world involves making sure your fire extinguisher works or since it’s summer and I’ve got beach on the brain, picking a beach with lifeguards, even if your kids have had swimming lessons. In the software security world, it involves security testing completed code, whether it’s developed internally or externally, and implementing for apps in production. Just as software is not static, application security isn’t either. Effective application security is not a one-and-done project, but an ongoing program that both prevents and responds to breaches at the app layer.