Understand the 3 P’s of Cloud Native Security
The movement to shift security left has empowered developers to find and fix defects early so that when the application is pushed into production, it is as free as possible from known vulnerabilities at that time… But shifting security left is just the beginning. Vulnerabilities arise in software components that are already deployed and running. Organizations need a comprehensive approach that spans left and right, from development through production. While there’s no formulaic one-size-fits-all way to achieve end-to-end security, there are some worthwhile strategies that can help you get there.
Here are three “P’s” of a holistic, end-to-end cloud native security strategy that will help bridge the security gap from left to right.
- Persistence
- Production-centric
- Prioritization
Persistence
New vulnerabilities are unearthed every day, and they can appear at any time. The time it takes to discover a vulnerability can range from hours to years. GitHub found that it takes, on average, four years for a security vulnerability in a software package to be discovered, and another 14 weeks to develop and distribute the fix. The incredibly broad timespan during which a vulnerability can emerge requires ongoing vigilance and persistence through continuous scanning, monitoring, and analysis.
Even with the best vulnerability scanning tools, you should have only limited confidence that shift-left scans can detect everything because they only offer a glimpse into security at a specific point in time. There is no assurance that a new vulnerability will not be discovered in the future, even if the same code is deemed secure right now. Security teams that persist in their scanning and detection efforts — across the entire CI/CD lifecycle — will be well equipped to remediate threats effectively and efficiently.
Production-centric
Shifting left can help organizations develop applications with security in mind. But no matter how confident you are in the security of an application when it leaves development, there is no guarantee that it will remain secure in production.
We have seen on a large scale that vulnerabilities are often disclosed well after being deployed to production. Reminders include Apache Struts, Heartbleed, and, most recently, Log4j, which was first published in 2013 but discovered just last year.
Additionally, production environments contain more than just the first-party code that you deploy, including:
- Container images pulled from external repositories.
- Runtime sidecars and integration tools installed when software is deployed.
- Third-party applications, such as application servers, dashboards, proxies, and firewalls are deployed without the stringent checks that your first-party code underwent.
- Infrastructure that is out of the control of the DevOps team and cannot be scanned by shift-left tools.
Determining the context of the application in production is an essential part of securing cloud native applications. What other components, code, and infrastructure interact with this application? You will need a different mindset and an additional toolset to bridge the security gap from left to right.
Prioritization
Scanning for vulnerabilities in production systems can surface hundreds or even thousands of vulnerable components, but the presence or volume of detected vulnerabilities does not necessarily correlate to a high risk of compromise. This is because vulnerability is not the equivalent of exploitability.
To better understand the risk a vulnerability poses, it’s necessary to understand how it sits within the context of the application. Is the vulnerability exploitable by using the application in a particular way? Can the vulnerable application be reached from the external attack surface, or does a would-be attacker need to first gain a degree of internal control to reach it?
By determining your most critical vulnerabilities, you can prioritize how you remediate. From the hundreds or thousands of potential vulnerabilities, teams can filter out the benign issues (along with all the alerts that they set off) and prioritize the very small proportion of vulnerabilities that are actually critical because they pose the greatest risk to the security of your application right now. By concentrating on the risk of exploitation and prioritizing remediation in order of criticality, even a small or short-staffed team can effectively secure cloud native applications at scale.
Conclusion
In summary, shifting security left is a very worthwhile practice, but alone it is not enough. Through persistence, attention to production, and prioritizing the fraction of vulnerabilities that create real risk for your organization, you will be ready to manage your organization’s security posture with increased confidence.
