Determine version ranges from NVD data

[msrb]

Description

In this spike we want to try to find a way how to extract version ranges from NVD data. Version range is a range that determines which versions of a component are affected by given vulnerability.

NVD plans to improve the format how affected versions are identified: https://nvd.nist.gov/General/News/CPE-Range-Notification
But it's very likely that old entries will not be migrated to this new format.

Example:

{
    "cve" : {
      "data_type" : "CVE",
      "data_format" : "MITRE",
      "data_version" : "4.0",
      "CVE_data_meta" : {
        "ID" : "CVE-2017-1000487",
        "ASSIGNER" : "[email protected]"
      },
      "affects" : {
        "vendor" : {
          "vendor_data" : [ ]
        }
      },
      "problemtype" : {
        "problemtype_data" : [ {
          "description" : [ {
            "lang" : "en",
            "value" : "CWE-77"
          } ]
        } ]
      },
      "references" : {
        "reference_data" : [ {
          "url" : "https://github.com/codehaus-plexus/plexus-utils/commit/b38a1b3a4352303e4312b2bb601a0d7ec6e28f41"
        }, {
          "url" : "https://snyk.io/vuln/SNYK-JAVA-ORGCODEHAUSPLEXUS-31522"
        } ]
      },
      "description" : {
        "description_data" : [ {
          "lang" : "en",
          "value" : "Plexus-utils before 3.0.16 is vulnerable to command injection because it does not correctly process the contents of double quoted strings."
        } ]
      }
    },
    "configurations" : {
      "CVE_data_version" : "4.0",
      "nodes" : [ {
        "operator" : "OR",
        "cpe" : [ {
          "vulnerable" : true,
          "cpe22Uri" : "cpe:/a:plexus-utils_project:plexus-utils",
          "cpe23Uri" : "cpe:2.3:a:plexus-utils_project:plexus-utils:*:*:*:*:*:*:*:*",
          "versionEndExcluding" : "3.0.16"
        } ]
      } ]
    },
    "impact" : {
      "baseMetricV3" : {
        "cvssV3" : {
          "version" : "3.0",
          "vectorString" : "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
          "attackVector" : "NETWORK",
          "attackComplexity" : "LOW",
          "privilegesRequired" : "NONE",
          "userInteraction" : "NONE",
          "scope" : "UNCHANGED",
          "confidentialityImpact" : "HIGH",
          "integrityImpact" : "HIGH",
          "availabilityImpact" : "HIGH",
          "baseScore" : 9.8,
          "baseSeverity" : "CRITICAL"
        },
        "exploitabilityScore" : 3.9,
        "impactScore" : 5.9
      },
      "baseMetricV2" : {
        "cvssV2" : {
          "version" : "2.0",
          "vectorString" : "(AV:N/AC:L/Au:N/C:P/I:P/A:P)",
          "accessVector" : "NETWORK",
          "accessComplexity" : "LOW",
          "authentication" : "NONE",
          "confidentialityImpact" : "PARTIAL",
          "integrityImpact" : "PARTIAL",
          "availabilityImpact" : "PARTIAL",
          "baseScore" : 7.5
        },
        "severity" : "HIGH",
        "exploitabilityScore" : 10.0,
        "impactScore" : 6.4,
        "obtainAllPrivilege" : false,
        "obtainUserPrivilege" : false,
        "obtainOtherPrivilege" : false,
        "userInteractionRequired" : false
      }
    },
    "publishedDate" : "2018-01-03T20:29Z",
    "lastModifiedDate" : "2018-01-18T15:32Z"
  }

All versions prior to 3.0.16 are affected. The goal is to try to come up with an approach how to automatically translate information from NVD about affected/fixed-in versions into format used by project victims. In this case it would be:

affected:
    - groupId: org.codehaus.plexus
      artifactId: plexus-utils
      version:
        - "<=3.0.15"
      fixedin:
        - ">=3.0.16"

Note determining groupId and artifactId is out of scope of this spike.

[msrb]

cc @abs51295 @CermakM

[abs51295]

@msrb Can you assign @CermakM here as well?

[msrb]

@abs51295 we don't need to do both spikes this sprint. If you could pick one, which one would it be?

[abs51295]

#2005 would be the one.

[msrb]

I am first doing some refactoring in the code that deals with NVD data.

[msrb]

Marek did some groundwork around this, but we realized that we first need to have good package name candidates before we can implement this properly. We will return to this (in slightly different shape and form) in future.

[msrb]

Next: #2485