Current strategies of scanning for and patching vulnerabilities in software leave a huge and highly-exploitable security gap.
Recent research by RunSafe Security partners show that current strategies of scanning for and patching vulnerabilities in software leave a huge and highly-exploitable security gap. When measured against NIST CVEs (Common Vulnerability Enumerations from the National Vulnerability Database), the researchers found that:
- Memory vulnerabilities are the most frequent CVEs reported in the database, making up 40% of the total, and are ranked as the #1 software weakness in MITRE’s current CVE rankings
- 59% of these memory CVEs have exploits available
- They produce the highest CVSS consequence scores, in the 7.2 to 9.8 out of 10.0 (the High and Critical ranges), in NIST’s Common Vulnerability Scoring System. In layman’s terms these are the vulnerabilities that, if exploited, can cause the most damage to an organization.
- Only 2.5% (15 of 592) of all Linux CVEs are currently detected by scanning tools, leaving a massive 97.5% security gap.
Does this mean scanning and patching are no longer relevant? Obviously they are – they are essential foundation elements for effective cyber security and hygiene.
What it does mean is that other solutions are required to fill the gap, to mitigate vulnerabilities before they are detected, reported, or patched. RunSafe calls this category “software immunization,” by which code can be inoculated against vulnerabilities before deployment. We believe this “third leg of the stool” is an essential new approach that can increase software security by a full order of magnitude, and in many specific use cases completely eliminate the most dangerous weakness in software today, memory-based vulnerabilities.
Complement Existing Security Scanning Tools
According to Thomas Scanlon at Carnegie Mellon’s Software Engineering Institute, “84% of software breaches exploit vulnerabilities at the application layer” (https://insights.sei.cmu.edu/sei_blog/2018/07/10-types-of-application-security-testing-tools-when-and-how-to-use-them.html). This has driven an entire domain of application security testing tools and techniques. Identification and remediation of these vulnerabilities has become extremely valuable in the marketplace – the vulnerability scanning software company Snyk raised a $200M round of venture capital in September 2020 that values that company at $2.6B (https://techcrunch.com/2020/09/09/snyk-bags-another-200m-at-2-6b-valuation-9-months-after-last-raise/).
In its definition from CSO magazine, “vulnerability scanning is an automated activity that relies on a database of known vulnerabilities such as CVE/NVD – scanning vendors [such as Snyk, Qualys, Rapid7, and Tenable] maintain more complete databases…”(https://csoonline.com, “What are vulnerability scanners and how do they work?,” Lucian Constantin, April 10, 2020). Despite intense investment in this space, however, the research showed that scanning tools only detect 2.5% of all Linux CVEs. Further, the NVD CVE and public vulnerability databases miss many vulnerabilities, only catching 60% of the vulnerabilities Snyk tracks.
The increasing prevalence of open source components in every area of software and firmware development adds to the scanning gap. According to Snyk’s 2019 open source security report (https://snyk.io/opensourcesecurity-2019/), 37% of open source developers don’t do any sort of security testing during CI, and the median time from when a vulnerability was added to an open source package until it was fixed was over 2 years.
By adding a software immunization step for memory vulnerabilities in CI/CD pipelines before testing, when scanning typically takes place, developers can immediately reduce their vulnerability management workload by 40%. This will, in turn, allow scanning software developers (and pen testers) to refocus 40% of their attention and resources on other, unsolved vulnerability classes.
Make Patching More Effective
Patching, in general, comes in two flavors. Every release of every software product in all time contains bugs and vulnerabilities. Planned patches prioritize fixes to known bugs in the normal update cycle. Emergency patches, however, arise when high-severity bugs or vulnerabilities are identified that must be fixed before the release date of a standard update.
Planned updates are largely automated in CI/CD workflows, but can still have very significant costs, especially when infrastructure, OT, SCADA, or iOT systems are in the mix.
Emergency patching slows down development by redirecting bandwidth away from planned sprints and backlog priorities to fix severe technical debt. Interrupting new feature enhancements and potentially planned bug fixes, emergency patches reduce release velocity, with many associated downstream costs. They also force additional releases outside normal update windows, diverting devops cycles and in some cases requiring significant unplanned costs to actually implement the fixes.
Immunization renders memory vulnerabilities inert, allowing development organizations to contain fixes within planned update cycles, and even enabling teams to avoid some vulnerability fixes altogether, since the chance of their being exploited has been driven to zero.
Summary
Scanning and patching are constantly improving, aided by continuous investment and progress by devops automation companies. They are essential components of cyber security and software hygiene. The attack surface they address, however, is like the literal tip of the iceberg, with 97.5% of known Linux CVEs going undetected and a rising tide of unknown vulnerabilities coming from the “vast sea of potentially vulnerable components” associated with the ascendance of open source.
Complementing scanning and patching with a third discipline, software memory immunization, can reduce exposure dramatically by making an entire class of vulnerabilities unexploitable. Using memory protection techniques like those pioneered by RunSafe, organizations can inoculate compiled code from 40-70% of the most dangerous weaknesses in software today.