Re: regarding OSV / SUSE

[Andrew Pollock]

Hi Marcus,

Nice to e-meet you, lovely to get in touch with you so quickly off the back of chatting with Joerg earlier today.

As I'd mentioned to Joerg, we have an interest in expanding OSV's coverage of Linux distribution package vulnerability data, and I wanted to explore SuSE's interest levels in providing an OSV format feed of this.

https://ossf.github.io/osv-schema/ has details of the schema, and OSV.dev is the aggregator for the data.

Happy to have an interactive conversation to discuss further.

Regards

Andrew 

On Wed, 20 Sept 2023, 11:45 am Marcus Meissner, <meis...@suse.de> wrote:

Hi Andrew,

Joerg Roedel who is currently in Bilbao has met you and you asked to
reach out to person who could help with OSV.

This would be me, I am overseeing the security automation data
generation at SUSE.

We generate OVAL, CVRF and CSAF and CSAF VEX data at this time.

Ciao, Marcus
--
Marcus Meissner (he/him), Distinguished Engineer / Senior Project Manager Security
SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew McDonald, Werner Knoblich, HRB 36809, AG Nuernberg

[Marcus Meissner]

Hi Andrew!

I have OSV data output on my mid-range TODO list, so I would
write a generator and see what kind of verification to run against it
form your tooling / schemas.

I would reach out once I have something ready, although I currently
cannot see in how many weeks.

Ciao, Marcus

[Marcus Meissner]

Hi Andrew,

I am currently working on the emitter.

The one for "advisory" style information is kind of simple, there I also
know the "id" can be our own SUSE id as it already has a SUSE prefix.

It seems however sensible to also generate per-CVE OSV entries.

Does this make sense?

What kind of id should be best used for those?

SUSE-CVE-2023-424242 ?

Ciao, Marcus

On Thu, Sep 21, 2023 at 06:23:17PM +0200, Andrew Pollock wrote:
> Hi,
>
> That's wonderful to hear. If you have any questions or think we can be of
> any assistance please don't hesitate to reach out.
>
> Regards
>
> Andrew

> > --
> > You received this message because you are subscribed to the Google Groups
> > "osv-discuss" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to osv-discuss...@googlegroups.com.
> > To view this discussion on the web visit
> > https://groups.google.com/d/msgid/osv-discuss/20230921154005.GL23149%40suse.de
> > .

[Andrew Pollock]

Hi Marcus,

I think it will make more sense to use the related or aliases field, and put the CVE ID in this field.

https://ossf.github.io/osv-schema/ discusses the subtleties between the two fields.

We can spot check a few records and provide feedback prior to commencing importing them.

Regards

Andrew

[Andrew Pollock]

Hi again,

I took a look at a concrete example of an existing advisory, https://www.suse.com/support/update/announcement/2023/suse-su-20234370-1/ and as you've noted, you can use your existing ID, and based on the CVEs listed as cross-references, assuming this one advisory relates to a single update that encompasses fixes for all of these vulnerabilities in one version bump, it would make the most sense to use OSV's related field to list the CVEs.

regards

Andrew

--

Andrew Pollock Software Engineer, Google Open Source Security Team | apol...@google.com Google LLC

This email is confidential. If you are not the right addressee, please inform the sender and please erase this email including any attachments.

[Marcus Meissner]

Hi,

I am generating these kind of advisories now for SUSE and openSUSE,
and relation has the CVE lists.

Can be found here:
https://ftp.suse.com/pub/projects/security/osv/

I would appreciate feedback if something is incorrect or missing.


What I see as gap:

- I cannot add CVSS scores to the advisory style OSV (besides potentially using the vendor specific fields).
- I cannot communicate some form of rating for the advisory (also except vendor specific fields).


This is why I was looking if a secondary per-CVE based space would make
sense for us.

Ciao, Marcus

> Andrew Pollock
>
> Software Engineer, Google Open Source Security Team | apol...@google.com
>
> Google LLC
>
> This email is confidential. If you are not the right addressee, please
> inform the sender and please erase this email including any attachments.

[Andrew Pollock]

On Wed, 8 Nov 2023 at 03:08, Marcus Meissner <meis...@suse.de> wrote:

Hi,

I am generating these kind of advisories now for SUSE and openSUSE,
and relation has the CVE lists.

Can be found here:
        https://ftp.suse.com/pub/projects/security/osv/

I would appreciate feedback if something is incorrect or missing.

Very cool! We'll take a look and collectively give you feedback, rather than giving it piecemeal so you can act on it all in one go.

 

What I see as gap:

- I cannot add CVSS scores to the advisory style OSV (besides potentially using the vendor specific fields).

You can, see https://ossf.github.io/osv-schema/#severity-field

 

- I cannot communicate some form of rating for the advisory (also except vendor specific fields).

Can you elaborate on your needs with this "rating", beyond what https://ossf.github.io/osv-schema/#severity-field seeks to achieve?

--

Andrew Pollock Software Engineer, Google Open Source Security Team | apol...@google.com Google LLC

[Marcus Meissner]

Hi Andrew,

On Wed, Nov 08, 2023 at 10:28:40AM +1100, Andrew Pollock wrote:
> On Wed, 8 Nov 2023 at 03:08, Marcus Meissner <meis...@suse.de> wrote:
>
> > Hi,
> >
> > I am generating these kind of advisories now for SUSE and openSUSE,
> > and relation has the CVE lists.
> >
> > Can be found here:
> > https://ftp.suse.com/pub/projects/security/osv/
> >
> > I would appreciate feedback if something is incorrect or missing.
> >
> >
> Very cool! We'll take a look and collectively give you feedback, rather
> than giving it piecemeal so you can act on it all in one go.

Thank you!

> >
> > What I see as gap:
> >
> > - I cannot add CVSS scores to the advisory style OSV (besides potentially
> > using the vendor specific fields).
> >
>
> You can, see https://ossf.github.io/osv-schema/#severity-field
>
>
> > - I cannot communicate some form of rating for the advisory (also except
> > vendor specific fields).
> >
> >
> Can you elaborate on your needs with this "rating", beyond what
> https://ossf.github.io/osv-schema/#severity-field seeks to achieve?

The thing is that advisories contain 0-n CVEs and usually the CVSS v3
score is associated with a CVE, not with an advisory.

While the severity field could list multiple CVSS_V3 scores, it has no
CVE assocation for them.

Thats why I was also looking at seperate OSV tree, not indexed by
advisory but indexed by CVE. I have attached a sample JSON for this.

Ciao, Marcus

[Andrew Pollock]

On Thu, 9 Nov 2023 at 01:02, Marcus Meissner <meis...@suse.de> wrote:

Hi Andrew,

On Wed, Nov 08, 2023 at 10:28:40AM +1100, Andrew Pollock wrote:
> On Wed, 8 Nov 2023 at 03:08, Marcus Meissner <meis...@suse.de> wrote:
>
> > Hi,
> >
> > I am generating these kind of advisories now for SUSE and openSUSE,
> > and relation has the CVE lists.
> >
> > Can be found here:
> >         https://ftp.suse.com/pub/projects/security/osv/
> >
> > I would appreciate feedback if something is incorrect or missing.
> >
> >
> Very cool! We'll take a look and collectively give you feedback, rather
> than giving it piecemeal so you can act on it all in one go.

Thank you!

> >
> > What I see as gap:
> >
> > - I cannot add CVSS scores to the advisory style OSV (besides potentially
> > using the vendor specific fields).
> >
>
> You can, see https://ossf.github.io/osv-schema/#severity-field
>
>
> > - I cannot communicate some form of rating for the advisory (also except
> > vendor specific fields).
> >
> >
> Can you elaborate on your needs with this "rating", beyond what
> https://ossf.github.io/osv-schema/#severity-field seeks to achieve?

The thing is that advisories contain 0-n CVEs and usually the CVSS v3
score is associated with a CVE, not with an advisory.

Ah, I see.

 

While the severity field could list multiple CVSS_V3 scores, it has no
CVE assocation for them.

Thats why I was also looking at seperate OSV tree, not indexed by
advisory but indexed by CVE. I have attached a sample JSON for this.

So here's my thoughts on this:

I'm assuming that SuSE users looking at using OSV data (with something OSV-Scanner, or other solutions using OSV.dev) are going to be interested in identifying and remediating as many vulnerabilities as possible. If vulnerabilities tracked by CVE IDs are potentially bundled into SuSE advisories, I see the SuSE advisory being the most useful unit to be surfacing with scanning tools.

So on the severity front, why not just take the maximum severity for the composite CVEs that an advisory relates to? For advisories that do not have any CVEs, it's perfectly fine to omit the severity field, or supply one determined by other means.

In other words, I'm suggesting not to worry about the individual CVEs and just keep them bundled as SuSE advisories.

The next steps are to get a prefix added to the OSV-Schema, here's a few previous pull requests to look to for inspiration:

• https://github.com/ossf/osv-schema/pull/141
  
• https://github.com/ossf/osv-schema/pull/188
• https://github.com/ossf/osv-schema/pull/190 

With the ecosystem field, what we've done with other distributions, and I'd recommend we do here as well, is to have colon delimiting releases or products.

For example, based on spot checking a few records (and please forgive my overall ignorance of the specifics of openSUSE as a distribution):

Points in common:

• For the ecosystem
• Use a "product" and a "version" separated by a colon (whitespace on either side of the colon is okay)
• Be consistent with the values on either side of the colon
• If there's a canonical source for validating the values on either side of colon, that helps a lot (and should be linked to from the schema definition) e.g. as described for Debian at https://ossf.github.io/osv-schema/#affectedpackage-field
• 
  

https://ftp.suse.com/pub/projects/security/osv/openSUSE-SU-2023%3A0361-1.json (no related CVEs)

Is the SP4 versus SP5 significant in identifying the package? If so, I'd suggest:

"ecosystem": "SUSE Package Hub:15 SP4"

"ecosystem": "SUSE Package Hub:15 SP5"

"ecosystem": "openSUSE Leap:15.4"

"ecosystem": "openSUSE Leap:15.5"

I see https://lists.opensuse.org/archives/list/security...@lists.opensuse.org/thread/6CUKHNCCOEC5HWMHMSYJY6GFFOSP2ZIL/ mentions a "moderate" rating. I think it's fine to either omit the severity, define a CVSS score, or alternatively, per the guidance at https://ossf.github.io/osv-schema/#severity-field we could discuss adding a new type over a pull request.

https://ftp.suse.com/pub/projects/security/osv/openSUSE-SU-2023%3A0360-1.json (many related CVEs)

"ecosystem": "SUSE Package Hub:12"

For the severity field, I'd suggest taking the maximum severity from the related CVEs. Taking a look over them, and using either the maximum base score, or exploitability score, or impact score, or some combination of these (again, I'd advise to be consistent with the selection criteria, and document this in the schema documentation for your prefix), all seem to point to CVE-2023-39323 seems like it has the highest base score and impact score, and there's a few that tie with it for exploitability score.

https://ftp.suse.com/pub/projects/security/osv/openSUSE-SU-2023%3A0354-1.json (one related CVE)

 If it's important for accurate conveyance of detail to users, and there should be a differentiation between "openSUSE Leap" and "openSUSE Leap NonFree", then

"ecosystem": "openSUSE Leap:15.5"

or

"ecosystem": "openSUSE Leap NonFree:15.5"

Given the single related CVE, just pull the existing CVSS score straight across to the OSV record.

 

Please let us know your thoughts, and if it would be beneficial to have an interactive conversation about any of this, I'm happy to find a mutually workable time to have a video call.

Ciao, Marcus

[Oliver Chang]

Hi Marcus, 

Thank you very much for helping get an OSV feed out for this so quickly! 

Alternatively, if per-CVE severity is an important piece of metadata for consumers, this can be encoded in `database_specific`. 

I'd like to echo Andrew's preference for keeping the SuSE IDs as well, if this is how they're typically surfaced. Having them be consistent across different export formats seems like a big win to me. 

 

The next steps are to get a prefix added to the OSV-Schema, here's a few previous pull requests to look to for inspiration:

• https://github.com/ossf/osv-schema/pull/141
  
• https://github.com/ossf/osv-schema/pull/188
• https://github.com/ossf/osv-schema/pull/190 

With the ecosystem field, what we've done with other distributions, and I'd recommend we do here as well, is to have colon delimiting releases or products.

+1. We'd need a PR against https://github.com/ossf/osv-schema to define the SuSE ecosystem in a way that's consistent and machine readable. 

Do you think you could help us with providing a definition for the "SuSE" ecosystem? 

E.g. for Debian (which seems like it's much simpler compared to SuSE), the definition looks like this:

The Debian package ecosystem; the name is the name of the source package. The ecosystem string might optionally have a :<RELEASE> suffix to scope the package to a particular Debian release. <RELEASE> is a numeric version specified in the Debian distro-info-data. For example, the ecosystem string “Debian:7” refers to the Debian 7 (wheezy) release.

And packages are specified like so: 

      "package": {
        "ecosystem": "Debian:10",
        "name": "netty"
      },

--

You received this message because you are subscribed to the Google Groups "osv-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to osv-discuss...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/osv-discuss/CAAJmWJ%2Boxtj%3D%3DRb1P7ReAy8zz%3Dpc56%3DHhizn2Vej2ZHncHZnBQ%40mail.gmail.com.

[Marcus Meissner]

Hi,

thanks for the emails!

I am currently on sickleave, but will get to it when I am back!

Ciao, Marcus

> <https://ossf.github.io/osv-schema/#database_specific-field>.

>
> I'd like to echo Andrew's preference for keeping the SuSE IDs as well, if
> this is how they're typically surfaced. Having them be consistent across
> different export formats seems like a big win to me.
>
>
> >
> > The next steps are to get a prefix added to the OSV-Schema, here's a few
> > previous pull requests to look to for inspiration:
> >

> > - https://github.com/ossf/osv-schema/pull/141
> > - https://github.com/ossf/osv-schema/pull/188
> > - https://github.com/ossf/osv-schema/pull/190

> >
> > With the ecosystem field, what we've done with other distributions, and
> > I'd recommend we do here as well, is to have colon delimiting releases or
> > products.
> >
>
> +1. We'd need a PR against https://github.com/ossf/osv-schema to define the
> SuSE ecosystem in a way that's consistent and machine readable.
>
> Do you think you could help us with providing a definition for the "SuSE"
> ecosystem?
>
> E.g. for Debian (which seems like it's much simpler compared to SuSE), the
> definition looks like this

> <https://ossf.github.io/osv-schema/#affectedpackage-field>:

>
> The Debian package ecosystem; the name is the name of the source package.
> The ecosystem string might optionally have a :<RELEASE> suffix to scope the
> package to a particular Debian release. <RELEASE> is a numeric version
> specified in the Debian distro-info-data

> <https://debian.pages.debian.net/distro-info-data/debian.csv>. For example,

> the ecosystem string “Debian:7” refers to the Debian 7 (wheezy) release.
>
> And packages are specified like so

> <https://storage.googleapis.com/debian-osv/dla-osv/DLA-3656-1.json>:

>
> "package": {
> "ecosystem": "Debian:10",
> "name": "netty"
> },
>
>
>
> > For example, based on spot checking a few records (and please forgive my
> > overall ignorance of the specifics of openSUSE as a distribution):
> >
> > Points in common:
> >

> > - For the ecosystem
> > - Use a "product" and a "version" separated by a colon (whitespace

> > on either side of the colon is okay)

> > - Be consistent with the values on either side of the colon
> > - If there's a canonical source for validating the values on either

> > side of colon, that helps a lot (and should be linked to from the schema
> > definition) e.g. as described for Debian at
> > https://ossf.github.io/osv-schema/#affectedpackage-field

> > -

> > Andrew Pollock
> >
> > Software Engineer, Google Open Source Security Team | apol...@google.com
> >
> > Google LLC
> >
> > This email is confidential. If you are not the right addressee, please
> > inform the sender and please erase this email including any attachments.
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "osv-discuss" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to osv-discuss...@googlegroups.com.
> > To view this discussion on the web visit
> > https://groups.google.com/d/msgid/osv-discuss/CAAJmWJ%2Boxtj%3D%3DRb1P7ReAy8zz%3Dpc56%3DHhizn2Vej2ZHncHZnBQ%40mail.gmail.com

> > <https://groups.google.com/d/msgid/osv-discuss/CAAJmWJ%2Boxtj%3D%3DRb1P7ReAy8zz%3Dpc56%3DHhizn2Vej2ZHncHZnBQ%40mail.gmail.com?utm_medium=email&utm_source=footer>

[Andrew Pollock]

Get well soon!

[Marcus Meissner]

Hi,

sorry for the delay in reply.

I will put a hold on the per-CVE id for now, or integrate it into the
per-advisory data via the private fields.


I thought about this ecosystem a bit and for me it seems a bit challenging to
follow the others, like "Debian:<nr>" or so due to the amount of
distinct products we have.

Or is there possibility to just say "with a prefix of 'SUSE' its the SUSE
ecosystem"?

Or would it make sense to have a bit of duplication, so something like this
for the bigger SUSE family:

"SUSE:SUSE Linux Enterprise Server 12 SP5"
"SUSE:SUSE Manager 4.3"
"SUSE:SUSE Linux Enterprise Module for Basesystem 15 SP4"
...


For openSUSE I could follow the Debian/Rocky/Alma pattern and use this:

"openSUSE:Leap 15.4"
"openSUSE:Leap Micro 5.5"
"openSUSE:Tumbleweed"

as there the product set is very small.

Ciao, Marcus



On Mon, Nov 20, 2023 at 11:05:08AM +1100, Oliver Chang wrote:

> <https://ossf.github.io/osv-schema/#database_specific-field>.

>
> I'd like to echo Andrew's preference for keeping the SuSE IDs as well, if
> this is how they're typically surfaced. Having them be consistent across
> different export formats seems like a big win to me.
>
>
> >
> > The next steps are to get a prefix added to the OSV-Schema, here's a few
> > previous pull requests to look to for inspiration:
> >

> > - https://github.com/ossf/osv-schema/pull/141
> > - https://github.com/ossf/osv-schema/pull/188

> > - https://github.com/ossf/osv-schema/pull/190

> >
> > With the ecosystem field, what we've done with other distributions, and
> > I'd recommend we do here as well, is to have colon delimiting releases or
> > products.
> >
>
> +1. We'd need a PR against https://github.com/ossf/osv-schema to define the
> SuSE ecosystem in a way that's consistent and machine readable.
>
> Do you think you could help us with providing a definition for the "SuSE"
> ecosystem?
>
> E.g. for Debian (which seems like it's much simpler compared to SuSE), the
> definition looks like this

> <https://ossf.github.io/osv-schema/#affectedpackage-field>:

>
> The Debian package ecosystem; the name is the name of the source package.
> The ecosystem string might optionally have a :<RELEASE> suffix to scope the
> package to a particular Debian release. <RELEASE> is a numeric version
> specified in the Debian distro-info-data

> <https://debian.pages.debian.net/distro-info-data/debian.csv>. For example,

> the ecosystem string “Debian:7” refers to the Debian 7 (wheezy) release.
>
> And packages are specified like so

> <https://storage.googleapis.com/debian-osv/dla-osv/DLA-3656-1.json>:

>
> "package": {
> "ecosystem": "Debian:10",
> "name": "netty"
> },
>
>
>
> > For example, based on spot checking a few records (and please forgive my
> > overall ignorance of the specifics of openSUSE as a distribution):
> >
> > Points in common:
> >

> > - For the ecosystem
> > - Use a "product" and a "version" separated by a colon (whitespace

> > on either side of the colon is okay)

> > - Be consistent with the values on either side of the colon
> > - If there's a canonical source for validating the values on either

> > side of colon, that helps a lot (and should be linked to from the schema
> > definition) e.g. as described for Debian at
> > https://ossf.github.io/osv-schema/#affectedpackage-field

> > -

> > Andrew Pollock
> >
> > Software Engineer, Google Open Source Security Team | apol...@google.com
> >
> > Google LLC
> >
> > This email is confidential. If you are not the right addressee, please
> > inform the sender and please erase this email including any attachments.
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "osv-discuss" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to osv-discuss...@googlegroups.com.
> > To view this discussion on the web visit
> > https://groups.google.com/d/msgid/osv-discuss/CAAJmWJ%2Boxtj%3D%3DRb1P7ReAy8zz%3Dpc56%3DHhizn2Vej2ZHncHZnBQ%40mail.gmail.com

> > <https://groups.google.com/d/msgid/osv-discuss/CAAJmWJ%2Boxtj%3D%3DRb1P7ReAy8zz%3Dpc56%3DHhizn2Vej2ZHncHZnBQ%40mail.gmail.com?utm_medium=email&utm_source=footer>

[Oliver Chang]

Thanks for getting back Marcus! Hope you're feeling better now. 

On Fri, 8 Dec 2023 at 03:48, Marcus Meissner <meis...@suse.de> wrote:

Hi,

sorry for the delay in reply.

I will put a hold on the per-CVE id for now, or integrate it into the
per-advisory data via the private fields.


I thought about this ecosystem a bit and for me it seems a bit challenging to
follow the others, like "Debian:<nr>" or so due to the amount of
distinct products we have.

Or is there possibility to just say "with a prefix of 'SUSE' its the SUSE
ecosystem"?

Or would it make sense to have a bit of duplication, so something like this
for the bigger SUSE family:

"SUSE:SUSE Linux Enterprise Server 12 SP5"
"SUSE:SUSE Manager 4.3"
"SUSE:SUSE Linux Enterprise Module for Basesystem 15 SP4" 

...

If we define a "SUSE" ecosystem, we have freedom to define what comes after it, and duplication isn't needed.

e.g. "SUSE:Linux Enterprise Server 12 SP5".

That said, is there an authoritative list of the products that can come after the ":" here? Such that there is a single way to refer to the same software, and users can easily construct this by following well defined rules? 

 

For openSUSE I could follow the Debian/Rocky/Alma pattern and use this:

"openSUSE:Leap 15.4"
"openSUSE:Leap Micro 5.5"
"openSUSE:Tumbleweed"

Sounds good! Similar question here regarding the bits that can come after ":" though. Is there an authoritative list or set of rules for how to specify the exact product in a consistent way? 

e.g. the OSV schema refers to the first column of this Debian release csv for the valid strings that can come after ":".

Cheers,

Oliver

[Marcus Meissner]

Hi,

Sounds reasonable to do it.

It is a long and growing list, currently around 300+ when I do a quick
grep.

But it could directly identified by the ecosystem.


I was also looking a bit into scanner for identification purposes,
there would need some RPM query relation for each of them:

"SUSE:Linux Enterprise Server 12 SP5" <=> RPM sles-release == 12.5

And this might need to be a hardcoded list.

I so far did not go into reading up on "purl" specification, this
might probably best bet here for identification instead of hardcoding
relations.

> > For openSUSE I could follow the Debian/Rocky/Alma pattern and use this:
> >
> > "openSUSE:Leap 15.4"
> > "openSUSE:Leap Micro 5.5"
> > "openSUSE:Tumbleweed"
> >
>
> Sounds good! Similar question here regarding the bits that can come after
> ":" though. Is there an authoritative list or set of rules for how to
> specify the exact product in a consistent way?

This is a shorter list and association is similar easy.

Currently its around 20, growing by 3 - 4 each year

> e.g. the OSV schema refers to the first column of this Debian release csv

> <https://debian.pages.debian.net/distro-info-data/debian.csv> for the valid

> strings that can come after ":".

Ciao, Marcus

[Oliver Chang]

Hey Marcus,

Sorry for the delayed response! It's been busy leading up to the end of the year. 

Great! How easy would it be to enumerate this and store this somewhere as the "source of truth" for the OSV schema?  

I was also looking a bit into scanner for identification purposes,
there would need some RPM query relation for each of them:

        "SUSE:Linux Enterprise Server 12 SP5" <=> RPM sles-release == 12.5

And this might need to be a hardcoded list.

I so far did not go into reading up on "purl" specification, this
might probably best bet here for identification instead of hardcoding
relations.

Would you mind expanding on this a bit more about the relations that need to be set up here? Are there existing SuSE advisories that encode this detail that we could look at to understand this better? 

> > For openSUSE I could follow the Debian/Rocky/Alma pattern and use this:
> >
> > "openSUSE:Leap 15.4"
> > "openSUSE:Leap Micro 5.5"
> > "openSUSE:Tumbleweed"
> >
>
> Sounds good! Similar question here regarding the bits that can come after
> ":" though. Is there an authoritative list or set of rules for how to
> specify the exact product in a consistent way?

This is a shorter list and association is similar easy.

Currently its around 20, growing by 3 - 4 each year

Awesome! Similar question here: is there a source of truth list we can point to from https://ossf.github.io/osv-schema/ ?

And on the topic of the schema, would you be happy to open a PR against https://github.com/ossf/osv-schema/blob/main/docs/schema.md to add the "openSUSE" ecosystem to start with? We can also help with this and add you as a reviewer if you prefer. 

Thanks,

Oliver 

[Oliver Chang]

Hey Marcus,

Happy New Year! Hope you had a nice holiday break. 

We're still really excited to get OSV support for SuSE advisories going, so I wanted to follow up on our conversations from last year :) I think the main thing remaining is just coming up with ecosystem and package naming definitions. 

Is there anything we can help with to provide definitions of the SUSE and openSUSE ecosystems in the OSV Schema? Perhaps we can start with openSUSE if the set of products for that is easier? We just need an authoritative list to point to for the set of products and and add a definition in https://github.com/ossf/osv-schema/blob/main/docs/schema.md. 

Kind regards,

--

Oliver