As práticas de desenvolvimento e de arquitetura em nuvem vêm se aperfeiçoando a cada dia. Novos serviços surgem o tempo todo, assim como novas soluções, produtos e formas mais rápidas de se realizar trabalhos.

Exemplo disso é o grande uso de métodos ágeis para desenvolvimento de software, que já há anos vêm sendo usados e aperfeiçoados. Nosso mundo é muito mais dinâmico do que cinco anos atrás.

Hoje, os consumidores querem novas funcionalidades, querem melhorias nos produtos que utilizam e querem novidades surgindo constantemente. As empresas sabem disso e trabalham muito para que isso ocorra. Mas quem tem ou apoia uma equipe de desenvolvimento sabe que essa área é cheia de desafios diários, assim como também é difícil encontrar programadores, profissionais de UX, arquitetos e especialistas em segurança.

E o desafio da segurança da informação é um dos protagonistas. A cibersegurança antigamente era responsável pelas implantações de projetos de segurança e ponto. O time de segurança estava acostumado a implantar seus produtos, como IPS, NGFW, Sandbox, EDR, WAF e assim por diante. Esses projetos serviam para proteger dados e aplicações, mas eram mais estáticos, não sofriam tantas alterações, e muitas vezes protegiam produtos desenvolvidos por terceiros, como um SAP, PeopleSoft, entre outros.

Mas a realidade hoje é diferente e pede integração. Então como o desenvolvedor traz o pessoal de segurança para a etapa de desenvolvimento? Como o profissional de segurança pode participar da etapa inicial sem ser um impeditivo para o produto? Como o profissional de estratégia de vendas une esses times para lançar a funcionalidade ou o produto no prazo esperado?

Assim como a cultura de DevOps quebrou muitos silos, a de DevSecOps também. Todos são responsáveis pela segurança, não apenas um time. Os riscos devem ser conhecidos, compartilhados e endereçados. E esse “endereçamento” pode ser resolver, compensar de alguma forma ou apenas aceitar que aquele risco existe (e o pior risco é aquele que o hacker conhece, mas você desconhece).

Assim, para fazer dar certo, recomendo o uso de algumas ferramentas, que farão grande diferença nas etapas de desenvolvimento e de operação.

Durante o desenvolvimento:

– Faça o “scan” do código com ferramentas de SAST, DAST e SCA para ter visibilidade de possíveis vulnerabilidades no que foi escrito.

– Utilize uma solução de Workload Protection para checar se aquela imagem de container possui vulnerabilidades conhecidas. Não se pode reinventar a roda todo dia e usar imagens/ livrarias/ containers públicos é inevitável (“fail fast, learn faster”), mas também é inviável o time de segurança avaliar cada uma delas. Além disso, uma solução de Workload Protection valida a configuração do container (por exemplo, se é privilegiado) e direciona para ferramentas de Sandbox que confirmam que não existem ameaças de dia-zero ali embutidas.

Durante a operação:

– Tem vulnerabilidade no código, o risco é conhecido, mas tem data de entrega e vai atrasar a divulgação? Verifique se soluções, como um NGFW e um WAF avançado (com ML e integrado a sistemas de inteligência de ameaças), conseguem mitigar seu risco, trazendo a camada de proteção que precisa no acesso ao produto. Esse tipo de solução mitiga boa parte dos grandes riscos, como Log4Shell, MiTB, Bots, Virtual Patching, vazamento de dados, entre muitos outros. Além de validar a configuração dos serviços da nuvem.

O ponto aqui é: uma vez que os riscos são conhecidos, é possível minimizar sua exposição e também o trabalho em sua correção, com planejamento, sem atrasar entregas e sem ficar exposto.