Vulnerability insights between deployments

[p5]

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).

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, 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

[cgwalters]

The feature request makes sense, but an emphasis for bootc is on wider scale deployments though we support standalone systems of course too. For wider scale, these types of "diffs" I think are something you want to see in your CI pipeline, not (necessarily) on the client.

Also xref #932

We've definitely gotten a related request for package-level diffs (which I think would need to live in a dnf bootc plugin or so).

Bigger picture though, has anyone written such SBOM-comparison tooling? It's not a problem domain specific to bootc at all.

[p5]

Thanks for the comments!

I guess this could depend on how bootc should be managed in these larger deployments.

A problem I have faced with managing bootc (at a much smaller scale compared to IoT - i.e. with 50 nodes) is a lack of current tooling. I'm sure RedHat will have some sort of integrations with Lighthouse which keep track of the image versions that are deployed to a fleet, though when this is not in place, it's difficult to know which servers are running which image versions, and therefore knowing the vulnerabilities on the servers is difficult. There may be servers being held back for one reason or another (networking issues, greenboot etc).

I could see this being useful client-side both for the desktop scenario, and for when you're home-rolling a fleet monitoring solution or something like Cockpit. Bootc could expose this data through the proposed RPC API, and the management service agent ships that off to the centralised management server.

But then again, if the API provides the image version information, this diff'ing could be done by the centralised server.

---

We've definitely gotten a related request for package-level diffs (which I think would need to live in a dnf bootc plugin or so).

It may not be the most effective solution, but this could be handled by SBOMs too. SBOMs list all packages (RPM, APT, APK or binaries), so a comparison of these would yield both package diffs and security diffs. This would also have the added benefit of being distro (or package-manager) agnostic.

Bigger picture though, has anyone written such SBOM-comparison tooling? It's not a problem domain specific to bootc at all.

There are tools that do so. While it's not a format I've used, I can see CycloneDX (a well-known SBOM format) provides their own CLI containing a diff command.