Living in a world filled with cyber threats, ongoing compliance regulations, and frequent data breaches can be daunting for any organization. It can be even more daunting since many organizations struggle to adequately address security debt – the cost of overdue work necessary to address existing vulnerabilities in software, systems, or applications.
For our annual State of Software Security 2023 report, we crunched fifteen years of data to better understand why flaw introduction occurs during application lifecycles and what can be done to prevent or slow the accumulation of security debt. The results of this study will help DevOps and application security teams reduce risk efficiently as they continue to sharpen their practices.
Why flaws build up
The average application grows at about forty percent per year for the first five years, regardless of its original size. Interestingly, the correlation between application growth and the introduction of flaws is quite complex, and there is no direct correlation between increase in application size and flaw introduction. Meanwhile, flaw accumulation continues to pile up all the way to the ten-year mark and beyond. It’s also worth noting that there is a 90 percent chance that an application has at least one flaw by the time it is ten years old.
Unlike application size, we do know that there is a correlation between flaw introduction and the age of applications. As seen in the report above, nearly one-third of applications enter production with security flaws. The percentage of applications with new flaws drops shortly after the initial security scan before beginning to climb again around the one-and-a-half year mark, forming a “honeymoon phase” when fewer new flaws are introduced. After this one-and-a-half year point, flaw introduction then continues to climb again until year five.
Chris Wysopal is Co-founder and Chief Technology Officer at Veracode.
Which factors prevent security debt accumulation
The introduction and accumulation of flaws, and thus security debt, is affected by scan frequency, scan type, and developer education. Our examination showed us that, in any given month, there is a 27 percent probability that an application will introduce one or more new flaws every month. It also showed us that this 27 percent chance can be influenced by certain factors.
Specifically, scan frequency can make the 27 percent chance increase or decrease depending on the cadence. For example, if an application has been scanned the month before, it is .4 percent less likely to introduce one or more flaws this month. On the other hand, for every month’s delay in scanning, the likelihood of flaw introduction increases by 1.3 percent, which piles up quickly. At six months since the last scan, the likelihood of flaws being introduced is +7.8 percent.
Additionally, automated scanning of applications via Application Programming Interface (API) reduces the probability of flaws being introduced in a given month by two percent. Developer education also plays a large role in preventing the accumulation of security debt; those who completed 10 hands-on application security training sessions in an immersive developer training tool using real-world vulnerabilities saw a reduction in the probability of introducing security flaws as they code by 1.8 percent in any given month.
How open-source libraries enter the picture
Log4j served as a wake-up call to the risk of building applications using open source libraries that are outside of a developer’s control. It was also a wake-up call to how leaving security debt unaddressed can make urgent issues take an egregious amount of time to fix. Trying to patch one library could cause another to break and so on.
Determining whether or not an open source library is safe to use is a complex issue that depends on several considerations, including the open source repository and its owner, the contribution frequency, and other intangible factors. In examining nearly 30,000 repositories actively being used in production code, we found that fifty percent had not had a commit—a change to the source code—in the last year, and ten percent had not one for almost six years. Half of the repositories scanned had more than ten contributors, and ten percent had more than 72 developers. This data shows us there is still plenty we need to learn about the open source ecosystem to qualify best practices. What we do know is that automating security into the build process when it comes to open source code, specifically Software Composition Analysis (SCA) that leverages multiple sources for flaws, will make addressing the next Log4j much more manageable.
Conclusion
Tackling security debt and reducing risk is easier when developers and security teams are empowered to address flaws early and often using multiple tools and techniques. Businesses should prioritize security training to provide understanding of which vulnerabilities are most likely to be introduced, as well as ways to prevent introducing flaws altogether. Furthermore, establishing a protocol for application lifecycle management that incorporates transformation, resource allocation, and organizational controls enables ongoing review of the measures involved in continuous product engineering.
An application is the result of thousands of manhours and can be representative of a company’s success and reputation. Protecting the security of that application is too important to leave to passive measures. Instead, by utilizing the right technology and DevSecOps practices, developers can dedicate more time to doing what they enjoy–building software rather than chasing flaws.
