Segurança de código aberto explicada

Nos últimos anos, o software de código aberto se tornou amplamente utilizado por sua natureza colaborativa e pública, o que também o torna conveniente tanto para desenvolvedores quanto para agentes mal-intencionados. Quando adversários descobrem que uma aplicação está exposta a uma vulnerabilidade conhecida publicamente, podem atacar qualquer aplicação desenvolvida com esse código aberto. Casos como as vulnerabilidades do Log4j e do Apache Struts mostram que esse é um risco real e, às vezes, grave para as organizações.

É essencial gerenciar componentes e dependências de código aberto para reduzir esse risco. No entanto, é difícil ter visibilidade de todos os componentes de código aberto usados em uma aplicação, e verificar manualmente cada um deles em bancos de dados de vulnerabilidades conhecidas é trabalhoso. As dependências aninhadas tornam tudo ainda mais complexo, pois é preciso proteger não apenas o código escrito pelos desenvolvedores, mas também todo o código aberto consumido por eles e as dependências contidas nesse código.

Neste artigo, vamos definir segurança de código aberto, explorar os riscos associados a esse tipo de software e apresentar ferramentas e processos que ajudam as organizações a reduzir os riscos ao consumir software de código aberto.

O que é segurança de código aberto?

Segurança de código aberto abrange os riscos e as vulnerabilidades associados a softwares de terceiros, além das ferramentas e dos processos usados para protegê-los. As ferramentas de segurança podem automatizar a identificação de bibliotecas e dependências de código aberto no código, analisar como esses componentes são usados nas aplicações e gerar alertas ou iniciar ações de correção sempre que vulnerabilidades forem detectadas. Práticas como a autenticação de dois fatores adicionam outra camada de segurança para ajudar a evitar violações.

4 benefícios do software de código aberto

As demandas dos negócios estão acelerando o desenvolvimento de software e os ciclos de lançamento. Para atendê-las, os desenvolvedores recorrem cada vez mais ao software de código aberto para complementar o código desenvolvido internamente.

Sua popularidade se deve a alguns fatores:

1. Custo: Os desenvolvedores de software podem usar, modificar e compartilhar livremente softwares de código aberto em domínio público, enquanto uma comunidade mundial de desenvolvedores e voluntários trabalha para mantê-los. Mesmo os pacotes comerciais de código aberto são relativamente baratos em comparação com o custo de desenvolver código personalizado do zero.

2. Facilidade de uso: Como o software de código aberto é pré-criado e aberto, os desenvolvedores podem aproveitar código já escrito para atender às suas necessidades específicas. Assim, sobra mais tempo para tarefas de maior valor.

3. Qualidade: Como uma comunidade de desenvolvedores cria, usa e analisa o código aberto, em teoria, há menos bugs, pois as vulnerabilidades são identificadas e corrigidas rapidamente.

4. Velocidade: Com o software de código aberto, os desenvolvedores conseguem levar aplicações importantes para os negócios ao mercado mais rapidamente.

Em alguns casos, a adoção de software de código aberto dobrou ou mais, permitindo que os desenvolvedores aproveitem as economias de escala, com mais ferramentas disponíveis e profissionais mais bem preparados entrando no mercado. Ao mesmo tempo, há compensações entre abertura e vulnerabilidade, agilidade e qualidade.

Figura 1: novos pacotes criados pelo ecossistema por ano

Ao usar software de código aberto, você depende de pessoas que não conhece para manter o código do qual suas aplicações dependem. Por isso, é fundamental usar sistemas e ferramentas para minimizar os possíveis riscos.

3 riscos de segurança do software de código aberto

Quase todas as aplicações nativas da nuvem dependem de componentes de código aberto. No entanto, como ninguém é responsável pela manutenção ou segurança deles, o software de código aberto está sujeito a diversos riscos, incluindo:

1. Vulnerabilidades em dependências de código aberto

Isso inclui vulnerabilidades conhecidas e desconhecidas. Entre as conhecidas estão as que receberam um número CVE (Common Vulnerabilities and Exposures), foram divulgadas na internet, constam em bancos de dados públicos de vulnerabilidades ou estão registradas em bancos de dados privados. Em geral, quanto mais conhecida a vulnerabilidade, mais urgente é a necessidade de corrigi-la.

Além de monitorar as vulnerabilidades, também é essencial rastrear cada dependência de código aberto presente em uma aplicação. As dependências transitivas, ou seja, aquelas que dependem de outras dependências, merecem atenção especial porque são menos visíveis para as ferramentas de segurança e as auditorias. Por isso, é útil usar ferramentas ou processos capazes de identificar e auditar todas as dependências de uma aplicação.

2. Riscos de conformidade com licenças

Os desenvolvedores precisam entender cada tipo de licença de software dos pacotes de código aberto que usam para garantir que o código seja utilizado em conformidade com as regras. Isso exige conhecer as condições das licenças e aplicá-las em todos os projetos. Para fazer cumprir as licenças de código aberto, as organizações precisam ter visibilidade detalhada de como esses componentes são usados. Também é importante monitorar as licenças continuamente, caso o titular dos direitos autorais altere a licença de uma biblioteca.

3. Pacotes de código aberto sem manutenção

Os pacotes de código aberto costumam ser mantidos por um único desenvolvedor ou uma equipe pequena, quando recebem manutenção. Os desenvolvedores de projetos comunitários de código aberto não têm o compromisso de manter o software, que é fornecido “no estado em que se encontra”. Por isso, cabe a quem o utiliza dedicar tempo e recursos para garantir que o código seja seguro. Felizmente, existem ferramentas úteis que simplificam esse processo, como o Snyk Advisor, que analisa os pacotes com base no nível de manutenção, na comunidade, na postura de segurança e na popularidade para ajudar você a avaliar a saúde dos pacotes de código aberto que usa.

Quer saber mais sobre os riscos do software de código aberto? Leia nosso artigo: 5 riscos potenciais do software de código aberto.

Principais estatísticas do relatório sobre o estado do código aberto

Dados são conhecimento. Por isso, a Snyk entrevistou desenvolvedores e profissionais de segurança para entender suas preocupações com a segurança do código aberto, as tendências de vulnerabilidades em pacotes e imagens de contêineres e as práticas adotadas por mantenedores e organizações para proteger seus softwares. Publicamos os resultados no nosso relatório State of Open Source Security de 2020. Confira alguns dos principais destaques.

A adoção do código aberto está crescendo

Os ecossistemas de código aberto continuam se expandindo, impulsionados pelas demandas do mercado e pelas necessidades dos negócios. O npm liderava o crescimento, com alta anual superior a 33% e 1,8 milhão de pacotes em março de 2022. A maioria das vulnerabilidades de código aberto continua sendo encontrada em dependências indiretas:

• npm: 86%

• Ruby: 81%

• Java: 74%

A cultura de segurança do código aberto está se voltando para os desenvolvedores

Os entrevistados indicaram que veem a segurança como uma responsabilidade compartilhada entre os departamentos:

• 85% consideraram os desenvolvedores responsáveis pela segurança do código aberto

• 55% consideraram as equipes de segurança responsáveis

• 35% disseram que as equipes de operações também têm um papel

Tendências de vulnerabilidades

O número de novas vulnerabilidades caiu 20% no geral, e as vulnerabilidades de cross-site scripting (XSS) foram as mais relatadas.

Figura 2: vulnerabilidades identificadas em ecossistemas desde 2014

Desafios de contêineres e orquestração

Imagens base oficiais marcadas como latest costumam incluir vulnerabilidades conhecidas. A imagem oficial do Node, em especial, tem quase 700 vulnerabilidades conhecidas. Mais de 30% dos participantes da pesquisa não revisam os manifestos do Kubernetes em busca de configurações inseguras, e os requisitos de controles de recursos relacionados à segurança não são amplamente implementados no Kubernetes.

Figura 3: vulnerabilidades em imagens oficiais de contêineres

Tendências de segurança do código aberto em 2022

No último ano, algumas tendências dominaram as conversas sobre segurança do código aberto: segurança da cadeia de suprimentos, mudanças culturais na atribuição de responsabilidades, queda no número de vulnerabilidades recém-descobertas, dependência de mantenedores voluntários e mudanças nas expectativas sobre a correção de vulnerabilidades.

Ataques à cadeia de suprimentos estão se tornando mais comuns

Os componentes de software de terceiros ficam em um repositório centralizado, que compõe a cadeia de suprimentos de software. Essa cadeia é um vetor de ataque atraente, pois agentes mal-intencionados podem explorar pontos vulneráveis no pipeline de desenvolvimento sem precisar alterar os repositórios de software. Por exemplo, podem explorar falhas de projeto em ataques de confusão de dependência ou namespace, ou comprometer componentes de terceiros para acessar dados de usuários e sistemas internos.

Cada elo é um possível vetor de ataque. Por isso, é importante proteger a cadeia de suprimentos desde o código-fonte até a implantação. As vulnerabilidades na cadeia de suprimentos não são novidade, mas dominaram as conversas em 2021 e foram um tema recorrente na ordem executiva sobre cibersegurança do presidente Biden.

Mudança cultural rumo à responsabilidade compartilhada pela segurança

Quem deve ser responsável pela segurança? Uma das tendências mais promissoras que observamos é a mudança em direção a uma responsabilidade compartilhada entre as equipes de desenvolvimento, segurança e operações.

A mudança para uma abordagem DevSecOps é positiva, mas 47% dos entrevistados disseram não ter programas específicos para promover a responsabilidade compartilhada, e apenas 15% implementaram programas de security champions, definidos como uma prática fundamental de segurança no OWASP Software Assurance Maturity Model (SAMM). Isso mostra que ainda há uma lacuna entre reconhecer a importância da responsabilidade compartilhada e colocá-la em prática.

Com base no relatório State of DevOps da Puppet, também aprendemos que, à medida que as organizações amadurecem suas práticas de DevOps, suas práticas de segurança evoluem junto.

“À medida que as práticas de DevOps melhoram, o DevSecOps surge naturalmente. Nas organizações mais avançadas, a segurança foi integrada desde o início: a maioria a incorpora aos requisitos (51%), ao design (61%), à construção (53%) e aos testes (52%). Em contrapartida, na maioria das organizações em estágio intermediário, a segurança só participa quando há uma auditoria de produção agendada (48%) ou quando um problema é relatado em produção (45%).”

Relatório Puppet State of DevOps 2021

Menos vulnerabilidades encontradas

Uma descoberta surpreendente do relatório é que o número de novas vulnerabilidades caiu 20% no geral. Essa tendência ocorre em um momento de crescimento acelerado dos ecossistemas de código aberto, o que a torna especialmente relevante.

Não há uma explicação clara para a redução no crescimento das vulnerabilidades de código aberto, enquanto o cenário mais que dobrou em alguns ecossistemas. Ainda assim, isso sugere que melhorias na conscientização, nas práticas e nas ferramentas de segurança estão dando resultado.

Vamos continuar acompanhando essa tendência, mas ainda é cedo para relaxar quanto aos controles e às práticas de segurança.

Mantenedores de código aberto estão reagindo às empresas

Podemos esperar mais tensão entre mantenedores de código aberto insatisfeitos com empresas e organizações que lucram com produtos criados com seu software sem financiar o trabalho dos mantenedores.

Uma pesquisa da Tidelift de 2021 com 400 mantenedores de código aberto constatou que 46% não recebem nenhum pagamento e apenas 26% ganham mais de US$ 1.000 por ano pelo trabalho de manutenção. Mais da metade (59%) já abandonou ou pensou em abandonar a manutenção de um projeto, e quase metade dos entrevistados apontou a falta de remuneração como o principal motivo para não gostar de ser mantenedor.

Esse sentimento está gerando consequências no mundo real. Em janeiro de 2022, por exemplo, o mantenedor do popular pacote npm colors introduziu código malicioso que gera um loop infinito e interrompe qualquer uso do pacote.

A versão comprometida do colors foi baixada mais de 95 mil vezes. O pacote é usado em vários outros projetos, incluindo o auxiliar de linha de comando prompt, com cerca de 500 mil downloads semanais, e o próprio aws-cdk da AWS, com cerca de 2 milhões de downloads semanais. Por isso, é um motivo de grande preocupação.

Um incidente semelhante também ocorreu com o popular pacote npm faker, mantido pela mesma pessoa. O mantenedor abriu uma issue dizendo que não manteria mais os projetos gratuitamente, embora eles sejam usados por várias empresas da Fortune 500.

Os prazos para corrigir vulnerabilidades ainda não atendem às expectativas

De acordo com a pesquisa Open Source Security de 2020, 47% dos entrevistados esperam que uma vulnerabilidade seja corrigida em até uma semana após ser descoberta, e quase 18% esperam uma correção em até um dia.

Figura 4: Expectativa para correções de vulnerabilidades de código aberto

Na prática, apenas 35% das vulnerabilidades em projetos analisados foram corrigidas em menos de 20 dias, enquanto 36% levaram 70 dias ou mais. O tempo médio para correção foi de 68 dias.

É evidente que as organizações precisam alinhar as expectativas em relação à sua postura de risco. Elas precisam estar cientes dos SLAs para corrigir vulnerabilidades de código aberto, principalmente quando a manutenção do código fica a cargo de uma pessoa colaboradora.

Métricas importantes para sua estratégia de segurança de código aberto

Um bom ponto de partida é acompanhar com atenção as métricas de segurança de código aberto das bibliotecas que você utiliza. Considere métricas como:

• O número de dias entre a descoberta de uma vulnerabilidade e sua correção

• O tempo médio para mesclar um pull request após a abertura de um problema

• O tempo necessário para corrigir o código por conta própria

Essas respostas ajudam a entender melhor como você responde a problemas de segurança nos pacotes que utiliza, permitindo criar uma estratégia para gerenciar componentes e identificar e corrigir vulnerabilidades.

Além disso, tome a iniciativa em relação aos pacotes de código aberto que você usa. Envie pull requests aos mantenedores para alertá-los sobre os problemas. Entenda como o software de código aberto afeta sua empresa e justifique a adoção de uma abordagem sistemática para gerenciá-lo.

6 recursos que você deve buscar em uma ferramenta de segurança de código aberto

As ferramentas de segurança têm um papel fundamental na estratégia de segurança de código aberto. Elas permitem analisar automaticamente o código aberto em busca de vulnerabilidades conhecidas e consultar bancos de dados de vulnerabilidades para entender os possíveis impactos e as medidas necessárias para corrigir os problemas. Essas ferramentas podem monitorar continuamente o código em produção e integrar segurança, licenciamento e governança em todo o processo de desenvolvimento de software.

1. Visão abrangente dos pacotes e das vulnerabilidades que os afetam

Como a visibilidade dos componentes e das dependências de código aberto faz parte do desafio de segurança, uma forma de inventariar e avaliar componentes automaticamente ajuda a controlar o ambiente de código aberto. Procure soluções automatizadas que identifiquem componentes em pipelines de CI/CD e avaliem o nível de ameaça que representam. Os componentes vulneráveis estão realmente sendo usados pela aplicação?

2. Recurso de gerenciamento de licenças

As ferramentas de segurança podem verificar continuamente o código de terceiros e o código personalizado em busca de vulnerabilidades e riscos relacionados a licenças enquanto o código é escrito no ambiente de desenvolvimento, eliminando a necessidade de analisar repositórios de código.

3. Automação

As ferramentas de segurança permitem monitorar e detectar vulnerabilidades automaticamente. Em caso de violação, elas podem avaliar os danos e definir a resposta adequada. Também é possível configurar políticas para correções, solicitações, patches e atualizações de dependências, automatizando esses processos.

4. Integrações diretas com ferramentas de desenvolvimento, fluxos de trabalho e pipelines de automação

Integrar a segurança diretamente às ferramentas e aos processos de desenvolvimento ajuda a simplificar a proteção do código. Com plugins, os desenvolvedores podem aplicar correções diretamente pela CLI ou pelo IDE. As integrações com o GitHub permitem testar repositórios, projetos e pull requests, além de aplicar correções por meio de pull requests automatizados.

5. Banco de dados atualizado e enriquecido, que vai além das CVEs conhecidas

As ferramentas de segurança vão além dos bancos de dados públicos de vulnerabilidades conhecidas e criam bancos de dados próprios e selecionados. Essas vulnerabilidades incluem aquelas com números CVE, as publicadas em avisos de segurança, as identificadas em rastreadores de problemas e as discutidas em fóruns ou nas redes sociais, entre outras.

6. Monitoramento contínuo dos projetos

As ferramentas de segurança podem monitorar continuamente aplicações em produção para prevenir automaticamente a exploração de vulnerabilidades. Assim, as aplicações passam a monitorar a si mesmas e ficam preparadas para se defender contra ataques ou problemas de licenciamento.

Para saber mais sobre como escolher uma ferramenta de segurança para monitorar componentes de código aberto, leia nosso guia Como escolher ferramentas de SCA.

6 benefícios de usar Snyk para a segurança de OSS

Snyk Open Source oferece uma ferramenta de segurança voltada para desenvolvedores que integra a segurança de aplicações a todo o pipeline de desenvolvimento de software. Assim, você pode criar e implantar aplicações com software de código aberto e proteger o código contra vulnerabilidades e problemas de licenciamento.

1. Compatível com DevSecOps

Snyk Open Source se integra ao SDLC desde a primeira linha de código. Investimos bastante em integrações para tornar a análise de segurança e licenças o mais simples possível. Isso coloca os desenvolvedores diretamente na linha de frente da segurança das aplicações e favorece a colaboração com as equipes de segurança e operações.

Também criamos o DevSecOps Hub, que destaca tecnologias, processos e pessoas para ajudar as organizações a desenvolver uma cultura DevOps que integre a segurança de forma eficaz; e nossa DevSecOps Community, que aproxima desenvolvedores e líderes de segurança por meio de um portal de suporte, eventos virtuais e presenciais e um programa de embaixadores que conecta os defensores da segurança mais diretamente à Snyk.

2. Corrija problemas diretamente nos fluxos de trabalho dos desenvolvedores

Snyk Open Source se integra a ferramentas de desenvolvimento como Atlassian Bitbucket, Visual Studio Code, Maven Central, GitHub e JetBrains. Assim, os desenvolvedores podem acessar a Snyk e identificar vulnerabilidades e problemas de licenciamento na ferramenta que preferirem.

3. Poucos falsos positivos

A equipe de especialistas em segurança da Snyk gerencia o banco de dados para manter baixa a taxa de falsos positivos. Ela analisa e testa cada item, atribui uma pontuação e um vetor CVSS a cada vulnerabilidade, investe em pesquisas próprias para descobrir novas vulnerabilidades e inclui resumos selecionados manualmente, com trechos de código quando aplicável.

4. Visualização da árvore de dependências

A Snyk usa o gerenciador de pacotes da sua aplicação para criar uma árvore de dependências e exibi-la na interface da Snyk. Isso ajuda a visualizar qual componente está causando um problema e permite que a Snyk o identifique, mesmo quando se trata de uma dependência transitiva. Também é possível automatizar a criação de um Software Bill of Materials (SBOM) diretamente nos fluxos de trabalho dos desenvolvedores. Depois de criar o SBOM, você pode verificar se há vulnerabilidades de segurança usando o SBOM Checker da Snyk.

5. Correções automatizadas

A Snyk sugere automaticamente correções para vulnerabilidades pela CLI, pelo IDE e pelos pipelines de CI/CD sempre que elas estão disponíveis. Quando não há correção para uma dependência, a Snyk pode avisar você quando uma solução estiver disponível ou quando novas vulnerabilidades forem descobertas.

6. Governança e licenciamento

O Snyk Open Source License Compliance Management permite gerenciar licenças diretamente nos fluxos de trabalho dos desenvolvedores, com aplicação automatizada de políticas e gerenciamento detalhado. Assim, você pode monitorar cada etapa, da primeira linha de código até a aplicação implantada, para garantir que seus projetos não violem nenhuma licença.

Play Video: Snyk Open Source Security Overview

Seção de perguntas frequentes

O que é segurança de código aberto?

Segurança de código aberto diz respeito aos riscos que desenvolvedores e equipes de segurança enfrentam hoje ao usar código de terceiros e de código aberto em suas aplicações, além dos processos, das metodologias e das ferramentas que adotam para mitigá-los. Ataques recentes que exploraram vulnerabilidades em código aberto geraram custos enormes para as organizações, ressaltando a importância da segurança de código aberto e da implementação e do monitoramento das estratégias relacionadas.

Por que a segurança de código aberto é importante?

O código aberto impulsiona a transformação digital que vemos hoje e é usado por empresas de todos os portes e de todos os setores. Mas também traz riscos. Reconhecer esses riscos é um primeiro passo importante, mas é preciso investir e manter um plano de segurança de código aberto bem definido, que inclua testes e monitoramento contínuos.

Quais são os riscos do código aberto?

Os desenvolvedores incorporam inúmeras dependências de código aberto sem controles de segurança nem visibilidade. Esses componentes são mantidos por voluntários externos à organização, que não têm obrigação de atualizá-los ou protegê-los. Além disso, por serem públicos, agentes mal-intencionados podem conhecer e explorar vulnerabilidades assim que elas se tornam conhecidas pelos desenvolvedores. Esses são alguns dos riscos do software de código aberto.