DEVOPSdigest

The meteoric rise of artificial intelligence (AI) in the past few years has been a boon for software developers, who quickly embraced AI's ability to help them create code more quickly. But the other edge of the AI sword is that its code isn't always secure, because AI models trained on flawed code, which exists in plenty of applications, are only going to repeat the same mistakes.

As AI-generated code proliferates, it compounds an already common problem, filling code bases with insecure code that will likely become security debt, increasing the risks to organizations.

Just like financial debt, security debt can accrue quickly over time, the result of organizations compromising security measures in favor of convenience, speed or cost-cutting measures. Security debt, introduced by both first-party and third-party code, affects organizations of all sizes. More than 70% of organizations have security debt ingrained in their systems — and nearly half have critical debt.

Over time, this accumulated debt poses serious risks because, as with financial debt, the bill will become due — potentially in the form of costly and consequential security breaches that can put an organization's data, reputation and overall stability at stake.

With organizations creating more code than ever as they strive to meet the demand for speed and innovation, addressing the threat of security debt has never been more critical.

Language Matters in Identifying Security Debt

A key to eliminating security debt is in identifying where flaws are most prevalent, and which pose the most serious risk. Programming languages come into play here.

The Language Snapshot in Veracode's 2024 State of Software Security report found that the prevalence of security debt varies widely among languages. For example, security debt was most common among organizations running .NET applications, being present in 75% of them, followed by Java at 64% and JavaScript at 54%. However, with critical security debt, .NET and Java traded places, with critical debt present in 51% of Java applications and 45% of .NET apps. JavaScript again had the lowest rate of critical debt, at 30%.

Another important factor is where flaws come from. The Snapshot found that although most security debt exists in first-party code written by in-house developers, the majority of critical debt arrives via third-party code, where it is present in 80% of Java apps and 63% of JavaScript apps.

Languages also showed differences when it comes to remediation. About 45% of first-party flaws in Java were still present after a year, at which point they meet the definition of security debt. JavaScript and .NET had lower percentages of flaws (both first- and third-party) that stuck around long enough to be classified as debt.

3 Steps to Reducing the Risk of Security Debt

Amid the dark clouds gathering over security debt, there is one silver lining. The number of high-severity flaws in organizations has been cut in half since 2016, which is clear evidence that organizations have made some progress in implementing secure software practices. It also demonstrates the tangible impact of quickly remediating critical security debt.

How can organizations build on that progress to further reduce security debt?

Here are the steps to take:

Step 1: Assess and Prioritize Risks

The first thing to do is conduct a thorough assessment of your organization's security risks, which involves identifying vulnerabilities, evaluating existing security controls and understanding potential threats. A comprehensive understanding of your security landscape will allow business leaders to prioritize areas that require immediate attention.

Step 2: Implement Robust Security Controls

Once you've identified the critical security risks, implement controls to mitigate those risks.

Patch management is a key strategy, ensuring that the organization's infrastructure and systems are up to date with the latest security patches and updates.

Educating employees and developers about cybersecurity best practices is also essential. If developers are to prioritize the most important fixes for critical security debt, they need to understand what it is, where it exists and how to remediate it. A lack of regular security training creates friction between development and security teams, hindering efforts to efficiently secure applications. Veracode's research found that 48% of flaws in applications turn into security debt when developers lack security labs training.

Step 3: Continuously Monitor and Improve

Like any other aspect of security, reducing debt is an ongoing process. Implementing the right security controls is just the beginning — leaders must regularly assess how well controls are working and be ready to adjust when necessary.

A powerful security monitoring system will provide real-time visibility, establishing a feedback loop that encourages employees to report security incidents or potential vulnerabilities. It will also support regular security audits and penetration testing for evaluating the effectiveness of security controls.

Continuous monitoring also must be accompanied by continuous remediation. The report found a clear connection between speed of remediation and the reduction of critical security debt. After dividing remediation speeds for active applications into equally sized categories of slow, medium and fast, the report found that those in the fast category had security debt in 50% of applications and critical security debt in only 5%. The slow category had security debt in 90% of applications and critical security debt in nearly a quarter of them.

Conclusion

Software code written in house, generated by AI or acquired from third parties all have one thing in common — security flaws that exist in various degrees that can linger long enough to become security debt. The language used in development has a strong bearing on the likelihood of security debt, including critical security debt, as does whether the code is first party or third party.

Different languages have inherently different security postures, environments and controls, so it's critical for developers to compare how their languages perform and also understand their security postures. Having identified the source of debt, particularly critical debt, organizations can take tangible steps to prioritize risk and in implementing controls and procedures to reduce the risk of security debt throughout their landscape.