feat(materials): Add support for CSAF 2.0 and 2.1 schemas and remaining CSAF_* materials

[javirln]

This pull request builds upon the changes introduced in PR #751 to implement CSAF version 2.0 and 2.1 support within Chainloop. This update incorporates three new CSAF Chainloop materials, expanding upon the existing CSAF VEX profile:

• Security Advisory
• Informational Advisory
• Security Incident Response

This implementation adheres to the CSAF 2.0 and 2.1 JSON schema verification standards, accessible here. Furthermore, it refactors the CSAFVEXCrafter to a more generalized CSAFCrafter, aligning with the JSON specification 2.0 and 2.1.

With this update, Chainloop contracts can now process the newly introduced materials, ensuring validation against the schema. Notably, there is no requirement to specify the csaf_version within the file, as Chainloop dynamically determines the appropriate schema for validation.

schemaVersion: v1
runner:
  type: GITHUB_ACTION
materials:
  - type: CSAF_INFORMATIONAL_ADVISORY
    name: informational-advisory
  - type: CSAF_SECURITY_ADVISORY
    name: security-advisory
  - type: CSAF_SECURITY_INCIDENT_RESPONSE
    name: security-incident-response

References: #635

This update enhances the versatility and compatibility of Chainloop with the latest CSAF standards.

[jiparis]

Looks great, just a couple of minor comments.

[migmartri]

Awesome!

I'd like to see if we can differentiate the different profiles. We could reuse a single crafter but we might need to do additional checks.

[migmartri]

On another note, let's not forget to document these new material types in the readme and the docs before release. Probably better in another patch, thanks!

[migmartri]

Awesome thanks!

[migmartri]

Left some comments for a future refactoring. For now I'd merge it.

Thanks!

[migmartri]

it would have been more clear if we use a custom struct with only the document and category objects.

[javirln]

hmm but the custom struct won't have the remaining fields to be passed down to the validator no? Maybe I'm missing something :/

[migmartri]

it will not, that's why I mentioned doing this validation after the other one. You might require another marshall process though.

Anyways, not a big deal, feel free to merge it :)

[migmartri]

if you use a custom struct I do not think you would have needed to do all these if checks and castings.

[migmartri]

I'd have done this validation after you do the base validation, that way you can guarantee that it's a base doc, and then use a custom struct to do a custom validation.

Does it make sense?

[migmartri]

it will not, that's why I mentioned doing this validation after the other one. You might require another marshall process though.

Anyways, not a big deal, feel free to merge it :)