LLMs e IA posicionados para dominar o mundo AppSec

Views: 112
0 0
Read Time:3 Minute, 18 Second

Riscos de desenvolvimento de aplicativos

Um novo relatório de pesquisa explora as tendências emergentes que as organizações de software precisam considerar como parte de sua estratégia de segurança e os riscos associados ao uso de software de código aberto (OSS) existente no desenvolvimento de aplicativos.

Em particular, como o desenvolvimento de software moderno adota cada vez mais arquiteturas distribuídas e microsserviços juntamente com componentes de código aberto e de terceiros, o relatório acompanha a popularidade surpreendente da API do ChatGPT, como as atuais plataformas de IA baseadas em modelo de linguagem grande (LLM) são incapazes de classificar com precisão o risco de malware na maioria dos casos e como quase metade de todos os aplicativos não faz nenhuma chamada para APIs sensíveis à segurança em sua base de código.

“O fato de ter havido uma expansão tão rápida de novas tecnologias relacionadas à Inteligência Artificial e de esses recursos estarem sendo integrados a tantos outros aplicativos é realmente notável, mas é igualmente importante monitorar os riscos que elas trazem”, disse Henrik Plate, pesquisador líder de segurança do Endor Labs Station9 .

“Esses avanços podem causar danos consideráveis ​​se os pacotes selecionados introduzirem malware e outros riscos à cadeia de fornecimento de software. Este relatório oferece uma visão antecipada dessa função crítica, assim como os primeiros usuários de protocolos de segurança correspondentes se beneficiarão mais com esses recursos”, acrescentou Plate.

Vulnerabilidades de código não utilizadas

As tecnologias LLM existentes ainda não podem ser usadas para auxiliar de forma confiável na detecção e dimensionamento de malware – na verdade, elas classificam com precisão o risco de malware em apenas 5% de todos os casos. Eles têm valor em fluxos de trabalho manuais, mas provavelmente nunca serão totalmente confiáveis ​​em fluxos de trabalho autônomos. Isso ocorre porque eles não podem ser treinados para reconhecer novas abordagens, como as derivadas das recomendações do LLM.

45% dos aplicativos não têm chamadas para APIs sensíveis à segurança em sua base de código, mas esse número na verdade cai para 5% quando as dependências são incluídas. As organizações rotineiramente subestimam o risco quando não analisam o uso de tais APIs por meio de dependências de código aberto.

Embora 71% do código de aplicativo Java típico seja de componentes de código aberto, os aplicativos usam apenas 12% do código importado. Vulnerabilidades em código não usado raramente são exploráveis; as organizações podem eliminar ou despriorizar 60% do trabalho de correção com informações confiáveis ​​sobre qual código pode ser acessado em um aplicativo.

Segurança de aplicativos LLM

Faz apenas cinco meses desde que a API do ChatGPT foi lançada, mas a pesquisa do Endor Labs já identificou que ela é usada em pacotes 900 npm e PyPi em diversos domínios de problemas. 75% deles são embalagens novas.

Embora os avanços sejam inegáveis, organizações de todos os tamanhos precisam praticar a devida diligência ao selecionar pacotes. Isso porque a combinação de extrema popularidade e falta de dados históricos representa um terreno fértil para possíveis ataques.

Focando especificamente em aplicativos LLM em segurança, a pesquisa revela como o LLM pode efetivamente criar e ocultar malware e até mesmo se tornar um inimigo dos aplicativos LLM defensivos. Diante desse cenário, as organizações precisarão documentar os componentes e as vulnerabilidades que seus aplicativos incluem, por exemplo, por meio de uma lista de materiais de software (SBOM) .

Os aplicativos geralmente usam apenas uma pequena porcentagem dos componentes de código aberto que integram, enquanto os desenvolvedores raramente entendem a torrente de dependências em cada um desses componentes.

Para atender aos requisitos de transparência e proteger a marca, é importante que as organizações vão além dos SBOMs padrão. Eles precisam entender não apenas a lista de componentes, mas também como eles estão sendo usados ​​em seus aplicativos e quais vulnerabilidades podem ser exploradas. Isso permitirá uma melhor compreensão do risco, melhorará a produtividade e reduzirá os custos.

FONTE: HELP NET SECURITY

POSTS RELACIONADOS