Companies that find themselves with old, vulnerable code in their environment risk lacking the resources to patch it. Most organizations will find themselves in this situation at some point, whether it’s because they’re using open source programs or outdated programs. But there are ways businesses can get a handle on the problem, including prioritizing, automating and mitigating issues.
The problem of old and broken code is pervasive in businesses. Vulnerable code in general is a problem – according to one Veracode report released earlier this year, 74% of apps analyzed over the past year had at least one security flaw and 19% had a high-severity vulnerability. And the older the application, the more likely it is to have problems, says Chris Eng, director of research at Veracode. When new applications are scanned for the first time, 32% of them have security vulnerabilities. After five years, this figure rises to 70%. When an application is 10 years old, there is a 90% chance that it has at least one security vulnerability.
One reason for the increase in problems is that new code is added to applications: according to Veracode, applications grow by an average of 40% each year for the first five years. Each new line of code adds the potential for errors, and increased complexity makes it more difficult to detect and fix problems.
Components are also a big part of the problem. “Most developers, when they download an open source component and integrate it into their application, never go back and update it,” Eng tells CSO. To be more precise, 79% of the time, old open source components are not updated. Over time, new vulnerabilities continue to be discovered, even if a new line of code is never added. “The security situation of this application continues to deteriorate,” explains Eng.
According to Synopsys open source security and risk analysis released in February, 96% of all commercial codebases contained open source components – and 89% contained outdated open source code more than four years old. The issue is so important to application security that vulnerable third-party libraries are present. OWASP Top Ten List security risks of web applications.
The solution seems simple at first glance: just replace the component with the most recent version. This is easy when the code base is relatively new. “If a patch comes out tomorrow, it’s pretty easy to do,” Eng says. “But if I linger for years and get multiple versions, then the amount of effort required to be up to date is enormous.”
With each new update, especially major releases, there are more opportunities for behavior changes. Key features may be outdated. This means that if the component is updated to the latest version, the application as a whole may stop working. “When multiple major releases are late, there will definitely be outages,” says Eng.
When organizations find themselves in this situation, the best thing to do is to focus on the most critical issues first.
Identify and prioritize bad code that poses the highest risk
Different vulnerabilities can have different impacts on an organization. In some cases, there may be a security vulnerability in a particular function, but the application does not use that function, thus making a system less vulnerable to that particular vulnerability. Then there is the question of whether exploits have been observed in the wild and what types of attack activities are being observed.
Context is also important. “If you have an archaic, very old application, but it’s deployed on a security network that no one has access to, maybe one or two people on the network, then its impact is not as high “, Adam Brown, management consultant at Synopsys Software Integrity. The group informs CSO. “Even though it’s classified as a very high-risk critical vulnerability, if you spend a lot of money fixing it, who benefits?
In regulated industries, there may also be compliance issues related to code correction, since any changes must be verified. This tends to happen in the financial and healthcare industries. For some older applications, it may make more sense to replace rather than repair. “Sometimes it’s easier to create a new model and slowly migrate to it than to try to fix the old one,” Brown says. “You can spend time patching a critical vulnerability, but ultimately what you should be doing is figuring out how to switch platforms.”
Synopsys published its own software vulnerability report earlier this month, based on 12,000 tests conducted over the past three years, focused on web and mobile applications. According to the report, 92% of applications had vulnerabilities, with 33% in the high or critical severity categories.
When setting their priorities, businesses must also be careful not to be influenced by current headlines. “Organizations tend to assess immediate threats based on the current level of media attention rather than the actual level of risk,” says Mike DeNapoli, director and cybersecurity architect at Cymulate, a cybersecurity vendor. Cymulate has published a report last March, it tracked the state of cybersecurity effectiveness, which also highlighted the presence of insecure code in organizations. According to the report, average risk scores deteriorated compared to the previous year.
The biggest problem with prioritizing software patches is that there is often a disconnect between security controls and business risk outcomes, according to Kayne McGladrey, senior IEEE member and field CISO at Hyperproof, a security and risk management company. That makes it harder to get management support, he says. Code maintenance and dependency management are not sexy topics. Instead, executive interest tends to focus “on the financial or reputational implications of downtime,” McGladrey tells CSO.
“To address this issue, organizations must document and agree on the business risks associated with first-party and third-party code. Next, they must determine the level of risk they are willing to accept in areas such as reputational damage, financial damage or legal oversight. Once there is consensus at the management level, owners of critical systems should work to identify and implement controls to reduce these risks,” says McGladrey.
Once a business has identified its highest priority problems, the next step is to solve them. Unfortunately, this is not always possible and organizations should consider other measures.
When the only answer is mitigation
When dealing with legacy systems, no one may have the knowledge to fix the code. According to a investigation published last November by technology services company Advanced, 42% of companies that use mainframes say their most important existing language is COBOL, and another 37% still use Assembler.
“It doesn’t matter what the job market is. It’s hard to find people with outdated programming language skills like COBOL,” says Paul Brucciani, cybersecurity advisor at WithSecure.
Another problem is the loss of source code. “You would be surprised by the (number) of organizations running on old software that can’t be updated because they lost the source code,” Brucciani tells CSO.
In some cases, applications are too important to touch because the risk of breaking them is too high and replacing them would cause too much disruption. “All legacy code and applications cannot be removed once discovered. In many cases, critical business processes rely on functionality and workflows performed by existing systems,” says Cymulate’s DeNapoli.
Software vulnerabilities may also go unpatched due to a lack of time or resources, or for compliance reasons, but they still pose a risk if exploited. In these cases, companies must put mitigation measures in place around vulnerable systems. Companies will need to resort to other strategies, such as implementing or strengthening compensating controls.
Zero Trust architectures, network segmentation, and increased emphasis on authentication can help reduce the risk of exploiting a vulnerable application. “There is a general tendency to put everything behind an authentication layer,” explains the Veracode engineer. “This happens regardless of the age of the code.”
Other mitigation strategies include encryption, firewalls, security automation, and dynamic data backups.
Automation to find old code and create more secure code
The latest solution to the problem of vulnerable old code involves new advances in artificial intelligence. We already have generative AI tools that can write new code, but vendors are also working on specialized AIs specifically trained to fix vulnerabilities. “The AI can suggest a fix, and then developers can change it a little,” Eng says.
The problem is that when companies use the big public language models, those models are trained on everything, including the wrong things. “As they used to say: waste goes in, waste goes out. Inevitably, the code generated by these models will also contain vulnerabilities. So the code will be produced faster, but it will still contain errors,” adds Eng.
Veracode builds its own AI based on its own verified code. “We generate vulnerable code and good code, and train the model on each of these categories,” explains Eng. “We then know for sure that what’s coming out isn’t pulled from some random developer’s Github repository.”
Veracode Fix was released last April, and according to the company, the product can generate fixes for 72% of vulnerabilities found in Java code, which can significantly speed up companies’ patching efforts.
At some point, large companies will likely want to build their own custom AI tools. “They want to generate fixes in the style of code they’re using,” says Eng.
But that doesn’t mean businesses should sit back and wait for AI to solve every problem. “With the amount of security debt most organizations have, even if you work on only the most serious tasks now, you won’t run out of things to do,” he says.
