Implement a PoC to export security-tracker data in CSAF/VEX format

We would like to export security-tracker data in a modern standard format, and we would like to rely on CSAF/VEX for that. This are some requirements (to be adjusted, if needed):

Provide general information that makes it possible to commonly identify the vulnerability (CVE ID). It is yet to be determined if the security-tracker should clearly identify alternative IDs, such vendor issues IDs.
Provide differentiated data per security-issue/package/debian-release/package-version/package-type, that must encompass, for every security-issue/package/debian-release/package-version/package-type:
- Status (Equivalent to: to be triaged / not fixed / ignored / fixed / does not affect)
- Severity (Critical, High, Medium, Low) -- currently missing in the security tracker
- Existing workarounds
- Justifications about why the Status is does not affect
Package-type here above refers to binary and source packages. So users can be informed that the source package of a given version is vulnerable (contains the vulnerable code) to a given security issue, while the binary package does not ship the vulnerable compiled code.
Additional information about the vulnerabilities could be provided in a per security-issue base. This means, we are not looking at giving additional comments (such as current NOTEs) in a security-issue/package/debian-release/package-version/package-type way.
Should be "SBOM-able", so consumers of future Software Bills of Materials could get vulnerability information along with the SBOMs. This means: "Be able to be integrated in supply-chain inventory for every debian package". SBOMs identifies all the components that were used to build an artifact (i.e. .buildinfo) and emerging SBOM standards aim at integrating vulnerability information. E.g. CycloneDX VEX or SPDX v3.
Users should be able to download files containing the data in the specified format, and give those files as input for vulnerability scanners. The scope of the files (per Debian release, single file for the whole security tracker) is to be determined.
Optionally, the security tracker information should be made available in a discoverable and standard method, that enhances the automation of its use by security scanners or related tools.* Provide general information that makes it possible to commonly identify the vulnerability (CVE ID). It is yet to be determined if the security-tracker should clearly identify alternative IDs, such vendor issues IDs.
Provide differentiated data per security-issue/package/debian-release/package-version/package-type, that must encompass, for every security-issue/package/debian-release/package-version/package-type:
- Status (Equivalent to: to be triaged / not fixed / ignored / fixed / does not affect)
- Severity (Critical, High, Medium, Low)
- Existing workarounds
- Justifications about why the Status is does not affect
Package-type here above refers to binary and source packages. So users can be informed that the source package of a given version is vulnerable (contains the vulnerable code) to a given security issue, while the binary package does not ship the vulnerable compiled code.
Include any information required to comply with existing regulations.
Additional information about the vulnerabilities could be provided in a per security-issue base. This means, we are not looking at giving additional comments (such as current NOTEs) in a security-issue/package/debian-release/package-version/package-type way.
Should be "SBOM-able", so consumers of future Software Bills of Materials could get vulnerability information along with the SBOMs.
Users should be able to download files containing the data in the specified format, and give those files as input for vulnerability scanners. The scope of the files (per Debian release, single file for the whole security tracker) is to be determined.
Optionally, the security tracker information should be made available in a discoverable and standard method, that enhances the automation of its use by security scanners or related tools.