0
0
Hackers estão sempre procurando novas maneiras de comprometer aplicativos. À medida que linguagens, ferramentas e arquiteturas evoluem, os exploits de aplicativos também evoluem. E o alvo mais recente são os desenvolvedores.
Tradicionalmente, as explorações da cadeia de suprimentos de software, como o incidente Struts na Equifax, dependiam da falha de uma organização em corrigir uma vulnerabilidade conhecida. Mais recentemente, os ataques à cadeia de suprimentos tomaram um rumo mais sinistro porque os maus atores não estão mais esperando por divulgações de vulnerabilidades públicas. Em vez disso, eles estão injetando código malicioso em projetos de código aberto ou construindo componentes maliciosos que alimentam a cadeia de suprimentos global.
Ninguém na empresa, incluindo desenvolvedores, conhece todos os componentes que um aplicativo compreende, nem entende todas as dependências associadas a esses componentes. É uma questão de responsabilidade potencial que, combinada com uma demanda por maior transparência, alimentou a adoção de ferramentas de análise de composição de software (SCA) e lista de materiais de software (SBOM).
“Criamos gerenciadores de pacotes que tornam mais fácil e rápido para os desenvolvedores reutilizar componentes binários, o que indiscutivelmente os torna mais produtivos, mas essas ferramentas também introduzem dependências transitivas”, disse Brian Fox, CTO da Sonatype. “Se eu puxar uma coisa, essa coisa puxa suas dependências e, em Java, não é incomum ver uma explosão de 10x ou mesmo 100x. Em JavaScript, é ainda pior, 100x a 1.000x.”
Ataques da Cadeia de Suprimentos de Próxima Geração Estão Crescendo
De acordo com o relatório State of the Software Supply Chain 2020 da Sonatype, o número de ataques cibernéticos de próxima geração visando ativamente projetos de código aberto aumentou 430% ano após ano. De fevereiro de 2015 a junho de 2019, 216 desses ataques foram registrados. Então, de julho de 2019 a maio de 2020, ocorreram 929 ataques adicionais. Esses ataques da cadeia de suprimentos da próxima geração estão aumentando por três razões.
Primeiro, os projetos de código aberto contam com contribuições de milhares de desenvolvedores voluntários e é difícil ou impossível discernir entre membros com intenção boa ou maliciosa.
Em segundo lugar, quando o código malicioso é secretamente injetado “upstream” no desenvolvedor via código aberto, é altamente provável que ninguém perceba que o malware existe, exceto a pessoa que o plantou. Essa abordagem permite que os adversários definam armadilhas sub-repticiamente a montante e realizem ataques a jusante assim que a vulnerabilidade se mover pela cadeia de suprimentos para a natureza.
Finalmente, os projetos de código aberto normalmente incorporam centenas ou milhares de dependências de outros projetos de código aberto, muitos dos quais contêm vulnerabilidades conhecidas. Enquanto alguns projetos de código aberto demonstram higiene exemplar medida pelo tempo médio para correção (MTTR) e tempo médio para atualização (MTTU), muitos outros não. O grande volume de código aberto e o grande número de dependências dificultam a avaliação rápida da qualidade e segurança de cada nova versão de uma dependência.
Por que as listas de componentes aprovadas não ajudam
A natureza dinâmica do desenvolvimento de software está em desacordo com as listas de componentes aprovadas, porque as listas não devem ser atualizadas com a frequência que deveriam ser. A tarefa é muito complexa e demorada para os seres humanos.
“Existem milhões de componentes se você incluir os vários ecossistemas que estão por aí, e eles estão mudando quatro, 10, 100 vezes por ano. Como você pode ter certeza de que o que estava bem há um ano ainda está bem?” disse Fox. “As pessoas ainda estão usando o Struts porque ele está em sua lista aprovada, embora seja uma vulnerabilidade de nível 10 há cerca de 15 anos.”
As empresas modernas precisam da capacidade de definir políticas que possam ser aplicadas a componentes individuais, seja a regra baseada no licenciamento, na idade do componente, na popularidade do componente ou em outros critérios. Uma vez que a política tenha sido definida, ela pode ser executada automaticamente.
“Com ferramentas, você pode inspecionar o software, executar essas políticas, entender por que um determinado componente não foi usado neste aplicativo e recomendar um melhor. Ao codificar tudo isso, você pode evitar ir até o jurídico, arquitetura ou segurança para pedir permissão”, disse Fox.
Embora as ferramentas de análise estática e dinâmica ajudem a identificar problemas no código, seus recursos podem não se estender ao código de terceiros porque há muitos caminhos de código para avaliar. Portanto, a grande maioria do código pode não ser digitalizada, dando aos desenvolvedores uma falsa sensação de segurança.
Além disso, quando um desenvolvedor baixa e executa um componente malicioso, esse componente pode instalar um backdoor em seu sistema. Da mesma forma, com integrações contínuas, o código venenoso pode se infiltrar ainda mais no pipeline.
“Os atacantes agora estão focados nos desenvolvedores e na infraestrutura de desenvolvimento como o caminho para a organização”, disse Fox. “Dessa forma, eles podem ignorar todas as coisas de segurança corporativa, como firewalls. Ao abstrair a pura complexidade dos componentes do aplicativo e suas dependências em políticas, você pode fornecer aos desenvolvedores grades de proteção que ajudam a melhorar a segurança dos aplicativos e esses desenvolvedores não precisam sempre permissão para outras pessoas na organização. ”
FONTE: SD TIMES