Entenda as equipes de desenvolvimento

A implementação de qualquer programa multifuncional exige empatia. A colaboração entre as equipes de segurança e desenvolvimento costuma fracassar porque suas perspectivas e seus objetivos são muito diferentes. Embora ambas possam querer alcançar o mesmo resultado — aplicações seguras —, os fluxos de trabalho preferidos e os critérios de sucesso podem ser bem distintos. Felizmente, a empatia pode promover o alinhamento.

Para conquistar uma adoção consistente e natural, é importante criar uma cultura colaborativa em que a equipe de segurança e as equipes de desenvolvimento falem a mesma língua e trabalhem juntas para alcançar objetivos comuns. A equipe de segurança não está mais ali para auditar e sobrecarregar as equipes de engenharia. Ela está ali para apoiar os engenheiros e ajudá-los a identificar e resolver problemas de segurança o mais cedo, rápido e eficazmente possível. As equipes de engenharia precisam ver a equipe de segurança como um grupo que as capacita a fazer isso e devem pedir ajuda quando esse não for o caso.

Ao implementar um programa moderno de AppSec, é fundamental que as pessoas que interagem com as equipes de desenvolvimento e as apoiam entendam claramente os problemas, atritos e frustrações que os desenvolvedores enfrentam hoje. Só depois de entender esses desafios é possível descobrir como integrar a segurança ao processo de desenvolvimento. Vamos explorar melhor os aspectos que vale a pena avaliar e considerar antes de iniciar novas colaborações. Confira algumas perguntas para fazer a si mesmo antes de começar a implementação.

"[A segurança] precisa ser uma parceria. Um dos principais motivos pelos quais temos tantas falhas de segurança é que tentamos ditar regras, em vez de construir uma parceria genuína com os grupos que queremos ajudar a ter sucesso. Meu papel é ajudar nossas equipes de engenharia na Mandiant a produzir código funcional, seguro e de qualidade com rapidez. Como empresa, precisamos agir rápido. A parceria é o que nos permite criar soluções que atendam às necessidades do negócio e da segurança."

Tim Crothers, vice-presidente sênior e diretor de segurança da Mandiant

Até que ponto você tem empatia e entende suas equipes de desenvolvimento?

É fundamental entender como suas equipes de desenvolvimento trabalham e tomam decisões. Ao compreender a abordagem geral e o nível de maturidade em desenvolvimento da equipe, você pode definir expectativas realistas sobre o que espera dela, determinar como e onde ela pode fazer mudanças e descobrir como oferecer o melhor suporte e capacitação. Sem isso, você não conseguirá entender o ponto de vista dessas equipes, o que gera atritos e reduz as chances de sucesso. Além disso, lembre-se de que as respostas às perguntas a seguir provavelmente variam entre as equipes da mesma unidade de negócios ou até do mesmo departamento. Evite fazer suposições sobre as equipes de desenvolvimento e considere as diferenças entre suas culturas e abordagens.

Qual é a disposição da equipe para mudar?

Algumas equipes de desenvolvimento gostam de experimentar as tecnologias mais recentes — às vezes até demais — e estão dispostas a testar novas ferramentas, tecnologias, bibliotecas, modelos de programação e muito mais, só para se manterem atualizadas ou descobrir se isso pode ser uma solução melhor. Outras só fazem esse tipo de mudança para resolver um problema existente ou quando têm certeza de que ela corrigirá algo que afeta a aplicação. Há ainda equipes que evitam mudanças por padrão, seguindo a filosofia de “em time que está ganhando não se mexe”.

Reconhecer o comportamento e a mentalidade das equipes de desenvolvimento em relação às mudanças ajuda a determinar a melhor forma de colaborar com elas para encontrar um objetivo comum para o programa de AppSec. Por exemplo, se elas já resistiram a testes em pull requests (PRs) do Git, não presuma que adicionar testes de segurança aos PRs terá um resultado diferente das tentativas anteriores.

Uma distinção importante ao avaliar a maturidade e a capacidade de adaptação das equipes de desenvolvimento é a adoção de tecnologia versus a adoção de processos. É comum que empresas menos maduras ou em estágio inicial priorizem a adoção de tecnologia em vez da padronização de processos. Por exemplo, startups precisam lançar produtos rapidamente para chegar primeiro ao mercado, deixando a maturidade de processos e padrões em segundo plano. Nessa fase, é bem difícil convencer uma empresa a implementar uma prática de segurança que funcione como bloqueio.

Quão bem definidos estão a equipe e os projetos?

Uma das principais diferenças entre as perspectivas de segurança e de desenvolvimento é a propriedade dos ativos. Do ponto de vista da equipe de segurança, há vários ativos sob a responsabilidade das equipes de engenharia, alguns mais críticos que outros. Já do ponto de vista dos desenvolvedores, cada equipe tem um foco e vários projetos ou serviços sob sua responsabilidade. Ela também pode contribuir para projetos de outras equipes e para projetos usados e dos quais muitas equipes dependem, mas que não têm uma equipe responsável claramente definida.

Por isso, o sucesso ao pedir que uma equipe de desenvolvimento se responsabilize pela segurança do próprio código e dos projetos varia conforme a propriedade de cada projeto. Quanto mais claramente definido for o escopo, maior a probabilidade de a equipe de desenvolvimento assumir a responsabilidade pela segurança daquele projeto.

Além disso, o tempo de existência da equipe também pode influenciar a implementação. O ideal é estabelecer padrões e processos desde o início para uma nova equipe. Mas, na prática, é mais provável aproveitar momentos naturais de mudança. Por exemplo, se uma equipe passar por uma grande mudança não relacionada ao seu programa (um novo gerente, uma reformulação da equipe etc.), será mais provável que ela adote novos padrões de desenvolvimento ao definir como quer trabalhar.

Qual é a capacidade atual da sua equipe?

Como a maioria das equipes, os desenvolvedores não ficam parados esperando o trabalho aparecer. Eles priorizam o que é mais importante fazer em seguida, sabendo muito bem que não conseguirão dar conta de tudo que se acumula na lista de tarefas. Simplesmente acrescentar mais tarefas à lista já lotada de um desenvolvedor ou de uma equipe não é construtivo nem ajuda. Isso é ainda mais problemático quando as equipes têm recursos insuficientes e se esforçam para concluir sprint após sprint, tentando não afundar.

"Sabemos que eles têm muitas outras responsabilidades. Precisam criar recursos e produtos. Também precisam se preocupar com desempenho e confiabilidade. Queremos tornar a participação em segurança o mais fácil possível."

Jason Chan, vice-presidente de Segurança da Netflix

Qual é a diversidade de habilidades entre as equipes da organização?

Vale a pena entender a dinâmica das equipes de desenvolvimento porque cada uma é diferente. É muito comum que um pequeno grupo de equipes de ponta adote primeiro novas tecnologias e processos, seguido pelas demais ao longo do tempo. A adoção pela maioria costuma começar devagar, mas ganha força quando há automações e boas práticas suficientes para facilitar a adoção por outras equipes. É claro que, para alcançar uma adoção ampla, muitas equipes precisarão de um caminho mais simples — e algumas levarão muito mais tempo para adotar, se é que vão adotar. Antes de incentivar a adoção entre os desenvolvedores, você precisa saber quantas equipes precisarão de um caminho mais simples e quais podem participar de projetos-piloto para criar automações e boas práticas.

Um exemplo da diversidade de habilidades entre as equipes são suas tendências em relação a integrações e ao recebimento de feedback. Em geral, equipes maduras querem receber feedback o mais cedo possível — no IDE, em automações nos processos locais de build e também nos repositórios Git. Equipes menos maduras talvez queiram automatizar apenas no processo de CI, recebendo feedback mais tarde, normalmente pouco antes da implantação em produção. Tentar incluir os dois tipos de equipe no mesmo grupo de implementações provavelmente não dará certo e pode sobrecarregar as equipes menos maduras.

A complexidade e a idade dos projetos são causas comuns das diferenças na adoção. Um serviço antigo e complexo, que está em manutenção em vez de receber desenvolvimento ativo, é um exemplo de projeto que talvez não seja adequado, pois é provável que haja mais resistência a mudanças nos processos. Da mesma forma, se sua organização cresceu por meio de aquisições, por exemplo, você herdará diferentes tecnologias, pipelines e culturas. Isso reduz a consistência em toda a organização e aumenta as chances de suas suposições sobre as equipes estarem erradas.

Como suas equipes de desenvolvimento integram práticas de segurança ao pipeline hoje?

Depois de avaliar as equipes de desenvolvimento da sua organização, é importante identificar quais práticas de segurança elas seguem hoje e como fazem isso, para definir um ponto de partida. Normalmente, as equipes começam com uma abordagem mais leve: talvez executem testes periodicamente apenas para ter visibilidade e os integrem ao pipeline quando possível. No início, provavelmente não haverá bloqueios nem etapas de aprovação, permitindo que a equipe continue lançando no ritmo a que está acostumada.

Em seguida, observe as preferências de integração. As equipes fazem verificações ou testes na CI ou mais cedo, nos PRs? Usam uma integração pronta ou criaram scripts e automações para adaptá-la ao pipeline ou projeto? Fazem testes nos IDEs ou adotam uma abordagem mais reativa? Uma equipe que prefere integrações tem mais chances de adotar uma solução integrada de segurança para desenvolvedores.

"Na minha opinião, o mais importante é entender as práticas preferidas das nossas equipes de engenharia. Quais são esses padrões? Assim, podemos colaborar para estabelecer diretrizes, em vez de impor controles. Queremos apoiar os resultados que as equipes buscam. Precisamos garantir que as práticas e os processos adequados sejam aqueles que elas definiram. E, normalmente, colaboramos nessa definição. Em resumo, estamos sempre procurando lacunas — nos processos e na nossa [colaboração]."

Tim Crothers, vice-presidente sênior e diretor de segurança da Mandiant

Como as equipes priorizam a segurança durante as sprints?

Outro bom indicador do estágio da jornada de segurança de uma equipe é saber se o foco está mais no desenvolvimento futuro ou no backlog. Muitas vezes, o backlog pode ser enorme, com milhares de problemas ou vulnerabilidades, enquanto um novo recurso talvez introduza apenas alguns. Também é importante entender como a equipe faz a triagem dos problemas para identificar o que é importante — ou necessário — corrigir, além de quando e como escalar. Se a equipe tiver OKRs relacionados ao backlog e processos que promovam avanços, será mais provável que adote ferramentas para chegar lá mais rápido.

Como a equipe incorpora testes e correções de segurança às sprints? Ela exige que os testes de segurança sejam aprovados para entregar código ou adiciona tarefas de segurança ao backlog de dívida técnica e dedica uma sprint a cada poucos meses para corrigir os problemas? A segunda opção é comum em equipes menos maduras e até em algumas equipes com desempenho abaixo do esperado, que não conseguem incluir esse trabalho nas sprints. Nesses casos, também é comum haver sprints dedicadas a escalabilidade, desempenho ou confiabilidade — todas disputando tempo com as sprints de segurança.

Por fim, a equipe tem alguma documentação interna sobre como faz os testes ou SLAs que segue para resolver os problemas? Essas são boas perguntas, que não só ajudam você a entender a situação atual da equipe, mas também indicam o próximo passo para facilitar os testes e ajudar todos a focarem no que realmente importa.