Vulnerability insights between deployments

I'll preface this issue by saying this. I have recently (30ish minutes ago) learned about something, and feel it could be applied here. There's a strong possibility it cannot, and would be more than happy to forget about it and move on.

---

rpm-ostree provides a nice security overview of vulnerabilities fixed between the current and staged deployment, which would be very handy to have here. I know bootc doesn't have (or is trying to remove?) the tight integration with the package manager, so doing this through rpm-ostree could be problematic, and need rework in the near future.

This gets me to the thing I have recently found out about - the referrers API, and attaching artifacts to OCI images ([video](https://youtu.be/_c1OdmP9Ssg)).

In this wild idea, bootc could query the OCI registry for SBOMs of the current image and staged image. From these two SBOMs, it might be trivial to work out the diff and be able to say which packages or binaries have resolved vulnerabilities.

All logic to scan the image and detect vulnerabilities would be offboarded to specialised tooling as part of the CI process, such as syft, and bootc would need to make a couple queries to a registry and learn how to ingest and compare data from an SBOM.

1. Bootc stages a new deployment
2. Bootc queries the registry for an image artifact of mediaType [`application/spdx+json`](https://www.iana.org/assignments/media-types/application/spdx+json), ingesting the data
3. Bootc compares the SBOM data from the current and staged deployments, informing the user as part of `bootc status` or `bootc update`

Please let me know if this is not possible, or if there are better ways to approach the problem.

Thanks,
Rob

Beginne damit zu prüfen, wie bootc das Deployment-Staging und die Ausgabe von `bootc status` oder `bootc update` handhabt, und untersuche anschließend die Registry Referrers API und die im Issue beschriebenen SPDX-SBOM-Daten. Vergleiche SBOMs für aktuelle und bereitgestellte Images und definiere, wie behobene Schwachstellen gemeldet werden sollen; das Issue ist abgeschlossen, sobald die Machbarkeit und der Implementierungsumfang feststehen.

Vom Indexierungsmodell aus dem Issue-Text verfasst.