Most people in our industry know what the acronym CVE means. For those that may not, CVE stands for Common Vulnerabilities and Exposures. According to their website, CVE was launched in 1999 as a list of common identifiers for publicly-known cybersecurity vulnerabilities found in commercial and open source software and / or firmware. What makes CVE so important is that prior to 1999, most cybersecurity vendors used their own tracking databases and vulnerability identifiers when a software flaw was discovered, which, as you can imagine, caused significant disparity since no standard was yet established. This also produced potential gaps in security coverage and little interoperability among the different databases and tools tracking the growing list of discovered software vulnerabilities. Thus, CVE was launched and today it’s an international cybersecurity community effort that has established an industry standard for common vulnerability and exposure identifiers. Looking back in 1999, there were a total of 894 vulnerabilities tracked that year. Below is a chart showing the number of software vulnerabilities recorded per year since its inception. Source It’s easy to see that the number of vulnerabilities discovered, labeled, and tracked with their own unique CVE has seen a massive spike in recent years – in fact, in 2018 alone, 16,556 vulnerabilities were identified, a 1,752 percent increase compared to 1999. Also, you’ll notice, there have already been 12,174 CVEs for this year alone. That number will likely grow before the end of 2019. When adding up all software vulnerabilities being tracked since 1999, a total of 122,774 have been identified overall. Next, let’s look at the breakdown of the number of vulnerabilities by type since 1999 as shown in the chart below. Source As we can see, Execute Code has the highest number of CVEs, followed by Denial of Service. What’s most interesting though is that the vulnerabilities discovered in commercial and open source software continues to grow over time. As a matter of fact, the latest OWASP Top 10 lists many of the vulnerabilities in the chart above as the most significant risks organizations face. Simply put, these vulnerabilities are due to the weaknesses in software caused by the humans who develop it. Another interesting aspect is that the vulnerabilities tracked by CVE have nothing to do with vulnerabilities found in software developed “in-house” by organizations who develop software for their own internal and external purposes. At the end of the day, what we can say is that the overabundance of software vulnerabilities leads to a major, industry-wide problem called “Software Exposure.”

What is Software Exposure?

Software exposure results from mistakes made in the design, coding, testing, and maintenance phases of software. Exploiting these vulnerabilities can make software unavailable or unreliable to users, or allow attackers to execute unauthorized code, read or modify data, change a user’s privileges, hide activities, or bypass security controls. In its simplest terms, software exposure is the primary cause for the majority of successful cyberattacks being experienced by organizations all over the world. Today’s attackers fully understand that software-borne vulnerabilities are the common facilitator of their successful attack campaigns and often applications developed in-house are chock full of flaws that frequently go undetected by the organizations who develop them. Once the simplest software vulnerability is exposed to the internet, the likelihood of attackers discovering it and taking advantage of it is extremely high. One could envision an attacker exploiting a simple application vulnerability allowing them to gain control over a computing system. As a matter of fact, this happens in nearly every data breach that does not include loss or abuse of user / admin credentials. Once control is obtained, upheld, and assured, the probability of an attacker using that computing system for more insidious internal attacks is almost guaranteed.

Addressing Software Exposure in the Code You Develop

No matter how or where a computing system is deployed, its running applications (software) must be hardened against all known forms of cyberattack. For example, static application security testing (SAST) should be performed to detect vulnerabilities while applications are in their uncompiled state. Interactive application security testing (IAST) should be performed to detect vulnerabilities while applications are in their run-time environment during functional testing. Finally, software composition analysis (SCA) should be performed to detect vulnerable open-source components before the application is deployed. This process needs to be continuously performed for every new code iteration (build) regardless of what the build is intended to enhance or fix. The use of SAST, IAST, SCA, and secure coding education (SCE), combined in a software security platform designed to be embedded easily within DevOps is becoming the de facto standard for organizations who develop applications in-house. This should also become the standard for commercial and open-source application development as well. It’s the only way the industry will ever be able to reduce the vulnerabilities being introduced during the software development process and turn the tides in the rapidly-rising CVE count we’re seeing.