Entenda a visão dos desenvolvedores sobre segurança

Eles fazem isso porque devem

A melhor maneira de levar as equipes de desenvolvimento a adotar a segurança é torná-la uma parte esperada de suas funções e metas. Isso dá às equipes de desenvolvimento uma responsabilidade formal e condições para priorizar a segurança. Nesse modelo, é importante definir claramente quem é responsável, para que as equipes não presumam que outra equipe assumiu a responsabilidade pela segurança de um projeto compartilhado ou legado.

Saber o que devem fazer não basta. Também é importante ter processos que ajudem as equipes a atingir suas metas de segurança. Por exemplo, dar visibilidade aos resultados dos testes ou explicar os níveis adicionais de exposição e risco que surgem depois que um desenvolvedor escreve um novo recurso. A visibilidade e a transparência proporcionadas por um scorecard podem ajudar a promover a responsabilidade individual de que os desenvolvedores precisam para garantir que a segurança faça parte do fluxo de trabalho. Essa abordagem também funciona especialmente bem com equipes terceirizadas, que tendem a circular entre projetos e a ter menos senso de responsabilidade ou orgulho por eles.

Eles fazem isso porque devem

É um motivo tão bom que o repetimos! Há outro fator que leva um desenvolvedor a programar com segurança: fazer a coisa certa. Uma parcela dos seus desenvolvedores se importa com segurança ou tem grande orgulho e senso de responsabilidade, pessoal ou profissional, em escrever código sustentável e seguro.

Faça do caminho certo o caminho mais fácil (ou seja, uma paved road)

Todo obstáculo que impede um desenvolvedor de realizar uma tarefa de segurança pode fazer com que ele desista. Esses obstáculos podem ir desde a falta de conhecimento até um fluxo de trabalho dolorosamente lento, passando por um volume excessivo de problemas sem saber por onde começar. Facilitar a inclusão da segurança nos fluxos de trabalho existentes é essencial para a adoção de práticas de segurança.

Incentivar o uso de práticas padronizadas com uma abordagem de paved road é uma ótima maneira de oferecer suporte útil e práticas recomendadas comprovadas. Além disso, isso abre mais oportunidades para criar documentação e orientações precisas e atualizadas, que outras pessoas podem reutilizar e atualizar regularmente.

"Chamamos esse conceito de paved road. Você pode, claro, abrir caminho no meio do mato e atravessar a floresta. Mas, se houver uma estrada pavimentada, lisa e agradável que leve ao seu destino, provavelmente você vai preferir usá-la."

Jason Chan, vice-presidente de Segurança da Netflix, no The Secure Developer, falando sobre empatia com desenvolvedores

Pense no que os desenvolvedores precisam para avançar. Analisar, testar e identificar problemas é relativamente fácil em comparação com corrigi-los. Um desenvolvedor não quer saber que há dez vulnerabilidades no grafo de dependências. Ele quer saber se uma pequena atualização de uma dependência vai corrigir os problemas que estão bloqueando a versão. Por isso, pense em soluções, não em problemas: em geral, a lista de soluções é bem menor!

Também é importante considerar onde os desenvolvedores querem dedicar seu tempo e como preferem receber resultados e ações de segurança. Qualquer coisa fora do fluxo de trabalho habitual é uma distração que eles precisarão lembrar de fazer. Integrações aos fluxos de trabalho existentes, implementadas por pessoas que entendem os processos atuais e a tecnologia por trás deles, podem proporcionar uma ótima experiência para desenvolvedores. Seja intencional: ofereça resultados úteis, feedback claro e prático, e mantenha o fluxo de trabalho rápido e sem complicações. Em resumo, implemente com empatia pelos seus desenvolvedores.

Automatize, automatize, automatize

Os pipelines de DevOps mais robustos são bem automatizados. Em um estudo recente, a Snyk constatou que a automação também tinha forte correlação com o sucesso de programas de segurança shift left. Os dados mostraram que organizações com pipelines de implantação totalmente automatizados têm o dobro de probabilidade de adotar ferramentas de teste de segurança estática de aplicações (SAST) e análise de composição de software (SCA) em seu SDLC. Além disso, as organizações com automação completa tinham mais de quatro vezes mais probabilidade de corrigir problemas de segurança em um dia e mais do dobro de probabilidade de corrigi-los em uma semana.

É evidente que, quanto mais automatizamos, mais testes podemos executar e mais problemas podemos detectar. Com cuidado, também podemos adicionar proteções e políticas de segurança aos pipelines para identificar problemas que exigem nossa atenção e ação. Isso cria uma dinâmica familiar para desenvolvedores que já automatizam tarefas como testes de integração.

Além disso, automatizar a segurança também reduz o atrito entre as equipes de segurança e de desenvolvimento, porque quem aponta a necessidade de corrigir um problema é um processo, não uma equipe ou uma pessoa. Assim, a equipe de segurança pode apoiar a equipe de desenvolvimento e ajudar com os problemas que exigem conhecimento especializado, em vez de se tornar um gargalo ou apenas dar más notícias.

"Eu diria que o que eles precisam fazer é automatizar todas as ferramentas de segurança (que fizerem sentido) no pipeline de DevOps. Gostaria que tivéssemos feito isso antes do que estamos fazendo e já fizemos. É essencial avisar o desenvolvedor sobre um problema no código o mais cedo possível, de forma automatizada. Se der para fazer isso no momento em que o código é enviado, para que ele entenda o problema na hora, melhor ainda. Ou até usar uma ferramenta que sinalize imediatamente um problema no IDE enquanto ele escreve o código. Implementar essa automação é fundamental. Tentar corrigir um problema pouco antes de lançar um produto é muito mais difícil."

Ryan Ware, arquiteto de Segurança e diretor da equipe de Garantia de Produtos Intel e Ferramentas de Segurança

Capacitação e conhecimento sobre desenvolvimento seguro

A capacitação pode ter resultados variados entre as equipes de desenvolvimento, sobretudo porque há muitos cursos e materiais irrelevantes que elas são obrigadas a fazer (e, depois, ainda precisam dedicar tempo a uma prova curta). Muitas vezes, tudo isso acaba marcado como concluído em uma lista de verificação de conformidade de capacitação.

Quando a capacitação se torna uma parte relevante do dia a dia do desenvolvedor — ajudando-o a trabalhar, corrigir um bug ou programar com mais segurança —, a adoção de práticas de segurança acelera. O curso ou módulo de capacitação precisa ser útil para o desenvolvedor, ajudá-lo a se proteger melhor e gerar resultados rapidamente.

Ao planejar a capacitação, pense em como ela ajuda suas equipes a se concentrarem no desenvolvimento seguro. Considere quais ações elas vão aprender e aplicar de fato aos processos ou fluxos de trabalho. Pense em como direcionar a capacitação para oferecer ajuda relevante no momento em que elas mais precisam. E considere como ela pode ir além da tecnologia, abordando também processos e cultura.

Confira algumas dicas para aproveitar ao máximo a capacitação em segurança:

• O treinamento deve ser envolvente o suficiente para que elas queiram participar. Uma maneira fácil de melhorar a qualidade da capacitação é realizar programas-piloto, coletar feedback e fazer ajustes antes de disponibilizá-la para todos.

• Reconheça que as equipes de desenvolvimento podem ter diferenças significativas em seus vetores de ataque e ofereça lições relevantes para cada caso. Por exemplo, ataques de directory traversal podem ser mais pertinentes para desenvolvedores de backend.

• Ao abordar vulnerabilidades em treinamentos, foque naquelas que afetam a equipe, considerando a linguagem de programação, o framework, as bibliotecas e outros fatores relevantes. Relatos de incidentes que afetaram outras empresas com ecossistemas semelhantes podem ajudar a demonstrar o potencial de estrago.

• Embora seja bom apresentar exemplos reais de problemas de segurança, não use o medo como principal motivador. Isso pode gerar resultados no curto prazo, mas não é uma estratégia duradoura. A exceção são problemas de segurança realmente assustadores, como aqueles que podem devastar uma empresa!

• Inclua a capacitação nos scorecards para responsabilizar as equipes por concluí-la.

• Garanta que a capacitação ensine como prevenir ataques concretos. Se você explicar uma vulnerabilidade, mostre como ela pode ser explorada. Se explicar como reforçar uma parte do pipeline, descreva a superfície de ataque que será mitigada. Torne tudo real e concreto.

• Garanta que exista documentação para todas as tarefas que você quer que os desenvolvedores realizem. Peça que eles validem se a documentação funciona ou, melhor ainda, que a escrevam para o próximo desenvolvedor ou equipe. Lembre-se: a documentação não substitui as proteções, mas elas também devem ser documentadas.

• Se uma equipe red encontrar um incidente, use-o como oportunidade para criar uma capacitação relevante e realista. Uma análise aprofundada do incidente ajuda a tornar o risco concreto. Se possível, convide a equipe red para uma sessão de perguntas e respostas.

Por que os desenvolvedores evitam a segurança?

Falamos sobre por que os desenvolvedores dedicam tempo a criar software seguro. Mas é igualmente importante, se não mais, entender por que eles resistem e evitam tomar medidas adicionais para garantir que entreguem código seguro.

Atrito

As barreiras identificadas pelas equipes variam conforme a etapa de adoção da segurança e a maturidade em desenvolvimento moderno. Nas equipes que estão começando a incorporar segurança, há resistência quando os motivos e benefícios das mudanças nos processos não são comunicados com clareza. O novo processo precisa ser pouco invasivo e considerar a equipe de desenvolvimento e seus fluxos de trabalho. Para incentivar a adoção, comunique-se de forma clara e frequente, reduza o atrito ao mínimo integrando a segurança aos processos existentes e, sempre que possível, consolide ferramentas para diminuir a complexidade.

"Acho que um dos maiores desafios que enfrentamos é fazer com que as principais partes interessadas da área de tecnologia e os desenvolvedores realmente entendam a importância e o valor da segurança. No mundo ideal, essa compreensão já existiria. Um desenvolvedor dificilmente terá motivação para fazer algo se não enxergar seu valor. O mesmo vale para um responsável pelo produto, um gerente de desenvolvimento ou até um diretor de engenharia de software. Se eles não compreenderem o valor da segurança, não terão muito incentivo para priorizá-la em relação ao trabalho nos recursos do produto."

Nicholas Vinson, líder de DevSecOps na Pearson

Desconfiança

Oferecer valor e manter ou conquistar a confiança são essenciais para estabelecer um processo duradouro, que as equipes vão seguir. Quando perdem a confiança nos dados, nas ferramentas ou no processo, elas passam a ver isso como um obstáculo e tentam contorná-lo. Por exemplo, falsos positivos recorrentes em uma ferramenta ou processo não apenas desmotivam ou irritam os desenvolvedores, mas também aumentam a probabilidade de eles ignorarem ou descartarem resultados de vulnerabilidades e problemas reais, em vez de confiar nos dados.

Complexidade

Da mesma forma, quando as ferramentas tornam os problemas existentes mais complexos e não ajudam a encontrar ou oferecer uma solução, elas apenas aumentam o trabalho dos desenvolvedores. Saber que existe uma vulnerabilidade é só o começo. O desenvolvedor ainda precisa identificar todas as formas e os locais em que ela pode ser acessada no aplicativo (por exemplo, os diferentes caminhos no grafo de dependências). Ele precisa saber imediatamente se é possível corrigi-la e, em caso afirmativo, como fazer isso. Os desenvolvedores querem ferramentas intuitivas e instrutivas para implementar soluções rapidamente.

Responsabilidade

Outro motivo para uma tarefa sair da lista de uma pessoa sem ser assumida por outra é a falta de definição de responsabilidades. Em projetos ou funcionalidades mais recentes, a responsabilidade pode estar clara: ninguém além de uma equipe mexe no código com o problema. Mas e se uma parte da aplicação for um serviço compartilhado, usado e mantido por várias equipes, sem que nenhuma seja totalmente responsável por ele? Quem assumiria um bug ou problema de segurança que não afeta diretamente sua equipe? Outro exemplo comum é uma imagem de contêiner usada por várias equipes. Quando todas estão correndo para entregar as funcionalidades de suas próprias equipes, problemas no código compartilhado muitas vezes acabam sem ninguém para resolvê-los.

Tempo

É claro que, mesmo quando as responsabilidades estão bem definidas, ainda é difícil encontrar tempo para incluir a segurança no fluxo de trabalho. Mesmo que haja automação para testar seu código, essa é a parte fácil. O trabalho de verdade está em analisar os resultados e corrigir os problemas. Quanto mais as ferramentas geram resultados ruins ou não orientam nem automatizam a correção, maior a chance de elas serem deixadas de lado. Da mesma forma, se a organização não prioriza as correções e atividades de segurança, o desenvolvedor vai resistir ou ignorar os pedidos das equipes de segurança para testar ou corrigir o código.

Responsabilização

A responsabilização é um dos pilares que justificam o trabalho de segurança por parte dos desenvolvedores, mas também importa a quem eles devem prestar contas. Por exemplo, é mais provável que um desenvolvedor se sinta motivado a realizar o trabalho se sua equipe, um security champion da equipe ou alguém na cadeia de gestão cobrar essa responsabilidade. Por outro lado, se apenas a equipe de segurança fizer essa cobrança, sem deixar claro o que pode acontecer caso o trabalho não seja feito, o desenvolvedor sentirá menos pressão para agir com segurança.

Falta de exemplos a seguir

As pessoas tendem a imitar o comportamento de quem está ao seu redor. Se não vemos outras pessoas desenvolvendo com segurança nem percebemos outras equipes priorizando a segurança em seus projetos, é fácil seguir o exemplo e ignorar as tarefas de segurança. Há algumas boas maneiras de combater isso, como dar visibilidade à segurança nas revisões de código, fazendo perguntas que exijam reflexão e atenção ao tema. Outra maneira é criar exemplos a seguir!

Valorize as pessoas por comportamentos que você quer ver com mais frequência na organização. Destaque as equipes que se sobressaíram ou avançaram na integração da segurança ao pipeline ou na redução do backlog de segurança. Faça com que as conquistas de segurança sejam valorizadas publicamente, reconhecidas pelas lideranças de engenharia e sirvam de exemplo para outras equipes por meio de documentação, automação e outras iniciativas.