Segurança vs. desenvolvimento: uma disputa de prioridades

No dinâmico ecossistema tecnológico atual, é fundamental gerenciar programas de AppSec em escala. À medida que as bases de código crescem e as ameaças se tornam mais sofisticadas, o foco está deixando de ser a correção de vulnerabilidades isoladas e passando a ser a construção de posturas de segurança coesas em todas as equipes de desenvolvimento. Abordagens emergentes, como gerenciamento da postura de segurança de aplicações (ASPM), permitem que as organizações vão além das vulnerabilidades individuais e coordenem programas abrangentes voltados ao gerenciamento dos riscos críticos para os negócios. Essas ferramentas simplificam o processo ao automatizar controles de segurança, aprimorar a análise de riscos e priorizar vulnerabilidades.

Vale lembrar que, embora o ASPM possa parecer uma abordagem nova para algumas pessoas, na Snyk estamos seguindo esse caminho há 8 anos. Desde o primeiro dia, a Snyk foi pioneira em ferramentas de AppSec “voltadas a desenvolvedores”. Nosso objetivo sempre foi levar os programas de AppSec além do simples “deslocamento para a esquerda” com ferramentas tradicionais de AppSec e mostrar às equipes que, para a AppSec ser realmente eficaz, as empresas precisavam dar mais responsabilidade pela segurança aos desenvolvedores. Para isso, era necessária uma categoria totalmente diferente de ferramentas de segurança, criada para desenvolvedores.

Mesmo quando as responsabilidades de segurança são transferidas para os desenvolvedores, a equipe de Segurança continua responsável pela postura de risco das aplicações da empresa. Integrar as ferramentas às ferramentas dos desenvolvedores é apenas parte do trabalho que fazemos na Snyk. Uma parte ainda maior é ajudar as equipes de Segurança e Desenvolvimento a trabalharem juntas para adotar uma abordagem de segurança mais preventiva. Isso inclui, claro, o uso das ferramentas da Snyk, mas também ações de capacitação e programas de Security Champions; a definição e a mensuração de métricas de sucesso em segurança de aplicações; e a expansão dos resultados alcançados pela primeira equipe de aplicações para todas as aplicações e equipes. Ao longo desse período atendendo nossos clientes, o ASPM é uma prova da nossa dedicação e da transformação do conhecimento que acumulamos em um produto, estabelecendo um padrão em segurança de aplicações.

Para aproveitar todo o potencial dessas ferramentas, é essencial alinhar estrategicamente as equipes de Desenvolvimento e Segurança. Esse alinhamento costuma ser um desafio, pois Segurança e Desenvolvimento podem parecer atuar em áreas distintas. Diante dos benefícios oferecidos pelo ASPM, é ainda mais importante entender o que motiva cada equipe.

Entender o que motiva cada equipe é fundamental para que os desenvolvedores adotem amplamente ferramentas de segurança como a Snyk.

Necessidades das equipes

Onde as necessidades entram em conflito

• Foco: Patches de segurança urgentes vs. novos recursos urgentes.

• Ritmo: A cautela da Segurança vs. o ritmo acelerado do Desenvolvimento.

• Adoção de ferramentas: O entusiasmo dos desenvolvedores por novas ferramentas pode fazê-los ignorar a fila de avaliação de segurança.

• Comunicação: Às vezes, as equipes falam idiomas diferentes — o que está documentado para uma pode ser incompreensível para a outra.

• Treinamento: Para um desenvolvedor, o treinamento de segurança pode parecer um desvio.

Reflexão: identificando o desalinhamento

Para resolver possíveis problemas na adoção de ferramentas de segurança por desenvolvedores, primeiro identifique os desalinhamentos existentes:

Perguntas que as lideranças de Segurança podem fazer a si mesmas

• Estratégia: Como incluímos os desenvolvedores na nossa visão de segurança?

• Ferramentas: Como apoiamos os desenvolvedores na incorporação da segurança?

• Aprendizado: Qual é o nosso plano de capacitação em segurança para desenvolvedores?

• Ciclo de feedback: Como está a comunicação entre Desenvolvimento e Segurança?

Perguntas que as lideranças de Engenharia podem fazer a si mesmas

• Visão dos desenvolvedores: Como os desenvolvedores percebem seu papel na segurança?

• Desafios: Que obstáculos eles enfrentam ao usar ferramentas de segurança para desenvolvedores?

• Relação entre Segurança e Desenvolvimento: Como você definiria a relação atual entre Segurança e Desenvolvimento?

• Aprendizado com os erros: Após incidentes de segurança, como as lições aprendidas são incorporadas?

• Alocação nas sprints: Que porcentagem das nossas sprints dedicamos à segurança?

Criando sinergia: aumentando a adoção de ferramentas de segurança por desenvolvedores

Depois de identificar o que está causando o desalinhamento, é hora de construir essa ponte:

Diálogo

• Liderança de Segurança: Mantenha os desenvolvedores informados sobre segurança e esteja aberto ao feedback deles.  

  • Priorize as atualizações essenciais: Embora o contato frequente seja fundamental, também é importante diferenciar alertas críticos de segurança dos menos importantes para não sobrecarregar os desenvolvedores.

  • Reúnam-se regularmente: Organize reuniões mensais ou trimestrais com os desenvolvedores para compartilhar informações sobre segurança e discutir tendências, em vez de incidentes isolados.

• Liderança de Engenharia: Incentive a participação aberta dos desenvolvedores nessas conversas. Designe uma pessoa de contato que possa trabalhar diretamente com o fornecedor das ferramentas de segurança.

Integração fluida

• Liderança de Segurança: Fazer verificações de segurança com ferramentas no SCM e/ou no CI/CD é um bom começo. Garanta que os dados de segurança estejam visíveis e permitam tomar medidas. No início, não bloqueie as verificações de segurança de PRs nem os builds; conquiste a confiança dos desenvolvedores com capacitação, não com imposição.

• Liderança de Engenharia: Capacite os desenvolvedores no uso das ferramentas de segurança. Alinhem-se sobre alertas de vulnerabilidade, triagem e planos de políticas.

Aprendizado contínuo

• Liderança de Segurança: Use as ferramentas de segurança para desenvolvedores em workshops direcionados.

• Liderança de Engenharia: Incentive os desenvolvedores a participar quando o conteúdo dos workshops for diretamente relevante para o trabalho deles.  Compartilhe feedback regularmente com a equipe de Segurança sobre as sessões, para que continuem interessantes e relevantes para o público de desenvolvimento.

Métricas unificadas

• Liderança de Segurança:  Comece a acompanhar KPIs de vulnerabilidades. Compartilhe os resultados, comemore as conquistas e acolha o feedback dos desenvolvedores.

• Liderança de Engenharia: Reserve parte do investimento em dívida técnica para a segurança, destinando uma porcentagem das sprints à correção de problemas existentes. Inclua metas de segurança no planejamento das sprints, especialmente ao lançar novos recursos.  Incentive os desenvolvedores a dar feedback contínuo sobre os alertas de segurança — diferencie os problemas críticos do ruído.

Priorize para manter a segurança

Em resumo, para otimizar programas de AppSec em escala, precisamos deixar de focar exclusivamente em vulnerabilidades individuais e estabelecer estratégias de segurança integradas em todas as iniciativas de desenvolvimento. Entender o que motiva desenvolvedores e equipes de Segurança é fundamental nesse processo.

Plataformas como a Snyk podem impulsionar a colaboração entre as equipes de Segurança e Desenvolvimento por meio de mais visibilidade, controles de segurança, análise aprofundada de riscos e priorização estratégica. Essa abordagem coletiva representa o futuro: a segurança não apenas identifica ameaças, mas também colabora com os desenvolvedores para criar defesas proativas e garantir um ecossistema tecnológico unificado, ágil e seguro.