Levar a segurança para a esquerda exige cultura, não apenas ferramentas

Esta é a segunda parte de uma série de quatro artigos sobre como criar uma estratégia de AppSec para Kubernetes. A primeira parte está aqui.

À medida que as organizações adotam práticas de DevOps e transformam a maneira como desenvolvem e mantêm aplicações, muitos aspectos do desenvolvimento de software estão mudando.

Em muitas organizações, a administração tradicional de sistemas mudou com a adoção da engenharia de confiabilidade de sites (SRE) e da filosofia “você cria, você opera”. As redes são cada vez mais descritas em software, especialmente com a ascensão do service mesh. As conversas sobre monitoramento estão deixando de buscar soluções para incógnitas conhecidas e passando a priorizar a observabilidade e as incógnitas desconhecidas. O padrão é claro: cada vez mais aspectos da operação de aplicações estão passando para as mãos dos desenvolvedores. No caso da segurança, essa mudança está apenas começando. Para que ela aconteça de forma eficaz, precisamos escolher as ferramentas com cuidado e construir uma cultura de propósito.

Contêineres como unidade de software

Vamos usar os contêineres para explorar os temas de ferramentas e cultura. Como mencionamos no artigo anterior, os contêineres estão se tornando a unidade padrão de software. Criamos imagens, conversamos sobre elas entre diferentes áreas da organização, fazemos afirmações sobre elas e, em geral, as usamos para abstrair detalhes de empacotamento específicos de plataformas ou linguagens.

A ideia de um formato único de pacote, de um repositório de pacotes e de um mecanismo para instalá-los em produção não é nova. Os pacotes e repositórios RPM e ferramentas como o Yum, por exemplo, podem ser considerados parte desse modelo. Mas, no caso dos contêineres, há duas diferenças importantes — mais organizacionais do que técnicas:

1. O uso de pacotes de sistemas operacionais costumava ser responsabilidade de uma equipe separada, dentro da área mais ampla de operações.

2. Poucas organizações usam apenas um formato de empacotamento. Cada sistema operacional ou linguagem de programação tem sua própria cadeia de ferramentas para empacotamento.

A novidade das imagens de contêiner é que a responsabilidade pelo empacotamento está passando invariavelmente para os desenvolvedores e as equipes de desenvolvimento. Por isso, há mais de 2 milhões de arquivos Dockerfile públicos no GitHub, por exemplo. Ferramentas de teste e segurança criadas para uma geração anterior de empacotamento e para antigas práticas organizacionais não se encaixam bem nos fluxos de trabalho e nas cadeias de ferramentas atuais dos desenvolvedores. Um exemplo disso é que a aplicação de patches está deixando de ser uma alteração direta em produção e passando a envolver a reconstrução e a reimplantação de artefatos imutáveis.

Quer saber mais sobre o gerenciamento de vulnerabilidades em contêineres? Saiba mais sobre como a Snyk pode ajudar a proteger seus contêineres.

Ferramentas centradas no desenvolvedor

A padronização das imagens abre muitas oportunidades para criarmos ferramentas realmente centradas no desenvolvedor, que acompanhem essa mudança. Quais são algumas das características dessa nova geração de ferramentas?

• Funcionam localmente — a maioria dos desenvolvedores escreve e lê código em suas próprias máquinas, e ferramentas que funcionam localmente ajudam a entender um novo domínio.

• Integradas aos IDEs — como os desenvolvedores usam ambientes de desenvolvimento integrados, as ferramentas que utilizam também devem ser integradas a eles.

• Interagem diretamente com sistemas de controle de versão — os sistemas de gerenciamento de controle de versão, cada vez mais baseados no Git, dominam o trabalho diário dos desenvolvedores. As ferramentas para desenvolvedores precisam fazer parte da equipe, especialmente à medida que mais pessoas adotam abordagens como GitOps.

• Podem ser configuradas em pipelines de CI/CD — a integração contínua é um pré-requisito para a entrega eficaz de software e o lugar ideal para integrar controles de qualidade, enquanto o ciclo de feedback dos desenvolvedores ainda é curto.

Uma das vantagens das ferramentas que abrangem todo o ciclo de vida de desenvolvimento de software (SDLC) é ajudar os desenvolvedores a entender melhor a aplicação e evitar o temido “funciona na minha máquina”.

Uma cultura DevOps de colaboração

Qualidade e segurança não são responsabilidade exclusiva dos desenvolvedores; profissionais de operações e especialistas em segurança continuam sendo essenciais para o sucesso. Especialistas são necessários para orientar e capacitar as equipes sobre como levar a segurança para a esquerda à medida que mais responsabilidades passam para as equipes de desenvolvimento. Assim como as equipes de engenharia de confiabilidade de sites (SRE) apoiam os desenvolvedores para que operem melhor suas aplicações, a segurança precisa adotar a mesma abordagem.

Ferramentas que facilitam a colaboração entre diferentes áreas, muitas vezes separadas por barreiras organizacionais, são indispensáveis, não apenas desejáveis. As alternativas — áreas separadas com ferramentas próprias que competem entre si ou uma equipe que tenha uma experiência de segunda categoria — não são suficientes. Se as equipes de operações usam um conjunto de ferramentas e as de desenvolvimento usam outro, o resultado são silos organizacionais. Isso não significa que deva existir uma única ferramenta para tudo. As ferramentas modernas para desenvolvedores se concentram na aplicação e no feedback ao longo do processo de desenvolvimento. Elas devem se integrar bem às ferramentas de operações, capazes de realizar investigações detalhadas e gerar relatórios ao longo do tempo, além de trabalhar com as abstrações usadas por diferentes funções.

Conclusão

As conversas sobre “levar para a esquerda” costumam tratar da transferência de responsabilidades das funções tradicionais de TI para as equipes de desenvolvimento, com o objetivo de acelerar o ciclo de feedback. Mas mudar fundamentalmente a forma como trabalhamos sem também mudar as ferramentas raramente funciona. O desenvolvimento de software complexo é, por si só, um sistema sociotécnico complexo. Ao envolvermos os desenvolvedores mais profundamente na responsabilidade pelos desafios de segurança, também precisamos reconhecer que as ferramentas de que eles precisam serão diferentes das ferramentas da geração anterior, voltadas para operações.