Code Review Incremental: contratar ou não fora de casa?
Quando iniciamos uma conversa com clientes ou empresas interessadas em nossos serviços, sempre surge uma questão: o que é mais vantajoso, contratar uma consultoria para realizar Code Review Incremental ou realizar os testes internamente?
Vamos tentar explicar esta dúvida falando um pouco sobre a diferença entre a realização de um Code Review Incremental e a realização de testes de code review internos.
Uma breve análise
Em um primeiro momento temos que entender que a realização de testes incrementais aqui descritos estão diretamente relacionados com a validação de códigos novos ou que sofreram alguma alteração durante o seu processo de codificação.
A abordagem de code review de forma incremental está relacionada aos processos de desenvolvimento ágil, e portanto ligados a uma estrutura de CI/CD de muitas empresas. Surge então uma dúvida quando as empresas precisam buscar soluções que visam trazer melhorias para o seu processo de revisão: seria mais vantajoso realizar o teste internamente ou contratar uma consultoria para realizar os testes?
Para responder a esta pergunta é preciso levar em consideração uma série de parâmetros mas, de forma geral, esta seria uma ótima oportunidade para realizar a contratação de um consultoria, desde que o volume de testes a ser realizado justifique este investimento, e que o movimento de transferência de conhecimento aconteça de forma direta entre as equipes.
O que as empresas ganham com contratação externa?
Um dos primeiros fatores considerados quando as empresas pensam em realizar seus testes internamente é o valor de aquisição de um serviço externo frente ao uso de seus próprios colaboradores. No entanto, temos que lembrar que dentro do valor de contratação do serviço externo temos muito mais coisas do que somente a própria revisão de código.
Quando atuamos em revisões de códigos de forma incremental, executamos ações diretamente ligadas às equipes de desenvolvimento, trocando ideias e explicando como uma vulnerabilidade pode afetar a aplicação. Muitas vezes a falta de visão das equipes internas de desenvolvimento no que se refere à segurança não se deve à falta de conhecimento, mas sim ao foco do profissional. A diferença é que um analista contratado externamente está totalmente focado em Application Security, enquanto os desenvolvedores estão com seu foco na criação do código em si.
Isto, muitas vezes, não é levado em consideração quando se realiza uma contratação externa. Existe uma falsa percepção de que se um profissional é um bom desenvolvedor será também um bom analista de segurança. Isso pode até ser verdade, mas não é uma garantia.
Ferramentas podem não ser suficientes
Outro ponto recorrente no planejamento feito pelas empresas é a contratação ou mesmo aquisição de uma ferramenta para realização de testes do tipo DAST e SAST, com o objetivo de suprir a necessidade de serviços externos.
Este tipo de testes pode ajudar em alguns casos, mas é importante observar que os testes de DAST e SAST devem ser usados como apoio ao processo de revisão de código, e não como ferramenta principal em um processo de revisão de código.
Isto se deve porque ferramentas do tipo DAST e SAST não realizam revisão de código com a mesma profundidade que um analista faz. Quando executamos ferramentas, estas se baseiam em padrões que serão buscados dentro do código e tais padrões podem ser identificados corretamente, mas também podem apresentar inúmeros resultados falsos. Os resultados chamados de “falsos positivos” são vulnerabilidades apontadas pela ferramenta, mas que na verdade não existem.
Um cenário ainda mais crítico é quando a ferramenta apresenta um resultado chamado de “falso negativo“ – onde há a vulnerabilidade mas a ferramenta não mostra esta falha. Isso pode acontecer por vários motivos, e o mais comum é que a ferramenta não tem a capacidade humana de interpretação de um cenário maior, observando um conjunto de dados e informações. Em determinados casos, somente a percepção humana é capaz de compreender que uma determinada falha não apresentar perigo quando isolada, mas dentro de um contexto pode ser usada como porta de entrada para a aplicação, tornando-a vulnerável.
Existe um custo escondido nos testes internos
A manutenção de um time de analistas de segurança é outro fator que deve ser avaliado na escolha entre testes internos ou contratação de serviços de consultoria.
Se avaliarmos a implementação de um processo contínuo de revisão de segurança de código, precisamos analisar alguns desafios, tais como:
- Adotar metodologias de análise de padrão mundial (afinal, seu atacante pode estar em qualquer lugar do mundo)
- Recrutar profissionais de alta-especialização, pois os analistas de segurança engajados na tarefa devem, antes de tudo, serem bons programadores nas linguagem adotadas pela organização e terem se especializado em segurança
- Implementar e manter processos eficientes de gestão de análises, pois o Code Review incremental precisa ser realizado em cada build liberado – o que pode ser especialmente difícil de gerenciar em um ambiente ágil
- Selecionar, adquirir, instalar e configurar ferramentas para dar suporte ao processo de análise contínua
- Implementar e controlar um sistema de gestão de vulnerabilidades para que os reports possam ser registrados, documentados, e encaminhados para correção
- Implementar e controlar ciclos de retestes, para que as vulnerabilidades identificadas e corrigidas possam ser realizadas de modo a garantir que o bugfix aplicado foi efetivo na eliminação da vulnerabilidade
- Desenvolver e aplicar um programa de treinamento e aprendizado contínuo, para que as equipes de desenvolvimento desenvolvam habilidades de codificação segura, de modo a reduzir a incidência de vulnerabilidades no código
- E, finalmente, consolidar dados e apresentar relatórios para balizar a tomada de decisão e promover melhorias no processo.
Agora ficou mais claro?
Ao se tomar ciência do desafio, ficam evidentes os benefícios da contratação de análise de revisão de código por meio de um serviço externo, quando comparada aos custos e esforços necessários para contratar uma equipe interna para realizar essas atividades.
Quando avaliamos o serviço externo de revisão de código, podemos observar que a entrega vem acompanhada de outros serviços, formando um serviço gerenciado, geralmente com escopo mais completo do que somente a revisão de código.
A implementação do serviço gerenciado reduz significativamente o prazo de implantação do modelo, pois os processos já vem pré-definidos, testados e validados em outras organizações, o que garante um grau de maturidade elevado.
A organização recebe ainda o conjunto inicial de ferramentas que já foram selecionadas, testadas e otimizadas, sendo implementadas rapidamente durante o setup (o que costuma levar cerca de duas semanas).
No modelo de serviço gerenciado, como os profissionais que aplicarão a revisão de código são integrantes da equipe da empresa fornecedora, a organização passará a dispor, de forma imediata, de uma equipe de analistas experientes, com conhecimento em diversas tecnologias, de modo a cobrir um leque maior de linguagens, frameworks e stacks que já são ou podem vir a ser utilizadas no processo de desenvolvimento.
E não para por aí…
Um outro problema nem sempre considerado durante a avaliação da contratação é o fato de não precisar lidar com questões de turn over de profissionais, além de economizar esforço para promover o engajamento e desenvolvimento destes profissionais.
Podemos concluir, por fim, que a contratação do serviço gerenciado pode ser bastante vantajosa para a organização também a médio e longo prazo, já que ela poderá contar com um melhor controle de gestão de vulnerabilidades, além de dashboards de acompanhamento de indicadores e relatórios de desempenho.
Estes recursos serão muito valiosos no futuro, pois facilitarão a medição de ROI e tomada de decisão de investimento em ações que apresentarem os melhores resultados.
