The last few days I have looked at ways to track open security issues here at my work with the University of Oslo. My idea is that it should be possible to use the information about security issues available on the Internet, and check our locally maintained/distributed software against this information. It should allow us to verify that no known security issues are forgotten. The CVE database listing vulnerabilities seem like a great central point, and by using the package lists from Debian mapped to CVEs provided by the testing security team, I believed it should be possible to figure out which security holes were present in our free software collection.
After reading up on the topic, it became obvious that the first building block is to be able to name software packages in a unique and consistent way across data sources. I considered several ways to do this, for example coming up with my own naming scheme like using URLs to project home pages or URLs to the Freshmeat entries, or using some existing naming scheme. And it seem like I am not the first one to come across this problem, as MITRE already proposed and implemented a solution. Enter the Common Platform Enumeration dictionary, a vocabulary for referring to software, hardware and other platform components. The CPE ids are mapped to CVEs in the National Vulnerability Database, allowing me to look up know security issues for any CPE name. With this in place, all I need to do is to locate the CPE id for the software packages we use at the university. This is fairly trivial (I google for 'cve cpe $package' and check the NVD entry if a CVE for the package exist).
To give you an example. The GNU gzip source package have the CPE name cpe:/a:gnu:gzip. If the old version 1.3.3 was the package to check out, one could look up cpe:/a:gnu:gzip:1.3.3 in NVD and get a list of 6 security holes with public CVE entries. The most recent one is CVE-2010-0001, and at the bottom of the NVD page for this vulnerability the complete list of affected versions is provided.
The NVD database of CVEs is also available as a XML dump, allowing for offline processing of issues. Using this dump, I've written a small script taking a list of CPEs as input and list all CVEs affecting the packages represented by these CPEs. One give it CPEs with version numbers as specified above and get a list of open security issues out.
Of course for this approach to be useful, the quality of the NVD information need to be high. For that to happen, I believe as many as possible need to use and contribute to the NVD database. I notice RHEL is providing a map from CVE to CPE, indicating that they are using the CPE information. I'm not aware of Debian and Ubuntu doing the same.
To get an idea about the quality for free software, I spent some time making it possible to compare the CVE database from Debian with the CVE database in NVD. The result look fairly good, but there are some inconsistencies in NVD (same software package having several CPEs), and some inaccuracies (NVD not mentioning buggy packages that Debian believe are affected by a CVE). Hope to find time to improve the quality of NVD, but that require being able to get in touch with someone maintaining it. So far my three emails with questions and corrections have not seen any reply, but I hope contact can be established soon.
An interesting application for CPEs is cross platform package mapping. It would be useful to know which packages in for example RHEL, OpenSuSe and Mandriva are missing from Debian and Ubuntu, and this would be trivial if all linux distributions provided CPE entries for their packages.