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

[kurtseifried]

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.

[oliverchang]

@rsc @chrisbloom7 thoughts?

[oliverchang]

My main concern here is that this balloons the scope of OSV a little -- this is no longer about open source software (or packages), and it may be a case of trying to shoehorn a use case that may not fit OSV very well and end up with a worse experience overall.

Perhaps this is where GSD can help with defining a separate, more specialized scheme for these (which you've already done)?

[joshbuker]

I could go either way on this tbh.

On one hand, there's serious value in keeping OSV as lean and simple as possible. OTOH, a couple of these minor changes would vastly increase the versatility and allow machine readable parsing for things like services (URI based).

One of our goals with GSD is to avoid inventing new formats as much as possible, which is why expanding the scope of OSV just slightly would make our lives simpler. But, if it's valuable to the community, we could always use a more expansive format and provide API endpoints for consuming OSV.

Things like documentation IDs (e.g. SQL textbook with examples vuln to SQL injection, or a Stackoverflow post that is popular/widely used and vulnerable to an exploit) would clearly be out of scope for OSV, but are something we would like to cover in a machine-readable way.

[kurtseifried]

OSV continues to be lean, this doesn't bloat it, we're not adding new data, we're adding a new category of data, for which we have a lot of need, for a recent example:

https://nvd.nist.gov/vuln/detail/CVE-2023-28858

sources:
redis/redis-py@v4.3.5...v4.3.6 |
redis/redis-py@v4.4.2...v4.4.3 |  
redis/redis-py@v4.5.2...v4.5.3 |  
redis/redis-py#2624 |  
redis/redis-py#2641 |  
https://openai.com/blog/march-20-chatgpt-outage

which has the affected data of:

"affected": [
{
"vendor": "n/a",
"product": "n/a",
"versions": [
{
"version": "n/a",
"status": "affected"
}
]
}
]

ignoring that it needs redis-py in there, it would also be hugely helpful to list chat.openai.com as being vulnerable from time X to time Y, as per their blog entry listed in the CVE:

Open a subscription confirmation email sent on Monday, March 20, between 1 a.m. and 10 a.m. Pacific time.

In ChatGPT, click on “My account,” then “Manage my subscription” between 1 a.m. and 10 a.m. Pacific time on Monday, March 20.

Virtually everytime there is a cloud service issue, we're going to need a timeframe for vulnerability regardless of whether or not we can find an affected software/API/etc version.

[oliverchang]

The target audiences for OSV today (who want to leverage the schema + data to enable high quality automated vulnerability scanning + remediation of their package dependencies so that they can update), seem very different to what this change is trying to enable (someone who wants to know if they used a service at some URL while it was vulnerable so they can take appropriate remediation steps), in that a vulnerability scanner will have no way to make use of this data.

Adding this seems like an a bad fit for OSV, and I think a separate, more specialised mechanism targetd at this second target audience would be a better approach.

[joshbuker]

The target audiences for OSV today (who want to leverage the schema + data to enable high quality automated vulnerability scanning + remediation of their package dependencies so that they can update), seem very different to what this change is trying to enable (someone who wants to know if they used a service at some URL while it was vulnerable so they can take appropriate remediation steps), in that a vulnerability scanner will have no way to make use of this data.

Adding this seems like an a bad fit for OSV, and I think a separate, more specialised mechanism targetd at this second target audience would be a better approach.

That's fair. We've been trying to use OSV as the source of truth for GSD, and our scope is definitely larger than package ecosystem vuln scanners (e.g. bundler audit, yarn audit, etc) which is where these asks are coming from. Cloud services and documentation are both explicitly within the scope of the GSD. And less explicitly, any vuln data that would benefit from having machine-readable identifiers.

Definitely understandable having OSV cater to a specific use-case and stay strictly within that scope (it is in the name, "Open Source Vulnerability" after all). We'll have to revisit the source of truth for GSD so that we can use/serve OSV where possible, but be able to cover these other scopes.

Mainly, we want to avoid the standards issue, and have been trying to avoid creating a new format in a vacuum.

[kurtseifried]

To clarify, the GSD project has been using the OSV data format to structure GSD data, and our scope is definitely larger than just the open source package ecosystem, we also include cloud services built upon and using open source (sometimes exclusively). We could currently use the “ECOSYSTEM” tag:
ECOSYSTEM: The versions introduced and fixed are arbitrary, uninterpreted strings specific to the package ecosystem, which does not conform to SemVer 2.0’s version ordering.
So we could simply use a timestamp tag, but we’d rather acknowledge a very common case and make the data easier to parse.
While we understand that OSV may want to stay open source focussed, we are disappointed by the refusal to include an additional keyword (“TIMESTAMP”) which adheres to the logic and behavior of the already existing “SEMVER”, “ECOSYSTEM” and “GIT” keywords.

[kurtseifried]

Also a concrete example of why we need this: IBM Cloud advisories:

https://cloud.ibm.com/status/security

e.g. note the "start time" and "update time" in all of these:

IBM Cloud Kubernetes Service is affected by two containerd security vulnerabilities (CVE-2023-25153 and CVE-2023-25173)

Component: Kubernetes Service

Location: Sydney, Dallas, Tokyo, Frankfurt, Washington DC, Osaka, London, Sao Paulo, Toronto

Start time: 6 Mar 2023 2:15 AM

End time: N/A

Update time: 9 Mar 2023 9:16 AM

Type: Security bulletin

IBM Cloud Kubernetes Service is affected by two security vulnerabilities found in containerd where (1) a maliciously crafted image with a large file could cause a denial of service when importing an OCI image (CVE-2023-25153) and (2) supplementary groups are not set up properly inside a container which could bypass primary group restrictions in some cases (CVE-2023-25173).

A user action is required to verify that their cluster worker nodes are not exposed.

For information see the security bulletin.

[andrewpollock]

This seems to be a duplicate of #62 should this or it be closed out?

[kurtseifried]

they should be merged yah