CVE: 10 years and more than 38,000 software vulnerabilities catalogued
Connecting state and local government leaders
The Common Vulnerabilities and Exposure dictionary celebrates its 10th anniversary as a tool for identifying and sharing information about security vulnerabilities in software.
On Sept. 29, the Common Vulnerabilities and Exposures database celebrates its 10th anniversary of giving researchers, software vendors and developers a tool for identifying and sharing information about security vulnerabilities in software.
CVE now contains more than 38,000 entries, each containing an agreed-upon common name to identify the vulnerability along with a brief description and references to other published information. There is no sign that its growth will stop.
“As long as people keep creating software, there will be vulnerabilities that need to be tracked,” said Steve Christey, CVE editor at Mitre, which developed the database.
Since its debut in 1999, the CVE has become accepted by vendors, the security community and users as an authoritative source for common information about vulnerabilities. Vendors that would not dream of referencing a competitor’s information about a vulnerability now can use CVE identifiers. The National Institute of Standards and Technology includes it as one of the six accepted protocols in its Security Content Automation Protocols and uses CVE in its National Vulnerability Database. Organizations, including the Defense Department, require CVE compatibility in the security tools they purchase. For the past six years, the Homeland Security Department’s National Cybersecurity Division has funded the project.
The International Telecommunications Union now has CVE on its agenda as a recommended standard. “It will be an X-series standard in the coming year,” said Robert Martin, Mitre’s CVE outreach and compatibility lead.
The notion of a standard way of identifying security vulnerabilities in software seems like common sense now, but a decade ago, the need was not that obvious. Christey ran into the problem of integrating vulnerability information from multiple sources when he was preparing to purchase a vulnerability-scanning tool and realized he was trying to compare apples to oranges to plums.
“I couldn’t tell whether one tool was testing the same vulnerability as another tool,” he said. “The tools also counted vulnerabilities differently, and I couldn’t define how many vulnerabilities one was testing.” It turned out that one tool that claimed to scan for 400 vulnerabilities was looking at about the same number of discrete problems as a tool that claimed only 200.
He and Mitre’s David Mann presented a paper on the problem and suggested a common system of identification at a workshop in January 1999, and they received a positive response from the community. During talks about setting up the scheme, the job fell to Mitre, a not-for-profit, federally funded research and development company.
“We realized that Mitre was well-positioned to do this,” Christey said. The company does not compete with the vendors, and it is chartered to serve the public interest.
By late September 1999, the theory had become a reality.
“On the technology side, there was not a lot of challenge because we kept it as simple as possible,” Christey said. But the scheme has evolved, and an editorial board with representatives from industry and academia continues to refine the structure.
“We find that we have to revisit our existing content decision several times a year,” Christey said. About five years ago, they decided to include information on wireless vulnerabilities, and just a couple of years ago, the question of vulnerabilities for supervisory control and data acquisition systems came up.
A companion program, the Common Weakness Evaluation listing of common programming problems that create vulnerabilities, was started in 2005. From it, a list of top 25 weaknesses was developed in an effort with the SANS Institute to prioritize programming problems.
Although not as dynamic as the CVE database, the CWE also is evolving.
“We still are uncovering what the underlying weaknesses are,” Christey said. “New technologies come along all the time.” One example: Until the Web became a vector for delivering malware, cross-site scripting was not an issue, for instance. Now, Web 2.0 is opening new areas of concern.