Enforce use of affected in csaf_security_advisory

[tschmidtb51]

Currently, we only enforce that a csaf_security_advisory has at least one product_status. That allows the production of CSAF security advisories with all products in status fixed. 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:

• Downgrade to csaf_base or
• add a version range below the fixed product (assuming that those are affected - less preferred as we are adding information that is not there and might be wrong).

[mprpic]

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.

[tschmidtb51]

@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:

---

Profile X: Security Advisory

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":

• The following elements MUST exist and be valid:
  • all elements required by the profile "CSAF Base".
  • /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.

• The value of /document/category SHALL be csaf_security_advisory.
• The following elements SHOULD exist:
  • /vulnerabilities[]/product_status/fixed

    Lists fixed products in regard to the vulnerability.

Profile Z: Historic Security Advisory

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":

• The following elements MUST exist and be valid:
  • all elements required by the profile "CSAF Base".
  • /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.

• The value of /document/category SHALL be csaf_historic_security_advisory.

---

Also a reference between the two profiles could be feasible:

Profile X: Security Advisory

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":

• The following elements MUST exist and be valid:
  • all elements required by the profile "CSAF Historic Security Advisory".
  • /vulnerabilities[]/product_status/affected

    Lists affected products in regard to the vulnerability.

• The value of /document/category SHALL be csaf_security_advisory.
• The following elements SHOULD exist:
  • /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).

[mprpic]

(warning: mostly subjective opinions ahead 😉)

By enforcing this in the standard, you're not encouraging, you're mandating 🙂 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.

[tschmidtb51]

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:

1. Old data should be able to stay with no or little effort.
2. Provide a standardized differentiation so that not each and every customer needs to specify which fields need to be there for automation.
3. Make it easy for all parties in the ecosystem to support it.
4. Improve data quality over time and make sure it just grows and does not degrade.

I think the suggestion takes all of that into account:

• Affected data is important if you want to automate the matching against a users asset database. You can't just assume that everything before the fixed version is affected as there might be multiple versions that fixed (just think about Log4Shell),
• To be able to specify that affected products need to be listed, we need to specify that in the profile for the security advisory.
• When we change old data from CSAF 2.0 to CSAF 2.1, we need a mapping that data that was a valid 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.
• The term "Historic Security Advisory" should convey that this is not longer the recommended way of publishing security advisories. However, that would not harm for historic data. For newly published security advisories, this should encourage the authors to fulfill the additional requirement.
• It is intentionally not done as role. Roles apply to all documents - the csaf profile just to the current. So my expectation would be that there might be old advisories in CSAF 2.1 that still use the csaf_historic_security_advisory but from each newly published advisory fulfills the requirement.
• That transition might be for each issuing party at a different point in time. Many already fulfill the requirement, some not yet.
• By establishing the two profiles, we allow customers to choose whether they want a 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.

[mprpic]

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.

[tschmidtb51]

1. We can't change csaf_vex freely as we need to fulfill the minimum requirements given by the CISA community process.
2. Just listing fixed artefacts would actually be more a VEX then a security advisory. VEX communicates the state of a product so fixed without mentioning affected is definitely in-scope. Security advisories should help with remediations. However, if something is fixed, there doesn't need to be a remediation.

So if you want, we could change all the ones that just provide fixed product into csaf_vex.

[mprpic]

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.

[tschmidtb51]

If understood you correctly, it should look like this:

Profile Z: Legacy Security Advisory

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":

• The following elements MUST exist and be valid:
  • all elements required by the profile "CSAF Base".
  • /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.

• The value of /document/category SHALL be csaf_legacy_security_advisory.

---

Also a reference between the two profiles could be feasible:

Profile X: Security Advisory

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":

• The following elements MUST exist and be valid:
  • all elements required by the profile "VEX".
  • /vulnerabilities[]/product_status/affected

    Lists affected products in regard to the vulnerability.

  • For each product given in /vulnerabilities[]/product_status/fixed, the corresponding affected version have to be given.

    Corresponding versions are usually in the same branches element.
    TODO: add example

• The value of /document/category SHALL be csaf_security_advisory.
• The following elements SHOULD exist:
  • /vulnerabilities[]/product_status/fixed

    Lists fixed products in regard to the vulnerability.

Correct?

[mprpic]

Yes, the data requirements look right, except I'd prefer the names to be Profile Z: Security Advisory and Profile X: Complete/Comprehensive (pick one) Security Advisory. "Legacy" somehow makes it sound like it shouldn't ever be used (is considered deprecated) when in fact there are legitimate use cases for such advisory type.

[tschmidtb51]

For reasons of pushing best practices, I think Profile Z should have a different name and Profile X should continue to use the Security Advisory. That helps to improve the CSAF quality

[mprpic]

Then maybe call the "legacy" one Base Security Advisory? Although, that is fairly close the the CSAF Base category, though maybe that one should be called CSAF Minimum. Other suggestions welcome.

I personally would appreciate a name that doesn't portray a significant amount of development effort to publish CSAF security advisories to suddenly be considered "legacy" or "outdated" just because the rules changed around publishing certain fields :-)

[sthagen]

This issue has been futher discussed during the 2024-12-18 TC meeting and a call for action has been issued to continue the discussion and finalize in the January TC meeting.

[tschmidtb51]

Some additional comments:

• Reasoning for 2 profiles: By just introducing the new rule, a CSAF 2.0 document that is converted to CSAF 2.1 and has just fixed products would fall back to csaf_base profile. Therefore, the consumer (and producer) would loose the mandatory tests enforced in CSAF 2.0's csaf_security_advisory profile. The csaf_legacy_security_advisory provides the profile needed to keep the tests actionable. This allows CSAF issuing parties to make the transition of applying the new rule at their own pace.
• Reasoning for adding the rule: Matching algorithms need to know which products are there and which status they have - especially which ones are affected. Product status that are not stated in CSAF just mean that we don't have any information about the. So stating "anything before the fixed version is affected" is not true. Therefore, explicit stating the affected products is necessary. (see also Clearly state what not mentioning a product in product_status means #850)

[thschaffr]

The motion to "Enforce the use of affected in csaf_security_advisory has passed in today's meeting. (29.01.2025)

We will proceed with the profile name of:
Deprecated Security Advisory with the corresponding category named csaf_deprecated _security_advisory.

[rjb4standards]

What affect, if any, will this have on CSAF profile 4?

[tschmidtb51]

What affect, if any, will this have on CSAF profile 4?

The current (CSAF 2.0) profile "Security Advisory" will be renamed "Deprecated Security Advisory". A new (CSAF 2.1) profile "Security Advisory" will be introduced that contains the restriction.
The restriction is necessary to allow for automated matching CSAF documents against SBOMs or assets.

I hope that answers your question.

[rjb4standards]

Thank you Thomas. That answers my question. So CSAF 2.1 will continue to have a "Security Advisory" artifact with additional restrictions to ensure automated matching of SBOM components. That looks like a good enhancement/improvement to me.

Thank you.