I really don't like these kinds of alarmist reports if they are not actually saying what the problems are and how they can lead to actual, real, serious attacks. A lot of claimed "high CVSS" vulnerabilities aren't when you put them in context, and sometimes vice versa.
Yes, we should strive to be a lot better and maintaining dependencies is one thing that generally everyone in modern development does bad, but this sort of alarmist posts that have no concrete examples generally just lead to people ignoring the whole field/industry. If those images are exploitable in the ways they are intended to be used highlight that. If it's as bad as this post makes it sound then that should be easy.
CVSS is a common and open approach. CVSS scores that are particularly high, are often directly exploitable. If they aren't, then probably their calculation was done wrong. You can try it for yourself here: https://www.first.org/cvss/calculator/3.0
Having said that, what can lead to a serious attack for your organization is often subject to a combination of factors. Say, there is an SSRF vulnerability in your own application, because the HTTP library you use doesn't parse the URL correctly, so now an attacker can let your application perform arbitrary HTTP requests. But fortunately, the connectivity of your application server is quite limited, so that an attacker can't reach internal systems, can't go to the internet, uses strong authentication to web services it does use, all the good stuff. So now the chance of a successful, serious attack is largely diminished.
Also, it can be quite complicated to know what the exact, real dependencies of your application are. What is the transitive/recursive list of dependencies your application uses? Which of your application's dependencies actually use libraries on your system? And what are _their_ dependencies? I think that cost wise, it is cheaper to make sure your application dependencies, containers, host system libraries, container orchestration tools, etc. are always up to date.
And yeah, I agree that the post doesn't do a good job at all to provide a sane rationale on _why_ you should update. Anyone who has ever administered an operating system knows that security vulnerabilities are found in them every day. But the awareness that a Docker container is subject to the same pace is definitely not present everywhere, and it probably should be.
I'm not sure if that was the idea, but nothing you said refutes what I said. If there is a potential SSRF due to one of those vulnerabilities show that, if there is a potential but unlikely RCE show that.
Just saying that the default node image has 580 vulnerabilities helps no one actually trying to fix these vulnerabilities or assess how to prevent this in the future.
Yes, we should strive to be a lot better and maintaining dependencies is one thing that generally everyone in modern development does bad, but this sort of alarmist posts that have no concrete examples generally just lead to people ignoring the whole field/industry. If those images are exploitable in the ways they are intended to be used highlight that. If it's as bad as this post makes it sound then that should be easy.