Metodologia de Criticidade Contextual da YAGA

1. Introdução e Motivação

A criticidade final atribuída a uma vulnerabilidade em um relatório de pentest é, com frequência, o ponto de maior dúvida na comunicação entre times de segurança e times de negócio. Ela nasce da combinação de vários sinais, técnicos, de ameaça e de contexto de negócio, e não da leitura direta de um único score de origem. Este documento existe para explicar, com transparência total e com o detalhamento matemático completo, como a YAGA (agente autônomo de pentest da HackerSec) forma essa criticidade a partir desses sinais.

O objetivo deste artigo é técnico, não promocional. Ele descreve, em ordem de grandeza e em lógica de raciocínio, quais dados de entrada a YAGA consome, quais famílias de fórmulas aplica, em que ordem, e por que cada etapa existe. Sempre que um conceito é um padrão público e verificável (CVSS 4.0, CISA KEV, FIRST EPSS, o modelo FAIR de quantificação de risco, ISO/IEC 27005, NIST SP 800-30), ele é apresentado conforme a especificação oficial, com a fonte citada. Sempre que um valor é específico do motor de risco da YAGA (pesos de calibração, limiares de decisão, fatores de correlação), ele é apresentado como parâmetro operacional ilustrativo da HackerSec, com ordem de grandeza plausível e claramente identificado como tal, não como a calibração operacional exata em produção, que é ajustada continuamente e não é publicada em sua forma completa.

Este documento também é a instanciação matemática detalhada, especificamente para o eixo de criticidade de vulnerabilidade, de uma metodologia mais ampla já proposta pela equipe de pesquisa da HackerSec para mapeamento de risco adversarial e análise de impacto de negócio em segurança ofensiva, a Adversarial Risk Mapping and Assessment (ARMA), que integra visualização de cadeia de ataque, mapeamento de compliance e pontuação de impacto para demonstrar como vulnerabilidades isoladas escalam para ameaças críticas à continuidade operacional, à conformidade regulatória e à estabilidade financeira [1]. O leitor interessado no framework de mapeamento de cadeia de ataque e impacto de negócio de forma mais ampla, além do escopo específico de criticidade tratado aqui, deve consultar essa referência.

A tese central deste artigo, desenvolvida em detalhe nas seções seguintes, é simples de enunciar e difícil de operacionalizar corretamente: um score técnico isolado, como o CVSS, mede severidade de impacto, não risco. Risco é uma função de três eixos independentes, probabilidade real de exploração, magnitude de impacto no ativo específico, e contexto de negócio do ambiente onde o ativo vive. A YAGA calcula esses três eixos separadamente e só então os recombina em um score final de criticidade, que frequentemente diverge de qualquer score técnico tomado isoladamente, exatamente porque nenhum score técnico isolado teve a pretensão de responder a pergunta “qual o impacto real disso no meu negócio, hoje, neste ambiente”.

2. Sinais de Severidade Técnica e os Limites de um Score Único

2.1 O Que o CVSS Mede de Fato

O Common Vulnerability Scoring System, na sua versão 4.0, é estruturado em quatro grupos de métricas [2]. O grupo Base captura a exploitabilidade intrínseca da vulnerabilidade (vetor de ataque AV, complexidade de ataque AC, requisitos de ataque AT, privilégios necessários PR, interação do usuário UI) e o impacto sobre o sistema vulnerável e sobre sistemas subsequentes (confidencialidade, integridade e disponibilidade, tanto VC/VI/VA quanto SC/SI/SA). O grupo Threat carrega uma única métrica, Exploit Maturity (E), que descreve se existe evidência real de exploração no mercado. O grupo Environmental permite ajustar os requisitos de segurança do ativo (Confidentiality Requirement, Integrity Requirement, Availability Requirement) e sobrepor as métricas base com valores modificados observados no ambiente real. O grupo Supplemental, opcional e sem peso numérico definido pela especificação, descreve dimensões operacionais como Safety, Automatable, Recovery, Value Density, Vulnerability Response Effort e Provider Urgency.

O ponto central é que, na prática de mercado, praticamente todo scanner automatizado, toda base pública de CVEs, e a maioria dos relatórios de pentest manuais publicam apenas o score Base. Os grupos Threat, Environmental e Supplemental, que são exatamente os grupos desenhados pela própria especificação para incorporar contexto real de ameaça e de negócio, são deixados como “Not Defined” (X) na enorme maioria dos casos, porque exigem dados a que um scanner não tem acesso e que um pentester manual raramente coleta de forma sistemática. A especificação define que, quando não preenchido, o valor Not Defined é tratado numericamente como equivalente ao pior caso (a métrica não reduz o score).

O resultado prático é que o número de CVSS que circula no mercado é, quase sempre, apenas o score Base, calculado sob a suposição implícita de que a exploração já é madura, que o ativo tem requisitos de segurança máximos, e que não existe nenhum controle compensatório em nenhum lugar. Essa suposição de pior caso universal é deliberada e correta como piso conservador de severidade técnica, mas ela não é, e nunca pretendeu ser, uma estimativa de risco real para um ativo específico. A literatura de quantificação de risco em segurança é explícita sobre essa limitação estrutural, bandas ordinais fixas (Baixo, Médio, Alto, Crítico) construídas sobre um único score agregado sofrem de perda de informação, de efeitos de arredondamento na fronteira das faixas, e de uma falsa sensação de precisão que mascara a incerteza real da estimativa subjacente [3].

2.2 A Separação Fundamental: Probabilidade Contra Impacto

A distinção mais importante deste artigo é a separação entre dois eixos que o CVSS Base tende a misturar em um único número, probabilidade de exploração e magnitude de impacto. O próprio FIRST.org, mantenedor tanto do CVSS quanto do EPSS, é explícito sobre essa separação de propósitos, o EPSS foi desenhado especificamente para complementar o CVSS ao fornecer a probabilidade estatística de exploração em uma janela de tempo, enquanto o CVSS descreve a severidade caso a exploração ocorra [4]. São eixos ortogonais. Uma vulnerabilidade pode ter severidade técnica altíssima (CVSS 9.8) e probabilidade de exploração real desprezível, porque o vetor exige acesso a um segmento de rede inacessível pela internet, ou porque não existe nenhum exploit público conhecido e o CVE é obscuro. E o inverso também ocorre, uma vulnerabilidade de severidade moderada em CVSS pode ter uma probabilidade de exploração próxima de 100%, porque está sob exploração ativa e massiva no momento em que o finding é reportado.

O motor de risco da YAGA formaliza essa separação em duas trilhas de cálculo de probabilidade, dependendo da existência de um identificador CVE conhecido, descritas na próxima seção, e uma camada de ajuste de impacto e contexto de negócio, descrita na Seção 5, que se aplica igualmente às duas trilhas.

3. A Camada de Sinalização de Ameaça Conhecida: KEV e EPSS

Quando o finding corresponde a um CVE catalogado, a YAGA prioriza dois sinais externos, objetivos e atualizados diariamente, sobre a estimativa de probabilidade de exploração, em vez de depender apenas do score Base do CVSS para inferir a ameaça.

3.1 CISA KEV: Confirmação Binária de Exploração Ativa

O catálogo Known Exploited Vulnerabilities, mantido pela Cybersecurity and Infrastructure Security Agency dos Estados Unidos, lista CVEs com evidência confirmada de exploração ativa em ambientes reais [5]. A presença de um CVE nesse catálogo é tratada pela YAGA como sinal binário de máxima confiança,

K(v) = { 1   se v ∈ catálogo KEV
0   caso contrário

Quando K(v) = 1, a YAGA trata a probabilidade de exploração como próxima do limite superior, independentemente do valor numérico do EPSS naquele instante, porque KEV não é uma predição estatística, é um fato observado. A única situação em que esse sinal não força a criticidade final para Crítico é quando o ativo específico está comprovadamente fora de qualquer caminho de exploração viável (por exemplo, um componente vulnerável presente no código mas nunca instanciado, ou isolado em um segmento sem rota de rede possível), caso em que o achado é rebaixado para informativo com justificativa técnica explícita, não por ausência de gravidade do CVE, mas por inexistência de superfície de ataque real.

3.2 EPSS: Probabilidade Estatística de Exploração

O Exploit Prediction Scoring System, mantido pelo FIRST.org, é um modelo estatístico treinado sobre um grande volume de metadados de CVEs (idade da publicação, referências públicas, menções em redes e listas de discussão, disponibilidade de código de exploração, fornecedor, categoria CWE, entre outras features) que produz uma probabilidade calibrada de que aquele CVE específico seja observado sob exploração ativa em uma janela padrão de 30 dias [4],

EPSS(v) : v → [0, 1]

O EPSS é atualizado diariamente e sua distribuição é fortemente assimétrica, a grande maioria dos CVEs cadastrados tem EPSS abaixo de 0,01, e apenas uma fração pequena, tipicamente CVEs com exploit público maduro ou sob exploração observada, concentra a massa de probabilidade acima de 0,5. Isso significa que EPSS alto já é, por construção estatística, um evento raro e informativo, e a YAGA trata qualquer EPSS acima do percentil 90 histórico do próprio corpus como sinal forte de priorização, mesmo antes de qualquer ajuste de contexto de negócio.

3.3 Limitações de Cobertura do EPSS

Duas limitações práticas do EPSS são explicitamente tratadas no pipeline da YAGA. A primeira é a esparsidade em CVEs muito recentes, o modelo depende de features que se acumulam com o tempo (menções, exploits publicados, discussão em comunidades), então um CVE publicado há poucas horas tende a ter EPSS artificialmente baixo simplesmente por falta de sinal acumulado, não por baixa gravidade real. A segunda é que o EPSS descreve o comportamento médio do ecossistema global de atacantes, não o interesse específico de um agente de ameaça contra o setor ou a organização do cliente. A primeira limitação é tratada revalidando o EPSS do finding a cada nova execução de scan durante o engajamento, em vez de congelar o valor no momento da descoberta. A segunda é tratada pelo fator de correlação setorial descrito na Seção 5.9, que complementa o EPSS com inteligência de ameaça específica do setor de atuação do cliente.

Quando não há CVE algum associado ao finding, situação comum em vulnerabilidades lógicas, de negócio, ou em código proprietário nunca antes catalogado, KEV e EPSS simplesmente não existem como sinal, e a YAGA transita para a segunda trilha, descrita na próxima seção.

4. Quando Não Há CVE: CVSS 4.0 Preenchido com Evidência Real

4.1 O Problema do “Not Defined” e a Inflação Sistemática de Severidade

Como descrito na Seção 3, a especificação CVSS 4.0 trata métricas Threat, Environmental e Supplemental não preenchidas como equivalentes ao pior caso. Isso é correto como convenção conservadora de publicação de CVE genérico (o mantenedor do CVE não conhece o ambiente de nenhum consumidor específico daquele CVE), mas é uma escolha inadequada quando o próprio agente que descobriu a vulnerabilidade tem acesso direto às evidências reais do ambiente. Manter “Not Defined” nesse caso não é neutralidade, é desperdício deliberado de informação disponível.

A YAGA nunca publica um CVSS com métricas Threat e Environmental em “Not Defined” quando o achado se origina de um engajamento ativo. Em vez disso, preenche cada uma dessas métricas com evidência coletada durante o próprio pentest,

TABELA 1: Origem das métricas CVSS 4.0

Métrica	Origem no scanner genérico	Origem na YAGA
Exploit Maturity (E)	Deixada em Not Defined (equivale a pior caso)	Derivada diretamente de K(v) e EPSS(v) quando há CVE, ou do resultado real de exploração obtido pelo próprio agente quando não há
Confidentiality/Integrity/Availability Requirement (CR/IR/AR)	Deixada em Not Defined (equivale a Medium)	Derivada da classificação de dados e criticidade do ativo obtida do inventário e da varredura de conteúdo real
Modified Base Metrics	Raramente preenchida, requer reteste manual	Derivada de evidência coletada em runtime, presença real de WAF, segmentação observada, autenticação efetivamente exigida

Para o grupo Threat especificamente, a regra de preenchimento da YAGA é,

E(v) = { Attacked   se K(v) = 1
POC   se K(v) = 0 e EPSS(v) ≥ 0.30
Unreported   caso contrário

O limiar de 0,30 é calibrado sobre o corpus histórico de CVEs cuja evolução de EPSS foi acompanhada até a confirmação ou não de exploração ativa, e é revisado periodicamente conforme o modelo EPSS é retreinado pelo FIRST.org.

4.2 Impacto Prático do Preenchimento Correto

O efeito líquido de preencher Threat e Environmental com evidência real, em vez de aceitar o padrão Not Defined, é que o mesmo CVE pode produzir scores CVSS 4.0 finais bastante diferentes dependendo do ativo. Um CVE com Exploit Maturity real classificada como Unreported (sem exploit conhecido, EPSS baixo) e Availability Requirement Low (ativo não crítico para disponibilidade) tem seu score reduzido em relação ao Base publicado. Um CVE com Exploit Maturity Attacked e Confidentiality Requirement High (ativo processa dados sensíveis) tem seu score elevado, às vezes acima do próprio Base publicado na base pública, porque o Base genérico assume Medium para os requisitos de segurança, não High.

Essa etapa, importante notar, ainda produz um número na escala técnica do CVSS, de 0 a 10. Ela responde “qual a severidade técnica desta vulnerabilidade, neste ativo, com a informação real que temos”, mas ainda não incorpora explicitamente o valor financeiro do ativo, a probabilidade de perda em unidades de negócio, nem o efeito de correlação com outros achados. Essa incorporação é o papel da camada seguinte, o motor de contexto de risco.

5. O Motor de Contexto de Risco da YAGA

5.1 Visão Geral do Pipeline

Independentemente de o finding ter chegado pela trilha KEV/EPSS ou pela trilha CVSS 4.0 contextualizado, ambas convergem para um único score de severidade técnica de entrada, S_tec(v) ∈ [0, 10],

S_tec(v) = { g(K(v), EPSS(v), CVSS_impacto(v))   se v possui CVE conhecido
CVSS_4.0(v)   caso contrário, com Threat/Environmental preenchidos por evidência

onde g(·) combina a probabilidade de exploração (KEV/EPSS) com a magnitude de impacto derivada do subvetor de impacto do CVSS (VC, VI, VA, SC, SI, SA), preservando a separação entre os dois eixos mesmo quando o CVE é conhecido. A partir de S_tec(v), o motor de contexto da YAGA aplica sete transformações sequenciais, cada uma descrita em uma subseção a seguir, para produzir o score final de criticidade R_final(v, a) para o par vulnerabilidade-ativo (v, a).

5.2 Annualized Rate of Occurrence a Partir da Janela de Exposição

O conceito de Annualized Rate of Occurrence (ARO), oriundo da literatura clássica de gestão quantitativa de risco [6], [7], representa a frequência esperada de ocorrência de um evento de perda. A YAGA adapta esse conceito à realidade de vulnerability management ao definir ARO não como probabilidade ao longo de um ano corrido arbitrário, mas como a probabilidade de exploração ocorrer dentro da janela de exposição real do finding, ou seja, o tempo entre a descoberta e a remediação efetiva, definido pela SLA de severidade adotada pela organização,

ARO_EPSS(v) = 1 − (1 − EPSS(v))^t_exp/30

onde t_exp é o número de dias da janela de exposição (a SLA de remediação aplicável à severidade técnica do achado) e o expoente converte a probabilidade calibrada em janela de 30 dias do EPSS para a janela de exposição real, sob a suposição simplificadora de independência entre subjanelas sucessivas de 30 dias, uma aproximação padrão em atuária de risco e amplamente utilizada em modelos FAIR de quantificação [8], ainda que conservadora quando a janela real é muito mais curta que um ano, como é o caso de SLAs de remediação críticas.

Quando o CVE está no catálogo KEV, o ARO é definido por um piso de exploração já confirmada, independente do cálculo estatístico do EPSS,

ARO(v) = max(ARO_EPSS(v), 0.95 × K(v))

O ARO é recalculado a cada execução, porque tanto o EPSS quanto o tempo restante da janela de exposição mudam continuamente, o que torna a criticidade um valor vivo, não uma fotografia estática do dia da descoberta.

5.3 Inferência Bayesiana da Probabilidade Real de Exploração

O ARO derivado de EPSS/KEV representa a probabilidade de exploração no ecossistema global de ameaças, sem considerar ainda as particularidades do ativo específico. A YAGA trata esse valor como probabilidade a priori e o atualiza via inferência Bayesiana com evidência coletada durante o próprio engajamento,

P(exploração real | E) = ARO(v) × P(E | exploração real) ARO(v) × P(E | exploração real) + (1 − ARO(v)) × P(E | ¬ exploração real)

Reescrevendo em forma de razões de chance (odds), que simplifica a combinação de múltiplas evidências independentes sob a suposição de Naive Bayes,

odds_priori = ARO(v) 1 − ARO(v)     odds_posteriori = odds_priori × ∏_i LR(E_i)     P(exploração real | E) = odds_posteriori 1 + odds_posteriori

onde LR(E_i) é a razão de verossimilhança de cada item de evidência de contexto observado pelo agente durante o pentest. A YAGA utiliza três categorias de evidência de probabilidade, cada uma com uma tabela de calibração de LR baseada no corpus histórico,

TABELA 2: Razões de verossimilhança (LR) por categoria de evidência

Evidência (Ei)	Condição	LR calibrado
Exposição do ativo à internet	Sim / Não	3,0 / 0,15
Controle preventivo efetivo na rota (WAF, autenticação, rate limit)	Ausente / Presente	2,5 / 0,50
Correlação setorial de ameaças T(v) (Seção 5.9)	Alta (T > 0.30) / Média / Baixa ou nula	8,0 / 2,0 / 1,0

5.4 Valor de Negócio do Ativo

O impacto de uma exploração bem sucedida depende diretamente do que está em jogo. A YAGA compõe um índice de valor de negócio do ativo, AV_bus(a) ∈ [0, 10], a partir de quatro dimensões coletadas do inventário de ativos e do contexto fornecido pelo cliente,

AV_bus(a) = w₁C_receita(a) + w₂C_dados(a) + w₃C_regulatório(a) + w₄C_{disponibilidade}(a)

com ∑_i w_i = 1 e cada componente normalizado em [0, 10], dependência direta de receita do ativo, sensibilidade dos dados que ele processa ou armazena, exposição regulatória associada (LGPD, PCI DSS, Bacen, setor específico do cliente), e criticidade de disponibilidade operacional. Um gateway de pagamentos em produção tipicamente aparece próximo ao topo dessa escala em todas as quatro dimensões, enquanto um ambiente de homologação isolado, sem dados reais de cliente e sem exposição regulatória, aparece próximo à base.

5.5 Fator de Exposição e Controles Compensatórios

O Exposure Factor (EF) representa a fração do valor do ativo efetivamente em risco caso a exploração se concretize, derivado do subvetor de impacto do CVSS (a magnitude técnica do dano possível) e atenuado por controles compensatórios de contenção (não os mesmos controles preventivos usados na inferência Bayesiana da probabilidade, mas controles que limitam o raio de dano depois que a exploração já ocorreu, segmentação de rede que limita movimento lateral, backups que limitam perda de integridade, monitoramento com contenção rápida que limita tempo de exposição),

EF(v, a) = EF_base(VC, VI, VA de v) × (1 − CCE(a))

onde CCE(a) ∈ [0, 1] é o índice agregado de efetividade dos controles compensatórios de contenção presentes no ambiente daquele ativo específico, coletado por evidência direta (segmentação observada em varredura de rede, existência e testabilidade de rotina de backup, cobertura real de monitoramento validada durante o engajamento), nunca assumido.

5.6 Single e Annualized Loss Expectancy

Com o valor do ativo e o fator de exposição definidos, a YAGA calcula a perda esperada em caso único de exploração (Single Loss Expectancy) e a perda esperada ponderada pela probabilidade real de ocorrência dentro da janela de exposição (Annualized/Adjusted Loss Expectancy), seguindo a formulação clássica de FAIR [8],

SLE(v, a) = AV_bus(a) × EF(v, a)       ALE(v, a) = SLE(v, a) × P(exploração real | E)

Ambos os termos são expressos em unidades normalizadas de perda, na mesma escala [0, 10] de AV_bus, calibráveis para moeda local pela organização mediante um fator de conversão definido em conjunto com o cliente (por exemplo, 1 unidade normalizada equivalente a um valor de referência em reais, derivado do custo médio de incidente da própria organização ou do setor).

5.7 Multiplicador de Ambiente

O ambiente onde o ativo vive, produção, homologação, desenvolvimento ou sandbox isolado, altera diretamente a probabilidade de que uma perda calculada em condições de produção se materialize de fato. A YAGA aplica um multiplicador de ambiente M_amb sobre a perda esperada,

TABELA 3: Multiplicador de ambiente

Ambiente	Mamb	Justificativa
Produção	1,00	Perda materializa-se diretamente sobre dados e operação real do negócio
Homologação/Staging	0,35	Dados sintéticos ou mascarados, mas com risco residual de promoção acidental para produção ou de reuso de credenciais/configuração
Desenvolvimento	0,15	Isolamento maior, ainda com risco de exposição de segredos e de propagação de padrão vulnerável ao código de produção
Sandbox isolado/Laboratório	0,05	Sem rota de rede real e sem dados sensíveis, risco residual essencialmente estrutural

ALE_eff(v, a) = ALE(v, a) × M_amb(env(a))

É essencial destacar que M_amb não reduz a severidade técnica S_tec(v), apenas o termo de perda de negócio esperada. Um achado crítico em homologação continua tecnicamente crítico, ele apenas representa, hoje, uma perda de negócio esperada muito menor do que o mesmo achado em produção, o que é precisamente o mecanismo central deste artigo.

5.8 Correlação com Findings Similares no Corpus Histórico da YAGA

O corpus de mais de 30.000 findings validados, acumulado pela YAGA ao longo de engajamentos anteriores, permite estimar empiricamente com que frequência achados tecnicamente e contextualmente similares a este foram, de fato, confirmados como exploráveis e escalados a impacto real, versus quantos foram desconfirmados ou permaneceram teóricos após reteste. Esse fator, H(v) ∈ [0, 1], é calculado por similaridade ponderada sobre um conjunto de findings de referência,

H(v) = ∑_j=1ⁿ sim(v, f_j) × outcome(f_j) ∑_j=1ⁿ sim(v, f_j)

onde sim(v, f_j) ∈ [0, 1] é a similaridade (por CWE, padrão de endpoint, stack tecnológico e classe de payload, calculada por similaridade de cosseno sobre representações vetoriais dos findings) entre o achado atual e cada um dos n findings históricos mais próximos, e outcome(f_j) ∈ [0, 1] registra o desfecho real daquele finding histórico (confirmado explorável e escalado a incidente real, parcialmente confirmado, ou descartado em reteste). H(v) funciona como um corretor empírico independente da probabilidade estatística de mercado (EPSS), capturando padrões específicos de como determinada classe de vulnerabilidade se comporta no tipo de arquitetura observado, informação que nenhum score genérico consegue capturar.

5.9 Correlação Setorial de Ameaças e Panorama Competitivo

A probabilidade de exploração de mercado (EPSS) descreve o comportamento médio global de atacantes contra qualquer alvo com aquele CVE. Ela não captura se o setor de atuação específico do cliente, ou organizações de perfil e porte equivalente (pares de indústria, concorrentes diretos e indiretos), está sendo ativamente mirado por campanhas explorando aquela mesma classe de vulnerabilidade. A YAGA mantém um fator de correlação setorial, T(v) ∈ [0, 1],

T(v) = n_{campanhas ativas explorando CWE/padrão equivalente no setor, janela de 90 dias} n_{campanhas monitoradas no setor no mesmo período}

construído a partir de inteligência de ameaça correlacionada por setor vertical (varejo, pagamentos, saúde, governo, entre outros) e mapeada a técnicas equivalentes de MITRE ATT&CK. Quando T(v) é elevado, a YAGA interpreta isso como evidência de que o mesmo padrão de ataque já demonstrou sucesso contra organizações de perfil comparável ao do cliente, o que eleva diretamente a razão de verossimilhança LR(E₃) utilizada na atualização Bayesiana descrita anteriormente. Em outras palavras, se um concorrente direto ou um par de indústria já foi comprometido por uma classe de ataque equivalente nos últimos 90 dias, essa evidência pesa objetivamente a favor de tratar o achado atual como mais provável de ser explorado, independentemente do que o EPSS genérico do CVE sozinho sugira.

5.10 Composição Final e Floor de Severidade Técnica

Os fatores anteriores são combinados em uma soma ponderada e integralmente auditável, deliberadamente linear e não uma função de ativação opaca, para que cada componente do score final possa ser inspecionado e justificado item a item no relatório entregue ao cliente,

R_contextual(v, a) = α × S_tec(v) + β × 10z_ALE(v, a) + γ × 10H(v) − δ × 10 CCE(a)

com pesos calibrados por regressão periódica sobre o corpus histórico de findings validados, correlacionando severidade prevista com desfecho real observado em reteste, atualmente α = 0.30, β = 0.45, γ = 0.15, δ = 0.10, e a normalização logarítmica da perda esperada efetiva,

z_ALE(v, a) = min ( 1, ln(1 + ALE_eff(v, a)) ln(1 + ALE_max) )

onde ALE_max é o teto de referência calibrado sobre o maior valor de perda normalizada observado no corpus histórico da YAGA (parâmetro operacional, revisado a cada ciclo de recalibração).

Por fim, para evitar que a matemática de contexto suprima integralmente um achado tecnicamente grave apenas porque, no instante da avaliação, o ambiente reduz a perda de negócio esperada, a YAGA aplica um piso mínimo de severidade técnica,

Floor(S_tec(v)) = { 4.0   se S_tec(v) ≥ 9.0
3.0   se 7.0 ≤ S_tec(v) < 9.0
0   caso contrário

R_final(v, a) = max(R_contextual(v, a), Floor(S_tec(v)))

Esse piso garante que uma vulnerabilidade tecnicamente crítica nunca desapareça do radar do cliente, mesmo quando o contexto atual de negócio reduz drasticamente a perda esperada, porque ambientes mudam (uma homologação pode ser promovida a produção, um controle compensatório pode ser removido em uma manutenção) e a gravidade técnica intrínseca permanece latente até a correção efetiva do defeito.

5.11 Cisnes Negros e Antifragilidade: A Justificativa Teórica do Floor

O piso mínimo de severidade técnica não é um ajuste arbitrário de conservadorismo, ele tem fundamento teórico direto na crítica de Nassim Nicholas Taleb à extrapolação estatística de eventos raros e de alto impacto. Em “O Cisne Negro”, Taleb descreve dois domínios distintos, Mediocristan, onde variáveis seguem distribuições bem comportadas e a média histórica é um bom preditor do próximo evento, e Extremistan, onde um único evento extremo e improvável domina o resultado agregado de forma desproporcional, e onde modelos treinados sobre o histórico sistematicamente subestimam a cauda porque o evento que mais importa é, por definição, o que ainda não está representado nos dados [9]. EPSS, ARO, H(v) e T(v) são, todos, estimativas construídas sobre comportamento observado no passado, competentes em Mediocristan, exploração de CVEs em geral, mas estruturalmente vulneráveis ao mesmo ponto cego em Extremistan, a descoberta de uma nova cadeia de exploração, a virada abrupta de um CVE obscuro para exploração em massa, ou a mudança de interesse de um agente de ameaça específico contra aquele setor, eventos que por natureza carregam pouco ou nenhum histórico para o modelo aprender antes de acontecerem.

O floor de severidade técnica é a resposta estrutural, não estatística, a essa limitação, e nesse sentido segue diretamente o princípio que Taleb chama de antifragilidade em “Antifrágil”, um sistema robusto tenta resistir ao choque previsto, um sistema antifrágil é desenhado para não depender de prever corretamente o choque em primeiro lugar, ele limita o dano do lado de baixo (downside) mesmo quando o modelo probabilístico está errado [10]. Ao nunca deixar R_final cair abaixo de 4,0 para uma vulnerabilidade com S_tec ≥ 9.0, independentemente de quão favoráveis pareçam o contexto e a matemática de probabilidade hoje, a YAGA aceita um custo pequeno e conhecido (o achado permanece visível e rastreado mesmo quando a matemática de contexto sugere baixo risco imediato) para eliminar um custo potencialmente catastrófico e desconhecido (um cisne negro, uma cadeia de exploração ainda não observada, materializando-se exatamente sobre um achado que o próprio modelo havia classificado como de baixo risco por ausência de evidência histórica). Isso é, na prática, uma escolha deliberada de assimetria de risco em favor da fragilidade zero no pior caso, mesmo ao custo de alguma imprecisão no caso médio.

6. Estudo de Caso: Mesma Vulnerabilidade, Criticidades Diferentes por Contexto

Para tornar concreto todo o mecanismo descrito, esta seção aplica o pipeline completo a um único CVE ilustrativo, presente em dois ativos distintos do mesmo cliente. Os valores numéricos abaixo são exemplos didáticos, com ordem de grandeza realista, não dados de um cliente real.

Vulnerabilidade base (idêntica nos dois cenários): biblioteca de desserialização insegura permitindo execução remota de código não autenticada. CVSS_4.0 = 9.8 (Crítico), sem entrada no catálogo KEV (K(v) = 0), EPSS(v) = 0.61. SLA de remediação para severidade Crítica adotada pelo cliente, t_exp = 7 dias.

ARO_EPSS(v) = 1 − (1 − 0.61)^7/30 = 1 − 0.39^0.2333 ≈ 1 − 0.8026 = 0.1974     odds_priori = 0.1974 0.8026 ≈ 0.2459

Esse resultado, aproximadamente 19,7% de probabilidade de tentativa de exploração dentro dos 7 dias da janela de remediação, é o único termo comum aos dois cenários. Tudo o que se segue diverge por causa do contexto do ativo.

6.1 Cenário A: Ambiente de Homologação Isolado

Ativo em ambiente de homologação, sem exposição à internet, com WAF e segmentação de rede efetivamente validados, dados sintéticos de teste, sem correlação relevante com campanhas setoriais contra esse tipo de ativo interno, e baixa taxa histórica de escalada em findings similares nesse tipo de ambiente.

Parâmetro	Valor
LR(E1), não exposto à internet	0,15
LR(E2), controle preventivo presente	0,50
LR(E3), correlação setorial baixa	1,00
LRtotal	0,15 × 0,50 × 1,00 = 0,075
oddsposteriori	0,2459 × 0,075 ≈ 0,0184
P(exploração real | E)	0,0184 / 1,0184 ≈ 1,81%
AVbus(a)	2,0 / 10
CCE(a), contenção	0,70
EF(v, a) = 0.95 × (1 − 0.70)	0,285
SLE(v, a) = 2.0 × 0.285	0,570
ALE(v, a) = 0.570 × 0.0181	0,0103
Mamb, homologação	0,35
ALEeff	0,0036
H(v), correlação histórica interna	0,08
zALE(v, a), com ALEmax = 8	≈ 0,0016

R_contextual = 0.30 × 9.8 + 0.45 × 10 × 0.0016 + 0.15 × 10 × 0.08 − 0.10 × 10 × 0.70
R_contextual = 2.94 + 0.007 + 0.12 − 0.70 = 2.37

Como S_tec(v) = 9.8 ≥ 9.0, aplica-se o floor de 4,0. R_final(v, a) = max(2.37, 4.0) = 4.0, banda Médio.

6.2 Cenário B: Ambiente de Produção, Ativo de Maior Valor

Mesmo CVE, agora presente no gateway de pagamentos em produção, exposto publicamente via API, sem cobertura de WAF na rota específica (endpoint recém publicado, ainda não incluído nas regras vigentes), sob escopo PCI DSS, com três campanhas ativas documentadas no setor de pagamentos nos últimos 90 dias explorando a mesma classe de vulnerabilidade, e alta taxa histórica de escalada real em findings similares dentro do corpus da YAGA.

Parâmetro	Valor
LR(E1), exposto à internet	3,00
LR(E2), controle preventivo ausente	2,50
LR(E3), correlação setorial alta	8,00
LRtotal	3,00 × 2,50 × 8,00 = 60,0
oddsposteriori	0,2459 × 60,0 ≈ 14,75
P(exploração real | E)	14,75 / 15,75 ≈ 93,65%
AVbus(a)	9,2 / 10
CCE(a), contenção	0,05
EF(v, a) = 0.95 × (1 − 0.05)	0,9025
SLE(v, a) = 9.2 × 0.9025	8,303
ALE(v, a) = 8.303 × 0.9365	7,776
Mamb, produção	1,00
ALEeff	7,776
H(v), correlação histórica interna	0,85
zALE(v, a), com ALEmax = 8	≈ 0,988

R_contextual = 0.30 × 9.8 + 0.45 × 10 × 0.988 + 0.15 × 10 × 0.85 − 0.10 × 10 × 0.05
R_contextual = 2.94 + 4.448 + 1.275 − 0.05 = 8.61

Como 8.61 ≥ Floor (4.0), o floor não altera o resultado. R_final(v, a) = 8.61, banda Crítico.

6.3 Comparação e Interpretação

TABELA 4: Mesmos sinais técnicos, criticidades finais divergentes

Grandeza	Cenário A (Homolog)	Cenário B (Produção)
CVSS 4.0 Base	9,8	9,8
EPSS	0,61	0,61
P(exploração real | E) posterior	1,81%	93,65%
ALE efetivo	0,0036	7,776
Rfinal	4,0 (Médio)	8,61 (Crítico)

Os dois achados compartilham exatamente os mesmos sinais técnicos de origem (CVSS Base 9,8 e EPSS 0,61). Nenhuma das duas entradas de “severidade de mercado” difere. O que diverge integralmente é a probabilidade real de exploração dado o contexto observado (1,81% contra 93,65%, uma diferença de mais de 50 vezes) e a perda de negócio esperada resultante (0,0036 contra 7,776 unidades normalizadas, uma diferença de mais de 2.100 vezes). Os sinais técnicos de origem continuam corretos nos dois casos, é a mesma vulnerabilidade, com o mesmo potencial de dano caso explorada com sucesso. O que nenhum deles isoladamente afirma, e nunca deveria ser lido como afirmando, é que a probabilidade e o impacto de negócio são os mesmos nos dois ambientes, essa é a lacuna que o motor de contexto da YAGA preenche.

7. Recálculo Contínuo e Ciclo de Vida do Finding

Todos os fatores descritos neste documento são dinâmicos, não estáticos. O EPSS varia diariamente conforme o modelo do FIRST.org é realimentado com novos dados de exploração observada no mercado. O ARO diminui conforme a janela de exposição t_exp se esgota, aumentando a urgência relativa do achado enquanto ele permanece aberto. O multiplicador de ambiente muda instantaneamente se um ativo em homologação é promovido para produção, situação que a YAGA trata como gatilho automático de reavaliação completa, não apenas do multiplicador, mas de todo o pipeline, porque o valor do ativo, os controles observados e a correlação setorial também tendem a mudar junto com o ambiente. O fator H(v) é recalculado a cada ciclo de retreinamento do corpus, incorporando o desfecho de engajamentos concluídos desde a última calibração. O fator T(v) é atualizado conforme novas campanhas setoriais são identificadas pela inteligência de ameaça monitorada. Isso significa que o mesmo finding pode subir ou descer de banda durante a vida do engajamento sem que nenhum dado técnico sobre a vulnerabilidade em si tenha mudado, e essa mudança é, por desenho, exatamente o comportamento esperado de um sistema de criticidade orientado a risco real e não a uma fotografia estática do dia da descoberta. Esse recálculo contínuo não é apenas ajuste de dado de entrada, é também autoavaliação de desempenho, o próprio H(v) (correlação com o desfecho real de findings passados) é, em essência, uma medição de quão bem o modelo previu risco no passado, reaplicada para calibrar a previsão presente, na linha do argumento de que medir a qualidade da própria medição de risco é, em segurança, a medição mais importante de todas, precisamente porque ela é o que impede que um processo de avaliação pareça rigoroso sem de fato prever nada de útil [11].

8. Transparência e Auditabilidade do Score

Cada um dos termos apresentados neste artigo, S_tec(v), ARO(v), cada LR(E_i) aplicado, AV_bus(a) e sua decomposição em quatro componentes, EF(v, a), CCE(a), ALE(v, a), M_amb, H(v), T(v), e o resultado final R_final(v, a) com indicação explícita de qual floor foi ou não aplicado, é registrado como metadado auditável do finding e pode ser anexado ao relatório entregue ao cliente, item a item, exatamente na forma tabular apresentada na seção anterior. Não existe etapa opaca ou caixa-preta neste pipeline, a composição final é deliberadamente uma soma ponderada linear, e não uma rede neural ou uma função de ativação não interpretável, precisamente para que qualquer diferença entre o score técnico de origem e a criticidade final possa ser explicada ao cliente até a última casa decimal, com a evidência de contexto que a justifica.

8.1 O Que é Ilustrativo Neste Documento e O Que é Auditável por Achado

É importante separar dois planos que este artigo trata de forma diferente. No plano do achado real, dentro de um engajamento em produção, o pacote de auditoria descrito no parágrafo anterior é concreto, específico daquele par vulnerabilidade-ativo, e entregue ao cliente. No plano deste documento, que é público e educativo, os pesos α, β, γ, δ, os limiares de LR, os multiplicadores de ambiente e os demais parâmetros numéricos são ilustrativos, escolhidos para ter ordem de grandeza plausível e demonstrar a lógica do raciocínio, não para serem a tabela de calibração operacional exata que a YAGA usa em produção, essa calibração é ajustada continuamente pelo próprio modelo à luz de novos desfechos validados e não é publicada em sua forma completa. A diferença é a mesma que existe entre explicar como um perito calcula um laudo, o raciocínio, as variáveis que pesam, a ordem em que são avaliadas, e entregar a régua exata e a tabela de conversão que o perito usa, para que qualquer pessoa sem a mesma experiência e sem acesso à mesma evidência possa produzir um laudo equivalente sozinha. Este artigo entrega o primeiro. O segundo continua sendo o motivo pelo qual o cliente contrata a YAGA em vez de calcular a criticidade por conta própria.

9. Extensão Analítica: Álgebra Linear, Razões e Números Complexos no Processamento Multi-Cenário

Todo o pipeline descrito nas seções anteriores foi apresentado achado por achado, por clareza didática. Na operação real de um engajamento, o modelo de linguagem que fundamenta a YAGA raramente avalia um achado isolado, ele avalia o portfólio completo de achados em conjunto, e o faz processando a evidência coletada pelo agente como estruturas de álgebra linear (vetores e matrizes) e, quando útil para agregação em nível de portfólio, como números complexos, em vez de repetir a mesma sequência de operações escalares achado por achado. O agente é responsável por coletar a evidência bruta durante o pentest (exposição, controles observados, similaridade semântica entre achados), e o modelo é responsável por formalizar essa evidência em estruturas algébricas e resolver as operações (produtos matriciais, decomposição espectral, razões e proporções, módulo e argumento de números complexos) dentro do próprio raciocínio, antes de emitir o score final e a justificativa de cada finding. As instruções operacionais do agente definem explicitamente um número elevado de cenários equivalentes de decisão matemática sobre os quais esse processamento se aplica, dos quais o exemplo a seguir é apenas uma instância ilustrativa [12].

9.1 Razão e Proporção: Conversão de Unidades Normalizadas em Moeda

A conversão de ALE_eff (unidades normalizadas de perda, Seção 5) em um valor monetário de referência segue uma regra de três simples, calibrada junto ao cliente a partir do custo médio de incidente da própria organização, considerando, de forma ilustrativa, 1 unidade normalizada equivalente a R$ 45.000,00,

1 45000 = 7.776 X → X = 7.776 × 45000 = 349920

Para o achado f₁ (Cenário B do estudo de caso, Seção 6), isso equivale a aproximadamente R$ 349.920,00 de perda esperada dentro da janela de exposição de 7 dias, o número que efetivamente entra na priorização orçamentária de remediação junto ao cliente.

9.2 Matriz de Evidência em Log-Domínio para um Portfólio de Achados

Considere um portfólio de n = 3 achados do mesmo engajamento, o RCE de desserialização do Cenário B (f₁), uma SQL Injection em painel administrativo interno em produção (f₂) e um XSS refletido em homologação (f₃). Em vez de calcular LR_total achado por achado através de multiplicação sequencial, o modelo constrói a matriz de log-verossimilhanças Λ ∈ ℝ^3×3 (linhas = achados, colunas = evidências E₁, E₂, E₃ da Seção 5) e resolve o produto contra o vetor unitário 1 em uma única operação matricial,

Λ = ( 1.09860.91632.07940.18230.40550.6931−1.6094−0.51080.0000 )    Λ · 1 = ( 4.09431.2809−2.1202 )

LR_total = exp(Λ · 1) = ( 60.003.600.12 )

O resultado confere exatamente com o produto direto das razões de verossimilhança de cada achado (3.00 × 2.50 × 8.00 = 60.0 para f₁, o mesmo LR_total do Cenário B na Seção 6), confirmando que a formulação matricial em log-domínio é algebricamente equivalente à multiplicação sequencial, com a vantagem de resolver o portfólio inteiro em uma única operação.

9.3 Decomposição Espectral: Concentração de Risco Sistêmico no Portfólio

Para detectar se os três achados compartilham uma causa raiz comum, o que reduziria o valor marginal de corrigi-los isoladamente, o modelo constrói a matriz de similaridade de cosseno C ∈ ℝ^3×3 entre os vetores de características de cada achado (padrão de CWE, stack tecnológico, padrão de endpoint),

C = ( 1.00000.98510.73570.98511.00000.71240.73570.71241.0000 )

C é real e simétrica, portanto diagonalizável com autovalores reais pelo teorema espectral. Por iteração de potência, o autovalor dominante converge para λ_max ≈ 2.63. A razão de concentração λ_max/n = 2.63/3 ≈ 0.877 indica que quase 88% da variância de risco do portfólio é explicada por um único fator latente comum, nesse caso, uma falha sistêmica de validação de entrada compartilhada pelas três classes de vulnerabilidade, e não três causas independentes. Essa leitura muda a recomendação de remediação entregue ao cliente, corrigir a causa raiz estrutural (a camada de validação de entrada) reduz o risco combinado do portfólio muito além do que a soma da remediação individual de cada achado sugeriria isoladamente.

9.4 Número Complexo: Plano de Risco de Magnitude e Fase do Achado Dominante

Para o achado f₁, o modelo representa simultaneamente a perda de negócio esperada e a correlação histórica de padrão como um único número complexo no plano de risco,

z(f₁) = ALE_eff(f₁) + i × 10H(f₁) = 7.776 + 8.5i

|z(f₁)| = √7.776² + 8.5² = √132.72 ≈ 11.52     θ(f₁) = arctan(8.5 / 7.776) ≈ 0.832 rad

A fase θ(f₁) ≈ 0.832 radianos (aproximadamente 47,7°) fica próxima da diagonal do plano, indicando equilíbrio entre os dois eixos, perda financeira projetada e correlação histórica de exploração real, o que reforça a classificação Crítica do Cenário B por duas linhas de evidência matematicamente independentes e simultâneas, não apenas uma. Achados com θ próximo de 0 são dominados por impacto financeiro isolado e priorizam controle compensatório imediato, achados com θ próximo de π/2 são dominados por padrão histórico de exploração e priorizam reteste de confirmação, e achados próximos da diagonal, como este, justificam ambas as ações em paralelo.

10. Conclusão

A criticidade final atribuída a uma vulnerabilidade ser diferente do seu score técnico de origem não é um defeito da metodologia da YAGA, é a evidência de que a metodologia está fazendo exatamente o que um score de severidade técnica isolado nunca foi desenhado para fazer, traduzir uma característica intrínseca da vulnerabilidade em uma estimativa de risco real para um ativo específico, em um ambiente específico, em um momento específico. O CVSS 4.0, quando disponível, permanece como um dos insumos indispensáveis de magnitude de impacto técnico, e a YAGA o preenche com evidência real de ameaça e de ambiente em vez de aceitar os padrões conservadores de “Not Defined” que inflacionam a severidade de praticamente todo scanner de mercado. Quando existe CVE catalogado, KEV e EPSS assumem o papel de estimar probabilidade de exploração com base em evidência de mercado real e atualizada diariamente, em vez de depender de heurísticas subjetivas. Sobre esses insumos, probabilidade e impacto, o motor de contexto de risco da YAGA aplica um pipeline matemático inteiramente transparente e auditável, ARO ajustado à janela de exposição real, atualização Bayesiana com evidência de exposição, controles e correlação setorial, valor de negócio do ativo, fator de exposição líquido de controles compensatórios, perda esperada single e ajustada (SLE/ALE) na tradição FAIR de quantificação de risco, multiplicador de ambiente, correlação com o histórico de mais de 30.000 findings já validados pela plataforma, e um piso de severidade técnica que impede que o contexto favorável de hoje apague permanentemente um defeito tecnicamente grave que pode se tornar crítico assim que o ambiente mudar.

O estudo de caso apresentado demonstra numericamente o argumento central deste artigo, o mesmo CVE, com os mesmos sinais técnicos de origem (CVSS 9,8 e EPSS 0,61), produz probabilidade real de exploração de 1,81% em um ambiente de homologação isolado e de 93,65% em um gateway de pagamentos em produção, uma diferença de mais de 50 vezes na probabilidade e de mais de 2.100 vezes na perda esperada, resultando em bandas finais de Médio e Crítico respectivamente. Nenhum dos dois resultados contradiz esses sinais de origem, ambos os complementam com a informação de probabilidade e de contexto de negócio que um score técnico isolado nunca teve a pretensão de carregar.

Nenhum modelo probabilístico, por mais rico que seja em variáveis, elimina a possibilidade de um evento raro e ainda não observado redefinir sozinho o risco real de um achado, essa é a lição que “O Cisne Negro” e “Antifrágil” trazem para fora do domínio financeiro em que Taleb originalmente a formulou, e que a YAGA incorpora estruturalmente através do floor de severidade técnica, ela não tenta prever o cisne negro, ela garante que o sistema não colapse silenciosamente caso um apareça [9], [10]. E nenhum desses cálculos existe isoladamente do quadro mais amplo de risco adversarial do engajamento, eles são a camada de criticidade por achado dentro da metodologia de mapeamento de cadeia de ataque e impacto de negócio que a HackerSec já havia formalizado como ARMA [1], aqui detalhada em profundidade matemática para responder à pergunta específica que motiva este documento, como a criticidade final de um achado se forma a partir de sinais técnicos, de ameaça e de contexto de negócio combinados.

Essa é a transparência que este documento se propôs a entregar, o raciocínio, a ordem de grandeza de cada variável e a fonte de cada fundamento externo estão aqui, de forma auditável e questionável item a item, ainda que a calibração operacional exata de produção, por natureza, continue evoluindo e não seja publicada em sua forma completa, exatamente porque quem calcula a criticidade final de cada achado real, com toda a evidência daquele engajamento específico, é o modelo de IA da YAGA, não uma fórmula estática que um terceiro possa reexecutar fora dele.

11. Referências