Thanks for the shout out XQ! And thanks for bringing this up.
Moving to a Distroless base for Go SDK images should reduce the
vulnerability surface to whichever version of glibc we have packaged in .
I do have some concerns around if a user would like to extend the image
(not having shells or pac
Hi,
Thanks for the tips. After talking with my team, I also realized that our
Dockerfile might not even be the same one used in your repository.
Best,
8
On Wed, Jan 24, 2024 at 12:58 PM 'XQ Hu' via Engineering <
e...@tokentransit.com> wrote:
> FYI. The ongoing PR: https://github.com/apache/beam
FYI. The ongoing PR: https://github.com/apache/beam/pull/30011 will
switch to the distroless images, which will have less vulnerabilities in
the future.
On Wed, Jan 24, 2024 at 12:32 PM Valentyn Tymofieiev
wrote:
> > Does the beam project generally attempt to address as many of these
> vulnerabi
> Does the beam project generally attempt to address as many of these
vulnerabilities?
Beam does not retroactively patch released container images, but we use the
latest available docker base images during each Beam release. Many
vulnerabilities concern software packages preinstalled in the Docker
Hi team,
We recently starting using the Google Artifact Registry's container
scanning, and have been able to fix almost all critical vulnerabilities
across our codebase. The one exception is the docker container created when
we deploy our dataflow beam jobs.
The "critical" vulnerability reported
