Create proposal to add purl, and swid properties to full_product_name_t

[sthagen]

Given robust product identification is an important factor for consumers of Security Advisories (SAs) this proposal shall offer other optional properties to the Full Product Name type (full_product_name_t) side by side with Common Product Enumeration CPE (cpe).

The inputs are the Software Package Data Exchange® (SPDX®) and CycloneDX specifications in their latest published versions.

Rationale:

CPE is not the only way to identify products. In CycloneDX it is marked as deprecated. While the communities seem to split their focus, no one seems to really want to keep CPE.

• some to SWID - ISO-IEC 19770-2 Software Identification (SWID) Tags [spec is paywalled :-1:]
• others to PackageURL (purl - https://github.com/package-url/purl-spec) CycloneDX and SPDX support this already
  • https://spdx.github.io/spdx-spec/appendix-VI-external-repository-identifiers/#purl (ibid also interesting cpe23 regex pattern :wink:)
  • https://cyclonedx.org/docs/1.2/#type_component (XML)
  • https://cyclonedx.org/schema/bom-1.2.schema.json (JSON)
• ...

This is IMO a dangerous situation for CSAF, as we have not many stakes in the discussions.

So, I suggest we support the main contenders. This way, the sharing communities of SAs have more options than tunneling data of other provenience say through a cpe field.

We had this unfortunate stuation of tunneling already in the past: In the wild producers placing CVSS3 as payload to CVSS2 fields ...

[mprpic]

Adding support for purl should be relatively easy since the entire purl string can be represented as a single string, so a hypothetical purl entry may look very similar to the CPE entry and validate against a generic URL pattern since all purls must also be valid URLs.

SWID is a bit more difficult since a single SWID tag is actually an XML document. Some examples of SWID tags can be found in the NISTIR 8060 Guidelines for the Creation of Interoperable Software Identification (SWID) Tags. I can't think of any reasonable way to include SWID tags within CSAF documents, nor do I think that is a good idea.

CSAF documents could simply refer to where a SWID tag for the particular product being described can be found. Unfortunately, I don't have any real-world examples of software shipped with SWID tags and whether those tags are available alongside the product in separate files (e.g. providing a download URL for a product and a separate URL for the SWID tag(s)), or are shipped embedded in the product somehow (e.g. shipping a package that includes a SWID tag file as one of its installed artifacts).

[tschmidtb51]

I support the idea of making a container available for different versions of product identifiers until we have a clear standard for unique Product IDs (in CSAF 3.0). So here is my suggestion:

"full_product_name_t": {
  "title": "Full product name",
  "description": "Specifies information about the product and assigns the local product_id.",
  "type": "object",
  "required": [
    "product_id",
    "name"
  ],
  "properties": {
    "product_id": {
      "$comment": "This is the place for the product_id used in the document."
      "$ref": "#/definitions/product_id_t"
    },
    "name": {
      "title": "Textual description of the product",
      "description": "The value should be the product’s full canonical name, including version number and other attributes, as it would be used in a human-friendly document.",
      "type": "string",
      "minLength": 1,
      "examples": [
        "Microsoft Host Integration Server 2006 Service Pack 1",
        "Cisco AnyConnect Secure Mobility Client 2.3.185"
      ]
    },

Here we insert a container for things which might help to identify the product:

    "product_identification_helpers": {
      "title": "List of items for identifying the product",
      "description": "Provides a least one method which aids in identifying the product in an asset database."
      "type": "object",
      "minProperties": 1,
      "properties": {

       "cpe": {
          // ...
       },
       "hashs": {
          "$comment": "Array of objects (algorithm, value, optional name)" 
         // ...
       "purl": {
         // ...
       },
       "sbom": {
         // ...
        },
        "serial_number": {
         // ...
        }
     }
   }

[sthagen]

@santosomar, @tschmidtb51: In case we accept the proposal (the amended one by @tschmidtb51 which I second) I can add the object to the schema, update the text in section 3, add references, and also add the terms to the glossary in the terminology section.

[santosomar]

This issue was approved during the CSAF TC monthly meeting on Feb 24, 2021, with the addition of a generic URI and description for a vendor specific or new standard.

[tschmidtb51]

184 still needs the regex for purl. The specification is located here.

[sthagen]

A future proof purl regex might be fun ... 🙈 - tomorrow is another day.

[tschmidtb51]

A future proof purl regex might be fun ... see_no_evil - tomorrow is another day.

I just put it there as note - so we won't forget about it...

[pombredanne]

A future proof purl regex might be fun ... see_no_evil - tomorrow is another day.

I just put it there as note - so we won't forget about it...

FWIW, Package URLs are rather easy to parse, but I am not sure what it would take to have a regex for them; this was never a goal ;) ... yet if you can craft a generic regex that passes the tests, I will happily support this and reference it in the purl README.

Note that since there are purl implementations in several programming languages, it may make the need for a regex a lesser issue?

[tschmidtb51]

I think we should add a product_number. This will allow asset owners who use SAP (or any other comparable software) to match based on what they bought.

[sthagen]

A future proof purl regex might be fun ... see_no_evil - tomorrow is another day.

I just put it there as note - so we won't forget about it...

FWIW, Package URLs are rather easy to parse, but I am not sure what it would take to have a regex for them; this was never a goal ;) ... yet if you can craft a generic regex that passes the tests, I will happily support this and reference it in the purl README.

Note that since there are purl implementations in several programming languages, it may make the need for a regex a lesser issue?

Having read the context aware purl definition again, I propose we stay with the main constraint of a purl being a valid URL and drop any REGEX approach.

The schema should never stand in the way of producer and consumer exchanging valid and meaningful (to their tool chains) content. Ensuring per schema, that any purl value conveyed must be a valid URL is helpful already IMO. Any inventory matching and source vetting should fall back on capabilities beyond this spec.

Thank you Philippe Ombredanne (@pombredanne) for pointing out the goals of PURL and the existing toolscape.

[tschmidtb51]

I had a look at that and did some tests... I suggest to use the following regex in addition to the URL check: "^pkg:[A-Za-z\\.\\-\\+][A-Za-z0-9\\.\\-\\+]*/.+" I think that captures enough of the structure and ensures the canonical form of purl but leaves plenty of room to be future prove. @pombredanne what do you think?

[pombredanne]

I had a look at that and did some tests... I suggest to use the following regex in addition to the URL check: "^pkg:[A-Za-z\\.\\-\\+][A-Za-z0-9\\.\\-\\+]*/.+" I think that captures enough of the structure and ensures the canonical form of purl but leaves plenty of room to be future prove. @pombredanne what do you think?

@tschmidtb51 I think it may not match this valid Package URL:

• pkg:ABC%20DEF

[tschmidtb51]

That is correct. But what is the type and what is the name in this example? Aren't both required and separated by /?

[sthagen]

Hm, that was fast - thanks @pombredanne for providing the counter example.

I propose that before we end up with a regex equivalent to startswith(pkg:) we rather go with the valid URI constraint, just sayin‘ … the benefit for the consumer is much higher than a starts with constraint and the URI property nicely aligns with a top level assurance of the current purl-spec.

Good idea, bad idea?

[pombredanne]

actually I am wrong: pkg:ABC%20DEF is not a valid purl in the sense that only a type would be useless. @tschmidtb51 you are right! pkg:foo/ABC%20DEF would be valid and match

Using startswith(pkg:) would be plenty good for now too.

[tschmidtb51]

pkg:ABC%20DEF is not a valid purl in the sense that only a type would be useless.

I guess ABC%20DEF is a name, not a type? As the type is defined in the spec as:

• The package type is composed only of ASCII letters and numbers, '.', '+' and '-' (period, plus, and dash)
• [...]
• The type must NOT be percent-encoded

pkg:foo/ABC%20DEF would be valid and match

That is true.

[tschmidtb51]

@pombredanne Do you have any concerns or would the suggested regex be safe for the near future?