Building cve2stix: Enriching NVD CVE data (part 4)

Posted by:

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 show you how cve2stix enriches CVEs to provide additional context to each vulnerability.

As has been shown over the last few weeks, the payload of NVD CVE data contains a lot of information relevant for understanding the vulnerability.

This data can be helpful to quickly categorise what a CVE does and how it could affect those running vulnerable software.

cve2stix uses MITRE data converted into STIX objects to provide additional context to consumers of the data.

CWEs

CVEs can contain references to zero or more Common Weakness Enumerations (CWE’s).

CWE’s are a community-developed list of software and hardware weakness types managed MITRE. It serves as a common language as a baseline for weakness identification, mitigation, and prevention efforts.

For example, CWE-79: Improper Neutralization of Input During Web Page Generation (‘Cross-site Scripting’).

When a CWE is linked to a CVE it is describing how the vulnerability is being exploited in a standardised way.

Here is another example; CWE-20 (Improper Input Validation) reported in CVE-2022-33704: https://nvd.nist.gov/vuln/detail/CVE-2022-33704

Which makes sense. The description of this CVE reads:

Improper validation vulnerability in ucmRetParcelable of KnoxSDK prior to SMR Jul-2022 Release 1 allows attackers to launch certain activities.

CVE-2022-33704 CWEs

For example, here is a reference to CWE-306 in the response from the CVE API (for CVE-2019-18939);

GET https://services.nvd.nist.gov/rest/json/cves/2.0/?cveId=CVE-2019-18939

                "weaknesses": [
                    {
                        "source": "[email protected]",
                        "type": "Primary",
                        "description": [
                            {
                                "lang": "en",
                                "value": "CWE-306"
                            }
                        ]
                    }
                ],

CWE’s are referenced inside the vulnerabilities.cve.weaknesses Object.

You will see the CVE response does not provide any detail about the CWE, except for its ID (in this case, CWE-306).

MITRE maintain an XML file with the full CWE definitions here.

In this .xml file, each CWE is captured between <Weaknesses ID...> </Weaknesses> tags.

For example,

<Weakness ID="306" Name="Missing Authentication for Critical Function" Abstraction="Base" Structure="Simple" Status="Draft">
         <Description>The product does not perform any authentication for functionality that requires a provable user identity or consumes a significant amount of resources.</Description>

In v4.9 there are 957 distinct CWEs although they are not ordered sequentially, e.g. Weakness ID="1021" exists.

In addition to ID and Name captured in the <Weakness> tag, you will also find;

Abstraction: either; Pillar, Class, Base, Variant, or Compound
Structure: either; Simple, Composite, or Chain
Status: either; Deprecated, Obsolete, Incomplete, Draft, Usable, or Stable.

Inside the <Weakness> tag is all the content for the CWE, including;

<Modes_Of_Introduction> provides information about how and when a given weakness may be introduced. The required <Phase> element identifies the point in the product life cycle at which the weakness may be introduced.
<Likelihood_Of_Exploit> defines the chance the CWE will be exploited. Either; low, medium, high, or unknown.
<Common_Consequences> is used to specify individual consequences associated with a weakness.
<Detection_Methods> is used to identify methods that may be employed to detect this weakness, including their strengths and limitations
<Potential_Mitigations> is used to describe potential mitigations associated with a weakness.
<Taxonomy_Mappings> is used to provide a mapping from an entry (Weakness or Category) in CWE to an equivalent entry in a different taxonomy.
<Related_Attack_Patterns> contains references to attack patterns (CAPECs) associated with this weakness using a CAPEC identifier. The association implies those attack patterns may be applicable if an instance of this weakness exists.
<References>: defined references (the detail of each reference is captured at the bottom of the file between the <External_References> tags).

CWEs are essentially vulnerabilities. Therefore like CVEs these can be modelled as STIX 2.1 Vulnerability Objects.

In cve2stix, the following CWE fields from the CWE dictionary are modelled as CWE Vulnerability Objects like so;

{
    "type": "vulnerability",
    "spec_version": "2.1",
    "id": "vulnerability--<GENERATED BY STIX2 LIBRARY>",
     "name": "CWE-<CWE ID>: <CWE NAME>",
     "created_by_ref": "identity--<SIGNALS CORPS IDENTITY ID>",
     "created": "<CWE TIME OF FIRST IMPORT>",
     "modified": "<CWE TIME OF FIRST IMPORT>",
     "description": "<Weaknesses.Weakness.Description>",
     "external_references": [
        {
         	"source_name": "cwe",
          	"external_id": "CWE-<CWE ID>",
          	"url": "http://cwe.mitre.org/data/definitions/CWE-<CWE ID>.html"
        },
        {
          	"source_name": "capec",
          	"external_id": "CAPEC-<CAPEC ID [N]>",
          	"url": "https://capec.mitre.org/data/definitions/<CAPEC ID [N]>.html"
        }
    ],
    "object_marking_refs": [
        "marking-definition--613f2e26-407d-48c7-9eca-b8e91df99dc9"
    ]
}

The external_references of the CWE Vulnerability Object will only contain reference to one CWE (itself), but might list multiple CAPEC records (listed inside the Related_Attack_Pattern tag).

The CWE Vulnerability Object created by cve2stix is deliberately simple. I decided to only model the critical fields assuming a user could view the CWE website for more information, if desired.

CWEs could be modelled much more richly as a collection of STIX Objects with relationships. For example, <Potential_Mitigations> could be modelled as Course of Action Objects to describe the potential mitigations in a structured way, linked to the CWE Vulnerability Objects using Relationship Objects. The reason I chose not to do this is that much of this data is already captured in CAPECs too (more on that soon).

In cve2stix, each CWE is linked directly to a CVE using a Relationship Object structure like so;

{
 	"type": "relationship",
 	"spec_version": "2.1",
 	"id": "relationship--<GENERATED BY STIX2 LIBRARY>",
 	"created_by_ref": "identity--<SIGNALS CORPS IDENTITY ID>",
 	"created": "<CWE TIME OF FIRST IMPORT>",
 	"modified": "<CWE TIME OF FIRST IMPORT>",
 	"relationship_type": "exploits",
 	"source_ref": "vulnerability--<CWE VULNERABILITY OBJECT>",
 	"target_ref": "vulnerability--<CVE VULNERABILITY OBJECT>",
    "object_marking_refs": [
        "marking-definition--613f2e26-407d-48c7-9eca-b8e91df99dc9"
    ],
    "external_references": [     
        {
            "source_name": "cve2stix",
            "external_id": "<vulnerability.id>",
            "url": "<HOST><API VERSION>/cve/<CVE ID>"
        }
    ]
}

Let me demonstrate with an example using CVE-2022-29098: https://nvd.nist.gov/vuln/detail/CVE-2022-29098

In CVE-2022-29098, the CWE-521 is referenced. Using the CWE dictionary file I can see this is Spyware.

<Weakness ID="512" Name="Spyware" Abstraction="Base" Structure="Simple" Status="Incomplete">

The CWE dictionary file lists the following CAPEC ID’s for CWE-521;

<Related_Attack_Pattern CAPEC_ID="112"/>
<Related_Attack_Pattern CAPEC_ID="16"/>
<Related_Attack_Pattern CAPEC_ID="49"/>
<Related_Attack_Pattern CAPEC_ID="509"/>
<Related_Attack_Pattern CAPEC_ID="55"/>
<Related_Attack_Pattern CAPEC_ID="555"/>
<Related_Attack_Pattern CAPEC_ID="561"/>
<Related_Attack_Pattern CAPEC_ID="565"/>
<Related_Attack_Pattern CAPEC_ID="70"/>

With this information, I can model the CWE as STIX Vulnerability Object;

{
	"type": "vulnerability",
	"spec_version": "2.1",
    "id": "vulnerability--f6883282-88db-4e2e-bfbf-2c750550f1df",
    "name": "CWE-521: Weak Password Requirements",
    "created_by_ref": "identity--c78cb6e5-0c4b-4611-8297-d1b8b55e40b5",
    "created": "2022-06-28T00:00:00.000Z",
    "modified": "2022-06-28T00:00:00.000Z",
    "description": "The product does not require that users should have strong passwords, which makes it easier for attackers to compromise user accounts.",
    "external_references": [
    	{
        	"source_name": "cwe",
         	"external_id": "CWE-521",
        	"url": "http://cwe.mitre.org/data/definitions/CWE-521.html"
        },
        {
         	"source_name": "capec",
         	"external_id": "CAPEC-112",
         	"url": "https://capec.mitre.org/data/definitions/112.html"
        },
        {
         	"source_name": "capec",
         	"external_id": "CAPEC-16",
         	"url": "https://capec.mitre.org/data/definitions/16.html"
        },
        {
        	"source_name": "capec",
         	"external_id": "CAPEC-49",
         	"url": "https://capec.mitre.org/data/definitions/49.html"
        },
        {
         	"source_name": "capec",
         	"external_id": "CAPEC-509",
         	"url": "https://capec.mitre.org/data/definitions/509.html"
        },
        {
         	"source_name": "capec",
         	"external_id": "CAPEC-55",
         	"url": "https://capec.mitre.org/data/definitions/55.html"
        },
        {
         	"source_name": "capec",
         	"external_id": "CAPEC-555",
         	"url": "https://capec.mitre.org/data/definitions/555.html"
        },
        {
         	"source_name": "capec",
         	"external_id": "CAPEC-561",
         	"url": "https://capec.mitre.org/data/definitions/561.html"
        },
        {
         	"source_name": "capec",
         	"external_id": "CAPEC-565",
         	"url": "https://capec.mitre.org/data/definitions/565.html"
        },
        {
         	"source_name": "capec",
         	"external_id": "CAPEC-70",
         	"url": "https://capec.mitre.org/data/definitions/70.html"
        }
    ],
    "object_marking_refs": [
        "marking-definition--613f2e26-407d-48c7-9eca-b8e91df99dc9"
    ]
}

Which would in turn be linked the the CVE object itself using an SRO like so;

{
 	"type": "relationship",
 	"spec_version": "2.1",
 	"id": "relationship--9ff27da3-c825-4b18-9611-28388d7c214b",
 	"created_by_ref": "identity--c78cb6e5-0c4b-4611-8297-d1b8b55e40b5",
    "created": "2022-06-28T00:00:00.000Z",
    "modified": "2022-06-28T00:00:00.000Z",
 	"relationship_type": "exploits",
 	"source_ref": "vulnerability--f6883282-88db-4e2e-bfbf-2c750550f1df",
 	"target_ref": "vulnerability--<CVE VULNERABILITY OBJECT>",
    "object_marking_refs": [
        "marking-definition--613f2e26-407d-48c7-9eca-b8e91df99dc9"
    ],
    "external_references": [     
        {
            "source_name": "cve2stix",
            "external_id": "<vulnerability.id>",
            "url": "<HOST><API VERSION>/cve/<CVE ID>"
        }
    ]
}

MITRE periodically update the CWE database. It is currently on version is 4.9, as you can see from the first row of the .xml file;

<?xml version="1.0" encoding="UTF-8"?><Weakness_Catalog Name="CWE" Version="4.9" Date="2022-10-13" xmlns="http://cwe.mitre.org/cwe-6" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://cwe.mitre.org/cwe-6 http://cwe.mitre.org/data/xsd/cwe_schema_v6.9.xsd" xmlns:xhtml="http://www.w3.org/1999/xhtml">

You can see Version="4.9" Date="2022-10-13", version 4.9 was last updated on 2022-10-13. Based on my observations, updates happen each quarter.

cve2stix can be explicitly instructed to check the CWE dictionary for updates. When an update is detected (where last Date is different to new Date) cve2stix creates new CWE Vulnerability Objects for any new CWE records, and updates existing records when changes/additions to mapped properties are observed (and the modified date in the CWE STIX Vulnerability object is also updated).

The CAPECs listed in CWEs (under external_references) are also modelled as STIX objects…

CAPECs

Common Attack Pattern Enumerations and Classifications (CAPEC) provide a comprehensive dictionary of known patterns of attack employed by adversaries to exploit known weaknesses (CWE’s) in cyber-enabled capabilities.

Like CWEs, CAPECs are also managed by MITRE.

For example, CAPEC-148: Content Spoofing.

An adversary modifies content to make it contain something other than what the original content producer intended while keeping the apparent source of the content unchanged.

Whilst CVEs do not explicitly reference CAPECs, CAPECs are referenced in CWEs (in the <Related_Attack_Patterns> tag, as shown earlier). Therefore CVEs can be linked to CAPECs using CWEs.

MITRE, distribute CAPEC entries as an xml file, that is very similar to the CPE structure.

MITRE also maintain a copy of this data as STIX 2.1 Objects, which unlike CWEs means no conversion is needed to be done by cve2stix. Note, you might also come across CAPEC version 2.0. This is a version of the same CAPEC data, but built on STIX 2.0 Objects, not 2.1.

The complete CAPEC STIX 2.1 bundle is here (BEWARE: it is a large file).

CAPEC 2.1 uses the following STIX 2.1 Objects;

Attack Pattern: the CAPEC
- e.g. CAPEC 112
Course of Action: ways to mitigate a CAPEC entry
- e.g. coa-102-0
Identity: only one Identity Object exists (for MITRE)
Marking definition: only one Marking Definition Object exists (one copyright statement)
Relationships: defines the connection between all STIX 2.1 Objects above, most importantly the relationship between Course of Action and Attack Pattern Objects to describe mitigations.
- note CAPEC object also have relationships defined by custom properties, e.g. x_capec_can_precede_refs.

A list of all STIX Objects and custom properties these Objects contain used by CAPEC can be viewed here too.

CAPECs are linked to CWE records using the following relationship object structure;

{
	"type": "relationship",
	"spec_version": "2.1",
	"id": "relationship--<GENERATED BY STIX2 LIBRARY>",
	"created_by_ref": "identity--<SIGNALS CORPS IDENTITY ID>",
	"created": "<CWE TIME OF FIRST IMPORT>",
	"modified": "<CWE TIME OF FIRST IMPORT>",
	"relationship_type": "exploited-by",
	"source_ref": "vulnerability--<CWE VULNERABILITY OBJECT>",
	"target_ref": "attack-pattern--<ATTACK PATTERN FOR CAPEC>"
}

It is important to point out the lookup direction here for clarity. cve2stix uses the CWE entry (Vulnerability object) to determine related CAPEC entries (either Attack Pattern or Course of Action objects).

When Vulnerability objects are built from CWEs by cve2stix, CAPEC entries are added via external_references. The external_references section of CAPEC Attack Pattern Object also contains an external_references section with references to CWEs.

cve2stix joins CWEs to CAPECs using the external_references in the CWE Vulnerability Objects only (NOT the external_references in CAPEC Attack Pattern or Course of Action Objects).

The relationship flow in cve2stix between these Objects is as follows;

CVE CWE CAPEC Relationship STIX 2.1

You might have also notice lots of custom properties inside CAPEC STIX Objects, namely the Attack Pattern Object.

For example, x_capec_execution_flows and x_capec_likelihood_of_attack. These are fields xml version of CAPEC in the and defined in the schema.

Let me continue the CVE-2022-29098 example used to explain CWEs earlier.

In this CVE, CWE-521 is referenced, which has the following CAPECs listed as a Related_Attack_Pattern;

You can find the CAPEC ID to join to CWE records in the CWE using the external_references.external_id section of the CAPEC STIX Objects, e.g. for CAPEC-70;

    "external_references": [
       	{
        	"external_id": "CAPEC-70",
            "source_name": "capec",
            "url": "https://capec.mitre.org/data/definitions/70.html"
        },

Note, in each CAPEC Attack Pattern Object, the external_references section only ever contains one CAPEC reference (the CAPEC ID of itself), but might also contain other non-CAPEC references (so cve2stix looks for a string starting with CAPEC-).

Continuing the example, a Relationship Object would now be created between the MITRE CAPEC-112 Brute Force STIX Object attack-pattern--7b423196-9de6-400f-91de-a1f26b3f19f1 and the one cve2stix created for CWE-512 (vulnerability--f6883282-88db-4e2e-bfbf-2c750550f1df);

{
    "type": "relationship",
    "spec_version": "2.1",
    "id": "relationship--443d12e2-8dba-4445-b468-5649f75ade00",
    "created_by_ref": "identity--c78cb6e5-0c4b-4611-8297-d1b8b55e40b5",
    "created": "2022-06-28T00:00:00.000Z",
    "modified": "2022-06-28T00:00:00.000Z",
    "relationship_type": "exploited-by",
    "source_ref": "vulnerability--f6883282-88db-4e2e-bfbf-2c750550f1df",
    "target_ref": "attack-pattern--7b423196-9de6-400f-91de-a1f26b3f19f1"
}

Earlier I mentioned other STIX Objects in the CAPEC library. These are not reference in CWEs, but can be discoved using Relationship Objects in the CAPEC library that link to or from Attack Pattern objects.

For example, STIX CAPEC Attack Pattern Objects have relationships to Course of Action Objects as defined in MITRE STIX bundle.

The STIX CAPEC-112 Brute Force Attack Pattern Object has relationships to three Course of Action Objects;

course-of-action–4cce5adb-bd38-46a1-b756-9c85290ad8e7 (relationship--720b2d97-9125-482c-b7b3-c17acce30c06)
course-of-action–aaaca7bd-c8e3-477f-8457-0dd2fa58b41c (relationship--c266ae48-e3db-42b8-b3ce-57936242fa62)
course-of-action–6863b358-1e48-48e0-b084-56c5cc603fb4 (relationship--cc237ef1-9283-4680-b8d0-9ef4a0cf8147)

Again, none of these objects (Course of Action and Relationships) are created by cve2stix, they are imported from the CAPEC library.

So far this gives us a CWE (Vulnerability), joined to a CAPEC (Attack Pattern), joined to a mitigation (Course of Action). The other eight CAPECs listed in CWE-521 would be modelled in the same way.

The CAPEC library is updated regularly to new versions. Each new version often includes additions, removals and updates of Objects. cve2stix uses the most upto date version of CAPEC at the time of CVE ingest/import.

Here is an example to describe this workflow;

CVE-XXXX-XXXXX is added to NVD DB on 2023-01-01 and imported to cve2stix on the same date.
When cve2stix is creating objects, it searches for CAPECs related to any CWEs in the bundle
The current CAPEC objects (on 2023-01-01 when objects created) are included in the CVE bundle
On 2023-03-03 the CVE is updated on NVD and updates are imported to cve2stix on the same date
When cve2stix is updating/creating objects, it searches for CAPECs related to any CWEs in the bundle
The current CAPCE objects (on 2023-03-03 when CVE is updated) are included in the CVE bundle
…

This means historic CVEs will always map to the most up-to-date version of the Objects (as Object retain their original id) when they are created. However, updates to the latest version of CAPEC objects will only occur if a CVE update happens (e.g. step 4 above), triggering cve2stix to reevaluate all lookups for the CVE. Updated Objects between versions can be detected when the modified property changes.

In the case of CAPEC Objects being removed, the removed CAPEC Object will be updated with the following properties "revoked": true. These Objects will be updated by cve2stix, but will still shows against CVEs.

ATT&CK Entries (Attack Pattern Objects)

ATT&CK is a globally-accessible knowledge-base of adversary tactics and techniques based on real-world observations.

ATT&CK is natively modelled as a wide range of STIX 2.1 Objects (including a few custom STIX Objects). If you missed it, my ATT&CK tutorial series dives deep into the framework and the STIX Objects used.

In the previous examples I have shown how CAPEC records are linked to a CWE records, then CWE records to a CVE.

Mapping ATT&CK data to CVE’s requires using CAPEC data as a key to create the join. ATT&CK techniques are reference in CAPEC objects (CAPECs are also referenced inside Attack Pattern Objects covering ATT&CK Technique and Sub-technique objects).

Take CAPEC-112 = Brute Force (attack-pattern–7b423196-9de6-400f-91de-a1f26b3f19f1). One ATT&CK object exists (identified where "source_name": "ATTACK");

                {
                    "description": "Brute Force",
                    "external_id": "T1110",
                    "source_name": "ATTACK",
                    "url": "https://attack.mitre.org/wiki/Technique/T1110"
                },

Which is covered by the following STIX 2.1 MITRE ATT&CK object (attack-pattern–a93494bb-4b80-4ea1-8695-3236a49916fd).

The following ATT&CK data types from the Enterprise and Mobile and ICS matrices are supported in CAPEC references.

Techniques (attack-pattern)
Sub-Technique (attack-pattern)

A join is made between CAPEC and STIX Objects.

{
	"type": "relationship",
	"spec_version": "2.1",
 	"id": "relationship--<GENERATED BY STIX2 LIBRARY>",
  	"created_by_ref": "identity--<SIGNALS CORPS IDENTITY ID>",
  	"created": "<ATT&CK TIME OF FIRST IMPORT>",
  	"modified": "<ATT&CK TIME OF FIRST IMPORT>",
  	"relationship_type": "capec-to-stix",
  	"source_ref": "attack-pattern--<ATTACK PATTERN FOR CAPEC STIX OBJECT>",
  	"target_ref": "attack-pattern--<ATTACK PATTERN FOR ATT&CK STIX OBJECT>"
}

Therefore in my previous example, a join is made between CAPEC-112 and T1110 STIX Objects that looks like this;

{
    "type": "relationship",
    "spec_version": "2.1",
    "id": "relationship--<GENERATED BY STIX2 LIBRARY>",
    "created_by_ref": "identity--<SIGNALS CORPS IDENTITY ID>",
    "created": "<ATT&CK TIME OF FIRST IMPORT>",
    "modified": "<ATT&CK TIME OF FIRST IMPORT>",
    "relationship_type": "capec-to-stix",
    "source_ref": "attack-pattern--7b423196-9de6-400f-91de-a1f26b3f19f1",
    "target_ref": "attack-pattern--attack-pattern--a93494bb-4b80-4ea1-8695-3236a49916fd"
}

Note, both Attack Pattern objects (for CAPEC and ATT&CK) have the same name property, but inspecting the json payload of each object will show which one is CAPEC and which is ATT&CK.

The structure of relationships and joins from CVEs and enrichment data sources in cve2stix is as follows;

cve2stix CVE CWE CAPEC ATT&CK

The entire ATT&CK STIX 2.1 bundle utilises a lot of other STIX 2.1 Objects (some of which are shown in the above image) with relationships to Attack Patterns (for techniques and sub-techniques joins to CAPECs).

The following ATT&CK objects are shown in a CVE bundle, should they have a relationship to an ATT&CK technique/sub-technique related to a CAPEC in the bundle;

course-of-action representing ATT&CK Mitigations.
intrusion-set representing ATT&CK Groups
malware representing ATT&CK Software (that is malicious)
tool representing ATT&CK Software (that is benign)
x-mitre-data-source representing the various subjects/topics of information that can be collected by sensors/logs.
relationships used to describe the relationship between the above ATT&CK STIX objects.

Now the enrichments gives us

a CWE (Vulnerability), which can be joined to a
CAPEC (Attack Pattern)
- which potentially has a relationship to a CAPEC mitigation (Course of Action)
- The CAPEC Attack Pattern could be joined to;
ATT&CK technique/sub-technique (Attack Pattern)
- which potentially has a relationship to an ATT&CK Mitigation, ATT&CK Group, ATT&CK Software, or an ATT&CK data source

ATT&CK is updated regularly to new versions. Each new version often includes additions, removals and updates of Objects.

cve2stix uses the latest released version of ATT&CK at the time of CVE ingest/update.

Here is an example to describe this workflow;

CVE-XXXX-XXXXX is added to NVD DB on 2023-01-01 and imported to cve2stix on the same date.
When cve2stix is creating objects, it searches for ATT&CK techniques related to any CAPECs in the bundle
The current ATT&CK objects (on 2023-01-01 when objects created) are included in the CVE bundle
On 2023-03-03 the CVE is updated on NVD and updates are imported to cve2stix on the same date
When cve2stix is updating/creating objects, it searches for ATT&CK techniques related to any CAPECs in the bundle
The current ATT&CK objects (on 2023-03-03 when CVE is updated) are included in the CVE bundle
…

This means historic CVEs will always map to the most up-to-date version of the Objects (as Object retain their original id) when they are created. However, updates to the latest version of ATT&CK objects will only occur if a CVE update happens (e.g. step 4 above), triggering cve2stix to reevaluate all lookups for the CVE. Updated Objects between versions can be detected when the modified property changes.

In the case of ATT&CK Objects being removed (fairly uncommon, but possible), the removed ATT&CK Object will be updated with the following properties "revoked": true. These Objects will be updated by cve2stix, but will still shows against CVEs.

Next up: Designing the cve2stix API

Now that STIX objects can be generated from NVD CVE and CPE entries by cve2stix, they now need to be exposed so that they can be easily retrieved for a variety of use-case.

In the next post I will explain the design decisions that went into the cve2stix API, and how you can use it.

Discuss this post

JOIN US