Code rot. Software decay. Software rot. All of these terms describe the gradual deterioration of software quality over time.
Plenty has been written about code rot.
However, here we’ll explore the connection between ‘old code’ and third-party risk exposure.
What it is.
Code rot is legacy software that is repeatedly patched and manually configured and often riddled with bugs. Over time, software systems, many of which are tried and true, degrade in efficiency, performance, and security.
Think of code rot as code that has been stuck in time. The world around it is still moving forward with innovations, enhancements, and features. Still, the code rot is stuck in the past, not getting security updates, performance improvements, or any sort of modernization.
How to spot code rot.
Heimdal Security presents a view on the ‘hallmarks’ of code rot, pointing out that IT staff deploying a software product can smell it from a mile away.
Upgrades to the new software are difficult. The difficulty stems from code that is kluged over time, with interdependencies that no longer exist. This ‘fragility’ manifests in software deployments plagued with complexity and errors.
“We see threat actors riding into a victim’s environment in a Trojan Horse, inside highrisk vulnerabilities in the software itself. Kill switch malware obfuscated in code vulnerabilities is what keeps me up at night.” Dan Rodriguez, Senior Systems Engineer, Cohesity
Code rot and security risk.
Software code that is poorly organized, contains code that is not actively used, or contains code for older features or connections that are not used and not secure, represents a significant security risk.
Vulnerable or fragile code presents a playground for clever malware architects.
First of all, the number of bugs or errors in the software deters the customer from rapidly deploying the newest version due to the dependencies that risk breaking operations.
Secondly, a preponderance of old or unused code gives malware more places to hide, like a Trojan horse.
Third, old code results in slower performance even in the absence of a breach. If the software is critical—or essential to the operation of a system—then serious damage could result if it malfunctions or slows in performance.
Finally, there is a risk to brand reputation. Larger, older companies are especially at risk of brand damage if their software code contains symptoms of code rot. This risk opens the door for newer competitors to present a sleeker, faster alternative, which is often less costly and more attractive than ‘legacy’ software.
Guidance for developers.
When software developers create new features, sometimes those are for usability, and sometimes they are for security, such as by default multi-factor authentication.
The CISA Secure by Design guidelines prescribe specific tactics during the software build and product development processes. These include memory-safe programming languages; hardware features; well maintained software libraries; parameterized queries; and static and dynamic application security testing. CISA also recommends vulnerability disclosure programs; cybersecurity performance goals, common vulnerability (CVE) completeness, and the creation of Software Bills of Materials. Figure 1.
SBOM guidance.
In September 2025, CISA co-published “A Shared Vision of SBOM for Cybersecurity,” along with the government cybersecurity leadership of many other nations, including India, Australia, New Zealand, Canada, France, Germany, Italy, the Czech Republic, Japan, Korea, and Singapore.
The guidance included the Value Proposition right at the beginning, pointing out that the transparency offered by the SBOM allows one to map a software product’s dependencies to existing vulnerabilities and continuously monitor for new exploitable vulnerabilities.
SBOMs’ transparency allows organizations to identify risks and respond with tailored mitigations more rapidly. CISA used, as an example, the Log4Shell vulnerability in a 2021 open source code library that resulted in widespread exploitation by threat actors. Further, CISA illustrated the SBOM’s effect of being able to identify the specific vulnerability quickly and thus more rapidly mitigate it.
Future direction of SBOM
CISA requested public comments on its updated SBOM guidance in the fall of 2025. Watch this blog for our perspective on how the SBOM product and process can continue to mature, strengthening the trust relationship between software producers and consumers.
Click here to learn more about how Cohesity helps organizations tackle code rot and strengthen their security posture.
Related News:
Cohesity Identity Resilience Unifies Data and Identity Protection
Cohesity Advances Cyber Resilience with New Security Innovations
