Eu suporia que as práticas recomendadas de segurança para o HHVM são semelhantes ou idênticas às do PHP. Na minha experiência, o HHVM se comporta basicamente como o PHP, exceto que ele tende a impor restrições mais rigorosas aos tipos de variáveis.
Para ser minucioso:
- Endureça o ambiente. O software do servidor é claro: link
- Quando aplicável, distribua serviços entre servidores. Bancos de dados em um servidor, Memcache em outro, etc. Para manter o sistema o mais seguro possível: isolar pontos de falha.
- Conceda a quantia mínima de privilégios necessários para qualquer item no seu servidor web. No mínimo, o proprietário dos arquivos pertencentes a um servidor da Web nunca deve ser o root, e as pastas graváveis devem ser mantidas fora da raiz da web. Isso, para limitar o impacto do escalonamento de privilégios e para reduzir o risco de upload e injeção de código.
- Isso é discutível, eles são ativados por padrão, mas muitos hosts da web usam php.ini para desativar funções como exec ou proc_open. Em um ambiente compartilhado, eles fornecem um shell para qualquer desenvolvedor PHP, basicamente. Em um vps, eles podem conceder um shell para os usuários externos. A escalação de privilégios não está longe.
- O restante e os itens específicos do php.ini, são discutidos em detalhes suficientes neste artigo: link
Outras considerações incluem tolerância geral a falhas e consumo de memória, usam software enxuto (preferem o Nginx e seu baixo consumo de memória, por exemplo), para moderar o risco de negação de serviço e possíveis arquivos de depuração ou de tempo de compilação. Eq. você não quer que apenas alguém leia os core dumps sempre que um componente falhar (incluindo o HHVM), e o HHVM produz arquivos .hhvm.hhbc - arquivos de bytecode armazenados em cache. Que você também queira ocultar, preservar e talvez manipular de alguma maneira.
Mais detalhes (de 2012) estão disponíveis aqui: link
Alguns ainda podem ser aplicados.