You would think you’d already have problems if someone’s managed to compromise one or more of your containers without you knowing though whether they can get the host or not

True, but the security idea behind being in a containerised environment is that your problems aren't immediately made worse by the fact that your database server is on the same machine as your web application - since they'd both be on separate but networked containers.

What if anything do people do about anti virus in containers?

The real threat to containers isn't AV-detectable malware, but Remote Code Execution (RCE) exploits.

Containers are best used as single purpose installations. With that configuration, it isn't easy to get non-standard executables - including malware - onto a container.

Most RCE exploits also don't involve the dropping of malware files onto the file system. There are some that do, but that issue is better handled in other ways.

Why? Well AVs only do something about binaries they know or think to be malware. A well crafted, customised Cobalt Strike beacon (aka: malicious remote control software) will blow through any resistance an AV has to offer.

So what do we do? Remember what I said that containers are best used as single purpose installations? Therefore you know exactly what executables should be running, making it trivial to set up executable whitelisting. That means that any executable not on the list will not run.

But even that isn't completely bulletproof. It won't do much against web shells, in which case your best detection mechanism is to look for applications calling /bin/bash or /bin/sh that shouldn't be.

Docker can be run in rootless mode[1]. Ideally that should be the standard mode unless you have specific requirements not satisfied by rootless mode.

[1] https://docs.docker.com/engine/security/rootless/

Even worse than that, they need to be able to make an arbitrary container from an arbitrary attacker-provided Dockerfile, or make fairly arbitrary calls to the Docker daemon (in which case you've already lost).

They're rather uninteresting for anyone self-hosting containers as the runc vuln doesn't offer a way to escape from within an already running container, while the BuildKit vulns all have fairly odd preconditions or require passing untrusted input. Quite the annoyance if you're running some kind of public cloud or public CI/CD service, though.