3 Key Takeaways from the State of Software Security  2023 Report

It’s one of our favorite times of the year – the unveiling of our annual State of Software Security (SoSS) report. Software security issues can have devastating effects on organizations, damaging their financial stability and reputations. That’s why our research this year centered on a crucial question: what can be done to avoid introducing security flaws in the first place? We dug into 17 years of data and analyzed three-quarters of a million applications to provide security and development teams with concrete steps they can act on together to minimize risk, protect applications, and meet industry regulations. Plus, we turn some conventional wisdom about open source on its head. Let’s dive in. 

1. 32 percent of apps contain security flaws at the first scan, and by the five-year mark, this jumps to 70 percent. 

By the time they move into production, nearly one-third of all applications have security flaws, and applications grow by about 40 percent year on year irrespective of their original size. As these apps grow and age, flaws accumulate, further driving up technical or security “debt.” Nearly 70 percent of applications contain at least one security flaw by the time they have been in production for five years, and things do not get any better after that. By the time an application is 10 years old, there is a 90 percent chance that it has at least one flaw.  

It’s interesting to see that new flaw introductions happen in fits and starts – they don’t line up evenly with an application’s growth over the software development lifecycle. That said, the five-year mark may be the optimal age for examining whether it's time for an application’s retirement party, based on the numbers. 

2. Certain choices made early in development can measurably improve security posture in the long run. 

In any given month, we found that there is a 27 percent chance that new flaws will be introduced in an application. We set out to pinpoint specific steps teams could take to drive down this probability and minimize the number of new flaws introduced overall.  

By digging around the data, we found that more frequent scanning reduces that 27 percent baseline. In fact, a scan in any given month reduces the probability of new flaws being introduced by .4 percent. When months are skipped between scans, there’s a higher chance of finding flaws during the next scan.  

Diversified testing methods are also important, since top flaws found in applications vary by tool. Static, dynamic, and software composition analysis (SCA) find completely different flaws in their top five flaw types. If you only focus on a single type of scanning, you may be missing some hard-to-identify flaws that can only be detectable through another type of scan. Notably, organizations that initiate scans via API reduce the probability of flaws being introduced by two percent in any given month.  
 
Finally, organizations that emphasize hands-on developer education and training measurably reduce the probability of flaws being introduced. In addition to the reduction in probability, completion of ten Security Labs trainings (which are highly experiential) correlates to a 12 percent reduction in the number of flaws introduced when flaws are introduced into the application. 

3. Open source may be extremely fragile, so proceed with caution.  

Given the current focus on software supply chain risk and the Software Bill of Materials (SBOM), we dedicated part of this project to researching open-source software. We wondered, “How common are 10-year-old libraries? What is considered a ‘young’ or ‘old’ library?” An exploration of 30,000 open-source repositories found half of libraries we examined to be at least five years old, with 10 percent of them passing the decade mark. Interestingly, 10 percent of repositories had their last commit around six years ago, and the same percentage of repositories had only a single contributor. 

In a way, this data opens more questions than it answers. Are apps more fragile when they depend on libraries with a single point of failure (a single developer) who hasn't touched it in years...or are they fine? Our research into this question continues. For now, since there’s no question that open source is here to stay, the data underscores a widespread need for more robust frameworks for managing code and automated approaches that can help teams identify vulnerabilities – even those beyond the National Vulnerability Database – earlier, so they can implement more effective safeguards. The report also includes three suggestions for reducing the risk posed by open-source libraries. 

Get the Full Story in the New State of Software Security 2023 Report  

What does this all mean for you? Tackling technical debt by remediating security flaws as early and quickly as possible can save teams major headaches – and hefty “interest” payments in the form of the time it takes to remediate accumulated flaws – down the road. Thankfully, there are data-driven, concrete steps teams can take to help meet this objective, including increasing scan cadence, scanning via API, and implementing developer education. The report also breaks out the top flaws by language, so you can know exactly what you to focus on depending on the language or languages you use. 

Want the full story? Read the report now, because an ounce of prevention is indeed worth a pound of cure.