The answer to that is "something that is not Docker handles it". Wherever you're hosting your images there'll be something platform-specific that handles it. Azure, AWS, and GCP all have tools that'll scan and raise a notification. If you want that to trigger an automatic rebuild, the tools are there to do it. Going from there to "I don't need to think about any CVE ever" is a bit more of a policy and opinion question.
I hadn't even thought I would be "hosting my images" on something like Azure, aWS, or GCP to deploy to fly.io. Their examples don't mention that. You just have a Dockerfile in your repo, you deploy to fly.io.
But it sounds like for patch/update management purposes, now I need to add something like that in? Another platform/host to maintain/manage, at possibly additional price, and then we add dealing with the specific mechanisms for scanning/updating too...
Bah. It remains mystifying to me that the current PaaS docker-based "best practices" involve _quite a bit_ more management than heroku. I pay for a PaaS hoping to not do this management! It seems odd to me that the market does not any longer seem to be about providing this service.
You can run something like trivy locally, which will do that particular job. Fly.io might add that later.
It is odd, but the general direction of the market (at least at the top) is becoming less opinionated, which means you need to bring your own. Not sure I like that myself.
