Yeah. I'm tempted to say "why not both" but I know I would definitely forget to check one.

Keeping s/w updated would also have prevented this attack. I wonder if the author could use Renovate or something similar.

(And yeah, there should have been a firewall so the umami container wasn't exposed externally)

Containerisation for the win! The only real fallout from the attack was increased CPU usage and an annoyed host from the scanning. The host server wasn't compromised.

The hack was the recent React2Shell vuln. But the author wasn't aware they were even running NextJS. This is a critical point and one of the reasons for the push towards SBOMs -- we should be able to immediately review our infrastructure for vulnerable components

react2shell.com

Some of the time you will be adding the cert while adding custom code or binaries, so it may not remove a build. But it's still one less thing to worry about. And there are many cases where the cert was the only customisation (e.g. application images like databases) and those are now taken care of.

Think about it -- previously you had to run a build just to drop the certs in every time a new image was released. Now we do that work for you.

Corollary: buy cables with different colours...

With the rise of LLM generated code, it feels like it's taken on a whole new meaning. Can you really say the code you're committing today is readable by humans? If not, be aware that it represents a lot tech debt that may need to be paid back with interest...

And the Renovate GitHub Action: github.com/renovatebot/...

You can find more about Octo-STS here: github.com/apps/octo-sts