Como equilibrar as equipes: seis dicas para superar as tensões entre segurança e desenvolvimento

Sempre haverá uma tensão natural entre as equipes de cibersegurança e de desenvolvimento. Afinal, o papel de quem desenvolve é “desenvolver”. Essas pessoas querem — e são remuneradas para — criar e lançar novas aplicações e recursos que ajudem a organização a avançar. Já o papel da segurança é garantir que nada de ruim aconteça quando um novo software é implantado, como uma violação de dados ou a indisponibilidade de serviços de negócios causada por software vulnerável.

Embora essa dinâmica gere uma tensão natural entre as duas funções, minha experiência mostra que não precisa ser assim. Basta tomar as medidas certas para aumentar a compreensão entre os dois grupos.

Infelizmente, muitas organizações não tomam as medidas necessárias. Com isso, a equipe de desenvolvimento passa a ver a segurança como um “obstáculo”, algo a ser superado. Da mesma forma, a equipe de segurança fica cada vez mais ressentida com a equipe de desenvolvimento, pois acredita que os desenvolvedores “não levam a segurança a sério o suficiente”.

Muito já se escreveu sobre como melhorar a relação entre desenvolvedores e equipes de segurança. Na última década, as práticas de DevOps se expandiram rapidamente com o objetivo de aliviar essa tensão. Houve algum avanço, mas, na minha opinião, não o suficiente. Por isso, decidi compartilhar o que aprendi ao liderar a equipe de segurança de aplicações de uma grande empresa de telecomunicações e obter algum sucesso ao equilibrar as tensões entre desenvolvimento e segurança.

Cada organização é diferente. Algumas equipes de desenvolvimento e segurança trabalham principalmente no escritório; outras, em grande parte remotamente; e há também as que combinam os dois modelos. Algumas contam com especialistas em segurança de aplicações muito experientes; outras, não. A equipe de que fiz parte trabalhava principalmente no escritório. O que funcionou para nós pode não funcionar para todos. Ainda assim, acredito que quem adotar estas seis dicas vai melhorar a relação fundamental entre as equipes de segurança e desenvolvimento.

Dica número um: priorize o treinamento.

As organizações devem oferecer treinamento em segurança de aplicações para novos desenvolvedores, conduzido pela equipe de AppSec e por alguém com experiência suficiente em desenvolvimento para conquistar o respeito dos participantes. Especialistas em AppSec com experiência em desenvolvimento entendem os problemas e as frustrações que os desenvolvedores enfrentam quando a equipe de segurança se comunica de maneira pouco eficaz.

Isso também se aplica, de modo geral, à equipe de AppSec. Quando ela é formada apenas por profissionais de segurança que nunca trabalharam com desenvolvimento, é provável que surja atrito entre os dois grupos, pois eles tendem a falar idiomas diferentes. Além disso, nenhum dos grupos entende os problemas e desafios enfrentados pelo outro. Quando a equipe de AppSec também conta com ex-desenvolvedores, a relação entre as equipes muda bastante.

Dica número dois: nos treinamentos de AppSec, use exemplos reais encontrados internamente pelas equipes de desenvolvimento e segurança.

Em todo treinamento de AppSec, os instrutores explicam como vulnerabilidades são introduzidas no código, como falhas de injeção, cross-site scripting (XSS) e controles de acesso inadequados. Também explicam o que essas vulnerabilidades representam para a aplicação e para a segurança dos dados. Embora a apresentação possa estar correta, ela também pode ser muito sem graça.

Para deixar o conteúdo mais interessante e chamar a atenção, tivemos bons resultados ao incluir vulnerabilidades em aplicações encontradas pela equipe de segurança durante verificações internas. A ideia não é personalizar o treinamento de AppSec. De forma alguma se deve apontar ou expor desenvolvedores individualmente.

O objetivo é aprender juntos sobre esses problemas. É mostrar que os desenvolvedores estão concentrados na lógica de negócios e no funcionamento da aplicação que estão criando, e não na segurança. Às vezes, a segurança nem está entre as prioridades deles, e isso é compreensível. Mas alguns exemplos de vulnerabilidades comuns encontradas internamente e que afetam a segurança da organização podem despertar o interesse e chamar a atenção.

Dica número três: elimine o estigma de encontrar vulnerabilidades.

No início da apresentação, mostramos um slide que ajudava a acabar com o estigma de ter vulnerabilidades no próprio código. Não vou revelar o nome da pessoa mencionada, mas o slide falava de um conhecido profissional de segurança. Ele desenvolve software de segurança distribuído como código aberto. Um software de código aberto criado por ele tinha uma vulnerabilidade — e era uma vulnerabilidade crítica.

Se essa pessoa pode lançar um software com vulnerabilidades críticas, qualquer desenvolvedor pode cometer os mesmos erros. Mostramos esse slide para explicar que é normal haver falhas de segurança no código, mesmo quando ele é escrito por alguém com muita experiência em segurança de aplicações. O importante é encontrá-las e eliminá-las.

Dica número quatro: ensine o impacto real das vulnerabilidades.

Também não nos limitamos a apresentar vulnerabilidades encontradas internamente. Nós as exploramos. É importante mostrar aos desenvolvedores como uma vulnerabilidade pode ser explorada e o que um invasor pode fazer com ela.

Em uma das primeiras sessões de treinamento, um desenvolvedor comentou sobre XSS e afirmou que esse tipo de vulnerabilidade não poderia ser tão prejudicial. Mostramos o que um invasor poderia fazer com um ataque de XSS, como se passar pela vítima, acessar dados confidenciais, sequestrar sessões, registrar teclas digitadas, disseminar malware e muito mais.

Isso abriu os olhos de muita gente. Na verdade, acho que esse é um problema de AppSec. Quando os desenvolvedores não entendem o impacto das vulnerabilidades, não se sentem motivados a corrigi-las nem a evitar que apareçam em suas aplicações. É da natureza humana ignorar riscos quando não se entende o impacto deles. Por isso, demonstrar o risco real pode fazer tanta diferença. Incluir esse conteúdo no treinamento ajudou a melhorar muito nossa relação com os desenvolvedores.

Dica número cinco: as equipes de segurança precisam saber o que é razoável.

Percebi que o atrito entre essas duas equipes muitas vezes surge quando a equipe de segurança exige tarefas impossíveis de concluir. Durante o treinamento, é essencial ensinar a equipe de desenvolvimento a trabalhar melhor com a segurança, sem dúvida. Mas é igualmente importante que a equipe de segurança faça solicitações razoáveis.

Às vezes, as solicitações são descabidas porque a equipe de segurança pede que sejam corrigidos problemas que não existem. Isso acontece quando ela executa um scanner de vulnerabilidades em aplicações e a ferramenta aponta uma vulnerabilidade inexistente ou um risco que não se aplica. A equipe de segurança repassa o resultado aos desenvolvedores, sem verificar, para que eles resolvam o problema. Se isso acontecer com frequência, os desenvolvedores ficarão frustrados e deixarão de dar atenção à equipe.

Além disso, as equipes de segurança precisam ter expectativas realistas, como dar tempo suficiente para corrigir vulnerabilidades e mais prazo quando elas forem complexas.

Dica número seis: use ferramentas precisas que capacitem os desenvolvedores.

Escolher ferramentas de avaliação precisas é essencial: elas explicam com clareza os problemas identificados, atribuem níveis de gravidade adequados e orientam sobre como corrigir as vulnerabilidades. Assim, os desenvolvedores entendem como resolver os problemas em questão. Melhor ainda é oferecer ferramentas feitas para desenvolvedores, que permitam a eles trabalhar de forma independente.

Embora sempre haja algum nível de tensão entre as equipes de segurança e desenvolvimento, e as organizações precisem se esforçar continuamente para reduzi-la, descobrimos que algumas medidas simples para promover compreensão e empatia entre as equipes ajudam muito a melhorar essa relação.

Alinhe as equipes de desenvolvimento e segurança para alcançar melhores resultados com a Snyk AI Trust Platform

As seis dicas acima são princípios fundamentais para aproximar as equipes de desenvolvimento e segurança. Não são apenas teorias: são medidas práticas que promovem empatia, criam entendimento mútuo e cultivam o respeito entre as equipes. Mas os princípios, por si só, não bastam. Eles precisam de ferramentas que transformem essa forma de trabalhar em realidade.

Quando as ferramentas são feitas para desenvolvedores, desaparece a divisão tradicional entre desenvolver com rapidez e desenvolver com segurança. A segurança deixa de ser um obstáculo e se torna uma parceira confiável para a inovação. A Snyk AI Trust Platform oferece essa base comum, permitindo que as duas equipes falem a mesma língua e trabalhem em direção ao mesmo objetivo: entregar software seguro e de alta qualidade com mais rapidez.

A Snyk AI Trust Platform foi desenvolvida para integrar a segurança perfeitamente ao SDLC e resolver diretamente as principais causas de atrito. A plataforma capacita os desenvolvedores com informações de segurança rápidas, precisas e práticas, diretamente nos ambientes em que trabalham: IDE, repositório e pipeline de CI/CD.

Pronto para criar uma verdadeira parceria entre suas equipes de desenvolvimento e segurança? Agende uma demonstração ao vivo e veja como capacitar suas equipes para incorporar a segurança desde o início.