Segurança de contêineres em todo o SDLC

Os contêineres estão se tornando cada vez mais a unidade padrão de software. A imagem de contêiner, definida tecnicamente na especificação de imagens OCI, é um componente essencial das ferramentas modernas, de Docker e Kubernetes a plataformas como AWS Fargate e Google Cloud Run. O que isso significa para a segurança de aplicações?

Onde usamos imagens de contêiner

Um aspecto interessante das imagens de contêiner é que elas abrangem o ciclo de vida do desenvolvimento de software (SDLC).

• Os desenvolvedores criam imagens localmente, que são uma forma prática de distribuir software com facilidade (às vezes, até facilidade demais).

• As imagens também são criadas como parte dos pipelines de integração e entrega contínuas. É possível anexar metadados sobre a aplicação à imagem para facilitar o gerenciamento de ativos.

• As imagens são enviadas para registros públicos e privados, de onde podem ser compartilhadas para implantação.

• Por fim, as imagens são implantadas em clusters, desde ambientes de desenvolvimento e teste até produção, cada vez mais gerenciados pelo Kubernetes ou por ferramentas semelhantes.

Cada uma dessas etapas oferece uma oportunidade de testar a imagem em busca de vulnerabilidades de segurança. Mas qual é o melhor momento para fazer isso?

Onde testar nossas imagens?

Quando se trata de proteger nossas imagens de contêiner, é fácil pensar que precisamos testá-las em apenas um ponto do SDLC. Por exemplo, se só houver imagens seguras no seu registro, você estará protegido, certo? A realidade é mais complexa e, em geral, envolve concessões.

Quanto mais perto da produção você fizer os testes, mais confiança terá de que entende os riscos das aplicações em execução. A menos que você seja um fornecedor de software que cria ferramentas para outras pessoas, provavelmente seu principal interesse é proteger as aplicações que estão em produção agora. Testar no fim do ciclo também é útil quando uma nova vulnerabilidade é divulgada em uma dependência que você usa. Assim, você avalia rapidamente quais aplicações em produção foram afetadas e age com a urgência adequada.

No entanto, testar somente no fim do SSDLC provavelmente significa ciclos lentos de feedback para os desenvolvedores. O desenvolvedor que decidiu usar ou modificar uma imagem continuou a desenvolver com base nela e já passou para outras tarefas. Por isso, fazer as mudanças necessárias para corrigir a falha de segurança acaba sendo mais difícil e caro. Vale lembrar: o objetivo não é apenas saber quais vulnerabilidades você pode ter (o que é importante), mas corrigi-las. Os testes locais oferecem o ciclo de feedback mais rápido, mas dependem de cada desenvolvedor se lembrar de fazer uma análise sempre, o que dificilmente é abrangente ou realista.

Antes de concluir que o pipeline é, portanto, o melhor lugar para testar, vale considerar também o custo de implementação. Talvez você tenha um ou dois registros de contêiner centralizados, que permitem avaliar todas as imagens criadas, mas provavelmente terá muito mais pipelines de integração contínua. Dependendo do seu nível de automação e de quem é responsável pelas diferentes ferramentas na sua organização, pode ser mais prático começar por um lugar ou por outro.

Também vale observar que temos níveis diferentes de contexto em cada etapa do SDLC. Testar localmente ou na CI provavelmente significa ter acesso tanto ao código-fonte quanto às informações de controle de versão. Isso pode facilitar a detecção de certos tipos de problema, como os causados pelo compilador usado ou por commits não assinados de um agente mal-intencionado. Também ajuda a entender como uma biblioteca foi introduzida. Já os testes em produção mostram exatamente quais imagens estão em uso e onde, além de como estão configuradas, o que pode ajudar a priorizar os problemas encontrados.

Conclusão

Na prática, testar em um único lugar pode atender às necessidades de uma função específica — seja desenvolvimento, operações ou segurança —, mas provavelmente não vai atender por completo ao objetivo geral do negócio: encontrar e corrigir vulnerabilidades o mais rápido possível. Veja um resumo:

Testes de vulnerabilidade em diferentes etapas do SDLC

A opção por onde começar depende das particularidades da sua organização. Mas o ideal é testar a fundo as aplicações baseadas em contêineres em todo o SDLC. Confiar em um único controle é uma abordagem simplista e provavelmente vai gerar atritos entre as equipes de desenvolvimento, operações e segurança, ou atrasar a implantação das aplicações.