Monitor CVE reports as provided by KF/manifest team

[tarilabs]

With KF 1.9, the Platform (KF/Manifest) team is introducing CVE reporting.
ref: https://blog.kubeflow.org/kubeflow-1.9-release/#cve-scanning

Since kubeflow/manifests#2860 it is possible to access the reports for the whole KF platform by accessing the zip archive in any of the run from: https://github.com/kubeflow/manifests/actions/workflows/trivy.yaml

With kubeflow/manifests#2856 we avoid a double-counting in the final report for image which are shared across WGs/Components (ie: we share Mysql and gcr.io/tfx-oss-public/ml_metadata_store_server)

Baseline

From the KF 1.9 release, this numbers where reported:

September 2nd

Source images

Scanning  kubeflow/model-registry:latest
+----------+------+--------+-----+
| Critical | High | Medium | Low |
+----------+------+--------+-----+
|    0     |  0   |   11   |  68 |
+----------+------+--------+-----+

Shared images

Scanning  gcr.io/tfx-oss-public/ml_metadata_store_server:1.14.0
+----------+------+--------+-----+
| Critical | High | Medium | Low |
+----------+------+--------+-----+
|    0     |  0   |   35   |  41 |
+----------+------+--------+-----+

Scanning  mysql:8.0.3
+----------+------+--------+-----+
| Critical | High | Medium | Low |
+----------+------+--------+-----+
|    17    |  71  |   55   |  42 |
+----------+------+--------+-----+

[tarilabs]

It looks to me to get better numbers we need to have coordination with KFP WG for which we copy the MLMD setup.

I notice mysql:8.0.39 as also suggested in #267 would improve some of this numbers, although same considerations as above, since it seems to be also failing the bare minimal K8s test we have on this repo.

[tarilabs]

On suggestion received during the MR biweekly meeting 2024-09-16, I've raised the question about the shared DB image in the Discussion forum for the KFP WG: kubeflow/pipelines#11224