Should we use yum update during image build to keep image lib up to date and protect from CVE?

[SamYuan1990]

take ubi 9.2 and 9.3 as an example,
for ubi 9.2 the curl package has a CVE which listed at https://catalog.redhat.com/software/containers/ubi9/618326f8c0d15aff4912fe0b?architecture=amd64&image=652fc5bc9252cb8029f46161
and if we start a ubi 9.2 image and run a yum update:

[root@e0efe413329c /]# yum update
Updating Subscription Management repositories.
Unable to read consumer identity
Subscription Manager is operating in container mode.

This system is not registered with an entitlement server. You can use subscription-manager to register.

Red Hat Universal Base Image 9 (RPMs) - BaseOS                                              236 kB/s | 515 kB     00:02    
Red Hat Universal Base Image 9 (RPMs) - AppStream                                           1.3 MB/s | 1.8 MB     00:01    
Red Hat Universal Base Image 9 (RPMs) - CodeReady Builder                                                                          58 kB/s | 192 kB     00:03    
Last metadata expiration check: 0:00:01 ago on Wed Apr 17 13:13:15 2024.
Dependencies resolved.
==================================================================================================================================================================
 Package                                           Architecture          Version                                        Repository                           Size
==================================================================================================================================================================
Upgrading:
 alternatives                                      x86_64                1.24-1.el9                                     ubi-9-baseos-rpms                    42 k
 audit-libs                                        x86_64                3.0.7-104.el9                                  ubi-9-baseos-rpms                   120 k
 crypto-policies                                   noarch                20230731-1.git94f0e2c.el9_3.1                  ubi-9-baseos-rpms                    87 k
 crypto-policies-scripts                           noarch                20230731-1.git94f0e2c.el9_3.1                  ubi-9-baseos-rpms                    97 k
 curl-minimal                                      x86_64                7.76.1-26.el9_3.3                              ubi-9-baseos-rpms                   129 k

we can see curl is on the list, and then we try ubi 9.3
as https://catalog.redhat.com/software/containers/ubi9/618326f8c0d15aff4912fe0b?architecture=amd64&image=65e093e60a21b531a96f93ca&container-tabs=security
we see expat-2.5.0-1.el9.x86_64
and I make a try with 9.3 with yum update, and expat is on the list. and we found https://access.redhat.com/errata/RHSA-2024:1530 as expat 3.1 package for fix.

yuanyi@yuanyideMacBook-Pro kepler % docker run -it registry.access.redhat.com/ubi9 /bin/bash    
[root@c90878faf22b /]# yum update
Updating Subscription Management repositories.
Unable to read consumer identity

This system is not registered with an entitlement server. You can use subscription-manager to register.

Red Hat Universal Base Image 9 (RPMs) - BaseOS                                                                                    470 kB/s | 515 kB     00:01    
Red Hat Universal Base Image 9 (RPMs) - AppStream                                                                                 600 kB/s | 1.8 MB     00:03    
Red Hat Universal Base Image 9 (RPMs) - CodeReady Builder                                                                         504 kB/s | 192 kB     00:00    
Dependencies resolved.
==================================================================================================================================================================
 Package                          Architecture                     Version                                      Repository                                   Size
==================================================================================================================================================================
Upgrading:
 expat                            x86_64                           2.5.0-1.el9_3.1                              ubi-9-baseos-rpms                           119 k
 tzdata                           noarch                           2024a-1.el9                                  ubi-9-baseos-rpms                           842 k

Transaction Summary
==================================================================================================================================================================
Upgrade  2 Packages

Total download size: 961 k
Is this ok [y/N]: 

@rootfs , @sthaha, @vprashar2929 , any suggestions?

[SamYuan1990]

so which means, running yum update during container build help us install CVE patches?

[SamYuan1990]

• @vimalk78 in loop

[SamYuan1990]

a temp solution PR as #1361 been opened.

[sthaha]

Some things to notes about about CVE that should be considered are

1. Does it affect us? E.g. does a CVE in curl affect kepler in any
2. Refer to https://access.redhat.com/articles/2208321 - the section on when images are rebuilt and republished

Base RHEL and UBI Images

• Built when a Critical or Important CVE is released: UBI container images are built wholly and completely from RHEL software packages. Critical and Important CVEs affecting software packages in RHEL, which are only a tiny subset of all of the changes released in RHEL, are patched and released as soon as possible, asynchronously from the standard release process, typically within hours or days. If one of these small number of Critical or Important CVEs affect an UBI container image, the image is automatically rebuilt and released, typically within hours or days.
• Built every 6 weeks: The vast majority of features, bug fixes and lower priority CVE fixes in RHEL are developed, built, tested, documented and released on a standardized 6 week release cadence. As a final step in this RHEL release process, all UBI container images are rebuilt and released. This ensures that UBI always has the latest patches available in RHEL.

Given the above, shouldn't pulling the image for every build ensure that most CVEs are fixed? For a high severity CVE,

3. Refer also to UBI - FAQ - updates - https://developers.redhat.com/articles/ubi-faq?extIdCarryOver=true&sc_cid=701f2000001Css5AAC#container_certification:~:text=Support%2C%20lifecycle%2C%20and%20updating

29. Will UBI receive updates?
    Yes, the Red Hat Universal Base Image content will follow the Red Hat Enterprise Linux schedule. Every time there is a new release of Red Hat Enterprise Linux, new Red Hat Universal Base Images and supporting packages will be released as a new version number. Building on UBI is a safe choice because you will receive updates for the lifecycle of the underlying Red Hat Enterprise Linux content.

New container images will be built and governed by the Red Hat Image Updates Policy. This includes image rebuilds for Critical and Important CVEs during releases. Also, a YUM repository will be provided with the latest set of RPMs for any given release. This will allow users to update container images during rebuilds, ensuring the latest errata (security, bug fixes, enhancements) is picked up and applied.

At release, only the latest version of each RPM will be provided in the publicly available YUM repositories.

Problem with yum upgrade

Packages are constantly updated in a repo so a running a yum upgrade does not guarantee reproducibility and the layer can't be cached. By reproducibility I mean that builds that happen at around the same time produce the same set of artifacts.

Yum upgrade doesn't just install only security patches, it also contains other upgrades - glibc for instance which kepler links against. Will an update to glibc break kepler?
So for the same commit on kepler repo, 2 builds made at roughly the same time can give us different builds if there is an update to the repo.

How about installing only security patches during build -

RUN yum -y update-minimal --security --sec-severity=Important --sec-severity=Critical && yum clean all

[SamYuan1990]

I suppose

RUN yum -y update-minimal --security --sec-severity=Important --sec-severity=Critical && yum clean all

is better for us, for example, today's curl is not a big deal for us, because kepler seems don't invoke curl directly, but I don't want to take a risk if next some_lib becomes big deal for us.