Generated.

[homepage.git] / blog / data / 2011-01-28-cve-cpe.txt

diff --git a/blog/data/2011-01-28-cve-cpe.txt b/blog/data/2011-01-28-cve-cpe.txt
index 4d5321513b97fd6fd4f39c9372447cf6e62d421d..eefc6183577b84751879139ef92a05e8cc95c8c2 100644 (file)
--- a/blog/data/2011-01-28-cve-cpe.txt
+++ b/blog/data/2011-01-28-cve-cpe.txt
@@ -1,30 +1,30 @@
 Title: Using NVD and CPE to track CVEs in locally maintained software
 Title: Using NVD and CPE to track CVEs in locally maintained software

-Tags: english, debian
-Date: 2011-01-23 00:20
+Tags: english, debian, sikkerhet
+Date: 2011-01-28 15:40

 
 <p>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
 
 <p>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 issue are forgotten.  The
+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.</p>
 
 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.</p>
 

-<p>After reading up on the issue, it became obvious that the first
+<p>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
 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 <ahref="http://cpe.mitre.org/index.html">Common
+solution.  Enter the <a href="http://cpe.mitre.org/index.html">Common

 Platform Enumeration</a> dictionary, a vocabulary for referring to
 software, hardware and other platform components.  The CPE ids are
 Platform Enumeration</a> dictionary, a vocabulary for referring to
 software, hardware and other platform components.  The CPE ids are

-mapped to CVEs in the <ahref="http://web.nvd.nist.gov/">National
+mapped to CVEs in the <a href="http://web.nvd.nist.gov/">National

 Vulnerability Database</a>, 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.
 Vulnerability Database</a>, 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.


@@ -34,22 +34,41 @@ NVD entry if a CVE for the package exist).</p>
 <p>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
 <p>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

-<ahref="http://web.nvd.nist.gov/view/vuln/search?cpe=cpe%3A%2Fa%3Agnu%3Agzip:1.3.3">cpe:/a:gnu:gzip:1.3.3
+<a href="http://web.nvd.nist.gov/view/vuln/search?cpe=cpe%3A%2Fa%3Agnu%3Agzip:1.3.3">cpe:/a:gnu:gzip:1.3.3

 in NVD</a> and get a list of 6 security holes with public CVE entries.
 The most recent one is
 in NVD</a> and get a list of 6 security holes with public CVE entries.
 The most recent one is

-<ahref="http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-0001">CVE-2010-0001</a>,
+<a href="http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-0001">CVE-2010-0001</a>,

 and at the bottom of the NVD page for this vulnerability the complete
 list of affected versions is provided.</p>
 
 <p>The NVD database of CVEs is also available as a XML dump, allowing
 and at the bottom of the NVD page for this vulnerability the complete
 list of affected versions is provided.</p>
 
 <p>The NVD database of CVEs is also available as a XML dump, allowing

-for offline processing of issues.  I've written a small script taking
-a list of CPEs as input which list all CVEs affecting these packages.
-One give it CPEs with version numbers and get a list of open security
-issues out.
+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.</p>

 
 

-- who uses CPEs?
-  - RHEL
+<p>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 href="https://www.redhat.com/security/data/metrics/rhsamapcpe.txt">a
+map from CVE to CPE</a>, indicating that they are using the CPE
+information.  I'm not aware of Debian and Ubuntu doing the same.</p>

 
 

-- quality
+<p>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.</p>

 
 

-- other applications
+<p>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.</p>