Breaking down the barriers between development and operations teams has transformed the application release process over the last several years. Enterprises who led the way five years ago, such as Amazon, Facebook, and Netflix, remain household names for consumers and the tech community alike. Leading the way with rapid release cycles at a massive scale, they’ve moved software development as a whole towards a DevOps approach, changing the speed of release from one big release every twelve to eighteen months to multiple releases each day. Integrating security into the DevOps process empowers the release of more secure code, but rapid releases also mean that you have very little time to fix issues. Your application security team needs to quickly identify critical vulnerabilities in the code so it can be resolved by engineering and pushed to release.
How often do you release software?
Consumers today expect web applications to be online and available — all the time. Remember when Disney+ launched, and was beset by launch-day bugs and crashes? Disney spokespeople claimed it was due to high demand for its new service, but that didn’t make their new subscribers any more patient with the login, streaming, and customer support issues. They wanted Disney+ available and functional, immediately.
While consumers once expected release models that took days or weeks for new software releases, today DevOps teams must work quickly to address crashes and bugs across web browsers on PC and Mac, Apple iOS and Android devices, and other platforms. Particularly for consumer facing applications, not only is downtime not an option, updated content and applications are expected regularly. To meet these demands, many enterprises release software updates quite frequently. Adidas, for example, releases as fast as five times per day. With these rapid releases, however, comes a challenge for the application security teams. In most enterprises, testing falls behind as development speeds up. The migration of applications to the cloud further highlights the importance of incorporating security and security testing into the DevOps process, according to the 2021 State of DevSecOps by Security Compass.
How much time do you have to fix issues?
Most organizations have several excellent software security testing tools running throughout the SDLC, all of which produce results. Many are informational that won’t be addressed by development, some are false positives, some are duplicates across the different tools, and some are true, high priority vulnerabilities. Now your security team needs to quickly determine which vulnerabilities need attention and how to prioritize them to resolve issues quickly. The Building Security in Maturity Model (BSIMM) 11, shows “the median ratio of full-time SSG [software security group] members to developers is 0.63% (1 SSG person for each 159 developers).” In other words, there are large development teams consistently pushing out software updates, and very few application security engineers to analyze and prioritize the issues. If you’re pushing out new code five times a day — or more — you need to prioritize vulnerabilities quickly and be able to show stakeholders why you fixed one over another.
How many people are on your security team?
Chances are you don’t have a large application security engineer team within your organization. For years there’s been a gap between the demand for cybersecurity experts and the number of people available to fill those roles. Technology can help reduce the need for some of those experts; for example, Application Security Orchestration and Correlation (ASOC) solutions deliver increased efficiency, scalability, and accountability to the AppSec process within organizations.
While tools can certainly help, you’ll still need a team to quickly identify the flaws and bugs that the security tools uncover. How many application security engineers you need depends on the number and size of your applications, how frequently you release, how complex the applications are, and the level of risk inherent in the application.
How do you prioritize which flaws to fix?
In enterprise organizations, there are multiple business units and application owners competing for both engineering and security resources. There are also frequently internal policies that dictate software can’t be released until all critical vulnerabilities have been resolved. Understandably, application owners want the full attention of security and engineering teams so they can quickly determine which vulnerabilities need to be fixed and move their application to release.
Unfortunately, it’s impossible for software security engineers to review every possible issue reported by testing tools, and even once they’ve reduced the results to an accurate list of critical vulnerabilities, they still need to balance the ongoing needs of multiple stakeholders. The engineering or security lead will need to explain what they are doing to resolve critical vulnerabilities, which vulnerabilities they’re resolving first, and why. To do that, they need a solution that helps them navigate the flood of vulnerability data, analyze the severity of the issue, and determine the impact of the issue on the business. Armed with that information, they can make the appropriate determination of how much time is required to fix the issue, balance it with the time and security resources available, and share how they came to that determination.