Mantenedores de código aberto querem segurança, mas 70% não têm as habilidades necessárias
26 de fevereiro de 2019
0 minutos de leituraBoas-vindas ao relatório anual da Snyk sobre o estado da segurança do código aberto de 2019. Este relatório está dividido em várias publicações:
Pacotes do Maven Central dobram; um quarto de milhão de novos pacotes são indexados no npm
Aumento de 88% nas vulnerabilidades de bibliotecas de aplicações em dois anos
Mantenedores de código aberto querem segurança, mas 70% não têm as habilidades necessárias
As dez imagens Docker mais populares contêm pelo menos 30 vulnerabilidades cada
Vulnerabilidades ReDoS no npm aumentam 143%, e os casos de XSS continuam crescendo
Ou baixe nosso belo relatório em PDF, feito à mão, que reúne todas essas informações e muito mais em um só lugar.
Baixe o relatório State of Open Source Security 2019
A postura de segurança dos mantenedores de código aberto
A maioria dos desenvolvedores e mantenedores provavelmente concorda que a segurança deve ter um papel importante na criação de produtos e na escrita de código. No entanto, não há regras estabelecidas que os mantenedores devam seguir ao criar projetos de código aberto. Por isso, os padrões de segurança podem variar bastante.
Os mantenedores dedicam tempo e esforço a diferentes aspectos do projeto, muitas vezes funcionais, o que pode fazer com que a segurança tenha menos prioridade no processo.
Desde nosso relatório anterior, publicado em 2017, há uma tendência positiva de maior engajamento e conscientização sobre segurança.
Mantenedores de código aberto afirmam que seus conhecimentos de segurança estão melhorando, mas ainda não são suficientes: a média é 6,6/10
Neste ano, a maioria dos usuários classificou seus conhecimentos de segurança como medianos, com média de 6,6 em dez. Uma pequena parcela (7%) avaliou seus conhecimentos como baixos. Já a proporção com conhecimentos medianos, que representa a maioria dos usuários, caiu para 63%, ante 56% no ano passado.
As maiores mudanças ocorreram nas classificações de conhecimentos baixos e altos. No ano passado, apenas 17% avaliaram seus conhecimentos de segurança como altos; neste ano, esse número subiu para quase 30%. Também houve uma redução semelhante entre os que avaliaram seus conhecimentos como baixos: eram 26% no ano passado, mas apenas 7% neste ano.
70% dos mantenedores de código aberto afirmaram não ter conhecimentos sólidos de segurança
Auditorias de segurança
Uma auditoria de segurança pode fazer parte de uma revisão de código, na qual colegas verificam se as boas práticas de programação segura estão sendo seguidas. Também pode envolver diferentes tipos de teste de segurança de aplicações, como testes estáticos ou dinâmicos. Sejam manuais ou automatizadas, as auditorias são essenciais para detectar e reduzir vulnerabilidades na sua aplicação. Elas devem ser realizadas com regularidade e o mais cedo possível durante o desenvolvimento, para reduzir os riscos de exposição e vazamento de dados em etapas posteriores.
Um em cada quatro mantenedores de código aberto não audita suas bases de código
No ano passado, 44% dos entrevistados afirmaram nunca ter feito uma auditoria de segurança. Neste ano, o número caiu bastante: 26% disseram não auditar o código-fonte. Em comparação com o relatório anterior, observamos uma tendência positiva de auditorias recorrentes neste ano, com um aumento médio de 10% no número de usuários que auditam o código-fonte com mais frequência, tanto trimestral quanto anualmente.
Profissionais de segurança costumam defender a abordagem shift-left para tratar questões e possíveis problemas de segurança mais cedo no ciclo de vida das aplicações. Com a automação, essa abordagem pode revelar informações valiosas para os desenvolvedores e ajudar as equipes de segurança a acompanhar o ritmo acelerado do desenvolvimento moderno e contínuo.
Antecipar a segurança, especialmente, é fundamental — e às vezes até essencial — para reduzir o custo de incidentes detectados somente em produção. Uma forma de abordar a segurança mais cedo e aumentar as chances de os desenvolvedores adotarem essas práticas é escolher ferramentas fáceis de usar para quem desenvolve e que se integrem aos fluxos de trabalho existentes.
Como os mantenedores ficam sabendo das vulnerabilidades?
É mais provável que os mantenedores sejam alertados sobre um problema de segurança do que o descubram por conta própria. Uma boa prática reconhecida pelo setor é ter uma política de divulgação responsável, que explique como pesquisadores de segurança e outras pessoas devem comunicar vulnerabilidades aos mantenedores do projeto com segurança.
Com base nos dados da pesquisa, podemos concluir que quase metade (48%) dos entrevistados fica sabendo de uma vulnerabilidade no próprio código por um canal público, por exemplo, quando alguém abre uma issue pública ou entra em contato por e-mail.
72% dos usuários disseram que descobrem vulnerabilidades no código ao revisar o próprio código. No entanto, 62% afirmaram ter conhecimentos medianos de segurança, enquanto apenas 30% dizem ter alto nível de especialização na área.
Além disso, embora a maioria dos usuários (72%) diga que revisa o próprio código para encontrar vulnerabilidades, 48% ainda só ficam sabendo delas quando outra pessoa abre uma issue pública. Isso mostra como é difícil depender da revisão de código de apenas um mantenedor, mesmo quando se acredita que ele tenha bons conhecimentos de segurança.
Da inclusão à divulgação
Uma das perguntas da pesquisa era: quanto tempo leva desde que uma vulnerabilidade entra na base de código até ser descoberta e divulgada? Para responder, analisamos algumas das principais bibliotecas do ecossistema npm e as vulnerabilidades descobertas nelas durante 2018.
Como essa análise leva mais tempo e é difícil de automatizar com precisão, examinamos as seis principais bibliotecas do npm e suas bases de código para comparar as datas dos commits que introduziram e corrigiram as vulnerabilidades. É claro que esses cálculos têm um certo viés, pois usamos uma amostra pequena, mas a faixa e a ordem dos números ainda são interessantes!
Entre essas sete bibliotecas, o menor tempo entre a inclusão e a correção foi de quase um ano — 289 dias, para ser exato. O tempo mediano foi de quase 2,5 anos, e o pior caso observado foi de 5,9 anos.
Em destaque: Equifax, um ano depois
Um relatório recente do governo dos EUA considerou totalmente evitável o famoso vazamento de dados da Equifax e mostrou como é importante antecipar a segurança, integrando-a ao fluxo de trabalho de desenvolvimento.
Com uma mentalidade DevSecOps e boas práticas, uma equipe de desenvolvimento poderia ter evitado que a vulnerabilidade do Struts causasse tanto impacto se:
os desenvolvedores tivessem identificado o problema usando ferramentas de análise de dependências de código aberto integradas ao fluxo de trabalho por meio de plugins para IDEs ou linters de código.
cada nova compilação executada por um servidor de CI testasse automaticamente as dependências da aplicação por meio de um plugin do servidor de CI ou da execução de um comando de CLI como tarefa. Isso teria sinalizado imediatamente a nova vulnerabilidade, interrompido o job de CI e exigido sua correção antes de prosseguir.
houvesse uma solução de monitoramento para notificar os desenvolvedores sobre novas vulnerabilidades nas dependências.
Mais monitoramento e informações em tempo de execução sobre o comportamento da aplicação e as funções vulneráveis que ela aciona poderiam ter alertado sobre as vulnerabilidades na biblioteca Struts.
Lançamento de correções
Um aspecto essencial da divulgação responsável de vulnerabilidades é a rapidez para corrigir e distribuir a solução. É importante resolver o problema o mais rápido possível, reduzindo o tempo em que ele permanece no código e dando aos usuários tempo suficiente para atualizar para uma versão corrigida — de preferência, antes que o problema se torne de conhecimento público.
Como as comunidades de código aberto dependem principalmente do trabalho voluntário dos desenvolvedores (um MUITO OBRIGADO a todas as pessoas incríveis que contribuem com software de código aberto — seu trabalho generoso é muito valioso, embora raramente seja reconhecido ou valorizado publicamente!), é interessante avaliar a rapidez com que os mantenedores conseguem reagir a uma vulnerabilidade e disponibilizar uma correção.
Uma expressiva maioria dos usuários, 84%, afirma que provavelmente lançaria uma correção em menos de uma semana. 56% provavelmente resolveriam o problema em até um dia, enquanto 22% dizem que conseguiriam corrigir uma falha de segurança em poucas horas após a notificação — nem todo herói usa capa!
Ritmo de correção
Ao analisar o Snyk Vulnerability Database, podemos identificar quais pacotes lançaram versões com correções de vulnerabilidades. O cenário não é dos melhores em alguns ecossistemas — estamos de olho em você, JavaScript! Java e Python têm ecossistemas bastante atentos às vulnerabilidades de segurança, enquanto JavaScript e Node.js, de modo geral, mostram que apenas 59% dos pacotes têm correções conhecidas para vulnerabilidades divulgadas.
Em destaque: divulgação responsável de vulnerabilidades
Uma grande vantagem de ter uma política de divulgação responsável é proteger os usuários. Quando uma vulnerabilidade é comunicada e avaliada de forma confidencial com o mantenedor do projeto, ele pode preparar uma correção antes que as informações sejam divulgadas ao público. Se os mantenedores agirem rapidamente e lançarem uma correção, os usuários terão um período para atualizar para a versão corrigida. Esse intervalo reduz bastante o número de pessoas que usam versões vulneráveis.
Acreditamos que uma política de divulgação responsável também comunica o forte compromisso do mantenedor com a segurança. Recomendamos incluir um selo na página inicial do projeto e adicionar um arquivo de política SECURITY.MD ao repositório como boas práticas.
No relatório anterior, descobrimos que os mantenedores com uma política pública de divulgação têm muito mais chances de receber relatos confidenciais de usuários do que aqueles sem essa política.
Cerca de 21% dos mantenedores sem uma política pública de divulgação receberam notificações privadas sobre vulnerabilidades, em comparação com 73% dos que têm uma política desse tipo.
Sites estão sujeitos a vulnerabilidades de segurança na web e se beneficiam de diretrizes claras sobre políticas de segurança. Uma proposta recente que pode ajudar é o SECURITY.TXT (RFC 5785), que já começa a ser adotado. O objetivo desse arquivo de política é informar aos pesquisadores de segurança os contatos relevantes, os idiomas preferidos, a política específica e as formas de comunicação, incluindo chaves públicas para divulgar vulnerabilidades de maneira segura e eficiente.
Continue lendo:
Pacotes do Maven Central dobram; um quarto de milhão de novos pacotes são indexados no npm
Aumento de 88% nas vulnerabilidades de bibliotecas de aplicações em dois anos
Mantenedores de código aberto querem segurança, mas 70% não têm as habilidades necessárias
As dez imagens Docker mais populares contêm pelo menos 30 vulnerabilidades cada
Vulnerabilidades ReDoS no npm aumentam 143%, e os casos de XSS continuam crescendo
Comece a resolver desafios de capture the flag
Aprenda a resolver desafios de capture the flag assistindo sob demanda ao nosso workshop virtual introdutório.