ASPM · Compliance Intelligence · nativo do GitLab

Prioridade, custo e evidência a partir dos scanners que o seu GitLab já roda.

O FFAST lê os resultados de SAST, DAST, Container Scanning, Dependency Scanning e Secret Detection, ordena o que importa pelo risco do seu negócio, calcula o preço de cada causa pela folha da sua equipe e pelo contexto do seu negócio e liga o finding ao controle regulatório quando a fraqueza (CWE) tem correspondência.

Solicitar demonstração Como é implantado

01 O caminho do dado

Siga um finding.

  1. 01 Scanners

    Três alertas. Um problema.

    O Dependency Scanning encontra a mesma CVE em dois manifestos do serviço de cadastro de clientes. O Container Scanning encontra de novo na imagem publicada. No GitLab, são três alertas.

    CVE-2025-24813 · tomcat-embed-core 10.1.34 · execução remota por PUT parcial

    dependency_scanning services/cadastro/pom.xml critical

    dependency_scanning services/documentos/pom.xml critical

    container_scanning api-cadastro:2.14 critical

  2. 02 Finding

    Uma causa raiz.

    O FFAST normaliza os três relatórios e agrupa por projeto e CVE: um upgrade resolve os três. A fila conta causas, não alertas.

    3 1

    causa: api-cadastro · CVE-2025-24813

    representante: a detecção mais antiga, há 47 dias

  3. 03 CRISP

    Risco 83 de 100.

    A severidade técnica é multiplicada pelo contexto do seu negócio. Aqui o serviço é público, trata dado pessoal financeiro (a classe mais alta do produto) e a CVE está no catálogo de exploração ativa da CISA.

    • severidade crítica 10
    • internet pública × 2,0
    • dado pessoal financeiro × 2,0
    • exploração ativa (KEV) × 2,0
    • 47 dias em aberto × 1,5
    • = 120

    83 / 100

  4. 04 Fila

    Primeiro da fila.

    A ordem de remediação sai da nota, não do CVSS. O relógio é o da sua política de SLA: para crítica, 3 dias.

    1º

    SLA crítica · 3 dias

    estourado há 44 dias

  5. 05 CREX

    O preço desta causa.

    A folha da sua equipe e as horas para corrigir, multiplicadas pelo contexto desta causa: serviço público, dado pessoal financeiro, exploração ativa e 47 dias em aberto. A economia de corrigir antes do deploy sai deste mesmo número.

    R$ 560.250

    R$ 14.940 80 h × R$ 186,75/h

    × 37,5 o contexto desta causa

  6. 06 Controle

    Postura no controle certo.

    A fraqueza por trás da causa (CWE) tem correspondência na base; por isso, a causa é ligada aos controles que fere. A postura de cada controle sai da cobertura dos scanners e dos findings abertos: quando a correção fecha a causa, o controle deixa de contá-la.

    • ISO/IEC 27001:2022 A.8.8 Gestão de vulnerabilidades técnicas
    • LGPD art. 46 Medidas de segurança
    • postura cobertura Dependency e Container Scanning · 1 causa aberta

  1. CVE-2025-24813 · tomcat-embed-core 10.1.34 · execução remota por PUT parcial

    dependency_scanning services/cadastro/pom.xml critical

    dependency_scanning services/documentos/pom.xml critical

    container_scanning api-cadastro:2.14 critical

  2. 3 1

    causa: api-cadastro · CVE-2025-24813

    representante: a detecção mais antiga, há 47 dias

    • severidade crítica 10
    • internet pública × 2,0
    • dado pessoal financeiro × 2,0
    • exploração ativa (KEV) × 2,0
    • 47 dias em aberto × 1,5
    • = 120

    83 / 100

  4. 1º

    SLA crítica · 3 dias

    estourado há 44 dias

  5. R$ 560.250

    R$ 14.940 80 h × R$ 186,75/h

    × 37,5 o contexto desta causa

    • ISO/IEC 27001:2022 A.8.8 Gestão de vulnerabilidades técnicas
    • LGPD art. 46 Medidas de segurança
    • postura cobertura Dependency e Container Scanning · 1 causa aberta

Exemplo ilustrativo. Os fatores, os pesos e as fórmulas são os do produto.

O FFAST não é um scanner.

Ele não repete o que a sua esteira já faz. Consome o resultado dos scanners nativos do GitLab e responde à pergunta que vem depois: o que corrigir primeiro, quanto custa corrigir e o que isso significa diante da norma pela qual você é auditado.

02 Quatro pilares

Quatro pilares

Cada pilar declara o que entra e o que sai. Os pesos são os do produto; o contexto de cada projeto é declarado por você ou presumido, e a origem fica à vista.

CRISP

Contextual Risk Index for Security Prioritization

Ordena a fila de remediação por risco real, não por severidade nominal.

Entra

  • Severidade técnica do finding
  • Exposição do projeto na rede
  • Classe de dado que o projeto trata
  • Exploração observada (EPSS, KEV) ou segredo vazado
  • Idade do finding em aberto

Sai

Um índice de 0 a 100 por finding, que define a ordem da fila.

CREX

Contextual Risk EXposure

O preço, em reais, de cada causa: a folha da sua equipe e as horas para corrigir, multiplicadas pelo contexto do seu negócio. É o número que o CEO e o board entendem.

Entra

  • A folha do seu time por perfil e as horas de correção por severidade
  • O contexto que as equipes declaram: exposição do projeto, tipo de dado, exploração (EPSS e KEV), idade e indústria
  • NIST e IBM, ao lado e em letra menor, como referência de mercado

Sai

O CREX de cada causa e do backlog: o que se gasta para corrigir ainda no desenvolvimento e o que vai custar se chegar à produção. A economia do shift-left é calculada sobre o mesmo número.

DORA

Métricas de entrega

O DORA do GitLab, do jeito que o GitLab calcula, e ao lado o DORA canônico.

Entra

  • O DORA do próprio GitLab, lido da API dele e exibido sem reinterpretação
  • Pipelines, deployments e incidentes do seu GitLab, para o cálculo canônico
  • Recorte por grupo, projeto e período

Sai

As quatro métricas nas duas leituras, lado a lado. No canônico, o lead time vai do primeiro commit da mudança ao deploy em produção, onde o GitLab parte do merge; a taxa de falha conta o deploy com incidente declarado ou com sinal no próprio deploy (falha, rollback, finding crítico em até 72 horas). A origem de cada sinal fica exposta.

GRC e DPO

Compliance intelligence

Diz ao DPO e à engenharia qual artigo de lei cada finding fere, e onde ele se corrige.

Entra

  • Findings abertos e a cobertura dos scanners em cada projeto
  • Base de 137 frameworks e 2.867 controles, um por artigo, com LGPD, BACEN e CMN
  • O setor declarado de cada projeto: norma setorial só conta onde se aplica
  • Inventário de licenças de software

Sai

Para cada finding, a obrigação que ele fere (por exemplo, LGPD art. 46) e se ela se corrige no pipeline ou pede processo e atestação. O mesmo dado em duas vistas: a jurídica, por lei e artigo, com o texto do artigo e os sistemas afetados; e a técnica, com os findings, a tarefa de correção e a dispensa com justificativa. Aceite de risco com prazo, atestação de controle, postura por framework e um dossiê em PDF das obrigações violadas.

A caminho

  • A instrução de correção de cada artigo, por setor e por camada: o que muda no pipeline e o que muda na organização
  • Relatório de impacto à proteção de dados (RIPD) a partir dos sistemas afetados
  • Registro das operações de tratamento (RoPA)
  • Notificação de incidente à ANPD e atendimento aos titulares

03 Base regulatória

137

frameworks regulatórios

2.867

controles na base

3

modelos de custo declarados

5

scanners GitLab consumidos

04 Roda dentro do seu perímetro

Roda dentro do seu perímetro

Não é SaaS multi-inquilino. É uma entrega, no seu ambiente, com o seu banco de dados.

Detalhes da implantação

  • Um container na sua infraestrutura. O dado nasce e morre do seu lado da fronteira.
  • O FFAST não envia nenhum dado do cliente para fora do seu ambiente. Além do seu próprio GitLab, as conexões de saída são: a verificação de licença, a cada 4 minutos, com o identificador da instância e da instalação (o servidor de licença vê o endereço IP de origem e o registra no log de acesso); e, por padrão, o download das bases públicas EPSS e KEV, que pode ser desligado. Com o enriquecimento desligado e a licença por arquivo, a única conexão de saída é com o seu GitLab. O arquivo de conferência de cobrança, que o cliente decide entregar à Dooper, traz contagens e os dados da leitura (mês e dia, origem, grupo lido no GitLab, teto e folga) e a data de geração; nenhuma pessoa; a lista pseudonimizada de contestação só é mostrada em reunião, sem cópia.
  • O FFAST não transmite nenhum finding, trecho de código, nome de repositório ou dado de colaborador para fora da sua infraestrutura.
  • Autenticação pelo seu próprio GitLab, self-hosted ou SaaS.

05 O que não dá para medir é declarado, não inventado

O que não dá para medir é declarado, não inventado

Métrica sem sinal de origem vira número bonito e decisão errada. Quando o ambiente não fornece o dado, o FFAST diz que não fornece — e mostra o que falta para passar a fornecer. O mesmo vale para o modelo de custo: o número financeiro nunca aparece sem o modelo que o gerou.

Quer ver rodando no seu GitLab?

A conversa começa técnica: 45 minutos olhando a sua estrutura de grupos, os scanners que já rodam e o tamanho do backlog.

Solicitar demonstração