Não crie ferramentas de segurança: crie ferramentas para desenvolvedores

Esta publicação foi publicada originalmente no CSO Online, em 3 de novembro de 2017.

Há muito tempo, líderes e fornecedores de segurança de aplicações perseguem o objetivo difícil de fazer com que os desenvolvedores adotem a segurança. Esse desejo é motivado, em parte, pelo valor de incorporar a segurança desde o início, mas sua principal causa é o volume de trabalho e o ritmo acelerado. O número de desenvolvedores é 100 vezes maior que o de profissionais de segurança, e a velocidade do desenvolvimento moderno torna impossível que qualquer equipe externa acompanhe o ritmo. Mesmo assim, repetidamente não conseguimos alcançar esse objetivo.

As soluções de segurança se integram às ferramentas de desenvolvimento, os requisitos de segurança são incluídos no fluxo normal de requisitos e os treinamentos de segurança são repetidos a cada trimestre. Ainda assim, a segurança é esquecida assim que a equipe de segurança deixa de participar. Como podemos romper esse ciclo?

O caminho para o sucesso é parar de criar ferramentas de segurança que tentam se adaptar ao desenvolvimento e começar a criar ferramentas de desenvolvimento que cuidem da segurança. Isso pode parecer uma diferença semântica, mas, na verdade, transforma a maneira como pensamos sobre ferramentas e programas de segurança.

Priorize as necessidades dos desenvolvedores

Quando uma equipe de segurança define um processo, normalmente começa pelas próprias necessidades. Ela precisa saber o que os desenvolvedores estão fazendo, garantir a aplicação de determinados controles e exigir a execução de certos testes. É compreensível que o processo ou as ferramentas se concentrem bastante em atender às necessidades de segurança, conformidade ou governança e às demandas da equipe de segurança.

Para conquistar o verdadeiro engajamento dos desenvolvedores, precisamos considerá-los os usuários mais importantes da nossa solução e entender a segurança e a conformidade como funções de apoio. Como essa prática de segurança ajudaria a reduzir o risco de uma interrupção? Como melhoraria a comunicação e a colaboração entre a equipe? Como daria a desenvolvedores mais juniores condições de assumir tarefas maiores? Se você reformular as necessidades de segurança pensando nos objetivos dos desenvolvedores, terá muito mais chances de atendê-las.

Mude seu ponto de partida.

Quase sempre, tentamos adaptar as práticas de segurança ao fluxo de trabalho de desenvolvimento. Tentamos executar análises estáticas no processo de build, mas descobrimos que elas demoram demais. Aplicamos essa análise na IDE, mas não confiamos que os desenvolvedores saibam descartar os falsos positivos. Alertamos sobre uma vulnerabilidade conhecida um desenvolvedor que não tem os recursos necessários para fazer a triagem.

Boas ferramentas para desenvolvedores partem do outro lado. Como funciona o processo de desenvolvimento? Em que momento esse controle de segurança agregaria mais valor ou seria menos intrusivo? Quais são os principais requisitos para integrá-lo com sucesso nesse momento? Com as respostas a esse tipo de pergunta, você pode criar sua solução de segurança com as prioridades certas em mente.

Essas perguntas também podem revelar ferramentas já presentes no fluxo de trabalho que podem ser usadas nos processos de segurança. Por exemplo, em episódios diferentes do podcast The Secure Developer, a equipe de segurança da PagerDuty falou sobre o uso do Splunk para fins de segurança, e Adam Jacobs, da Chef, explicou como o InSpec pode ajudar a melhorar sua postura de segurança.

Compare-se com outros produtos.

As ferramentas para desenvolvedores evoluíram muito na última década, impulsionadas pela revolução de DevOps e pelo protagonismo dos desenvolvedores. Com base nas ferramentas de maior sucesso, as boas práticas também evoluíram — da usabilidade aos preços, passando pela importância da documentação.

Em vez de comparar seu firewall de aplicações web a um firewall de rede, compare-o a uma ferramenta de APM (monitoramento de desempenho de aplicações) bem-sucedida. Compare suas ferramentas de teste de segurança de aplicações com linters e ferramentas de revisão de código, não com scanners de segurança de rede. Essas são ferramentas que conquistaram espaço no dia a dia dos desenvolvedores, que agora dependem delas regularmente. Se você reproduzir o funcionamento dessas ferramentas, sua solução se encaixará naturalmente na forma como os desenvolvedores pensam e trabalham.

Embora meus exemplos enfatizem um pouco mais as ferramentas do que os processos, o princípio vale para ambos. As práticas de desenvolvimento seguro também se beneficiam quando as necessidades dos desenvolvedores são priorizadas, quando se parte das metodologias de desenvolvimento atuais e quando se consideram outras práticas e processos adotados pela equipe de engenharia. Uma prática de segurança imposta corre o risco constante de ser deixada de lado. Já uma prática de desenvolvimento, mesmo quando envolve segurança, pode se integrar à rotina com muito mais naturalidade.

Para conquistar o apoio dos desenvolvedores à segurança, não crie ferramentas de segurança. Crie ferramentas para desenvolvedores que ajudem na segurança e veja como isso faz toda a diferença na adoção.