Unpatched vulnerabilities are an everyday fact of life in many IT environments. Ransomware incidents like WannaCry serve as proof that enterprises are lagging behind patches. WannaCry managed to compromise more than 220,000 systems even though it exploited a known vulnerability. A known vulnerability that should have been fixed in most infrastructures, as Microsoft issued a patch more than two months before the infections hit.
The patching problem cannot be solved by finding more engineers to manually patch and test the applications. Although a single static application security testing (SAST) report could identify hundreds—if not thousands—of instances of each vulnerability, the process of running SAST and dynamic application security testing (DAST) tools to identify all the vulnerabilities in the software takes a considerable amount of time and effort—usually more than what organizations can afford.
Asking developers to remediate all vulnerabilities is a no-win proposition because many of these vulnerabilities are not located in the application code that they write and control. Even if organizations are willing to correct the vulnerabilities in their own code, applications can still be vulnerable as only 10 to 20 percent of the code that runs on the system is written by application developers.
Some of these components are closed source, proprietary components and the majority in most cases are open source. According to the latest study from Sonatype in 2017 52 billion Java open source components were downloaded from the Central Repository. That’s a 68 percent increase since 2016, showing a trend likely to continue growing.
That’s no surprise. Open source favors rapid innovation and fast deliveries and thus plays a central role in software development and lifecycle in general.
But that rapid innovation and fast delivery can come at a cost. Sonatype analyzed 1.8 million Java components available in the Central Repository and identified that 5.9 percent of them contained a known vulnerability. Researchers from Northeastern University analyzed data from more than 133,000 websites and reported that 37 percent include at least one library with a known vulnerability.
The solution to fixing these vulnerabilities sounds simple. Just patch the vulnerable component with a newer version. The reality is that this process can be difficult to manage and scale since more than ten thousand new component versions offering new features, bug fixes, and security patches are released daily. Security and DevSecOps teams are overburdened and often cannot easily cope with the vast number of patches that must be applied.
Published by Security InfoWatch where you can read the full article.
