You are not logged in.
Pages: 1
Yeah, this hits close to home. We've been running containers in production for a while now, and honestly, the pre-deployment scans give you a false sense of security. A buddy of mine had a similar wake-up call last year when a dependency they'd been using for months got silently backdoored. No CVE, no warning, just a weird spike in outbound traffic that their monitoring picked up by accident. That's the part nobody talks about – you can scan all you want, but once something's live, you're basically trusting that nothing changed. Runtime visibility is where the real story is, not the static checks. Curious if anyone here has actually caught something in production that their scanners completely missed
I’m a backend developer, not a security person, so I’m pretty lost here. We run a small set of microservices in Docker. Twice now, a container that’s supposedly running our Node app suddenly spikes to 100% CPU. I exec in and find a crypto miner process I definitely didn’t put there. We rebuild the image from scratch (it scans clean in the registry), redeploy, and a week later it’s back sometimes a reverse shell instead. Our host EDR, antivirus, and network monitoring see absolutely nothing because everything happens inside the container. I don’t understand how this keeps happening if our images are clean and we’re not exposing ports we shouldn’t. Is there any kind of tool that can simply block unknown processes from starting inside a running container? Something that says “if this wasn’t in the original image or isn’t explicitly allowed, kill it immediately”? I’m exhausted cleaning up after these and worried one will eventually exfiltrate real data. Any pointers would save my sanity.
Pages: 1