Reduce the amount of vulnerability fields stored in the vulnerabilities report

[chen-keinan]

in some clusters the vulnerability report produce by 'trivy-operator' is hitting the max request limit of etcd

it is suggested to reduce the amount of fields stored for each vulnerability , that same data already exist in AVD so the data will not be lost.

example of fields that can be removed: title , fixed version and etc

Vulnerability data with fields :

{"vulnerabilityID":"CVE-2022-1304","resource":"libcom","installedVersion":"1.43.4-2+deb9u1","fixedVersion":"","severity":"HIGH","title":"e2fsprogs: out-of-bounds read/write via crafted filesystem","primaryLink":"https://avd.aquasec.com/nvd/cve-2022-1304","links":[],"score":5.8,"target":""}

Vulnerability data without fields :

{"vulnerabilityID":"CVE-2022-1304","resource":"libcom","installedVersion":"1.43.4-2+deb9u1","severity":"HIGH","primaryLink":"https://avd.aquasec.com/nvd/cve-2022-1304\"}

The removed fields can be found in AVD for this CVE-2022-1304 so no data get lost

[Orrimp]

We also have this problem "error":"etcdserver: request is too large". The Scan Jobs and Pods remain, and therefore no new Scan Jobs can start.

[aarz-snl]

seeing this same problem

[Starttoaster]

It would be excellent if all of the current fields could stay in PolicyReports if it's planned to support those. The data being in the report makes it easier to develop alternative viewing tools that consume the in-cluster reports. In particular I would like to keep the "fixed version" field, though, if not both.

[cthtrifork]

Is there a solution proposal?

1. We could update the builder.go file to do some clever reflection of allowedFields before submitting the report
2. We could clone vulnerability_types.go and create a similar set of structs with less fields. This would have a lot of impact on the codebase, as we would need to use interfaces or possible pass around func() some more. I am not sure how tokeep the codebase pretty.
3. ???