O futuro do código aberto está ameaçado?

Software de código aberto (OSS) é a espinha dorsal da arquitetura de aplicativos de hoje. Ao acelerar o tempo de lançamento no mercado e reduzir a carga sobre os desenvolvedores frequentemente sobrecarregados, o código aberto consolidou sua posição revolucionária no cenário do DevOps. Embora profundamente transformador para o desenvolvimento de aplicativos modernos, copiar e colar de código aberto continua a representar um grande risco de segurança para organizações e indivíduos. Combater isso exige uma lista negra total de código-fonte aberto ou a implementação proativa de contramedidas, como uma solução WAF de próxima geração.

O código de terceiros é vital para o desenvolvimento de aplicativos

As bibliotecas são esconderijos incrivelmente úteis de código-fonte para componentes de aplicativos da Web ou móveis. Essas bibliotecas podem ser de código aberto – disponíveis para todos sem nenhum custo – ou proprietárias, que bloqueiam o código por trás do pagamento. Embora o código aberto reivindique grande parte da glória, o código proprietário também desempenha um papel no funcionamento contínuo dos aplicativos corporativos.

Esse software de terceiros, quando usado com responsabilidade, evita que os desenvolvedores precisem constantemente reinventar a roda. Isso melhora drasticamente a eficiência do processo de desenvolvimento, ao mesmo tempo em que auxilia na produção de um produto final de alta qualidade. Por fim, o uso livre e liberal do código-fonte aberto cria um ciclo de feedback positivo, permitindo que os desenvolvedores lancem seu produto mínimo viável mais rapidamente, o que abre caminho para a coleta e implementação rápidas de feedback e avaliação do usuário. Embora os desenvolvedores estejam profundamente cientes da posição crítica do código aberto no processo DevOps, os executivos geralmente ficam surpresos ao saber que 80% do código que suporta aplicativos modernos se origina de código pré-existente.

O Perigo Sombrio das Dependências Transitivas

Não é novidade que o código-fonte aberto vem com riscos. Fraquezas generalizadas recentes, como Log4j e HeartBleed, colocaram irrevogavelmente o risco de código aberto no mapa. O que continua sendo uma área crescente de compreensão é a frequência absoluta com que o código aberto é usado e a discrição com que as vulnerabilidades podem se infiltrar em um projeto ativo. Apesar do risco contínuo apresentado pelos projetos de código aberto, muito pouca pesquisa foi realizada sobre o tipo específico de risco que o código aberto apresenta. Pesquisadores do Endor Labs decidiram mudar isso, esclarecendo a origem das principais ameaças de OSS.

Dentro do software, as dependências transitivas descrevem uma relação exclusivamente indireta entre dois componentes. Por exemplo, digamos que sua equipe de desenvolvimento adicione o pacote B a um projeto em andamento. O pacote B, por sua vez, baixa automaticamente o pacote C. Nesse cenário, enquanto o software em desenvolvimento desfruta de um relacionamento direto com o pacote B, o pacote C permanece à espreita em segundo plano – integral, mas amplamente invisível. O que frustra qualquer tentativa de práticas de desenvolvimento mais seguras é o fato de que apenas 5% das dependências de software de código aberto são selecionadas manualmente para implementação no processo DevOps. Dessa maneira, a maioria das dependências simplesmente é puxada automaticamente para a base de código. Isso descreve a origem de uma vulnerabilidade transitiva. Um relatório recente do Endor Labs descobriu que surpreendentes 95% das vulnerabilidades de código aberto se originam de dependências transitivas .

Os dados foram compilados a partir do relatório Census II da Core Infrastructure, que lista os softwares de código aberto gratuitos mais populares. Esses dados foram então enriquecidos com outras fontes que permitiram aos pesquisadores do Endor escanear gerenciadores de pacotes populares e bibliotecas OSS. Os pesquisadores descobriram que – dos 254 pacotes mencionados nos dados do Censo II – a maioria sofre em média de 14 dependências transitivas. No vácuo, 14 pode não parecer muito alto, mas a maioria dos aplicativos depende de dezenas – senão centenas – de dependências diretas; suas contrapartes transitivas escalam exponencialmente.

A maior preocupação expressa pelos pesquisadores é baseada na subestimação generalizada do problema pela indústria. Os executivos continuam a minar a quantidade de código-fonte em uso no processo de desenvolvimento – as dependências transitivas ainda não estão no radar. A profundidade absoluta dos problemas de segurança continua a espreitar abaixo da superfície, aumentando o raio de explosão de ataques de typosquatting e execução remota de código. Para que a reutilização constante do código-fonte aberto atinja todo o seu potencial, a segurança precisa se tornar uma prioridade mais alta no processo DevOps.

Como se proteger contra vulnerabilidades à espreita

O processo de manter uma pilha de tecnologia segura nunca foi tão complexo. Com os alertas de patch rapidamente se tornando opressores, é hora da segurança corporativa priorizar a proteção automatizada e sem patches. As medidas tradicionais que priorizam a segurança do perímetro juntamente com análises estáticas e dinâmicas dependem de atualizações manuais, o que significa que não há proteção contra dias zero. O código backdoor que os invasores usaram no infame ataque SolarWinds não foi detectado por nenhuma análise estática, pois tecnicamente não havia erros.

Identificar e bloquear tentativas de exploração requer um pequeno conjunto de software de bloqueio. Para primeiro ajudar a definir e proteger o perímetro de um aplicativo, um Web Application Firewall (WAF) de última geração pode ser implantado. Situando-se no limite entre o externo e o interno, o WAF monitora todo o tráfego que flui de e para um aplicativo. O aspecto de próxima geração permite que esse WAF se adapte e implemente automaticamente novas políticas. A implantação automatizada dessa evolução constante libera tempo e energia significativos para a equipe de segurança que um WAF antigo drenaria.

Enquanto o WAF controla qualquer tentativa externa de executar código, o Runtime Application Self Protection (RASP) protege contra fraquezas internas e injeções de código. Esse nível de proteção avalia todas as cargas úteis (como consultas SQL e comandos do sistema operacional) em tempo real. Este processo não requer assinaturas ou uma fase de aprendizado e ocorre inteiramente dentro do contexto do aplicativo. Como opera dentro do aplicativo, abrange quase todos os contextos. Isso significa que, mesmo que uma exploração permita a violação do perímetro, um invasor é impedido de se mover lateralmente, pois qualquer comportamento suspeito do aplicativo aciona o desligamento do RASP. Isso encerra a atividade suspeita e alerta as equipes de segurança. Dessa forma, o RASP é complementar a um WAF de última geração; enquanto o WAF ajuda a manter fora o tráfego ruim, o risco representado por explorações transitivas e ocultas é mitigado pelo RASP. Com esses componentes protegendo uma pilha de tecnologia, a carga que o OSS atualmente impõe à segurança é significativamente reduzida.