Java, JavaScript, .NET: Which Has the Riskiest Security Debt?

In the realm of secure software development, managing security debt is crucial. The following data highlights a concerning trend in the accumulation of critical security debt, particularly in the popular programming languages of Java, JavaScript, and .NET. Let’s dive into this new research and explore options for managing the prioritization dilemma we’re seeing. 

The Prioritization Dilemma Revealed by Security Debt Accumulation 

Prioritizing software vulnerability remediation is about focusing on those vulnerabilities with the potential to cause the most significant damage. The challenge for developers is not merely identifying these flaws but prioritizing which to address first. This prioritization is crucial in an environment where resources are often limited, and not all security issues can be resolved immediately.  

The focus should be on critical flaws that could turn into severe security breaches if left unremediated. Unfortunately, that is not the case we see in the data presented next. 

Security Debt Accumulation by Severity in Java, JavaScript, and .NET 

The accumulation of security debt varies significantly across different programming languages. For the purposes of the research, we define security debt as flaws that remain unremediated for over one year.  

Each chart below shows the remediation patterns of critical flaws vs. non-critical flaws (i.e. low/medium severity). If remediation were being prioritized based on criticality, you’d expect to see a sharp vertical drop in the “Critical” curve towards the left side of the chart, followed by a gradual descent toward 0% which would indicate all those flaws were fixed. For the “Low/Medium” curve, you’d expect it to start out more horizontal since developer time would be spent fixing the critical items first. Then at some point in time it would start to drop, asymptotically approaching some non-zero percentage since realistically most teams will not fix all their low severity flaws and will often fix medium severity flaws selectively. 

As you will see, actual developer behavior looks completely different. Regardless of language, the curves follow nearly identical paths. Often, low and medium severity flaws are being fixed with greater urgency than critical flaws – the opposite of what a security practitioner would want to see.

Figure 1: Security Debt Accumulation by Severity in Java Applications 

In the figure above, Java, with 51% of critical flaws turning into security debt at the one year mark, is at the forefront of this dilemma. This high percentage is particularly alarming given Java's extensive use in enterprise environments, where security breaches can have severe repercussions.  

Figure 2: Security Debt Accumulation by Severity in JavaScript Applications

JavaScript, while having a lower percentage of critical flaws at 38%, still presents substantial risks due to its extensive presence in web applications. The dynamic nature of JavaScript development can lead to overlooked security practices, thus accumulating debt. 

Figure 3: Security Debt Accumulation by Severity in .NET Applications

The story looks a little different in Figure 3 regarding .NET. Beyond having the lowest percentage of critical flaws at 28%, .NET shows a better handle on prioritization given that low/medium severity flaws have a 12% higher chance of becoming security debt than critical flaws. Whereas in both Java and JavaScript, we see critical flaws having a higher chance of turning into debt than low/medium severity flaws. 

In each of these languages, we observed a non-trivial percentage of critical flaws turning into security debt. Had teams focused on their most critical findings first, some or all of the critical debt could have been avoided. 

Recommendations for Security Debt Risk Management 

Beyond prioritization, data from our State of Software Security 2024 report shows development teams that fix flaws fastest are four times less likely to let critical security debt materialize in their applications. To effectively manage risk, implementing secure coding practices and providing training for developers goes a long way. 

In addition to developer education, AI shows promise for helping speed up remediation time. Veracode's AI-driven remediation tool, Veracode Fix, can address many Common Weakness Enumeration (CWE) categories with severity ratings ranging from medium to very high. This innovative approach, leveraging a curated set of reference patches from our security research team, enables organizations to proactively reduce security debt and strengthen their software security posture. Notably, using curated reference patches avoids the pitfall of many AI-driven code assistants that rely on unvetted open-source code to generate suggestions. 

Still, the focus must always be on prioritizing and addressing the most critical flaws first. With the support of advanced tools and a strategic approach to security, developers can significantly reduce the impact of security debt on their applications and organizations. 

For further insights into security debt by language, download our State of Software Security 2024: Language Snapshot.