Patch reports belong in the control plane

A patch report answers a customer question

Customers need more than a scanner exit code. They need to know which host was checked, when it was checked, which packages are behind, how serious the finding is, and whether someone has acted on it.

That information belongs beside deployment state because patch age affects the workload the customer is paying to run.

Scan the host and the image

Host package scanning and container image scanning answer different questions. A host report covers the operating system packages on a VM or node. An image report covers the packages that will enter a container when it runs.

The control plane can present both without pretending that one scan proves the other.

Make findings actionable

A useful finding has a stable asset, package, severity, first-seen time, last-seen time, and current remediation state. It can be acknowledged, linked to a reconfigure run, or left open until the package state changes.

This makes patch reporting part of the operating workflow instead of a PDF that is already out of date when it is downloaded.

Choose the signal

A critical finding can trigger a webhook or immediate notification. A routine package report can go by email on a schedule. The same finding remains queryable through the API for a trust-centre or internal dashboard.

Delivery policy changes the signal. It does not change the finding.

Do not confuse reporting with a promise

A report describes observed package state at a scan time. It is not an SLA, a certification, or a claim that every dependency is safe. Customers can see the evidence and decide which remediation path fits their workload.