Buildroot:Security Vulnerability Management

Revision as of 14:42, 5 August 2020 by Matthewlweber (talk | contribs) (Managing CPE entries)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Vulnerability Reporting

There are many different vulnerability databases (open/paid). This section documents the use of the National Vulnerability Database(NVD) provided by the National Institute of Standards and Technology (NIST).

Package Report

The includes a holistic view of all packages CVEs. This information should match the individual reports sent out to the package maintainers but double check the timestamp at the bottom of the page as the pkgstats and maintainer reports don't occur at the same time.

Package Maintainer Reporting

Each week the package maintainers listed in the DEVELOPERS file are emailed with all CVE entries applicable to the current version of the packages they maintain. In some cases these reports may list patched CVEs and a maintainer could sent in updates to the <pkg>_IGNORE_CVES list under the respective package. On the following week the report will reflect the additional CVE being filtered out. For more information on the ignoring CVEs, see under the "generic-package reference" section.

How CVE are related to CPE

CPE stands for Common Platform Enumeration and is "a standardized method of describing and identifying classes of applications, operating systems, and hardware devices". A single product would have a set of CPE representing the configuration. A CPE dictionary is published by the US Government's NIST organization. The CPE represents the item's name, vendor, version and applicable CVE mappings.

CVE stands for Common Vulnerabilities and Exposures and is "a feed of vulnerability information that may not completely have CPE matches for all entries".

If an update is required, the direction taken, depends on where the information is incorrectly represented.

Updating CVE dictionary entries

The NIST organization manages the dictionary we use to identify CVE against packages. To make an update, navigate to and fill out the form in a similar manner to this example fix-up of the libnids version issue. The important detail is to provide enough argument to make the change and examples of what change you'd propose. If the CPE assignment is incorrect, the next section on `Managing CPE Entries` must also be followed (as such was the case for this libnids example where the relevant version was misassigned).

  1. "Select a request type" as "Request and update to an existing CVE Entry"
  2. "Type of update requested" is suggested to select "Other" and then provide the details in the description field.
  3. "CVE ID to be updated" as 2010-0751
  4. "Description" as "We've found that the v1.24 fixes the CVE and all prior versions contain the bug. The CVE currently lists that 1.24 is still vulnerable. This can be proved by checking the CHANGES file within the source archive( that outlines this ("fixed another remotely triggerable NULL dereference in ip_fragment.c") comment. Also within that archive the source code src/ip_fragment on line 378 has the fix (;bug=576281;filename=CVE-2010-1144.patch;msg=5) (NOTE 2010-1144 is a rejected CVE which was split to include 2010-0751)."

Managing CPE entries

To submit a new entry or updated entry to NIST, create a request email to the recipient and if possible, attach an individual xml file per package being added/updated. It is OK to have multiple version updates in a single file as long as they are all for the same package. For reference the guidance can be found on the NIST CPE site ( (TBD, pending patchsets to try to automate creating this xml*)

For a request to clarify or update a CVE assignment, sent an email to and provide a similar amount of detail as the CVE request. In the example of libnids, I forwarded my notes related to the version assignment needing adjusting and that we already got confirmation from CVE team of the description being updated.