Posted by:

David Greenwood

David Greenwood, Chief of Signal

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 for the full interactive viewing experience.

In this post I will show Vulmatch enriches CVEs to help an analyst triage alerts when they are triggered.

Note: Vulmatch is an ever evolving product therefore the concepts described in this post might not always be relevant for the latest version.

Once a match has been identified between a CVE CPE configuration and a CPE configuration being used by a user, Vulmatch will raise an alert.

When an analyst is reviewing the alert, Vulmatch provides even more information than the CPE and CVE information available so that analysis can be performed in a single product.

This post will describe some of the other open frameworks Vulmatch uses to provide additional context, and how the data is ingested and processed from each source.


CVEs can contain references to zero or more Common Weakness Enumerations (CWE’s) referenced inside the cve.problemtype Object.

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 weakness (aka vulnerability) is being exploited in a standardised way.

Here is another example; CWE-20 (Improper Input Validation) reported in 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


In the response you can identify the CWE under the problemtype object;

"problemtype": {
    "problemtype_data": [
            "description": [
                    "lang": "en",
                    "value": "CWE-20"

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

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="20" Name="Improper Input Validation" Abstraction="Class" Structure="Simple" Status="Stable">
        <Description>The product receives input or data, but it does
        not validate or incorrectly validates that the input has the
        properties that are required to process the data safely and

In v4.8 there are 951 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 Vulmatch, 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": "<CWE ID>.html"
          "source_name": "capec",
          "external_id": "CAPEC-<CAPEC ID>",
          "url": "<CAPEC ID>.html"

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

The CWE Vulnerability Object created by Vulmatch 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. 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 Vulmatch, 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": "<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>"

Let me demonstrate with an example using 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 it as STIX Objects;

CWE Updates

MITRE periodically update the CWE database. It is currently on version is 4.8, 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.8" Date="2022-06-28" xmlns="" xmlns:xsi="" xsi:schemaLocation="" xmlns:xhtml="">

You can see Version="4.8" Date="2022-06-28", version 4.8 was last updated on 2022-06-28. Vulmatch queries the xml file each month for updates. When an update is detected (where last Date is different to new Date) Vulmatch creates new CWE Vulnerability Objects for any new CWE records. Updates to existing objects in the CWE dictionary are not considered by Vulmatch, because the updates happen to fields that are not used by Vulmatch to create the CWE Vulnerability Object.


Common Attack Pattern Enumerations and Classifications (CAPEC) provides 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>). 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 necessary by Vulmatch. 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
  • Course of Action: ways to mitigate a CAPEC entry
  • 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.

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": "<CWE TIME OF FIRST IMPORT>",
  "modified": "<CWE TIME OF FIRST IMPORT>",
  "relationship_type": "targets",
  "source_ref": "attack-pattern--<ATTACK PATTERN FOR CAPEC>",
  "target_ref": "vulnerability--<CWE VULNERABILITY OBJECT>"

It is important to point out the lookup direction here for clarity. Vulmatch uses the CWE entry to determine related CAPEC entries.

When Vulnerability objects are built from CWEs by Vulmatch, 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.

Vulmatch joins CWEs to CAPECs using the external_references in the CWE Objects only (NOT the external_references in CAPEC Objects).

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

CVE CWE CAPEC Relationship STIX 2.1

You might have also notice lots of custom properties inside CAPEC 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. Where CWE-521 is referenced, which has the following CAPECs referenced in the CWE xml file;

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

                    "external_id": "CAPEC-70",
                    "source_name": "capec",
                    "url": ""

Note, in each CAPEC Attack Pattern Object, the external_references section only ever contains one CAPEC reference (the CAPEC ID of itself).

Continuing the example, here is the relationship between CAPEC-112 Brute Force and CWE-512 modelled as STIX;

CAPEC ATTACK objects also have relationships defined by custom properties, e.g. x_capec_can_precede_refs.

Modelling all the Attack Pattern Objects listed in CWE-521 you can see these custom relationships;

In turn, 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, as modelled below;

The above graph does not show Attack Pattern Objects for CAPEC-16, CAPEC-49, CAPEC-509, CAPEC-55, CAPEC-555, CAPEC-561, CAPEC-565, and CAPEC-70 which are referenced in CWE-512. These Attack Pattern Objects have links to other Course of Action Objects.

CAPEC Updates

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

Vulmatch uses the most upto date version of CAPEC at the time of CVE ingest.

This means historic CVEs will always map to the most up-to-date version of the Objects (as Object retain their original id). 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 Vulmatch, 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.

Download the entire ATT&CK STIX 2.1 bundle (BEWARE: large file).

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 relationship. CAPECs are referenced inside Attack Pattern Objects covering ATT&CK Technique and Sub-technique objects.

Take the ATT&CK sub-technique; T1110.004 Credential Stuffing (attack-pattern–b2d03cea-aec1-45ca-9744-9ee583c1e1cc), which references CAPEC-600.

Therefore a join is made between using the CAPEC ID (600) referenced in the ATT&CK STIX 2.1 Attack Pattern Object to the CAPEC Attack Pattern Object.

  "type": "relationship",
  "spec_version": "2.1",
  "id": "relationship--<GENERATED BY STIX2 LIBRARY>",
  "created": "<ATT&CK TIME OF FIRST IMPORT>",
  "modified": "<ATT&CK TIME OF FIRST IMPORT>",
  "relationship_type": "targets",
  "source_ref": "attack-pattern--<ATTACK PATTERN FOR ATT&CK STIX OBJECT>",
  "target_ref": "attack-pattern--<ATTACK PATTERN FOR CAPEC STIX OBJECT>"

As an example let’s use the ATT&CK Credential Stuffing Sub-Technique Attack Pattern Object

It contains a reference to CAPEC-600 in external_references.external_id as follows:

    "url": "",
    "external_id": "CAPEC-600",
    "source_name": "capec"

So this T1110.004 Credential Stuffing would target CAPEC-600: Credential stuffing.

In STIX, this would be modeled like so;

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 entire ATT&CK STIX 2.1 bundle utilises a lot of other STIX 2.1 Objects with relationships to Attack Patterns (for techniques and sub-techniques). These include;

  • 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)
  • Data Sources representing the various subjects/topics of information that can be collected by sensors/logs.
  • Relationships: used to describe the relationship between ATT&CK STIX objects.

I will not model these in this post, but the structure of relationships and joins from CVEs and enrichment data sources in Vulmatch is as follows;


ATT&CK Updates

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

Vulmatch uses the most upto date version of ATT&CK at the time of CVE ingest.

This means historic CVEs will always map to the most up-to-date version of the Objects (as Object retain their original id). Updated Objects between versions can be detected when the modified property changes.

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

And that is Vulmatch!

At the start of this series of posts I promised to lift the lid on Vulmatch by explaining exactly how it works so you can build it yourself.

I also did it for another reason; your feedback.

Everyone will have their own views on how the data described in the last six posts should be modelled. I am also aware that I make (many) mistakes. So please do send any feedback you have that could be used to help improve Vulmatch. Thanks from both me and all the Vulmatch users in advance!

Our brand new Discord!

Like this blog?

Sign up to receive new posts in your inbox.


Stixify. Extract machine readable intelligence from unstructured data.

Extract machine readable intelligence from unstructured data.



Turn any blog into structured threat intelligence.



Know when software you use is vulnerable, how it is being exploited, and how to detect an attack.

SIEM Rules

SIEM Rules. Your detection engineering database.

View, modify, and deploy SIEM rules for threat hunting.