Fundamentos de Proof-Driven AppSec

Por que volume de alertas não é segurança

A maioria dos programas de segurança de aplicações sabe dizer quantos alertas tem. Bem menos sabem dizer quais desses alertas um atacante consegue de fato explorar, o que cada um afeta e se a correção chegou à produção. Este curso começa por essa lacuna, porque o restante da plataforma foi construído para fechá-la.

Uma contagem de alertas mede quantas ferramentas você roda e quantas regras elas aplicam. Ela não mede risco. Quatro problemas explicam a diferença.

Proliferação de ferramentas

As equipes costumam adicionar ferramentas uma categoria por vez: um analisador estático para o código, um verificador de dependências, um scanner de segredos, um verificador de infraestrutura como código, um scanner de imagens de contêiner. Cada uma tem seu próprio console, sua própria escala de severidade e seu próprio formato de saída. A mesma dependência vulnerável pode aparecer em duas ou três delas com nomes e severidades diferentes, e ninguém é responsável pela visão consolidada. Os engenheiros acabam conciliando exportações em vez de corrigir código.

O Plexicus reúne a saída dos scanners em um único formato de achado e elimina as duplicatas, e o achado que permanece fica com a pior severidade entre as suas duplicatas. Você também pode importar resultados de scanners de terceiros compatíveis (por exemplo, em SARIF) para o mesmo fluxo de trabalho. O módulo 3 aborda os mecanismos de análise, a cobertura e a regra exata de deduplicação.

Ruído

Pense em um resultado de análise estática intitulado “possível injeção de SQL no handler de login”. Pode ser uma falha real e explorável no formulário de login, em que o nome de usuário vai direto para a string da consulta. Também pode ser uma consulta montada a partir de uma constante em um helper de testes, que nenhuma entrada de usuário jamais alcança. Os dois chegam com o mesmo rótulo e, muitas vezes, com a mesma severidade.

Quando a maioria dos alertas acaba sendo do segundo tipo, os desenvolvedores aprendem a ler a lista por cima, e os alertas reais também acabam lidos por cima. O que separa os dois casos é a evidência: se existe um caminho da entrada controlada pelo atacante até o código vulnerável, se o código é sequer alcançável e se uma segunda verificação, independente, confirma o resultado.

O gargalo da remediação

Detectar não é corrigir. Cada achado em aberto é trabalho que sua equipe ainda deve. Encontrar um novo problema é barato. Corrigi-lo exige um desenvolvedor que entenda o código, uma mudança que não quebre nada, uma revisão e um merge. Se a fila cresce mais rápido do que a equipe consegue fechá-la, mais detecção só aumenta o backlog, sem deixar a aplicação mais segura. O verdadeiro gargalo está no contexto e nas mudanças revisáveis, não na falta de alertas.

Postura sem visibilidade

Tente responder a estas perguntas a partir de uma lista bruta de alertas. Quais três repositórios concentram mais risco explorável? Você está fechando achados mais rápido do que os cria? Quanto tempo um achado crítico fica em aberto? Uma pilha crescente de alertas não responde a nenhuma delas. A liderança vê um número que só sobe, e a próxima auditoria encontra os mesmos problemas de novo.

Escanear com mais frequência tem o mesmo limite. Um scan noturno que reporta a mesma injeção de SQL não corrigida durante um mês mede atividade, não progresso. A frequência de scans diz quantas vezes você olhou, não se algo ficou mais seguro.

O Dashboard do Plexicus segue a mesma ideia: os totais contam apenas o trabalho em aberto (módulo 2). A aba CISO mostra Risk Posture Score, New vs Fixed e Top Risky Repositories. A aba DevSecOps acrescenta alcançabilidade, idade dos achados e velocidade de remediação.

O ciclo Proof-Driven: Validar, Entender, Remediar

O Plexicus chama a sua abordagem de Proof-Driven AppSec: saiba o que é real, entenda o que isso afeta e corrija com evidência. A abordagem tem três etapas, e cada etapa é um produto.

Etapa	Produto	Pergunta que responde	O que você recebe
Validar	AI Swarm Pentest	Isso pode mesmo ser explorado dentro do escopo autorizado?	Achados verificados com evidência reproduzível, uma prioridade e um handover documentado
Entender	Deep Code Analysis	Que código, dados e fluxo de negócio isso afeta, e um atacante consegue alcançá-lo?	O fluxo afetado, sua alcançabilidade e exposição, uma classe de fraqueza CWE e uma prioridade
Remediar	Remediation	Que mudança resolve o problema, e a mudança funcionou?	Uma mudança pronta para revisão, com a evidência anexada, entregue pelo seu fluxo de pull requests, além de re-tests de verificação onde estiverem configurados

Validar com o AI Swarm Pentest

O AI Swarm Pentest é um engagement autorizado e com escopo definido contra uma aplicação, API, código-fonte ou ambiente de testes. Verificações de IA coordenadas mapeiam a superfície de ataque, formulam hipóteses e testam caminhos, e uma segunda rodada confirma cada achado de forma independente antes que ele seja marcado como verificado. Não é um scanner de assinaturas nem um chatbot de segurança. No produto, ele aparece como AI Pentest na seção Pentest. O módulo 6 aborda o tema em profundidade.

Entender com o Deep Code Analysis

Uma regra de análise estática consegue sinalizar um padrão, e um modelo de linguagem consegue explicar código. Nenhum dos dois estabelece como uma fraqueza afeta a sua aplicação. O Deep Code Analysis conecta o achado ao código, ao fluxo de dados e ao impacto no negócio. Para cada achado, você recebe o fluxo afetado (source, propagação e sink), se um atacante consegue alcançá-lo e a partir de onde (alcançabilidade e exposição à internet), e uma classe de fraqueza mapeada para CWE e OWASP. O módulo 5 aborda esse produto.

Remediar com o Remediation

Depois que um achado é verificado, o Remediation prepara o contexto e uma mudança sugerida na forma de um diff pronto para revisão. Sua equipe revisa e decide se faz o merge. Quando é feito o merge do pull request, o Plexicus marca o achado como Fixed. Dependendo do seu plano e da configuração, um teste de verificação pode checar a correção antes de o pull request ser aberto e, no caso de um achado de pentest, você pode repetir o scan da avaliação para confirmar que o caminho foi fechado. O módulo 7 aborda o fluxo de trabalho.

Onde entram o XBOM e o Plexicus Automation

Dois produtos trabalham ao lado do ciclo, e não dentro de uma etapa:

• XBOM é um inventário único de componentes de software (SBOM), ativos criptográficos (CBOM) e modelos de IA (AIBOM), com declarações VEX que registram se uma vulnerabilidade conhecida afeta você. Ele responde a perguntas como “onde distribuímos a versão vulnerável desta biblioteca?” e gera evidências para auditorias. O módulo 8 aborda o XBOM.
• Plexicus Automation encaminha achados para correções, tickets, aprovações e notificações, por exemplo quando um achado é criado, enriquecido ou reaberto. Apenas administradores podem ativar um fluxo. O módulo 9 aborda o Plexicus Automation.

SAST, SCA, verificações de infraestrutura como código, detecção de segredos e resultados importados de scanners oferecem cobertura de apoio. Eles fornecem sinais que alimentam o ciclo. Não o substituem.

O padrão de evidência e seus guardrails

A regra por trás de cada entregável do Plexicus cabe em uma linha: sem prova reproduzível, não há achado verificado. Esta lição aborda o que conta como prova, como um sinal se torna um achado verificado e os quatro guardrails que mantêm um engagement dentro dos limites acordados.

Prova reproduzível

Cada achado em um entregável do AI Swarm Pentest traz evidências que outra pessoa consegue reproduzir: a requisição, a resposta, os passos e o impacto demonstrado. “O scanner disse” não é prova. Os achados de pentest no produto podem incluir uma prova de conceito para replay, como um comando cURL, um script de shell ou uma captura HAR. Ela é exibida exatamente como foi registrada e não é executada novamente a partir do seu navegador.

Verificação independente

Um sinal não vira um achado verificado só porque uma verificação diz que sim. Uma segunda rodada precisa confirmar o comportamento observado de forma independente.

Estágio	O que significa	O que acontece em seguida
Achado candidato	Uma hipótese gerou um sinal com contexto técnico	Ele segue para verificação independente
Achado verificado	Uma segunda rodada reproduziu o resultado	Ele entra no entregável com impacto e prioridade
Não confirmado	A segunda rodada não conseguiu reproduzi-lo	Ele é marcado como não verificado ou descartado, e nunca é reportado como verificado

Aplique a mesma disciplina ao fazer a triagem de resultados de scanners. A tela de detalhes do achado mostra a severidade do scanner ao lado da severidade validada por IA (“Severity — scanner vs AI”). Ela também identifica a origem de cada etapa de um rastreamento de fluxo de dados, como Scanner dataflow ou AI-verified. Trate qualquer etapa marcada como AI-inferred (unverified) como uma pista a verificar, e não como prova (o módulo 5 explica como os rastreamentos são verificados).

Os quatro guardrails

Em um engagement de AI Swarm Pentest, o padrão de evidência é sustentado por quatro guardrails. São os mesmos quatro que você verá na página pública do AI Swarm Pentest, e o módulo 6 os aplica em profundidade.

Guardrail	O que significa para você
Escopo acordado por escrito	O alvo (uma aplicação, API, código-fonte ou ambiente de testes), o acesso de teste e as regras de atuação são confirmados antes de o trabalho começar. O Plexicus não atua fora desse escopo.
Evidência rastreável	A evidência de apoio permanece anexada ao achado que ela explica.
Limites do engagement	Tempo, recursos e acessos são limitados, para que cada execução permaneça sob controle.
Decisão humana	Sua equipe mantém a aprovação final e o controle de cada mudança. O Plexicus não faz alterações automáticas em produção.

Como o produto garante o escopo

Você só consegue iniciar um AI Pentest depois de provar que é dono do alvo. Para uma aplicação, a prova é feita com um token em uma meta tag HTML ou em um arquivo em /.well-known/. Para um domínio inteiro, a prova é feita com um registro DNS TXT. Aceitar os termos de serviço não conta como prova. Em uma nova avaliação, “Destructive actions” já vem pré-selecionado como fora do escopo, e o assistente recomenda testar o ambiente de staging em vez do de produção.

Decisão humana e controle do merge

A IA automatiza o trabalho repetitivo de exploração, correlação e reprodução. Sua equipe mantém o contexto, a supervisão e a decisão final. No produto, a decisão de uma pessoa em “Mark as false positive” prevalece, e as rodadas posteriores de IA não a substituem. As correções preparadas por IA vêm com uma nota pedindo que o revisor valide a mudança.

O Plexicus nunca modifica a produção. Ele entrega apenas propostas revisáveis, como pull requests ou arquivos de patch separados. O agente de correção por IA edita um clone isolado do seu repositório. O Plexicus faz push da mudança apenas para uma nova branch e abre um pull request contra a sua branch base, e nunca faz o merge desse pull request. O merge é sempre uma decisão da sua equipe, no seu próprio controle de código-fonte.

Um mapa da plataforma e de quem a usa

A barra lateral principal leva você a Dashboard, Assets, Pentest, Findings, XBOM, à página Automations e a Settings. Docs e Support ficam na parte inferior. Pressione ⌘K (Ctrl+K no Windows e no Linux) para abrir uma paleta de comandos e ir direto a qualquer seção.

Área	O que você faz ali	Quem mais usa
Dashboard	Acompanhar a postura pelas abas CISO, DevSecOps, Compliance, Developer e Custom, com filtros por período e por repositório	Líderes de segurança, engenheiros de segurança, desenvolvedores
Assets	Gerenciar os repositórios conectados na aba Repo Scan: adicionar repositórios, acompanhar scans, escanear novamente. As abas Registry Audit e Cloud Assessment ficam disponíveis conforme o seu plano	Engenheiros de segurança, responsáveis pela plataforma
Pentest	Criar avaliações de AI Pentest, verificar a propriedade do alvo, acompanhar as execuções e abrir os resultados	Engenheiros de segurança
Findings	Fazer a triagem dos achados nas abas Repo, SCM, Cloud, Registry e App Pentest. Abrir um achado para revisar a evidência, criar um ticket ou iniciar a remediação	Engenheiros de segurança, desenvolvedores
XBOM	Navegar pelos inventários Software (SBOM), Cryptography (CBOM) e AI Models (AIBOM), definir declarações VEX e exportar	Engenheiros de segurança, compliance, responsáveis pela plataforma
Automations	Criar fluxos que encaminham achados para correções, tickets e aprovações	Administradores criam e ativam os fluxos
Settings	Organization (equipe, funções, verificação de propriedade), Configuration (integrações, opções da plataforma, faturamento) e My Account (dados da conta, autenticação, tokens)	Administradores e responsáveis pela plataforma, além de todos os usuários para a própria conta

Três tipos de usuários

• Engenheiros de segurança (AppSec e DevSecOps) fazem a triagem dos achados, configuram scans, executam avaliações de AI Pentest e repassam o trabalho verificado aos desenvolvedores.
• Desenvolvedores trabalham nos achados atribuídos a eles, revisam correções preparadas por IA e abrem pull requests. Muitos preferem fazer isso pela IDE ou pelo terminal, o que o módulo 9 aborda.
• Responsáveis pela plataforma implantam e operam o Plexicus, conectam o controle de código-fonte e os provedores de identidade e gerenciam as configurações da organização.

Visão geral das funções nativas

Função	Para que serve
Admin	Administração completa da organização: equipe, funções, configurações, integrações, faturamento e o registro de auditoria. Admins também podem gerar remediações e abrir pull requests.
Cyberoper	A função de operador de segurança. Faz a triagem de achados, marca falsos positivos, gera remediações e usa Send to Dev Team para atribuir trabalho. Por padrão, não abre pull requests.
Developer	Trabalha nos achados atribuídos a ele e abre pull requests para as correções que estão Ready to Fix.

A divisão é intencional. Com as funções padrão, quem prepara uma correção e quem a propõe para a base de código podem ser pessoas diferentes. Um Cyberoper gera e revisa a mudança, e um Developer abre o pull request. Dependendo do seu plano, os administradores também podem criar funções personalizadas em Settings Roles . As funções nativas não podem ser renomeadas nem excluídas. O módulo 10 aborda funções, SSO e o registro de auditoria em detalhes.

Fundamentos de implantação e confiança

O Plexicus roda como SaaS na UE ou auto-hospedado, e o air-gapped é uma variante do auto-hospedado. O produto é o mesmo em todos os casos; só mudam a hospedagem e os limites de rede.

Opção	Onde roda	Quando escolher
SaaS na UE (padrão)	Hospedado pela Plexicus em app.plexicus.ai, operado sob um compromisso de residência de dados na UE (consulte trust.plexicus.ai)	A maioria das equipes. Não há infraestrutura para gerenciar, e as atualizações são automáticas
Auto-hospedado	Seu próprio cluster Kubernetes, on-premises ou em uma conta de nuvem que você controla, instalado com o Helm chart oficial	Requisitos rígidos de residência de dados, compliance ou isolamento de rede
Air-gapped (variante auto-hospedada)	A instalação auto-hospedada via Helm, com imagens espelhadas em um registro interno e o seu próprio emissor interno de certificados	Clusters sem acesso à internet pública ou com controles rígidos de tráfego de saída

O que significa “auto-hospedado”

Auto-hospedado e on-premises são o mesmo produto, o mesmo chart e a mesma licença, e uma implantação auto-hospedada não envia telemetria, dados analíticos nem dados de feedback para fora do seu cluster. Os recursos que dependem dos serviços comerciais da Plexicus, como o faturamento, ficam desativados, e apenas as integrações que você mesmo configura, como o seu controle de código-fonte e o seu provedor de IA, se comunicam com sistemas externos. O módulo 10 aborda Helm, instalações air-gapped e backups.

Seu código e a IA

• O código dos clientes não é usado para treinar modelos de IA.
• O SaaS do Plexicus é operado sob um compromisso de residência de dados na UE (consulte trust.plexicus.ai). A pessoa jurídica, PLEXICUS, S.L., tem sede em Bilbao, na Espanha, sob jurisdição da UE.
• Os recursos de IA enviam o contexto de código relevante para o endpoint de modelo configurado. Esse endpoint é, por padrão, o dos modelos gerenciados pela Plexicus ou, dependendo do seu plano, o do seu próprio provedor de IA, configurado em Settings BYOAI .

Confiança e evidências

A Plexicus tem certificação SOC 2 Type II. Uma empresa independente faz um pentest na plataforma todos os anos. O relatório SOC 2, um modelo de DPA, o resumo do teste de invasão e as respostas a questionários de segurança ficam disponíveis em autoatendimento no portal de confiança, em trust.plexicus.ai. Para reportar uma vulnerabilidade no próprio Plexicus, escreva para info@plexicus.ai.

Seja preciso ao falar de compliance. O Plexicus não coloca a sua organização em conformidade com NIS2, o Artigo 28 do DORA, o CRA ou o EU AI Act. Ele mapeia os achados para os frameworks que você seleciona, como NIS2, DORA e o CRA, na aba Compliance do Dashboard, e as atestações do XBOM podem ser pontuadas em relação a perfis como EU CRA e EU AI Act. Depois, os seus auditores avaliam essas evidências. O módulo 8 aborda o tema em detalhes.

Principais pontos

• O volume de alertas mede a saída das ferramentas, não o risco. A proliferação de ferramentas, o ruído, o gargalo da remediação e a postura sem visibilidade mantêm as equipes ocupadas sem deixá-las mais seguras.
• Proof-Driven AppSec é um ciclo: Validar com o AI Swarm Pentest, Entender com o Deep Code Analysis e Remediar com o Remediation. XBOM e Plexicus Automation trabalham ao lado dele.
• Sem prova reproduzível, não há achado verificado. Um resultado que uma segunda rodada não consegue reproduzir é marcado como não verificado ou descartado.
• Em um engagement de AI Swarm Pentest, valem quatro guardrails: escopo acordado por escrito, evidência rastreável, limites do engagement e decisão humana. O Plexicus não faz alterações automáticas em produção, e a sua equipe sempre mantém o controle do merge.
• A barra lateral leva você a Dashboard, Assets, Pentest, Findings, XBOM, à página Automations e a Settings. As três funções nativas, Admin, Cyberoper e Developer, dividem as responsabilidades.
• SaaS na UE é o padrão, e as instalações auto-hospedadas via Helm e air-gapped rodam o mesmo produto. O código dos clientes não é usado para treinar IA. A Plexicus tem SOC 2 Type II, e a plataforma gera evidências, e não conformidade, para os seus frameworks.