If you are reading this blog post via a 3rd party source it is very likely that many parts of it will not render correctly. Please view the post on signalscorps.com for the full interactive viewing experience.
In this post I will introduce the important concepts of CVEs and CPEs and explain how to work with them using the NVD API.
cve2stix is a web app and API that documents published vulnerabilities (CVEs) as STIX 2.1 objects.
Over the next few posts, I am going to lift the lid on cve2stix and explain exactly how it works and some of the design decisions made along the way so that you can build it yourself. Of course, you can sign up for free right now too.
Before jumping cve2stix, let me start off by explaining the underlying concepts of CPEs and CVEs…
CPEs
Having a standardised way of to describe them becomes very useful when managing software tools you’re using. That is where Common Platform Enumerations (CPEs) come in;
CPE is a structured naming scheme for information technology systems, software, and packages. Based upon the generic syntax for Uniform Resource Identifiers (URI), CPE includes a formal name format, a method for checking names against a system, and a description format for binding text and tests to a name.
CPEs were originally managed by MITRE but ownership has since been transferred to the US National Institute of Standard of Technology (NIST).
The most important part of a CPE is the URI – a computer readable format to describe the details of operating systems, software applications, or hardware devices.
Here is the CPE 2.3 URI schema;
cpe:2.3:<part>:<vendor>:<product>:
<version>:<update>:<edition>:<language>:<sw_edition>:<target_sw:>:<target_hw>:<other>
Where:
- cpe: always
cpe - 2.3: the cpe version (currently latest is 2.3)
<part>: The part attribute SHALL have one of these three string values:afor applications,ofor operating systems,hfor hardware devices
<vendor>: described or identifies the person or organisation that manufactured or created the product<product>: describes or identifies the most common and recognisable title or name of the product<version>: vendor-specific alphanumeric strings characterising the particular release version of the product<update>: vendor-specific alphanumeric strings characterising the particular update, service pack, or point release of the product.<edition>assigned the logical value ANY (*) except where required for backward compatibility with version 2.2 of the CPE specification<language>: valid language tags as defined by [RFC5646]<sw_edition>: characterises how the product is tailored to a particular market or class of end users.<target_sw>: characterises the software computing environment within which the product operates.<target_hw>: characterises the instruction set architecture (e.g., x86) on which the product being described or identified operates<other>: capture any other general descriptive or identifying information which is vendor- or product-specific and which does not logically fit in any other attribute value
Here is an example of a CPE URI (for Apple Quicktime v7.71.80.42);
cpe:2.3:a:apple:quicktime:7.71.80.42:*:*:*:*:*:*:*
Where;
part:a(application)vendor: appleproduct: quicktimeversion: 7.71.80.42update: *edition: *language: *sw_edition: *target_sw: *target_hw: *other: *
Where;
*means ANY specified or unspecified option-means no product version specified (but still represents a distinct version of the product)
A word of warning when parsing CPE URI’s, you will occasionally see escape characters (\\) in the match string. Here, "cpe:2.3:a:apple:swiftnio_http\\/2:1.19.1:*:*:*:*:swift:*:*", two backslashes \\ escape the forward slash / present in the version string. For full information about when escaping is needed, read the CPE 2.3 naming spec document here.
You can browse all CPEs in the dictionary here. Here is the record shown in the example above: https://nvd.nist.gov/products/cpe/detail/165622
The NVD CPE data can be also accessed via their APIs.
To start using the NVD APIs you will need to request an API key here.
Once you have your API key, you can start making requests. The API Key must be passed in the header of the request using the apiKey property.
A little helper: here is a Postman Collection I created for the API’s you might find useful to get started with.
CPE API’s
- CPE API: used to easily retrieve information on a single CPE record or a collection of CPE records from the Official CPE Dictionary.
- Match Criteria API: The CPE Match Criteria API is used to easily retrieve the complete list of valid CPE Match Strings (as shown above).
CPE API
The root endpoint will return all CPEs;
GET https://services.nvd.nist.gov/rest/json/cpes/2.0/
At the time of writing this is almost 1 million CPEs!
{
"resultsPerPage": 50,
"startIndex": 0,
"totalResults": 998588,
"format": "NVD_CPE",
"version": "2.0",
"timestamp": "2023-01-05T11:11:54.800",
"products": [
There are a range of parameters to filter the CPEs returned in the response.
For example, I can use a full or partial cpeMatchString parameter (the CPE URI shown earlier) to query the API for it;
GET https://services.nvd.nist.gov/rest/json/cpes/2.0/?cpeMatchString=cpe:2.3:a:microsoft:access:-:*:*:*:*:*:*:*
Which returns;
{
"resultsPerPage": 1,
"startIndex": 0,
"totalResults": 1,
"format": "NVD_CPE",
"version": "2.0",
"timestamp": "2023-01-06T08:51:32.650",
"products": [
{
"cpe": {
"deprecated": false,
"cpeName": "cpe:2.3:a:microsoft:access:-:*:*:*:*:*:*:*",
"cpeNameId": "87316812-5F2C-4286-94FE-CC98B9EAEF53",
"lastModified": "2011-01-12T14:35:56.427",
"created": "2007-08-23T21:05:57.937",
"titles": [
{
"title": "Microsoft Access",
"lang": "en"
},
{
"title": "マイクロソフト Access",
"lang": "ja"
}
]
}
}
]
}
The response shows the friendly name of the software in different languages (Microsoft Access (EN) and マイクロソフト Access (JA)) among other fields.
You do not need to pass all parts of a cpeMatchString (URI). cpeMatchString=cpe:2.3:a:microsoft:access is exactly the same as cpeMatchString=cpe:2.3:a:microsoft:access::: which is exactly the same as cpe:2.3:a:microsoft:access:*:*:*:*:*:*:*:* (all these cpeMatchString’s return 32 results at the time of writing).
Taking this further if I wanted a list of all Apple (vendor=apple) applications (part=a) released in the last 3 months of 2022 I could introduce a few more parameters and run the following query;
GET https://services.nvd.nist.gov/rest/json/cpes/2.0/?lastModStartDate=2021-08-04T13:00:00.000%2B01:00&lastModEndDate=2021-10-22T13:36:00.000%2B01:00&cpeMatchString=cpe:2.3:a:apple
Returns three results;
{
"resultsPerPage": 3,
"startIndex": 0,
"totalResults": 3,
"format": "NVD_CPE",
"version": "2.0",
"timestamp": "2023-01-06T15:46:40.793",
"products": [
{
"cpe": {
"deprecated": false,
"cpeName": "cpe:2.3:a:apple:safari:14.1.2:*:*:*:*:*:*:*",
"cpeNameId": "78DEE287-2542-4591-99FC-E961C3DBE74E",
"lastModified": "2021-09-17T18:29:54.370",
"created": "2021-09-14T14:43:00.740",
"titles": [
{
"title": "Apple Safari 14.1.2",
"lang": "en"
}
],
"refs": [
{
"ref": "https://support.apple.com/en-us/HT212606",
"type": "Change Log"
}
]
}
},
{
"cpe": {
"deprecated": false,
"cpeName": "cpe:2.3:a:apple:boot_camp:6.1.14:*:*:*:*:*:*:*",
"cpeNameId": "E5428D10-40C8-4C2A-BBEB-9936654714FF",
"lastModified": "2021-09-19T01:27:12.450",
"created": "2021-09-16T14:42:09.773",
"titles": [
{
"title": "Apple Boot Camp 6.1.14",
"lang": "en"
}
],
"refs": [
{
"ref": "https://support.apple.com/en-us/HT212517",
"type": "Product"
}
]
}
},
{
"cpe": {
"deprecated": false,
"cpeName": "cpe:2.3:a:apple:boot_camp:-:*:*:*:*:*:*:*",
"cpeNameId": "0AAAB8F0-3F20-4DAB-B7D0-6AE256E4B64A",
"lastModified": "2021-09-22T16:55:23.163",
"created": "2021-09-21T13:32:21.907",
"titles": [
{
"title": "Apple Boot Camp",
"lang": "en"
}
],
"refs": [
{
"ref": "https://support.apple.com/boot-camp",
"type": "Product"
}
]
}
}
]
}
Full CPE API response schema for reference.
lastModStartDate and lastModEndDate can also be used to identify new CPEs, in such cases the timestamps for products.cpe.lastModified and products.cpe.created will be the same.
CPE Match Criteria API
In many cases you want to know all CPE variations are vulnerable to a CVE (often there are many language/versions/etc. combinations), this is where the Match Criteria API comes in useful.
However, before this API can be fully understood, you first need to look at the CVE APIs, and before that an understanding of what a CVE is…
CVE’s
In January 1999, the MITRE Corporation published “Towards a Common Enumeration of Vulnerabilities”.
The aim; to identify, define, and catalog publicly disclosed cybersecurity vulnerabilities.
Very soon after this meeting, the original 321 Common Vulnerabilities and Exposures (CVE) Entries, including entries from previous years, was created and the CVE List was officially launched to the public in September 1999.
Each CVE has a unique ID. In its first iteration, 9,999 CVEs were allowed per year because CVE IDs were assigned using the format CVE-YYYY-NNNN (CVE-2001-1473). Currently, tens-of-thousands of CVEs are reported a year. To account for this explosion of CVEs, the CVE ID syntax was extended by adding one more digit to the N potion from four to five digits to CVE-YYYY-NNNNN in 2015.
Whilst CVEs are ultimately managed MITRE and a network of CNA (CVE numbering authorities), NIST (the same organisation managing CPEs) manages a more comprehensive analysis of CVEs in the US National Vulnerability Database (NVD).
The NVD is tasked with analysing each CVE once it has been published to the CVE List (MITREs list) using the reference information provided with the CVE and any publicly available information at the time of analysis to associate Reference Tags, Common Vulnerability Scoring System (CVSS) v2.0, CVSS v3.1, CWE, and CPE Applicability statements.
Once a CVE is published and NVD analysis is provided, there may also be additional maintenance or modifications made. References may be added, descriptions may be updated, or a request may be made to have a set of CVE IDs reorganised (such as one CVE ID being split into several). Furthermore, the validity of an individual CVE ID can be disputed by the vendor that can result in the CVE being revoked (e.g at the time of writing CVE-2022-27948 is disputed).
The full process is described here.
For cve2stix, the key takeaways for working with CVEs are that 1) they are published regularly, 2) the NVD is one of the most comprehensive public sources of CVE analysis and, 3) NVD can updated the data inside at CVE record once it is published.
The NVD CVE data can be also accessed via their APIs. It is the same API used for CPEs, so no new API key is needed.
CVE API’s
- CVE API: The CVE API is used to easily retrieve information on a single CVE or a collection of CVE from the NVD.
- CVE Change History API: The CVE Change History API is used to easily retrieve information on changes made to a single CVE or a collection of CVE from the NVD.
CVE API
The root endpoint will return all CVE’s.
GET https://services.nvd.nist.gov/rest/json/cves/2.0/?resultsPerPage=50
At the time of writing this is almost 204,207 CVEs!
{
"resultsPerPage": 50,
"startIndex": 0,
"totalResults": 204207,
"format": "NVD_CVE",
"version": "2.0",
"timestamp": "2023-01-08T14:08:32.030",
"vulnerabilities": [
{
"cve": {
There are a wide range of parameters to filter the CVEs returned in the response. If you know the CVE you want, you can add that to the query;
GET https://services.nvd.nist.gov/rest/json/cves/2.0/?cveId=CVE-2019-1010218
Which prints all the information about the CVE;
{
"resultsPerPage": 1,
"startIndex": 0,
"totalResults": 1,
"format": "NVD_CVE",
"version": "2.0",
"timestamp": "2023-01-08T14:10:27.753",
"vulnerabilities": [
{
"cve": {
"id": "CVE-2019-1010218",
"sourceIdentifier": "[email protected]",
"published": "2019-07-22T18:15:10.917",
"lastModified": "2020-09-30T13:40:18.163",
"vulnStatus": "Analyzed",
"descriptions": [
{
"lang": "en",
"value": "Cherokee Webserver Latest Cherokee Web server Upto Version 1.2.103 (Current stable) is affected by: Buffer Overflow - CWE-120. The impact is: Crash. The component is: Main cherokee command. The attack vector is: Overwrite argv[0] to an insane length with execl. The fixed version is: There's no fix yet."
},
{
"lang": "es",
"value": "El servidor web de Cherokee más reciente de Cherokee Webserver Hasta Versión 1.2.103 (estable actual) está afectado por: Desbordamiento de Búfer - CWE-120. El impacto es: Bloqueo. El componente es: Comando cherokee principal. El vector de ataque es: Sobrescribir argv[0] en una longitud no sana con execl. La versión corregida es: no hay ninguna solución aún."
}
],
"metrics": {
"cvssMetricV31": [
{
"source": "[email protected]",
"type": "Primary",
"cvssData": {
"version": "3.1",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"attackVector": "NETWORK",
"attackComplexity": "LOW",
"privilegesRequired": "NONE",
"userInteraction": "NONE",
"scope": "UNCHANGED",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"availabilityImpact": "HIGH",
"baseScore": 7.5,
"baseSeverity": "HIGH"
},
"exploitabilityScore": 3.9,
"impactScore": 3.6
}
],
"cvssMetricV2": [
{
"source": "[email protected]",
"type": "Primary",
"cvssData": {
"version": "2.0",
"vectorString": "AV:N/AC:L/Au:N/C:N/I:N/A:P",
"accessVector": "NETWORK",
"accessComplexity": "LOW",
"authentication": "NONE",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"availabilityImpact": "PARTIAL",
"baseScore": 5.0
},
"baseSeverity": "MEDIUM",
"exploitabilityScore": 10.0,
"impactScore": 2.9,
"acInsufInfo": false,
"obtainAllPrivilege": false,
"obtainUserPrivilege": false,
"obtainOtherPrivilege": false,
"userInteractionRequired": false
}
]
},
"weaknesses": [
{
"source": "[email protected]",
"type": "Primary",
"description": [
{
"lang": "en",
"value": "CWE-787"
}
]
},
{
"source": "[email protected]",
"type": "Secondary",
"description": [
{
"lang": "en",
"value": "CWE-120"
}
]
}
],
"configurations": [
{
"nodes": [
{
"operator": "OR",
"negate": false,
"cpeMatch": [
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cherokee-project:cherokee_web_server:*:*:*:*:*:*:*:*",
"versionEndIncluding": "1.2.103",
"matchCriteriaId": "DCE1E311-F9E5-4752-9F51-D5DA78B7BBFA"
}
]
}
]
}
],
"references": [
{
"url": "https://i.imgur.com/PWCCyir.png",
"source": "[email protected]",
"tags": [
"Exploit",
"Third Party Advisory"
]
}
]
}
}
]
}
Full CVE API response schema for reference.
A lot of the NVD website CVE pages are populated from the response of this API – see the similarities between the CVE-2019-1010218 entry here, and the JSON payload above.
If you remember back to the NVD analysis process describe above the vulnerabilities.cve.vulnStatus property tells us the current state (in this case Analyzed). If you’re seeing minimal data returned for a CVE it might be that is awaiting analysis (or rejected) so be sure to check this field (or validate it by checking the entry for the CVE on the NVD website if still unsure).
If you want to be more specific, instead of filtering on a specific CVE, you can also search using various properties of the CVEs you want returned, including;
cpeName: a full or partial CPE match string (e.g.cpe:2.3:o:microsoft)cvssV3Metrics: a CVSS v3 full or partial string (e.g.AV:N/AC:H/Au:N/C:C/I:C/A:C)cvssV3Severity: a CVSS v3 severity (e.g.LOW)cweId: a CWE ID found in a CVE (e.g.CWE-120)hasCertAlerts: if set, only returns the CVE that contain a Technical Alert from US-CERThasCertNotes: if set, only returns the CVE that contain a Vulnerability Note from CERT/CChasKev: if set, ,only returns the CVE that appear in CISA’s Known Exploited Vulnerabilities (KEV) CataloghasOval: if set, only returns only CVE associated with a specific CPE, where the CPE is also considered vulnerable. The exact value provided withcpeNameis compared against the CPE Match Criteria within a CVE applicability statement. If the value ofcpeNameis considered to match, and is also considered vulnerable the CVE is included in the results.keywordExactMatch: By default,keywordSearchreturns any CVE where a word or phrase is found in the current description.keywordSearch: This parameter returns only the CVEs where a word or phrase is found in the current description. Descriptions associated with CVE are maintained by the CVE Assignment.noRejected: By default, the CVE API includes CVE records with the REJECT or Rejected status. This parameter excludes CVE records with the REJECT or Rejected status from API response.
There are also a few date specific parameters (e.g. pubStartDate & pubEndDate, e.g. lastModStartDate & lastModEndDate) that are useful for filtering by time. For example, when backfilling CVEs into a database.
CVE’s can be changed over time (as new information is uncovered). As such lastModStartDate & lastModEndDate can become important to monitor for updated CVE’s too.
The actual changes made to the CVE won’t be shown in the response of the CVE API (only the most recent version of the CVE will be returned). The CVE Change History API allows for this to be done.
CVE Change History API
The root endpoint will return all changes for every single CVE’s which isn’t particularly helpful (at least for what cve2stix does). However, you can filter this endpoint using a CVE ID like so;
GET https://services.nvd.nist.gov/rest/json/cvehistory/2.0/?cveId=CVE-2019-1010218
Which shows four changes (in the response below, I’ve only printed the first change);
{
"resultsPerPage": 4,
"startIndex": 0,
"totalResults": 4,
"format": "NVD_CVEHistory",
"version": "2.0",
"timestamp": "2023-01-23T08:02:06.203",
"cveChanges": [
{
"change": {
"cveId": "CVE-2019-1010218",
"eventName": "Initial Analysis",
"cveChangeId": "E52AFC66-FAFE-4393-B7FF-4EC2FA6CB6C4",
"sourceIdentifier": "[email protected]",
"created": "2019-07-24T16:03:52.787",
"details": [
{
"action": "Added",
"type": "CVSS V2",
"newValue": "(AV:N/AC:L/Au:N/C:N/I:N/A:P)"
},
{
"action": "Added",
"type": "CVSS V3",
"newValue": "AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H"
},
{
"action": "Changed",
"type": "Reference Type",
"oldValue": "https://i.imgur.com/PWCCyir.png No Types Assigned",
"newValue": "https://i.imgur.com/PWCCyir.png Exploit, Third Party Advisory"
},
{
"action": "Added",
"type": "CWE",
"newValue": "CWE-119"
},
{
"action": "Added",
"type": "CPE Configuration",
"newValue": "OR\n *cpe:2.3:a:cherokee-project:cherokee_webserver:*:*:*:*:*:*:*:* versions up to (including) 1.2.103"
}
]
}
},
...
]
}
Full CVE change response schema for reference.
Here four items were Added and one was Changed to CVE-2019-1010218.
You can see this data represented clearly on the Change History section on the NVD website.
CPE Match Criteria API
Remember back to the CPE Match Criteria API, and the response returned by the CVE API?
In the CVE API response you will see the CPE URI cpe:2.3:a:cherokee-project:cherokee_web_server:*:*:*:*:*:*:*:*, under the property vulnerabilities.cve.configurations.nodes.cpeMatch.criteria.
"configurations": [
{
"nodes": [
{
"operator": "OR",
"negate": false,
"cpeMatch": [
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cherokee-project:cherokee_web_server:*:*:*:*:*:*:*:*",
"versionEndIncluding": "1.2.103",
"matchCriteriaId": "DCE1E311-F9E5-4752-9F51-D5DA78B7BBFA"
}
]
}
]
}
],
Whilst there is only one CPE listed above, many CPEs can exist in multiple node combinations (as I will cover in the next post).
Though these cpeMatch’s also come with a matchCriteriaId property value (here DCE1E311-F9E5-4752-9F51-D5DA78B7BBFA), that can be passed to the CVE History API;
GET https://services.nvd.nist.gov/rest/json/cvehistory/2.0/?matchCriteriaId=DCE1E311-F9E5-4752-9F51-D5DA78B7BBFA
Which returns one match;
{
"resultsPerPage": 1,
"startIndex": 0,
"totalResults": 1,
"format": "NVD_CPEMatchString",
"version": "2.0",
"timestamp": "2023-01-23T08:15:05.813",
"matchStrings": [
{
"matchString": {
"matchCriteriaId": "DCE1E311-F9E5-4752-9F51-D5DA78B7BBFA",
"criteria": "cpe:2.3:a:cherokee-project:cherokee_web_server:*:*:*:*:*:*:*:*",
"versionEndIncluding": "1.2.103",
"lastModified": "2019-10-08T16:44:34.360",
"cpeLastModified": "2019-10-08T16:44:34.377",
"created": "2019-10-08T16:44:34.360",
"status": "Active",
"matches": [
{
"cpeName": "cpe:2.3:a:cherokee-project:cherokee_web_server:1.0.12:*:*:*:*:*:*:*",
"cpeNameId": "946ED27F-93AB-4447-9F04-30FEE3EAA8E7"
},
{
"cpeName": "cpe:2.3:a:cherokee-project:cherokee_web_server:1.0.13:*:*:*:*:*:*:*",
"cpeNameId": "E706BE3F-8E91-48E4-8677-C94244016A67"
},
{
"cpeName": "cpe:2.3:a:cherokee-project:cherokee_web_server:1.0.14:*:*:*:*:*:*:*",
"cpeNameId": "FB6C0C33-D9B8-45C2-BE5E-E836AA912A29"
},
{
"cpeName": "cpe:2.3:a:cherokee-project:cherokee_web_server:1.0.15:*:*:*:*:*:*:*",
"cpeNameId": "8EFC2886-764E-427B-8A8E-ADE7B848A516"
},
{
"cpeName": "cpe:2.3:a:cherokee-project:cherokee_web_server:1.0.16:*:*:*:*:*:*:*",
"cpeNameId": "6E542416-8B7A-402E-AFF7-97FEC339BC39"
},
{
"cpeName": "cpe:2.3:a:cherokee-project:cherokee_web_server:1.0.17:*:*:*:*:*:*:*",
"cpeNameId": "5C22473B-9EBD-49B6-86D6-E15538291DE6"
},
{
"cpeName": "cpe:2.3:a:cherokee-project:cherokee_web_server:1.0.18:*:*:*:*:*:*:*",
"cpeNameId": "2AF60F33-AABE-4C14-BE86-668AADDEC011"
},
{
"cpeName": "cpe:2.3:a:cherokee-project:cherokee_web_server:1.0.21:*:*:*:*:*:*:*",
"cpeNameId": "A36E8601-4E38-47E0-B91D-65B42A0A7AE8"
},
{
"cpeName": "cpe:2.3:a:cherokee-project:cherokee_web_server:1.2.0:*:*:*:*:*:*:*",
"cpeNameId": "64DCAC28-ADF7-442A-8746-2C237C877D27"
},
{
"cpeName": "cpe:2.3:a:cherokee-project:cherokee_web_server:1.2.2:*:*:*:*:*:*:*",
"cpeNameId": "59CF5F3E-5158-4116-8733-F65859CB43C3"
},
{
"cpeName": "cpe:2.3:a:cherokee-project:cherokee_web_server:1.2.98:*:*:*:*:*:*:*",
"cpeNameId": "2274D1F6-911C-45D1-8ED5-89B63DA542AD"
},
{
"cpeName": "cpe:2.3:a:cherokee-project:cherokee_web_server:1.2.99:*:*:*:*:*:*:*",
"cpeNameId": "460FA01F-61D5-4B8E-9F0E-B98159A4F980"
},
{
"cpeName": "cpe:2.3:a:cherokee-project:cherokee_web_server:1.2.101:*:*:*:*:*:*:*",
"cpeNameId": "9163CD3B-EEED-4658-8CFD-944827E2B05E"
},
{
"cpeName": "cpe:2.3:a:cherokee-project:cherokee_web_server:1.2.102:*:*:*:*:*:*:*",
"cpeNameId": "45747884-B233-4095-AA7E-012698B4C6A5"
},
{
"cpeName": "cpe:2.3:a:cherokee-project:cherokee_web_server:1.2.103:*:*:*:*:*:*:*",
"cpeNameId": "6F607266-EFB1-4737-A579-AFF23B18E5B1"
}
]
}
}
]
}
Full CPE Match response schema for reference.
The CPE criteria (in the CVE response) showed the CPE URI cpe:2.3:a:cherokee-project:cherokee_web_server:*:*:*:*:*:*:*:*. Using the Match Criteria API by passing the matchCriteriaId (DCE1E311-F9E5-4752-9F51-D5DA78B7BBFA) shows us the complete list of valid CPE Match Strings. Put another way, all iterations of the products that match the CPE URI in the CVE response (in this case 15 in total).
Backfilling data at the setup
Now the data structure is clear, a user has a few options when setting up cve2stix using a variety of parameters to filter on the data they want:
type: Possible values are “cve” and “cpe”, denoting whether CVEs or CPEs is to be download, respectively. You must run script once for type.start-date: The datetime from which CVEs/CPEs are downloaded (or updated)end-date: The datetime upto which CVEs/CPEs are downloaded (or updated)cve-run-mode: Possible value “download” or “update”, denoting if new CVEs are to be downloaded or existing CVEs need to be updated. This setting is ignored iftypeiscpe.
Note in all cases, all enrichment data sources (covered in the next post) will be downloaded (or updated on CVE / CPE update run).
Next time: Known Affected Software (CPE) Configurations
This post introduced the basic concepts of CPEs and CVEs.
However, I only touched on a basic example of CPE nodes in a CVE configuration.
In the next post I will take a deeper look at more complex CPE configurations that contribute to a vulnerability (and also negate them).
Discuss this post
Never miss an update
Sign up to receive new articles in your inbox as they published.