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!