The RHEL AppStream Life Cycle is complex, and this is also reflected in the life cycle of first-party containers in the Ecosystem Catalog.  This means it is easy for a customer to deploy an official container image that soon becomes deprecated and no longer receives functional or security updates via `podman auto-update` (or similar).  This may silently lead to a running an insecure version of containerized software, even though packages on the host are up-to-date.

As a concrete example, the ubi8/nginx-120 container image was marked as "deprecated" in the ecosystem catalog in November 2023, when the underlying AppStream for Nginx 1.20 reached the end of life. (https://catalog.redhat.com/software/containers/ubi8/nginx-120/6156abfac739c0a4123a86fd)  No mechanism currently flags that running ubi8/nginx-120 containers are deprecated and no longer receiving updates; simply no updates appear in the upstream repository.

Ideally this would also flag on running containers that are FROM (layered upon) known-deprecated images, as client-local images often apply limited customization on top of upstream ubi/rhel images and would also be silently vulnerable.

This WIP presentation from Brian Smith discusses how pervasive this problem is, primarily in the context of Image Builder: https://docs.google.com/presentation/d/1RrVwNnkROR4GIcRkww1ArrAVfgCRzcxG-mpfW_O8_I8/edit  In the sample set, over 70% of (non-containerized) deployments of nginx and NodeJS on RHEL 8 are running from deprecated AppStreams.