Great post! There's a lot of stuff to take in here.
One thing that's applicable to many developers is that it demonstrates some of the risks of storing secret/sensitive configuration in environment variables. Environment variables are inherited by child processes, and a malicious child process can run env or look in /proc/[PID]/environ to see them.
It's fine for dev, but shouldn't be done in prod. On a Linux system, systemd has some abstractions to properly deal with secrets (https://systemd.io/CREDENTIALS/ ). Most importantly, the secrets aren't visible to any other process (using mount namespacing), nor are they automatically passed to child processes. Access control is implemented in the kernel itself, and encryption can be handled a bunch of ways - using a key on a TPM chip, on disk, passed in via SMBIOS OEM strings, via a Cloud Instance Metadata Services (IMDS), etc.
Of course, there's other solutions for secret management too.
More broadly, I think attacks like this demonstrate the need for stronger sandboxing and process isolation, maybe potentially at the CPU level? x86 virtualization isn't as isolated as people would like to believe.
