Shifting left in security? The numbers are convincing
March 3, 2021
Special thanks to Rahul Sood, Senior Vice President—Prisma Cloud, Palo Alto Networks, for his collaboration and contribution to this blog post.
The more metrics we gather, the more compelling 'shifting left' in application development appears. For example, organizations could be looking at:
- A 70% reduction in build costs.
- Three times faster build speeds, compared to legacy methodologies.
- A 50% average time reduction in time to go-live.
- Up to 40% reduction in run operation costs vs legacy.
As you probably know by now, trends like “shift-left security” and “DevSecOps” refer to integrating security throughout the build cycle, rather than the end, where it traditionally resided—or should we say 'languished?" Shifting left can help organizations keep workloads secure in the age of cloud-based applications and infrastructures that are constantly changing and constantly subjected to increasingly sophisticated cyber-attacks.
<<< Start >>>
<<< End >>>
What shift-left security looks like
The high-level view is simple. When development starts without security, software quality checks are usually only conducted during runtime. The result in many cases is a series of difficult, last-minute skirmishes between the people in development and those in security. Perhaps more important, flaws that can lead to brand-damaging attacks are more likely to get through to the operations side. But if security teams get involved at the very beginning, working closely with developers, security processes will be embedded, allowing developers to help in quickly correct vulnerabilities.
Why it's critically important
Recent vulnerability research shows that during the past five years, up to 76% of all vulnerabilities were from applications. This can be viewed as an opportunity, because shifting left can start addressing 76% of all your vulnerabilities in a single step. As the numbers at the top of this blog show, the earlier you catch problems, the cheaper (and faster) they are to fix. If you have to stop everything and fix code that was created months ago, you're going to pay more and it’s going to take a while.
An additional benefit that is often overlooked is that shifting left helps organizations identify systemic problems in their development process that produce vulnerabilities, delays, cost overruns and less-effective applications again and again. Keep in mind that while Infrastructure as Code (IaC) templates can save time and reduce errors, they also can—if incorrectly configured—replicate problems. Fortunately, these previously unseen systemic problems are often uncovered after a shift left, which make a big difference in a little bit of time. It is also an opportunity to renegotiate contracts to include embedded security in the development work. This can have an immediate, positive effect on the development process.
Reducing the 'noise'
Let's not forget that more-secure applications lead to fewer alerts. Once security teams are free from trying to deal with barrages of false alerts, they can focus on the ones that matter. This is true even for organizations that use automation, which is helpful but typically used sparingly. Either way, it's far more efficient to prevent alerts than to try to deal with them as they arise. Based on our experience with customers who are using Palo Alto's Prisma product, some 80 percent of alerts can be fixed earlier and caught easily by shifting left. This is a huge help to IR and SOC teams.
Shift left is even more important in a multi cloud environment
Because cloud services are by nature a world of self-service and automation, cloud security is by default handled by developers. Unfortunately, nearly half of developers and engineers bypass cloud security and compliance policies. This may be one reason cloud misconfigurations cost companies nearly $5 trillion from 2018-2019 alone.
How to implement? First, consider everybody a tester
The idea is to make sure developers know they are responsible for testing, which ensures that the whole process starts with a testing mindset, while automating the testing as much as possible. Code review quality checks are also key, as is teaching testers to code, as the line between developers and testers will and should begin blurring. Also, make sure everybody uses the same tools.
Do all this and you would minimize the damage misconfigurations and vulnerabilities can cause while saving time and money in the process. That's a win-win-win.
For more information, please read our Secure Cloud POV.
Accenture Security helps organizations build resilience from the inside out, so they can confidently focus on innovation and growth. Leveraging its global network of cybersecurity labs, deep industry understanding across client value chains and services that span the security lifecycle, Accenture helps organizations protect their valuable assets, end-to-end. With services that include strategy and risk management, cyber defense, digital identity, application security and managed security, Accenture enables businesses around the world to defend against known sophisticated threats, and the unknown. Follow us @AccentureSecure on Twitter or visit us at www.accenture.com/security .
Accenture, the Accenture logo, and other trademarks, service marks, and designs are registered or unregistered trademarks of Accenture and its subsidiaries in the United States and in foreign countries. All trademarks are properties of their respective owners. All materials are intended for the original recipient only. The reproduction and distribution of this material is forbidden without express written permission from Accenture. The opinions, statements, and assessments in this report are solely those of the individual author(s) and do not constitute legal advice, nor do they necessarily reflect the views of Accenture, its subsidiaries, or affiliates. Given the inherent nature of threat intelligence, the content contained in this report is based on information gathered and understood at the time of its creation. It is subject to change. Accenture provides the information on an “as-is” basis without representation or warranty and accepts no liability for any action or failure to act taken in response to the information contained or referenced in this report.
