Sejam aplicativos ou APIs, aplicativos tradicionais, modernos ou de IA, a programabilidade é uma ferramenta essencial na caixa de ferramentas de segurança para lidar com problemas de segurança.
Uma das maneiras de manter aplicativos e APIs seguros é por meio de testes de vulnerabilidades e correção antes de disponibilizá-los para clientes e parceiros. Uma técnica popular para testar aplicativos e APIs é o teste fuzz .
O teste de fuzz envolve o envio de entradas inesperadas — strings em vez de números, caracteres especiais, muito longos, muito curtos, etc. — para verificar a resposta da API ou do aplicativo. Uma implementação robusta manipulará essas entradas rejeitando-as como inválidas. Mas tão importante quanto testar o tratamento de entrada é testar o código que executa o tratamento de entrada.
Em outras palavras, não basta que a lógica do aplicativo ou da API rejeite entradas inválidas; a lógica que verifica entradas inválidas também deve ser robusta.
Agora, como costuma acontecer no mundo da segurança de aplicativos, alguém criará uma entrada que não era esperada ou considerada. Ignoraremos que um bom número de implementações de higienização de entrada são simplesmente ruins e fingiremos que todas são robustas e capazes de detectar 99% das malformações.
Mesmo com essa suposição utópica, sempre há aquele 1% que ninguém considerou. Essa é uma das maneiras pelas quais as vulnerabilidades de dia zero nascem.
Às vezes, eles são o resultado de um defeito no conjunto de tecnologias. Talvez seja o servidor web, o servidor de aplicativos, o servidor GraphQL. Talvez esteja em um conector para uma fonte de dados, como um banco de dados vetorial usado para dar suporte ao caso de uso de geração aumentada de recuperação (RAG) cada vez mais popular para IA generativa. Ou talvez seja a chegada de vulnerabilidades de inferência de IA, como Probllama . Afinal, a adição de uma nova camada dentro da arquitetura mais ampla do aplicativo significa novas vulnerabilidades.
Essas são as vulnerabilidades que levam ao pânico na Internet. Eles nos deram Apache Killer (2011), HeartBleed (2014), Spectre and Meltdown (2018) e Log4Shell (2021).
Essas eram vulnerabilidades imprevistas. Não se poderia esperar que desenvolvedores, SecOps, DevSecOps e QA os antecipassem. Eles realmente não conseguiram.
Independentemente da falta de previsão por parte dos desenvolvedores e profissionais de segurança, quando uma vulnerabilidade de dia zero aparece, algo precisa ser feito. Especialmente se uma organização estiver vulnerável porque está executando a tecnologia em questão. É isso que transforma o risco em ameaça , e as ameaças precisam ser neutralizadas.
É aí que a programabilidade dos serviços de aplicação entra em cena.
A programabilidade de serviços de aplicativos não é nenhuma novidade. As organizações têm usado a programabilidade desde os primórdios da Internet para implementar uma variedade de soluções.
Os usos mais comuns da programabilidade no caminho de dados incluem:
Sabemos que elas são comuns porque nossos dados internos nos dizem que são. Mais de 70% dos nossos clientes usam a programabilidade diariamente para uma ampla variedade de soluções. Alguns deles estão focados em segurança.
Portanto, não foi surpresa quando pesquisamos o mercado em geral e descobrimos que a programabilidade está no topo dos recursos técnicos importantes para a segurança de API.
A versatilidade de uma solução de segurança de API que oferece suporte à programabilidade é praticamente ilimitada. E embora a F5 certamente tenha sido pioneira nessa capacidade, ela se tornou um produto básico do mercado para serviços de aplicativos em geral. Existem muito poucos serviços de aplicativos — e particularmente aqueles focados em proteger aplicativos e APIs — que não oferecem programabilidade como parte de seus principais recursos.
Isso ocorre porque a programabilidade é a base para mitigar ameaças de dia zero e permitir que as organizações projetem planos de patch mais deliberadamente, que impactam uma porcentagem significativa de seus sistemas.
A programabilidade faz, bem, quase tudo. Mas no campo da segurança — especialmente da segurança de API — não é apenas algo “bom de se ter”. É essencial.
Para mais insights sobre API, confira nosso Relatório de Estratégia de Estado de Aplicativos: Segurança de API.