SurveyMonkey conversa com a Snyk sobre segurança para desenvolvedores durante um crescimento acelerado

Muitas empresas recorrem a CISOs ou equipes de compliance para gerenciar a segurança em todo o ciclo de desenvolvimento de software. Mas essa prática costuma manter as questões de segurança separadas dos desenvolvedores. Os CISOs podem atribuir tarefas de segurança aos desenvolvedores, mas, se eles não pensarem em segurança com frequência, essas tarefas podem acabar esquecidas. Uma maneira de aproximar essas áreas é contar com uma liderança de engenharia de segurança (algo semelhante a um security champion) — alguém que defenda a segurança como parte do processo geral de engenharia.

Em uma recente mesa-redonda, Simon Maple, Field CTO da Snyk, conversou com Craik Pyke, diretor sênior de engenharia de segurança, cloud e DataStores da SurveyMonkey (hoje parte da Momentive). Eles falaram sobre o uso de ferramentas que oferecem visibilidade e sobre a criação de um caminho seguro e bem definido 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 a segurança a todo o processo de desenvolvimento. Confira os principais pontos da conversa.

Crie consistência e visibilidade

Quando Craik chegou à SurveyMonkey, a empresa usava uma arquitetura de microsserviços. Cada equipe era responsável por seus próprios serviços, do projeto à construção, implantação e suporte. Com isso, cada equipe fazia o que queria: todos adicionavam plugins aos próprios pipelines e usavam suas ferramentas preferidas. Isso dificultava o rastreamento. Não havia um controle claro de onde os desenvolvedores obtinham os containers nem de quantas dependências usavam. Nesse cenário, a maior preocupação de Craik era o gerenciamento de código aberto. Ele perguntou se havia uma maneira de acompanhar o uso de licenças ou gerar uma declaração de atribuição confiável. Mas, como tudo era gerenciado manualmente, a resposta geralmente era não.

[Os desenvolvedores diziam]: "Tenho 80 mil dependências nos meus projetos. Como posso saber o que estou incluindo? E preciso pesquisar todas essas licenças?" Foi aí que começamos: precisávamos ajudar os desenvolvedores a responder a essas perguntas — não obrigá-los a fazer algo só porque era uma questão de segurança.

Com sua experiência, Craik sabia que esse era o primeiro desafio a enfrentar: estabelecer visibilidade e implementar governança. Antes, ele havia trabalhado em uma empresa que lançava produtos rapidamente, mas a possibilidade de entender as versões dos pacotes e os riscos do código aberto só foi considerada quando um cliente pediu. Por isso, na SurveyMonkey, antes de pensar em visibilidade, ele priorizou a consistência. Precisava estabelecer uma cultura de DevOps, em que os desenvolvedores pudessem delegar a criação de um pipeline a um grupo específico, responsável por gerenciá-lo. Depois que a equipe comprou a ideia, foi fácil criar um único pipeline de build. Chegar ao artefato de build foi o primeiro passo. Logo, ele passou a buscar ferramentas que oferecessem visibilidade além do pipeline, sobre o que os desenvolvedores faziam em suas máquinas.

Ofereça ferramentas e dados melhores

Os desenvolvedores gostam de descobrir como as coisas funcionam — eles incluem o que for necessário para resolver um problema na própria máquina ou IDE. Craik queria definir e documentar o que os desenvolvedores incluíam durante a fase de prototipagem. Também queria oferecer ferramentas que reproduzissem o que acontecia no pipeline de build, na IDE ou na linha de comando.

Como podemos oferecer aos [desenvolvedores] ferramentas que funcionem da mesma forma na máquina deles e no pipeline de build? Identificar essas ferramentas e implantá-las... foi, na verdade, uma adoção fácil pelos desenvolvedores quando perceberam que elas reproduziam o pipeline. Consistência é fundamental.

Ele também queria oferecer dados de qualidade aos desenvolvedores. Por exemplo, facilitar a avaliação de um pacote para saber se ele é adequado a um projeto ou se é melhor buscar outra opção. A melhor maneira de fazer isso é com dados. Quando os desenvolvedores sabem que podem contar com algo como o Snyk Advisor e encontrar rapidamente métricas — como a popularidade de um pacote ou o problema mais recente relacionado a ele —, entendem melhor a complexidade. Craik afirma que esse foi um dos fatores decisivos em sua função atual: disponibilizar dados confiáveis para os desenvolvedores e, depois, confiar que farão as escolhas certas.

Crie um caminho seguro e bem definido

Em seguida, Craik começou a trabalhar em uma infraestrutura de build comum. Ele usou um repositório compartilhado de artefatos (no caso dele, o Artifactory, mas há várias opções). O principal objetivo era garantir que os desenvolvedores sempre baixassem artefatos do registro. Essa é uma etapa essencial em uma organização de crescimento acelerado, onde o aumento da equipe de desenvolvimento pode levar à expansão da infraestrutura — sem o devido controle. Mas Craik não queria que a equipe de segurança fosse um obstáculo. A orientação para os desenvolvedores era: “aponte seu arquivo de configuração preferido para este sistema de artefatos. Se o que você precisa não estiver aqui, o sistema fará o download para você. Ele vai ajudar.” No início, foi preciso defender a ideia para que os desenvolvedores fizessem a mudança. Mas, quando todos passaram a obter os artefatos por meio de um único cluster, a equipe ganhou visibilidade sobre o que estava sendo usado, onde e quando — incluindo as versões em uso.

A equipe de Craik permitia que os desenvolvedores trabalhassem fora do pipeline, mas, assim que tentavam enviar um PR, ele falhava. O pipeline de build que executa os testes a partir do GitHub não podia baixar conteúdo diretamente da internet; só podia acessar o repositório de artefatos da empresa. Portanto, se os desenvolvedores adotassem o comportamento esperado desde o início e usassem o repositório de artefatos, não haveria problema.

Como os desenvolvedores não viam a segurança como um obstáculo? Adotamos uma abordagem amigável. Usamos incentivos o tempo todo. Dizíamos: “ao usar o repositório único de artefatos, você não precisa se preocupar com pacotes maliciosos ou licenças inadequadas, porque podemos analisar tudo assim que chega. Podemos garantir que você não faça algo errado.” Assim, os desenvolvedores deixaram de ver a segurança como adversária e passaram a nos procurar para tirar dúvidas. Estamos aqui para ajudar, não para atrapalhar.

Security champions: uma iniciativa que nasce da equipe

Enquanto a equipe de Craik mantinha o caminho seguro e bem definido, alguns desenvolvedores da SurveyMonkey foram se tornando security champions. Os mais experientes ensinaram os novos membros da equipe sobre o repositório de artefatos, como identificar sinais nos PRs e a quem recorrer em caso de dúvidas. Craik chama isso de “uma ideia informal de colocar o suporte de primeiro nível dentro das equipes de desenvolvimento”. Ele não formalizou um programa de security champions, porque, à medida que as pessoas entravam na equipe, a segurança simplesmente se tornava um hábito aprendido.

Quando os desenvolvedores auditam a segurança do próprio código, a equipe de segurança pode atuar como facilitadora: pessoas que dão suporte aos desenvolvedores quando precisam de ajuda. Craik destaca que, com um caminho seguro e um conjunto de ferramentas adequados — incluindo as ferramentas da Snyk, que facilitam a detecção e a correção de vulnerabilidades —, a equipe de segurança pode iniciar novos builds dos artefatos, se necessário, sem precisar incomodar os desenvolvedores.

Os dados que obtemos com nossas ferramentas e nosso pipeline realmente permitem que os desenvolvedores tomem decisões bem fundamentadas.

Compartilhe responsabilidades e objetivos

Em uma cultura bem-sucedida de shift left, os desenvolvedores querem atender aos requisitos de segurança desde o início. A validação permite que concluam mais rapidamente o trabalho que gera receita. A equipe de segurança não procura os desenvolvedores para dizer “vocês precisam seguir estas etapas por causa da segurança”. Em vez disso, os desenvolvedores procuram a equipe de segurança e perguntam: “Encontrei um problema neste pacote. Posso continuar?” A equipe também busca compartilhar a responsabilidade: em vez de culpar alguém por uma vulnerabilidade que passou despercebida, corrige o problema o mais rápido possível e depois conversa sobre o que aprendeu com ele.

Dar suporte aos desenvolvedores também significa permitir que eles apoiem uns aos outros. Quando a equipe de Craik implementou a Snyk para verificar vulnerabilidades, não transformou isso em um bloqueio no GitHub. Em vez disso, permitiu que desenvolvedores mais experientes orientassem os mais novos durante as revisões de código e de PRs. Um desenvolvedor sênior poderia dizer: “Este X vermelho indica que há um problema. Sim, tecnicamente você ainda pode fazer o merge do código, mas é isto que está acontecendo agora.” Não houve imposição rígida desde o primeiro dia; em vez disso, a equipe construiu uma cultura colaborativa. A melhor abordagem foi implementar as ferramentas da Snyk no nível certo para as equipes da SurveyMonkey.

Assista à conversa completa para conferir mais insights sobre segurança para desenvolvedores.