Любопытная статья "Compromising Read-Only Containers with Fileless Malware", где авторы показываются, что это не останавливает злоумышленников с Fileless Malware.

Делая файловую систему невозможной для изменения, злоумышленник не может записать исполняемый файл своего вредоносного ПО на диск. Большинство атак основаны на записи файлов, но атакующий может и использовать Fileless Malware как часть своей атаки.

Для демонстрации было взято следующее окружение:
- Redis как таргет
- coreutils как часть образа Redis
- CVE-2022-0543 Redis Lua Sandbox Escape and Remote Code Execution - выполнение любых команд через eval()
- spec:containers:securityContext:readOnlyRootFilesystem:true
- Отсутствие других механизмов безопасности

Для запуска вредоносного кода используется:
- /dev/shm (более известна как tmpfs) - для создания файлов в контейнере с read-only filesystem
- Утилита mktemp из GNU coreutils - для записи в /dev/shm
- DDexec для выполнения Fileless Malware

Моё IMHO - пример хороший, но многое что в нем хорошо подобрано - и тип уязвимости и наличие интерпретатора, и наличие дополнительных утилит в образе и т.д. Ну и само применение Fileless Malware при записи 2-х дополнительных файлов делают атаку не такой уж и fileless ...