google/osv.dev#545

Speaking of which in the OSV data there's a lot of aliases of just some number:

["CVE-2020-3671","2576091"]

which makes it... hard to track, or know where it came from, e.g. unless an alias is unique (so not just a number) and identifiable, e.g. CVE-, GSD-, RHSA-, it's basically just confusing. To quote the docs:

The aliases field gives a list of IDs of the same vulnerability in other databases, in the form of the id field. This allows one database to claim that its own entry describes the same vulnerability as one or more entries in other databases. Or if one database entry has been deduplicated into another in the same database, the duplicate entry could be written using only the id, modified, and aliases field, to point to the canonical one.

but there's no data around which database that alias is for...

I feel like I should open up another ticket to discuss this as a pile of random numbers that end up overlapping between different entries is going to be problematic.

Moved here as per CloudSecurityAlliance/gsd-database#2389

@oliverchang I'm not sure what the best place for that to live would be, worst case scenario we can point it at the raw link for the main branch (https://raw.githubusercontent.com/ossf/osv-schema/main/validation/schema.json).

Relates to #51 somewhat (aiding parsers in knowing when an object is OSV, and what to expect from said OSV).

So we have

affected:ranges:events:introduced
affected:ranges:events:fixed
affected:ranges:events:last_affected
affected:ranges:events:limit

but we're missing a "notaffected" or "unaffected" as in "we checked and we're not affected at all", e.g. data from the CISA log4j repo:

https://github.com/kurtseifried/log4j-affected-db/blob/develop/data/cisagov.yml

cves:
cve-2021-4104:
investigated: true
affected_versions: []
fixed_versions: []
unaffected_versions: - '>= 1.0.0'

cve-2021-44228:
investigated: true
affected_versions: []
fixed_versions: []
unaffected_versions: - '>= 1.0.0'

So I'd like to propose a "notaffected" tag.

Currently the catch-all for references of an unknown type is "WEB". At first glance however, it's not necessarily clear that these are references of essentially an undefined or unknown type.

Some various alternatives:

• UNKNOWN
• OTHER
• UNSPECIFIED

@oliverchang this would be a pretty major change, but I think have some positive long term implications as far as keeping the data intuitive and reducing institutional knowledge required.

the versions array is mandatory if you e.g. put a git commit in for affected, but the versions array can be blank:

"allOf": [
{
"if": {
"properties": {
"ranges": {
"contains": {
"properties": {
"type": {
"enum": [
"SEMVER",
"ECOSYSTEM"
]
}
}
}
}
}
},
"then": {},
"else": {
"required": [
"versions"

I would ask it either be removed or if it's intended to be there, then some content should be checked for (which breaks things, some things have git commit's but no releases/etc.) so I would suggest we remove this versions requirement.

credits fields
{
"credits": [ {
"name": string,
"contact": [ string ],
} ]
}
The credits field is a JSON array providing a way to give credit for the discovery, confirmation, patch, or other events in the life cycle of a vulnerability.

is there some reason we don't have an optional text description or ENUM for what kind of credit(s)?

Repo Issue!

The references field which is currently:

{
"references": [ {
"type": string,
"url": string
} ]
}

One major change I'd like to propose is that type be EITHER a string (singular) or an array (multiple entries), although ideally I'd prefer it just be an array with 1 or more entries.

Related to this I'd like to propose some additional values for type such as:

EXPLOIT (exploit code/methodology/etc.)
EXPLOITATION (reports of exploitation)
WORKAROUND
DISCUSSION (e.g. Twitter threads)

and obviously, some of these URLs can be multiple things, e.g. an ADVISORY could contain FIX and WORKAROUND and EXPLOIT hence the string/array request

I'd also like to propose adding a timestamp for when it was seen, this is extremely useful when creating timelines and I've noticed a worrying trend for web pages/forum posts/etc to not contain a published date or "1 month ago".

As you can see from https://github.com/cloudsecurityalliance/gsd-database/blob/main/2021/1002xxx/GSD-2021-1002352.json (search for "timestamp") it's incredibly helpful when reconstructing the Twitter activity timeline.

This is in relation to: CloudSecurityAlliance/gsd-database#2389

Ok meta comments:

Obviously, we want this added as a reference, but the OSV schema only supports:

https://ossf.github.io/osv-schema/#references-field

ADVISORY: A published security advisory for the vulnerability.
ARTICLE: An article or blog post describing the vulnerability.
REPORT: A report, typically on a bug or issue tracker, of the vulnerability.
FIX: A source code browser link to the fix (e.g., a GitHub commit) Note that the fix type is meant for viewing by people using web browsers. Programs interested in analyzing the exact commit range would do better to use the GIT-typed affected[].ranges entries (described above).
PACKAGE: A home web page for the package.
EVIDENCE: A demonstration of the validity of a vulnerability claim, e.g. app.any.run replaying the exploitation of the vulnerability.
WEB: A web page of some unspecified kind.

So it could be classed as "EVIDENCE", which is what I'll use for now, but I'm going to file an upstream issue with OSV to try for a better word, e.g.:

REPRODUCER: Nonweaponized, programmatic method to trigger the vulnerability?
EXPLOIT: weaponized, programmatic method to trigger the vulnerability (can be a link to code?)
EXPLOITATION: reports of exploitation but no actual technical reproducer/exploit available?

I think one possible way to do this would be to use "sub tags" e.g. EVIDENCE:EXPLOIT or EVIDENCE:REPRODUCER. This would prevent clutter and an explosion of top level tags, and for data consumers they can for example simply support "EVIDENCE" and ignore subtags, or choose to also support subtags, either way they are able to broadly classify the data according to the top level tags, even if they don't want to check for subtags.

I was looking to enrich the GSD Database with additional data from VMWare Photon Advisories (Filed PR: CloudSecurityAlliance/gsd-database#2443), and was planning to add PHSA as a database prefix here once that is merged.

However, I had a few questions:

1. What's the expectation from a "home"-database? Does it need to serve valid OSV schema, or will a redirect to the relevant CVE also work? Is there a specific URL which needs to be registered, any other requirements?
   I was planning to just keep all the advisories in OSV format in a GitHub Repository - that should be fine?
   In this case, since the PHSA Advisory links to multiple CVEs: I can't really setup redirects, what will a home database for PHSA look like?

2. In the case of Photon, an advisory (identifier issued here) contains multiple vulnerabilities. This impacts the severity field, but also other details, which might vary on a per-package basis.

This also creates issues around aliases - should PHSA-2022-0304 be considered an alias for both CVE-2022-4415 and CVE-2022-43551?

Discovered this while discussing #132

Currently, the canonical url for the schema is:
https://raw.githubusercontent.com/ossf/osv-schema/v<SEMVER>/validation/schema.json

For example, 1.4.0 resolves to:
https://raw.githubusercontent.com/ossf/osv-schema/v1.4.0/validation/schema.json

1.0.0 is historically important due to schema_version being null is implied to be 1.0.0, however currently that 404s:
https://raw.githubusercontent.com/ossf/osv-schema/v1.0.0/validation/schema.json

This should be added or backported so that it is consistent and can be used by validators.

Add support for editing of Ruby language (non-RubyGem) advisories in GHSA database.

 * jruby: https://github.com/advisories?query=jruby+ (23)
 * mruby: https://github.com/advisories?query=mruby  (40)
 * ruby-lang: https://github.com/advisories?query=ruby-lang (86)
TOTAL: 143

Looks like their is 5 non-rubygems, non-ruby-language advisories, 
but we can deal with them separately.
 * Unreviewed "ruby: https://github.com/advisories?query=ruby+type%3Aunreviewed (148)

I tried to add missing information to some of them lately and was blocked
by not having an "ECOSYSTEM" value for them.

I propose something similar to "Ruby Languages" or "Rubies" be added
as a possible "ECOSYSTEM" value.

The "PACKAGE" value could be ["ruby-lang", "jruby", "mruby", "rbx/rubinius", "truffleruby", etc].

A good reference for other possible "PACKAGE" values at https://github.com/codicoscepticos/ruby-implementations
Thanks.

As part of #761, we became aware that the Cloud Security Alliance has a schema validator.

It seems like shipping a canonical, authoritative validator tool and library with the schema would be best, rather than each ecosystem integrator needing to reinvent the wheel (and possibly less comprehensively than desired).

Codecov Report

Merging #5226 (799b462) into main (0ec1264) will decrease coverage by 0.02%.
The diff coverage is 94.28%.

@@            Coverage Diff             @@
##             main    #5226      +/-   ##
==========================================
- Coverage   88.58%   88.57%   -0.02%     
==========================================
  Files         295      294       -1     
  Lines       40114    40094      -20     
==========================================
- Hits        35534    35512      -22     
- Misses       4580     4582       +2     

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

Originally posted by @codecov in ietf-tools/datatracker#5226 (comment)

Please add "data_type" tag to make parsing easier, for example the CVE JSON format has:

"data_type": "CVE" which means you don't have to guess and test to see what kind of data you're parsing. If the OSV ould add a " "data_type": "OSV" to everything that would make life much simpler. Especially if more people start using things like OSV's database_specific field to embed OSV data into other formats (cats and dogs living together, it's turtles all the way down).

So I read https://ossf.github.io/osv-schema/ and I think there's an underlying assumption that should maybe be made explicit:

In most cases, there should be exactly one entry in the affected array per affected package to describe all affected versions. In rare cases, for example if the ecosystem_specific encodes platform information that doesn’t apply equally to all listed versions and ranges, a separate entry with the same package in the affected array may be needed.

The versions field can enumerate a specific set of affected versions, and the ranges field can list ranges of affected versions, under a given defined ordering. A version is considered affected if it lies within any one of the ranges or is listed in the versions list.

So in theory (assuming the data is correct) anything NOT listed is explicitly NOT vulnerable, correct? Should this logic be made explicit (assuming it is correct)?

I also wonder if it might be helpful to also support an "unknown" or "needs investigation:" type tag, this would for example allow people to publish OSV's quicker ("we know this specific version is affected, but we haven't looked at much older code yet, someone should probably do that") with a finer degree of detail, or is this overengineering and not needed (I'm leaning in this direction mostly right now).

It is my understanding that both osv-schema and cve-schema try to describe a vulnerability, and many fields in osv-schema and cve-schema share the same meaning, especially for cve-schema v5.0.

Therefore, I'm now confusing about what is the major difference between the two schemas.

Thank you for your response.

Allow not just aliasing (this ID is also known as...) and relates to (this ID is different from, but related to...), but also more nuanced relationships like parent/child and such.

@JLLeitschuh what would be most useful relationship types to include from a researcher's perspective?

Notable changes:

• per package severity: e6ba0d9

Is this missing anything? It seems like a complete and blank example:

{
  "schema_version": "string",
  "id": "string",
  "modified": "string",
  "published": "string",
  "withdrawn": "string",
  "aliases": [
    "string"
  ],
  "related": [
    "string"
  ],
  "summary": "string",
  "details": "string",
  "severity": [
    {
      "type": "string",
      "score": "string"
    }
  ],
  "affected": [
    {
      "package": {
        "ecosystem": "string",
        "name": "string",
        "purl": "string"
      },
      "severity": [
        {
          "type": "CVSS_V2",
          "score": "string"
        },
        {
          "type": "CVSS_V3",
          "score": "string"
        },
        {
          "type": "EPSS",
          "score": "string"
        }
      ],
      "ranges": [
        {
          "type": "SEMVER",
          "repo": "string",
          "events": [
            {
              "introduced": "string",
              "fixed": "string",
              "last_affected": "string",
              "limit": "string"
            }
          ],
          "database_specific": {}
        },
        {
          "type": "ECOSYSTEM",
          "repo": "string",
          "events": [
            {
              "introduced": "string",
              "fixed": "string",
              "last_affected": "string",
              "limit": "string"
            }
          ],
          "database_specific": {}
        },
        {
          "type": "GIT",
          "repo": "string",
          "events": [
            {
              "introduced": "string",
              "fixed": "string",
              "last_affected": "string",
              "limit": "string"
            }
          ],
          "database_specific": {}
        }
      ],
      "versions": [
        "string"
      ],
      "ecosystem_specific": {},
      "database_specific": {}
    }
  ],
  "references": [
    {
      "type": "string",
      "url": "string"
    }
  ],
  "credits": [
    {
      "name": "string",
      "contact": [
        "string"
      ],
      "type": [
        "string"
      ]
    }
  ],
  "database_specific": {}
}

We should implement a CVE 5.0 converter to/from OSV.

Go, GitHub, and Rust all define their own way of specifying affected functions:

• https://go.dev/security/vuln/database
• https://github.com/github/advisory-database/blob/842e4bc17b3bf12f3bb648ab984f8fd2b3fe7202/advisories/github-reviewed/2021/08/GHSA-9r2w-394v-53qc/GHSA-9r2w-394v-53qc.json#L49
• https://github.com/rustsec/advisory-db/blob/1e82879b3b3dcca2888e7c51361257d672cb18a4/crates/RUSTSEC-2021-0072.json#L23

We should define a unified field for expressing these in a way that works for all languages and their nuances.

Per some of the conversation in #50, allowing the use of database_specific on a permanent and intentional basis could lead to an undesirable fracturing of the OSV standard, where every database has their own pet fields that get included and create sub-standards. (Obligatory XKCD)

By renaming the database_specific field to experimental, it would still allow databases to explore new fields for inclusion in the OSV schema proper, while making it clear that those fields are not official and reliable yet. It would also encourage databases to push for fields that are being heavily used in their own projects back upstream into the central OSV format.

Description

Hi!

I was trying to express some NVD vulnerabilities with OSV.
They use these keywords for the ranges

• versionStartIncluding
• versionStartExcluding
• versionEndIncluding
• versionEndExcluding

So we can have these type of intervals

• [X,..., Y] : from X to Y, both ends included
• [X,..., Y) : from X to Y, X included, Y excluded
• (X,..., Y] : from X to Y, X excluded, Y included
• (X,..., Y) : from X to Y, both ends excluded

But here in OSV, we have:

• introduced: this is equivalent to versionStartIncluding
• fixed: this is equivalent to versionEndExcluding
• last_affected: this is equivalent to versionEndIncluding
• limit: in this context, it is similar to fixed

It isn't posible to express (X,..., Y] / (X,..., Y) ranges, we are missing an equivalen to versionStartExcluding.

Example

The https://nvd.nist.gov/vuln/detail/CVE-2022-34465 vulnerability has this type of ranges

CVSS_V3 | A CVSS vector string representing the unique characteristics and severity of the vulnerability using a version of the Common Vulnerability Scoring System notation that is >= 3.0 and < 4.0 (e.g."CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:N/A:N").

Can we please either:

1. add CVSS_V2 tag for CVSS v2 data (e.g. historical stuff)
2. change CVSS_V3 to CVSS and simply specify the CVSS version in the string (as generally done). This also solves the "what about CVSS v4 problem in future?

I noted in latest version of schema the addition of severity but seems to allow for multiple score of the same type without a means to distinguish so if you wanted to favour a severity say from a source it is challenging to work out. Currently there are only in database CVSS_V3 because of this lack of being able to distinguish identical score types should the data struct instead of being

"severity" : [
    {
         "type":"string",
         "score":"string"
    }
]

as types really should be unique base don this

"severity" : {
     "type_key" : "score"
     ....
}

You could even enumerate the types supported but this allows same flexibility bit avoids the doubt around duplicate values as that is simply not valid.

So what is done today in the database would be;

"severity" : {
    "CVSS_V3": "CVSS v3 score uri"
    "CVSS_V2":"CVSS v3 score uri"
    "ANotherseverityscore": "An other score"
}

Moving discussion from #10.

When defining vulnerable version ranges, the > operator, aka lower bound exclusive, represents the last-known-good release before a vulnerability is introduced. It might be argued that if one knows the last-known-good, one should also know the first-known-bad. However, this isn't always possible, and in some cases there are legitimate reasons for using > even if one has access to the first-known-bad version.

Example 1 - prereleases

In SemVer syntax, 1.2.3.alpha1 is less than 1.2.3 because the former is a prerelease of the latter. If a vulnerability is known to have been introduced in a particular prerelease then one could simply say >= 1.2.3.rc2 which can be converted to an introduced range event type to cover all latter prereleases plus the release itself, assuming the order of the prereleases is alphabetical and machine parseable. However, sometimes there may be so many prereleases that it's not possible to immediately identify which ones are affected. In this case, one way to ensure that all prereleases are covered is to specify > last-known-good.

Example 2 - interlaced affected versions

If a package has multiple affected versions with interlaced fixes, it's reasonable to list them like so:

>= 2.0-beta7, < 2.3.2
> 2.3.2, < 2.12.4
> 2.12.4, < 2.17.1

That example is from the recent log4j vulnerability.

Proposal

One suggestion for handling this is to extend affected[].ranges[].events[] to accept an event with a "last known good" event, and change the validation so that at least one introduced OR "last known good" field is present. This can still be programmatically evaluated by comparing a given version to see if it's > the last known good, just as you could compare it to see if it's >= and introduced event. This could be expressed in the evaluation example in the schema docs by slightly altering the IncludedInRanges method:

func IncludedInRanges(v, ranges)
  vulnerable = false
  for range in ranges
    if BeforeLimits(v, range)
      for evt in sorted(range.events)
        if evt.last_known_good is present && v > evt.last_known_good
           vulnerable = true
        else if evt.introduced is present && v >= evt.introduced
           vulnerable = true
        if evt.fixed is present && v >= evt.fixed
           vulnerable = false

@woodruffw in google/osv.dev#857 mentioned

(Separately, I wonder if it might make sense to redefine the schema to enforce seconds-only precision -- having the microseconds in the published timestamp probably doesn't convey anything of value to most consumers and potentially makes naive timestamp comparison a little harder.)

https://www.cisa.gov/blog/2022/11/10/transforming-vulnerability-management-landscape

completley unusable until you support this. Why even bother to create your own standard?

This effort makes it much harder for defenders, congratulations on your standalone island

Let us know if and when you decide to join the rest of the planet

Context

Currently, GitHub's Advisory Database encodes pairs of (introduced, fixed) events in separate affected objects. This is because GitHub needs to preserve these pairs when converting the OSV entry back into their internal database represenation.

An example: https://github.com/github/advisory-database/blob/d6004eb8de91ad341605da869ab1b9f1e4abe433/advisories/github-reviewed/2017/10/GHSA-xgr2-v94m-rc9g/GHSA-xgr2-v94m-rc9g.json#L14

"affected": [
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "activesupport"
      },
      "ranges": [
        {
          "type": "ECOSYSTEM",
          "events": [
            { "introduced": "2.3.2" },
            { "fixed": "2.3.16" }
          ]
        }
      ]
    },
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "activesupport"
      },
      "ranges": [
        {
          "type": "ECOSYSTEM",
          "events": [
            { "introduced": "3.0.0" },
            { "fixed": "3.0.20" }
          ]
        }
      ]
    }
  ],

One obvious alternative here is to use a single affected entry and have two separate ECOSYSTEM ranges in there:

      "ranges": [
        {
          "type": "ECOSYSTEM",
          "events": [
            { "introduced": "2.3.2" },
            { "fixed": "2.3.16" }
          ]
        }, 
        {
          "type": "ECOSYSTEM",
          "events": [
            { "introduced": "3.0.0" },
            { "fixed": "3.0.20" }
          ]
        }
      ]

However, I believe this wasn't done, because GitHub needs to record version metadata using a <= operator, and relies on database_specific to this. One example: https://github.com/github/advisory-database/blob/d6004eb8de91ad341605da869ab1b9f1e4abe433/advisories/github-reviewed/2020/03/GHSA-gww7-p5w4-wrfv/GHSA-gww7-p5w4-wrfv.json

This has a bunch of affected entries that look like:

GHSA-gww7-p5w4-wrfv.json

    {
      "ranges": [
        {
          "type": "ECOSYSTEM",
          "events": [
            {
              "introduced": "2.0.0"
            }
          ]
        }
      ],
      "database_specific": {
        "last_known_affected_version_range": "<= 2.0.6"
      }
    },

Problems

There are a number of problems here:

1. Using the the current evaluation pseudo-code, the semantics of the GHSA-gww7-p5w4-wrfv.json entry above would mean: everything after 2.0.0 is affected, regardless of any fixes that are encoded afterwards in other affected entries.

   This advisory has fixes later specified in 2.8.11.5 and 2.9.10.1, but they're not going to be considered under the current evaluation algorithm. Any version after 2.0.0 will be incorrectly considered to be vulnerable.

2. Having duplicate package entries makes the entry a lot less lean than it should be

Proposed solutions

Add database_specific to affected[].ranges[]

If we instead add database_specific to affected[].ranges[], we could encode GHSA-gww7-p5w4-wrfv as

{
      "package": {
        "ecosystem": "Maven",
        "name": "com.fasterxml.jackson.core:jackson-databind"
      },
      "ranges": [
        {
          "type": "ECOSYSTEM",
          "events": [
            {
              "introduced": "2.0.0"
            },
          ],
          "database_specific": {
            "last_known_affected_version_range": "<= 2.0.6"
          }
        }, 
        {
          "type": "ECOSYSTEM",
          "events": [
            {
              "introduced": "2.1.0"
            },
          ],
          "database_specific": {
            "last_known_affected_version_range": "<= 2.1.5"
          }
        }, 
        ...
      ],

The pseudo-code as is should work as intended with this encoding (with minor changes re sorting), and the resulting JSON has far less duplication.

Support a <= event

Similar to above, rather than encoding this in database_specific, we support a "last_affected" event or something similar:

      "ranges": [
        {
          "type": "ECOSYSTEM",
          "events": [
            {
              "introduced": "2.0.0",
              "last_affected": "2.0.6"
            },
          ],
        }, 
        {
          "type": "ECOSYSTEM",
          "events": [
            {
              "introduced": "2.1.0",
              "last_affected": "2.1.5"
            },
          ],
        }, 

In the vast majority of cases, GitHub does actually know the exact fix version (example), but they would still like to record this <= information for use in tools such as Dependabot.

Supporting this would mean we potentially complicate our version specification, and potentially encourage entries that only use last_affected when we really want fixed in all cases. On the other hand, CVE 5.0 does support a lessThanOrEqual, and perhaps OSV was missing this.

Fix the evaluation algorithm to consider all affected entries for the same package.

We could alternatively make the pseudo-code handle these problematic cases, but it doesn't seem ideal as it:

• Does not address the duplication issue. The intention of having multiple duplicate affected entries for the same package was to encode things like platform configurations where the set of affected versions are not the same.
• Complicates the algorithm.

It would be incredibly useful to have some standard way of referring to generic tooling that is part of a language or OS ecosystem, but not actually installed via that ecosystem's package registry.

An example might be cargo, which is a part of the rust ecosystem and has advisories issued from the Rust Advisory Database but is apart from the existing crates.io OSV ecosystem (some previous discussion on this)

Or a very recent example would be some way to refer to generic nodejs that hasn't been installed via a system package manager and would be separate from the existing npm OSV ecosystem, but still quite important to have some standard way of representing security advisories for. That would also hopefully open the door to flagging these tools within the existing GitHub Advisory Database for the languages they currently support

So according to: https://github.com/ossf/osv-schema/tags
We have 0.7.1, 1.0.0, 1.3.0

And according to https://github.com/ossf/osv-schema/releases
We have 0.7.1, 1.2.0 and 1.3.0

but the 1.2.0 file has a file path of "osv-schema-1.0.0"

So is 1.2.0 actually 1.0.0? I ask because GHSA's specifies 1.2.0 for OSV version.

Can we make "schema_version" a required tag? Currently I have to brute force it by applying schemas until one passes, and it also makes identifying the files tricky.

When embedding the OSV schema into another schema using $ref we get an error:

Error: https://raw.githubusercontent.com/ossf/osv-schema/v1.3.1/validation/schema.json is not a schema. Found a document with media type: text/plain

https://raw.githubusercontent.com/ossf/osv-schema/v1.3.1/validation/schema.json serves as text plain which fails: it needs to be served as "application/schema+json"

is there some official endpoint at osv.dev for example that serves the various schema files as application/schema+json?

If there already is one I apologize, I couldn't find it.

Where do we put the vendor name? There are lots of packages, sometimes in the same ecosystem, or not really in any ecosystem at all, for which the vendor name is really helpful.

The osv-data seems to do things like:

"ecosystem": "Debian:5.0",
"ecosystem": "Debian:10",

is this the official way to do it? If so can we update the documentation at https://ossf.github.io/osv-schema/#affected-fields doesn't mention this explicitly but does show examples, and:

Your ecosystem here. | Send us a PR.

if so (for the data I'm currently working with) there are about 50 vendors with 100+ items, 250 with 10-99 and 300 with 5-9. What's the bar for entry here to get listed? Do they need to be listed? (E.g. you have Debian so can we add all the major Linux vendors? BSD's?).

so I found a vuln in service, they fixed it, I updated the GSD entry:

CloudSecurityAlliance/gsd-database#2366

and realized there's no way to list a date.

affected[].ranges[].type field supports SEMVER/ECOSYSTEM/GIT, and an easy fix here would be to add TIME (suggested RFC 3339 format), so can we add that, specified as RFC 3339 format? Thanks

So for reference types we have:

FIX: A source code browser link to the fix (e.g., a GitHub commit) Note that the fix type is meant for viewing by people using web browsers. Programs interested in analyzing the exact commit range would do better to use the GIT-typed affected[].ranges entries (described above).

But we have no inverse, no "INTRODUCED", and for many of these vulnerabilities we have the commit/change/issue/pull/etc that introduced the vulnerability, but no way to label it as such. I would like to simply suggest we add "INTRODUCED" as the inverse of "FIX" for the reference types.

Currently, the way to discover / determine OSV producers is to look at the README.md in this repo.

There should be a more well defined way to do this.

I just noticed if I have two different severities for the same identifier, I can't note this in a sensible manner.

For example

Let's say ID-1 affects two Linux distributions differently. On one distro it's critical, on the other it's important.

Right now the severity field is inflexible
https://ossf.github.io/osv-schema/#severity-field

It's an array, but the spec only support CVSSv3, and there is no way to namespace the findings into package or ecosystem. In the affected fields, I will specify an ecosystem to account for this

{"ecosystem": "distro1", "name": "package"}

and

{"ecosystem": "distro2", "name": "package"}

I've also seen instances where different versions have different severities to make this even more difficult. This is less common, so trying to put severity in the affected field would create a lot of duplication for what is not a common occurrence.

👾

It would be great to pull in advisory data from the GitLab Community Advisory Database.

I think transforming the GitLab format into OSV shouldn't be too difficult; however, figuring out what to use as the identifier within OSV might need some discussion as GitLab primarily use the cve Id as the identifier within their DB. Perhaps something like a prefix of GITLAB and the uuid from the record (although that field isn't documented and I haven't verified it exists on every record)?

Also, I know @oliverchang submitted an issue directly to GitLab quite some time ago about exporting OSV directly, but I'm not sure there's been much movement there yet.

I do think it'd be valuable to start bringing this in as there is quite a bit more coverage particularly in the maven ecosystem than GitHub currently has. I'm very slowly working on getting them in sync, but that is going to take quite a long time

affected[].ranges[].type missing timestamp type

So we have:
https://github.com/cloudsecurityalliance/gsd-database/blob/main/2023/1001xxx/GSD-2023-1001657.json

"product_version": "prior to Jan 4 of 2023 (2022/01/04)",
"vulnerability_type": "XSS",
"affected_component": "https://app.zerossl.com",

as it's a service there is no good way to specify a version. But we know for sure it was vulnerable prior to the fix time, so this is actionable information (if you have any certs from them that were created before this time you should probably roll them over).

having a TIMESTAMP type in addition to SEMVER and GIT would solve this problem easily. Can I submit a PR to add this?

As we've seen there's a lot of vulns in a lot of services and we need to start documenting them.

So I'm finding timeline analysis is a lot easier when the Source URLs are tagged with time data, can I suggest we add an (optional, not required) support for a publishedDate and lastModifiedDate, e.g. almost all Red Hat RHSA's have it (Issued: 2017-11-16 Updated: 2017-11-16), Debian DSA (Date Reported: 09 Mar 2022), and so on.

From: https://ossf.github.io/osv-schema/

Special values
"introduced" allows a version of the value "0" to represent a version that sorts before any other version.

What does 0 mean? "since forever"? "unknown"? Something else? Right after we have:

"limit" allows versions containing the string "" to represent “infinity”. If no limit events are provided, an implicit { "limit": "" } is assumed to exist. Multiple "limit" events are allowed in the same range.

So I assume 0 is meant to assume the inverse, or "forever", but for example, this breaks in the common case where the code has NOT been present in the given software since "forever" (e.g. the Linux Kernel, a lot of security fixes are for code added in the last decade, not earlier). Can we please clearly define what the "0" means?

The algorithm for evaluating if a package/version is affected by a vulnerability (https://ossf.github.io/osv-schema/#evaluation) is dependent on the order of ranges. It doesn't look like this is intentional.

func IncludedInRanges(v, ranges)
  vulnerable = false
  for range in ranges
    if BeforeLimits(v, range)
      for evt in sorted(range.events)
        if evt.introduced is present && v >= evt.introduced
           vulnerable = true
        else if evt.fixed is present && v >= evt.fixed
           vulnerable = false
        else if evt.last_affected is present && v > evt.last_affected
           vulnerable = false

  return vulnerable

If we have:

"ranges": [ {
    "type": "SEMVER",
    "events": [
      { "introduced": "1.1.0" },
      { "fixed": "1.1.3" },
    ]
}, {
    "type": "SEMVER",
    "events": [
      { "introduced": "0" },
      { "fixed": "1.0.2" },
    ]
} ]

Then according to this algorithm, 1.1.0 is not vulnerable: The first iteration of for range in ranges: sets vulnerable=true, the second iteration if sets vulnerable=false, and the function returns false.

I think there may be an implicit assumption that there will be only one range of a given type, but I can't find any such restriction in the spec. Perhaps I'm overlooking it. Even if there is such a restriction, however, it seems like IncludedInRanges should return true if any range matches the given version.