A cibersegurança tem um problema estranho.
Todos dizem que querem reduzir o risco. Mas, com demasiada frequência, a forma como avaliamos os produtos recompensa algo mais restrito: a rapidez com que um fornecedor consegue demonstrar valor numa Prova de Conceito (PoC).
Pode ser implementado rapidamente? Pode funcionar sem agente? Pode produzir um relatório limpo? Pode mapear para OWASP, NIST, o Regulamento Europeu de IA, ou a estrutura mais recente? Pode preencher requisitos suficientes no RFP?
A armadilha das caixas de seleção
As equipas de segurança estão sobrecarregadas. Todos os anos trazem uma nova superfície de ataque, categoria, framework e requisito de conformidade.
Assim, os compradores simplificam. Eles criam grelhas. Eles comparam funcionalidades. Eles pedem implementação rápida, valor imediato e cobertura de frameworks.
Isso faz sentido. Mas tem uma consequência não intencional.
A forma como avaliamos os produtos de segurança molda o que as startups constroem. Se o mercado recompensa o valor rápido da PoC, dashboards sem agente, ampla cobertura de requisitos e relatórios polidos mais do que profundidade, precisão e operacionalização, as startups construirão para esse mercado.
O tempo rápido para o valor importa. A implementação sem agente importa. A cobertura de frameworks importa. Mas quando estes se tornam a avaliação completa, criamos um mercado onde as startups otimizam para as primeiras duas semanas de uma PoC em vez dos próximos cinco anos de redução de risco empresarial.
A IA vai piorar isto
Uma pequena equipa pode agora 'vibe-codificar' uma UI limpa, alguns fluxos de trabalho, um relatório polido e mapeamento de frameworks suficiente para parecer credível. Isso não significa que possa sobreviver numa empresa.
Nunca substituiríamos o Salesforce por um CRM 'vibe-codificado' depois de ver três ecrãs bonitos. Perguntaríamos se escala, se integra com o negócio, suporta permissões e fluxos de trabalho, produz evidências de auditoria, treina utilizadores e sobrevive a anos de uso operacional.
A segurança merece o mesmo padrão.
Os frameworks são úteis. As caixas de seleção não são suficientes.
Frameworks como OWASP, NIST, o Regulamento Europeu de IA, MITRE e CIS dão às equipas uma linguagem comum. O erro é tratar cada requisito como uma pergunta de sim ou não.
Considere BOLA, Broken Object Level Authorization, o risco número um no Top 10 de APIs da OWASP. Em termos simples, BOLA significa que um utilizador pode aceder aos dados de outra pessoa alterando um identificador.
Imagine que abro a minha aplicação bancária e a aplicação faz a seguinte chamada:
GET /accounts/12345
A API devolve o meu nome, e-mail, saldo, transações recentes e os últimos quatro dígitos da minha conta bancária. Se um atacante alterar o ID e obtiver os detalhes da conta de outro cliente, isso é BOLA.
Em muitas avaliações, o teste é óbvio: um scanner envia 1.000 chamadas de API em poucos segundos, alterando rapidamente os IDs. A maioria das ferramentas consegue detectar isso. É barulhento, rápido e fácil de reconhecer.
Atacantes reais são mais pacientes. Eles podem enumerar lentamente ao longo de horas ou dias, usar tokens válidos, alterar um valor a cada poucos minutos e mover-se entre contas, endpoints, sessões, regiões ou unidades de negócio. Cada requisição pode parecer normal por si só.
Agentes de IA pioram isso. Se os agentes estiverem conectados a essas APIs, os atacantes podem usá-los para explorar e explorar caminhos de autorização fracos mais rapidamente. A vulnerabilidade da API já era séria. O acesso por agentes a torna escalável.
Na Salt, investimos pesadamente em um motor de intenção de big data para detectar esse comportamento lento e discreto: não apenas se alguém alterou um ID, mas se o seu comportamento mostra a intenção de enumerar objetos aos quais não deveria ter acesso.
As equipes que testaram isso entenderam a diferença. Mas muitas avaliações não tinham uma forma clara de pontuar. Se dois fornecedores mostrassem “BOLA detectado” no teste ruidoso, ambos recebiam a mesma marca de verificação.
A profundidade desapareceu na planilha.
O showroom não é a estrada
Uma POV é o showroom. A produção é a estrada.
No showroom, tudo é controlado. O conjunto de dados é limitado. O fornecedor está observando de perto. O painel está limpo. O relatório parece bom.
Então a solução entra em produção, e equipes reais a herdam.
A AppSec prioriza as descobertas. O SOC decide o que importa. A Engenharia precisa de tickets que possa corrigir. O Risco precisa de evidências. As unidades de negócio precisam de propriedade. As ferramentas existentes precisam de integração.
Frequentemente, os avaliadores não são os usuários diários. É por isso que a operacionalização importa.
O verdadeiro teste não é a clareza da primeira semana. É se o produto ainda cria valor seis meses depois, em todas as unidades de negócio, equipes distribuídas, dados ruidosos, exceções, lacunas de propriedade e atacantes reais.
O mesmo se aplica ao fornecedor: eles ajudam a construir o programa, treinar equipes e impulsionar a adoção, ou apenas reagem depois que o negócio é fechado?
Aprendemos isso da maneira mais difícil
Na Salt, aprendemos isso da maneira mais difícil.
Começamos com tecnologia. Focamos nos problemas mais difíceis primeiro: análise comportamental profunda, detecção precisa, padrões de ataque complexos e compreensão em tempo de execução que abordagens superficiais frequentemente ignoram.
Alguns clientes entenderam imediatamente por que essa profundidade importava. Mas muitas avaliações não foram projetadas para medi-la. Elas foram projetadas para comparar colunas: implanta rapidamente, suporta este framework, tem este relatório e mostra algo impressionante na primeira reunião?
Isso nos forçou a aprender uma lição importante: a profundidade importa, mas a profundidade também precisa ser embalada de uma forma que o mercado possa adotar.
Então construímos a jornada: valor sem implantação, visibilidade e governança sem agente, e depois proteção completa em tempo de execução. Tornar mais fácil começar, sem abrir mão da profundidade necessária para realmente proteger uma empresa.
Isso levou mais de oito anos. A verdadeira profundidade de segurança é difícil de construir. Se as avaliações não a medem, menos empresas investirão nela.
Avalie o caminho, não apenas o showroom
O ecossistema de startups responde a incentivos.
Se os compradores recompensam dashboards de primeiro dia, mapeamentos amplos de frameworks e implantação sem atrito acima de tudo, os fornecedores otimizarão para isso.
Então pergunte o que a ferramenta não consegue ver sem uma integração mais profunda ou visibilidade em tempo de execução. Pergunte quão profundamente ela cobre cada requisito e como ela se comporta quando o ambiente está bagunçado. Pergunte o que acontece seis meses depois, quando equipes reais, fluxos de trabalho, atacantes e consequências aparecem.
O valor rápido importa. Mas precisa se tornar um valor mais profundo.
POVs importam. RFPs importam. Frameworks importam.
Mas eles não são o objetivo.
O objetivo é tornar a empresa mais segura.
Se queremos que as startups construam para isso, temos que avaliar para isso.
Agentes de IA impulsionam a inovação, mas também introduzem riscos invisíveis. A Plataforma de Segurança Agêntica™ da Salt oferece visibilidade e controle totais, para que você possa reduzir riscos, cumprir a conformidade e manter-se resiliente. Agende uma demonstração para saber mais.