Topics

CPE


Daniel Stenberg
 

Hey,

I pushed a little further on the badge process for two of "my" projects today and then I decided to check out this "CPE" thing that is asked for promimently on the top of the Basics tab. (I've honestely never heard of CPE before.)

Of course, the two smaller projects I just added (c-ares and libssh2) aren't found on the CPE web site. So I then checked what it might say about curl...

"There are 241 matching records"

Whoa. So they register each product and version number that we've ever reported vulnerabilities for and since we do both a tool and a library and both tend to be vulnerable at the same time, there are basically two entries for each vulnerable version. Fun! (they also include version numbers for versions *we* never reported any flaws for, so I guess they suck in info from 3rd party sources they think are trustworthy)

But it really doesn't help me. What's the CPE name for curl? Is it the short name they use in "Product?" Is it the long one they started with cpe that includess the version number ?

The CPE name seems to be per product, right? The form we fill in is for a *project*. Shouldn't we then added a CPE (if possible) for each product we make/maintain ?

Is this really information that will be helpful to anyone? I couldn't fill it in for any of my three projects. Will others?

--

/ daniel.haxx.se


David A. Wheeler
 

Daniel Stenberg:
I pushed a little further on the badge process for two of "my" projects today
and then I decided to check out this "CPE" thing that is asked for
promimently on the top of the Basics tab. (I've honestely never heard of CPE
before.)
...
Whoa. So they register each product and version number that we've ever
reported vulnerabilities for and since we do both a tool and a library and
both tend to be vulnerable at the same time, there are basically two entries
for each vulnerable version. Fun! (they also include version numbers for
versions *we* never reported any flaws for, so I guess they suck in info from
3rd party sources they think are trustworthy).
Right. The National Vulnerability Database (NVD) from NIST uses CPEs, for example:
https://nvd.nist.gov/
The NVD is a database of publicly-known vulnerabilities, collected from many sources.
Each vulnerability has a CVE identifier, and in many cases there's a CPE number for project.

Lots of people use the NVD and CPEs:
* If you're scanning code libraries, cross-link the library versions against the database. OWASP Dependency-Check, for example, does this.
* If you're scanning the software that runs on your computer (including VM or container), or across your enterprise, you cross-check the software installed with the NVD entries.
To make this work, you need to know what software the vulnerability applies to...
which is where identifiers like CPE come into play.
You look at the software, find its CPE, then use that as the key to search
the vulnerability database. Well, that's the theory.

You can see the discussion about adding the CPE field here:
https://github.com/linuxfoundation/cii-best-practices-badge/issues/177


But it really doesn't help me. What's the CPE name for curl? Is it the short
name they use in "Product?" Is it the long one they started with cpe that
includess the version number ?
The long one that starts "cpe...". Most people won't have a CPE name.
I guess we assumed that if you had one, you'd know what it was.
That's obviously not always true, but I'm not sure how to "fix" that.


The CPE name seems to be per product, right? The form we fill in is for a
*project*. Shouldn't we then added a CPE (if possible) for each product we
make/maintain ?
Fair enough; I guess that should actually be a text box, not a string.

Is this really information that will be helpful to anyone? I couldn't fill it in for
any of my three projects. Will others?
It *should* be helpful eventually, though I admit it hasn't done much so far.

The idea was that this would make it much easier to answer questions like,
"are they responding to known vulnerabilities" because the CPE would let us
cross-link vulnerability databases to the badge entries.
Our automation doesn't actually *use* this information yet, but we have hopes.
Our plan was to capture the info now, and then add the automation later.

Another issue: per the XKCD "standards" cartoon <https://xkcd.com/927/>;, there's
more than one way to identify software. Another mechanism is
Software Identification Tags (SWID) per ISO/IEC 19770 part 2, which was
discussed here:
https://github.com/linuxfoundation/cii-best-practices-badge/issues/178
A challenge with using SWID's is that it has no way of indicating software
*without* a version number; it can only identify software with specific version numbers.

There are some other negatives with SWIDs, but I think those can be handled:
* They're huge (big honking XML files); we could resolve that by capturing
some URLs pointing to them as opposed to SWIDs themselves.
* The ISO spec is paywalled (aka unpublished).
That said, NIST IR 8060 is publicly available, so it may be that
the key information from ISO 19770 *is* available to the public:
http://nvlpubs.nist.gov/nistpubs/ir/2016/NIST.IR.8060.pdf

--- David A. Wheeler