SurveyMonkey conversa com Snyk sobre a segurança dos desenvolvedores durante período de hipercrescimento

Muitas empresas esperam que o diretor de segurança das informações (CISO) ou que as equipes de conformidade gerenciem a segurança durante todo o processo de desenvolvimento de um software. Essa prática, no entanto, costuma afastar os desenvolvedores das considerações sobre segurança. Os CISOs podem atribuir tarefas de segurança aos desenvolvedores, mas se estes não pensarem em segurança regularmente, as tarefas podem ser esquecidas. Uma maneira de fechar essa lacuna é incluir um líder de engenharia de segurança (similar a um defensor da segurança), alguém que incentive a segurança como parte do processo global de engenharia.

Em um encontro recente, Simon Maple, diretor de tecnologia de campo da Snyk, conversou com Craik Pyke, diretor sênior de engenharia de segurança, nuvem e armazenamento de dados da SurveyMonkey (agora parte da Momentive). Eles abordaram o uso de ferramentas que fornecem visibilidade e a criação de uma estratégia de caminho mais simples para incentivar os desenvolvedores a priorizar a segurança em organizações de crescimento acelerado. A SurveyMonkey usa Snyk Open Source, Snyk Container e Snyk Code para integrar segurança ao processo de desenvolvimento. Confira a seguir um resumo dos assuntos discutidos.

Criar consistência e visibilidade

Quando Craik começou a trabalhar na SurveyMonkey, a empresa usava uma arquitetura de microsserviços. Cada equipe era responsável pelos seus próprios serviços, como design, criação, implantação e suporte. Com isso, as equipes faziam o que bem entendiam, e cada pessoa adicionava plug-ins aos próprios pipelines e usava suas ferramentas preferidas. Isso gerou uma dificuldade de rastreamento. Não havia um rastreamento claro de onde os desenvolvedores recebiam os contêineres nem de quantas dependências eles tinham. Nesse ambiente, a maior preocupação de Craik era o gerenciamento do código aberto. Ele perguntou se havia alguma forma de rastrear o uso das licenças ou de produzir uma declaração de atribuição confiável. Mas, como tudo era gerenciado de forma manual, a resposta geralmente era negativa.

\[Os desenvolvedores diziam] "Tenho 80.000 dependências nos meus projetos. Como faço para saber de onde estou fazendo pull? Preciso consultar todas essas licenças?” Esse foi o ponto de partida: precisávamos ajudar os desenvolvedores a responder às perguntas e não forçá-los a tomar determinadas ações só porque se referiam à segurança.

Por experiência, Craik sabia que primeiro o primeiro desafio era gerar visibilidade e adicionar governança. Ele havia trabalhado em uma empresa que lançava produtos com rapidez, mas a noção de poder entender as versões dos pacotes e os riscos de código aberto envolvidos só eram abordados quando um cliente solicitava. Por isso, na SurveyMonkey, ele pensou em consistência antes de pensar em visibilidade. Ele precisava estabelecer uma cultura de DevOps, em que os desenvolvedores podiam transferir o trabalho de criar um pipeline a um grupo designado que pudesse gerenciá-lo. Depois de deixar as pessoas interessadas nessa ideia, foi fácil criar um pipeline simples para o processo de desenvolvimento. O primeiro objetivo foi materializar esse artefato de criação. Em pouco tempo, ele passou a considerar o desenvolvimento de ferramentas como forma de obter visibilidade além do pipeline e saber o que os desenvolvedores faziam nas suas máquinas.

Fornecer ferramentas e dados melhores

Os desenvolvedores gostam de desvendar mistérios. Eles fazem o que for necessário para resolver um problema em sua própria máquina ou no seu IDE. Craik queria articular e definir o que os desenvolvedores faziam durante a fase de prototipagem. Sua intenção era que eles tivessem ferramentas que refletissem as ações no pipeline de criação e no IDE ou linha de comando.

Como podemos oferecer \[aos desenvolvedores] boas ferramentas que funcionem da mesma forma nas máquinas deles e no pipeline de criação? Identificar e implementar isso, na verdade, era uma tarefa fácil para os desenvolvedores depois que eles perceberam que o processo refletia o pipeline. Consistência é tudo.

Ele também queria que os desenvolvedores tivessem dados de qualidade, para permitir, por exemplo, que eles determinassem com facilidade se um pacote era viável para um projeto ou se era preciso usar outro. A melhor maneira de fazer isso é com dados. Quando os desenvolvedores descobrem que um recurso como o Snyk Advisor existe e disponibiliza métricas com praticidade, como a popularidade de um pacote ou qual foi seu problema mais recente, eles entendem a complexidade. Craik disse que um dos fatores decisivos no seu cargo atual foi colocar dados confiáveis nas mãos dos desenvolvedores e permitir que eles fizessem as escolhas corretas.

Uma estratégia de caminho mais simples

Depois disso, Craik começou a trabalhar em uma infraestrutura comum de desenvolvimento. Ele usou um repositório de artefatos comuns (Artifactory, mas existem outras opções disponíveis). O principal objetivo era fazer com que os desenvolvedores sempre extraíssem os artefatos do registro. Essa é uma etapa vital em uma organização de crescimento acelerado, em que uma equipe de desenvolvedores em expansão pode indicar uma infraestrutura também em expansão (e ainda sem regulação). Mas Craik não queria que a equipe de segurança agisse como um bloqueio. Ele dizia aos desenvolvedores: “Aponte o arquivo de configuração da sua preferência para o sistema de artefato. Se o sistema não tiver o que você busca, ele obtém para você. Ele ajuda.” No início, foi preciso convencer os desenvolvedores a aceitar a mudança. Mas, depois que a equipe passou a obter os artefatos de um único cluster, todo mundo passou ganhou visibilidade para saber o que estava acontecendo, onde e quando, e quais versões eram executadas.

A equipe de Craik permitiu que os desenvolvedores trabalhassem fora de seus pipelines, mas as tentativas de enviar uma solicitação de pull geravam uma falha. O pipeline de desenvolvimento que faz os testes do GitHub não podia fazer solicitações de pull diretamente da internet, apenas do repositório de artefatos. Então, se os desenvolvedores haviam adotado o comportamento esperado desde cedo e estavam usando o armazenamento de artefatos, não havia problema.

Como os desenvolvedores não viram a segurança como um bloqueio? Fizemos isso com uma abordagem amigável. Usamos recompensas ao longo do caminho. Dissemos “ao acessar o repositório único de artefatos, você não precisa se preocupar com pacotes maliciosos ou licenças incorretas, porque podemos verificar o conteúdo recebido. Podemos ter certeza de que você não está fazendo nada errado.” Assim, os desenvolvedores mudaram a noção sobre a equipe de segurança, que deixou de ser adversária para ser uma equipe de perguntas e respostas. Estamos na empresa para ajudar, não para complicar.

Defensores da segurança: uma questão básica

Com a equipe de Craik mantendo a estratégia de caminho mais simples, alguns desenvolvedores da SurveyMonkey gradualmente se tornaram defensores da segurança. Os mais experientes ensinavam aos novatos sobre o repositório de artefatos, como encontrar sinais em solicitações de pull e onde tirar dúvidas. Craik chamou isso de “uma noção isolada de inserir suporte de primeiro nível nas equipes de desenvolvedores”. Ele não criou formalmente um programa de defensores porque, à medida que novas pessoas ingressavam na equipe, o foco em segurança se tornou um comportamento adquirido.

Quando os desenvolvedores são auditores de segurança de seus próprios códigos, a equipe de segurança pode trabalhar na capacitação, prestando suporte quando necessário. Craik menciona que, com uma boa estratégia de caminho mais simples e um conjunto de ferramentas (incluindo as da Snyk) para facilitar a detecção e correção de vulnerabilidades, a equipe de segurança pode acionar novas versões dos artefatos quando necessário sem incomodar os desenvolvedores.

Os dados que recebemos das ferramentas e do pipeline permitem que os desenvolvedores façam escolhas inteligentes.

Compartilhar responsabilidades e metas

Na cultura que implantamos, os desenvolvedores querem abordar os requisitos de segurança desde o início. A validação permite que eles trabalhem com mais rapidez para concluir tarefas que geram receita. A equipe de segurança não precisa estipular os passos que os desenvolvedores devem seguir para manter a segurança. Os desenvolvedores é que procuram a equipe de segurança para dizer que encontraram um problema em um pacote e perguntar se podem prosseguir. A equipe também se esforça para compartilhar a responsabilização: em vez de encontrar um culpado pela vulnerabilidade que pode ter se infiltrado, eles corrigem o problema o mais depressa possível e depois as lições aprendidas.

Oferecer suporte aos desenvolvedores também significa permitir que eles apoiem uns aos outros. Quando a equipe de Craik introduziu a Snyk para a verificação de vulnerabilidades, eles não a defiram como bloqueadora no GitHub. Eles permitiram que os desenvolvedores mais experientes ensinassem os mais novos durante as revisões de código e solicitação de pull. Um desenvolvedor sênior podia dizer: “Este X vermelho indica que você tem um problema. Sim, tecnicamente você ainda pode mesclar o código, mas é isso que está acontecendo”. Não houve uma pressão para adotar essa prática desde o primeiro dia. Eles que criaram uma cultura de colaboração. A maior adoção das ferramentas da Snyk no nível certo para as equipes da SurveyMonkey foi a melhor abordagem.

Assista à conversa na íntegra para obter mais insights.