Structure of a cpe inside cpe2stix STIX Software object

OSS Support
1

I am using cpe2stix

And it is creating STIX Software objects that look like this

      {
            "type": "software",
            "spec_version": "2.1",
            "id": "software--08674808-cb43-5780-b64a-d045467169d3",
            "name": "Bitcoin Bitcoin Core 26.0 -",
            "cpe": "cpe:2.3:a:bitcoin:bitcoin_core:26.0:-:*:*:*:*:*:*",
            "swid": "E783D879-1840-4B10-A1E3-969B65C0D8B5",
            "languages": [
                "en"
            ],
            "vendor": "bitcoin",
            "version": "26.0",
            "object_marking_refs": [
                "marking-definition--94868c89-83c2-464b-929b-a1a8aa3c8487",
                "marking-definition--5e6fc5ec-e507-52e7-8465-cf5ffc47138a"
            ]
        },

So I understand this Software object represents Bitcoin Core v26.

However, what I am unsure about is the cpe key showing the value

cpe:2.3:a:bitcoin:bitcoin_core:26.0:-:*:*:*:*:*:*

What do the - and * characters represent here?

2

Hey @0101001001001 ,

The answer you’re looking for is in the CPE spec document:

Now for the tl;dr version…

This is the CPE 2.3 URI schema (2.3 is the latest version, and I don’t older versions being actively used as 2.3 is many years old now);

cpe:2.3:<part>:<vendor>:<product>:<version>:<update>:<edition>:<language>:<sw_edition>:<target_sw:>:<target_hw>:<other>

The : chars break down each part of the CPE.

Where:

  • cpe: always cpe
  • 2.3: the cpe version (currently latest is 2.3). Note, you should check this is always 2.3 when parsing, as older versions do not have the same structure (although as noted, you’re unlikely to stumble across older versions)
  • <part>: The part attribute SHALL have one of these three string values:
    • a for applications,
    • o for operating systems,
    • h for 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: apple
  • product: quicktime
  • version: 7.71.80.42
  • update: *
  • edition: *
  • language: *
  • sw_edition: *
  • target_sw: *
  • target_hw: *
  • other: *

As in your Bitcoin example, you’ll see hyphens - and asterisks * in CPE strings. From the spec (6.2.3.1):

If a field contains only an asterisk, it is unbound to the logical value ANY. If a field contains only a hyphen, it is unbound to the logical value NA.

And 5.3.1:

An attribute of a WFN MAY be assigned one of these logical values:

  1. ANY (i.e., “any value”). The logical value ANY SHOULD be assigned to an attribute when there are no restrictions on acceptable values for that attribute.
  2. NA (i.e., “not applicable/not used”). The logical value NA SHOULD be assigned when there is no legal or meaningful value for that attribute, or when that attribute is not used as part of the description. This includes the situation in which an attribute has an obtainable value that is null.

A good example of when a - is used could be to describe an initial release if a platform does identify with a given component but no term is commonly used to describe it. An example of this might be the initial release of an application before any updates have been released. The very first release of an application might be known as “Acme Product 1.0”.

cpe:2.3:a:acme:product:1.0:-

A few months later an update is released by the vendor and the once applied, the platform is known as “Acme Product 1.0 Update 1”.

cpe:2.3:a:acme:product:1.0:update1

Also from the spec (5.2):

It is important to note that when a CPE Name is being created for a specific platform type (i.e. a specific release of an application) then the hyphen should be used at all times (when a vendor term is not available) instead of a blank component. The blank component is to be used only when a more general platform type is being enumerated. (i.e. any version of an application)

The * value is a little more simple to get your head around. Essentially, if a * is present it means any value for this part. For example, if the version part contains a *, e.g.

cpe:2.3:a:acme:product:*

It means ANY version of that product that exists.

One final word of warning…

When parsing CPE stings, you will occasionally see escape characters in the match string (especially to escape the interpretation of * and - charachters).

The following are examples of where escape characters need to be used:

  • foo\-bar (hyphen is quoted)
  • \"oh_my\!\" (quotation marks and exclamation point are quoted)
  • g\+\+ (plus signs are quoted)
  • 9\.? (period is quoted, question mark is unquoted)
  • sr* (asterisk is unquoted)
  • big\$money (dollar sign is quoted)
  • foo\:bar (colon is quoted)
  • back\\slash_software (backslash is quoted)
  • with_quoted\~tilde (tilde is quoted)
  • *SOFT* (single unquoted asterisk at beginning and end)
  • 8\.?? (two unquoted question marks at end)
  • *8\.?? (one unquoted asterisk at beginning, two unquoted question marks at end)

For example, the CPE string cpe:2.3:a:apple:swiftnio_http\\/2:1.19.1:*:*:*:*:swift:*:* has a backslashes \ to escape a \ present in the version string.

This text should be interpreted literally as cpe:2.3:a:apple:swiftnio_http\/2:1.19.1:*:*:*:*:swift:*:*

For full information about when escaping is needed/used, see 5.3.2 Restrictions on attribute-value strings in the specification for detailed info.

Hope this helps!

1 Like