From 3e2b1b8872cc11da85f5410afc77b7fa9e4ee48f Mon Sep 17 00:00:00 2001
From: Petter Reinholdtsen <pere@hungry.com>
Date: Fri, 28 Jan 2011 14:24:39 +0000
Subject: [PATCH] A bit more.

---
 blog/data/2011-01-28-cve-cpe.txt | 63 ++++++++++++++++++++------------
 1 file changed, 39 insertions(+), 24 deletions(-)

diff --git a/blog/data/2011-01-28-cve-cpe.txt b/blog/data/2011-01-28-cve-cpe.txt
index 44747d4226..4d5321513b 100644
--- a/blog/data/2011-01-28-cve-cpe.txt
+++ b/blog/data/2011-01-28-cve-cpe.txt
@@ -3,38 +3,53 @@ Tags: english, debian
 Date: 2011-01-23 00:20
 
 <p>The last few days I have looked at ways to track open security
-issues here at the University of Oslo where I work.  My idea was that
-it should be possible to use the information in security issues
+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 to verify
-that no known security issue had been 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, it should be possible to figure out which security
-holes were present in our free software collection.</p>
+maintained/distributed software against this information.  It should
+allow us to verify that no known security issue 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>
 
 <p>After reading up on the issue, 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.  But it seem
-like I am not the first one to come across this problem, and MITRE had
-already proposed and implemented a solution to this naming problem.
-Enter the <ahref="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 mapped to
-CVEs in the <ahref="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.  This is fairly
-trivial (I google for 'cve cpe $package' and check the NVD entry if a
-CVE for the package exist).</p>
+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
+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
+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.
+This is fairly trivial (I google for 'cve cpe $package' and check the
+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
+<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
+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>,
+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.
 
- - CPE -> CVE
+- who uses CPEs?
+  - RHEL
 
+- quality
 
-http://web.nvd.nist.gov/view/vuln/search
-http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-3430
-cpe:/a:kernel:linux-pam:1.1.2
+- other applications
-- 
2.51.0