Re: [oasis-tcs/csaf] As a consumer I want every CSAF document to be a security advisory. (#193)

["Omar Santos (osantos)" <osantos@cisco.com>]

Thank you, Allan!

 

This is a great discussion and an amazing use case (third-party software security advisories [since this could happen with open source and shared closed source, as well]).

 

I have included some comments to your questions below (tagged with [os]):

 

• inherits all from CSAF 2.0
• /product_tree: Which products are going to be mentioned in this security advisory?

[os] The document creator has the flexibility to use one or more of the ones below:

• one of:
• /vulnerabilities/0/product_status/known_not_affected: Which products are known to be not affected?

[os] There are several use cases:

1. A multi-vulnerability advisory from a vendor that reports what products are affected by a given vulnerability. A vendor like Red Hat, Oracle, Amazon, Cisco, etc. may respond to a given âOpenSSL vulnerabilityâ and list all the products that are affected and the products that are not affected in a single advisory.
2. Another use case is when there is only one product affected, but a variance, model, or version of that product may not be affected by that given vulnerability because of the way that it used that component.  This field can also be used to list those ânon affectedâ products/models, etc.

• /vulnerabilities/0/product_status/fixed: In which products was the vulnerability fixed before discovered?

[os] Fixed after discovered. However, this may not be the first fixed version that addresses the issue. Thus the field below (first_fixed).

• /vulnerabilities/0/product_status/first_fixed: In which products was the vulnerability fixed before discovered? Was this the first product with this change?

[os] Another use case is when you have a series of advisories that are linked together. For instance, a vendor may have published several vulnerabilities in âa bundleâ, each with a first fixed version, but then congregate the ârecommended releaseâ by calculating first_fixed and fixed.

Hope this helps. Any other thoughts from the TC and community? I love this brainstorming!

 

Regards,

 

Omar

 

From: Allan Friedman <notifications@github.com>
Reply-To: oasis-tcs/csaf <reply+AAM42ERCLRW6I2WWIZ4XG2F6LN537EVBNHHDCFXZYM@reply.github.com>
Date: Monday, March 15, 2021 at 1:35 PM
To: oasis-tcs/csaf <csaf@noreply.github.com>
Cc: "os@cisco.com" <os@cisco.com>, Mention <mention@noreply.github.com>
Subject: Re: [oasis-tcs/csaf] As a consumer I want every CSAF document to be a security advisory. (#193)

 

VEX

Thanks for starting on this! Very excited to engage and bring together two smart groups.

• inherits all from CSAF 2.0
• /product_tree: Which products are going to be mentioned in this security advisory?
• one of:

• /vulnerabilities/0/product_status/known_not_affected: Which products are known to be not affected?
• /vulnerabilities/0/product_status/fixed: In which products was the vulnerability fixed before discovered?
• /vulnerabilities/0/product_status/first_fixed: In which products was the vulnerability fixed before discovered? Was this the first product with this change?

The VEX/SBOM initial approach is to use 'known_not_affected' , 'known_affected' , and 'under_investigation'. Very happy to dive into these more.

• one of:

• /vulnerabilities[]/notes: Provide some details about what the vulnerability is about.
• /vulnerabilities[]/cve: Provide the corresponding CVE number.

While CVEs will be the most common, we'd like to build this agnostic to the type of vulnerability identifier.

There is one case, where it actually should use the product status fixed (resp. first_fixed) instead of known_not_affected: If the vulnerability was fixed (e.g. using an open source component but changed the lines with the vulnerability) before it was discovered.

Hmm. Would love more discussion on this, and input from the CSAF community. Our initial approach is to try to keep things simple from the consumer's perspective: is it affected or not. Futher details can inform how/why/when something is affected or isn't. (e.g. context, config, etc)

â
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.