Como aprimorar a experiência dos desenvolvedores com ferramentas de segurança no Pinterest

Usar bibliotecas de código aberto com segurança é uma prioridade constante em grandes organizações. Um dos principais desafios é integrar ferramentas de segurança ao fluxo de trabalho dos desenvolvedores — e criar um sistema que priorize a correção de vulnerabilidades — sem sobrecarregá-los. Mas como é uma abordagem bem-sucedida?

Nosso Simon Maple (CTO de campo da Snyk) conversou com Kalpesh Dharwadkar (engenheiro de segurança de produtos no Pinterest) para entender como o Pinterest usa a Snyk para criar práticas de segurança que funcionam para desenvolvedores.

Três grandes prioridades: visibilidade, varredura e triagem

O Pinterest usa muitos softwares de código aberto em sua stack de desenvolvimento, então uma biblioteca vulnerável pode, sem dúvida, afetar sua reputação junto à liderança. Antes da chegada de Kalpesh à empresa, a equipe usava um sistema improvisado para criar visualizações das bibliotecas de código aberto com o NPM audit. Ao entrar, Kalpesh quis implementar um sistema centralizado que oferecesse visibilidade de todas as bibliotecas de código aberto em uso. A equipe avaliou várias soluções e escolheu a Snyk por dois motivos principais: os recursos pensados para desenvolvedores e o suporte a repositórios específicos de cada linguagem, como o Bazel (a ferramenta de build escolhida pela equipe). No início da conversa, Kalpesh descreveu suas principais prioridades de segurança:

Para proteger o código aberto no Pinterest, temos três focos principais: ter visibilidade das bibliotecas vulneráveis, contar com ferramentas em toda a stack, além da análise para encontrar correções, e, por fim, fazer a triagem das vulnerabilidades.

Kalpesh explicou que a equipe usa o Jenkins para os builds. Eles analisam o sistema de build com a Snyk CLI e enviam os resultados para a interface web da Snyk. O primeiro objetivo é ter visibilidade de todas as dependências nos repositórios de código e priorizar a correção das vulnerabilidades. Por isso, avaliaram o Sistema Comum de Pontuação de Vulnerabilidades (CVSS), que oferece visibilidade sobre elas. Quando há uma exploração conhecida, usam as informações da Snyk para determinar se a correção deve ser tratada como prioridade.

Inclua testes de segurança em todo o pipeline

Em seguida, Simon perguntou sobre os testes ao longo do pipeline de desenvolvimento e os desafios de ensinar os desenvolvedores a usar a Snyk. Kalpesh tem uma solução simples para essa etapa. Quando começou a introduzir a Snyk no pipeline de desenvolvimento, em vez de mostrar o console da Snyk aos desenvolvedores, configurou a análise como uma etapa do build no Jenkins. Depois, começou a resolver alguns dos problemas mais simples por conta própria e pediu a revisão do trabalho a líderes técnicos ou responsáveis pelos projetos. Isso despertou o interesse da equipe em aplicar correções com as ferramentas da Snyk e ajudou a conquistar mais apoio.

Como fazer a triagem com eficiência, priorizar correções e lidar com o Log4Shell

A conversa passou para a triagem de vulnerabilidades. Simon perguntou: “Que sinais ou alertas você procura no backlog para dizer aos desenvolvedores ‘estas são as cinco principais vulnerabilidades’ que precisam ser avaliadas?” Kalpesh leva em conta a gravidade da vulnerabilidade, se há uma exploração ativa e se ela afeta um serviço exposto à internet. Esses critérios definem a prioridade das correções. Em seguida, a equipe cria um ticket para que um desenvolvedor ou responsável pelo serviço corrija a vulnerabilidade. As informações registradas no ticket ajudam a equipe a entender se a avaliação de prioridade está alinhada com o que os desenvolvedores consideram importante.

O ticket é atribuído ao desenvolvedor. Ele pode voltar e dizer: ‘Olha, não usamos esse recurso específico da dependência que está vulnerável’. Nesse caso, tentamos reduzir a prioridade desse recurso.

Quando a conversa chegou ao Log4Shell, Simon perguntou a Kalpesh como o Pinterest lida com uma grande vulnerabilidade de dia zero. Kalpesh lembrou que, na manhã seguinte ao anúncio do Log4Shell, sua equipe declarou um incidente para investigar quantos serviços haviam sido afetados. Havia uma flag da JVM (ou solução alternativa), que foi aplicada aos serviços Java. Mas a equipe dependia dos responsáveis pelos serviços para fazer a implantação em todos eles — e isso leva tempo. A implantação da solução alternativa se estendeu até o fim de semana, pois a equipe queria garantir que todos os serviços estivessem usando a flag da JVM. Eles organizaram o trabalho em duas frentes: uma para identificar todos os serviços Java no Pinterest e outra para detectar os serviços que não estariam protegidos pela solução alternativa com a flag da JVM. Nos serviços em que a flag não era suficiente, a única forma de mitigar a ameaça era aplicar uma atualização. Kalpesh acrescentou que uma lição importante do Log4Shell foi manter um painel único que mostrasse tudo o que está em execução na produção.

Automatize as análises para manter o desenvolvimento avançando

Voltando ao uso da Snyk no Pinterest, Simon perguntou quanto a Snyk reduziu o trabalho manual ao permitir que os desenvolvedores resolvessem questões por conta própria e quanta visibilidade a equipe tem dos pipelines de desenvolvimento.

No Pinterest, usamos monorepos específicos para cada linguagem. Depois que você adiciona um monorepo à Snyk, todo projeto novo criado nesse repositório é adicionado automaticamente. Assim, não é preciso fazer nada a mais quando um projeto é criado. Quando o código é mesclado ao repositório e a análise da Snyk é executada, conseguimos saber quais dependências foram incluídas. [Quando um desenvolvedor cria um projeto no monorepo, a análise é] transparente para ele. Nem é preciso saber que a Snyk está em execução.

Com essa configuração, sempre que um desenvolvedor cria um projeto, ele é analisado automaticamente e enviado à interface da Snyk — permitindo que a equipe de Kalpesh tenha uma visão geral de tudo.

Simon observa que, em geral, os desenvolvedores preferem continuar no próprio fluxo de trabalho em vez de recorrer a outras ferramentas. Ele perguntou a Kalpesh: “Como vocês configuram tudo para que os desenvolvedores possam continuar nos próprios pipelines?”

Kalpesh concordou que os desenvolvedores gostam de “continuar nos próprios tickets” e, ao mesmo tempo, ter acesso a todas as informações necessárias. Ele mencionou o hub de aprendizado da Snyk, que reúne recursos educacionais para desenvolvedores. Kalpesh disse que o acesso a esse conteúdo o fez considerar mostrar mais do console web da Snyk aos desenvolvedores ou talvez incluir no ticket do JIRA um link para informações relevantes do Snyk Learn, dando mais contexto sobre vulnerabilidades como XSS ou injeção de SQL. É uma boa maneira de incentivar os desenvolvedores a ampliar seus conhecimentos de segurança.

Deixe os desenvolvedores trabalharem onde preferem

No geral, Kalpesh e sua equipe no Pinterest valorizam um fluxo de trabalho pensado para desenvolvedores, com ênfase na triagem para evitar que eles fiquem sobrecarregados. Ele observa que, quando integraram a Snyk, identificaram um grande número de vulnerabilidades nas dependências. Por isso, era importante destacar apenas aquelas que eram prioridade para o negócio. Automatizar as análises e consultar os resultados na Snyk, permitindo que os desenvolvedores continuem usando as ferramentas de sua preferência, ajuda o Pinterest a manter o desenvolvimento fluindo.

Os desenvolvedores querem saber: qual é o problema, como corrigi-lo e qual é a prioridade. Se você incluir essas informações no ticket do desenvolvedor, está tudo certo.