Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Just say no to :latest

platformers.dev

Post reply on HN
Print view View original

71–80 of 135 posts

Re: Just say no to :latest

#71

Post by zufallsheld »

keymone wrote: post #5
delusional wrote: post #4

Earlier quoted context omitted.

From the original article > This brings up an interesting side point, in that Docker Hub and most other registries allow mutable tags by default. So nginx:1.21.6 might not be the same image today as it was yesterday. In reality, you probably need a mechanism to enforce tag immutability: e.g., your own registry mirror, or referring to images by SHA)

yeah, well, i stopped reading when i saw that "GOOD" example. it's not. and that isn't a "side point", that's the most critical point for preserving security and reproducibility of builds.

Well then you'd vendor your docker images anyway and not pull them from the internet, right?

Re: Just say no to :latest

#72

Post by bearjaws »

The security questionaires we have to perform for our larger customers now include that we pin the exact hash of a container or mirror any image locally. This is in addition to pinning versions of NPM packages and using our package lock for installation.

We now have a basic rule that :latest doesn't make it past proof of concept stage.

This has made automation of our package & container maintenance crucial, since we are a lean shop. It's pretty much a weekly occurrence that a low-medium vulnerability pops up somewhere once your application is large enough.

Re: Just say no to :latest

#73

Post by yardstick »

oxfordmale wrote: post #63
laumars wrote: post #23

Earlier quoted context omitted.

> Ideally you only use Docker official images,or their equivalent to avoid using unvetted code. Docker images don’t ship every dependency in the average development project. They’re also not a security guarantee either. > It is always a trade off, however it is far more likely that a hacker will use a ten year old well exploited CVE, rather than a recent one In general that’s the case but in practice that’s still the…

I have seen many cases where a something is pinned to a minor version, and then gets forgotten about for 2 or 3 years. In my current companies there is Production codebase that hasn't been touched for over two years. The original developers have long since moved on and no one really owns the code. That is the most common scenario leading to security breaches. This is about succession planning, with the realisation th…

In that case, better the devil you know? But either way if you don’t have a vulnerability management plan you are at risk.

Re: Just say no to :latest

#74

Post by crucialfelix »

Agree. I think it's better to explicitly update major versions and know to keep an eye on the deployment in case it's something that tests can't cover.

I had a CloudBuild fail to deploy due to a bug in one of the builders :latest. Ironically the bug was due to a change in error logging, so it failed silently.

So it's not just docker or dependencies.

In this case I could've used a GCP notify that the builder failed.

Re: Just say no to :latest

#75

Post by synergy20 »

I agree. Or provide something in parallel such as:

    :lts      -- newest long term stable release
    :release  -- newest regular stable release
    :x.y.z   --  supported but you need find out the exact version each time!

Re: Just say no to :latest

#76

Post by cube00 »

pojzon wrote: post #70
oxfordmale wrote: post #9

This is always a balance. The moment you pin to a specific version you need to have a process in place to ensure you regularly upgrade to avoid introducing vulnerabilities in your production system. Throughout my career I have seen many cases where certain software still runs on ancient versions as the team originally maintaining it is no longer around (e.g. reorganisations or lay-offs). It is always hard to convince…

Its hard to convince management that them adapting devops means they actually have to follow devops principles. Too many times Ive seen companies throwing this buzzword around without understanding how much work is actually required to have real devops.

:s/devops/agile/g

Re: Just say no to :latest

#77

Post by cedws »

Pinning image tags is only useful if the upstream doesn't keep retagging images. I've had a case in the past where a vendor has retagged an image and broken something.

Maybe we should even be pinning to a specific layer/checksum like so:

  FROM ubuntu@sha256:8ae9bafbb64f63a50caab98fd3a5e37b3eb837a3e0780b78e5218e63193961f9

Re: Just say no to :latest

#78

Post by addingnumbers »

cedws wrote: post #77

Pinning image tags is only useful if the upstream doesn't keep retagging images. I've had a case in the past where a vendor has retagged an image and broken something. Maybe we should even be pinning to a specific layer/checksum like so: FROM ubuntu@sha256:8ae9bafbb64f63a50caab98fd3a5e37b3eb837a3e0780b78e5218e63193961f9

The article covered that five paragraphs in:

> In reality, you probably need a mechanism to enforce tag immutability: e.g., your own registry mirror, or referring to images by SHA).

Re: Just say no to :latest

#79

Post by ipsocannibal »

I think this is an X/Y problem. The problem isn't pinning to latest. The problem is lack of automation that makes builds reproducable. In at least one FANG company I've worked for if you aren't building from latest no one will listen to your issue. Too much software changes to quickly to be pinning to specific versions. However, the build system keeps track of the build audit details and can rollback any build to any state. Teams are required to add the necessary layers of unit, integration, stress, crush, and chaos testing to validate each build. Its not cheap but when you need to do a monthly firedrill of 'emergency update this dep because of Z vulnerability' its worth it.
Post reply on HN