Open tschmidtb51 opened 9 months ago
I am not a big fan of this being enforced. It's easy to perhaps add a catch-all that anything before the fixed version is affected, but then you might also be implicitly including versions that might not be vulnerable because they were released before the vulnerability was introduced into the product. Figuring out the exact ranges of affected versions costs a lot of time in analysis. In a perfect world, we'd have this data already but that's just not the case, especially for older CVEs. It would be a considerable amount of effort to figure out the exact affected versions for CVEs from 2010 and earlier, and I'm not sure it's worth it at this point. Publishing the information on at least fixed versions is still valuable and I would strongly dislike to see us having to remove that information or hobble it somehow (by downgrading the files to a lesser state) just because of this requirement.
@mprpic Thank you for your input. I see this question between the poles of keeping old data valid and encourage to produce better data for tomorrow. Just listing the fixed versions in security advisories makes matching very hard - how would they know that previous version should be deemed affected?
Here is my suggestion:
This profile SHOULD be used to provide information which is related to vulnerabilities, affected products and corresponding remediations.
A CSAF document SHALL fulfill the following requirements to satisfy the profile "Security Advisory":
/product_tree
which lists all products referenced later on in the CSAF document regardless of their state./vulnerabilities
which lists all vulnerabilities./vulnerabilities[]/notes
Provides details about the vulnerability.
/vulnerabilities[]/product_status
Lists each product's status in regard to the vulnerability.
/vulnerabilities[]/product_status/affected
Lists affected products in regard to the vulnerability.
/document/category
SHALL be csaf_security_advisory
./vulnerabilities[]/product_status/fixed
Lists fixed products in regard to the vulnerability.
This profile SHOULD be used to provide information which is related to vulnerabilities and corresponding remediations.
A CSAF document SHALL fulfill the following requirements to satisfy the profile "Historic Security Advisory":
/product_tree
which lists all products referenced later on in the CSAF document regardless of their state./vulnerabilities
which lists all vulnerabilities./vulnerabilities[]/notes
Provides details about the vulnerability.
/vulnerabilities[]/product_status
Lists each product's status in regard to the vulnerability.
/document/category
SHALL be csaf_historic_security_advisory
.Also a reference between the two profiles could be feasible:
This profile SHOULD be used to provide information which is related to vulnerabilities, affected products and corresponding remediations.
A CSAF document SHALL fulfill the following requirements to satisfy the profile "Security Advisory":
/vulnerabilities[]/product_status/affected
Lists affected products in regard to the vulnerability.
/document/category
SHALL be csaf_security_advisory
./vulnerabilities[]/product_status/fixed
Lists fixed products in regard to the vulnerability.
This would allow to keep historic security advisories labeled as "security advisories" and improve the situation for matching (as the requirement in the "Security Advisory" profile allows customers to request better data).
(warning: mostly subjective opinions ahead :wink:)
By enforcing this in the standard, you're not encouraging, you're mandating :slightly_smiling_face: Also, marking something as "historic" makes it sound like it should be (or will soon be) deprecated, which, considering the majority of vendors out there aren't publishing version ranges and distinguish between affected and fixed, would make most advisories published today historic.
Don't get me wrong, I'm all for improving the publishing of data that can lead to better automation, but it needs to happen via examples and real use cases, and needs to happen gradually. Most of the software industry (outside of security teams) doesn't currently see the value in diligently keeping track of this data so that it can be shared externally. Forcing them to do it won't explain the "why".
Could this instead be turned into a specific Role? Meaning if you meet certain requirements of providing complete affectedness data, you can claim a Role of "Complete Data Provider" or something similar? In fact, the CVE Program is having a similar discussion about measuring the quality of CVE records to ensure they all contain at least one valid reference, CVSS metrics, a vulnerability type (via CWE, for example), and component identifiers (CPE being discussed). CSAF could adopt a similar approach and simply reward publishers that provide complete data with elevated status.
I think we are on the same page but it looks like I did a bad job in explaining why I think this should be done exactly this way. I'll try to provide more details:
Objectives:
I think the suggestion takes all of that into account:
csaf_security_advisory
in CSAF 2.0 has a place in CSAF 2.1. We either need a new profile or all old data would fall back to csaf_base
(which is doable but a bit harsh and would also degrade the quality). Falling back to csaf_base
would also eliminate multiple business-level test which are important to hold the data quality standard, especially for newly generated advisories. (As not everyone might be able to fulfill the new requirement straight away (due to tool or processes etc.)). Therefore, I created the csaf_historic_security_advisory
. The name might not be the best choice and I'm open for suggestions.csaf_historic_security_advisory
but from csaf_historic_security_advisory
or a csaf_security_advisory
(the latter being recommended). This recommendation also promotes better data quality for automation.I hope this makes it clearer, why I suggest this way.
Don't we already have very similar requirements in the csaf_vex
profile though? Maybe the definitions there just need to be tightened up to explicitly state what the relationship between affected and fixed versions should be and we can leave the security advisory profile as is to allow simple listings of fixed artifacts.
csaf_vex
freely as we need to fulfill the minimum requirements given by the CISA community process.So if you want, we could change all the ones that just provide fixed product into csaf_vex
.
Well, the security advisory profile merely states that you must have a non-empty /vulnerabilities[]/product_status
while VEX states that you must include either a fixed status or unfixed (known affected, known not affected, under investigation). So VEX is the more restricting ones when it comes to defining what data needs to be present. The current VEX guidelines could be extended to add that for each element marked as /vulnerabilities[]/product_status/fixed
, there needs to be an element with a /vulnerabilities[]/product_status/known_affected
status that is in the same version lineage as the fixed component.
If understood you correctly, it should look like this:
This profile SHOULD be used to provide information which is related to vulnerabilities and corresponding remediations.
A CSAF document SHALL fulfill the following requirements to satisfy the profile "Legacy Security Advisory":
/product_tree
which lists all products referenced later on in the CSAF document regardless of their state./vulnerabilities
which lists all vulnerabilities./vulnerabilities[]/notes
Provides details about the vulnerability.
/vulnerabilities[]/product_status
Lists each product's status in regard to the vulnerability.
/document/category
SHALL be csaf_legacy_security_advisory
.Also a reference between the two profiles could be feasible:
This profile SHOULD be used to provide information which is related to vulnerabilities, affected products and corresponding remediations.
A CSAF document SHALL fulfill the following requirements to satisfy the profile "Security Advisory":
/vulnerabilities[]/product_status/affected
Lists affected products in regard to the vulnerability.
/vulnerabilities[]/product_status/fixed
, the corresponding affected version have to be given./document/category
SHALL be csaf_security_advisory
./vulnerabilities[]/product_status/fixed
Lists fixed products in regard to the vulnerability.
Correct?
Currently, we only enforce that a
csaf_security_advisory
has at least oneproduct_status
. That allows the production of CSAF security advisories with all products in statusfixed
. One might implicit assume that previous versions are affected. However, that is terrible for automated matching: If the advisory tells that Product A in version 4.2 is fixed and I have Product A but version 4.1 - the matcher can't tell me that I have an issue. Also, fixed products can't have remediations as they are fixed.The easiest transition rule (CSAF 2.0=> CSAF 2.1) would be:
csaf_base
or