feat(suse): replace CVRF feed with advisory CSAF updater

[manojkrishnanomula]

Summary

• Replace the legacy SUSE CVRF XML updater with a single advisory-level CSAF feed (csaf.tar.bz2).
• Store trimmed native CSAF JSON under csaf/suse/{suse|opensuse}/<year>/, including CVSS v3 and arch-normalized product relationships.
• Remove suse/cvrf and switch CI/docs to the new suse-csaf target.

Context

SUSE publishes advisory CSAF at the same granularity as CVRF (document.tracking.id = SUSE-SU-* / openSUSE-SU-*), with CVSS v3 scores and equivalent product relationships. This supersedes both the advisory CVRF feed (v2 only) and a separate per-CVE CVRF feed.

[DmitriyLewen]

Two moments:

1. Don't trim the data — store it as-is

In vuln-list-update the convention is to store source data as-is (raw) and do trimming/normalization in downstream repos (e.g. trivy-db). This PR is the only place in the whole repo that manually trims data before saving (trim, trimNotes, trimDocReferences, trimProductTree, trimVulnerabilities, trimScore).

For reference:

• The sibling CSAF updater redhat/csaf decodes into csaf.Advisory, calls advisory.Validate(), and stores the whole structure — no trimming.
• The old SUSE CVRF updater being removed here also stored the fully parsed structure.

Downsides of trimming here:

• Any new field Trivy needs later requires changes in this repo (trim* + types.go), whereas selecting fields should be the downstream's job.
• Silent data loss by design: if SUSE adds a new field/category (e.g. CVSS v4), it just won't make it into the output.
• Because of the manual trim with hand-written nil checks, a single malformed advisory aborts the whole archive walk (Update returns an error from walkArchive), dropping every subsequent advisory for that run.

Suggestion: align this updater with redhat/csaf — decode into csaflib.Advisory, optionally Validate(), and store it in full (utils.SaveCVEPerYear / WriteJSON), without trim*. That removes the trim functions and types.go and resolves several issues at once.

If there's a concern about feed size (SUSE advisory-level documents carry many products/arches), let's discuss and measure it — but we shouldn't diverge from the convention by default.

2. A companion trivy-db PR is required

Both the output path and the format change: it used to be cvrf/suse/... in the CVRF schema, now it's csaf/suse/... in a new schema. Meanwhile trivy-db (pkg/vulnsrc/suse-cvrf) reads the old cvrf/suse path and decodes the CVRF structure.

Once this PR merges and CI runs, the old cvrf/suse data stops updating while trivy-db can't read the new format yet — SUSE scanning in Trivy would silently degrade.

So a corresponding trivy-db PR for the new path/format is needed, and both PRs must be merged together (or in close coordination). Please link the related trivy-db PR here.

Note that this ties back to point 1: since we store the raw CSAF here, the trimming/normalization (the logic currently in the trim* functions) belongs in that trivy-db PR, where the new format is consumed.

[manojkrishnanomula]

Companion trivy-db PR is ready and linked here:\n\n- aquasecurity/trivy-db#674 updates SUSE ingestion to read raw advisory data (with legacy fallback during transition).

[manojkrishnanomula]

Companion trivy-db PR is ready and linked here:

• feat(suse-cvrf): consume SUSE advisory CSAF feed format trivy-db#674

It updates SUSE ingestion to read vuln-list/csaf/suse/... raw advisory data (with legacy cvrf/suse/... fallback during transition).