Invalid CSAF files

Describe the bug
I tried using the CSAF feature and then had a look at a few of the CSAF files generated into https://api.main.devguard.org/api/v1/.well-known/csaf-aggregator/aggregator.json.
There a few things that are not right with the generated files.

Mandatory
In the vulnerabilities section

• the notes can't have an empty text
• each status under product_status must reference an element from the product_tree
• the product id should only be an internal reference (inside the document) with no meaning outside (see https://docs.oasis-open.org/csaf/csaf/v2.1/csaf-v2.1.html#product-id-type). You could use a PURL here, but it adds some confusion. PURLs belong to the product_identification_helpers
• cve should only contain valid CVEs

The /document/tracking/id and thus the file name should not be a CVE or some common string. A CSAF document is specific to your product for one or more vulnerabilities it may have, hence the id and file name should reflect that. Usually it comes in the form of an identifier for your company, your product and some increasing number or date scheme (i.e. OASIS_CSAF_TC-CSAF_2.0-2021-6-1-21-02, SSA-082556 (Siemens) ). Together with the namespace it should be globally unique. See https://docs.oasis-open.org/csaf/csaf/v2.1/csaf-v2.1.html#document-property-tracking-id for an explanation.

Recommended

• the products defined in relationships should be used
• the canonical_url is missing for the document
• the lang is missing for the document, instead you use source_lang which is reserved for entities only translating CSAF documents
• each item under /vulnerabilites[]/product_status/under_investigation should have a corresponding remediation, which can be of the category none_available
• in some files i've seen multiple products with the same product_identification_helper which is highly unusual
• the JSON should be sorted alphabetically on each level
• product names should be more human readable - for identifying programmatically, there are the product_identification_helpers

We are developing a rust csaf validation library at the moment https://github.com/csaf-rs/csaf where we'll try to add language binding through UniFFI, also for GO in the near future. This then may relate to #1727

If you need any help how CSAF files should look like, feel free to contact me.