Ram would be a really hard component to supply chain attack. It doesn’t store anything when powered off, so you’d need another chip on the board that can store your attack and that’d stick out like a sore thumb.

It also requires incredibly low latency, so low that trace lengths need to be optimized in order to deliver data accurately. So stream manipulation is out the window.

You’re left with searching through the contents looking for something juicy and that requires some kind of extra sore thumb chip that can’t go fast because it doesn’t have a heatsink.

Plus it’s been standard practice to harden the memory of libraries and programs and even operating systems to avoid stuff like the old Intel hyper threading attacks for at least fifteen years now, so there’s a reduced attack surface.

No one’s supply chain attacking your ram.

Hang on, I’m gonna add a suspicious new component onto a part that is incredibly expensive and heavily scrutinized specifically for speed and latency that will bit bash the I/o.

You add a piece of code (to ram, which famously does not hold information while unpowered).

Which scans for a specific very big prime number (finding large primes quickly would completely invalidate the world’s cryptography and therefore banking, that’s why people are afraid of the quantum boogeyman).

You look for any process and inject into stdlibc any backdoor of your choice (just any process, doesn’t need elevated permissions, assuming they use libc, assuming the backdoor hasn’t been patched out from the other end, defeated by any of the dozens of software integrity checks that have become standard).