Adicionando o “Sec” no DevOps
O principal desafio a ser enfrentado é tornar o “Sec” o mais silencioso e transparente possível para os desenvolvedores.
Um dos principais objetivos das empresas que implementam a cultura do DevOps é justamente quebrar os silos existentes entre a equipe de desenvolvimento e operações. Adicionar a equipe de segurança da informação nesta filosofia colaborativa fatalmente representará a necessidade de quebrar mais um silo. A integração da equipe de segurança da informação a fim de oferecer o DevSecOps fatalmente irá requerer uma mudança de mentalidade, processos e tecnologias.
É importante que fique claro desde o início que a segurança da informação deverá se adaptar aos processos e ferramentas de desenvolvimento, e não o contrário. Assim como é importante compreender que, vulnerabilidade zero não existe e que adicionar o “Sec” no DevOps jamais deverá impactar nos processos e na cadência da integração e do deploy contínuo.
Talvez o principal desafio a ser enfrentado é tornar o “Sec” o mais silencioso e transparente possível para os desenvolvedores. Entendo que esta seja uma mudança significativa, uma vez que é comum que profissionais de SI forcem os desenvolvedores a se adequarem aos processos existentes, por isto que mudanças nos processos serão necessárias.
Será necessário integrar de maneira continua as ferramentas e controles de segurança na esteira DevOps. Neste cenário é comum que as empresas adotem ferramentas de SAST e DAST dentro do processo de desenvolvimento, porém mais recentemente a adoção de ferramentas IAST (Interactive Application Security Testing) vem ganhando espaço, justamente por atuarem no servidor de aplicação, como um agente que realiza em tempo real a detecção de problemas de segurança através da análise do tráfico e da execução de fluxos da aplicação. O uso do IAST não requer modificações na aplicação nem atividades de testes de penetração, uma vez que a ferramenta de IAST detecta as vulnerabilidades implementando um agente no qual injeta funcionalidades em certos pontos de execução de sua aplicação.
Já dizia o proverbio, “o ótimo é inimigo do bom”, a segurança perfeita é impossível, principalmente no contexto atual onde a segurança perfeita fica em desacordo com as necessidades dos negócios e com os desenvolvedores pressionados pela velocidade e agilidade. Ferramentas do tipo SAST e DAST apresentam um nível considerável de falsos positivos, já nas ferramentas de IAST este índice chega próximo de zero, porém ainda assim será uma tentativa inútil remover todas as vulnerabilidades, pois estaremos diminuindo a velocidade do desenvolvimento e desperdiçando tempo perseguindo problemas que não são reais. Além disso, podemos compensar parte do risco residual utilizando controles de proteção como IPS e Firewalls de aplicativos (WAF).
Se eu puder te dar uma dica eu diria, foque primeiro em identificar e remover vulnerabilidades críticas e conhecidas, principalmente aquelas relacionadas ao OWASP-10. Aplicações modernas são desenvolvidas utilizando componentes, bibliotecas e estruturas pré-construídas onde a parte do código personalizado representa uma porcentagem menor do código. Desta maneira o foco de uma varredura deve estar justamente nos problemas conhecidos de configurações incorretas de bibliotecas, estruturas e componentes. Ou seja, é mais fácil identificar vulnerabilidades em códigos conhecidos do que vulnerabilidades em códigos personalizados.
Por fim, tente adotar um modelo de “Security Champion”. O uso deste modelo tem como objetivo principal antecipar possíveis problemas de projetos ou implementação no início do projeto de desenvolvimento, reduzindo assim a complexidade percebida da codificação segura, ajudando a equipe de desenvolvimento a tratar problemas que de fato precisam ser tratados antes que a aplicação esteja em produção.
*Por Daniel Rosa
