Feature request: extend the schema to allow tags

[andrewhowdencom]

Currently, there are vulnerabilities that may affect a large number of products, such as the monolog library. Most PHP packages integrate into composer, but this project does not limit it's scope to just those packages that do integrate with composer. It is thus difficult to determine what software versions a package might affect.

One way to mitigate this is to extend the schema to allow "tags" on data. An example is below

title:     Remote Code Execution in Qquoteadv/controllers/DownloadController.php
link:      https://cart2quote.zendesk.com/hc/en-us/articles/115000616303--FIXED-Security-Vulnerability-in-downloadCustomOptionAction
# This section is new, and allows grouping vulns along arbitrary criteria as they develop
tags:
  - magento
cve:       ~
branches:
    4.x:
        time:     2017-02-01 10:45:00
        versions: ['>=4.1.6', '<=4.4.5']
    5.x:
        time:     2017-02-01 10:45:00
        versions:  ['>=5.0.0', '<5.4.4']
reference: composer://cart2quote/module-quotation
composer-repository: false

This allows users within a community to tag vulns with words that have meaning within that community to make the content more consumable.

Tags would have styleguide contentions (such as all lower case, separated by a "-" character) but not a limit in their content. There would be no limits on the number of tags.

Other such use cases would be:

• Tagging vulns that exist within some other tracking system, such as CVE
• Tagging vulns of a particular type, such as XSS, RCE, SQL-Injection

I would get around to doing this work at some point. "Managing Expectations" though, it'd either be within the next week or I'd close this issue as "I'm not going to do this" (I have a short attention span)

[stof]

CVE is already a first-class citizen in the advisory format.

Regarding tags, I'm not sure we need them here (and even more if they are about mixing info about the kind of vulnerability and the community in which they happen).
Tagging vulnerability types might be useful

[xabbuh]

I agree with @stof. Tagging the affected community IMO doesn't make much sense. If you are not part of that community, you shouldn't have that package installed at all in the first place. However, being able to see what kind of vulnerability has been fixed might indeed be valuable information.

[andrewhowdencom]

That seems reasonable.

The initial problem I was trying to solve was to group vulnerabilities together so someone who doesn't use composer in their projects (Magento 1.x, for example, doesn't support it natively) so they could still track the list of vulns that affect their stack. Is there another schema that you would recommend for this?

I'm undecided how I feel about a schema specific to vuln types; a new, limited schema must have a greater justification than a schema less limited in scope. I would currently argue that as it is not a problem I'm currently having, vuln types should not be part of the spec.

I tend to treat vulns as a boolean "should fix", rather than assessing the type.

[stof]

@andrewhowdencom a generic tag system is not useful for tooling built on top of this advisory database, as the tools could not know what these tags are meant to represent

[andrewhowdencom]

The tooling doesn't need to be clever necessarily; just provide a means of grouping vulnerabilities in a that means they're easy to browse. At the moment, there is no way to do this - as a Magento (or Drupal or Wordpress or whatever)

I'm quite happy to find another way to do this
this -- I just can't think of one without extending the schema in some way.

[andrewhowdencom]

I'm going to close this, as it doesn't seem like something that can be resolved at the moment.