Corrigindo meio milhão de vulnerabilidades de segurança

As hackathons são conhecidas entre equipes de desenvolvimento de software por impulsionar a inovação e a colaboração. Então, e se aplicássemos esse modelo à cibersegurança para melhorar a postura de segurança de aplicações de uma organização? Seria um sonho para qualquer CISO ou profissional de segurança — e foi exatamente isso que nos propusemos a fazer na Snyk em fevereiro de 2023.

Confira alguns dos momentos mais engraçados dos nossos painéis.

Nossa missão era corrigir 200 mil vulnerabilidades de segurança. Veja como tudo terminou.

Organizando um hackathon de correção de vulnerabilidades

O segredo para realizar um evento de sucesso é garantir que desenvolvedores e profissionais de segurança se divirtam enquanto aprendem novas habilidades que possam aplicar em projetos pessoais ou profissionais. Para isso, estabelecemos o seguinte:

1. Com suporte contínuo, os participantes da hackathon são convidados a se juntar a seus pares na comunidade Discord da Snyk para aprender sobre segurança e receber ajuda com as correções.

2. Uma transmissão ao vivo de 24 horas, que cumpriu nossa promessa de promover o aprendizado, foi um dos destaques do Big Fix deste ano. Fizemos a transmissão ao vivo de 24 horas mundial no YouTube e na Twitch, com palestrantes da Atlassian, Dynatrace, Morgan Stanley, The Linux Foundation, Sysdig, AWS, StackHawk e outras empresas.

3. Prêmios: Queríamos reconhecer o esforço de cada participante para criar softwares mais seguros. Por isso, todos que corrigiram pelo menos uma vulnerabilidade de segurança ganharam uma camiseta de edição limitada do The Big Fix ou um crédito de US$ 15 na OpenCollective, que podem usar para doar a projetos e mantenedores de código aberto.

4. Classificação: Para trazer um pouco de competição ao evento, criamos uma classificação com os participantes que mais corrigiram vulnerabilidades. Os três primeiros colocados receberam, respectivamente, um headset de realidade virtual (1º lugar), uma caixa de som sem fio (2º lugar) e um kit inicial Arduino (3º lugar).

Uma das melhores coisas da hackathon é que não era necessário ter experiência prévia em segurança de aplicações ou segurança na nuvem para participar e subir na classificação.

Isso foi possível graças à abordagem da Snyk que prioriza desenvolvedores, às integrações com um ecossistema amplo e aos recursos de correção automatizada, que ajudam você a encontrar e corrigir problemas de segurança com facilidade. Seja você desenvolvedor, profissional de DevOps, segurança ou garantia da qualidade, a Snyk oferece as ferramentas necessárias para começar.

Agora, mais do que nunca, é uma ótima oportunidade para começar a usar Snyk Code, Snyk Open Source, Snyk Container e Snyk Cloud.

Protegendo os softwares do mundo

Então, como foi o resultado? Agora que o The Big Fix chegou ao fim, vamos analisar os dados e conferir os resultados de um evento que capacita desenvolvedores a corrigir problemas de segurança.

Em um mês, os participantes do The Big Fix contribuíram com 597.589 correções de segurança em seus projetos de software, fossem eles de código aberto ou fechado. Mais de 1.800 pessoas se inscreveram no evento. Entre os participantes, havia mais de 120 funcionários da Snyk, mais de 220 clientes e mais de 1.480 engenheiros de diferentes empresas.

Analisamos mais a fundo o banco de dados da Snyk para determinar o impacto do evento na segurança dos projetos monitorados pela Snyk. Por isso, as métricas e análises a seguir abrangem todos os dados analíticos de produto coletados em atividades de contas registradas no evento — incluindo mais projetos e vulnerabilidades de segurança encontradas e corrigidas do que apenas os projetos adicionados à hackathon.

Imagens de contêiner são as mais propensas a vulnerabilidades, mas também as mais fáceis de corrigir.

Entre os milhões de vulnerabilidades de segurança detectadas em projetos de contêineres, código e infraestrutura monitorados pela Snyk, os projetos classificados como contêineres Docker tiveram uma taxa de correção de 73,3%. É razoável dizer que um dos principais motivos dessa alta taxa é o fato de o Snyk Container oferecer correções automatizadas por pull request e recomendações de imagem-base, sugerindo proativamente imagens de contêiner alternativas com menos vulnerabilidades.

As ações de segurança relacionadas a código e dependências apresentam uma taxa relativamente baixa de correções aplicadas. O Snyk Code encontrou mais de 82.160 possíveis vulnerabilidades de segurança no código, com uma taxa de correção de 10,2% pelos participantes. O Snyk Open Source, que detecta vulnerabilidades conhecidas publicamente em dependências de código aberto, teve uma taxa de correção de 14,4%. Como as correções de dependências são automatizadas por pull requests e os problemas de segurança no código são tratados no IDE com o mecanismo de recomendações da Snyk, milhares de vulnerabilidades de segurança foram mitigadas logo no início — e rapidamente — do processo de desenvolvimento.

Vamos analisar mais de perto o conjunto de dados dos projetos de imagens de contêiner. Os 10 principais projetos de contêineres Docker monitorados pela Snyk apresentam uma taxa extremamente alta de correção de problemas de segurança — o que reforça a afirmação anterior de que são muito mais fáceis e rápidos de corrigir. Distribuições-base do Ubuntu e imagens de contêiner, como ubuntu:rolling e imagens node, apresentam taxas de correção de problemas de segurança superiores a 90%.

De 13% a 30% das vulnerabilidades de segurança conhecidas publicamente são corrigidas antes e com mais rapidez

Ao analisar ecossistemas de linguagens específicos, também podemos observar as taxas de correção de segurança aplicadas a cada linguagem de programação. Esses dados podem ser distorcidos por vulnerabilidades encontradas em problemas de segurança de baixa importância, como os relatados em dependências de desenvolvimento. Outro motivo pode ser a existência de problemas de segurança impossíveis de corrigir em projetos de código sem manutenção. No geral, as vulnerabilidades de segurança relacionadas a dependências apresentam uma taxa de correção de aproximadamente 13% a 30%. Essas correções podem ser automatizadas para ajudar desenvolvedores de software a se concentrar na criação de aplicações, em vez de resolver problemas de segurança.

Código Go propenso a erros de codificação segura relacionados a negação de serviço, fluxo de controle e ponteiros

As principais vulnerabilidades corrigidas em Go mostram que os desenvolvedores estão dedicando tempo a mitigar erros de codificação segura relacionados ao fluxo de controle do programa, à negação de serviço e ao tratamento de ponteiros. Estas são as cinco principais vulnerabilidades de segurança corrigidas em projetos Go:

• CWE-400: Consumo descontrolado de recursos

• CWE-266: Atribuição incorreta de privilégios

• CWE-787: Gravação fora dos limites

• CWE-674: Recursão descontrolada

• CWE-476: Desreferência de ponteiro NULL

Projetos Python são mais vulneráveis a problemas de memória, validação de entrada e fluxo de controle do programa

Os principais tipos de vulnerabilidade em Python têm semelhanças com os encontrados em projetos Go, como consumo descontrolado de recursos, gravação fora dos limites e leitura fora dos limites. Entre outras vulnerabilidades comuns identificadas em bases de código Python estão:

• CWE-369: Divisão por zero

• CWE-617: Asserção alcançável

• CWE-1333: Complexidade ineficiente de expressões regulares

Bases de código Java e JavaScript compartilham os principais tipos de vulnerabilidade

Entre os 10 principais tipos de vulnerabilidade monitorados durante o The Big Fix, identificamos um conjunto de CWEs compartilhadas por bases de código Java e JavaScript:

• CWE-400: Consumo descontrolado de recursos

• CWE-94: Controle inadequado da geração de código ('injeção de código')

• CWE-22: Limitação inadequada do nome do caminho a um diretório restrito ('travessia de diretório')

• CWE-200: Exposição de informações confidenciais a um agente não autorizado

Ruby é mais vulnerável a negação de serviço, cross-site scripting e contrabando de solicitações HTTP

Ruby, mais conhecido pelo Ruby on Rails, é bastante associado ao desenvolvimento web. Por isso, não surpreende que suas cinco principais vulnerabilidades de segurança, também corrigidas durante o evento, envolvam riscos para aplicações web:

• CWE-1333: Complexidade ineficiente de expressões regulares

• CWE-400: Consumo descontrolado de recursos

• CWE-79: Neutralização inadequada de entrada durante a geração de páginas web ('cross-site scripting')

• CWE-444: Interpretação inconsistente de solicitações HTTP ('contrabando de solicitações/respostas HTTP')

• CWE-200: Exposição de informações confidenciais a um agente não autorizado

Na verdade, uma das principais vulnerabilidades encontradas e corrigidas pelos participantes é um problema de segurança menos conhecido: o contrabando de solicitações HTTP.

Vulnerabilidades de segurança mais fáceis de corrigir com testes estáticos de aplicações

Os testes estáticos de aplicações são uma abordagem que usa informações do código e fluxos de execução, como árvores de sintaxe abstrata, para identificar possíveis vulnerabilidades e práticas de codificação inseguras. Essa é uma ótima maneira de fornecer feedback antecipado aos desenvolvedores e apontar problemas de segurança enquanto escrevem o código — em vez de fazer isso mais tarde, quando os recursos já estão prontos.

O Snyk Code oferece informações de segurança integradas ao IDE e recomendações de correção que os desenvolvedores podem adotar com facilidade instalando a extensão para VS Code (também há suporte para IntelliJ e outros IDEs!). Brian Clark e Nate Michalov mostram como encontrar e corrigir problemas de segurança nesta sessão de programação ao vivo:

Play Video: How to Get Started with Snyk Code (feat. Nate Michalov) - The Big Fix 2022 by Snyk

Entre todos os problemas detectados pela ferramenta SAST do Snyk Code, estes foram os tipos de vulnerabilidade mais comuns:

• ​​CWE-94: Controle inadequado da geração de código ('injeção de código')

• CWE-79: Neutralização inadequada de entrada durante a geração de páginas web ('cross-site scripting')

• CWE-916: Uso de hash de senha com esforço computacional insuficiente

• CWE-798: Uso de credenciais codificadas diretamente

• CWE-352: Falsificação de solicitação entre sites (CSRF)

E agora?

Agradecemos a todos que participaram do The Big Fix deste ano e aproveitamos a oportunidade para convidar você para um dos nossos próximos eventos abertos ao público — onde poderá aprender mais sobre segurança de aplicações e conhecer outros profissionais de cibersegurança:

• Workshop CTF 101 (25 de maio de 2023): um workshop prático que ensina você a resolver desafios de capture the flag!

• Workshop de Hacking Ético (21 de junho de 2023): um workshop prático que ensina você a realizar hacking ético e divulgação responsável.

• DevSecCon (27 de junho de 2023): nossa conferência comunitária de destaque sobre tudo relacionado a DevSecOps.

Por fim, se você quiser se conectar com desenvolvedores e profissionais de segurança com interesses em comum, participe do Discord DevSecOps.