Repository navigation
Detect package updates and rebuild images #1455
Description
When updates are made available in a dependent package that is installed by one of the .NET Core Dockerfiles, this update should be detected and the image rebuilt and published to provide consumers with the latest version of the package. There is currently a system for detecting changes to base images and rebuilding dependent images so, in theory, this would be an extension of that to include the detection of package updates.
Activity
MichaelSimons commentedon Nov 20, 2019
Recently there was an instance in which
curlhad a security vulnerability which is included in the .NET images. The ARM32 images didn't pick this up because the base image never changed. Vulnerability scanning caught this and a build was manually triggered to get the patched curl version that addressed the vulnerability.Rebuilding any time that any of the packages that are included in the .NET images may cause a lot of churn. We may want to consider batching these to reduce churn if they are not addressing vulnerabilities.
richlander commentedon Nov 21, 2019
This makes good sense, but is more complicated than the base image updates.
NasAmin commentedon Apr 22, 2020
Can something like Trivy be used?
https://github.com/aquasecurity/trivy
mthalman commentedon Nov 30, 2020
Another example where this would have been useful: #2417. The
krb5package had been updated with a security fix but the parent Alpine image never changed. This meant we never automatically triggered a build to rebuild the image.mthalman commentedon Nov 8, 2021
As stated in dotnet/docker-tools#824 (comment), the plan is stored the package graph as metadata in the image info file. In addition to actually storing this metadata, we should also provide notifications whenever the package graph changes for a given Dockerfile (see #3271 (comment)). This allows us to be aware of any unexpected changes.
mthalman commentedon Mar 14, 2022
Now that the infrastructure supports the generation of SBOMs, it seems more appropriate to consume the SBOM's description of the packages that are installed in an image rather than duplicating that information in the image info file. This would clean up code and provide a single source of truth.
mthalman commentedon May 3, 2022
With CBL-Mariner 2.0, there are no longer the necessary commands to execute the scripts to get the set of installed packages in a Mariner 2.0 container because the
sedandcolumncommands aren't available. Installing them isn't a straightforward option because that would then impact the results of which packages are installed.As a result, package gathering for Mariner 2.0 will not be done via these scripts. It's not worth the investment considering it makes more sense to use SBOMs as the source of packages instead.
By using SBOMs, we'll have a centralized, cross-platform method of retrieving package information that isn't reliant on execution within the container itself.
mthalman commentedon Aug 18, 2022
This will need to account for the newly added Chiseled Ubuntu Dockerfiles. Those are unique in that they are based on
scratchand use the chisel tool to install the packages. So whatever logic is used to determine the source of the packages to compare against needs to account for this scenario.