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

O uso seguro de bibliotecas de código aberto é uma prioridade constante das grandes organizações. Um dos maiores desafios é integrar as 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 funcionaria essa abordagem?

Simon Maple (diretor de tecnologia de campo da Snyk) conversou com Kalpesh Dharwadkar (engenheiro de segurança de produto do Pinterest) para saber como o Pinterest usa a Snyk na criação de práticas de segurança voltadas aos desenvolvedores.

Três grandes prioridades: visibilidade, verificação e triagem

O Pinterest usa muitos softwares de código aberto na pilha de desenvolvimento, por isso uma biblioteca de código aberto pode afetar seu perfil executivo. Antes a empresa usava um sistema específico para criar visualizações das bibliotecas de código aberto que usam auditoria NPM. Mas, quando foi contratado, Kalpesh queria criar um sistema centralizado para ter visibilidade de todas as bibliotecas de código aberto utilizadas. Sua equipe avaliou diversas soluções e escolheu a Snyk por dois motivos principais: os recursos voltados para desenvolvedores e o suporte a repositórios em linguagens específicas, como Bazel (a ferramenta de desenvolvimento escolhida). Kalpesh descreveu suas prioridades em segurança no início da conversa:

Para a segurança de código aberto no Pinterest, existem três focos principais: obter visibilidade das bibliotecas vulneráveis, criar ferramentas para toda a pilha em acréscimo à verificação em busca de correções e, por fim, realizar triagem das vulnerabilidades.

Kalpesh explicou que sua equipe usa o Jenkins nas builds. A empresa verifica o sistema da build Snyk CLI e depois carrega os resultados na interface da Web da Snyk. O primeiro objetivo é obter visibilidade de todas as dependências nos repositórios de código e priorizar a correção das vulnerabilidades. Para isso, a empresa considerou o Common Vulnerability Scoring System (CVSS), que oferece visibilidade de vulnerabilidades. Caso haja um exploit, as informações da Snyk são usadas para determinar se a correção tem alta prioridade.

Mais testes de segurança no pipeline

Depois disso, Simon perguntou sobre os testes durante o pipeline de desenvolvimento e quais foram os desafios de ensinar os desenvolvedores a usar a Snyk. Kalpesh tem uma solução simples para isso. Quando começou a inserir a Snyk no pipeline dos desenvolvedores, em vez de expor o console da Snyk à equipe, ele introduziu a verificação como uma etapa na build do Jenkins. Em seguida, começou a lidar com as correções mais simples por conta própria e pediu para os líderes em tecnologia ou proprietários de projetos revisarem seu trabalho. Isso fez com que eles se interessassem em aplicar as correções com as ferramentas da Snyk e aumentou a adesão.

Triagem eficaz, priorização de correções e contenção do Log4Shell

A conversa mudou para a triagem de vulnerabilidades. Simon perguntou “Que tipo de sinais de alerta você procura no backlog para informar aos desenvolvedores sobre as principais vulnerabilidades em que eles devem ficar de olho?”. A solução de Kalpesh é considerar a gravidade da vulnerabilidade, se o exploit é ativo ou não e se a vulnerabilidade está em um serviço exposto à internet. Esses são os parâmetros que ele usa para definir a prioridade das correções. Depois disso, um ticket é criado para alguém da equipe de desenvolvimento ou um responsável de serviço corrigir a vulnerabilidade. O rastreamento das informações no ticket ajuda a equipe de Kalpesh a compreender se a avaliação da vulnerabilidade está em linha com o que os desenvolvedores julgam ser importante.

O desenvolvedor é atribuído ao ticket. Ele pode responder dizendo que a equipe não usa o recurso específico que está vulnerável na dependência. Nesse caso, podemos tentar reduzir a prioridade do recurso.

Quando começaram a falar sobre Log4Shell, Simon perguntou a Kalpesh como o Pinterest lida com uma grande vulnerabilidade de dia zero. Kalpesh lembrou que, na manhã após o anúncio do Log4Shell, sua equipe declarou um incidente para descobrir quantos serviços haviam sido afetados. A equipe aplicou um sinalizador JVM (ou solução alternativa) disponível aos serviços em Java, mas ainda dependia dos proprietários de serviço para cuidar da implantação em todos os serviços, e isso leva tempo. A execução da solução alternativa levou todo o fim de semana, porque a equipe queria garantir que todos os serviços tinham sido implantados com o sinalizador JVM. Foram estabelecidos dois fluxos de trabalho: um para detectar todos os serviços em Java no Pinterest, e outro para detectar os serviços não abrangidos pela solução alternativa do sinalizador JVM. Para os serviços em que a flag de JVM não era suficiente, uma atualização foi a única maneira de mitigar a ameaça. Kalpesh comentou ainda que uma lição importante do Log4Shell foi ter um único painel mostrando tudo que estava sendo executado no modo de produção.

Verificações automatizadas para seguir com o desenvolvimento

Falando novamente sobre o uso da Snyk, Simon perguntou o quanto a Snyk reduziu os esforços manuais do Pinterest com autoatendimento para desenvolvedores e o nível de visibilidade que a equipe tem dos pipelines de desenvolvimento.

No Pinterest, usamos monorepos específicos de linguagem. Quando um monorepo é adicionado à Snyk, todo projeto novo criado nesse repositório é inserido automaticamente. Dessa forma, não é preciso fazer mais nada quando um novo projeto passa a fazer parte do repositório. Quando o código é mesclado ao repositório e a Snyk faz a verificação, entendemos quais dependências foram introduzidas. \[Quando um desenvolvedor cria um projeto no monorepo, a verificação é] transparente para o desenvolvedor. Eles nem precisam saber que a Snyk está em execução.

Com essa configuração, sempre que um desenvolvedor cria um projeto, a verificação e o envio à IU da Snyk ocorrem de modo automático, permitindo que a equipe de Kalpesh tenha uma visibilidade completa.

Simon argumenta que os desenvolvedores geralmente querem permanecer no seu próprio fluxo de trabalho em vez de usar outras ferramentas. Ele perguntou a Kalpesh “Como vocês organizam tudo para que os desenvolvedores não precisem sair dos pipelines?”.

Kalpesh concordou que os desenvolvedores gostam de “ficar nos seus tickets” e, ainda assim, querem ficar a par de tudo. Ele mencionou o hub de conhecimento da Snyk, que contém recursos educacionais para desenvolvedores. Kalpesh disse que ter esse currículo o fez pensar em oferecer aos desenvolvedores mais acesso ao console da Web da Snyk, ou possivelmente adicionar um link para informações relevantes do Snyk Learn no ticket do Jira para dar mais contexto sobre vulnerabilidades como XSS ou injeção de SQL. É uma maneira útil de incentivar a equipe a ampliar o conhecimento em segurança.

Como manter os desenvolvedores onde se sentem mais à vontade

De maneira geral, Kalpesh e sua equipe no Pinterest valorizam fluxos de trabalho com foco nos desenvolvedores e ênfase na triagem para impedir que fiquem sobrecarregados. Ele relembra que, quando iniciaram a integração com a Snyk, a equipe detectou um inúmeras vulnerabilidades nas dependências e que era importante exibir apenas as que tivessem alta prioridade para a empresa. A capacidade de automatizar as verificações e visualizar os resultados com a Snyk, sem obrigar os desenvolvedores a abrir mão de suas ferramentas preferidas, ajuda o Pinterest a seguir com o desenvolvimento de forma fluida.

Os desenvolvedores querem saber qual é o problema, como corrigi-lo e qual é a prioridade. Se você conseguir especificar esses detalhes no ticket, será meio caminho andado.