How YAGA Scores Contextual Criticality

1. Introduction and Motivation

The final criticality assigned to a vulnerability in a pentest report is often the point of greatest doubt in the communication between security teams and business teams. It arises from the combination of several signals, technical, threat-related and business-context-related, and not from the direct reading of a single origin score. This document exists to explain, with full transparency and complete mathematical detail, how YAGA (HackerSec's autonomous pentest agent) forms that criticality from those signals.

The goal of this article is technical, not promotional. It describes, in order of magnitude and in reasoning logic, which input data YAGA consumes, which families of formulas it applies, in what order, and why each step exists. Whenever a concept is a public and verifiable standard (CVSS 4.0, CISA KEV, FIRST EPSS, the FAIR model of risk quantification, ISO/IEC 27005, NIST SP 800-30), it is presented according to the official specification, with the source cited. Whenever a value is specific to YAGA's risk engine (calibration weights, decision thresholds, correlation factors), it is presented as an illustrative operational parameter of HackerSec, with plausible order of magnitude and clearly identified as such, not as the exact operational calibration used in production, which is continuously adjusted and is not published in full.

This document is also the detailed mathematical instantiation, specifically for the vulnerability criticality axis, of a broader methodology already proposed by HackerSec's research team for adversarial risk mapping and business impact analysis in offensive security, the Adversarial Risk Mapping and Assessment (ARMA), which integrates attack-chain visualization, compliance mapping and impact scoring to demonstrate how isolated vulnerabilities escalate into critical threats to operational continuity, regulatory compliance and financial stability [1]. The reader interested in the broader attack-chain and business-impact mapping framework, beyond the specific criticality scope treated here, should consult that reference.

The central thesis of this article, developed in detail in the following sections, is easy to state and hard to operationalize correctly: an isolated technical score, such as CVSS, measures impact severity, not risk. Risk is a function of three independent axes, real probability of exploitation, magnitude of impact on the specific asset, and business context of the environment where the asset lives. YAGA computes these three axes separately and only then recombines them into a final criticality score, which frequently diverges from any technical score taken in isolation, precisely because no isolated technical score ever intended to answer the question “what is the real impact of this on my business, today, in this environment”.

2. Technical Severity Signals and the Limits of a Single Score

2.1 What CVSS Actually Measures

The Common Vulnerability Scoring System, in its version 4.0, is structured into four metric groups [2]. The Base group captures the intrinsic exploitability of the vulnerability (attack vector AV, attack complexity AC, attack requirements AT, privileges required PR, user interaction UI) and the impact on the vulnerable system and on subsequent systems (confidentiality, integrity and availability, both VC/VI/VA and SC/SI/SA). The Threat group carries a single metric, Exploit Maturity (E), which describes whether there is real evidence of exploitation in the wild. The Environmental group allows adjusting the asset's security requirements (Confidentiality Requirement, Integrity Requirement, Availability Requirement) and overriding the base metrics with modified values observed in the real environment. The Supplemental group, optional and without numeric weight defined by the specification, describes operational dimensions such as Safety, Automatable, Recovery, Value Density, Vulnerability Response Effort and Provider Urgency.

The central point is that, in market practice, practically every automated scanner, every public CVE database, and most manual pentest reports publish only the Base score. The Threat, Environmental and Supplemental groups, which are precisely the groups designed by the specification itself to incorporate real threat and business context, are left as “Not Defined” (X) in the vast majority of cases, because they require data a scanner has no access to and that a manual pentester rarely collects systematically. The specification defines that, when not filled in, the Not Defined value is treated numerically as equivalent to the worst case (the metric does not reduce the score).

The practical result is that the CVSS number circulating in the market is almost always just the Base score, computed under the implicit assumption that exploitation is already mature, that the asset has maximum security requirements, and that there is no compensating control anywhere. This universal worst-case assumption is deliberate and correct as a conservative floor of technical severity, but it is not, and never intended to be, an estimate of real risk for a specific asset. The risk-quantification literature in security is explicit about this structural limitation, fixed ordinal bands (Low, Medium, High, Critical) built on a single aggregate score suffer from information loss, rounding effects at band boundaries, and a false sense of precision that masks the real uncertainty of the underlying estimate [3].

2.2 The Fundamental Separation: Probability Versus Impact

The most important distinction in this article is the separation between two axes that CVSS Base tends to blend into a single number, probability of exploitation and magnitude of impact. FIRST.org itself, maintainer of both CVSS and EPSS, is explicit about this separation of purposes, EPSS was designed specifically to complement CVSS by providing the statistical probability of exploitation within a time window, while CVSS describes the severity if exploitation occurs [4]. They are orthogonal axes. A vulnerability can have very high technical severity (CVSS 9.8) and negligible real probability of exploitation, because the vector requires access to a network segment unreachable from the internet, or because there is no known public exploit and the CVE is obscure. And the reverse also occurs, a vulnerability of moderate CVSS severity can have a probability of exploitation close to 100%, because it is under active and massive exploitation at the moment the finding is reported.

YAGA's risk engine formalizes this separation into two probability-computation tracks, depending on the existence of a known CVE identifier, described in the next section, and an impact and business-context adjustment layer, described in Section 5, which applies equally to both tracks.

3. The Known-Threat Signaling Layer: KEV and EPSS

When the finding corresponds to a cataloged CVE, YAGA prioritizes two external, objective and daily-updated signals over the exploitation-probability estimate, instead of relying only on the CVSS Base score to infer the threat.

3.1 CISA KEV: Binary Confirmation of Active Exploitation

The Known Exploited Vulnerabilities catalog, maintained by the United States Cybersecurity and Infrastructure Security Agency, lists CVEs with confirmed evidence of active exploitation in real environments [5]. The presence of a CVE in that catalog is treated by YAGA as a binary signal of maximum confidence,

K(v) = { 1   if v ∈ KEV catalog
0   otherwise

When K(v) = 1, YAGA treats the probability of exploitation as close to the upper bound, regardless of the numeric EPSS value at that instant, because KEV is not a statistical prediction, it is an observed fact. The only situation in which this signal does not force the final criticality to Critical is when the specific asset is provably outside any viable exploitation path (for example, a vulnerable component present in the code but never instantiated, or isolated in a segment with no possible network route), in which case the finding is downgraded to informational with an explicit technical justification, not for lack of severity of the CVE, but for absence of a real attack surface.

3.2 EPSS: Statistical Probability of Exploitation

The Exploit Prediction Scoring System, maintained by FIRST.org, is a statistical model trained on a large volume of CVE metadata (age of publication, public references, mentions in networks and mailing lists, availability of exploit code, vendor, CWE category, among others) that produces a calibrated probability that a specific CVE will be observed under active exploitation within a standard 30-day window [4],

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

EPSS is updated daily and its distribution is strongly skewed, the vast majority of registered CVEs have EPSS below 0.01, and only a small fraction, typically CVEs with a mature public exploit or under observed exploitation, concentrates the probability mass above 0.5. This means that a high EPSS is already, by statistical construction, a rare and informative event, and YAGA treats any EPSS above the historical 90th percentile of its own corpus as a strong prioritization signal, even before any business-context adjustment.

3.3 EPSS Coverage Limitations

Two practical limitations of EPSS are explicitly handled in YAGA's pipeline. The first is sparsity in very recent CVEs, the model depends on features that accumulate over time (mentions, published exploits, community discussion), so a CVE published a few hours ago tends to have an artificially low EPSS simply for lack of accumulated signal, not for low real severity. The second is that EPSS describes the average behavior of the global attacker ecosystem, not the specific interest of a threat actor against the client's sector or organization. The first limitation is handled by revalidating the finding's EPSS on every new scan execution during the engagement, instead of freezing the value at discovery time. The second is handled by the sector-correlation factor described in Section 5.9, which complements EPSS with threat intelligence specific to the client's industry.

When there is no CVE associated with the finding at all, a common situation in logic and business vulnerabilities, or in proprietary code never previously cataloged, KEV and EPSS simply do not exist as a signal, and YAGA transitions to the second track, described in the next section.

4. When There Is No CVE: CVSS 4.0 Filled with Real Evidence

4.1 The “Not Defined” Problem and Systematic Severity Inflation

As described in Section 3, the CVSS 4.0 specification treats unfilled Threat, Environmental and Supplemental metrics as equivalent to the worst case. This is correct as a conservative convention for publishing a generic CVE (the CVE maintainer does not know the environment of any specific consumer of that CVE), but it is an inadequate choice when the very agent that discovered the vulnerability has direct access to the real evidence of the environment. Keeping “Not Defined” in that case is not neutrality, it is deliberate waste of available information.

YAGA never publishes a CVSS with Threat and Environmental metrics set to “Not Defined” when the finding originates from an active engagement. Instead, it fills each of those metrics with evidence collected during the pentest itself,

TABLE 1: Origin of CVSS 4.0 metrics

Metric	Origin in a generic scanner	Origin in YAGA
Exploit Maturity (E)	Left Not Defined (equals worst case)	Derived directly from K(v) and EPSS(v) when there is a CVE, or from the real exploitation result obtained by the agent itself when there is none
Confidentiality/Integrity/Availability Requirement (CR/IR/AR)	Left Not Defined (equals Medium)	Derived from the data classification and asset criticality obtained from inventory and real content scanning
Modified Base Metrics	Rarely filled, requires manual retest	Derived from evidence collected at runtime, real presence of WAF, observed segmentation, effectively required authentication

For the Threat group specifically, YAGA's filling rule is,

E(v) = { Attacked   if K(v) = 1
POC   if K(v) = 0 and EPSS(v) ≥ 0.30
Unreported   otherwise

The 0.30 threshold is calibrated on the historical corpus of CVEs whose EPSS evolution was tracked until exploitation was or was not confirmed, and is reviewed periodically as the EPSS model is retrained by FIRST.org.

4.2 Practical Impact of Correct Filling

The net effect of filling Threat and Environmental with real evidence, instead of accepting the Not Defined default, is that the same CVE can produce quite different final CVSS 4.0 scores depending on the asset. A CVE with real Exploit Maturity classified as Unreported (no known exploit, low EPSS) and Availability Requirement Low (asset not critical for availability) has its score reduced relative to the published Base. A CVE with Exploit Maturity Attacked and Confidentiality Requirement High (asset processes sensitive data) has its score raised, sometimes above the Base published in the public database itself, because the generic Base assumes Medium for the security requirements, not High.

This step, importantly, still produces a number on the CVSS technical scale, from 0 to 10. It answers “what is the technical severity of this vulnerability, on this asset, with the real information we have”, but it does not yet explicitly incorporate the financial value of the asset, the probability of loss in business units, nor the effect of correlation with other findings. That incorporation is the role of the next layer, the risk-context engine.

5. YAGA's Risk-Context Engine

5.1 Pipeline Overview

Regardless of whether the finding arrived through the KEV/EPSS track or the contextualized CVSS 4.0 track, both converge to a single input technical-severity score, S_tec(v) ∈ [0, 10],

S_tec(v) = { g(K(v), EPSS(v), CVSS_impact(v))   if v has a known CVE
CVSS_4.0(v)   otherwise, with Threat/Environmental filled by evidence

where g(·) combines the probability of exploitation (KEV/EPSS) with the magnitude of impact derived from the CVSS impact sub-vector (VC, VI, VA, SC, SI, SA), preserving the separation between the two axes even when the CVE is known. From S_tec(v), YAGA's context engine applies seven sequential transformations, each described in a subsection below, to produce the final criticality score R_final(v, a) for the vulnerability-asset pair (v, a).

5.2 Annualized Rate of Occurrence from the Exposure Window

The concept of Annualized Rate of Occurrence (ARO), from the classical literature on quantitative risk management [6], [7], represents the expected frequency of occurrence of a loss event. YAGA adapts that concept to the reality of vulnerability management by defining ARO not as a probability over an arbitrary calendar year, but as the probability of exploitation occurring within the finding's real exposure window, that is, the time between discovery and effective remediation, defined by the severity SLA adopted by the organization,

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

where t_exp is the number of days of the exposure window (the remediation SLA applicable to the finding's technical severity) and the exponent converts the EPSS 30-day calibrated probability to the real exposure window, under the simplifying assumption of independence between successive 30-day subwindows, a standard approximation in risk actuarial practice and widely used in FAIR quantification models [8], albeit conservative when the real window is much shorter than a year, as is the case with critical remediation SLAs.

When the CVE is in the KEV catalog, ARO is defined by a floor of already-confirmed exploitation, independent of the EPSS statistical computation,

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

ARO is recomputed on every execution, because both EPSS and the remaining time of the exposure window change continuously, which makes criticality a living value, not a static snapshot of the discovery day.

5.3 Bayesian Inference of the Real Probability of Exploitation

The ARO derived from EPSS/KEV represents the probability of exploitation in the global threat ecosystem, without yet considering the particularities of the specific asset. YAGA treats that value as a prior probability and updates it via Bayesian inference with evidence collected during the engagement itself,

P(real exploitation | E) = ARO(v) × P(E | real exploitation) ARO(v) × P(E | real exploitation) + (1 − ARO(v)) × P(E | ¬ real exploitation)

Rewriting in odds form, which simplifies the combination of multiple independent pieces of evidence under the Naive Bayes assumption,

odds_prior = ARO(v) 1 − ARO(v)     odds_posterior = odds_prior × ∏_i LR(E_i)     P(real exploitation | E) = odds_posterior 1 + odds_posterior

where LR(E_i) is the likelihood ratio of each item of context evidence observed by the agent during the pentest. YAGA uses three categories of probability evidence, each with an LR calibration table based on the historical corpus,

TABLE 2: Likelihood ratios (LR) by evidence category

Evidence (Ei)	Condition	Calibrated LR
Asset exposure to the internet	Yes / No	3.0 / 0.15
Effective preventive control on the route (WAF, authentication, rate limit)	Absent / Present	2.5 / 0.50
Sector threat correlation T(v) (Section 5.9)	High (T > 0.30) / Medium / Low or none	8.0 / 2.0 / 1.0

5.4 Business Value of the Asset

The impact of a successful exploitation depends directly on what is at stake. YAGA composes a business-value index for the asset, AV_bus(a) ∈ [0, 10], from four dimensions collected from the asset inventory and the context provided by the client,

AV_bus(a) = w₁C_revenue(a) + w₂C_data(a) + w₃C_regulatory(a) + w₄C_availability(a)

with ∑_i w_i = 1 and each component normalized to [0, 10], the asset's direct revenue dependency, the sensitivity of the data it processes or stores, the associated regulatory exposure (LGPD, PCI DSS, central-bank regulation, the client's specific sector), and operational availability criticality. A payment gateway in production typically appears near the top of this scale across all four dimensions, while an isolated staging environment, with no real client data and no regulatory exposure, appears near the bottom.

5.5 Exposure Factor and Compensating Controls

The Exposure Factor (EF) represents the fraction of the asset value effectively at risk if exploitation materializes, derived from the CVSS impact sub-vector (the technical magnitude of the possible damage) and attenuated by compensating containment controls (not the same preventive controls used in the Bayesian inference of probability, but controls that limit the blast radius after exploitation has already occurred, network segmentation that limits lateral movement, backups that limit integrity loss, monitoring with fast containment that limits exposure time),

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

where CCE(a) ∈ [0, 1] is the aggregate effectiveness index of the compensating containment controls present in the environment of that specific asset, collected by direct evidence (segmentation observed in network scanning, existence and testability of a backup routine, real monitoring coverage validated during the engagement), never assumed.

5.6 Single and Annualized Loss Expectancy

With the asset value and the exposure factor defined, YAGA computes the expected loss in a single exploitation case (Single Loss Expectancy) and the expected loss weighted by the real probability of occurrence within the exposure window (Annualized/Adjusted Loss Expectancy), following the classical FAIR formulation [8],

SLE(v, a) = AV_bus(a) × EF(v, a)       ALE(v, a) = SLE(v, a) × P(real exploitation | E)

Both terms are expressed in normalized loss units, on the same [0, 10] scale as AV_bus, calibratable to local currency by the organization through a conversion factor defined jointly with the client (for example, 1 normalized unit equivalent to a reference amount derived from the average incident cost of the organization itself or of the sector).

5.7 Environment Multiplier

The environment where the asset lives, production, staging, development or isolated sandbox, directly changes the probability that a loss computed under production conditions will actually materialize. YAGA applies an environment multiplier M_env over the expected loss,

TABLE 3: Environment multiplier

Environment	Menv	Rationale
Production	1.00	Loss materializes directly over real business data and operation
Staging	0.35	Synthetic or masked data, but with residual risk of accidental promotion to production or reuse of credentials/configuration
Development	0.15	Greater isolation, still with risk of secret exposure and propagation of the vulnerable pattern into production code
Isolated sandbox/Lab	0.05	No real network route and no sensitive data, essentially structural residual risk

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

It is essential to stress that M_env does not reduce the technical severity S_tec(v), only the expected business-loss term. A critical finding in staging remains technically critical, it simply represents, today, a much smaller expected business loss than the same finding in production, which is precisely the central mechanism of this article.

5.8 Correlation with Similar Findings in YAGA's Historical Corpus

The corpus of more than 30,000 validated findings, accumulated by YAGA across previous engagements, allows empirically estimating how often findings technically and contextually similar to this one were, in fact, confirmed as exploitable and escalated to real impact, versus how many were disconfirmed or remained theoretical after retest. That factor, H(v) ∈ [0, 1], is computed by weighted similarity over a set of reference findings,

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

where sim(v, f_j) ∈ [0, 1] is the similarity (by CWE, endpoint pattern, technology stack and payload class, computed by cosine similarity over vector representations of the findings) between the current finding and each of the n closest historical findings, and outcome(f_j) ∈ [0, 1] records the real outcome of that historical finding (confirmed exploitable and escalated to a real incident, partially confirmed, or discarded on retest). H(v) works as an empirical corrector independent of the market statistical probability (EPSS), capturing specific patterns of how a given vulnerability class behaves in the observed type of architecture, information no generic score can capture.

5.9 Sector Threat Correlation and Competitive Landscape

The market probability of exploitation (EPSS) describes the average global behavior of attackers against any target with that CVE. It does not capture whether the client's specific sector, or organizations of equivalent profile and size (industry peers, direct and indirect competitors), is being actively targeted by campaigns exploiting that same vulnerability class. YAGA maintains a sector-correlation factor, T(v) ∈ [0, 1],

T(v) = n_{active campaigns exploiting an equivalent CWE/pattern in the sector, 90-day window} n_{monitored campaigns in the sector over the same period}

built from threat intelligence correlated by vertical sector (retail, payments, health, government, among others) and mapped to equivalent MITRE ATT&CK techniques. When T(v) is high, YAGA interprets it as evidence that the same attack pattern has already demonstrated success against organizations of a profile comparable to the client's, which directly raises the likelihood ratio LR(E₃) used in the Bayesian update described earlier. In other words, if a direct competitor or an industry peer has already been compromised by an equivalent attack class in the last 90 days, that evidence objectively weighs in favor of treating the current finding as more likely to be exploited, regardless of what the generic CVE EPSS alone suggests.

5.10 Final Composition and Technical-Severity Floor

The previous factors are combined into a weighted, fully auditable sum, deliberately linear and not an opaque activation function, so that each component of the final score can be inspected and justified item by item in the report delivered to the client,

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

with weights calibrated by periodic regression over the historical corpus of validated findings, correlating predicted severity with the real outcome observed on retest, currently α = 0.30, β = 0.45, γ = 0.15, δ = 0.10, and the logarithmic normalization of the effective expected loss,

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

where ALE_max is the reference ceiling calibrated on the largest normalized-loss value observed in YAGA's historical corpus (an operational parameter, revised on each recalibration cycle).

Finally, to prevent the context math from entirely suppressing a technically serious finding just because, at the moment of assessment, the environment reduces the expected business loss, YAGA applies a minimum technical-severity floor,

Floor(S_tec(v)) = { 4.0   if S_tec(v) ≥ 9.0
3.0   if 7.0 ≤ S_tec(v) < 9.0
0   otherwise

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

This floor ensures that a technically critical vulnerability never disappears from the client's radar, even when the current business context drastically reduces the expected loss, because environments change (a staging environment can be promoted to production, a compensating control can be removed during maintenance) and the intrinsic technical severity remains latent until the effective fix of the defect.

5.11 Black Swans and Antifragility: The Theoretical Justification of the Floor

The minimum technical-severity floor is not an arbitrary conservatism adjustment, it has a direct theoretical foundation in Nassim Nicholas Taleb's critique of the statistical extrapolation of rare, high-impact events. In “The Black Swan”, Taleb describes two distinct domains, Mediocristan, where variables follow well-behaved distributions and the historical average is a good predictor of the next event, and Extremistan, where a single extreme and improbable event dominates the aggregate outcome disproportionately, and where models trained on history systematically underestimate the tail because the event that matters most is, by definition, the one not yet represented in the data [9]. EPSS, ARO, H(v) and T(v) are, all of them, estimates built on behavior observed in the past, competent in Mediocristan, exploitation of CVEs in general, but structurally vulnerable to the same blind spot in Extremistan, the discovery of a new exploitation chain, the abrupt turn of an obscure CVE into mass exploitation, or the shift of interest of a specific threat actor against that sector, events that by nature carry little or no history for the model to learn from before they happen.

The technical-severity floor is the structural, non-statistical, response to that limitation, and in that sense follows directly the principle Taleb calls antifragility in “Antifragile”, a robust system tries to resist the predicted shock, an antifragile system is designed not to depend on correctly predicting the shock in the first place, it limits the downside even when the probabilistic model is wrong [10]. By never letting R_final fall below 4.0 for a vulnerability with S_tec ≥ 9.0, regardless of how favorable the context and the probability math look today, YAGA accepts a small, known cost (the finding stays visible and tracked even when the context math suggests low immediate risk) to eliminate a potentially catastrophic, unknown cost (a black swan, an exploitation chain not yet observed, materializing exactly over a finding that the model itself had classified as low risk for lack of historical evidence). This is, in practice, a deliberate choice of risk asymmetry in favor of zero fragility in the worst case, even at the cost of some imprecision in the average case.

6. Case Study: Same Vulnerability, Different Criticalities by Context

To make the whole described mechanism concrete, this section applies the complete pipeline to a single illustrative CVE, present in two distinct assets of the same client. The numeric values below are didactic examples, with realistic order of magnitude, not data from a real client.

Base vulnerability (identical in both scenarios): insecure deserialization library allowing unauthenticated remote code execution. CVSS_4.0 = 9.8 (Critical), no entry in the KEV catalog (K(v) = 0), EPSS(v) = 0.61. Remediation SLA for Critical severity adopted by the client, t_exp = 7 days.

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

This result, approximately 19.7% probability of an exploitation attempt within the 7 days of the remediation window, is the only term common to both scenarios. Everything that follows diverges because of the asset context.

6.1 Scenario A: Isolated Staging Environment

Asset in a staging environment, no internet exposure, with WAF and network segmentation effectively validated, synthetic test data, no relevant correlation with sector campaigns against this type of internal asset, and a low historical escalation rate in similar findings in this type of environment.

Parameter	Value
LR(E1), not exposed to the internet	0.15
LR(E2), preventive control present	0.50
LR(E3), low sector correlation	1.00
LRtotal	0.15 × 0.50 × 1.00 = 0.075
oddsposterior	0.2459 × 0.075 ≈ 0.0184
P(real exploitation | E)	0.0184 / 1.0184 ≈ 1.81%
AVbus(a)	2.0 / 10
CCE(a), containment	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
Menv, staging	0.35
ALEeff	0.0036
H(v), internal historical correlation	0.08
zALE(v, a), with 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

Since S_tec(v) = 9.8 ≥ 9.0, the floor of 4.0 applies. R_final(v, a) = max(2.37, 4.0) = 4.0, Medium band.

6.2 Scenario B: Production Environment, Higher-Value Asset

Same CVE, now present in the payment gateway in production, publicly exposed via API, with no WAF coverage on the specific route (a recently published endpoint, not yet included in the current rules), under PCI DSS scope, with three active campaigns documented in the payments sector over the last 90 days exploiting the same vulnerability class, and a high historical rate of real escalation in similar findings within YAGA's corpus.

Parameter	Value
LR(E1), exposed to the internet	3.00
LR(E2), preventive control absent	2.50
LR(E3), high sector correlation	8.00
LRtotal	3.00 × 2.50 × 8.00 = 60.0
oddsposterior	0.2459 × 60.0 ≈ 14.75
P(real exploitation | E)	14.75 / 15.75 ≈ 93.65%
AVbus(a)	9.2 / 10
CCE(a), containment	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
Menv, production	1.00
ALEeff	7.776
H(v), internal historical correlation	0.85
zALE(v, a), with 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

Since 8.61 ≥ Floor (4.0), the floor does not change the result. R_final(v, a) = 8.61, Critical band.

6.3 Comparison and Interpretation

TABLE 4: Same technical signals, divergent final criticalities

Quantity	Scenario A (Staging)	Scenario B (Production)
CVSS 4.0 Base	9.8	9.8
EPSS	0.61	0.61
P(real exploitation | E) posterior	1.81%	93.65%
Effective ALE	0.0036	7.776
Rfinal	4.0 (Medium)	8.61 (Critical)

The two findings share exactly the same technical origin signals (CVSS Base 9.8 and EPSS 0.61). Neither of the two “market severity” inputs differs. What diverges entirely is the real probability of exploitation given the observed context (1.81% versus 93.65%, a difference of more than 50 times) and the resulting expected business loss (0.0036 versus 7.776 normalized units, a difference of more than 2,100 times). The technical origin signals remain correct in both cases, it is the same vulnerability, with the same damage potential if successfully exploited. What neither of them states in isolation, and should never be read as stating, is that the probability and the business impact are the same in both environments, that is the gap YAGA's context engine fills.

7. Continuous Recomputation and the Finding Lifecycle

All factors described in this document are dynamic, not static. EPSS varies daily as the FIRST.org model is fed with new data on exploitation observed in the market. ARO decreases as the exposure window t_exp runs out, increasing the relative urgency of the finding while it remains open. The environment multiplier changes instantly if an asset in staging is promoted to production, a situation YAGA treats as an automatic trigger for a full reassessment, not only of the multiplier, but of the entire pipeline, because the asset value, the observed controls and the sector correlation also tend to change together with the environment. The H(v) factor is recomputed on each corpus retraining cycle, incorporating the outcome of engagements concluded since the last calibration. The T(v) factor is updated as new sector campaigns are identified by monitored threat intelligence. This means the same finding can rise or fall a band during the life of the engagement without any technical data about the vulnerability itself having changed, and that change is, by design, exactly the expected behavior of a criticality system oriented toward real risk and not a static snapshot of the discovery day. This continuous recomputation is not just input-data adjustment, it is also performance self-assessment, H(v) itself (correlation with the real outcome of past findings) is, in essence, a measurement of how well the model predicted risk in the past, reapplied to calibrate the present prediction, in line with the argument that measuring the quality of one's own risk measurement is, in security, the most important measurement of all, precisely because it is what prevents an assessment process from looking rigorous without actually predicting anything useful [11].

8. Transparency and Auditability of the Score

Each of the terms presented in this article, S_tec(v), ARO(v), each LR(E_i) applied, AV_bus(a) and its decomposition into four components, EF(v, a), CCE(a), ALE(v, a), M_env, H(v), T(v), and the final result R_final(v, a) with an explicit indication of which floor was or was not applied, is recorded as auditable metadata of the finding and can be attached to the report delivered to the client, item by item, exactly in the tabular form presented in the previous section. There is no opaque or black-box step in this pipeline, the final composition is deliberately a linear weighted sum, and not a neural network or a non-interpretable activation function, precisely so that any difference between the technical origin score and the final criticality can be explained to the client down to the last decimal, with the context evidence that justifies it.

8.1 What Is Illustrative in This Document and What Is Auditable per Finding

It is important to separate two planes that this article treats differently. On the plane of the real finding, within a production engagement, the audit package described in the previous paragraph is concrete, specific to that vulnerability-asset pair, and delivered to the client. On the plane of this document, which is public and educational, the weights α, β, γ, δ, the LR thresholds, the environment multipliers and the other numeric parameters are illustrative, chosen to have a plausible order of magnitude and to demonstrate the reasoning logic, not to be the exact operational calibration table that YAGA uses in production, that calibration is continuously adjusted by the model itself in light of new validated outcomes and is not published in its complete form. The difference is the same as that between explaining how an expert computes an appraisal, the reasoning, the variables that weigh, the order in which they are assessed, and handing over the exact ruler and conversion table the expert uses, so that anyone without the same experience and without access to the same evidence could produce an equivalent appraisal on their own. This article delivers the former. The latter remains the reason a client hires YAGA instead of computing criticality on their own.

9. Analytical Extension: Linear Algebra, Ratios and Complex Numbers in Multi-Scenario Processing

The entire pipeline described in the previous sections was presented finding by finding, for didactic clarity. In the real operation of an engagement, the language model underpinning YAGA rarely assesses an isolated finding, it assesses the complete portfolio of findings together, and it does so by processing the evidence collected by the agent as linear-algebra structures (vectors and matrices) and, when useful for portfolio-level aggregation, as complex numbers, instead of repeating the same sequence of scalar operations finding by finding. The agent is responsible for collecting the raw evidence during the pentest (exposure, observed controls, semantic similarity between findings), and the model is responsible for formalizing that evidence into algebraic structures and solving the operations (matrix products, spectral decomposition, ratios and proportions, modulus and argument of complex numbers) within its own reasoning, before emitting the final score and the justification of each finding. The agent's operational instructions explicitly define a large number of equivalent mathematical decision scenarios over which this processing applies, of which the example below is only one illustrative instance [12].

9.1 Ratio and Proportion: Converting Normalized Units into Currency

Converting ALE_eff (normalized loss units, Section 5) into a reference monetary value follows a simple rule of three, calibrated with the client from the organization's own average incident cost, considering, illustratively, 1 normalized unit equivalent to R$ 45,000.00,

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

For finding f₁ (Scenario B of the case study, Section 6), this equals approximately R$ 349,920.00 of expected loss within the 7-day exposure window, the number that effectively enters the remediation budget prioritization with the client.

9.2 Log-Domain Evidence Matrix for a Portfolio of Findings

Consider a portfolio of n = 3 findings from the same engagement, the deserialization RCE from Scenario B (f₁), a SQL Injection in an internal admin panel in production (f₂) and a reflected XSS in staging (f₃). Instead of computing LR_total finding by finding through sequential multiplication, the model builds the log-likelihood matrix Λ ∈ ℝ^3×3 (rows = findings, columns = evidence E₁, E₂, E₃ from Section 5) and solves the product against the unit vector 1 in a single matrix operation,

Λ = ( 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 )

The result matches exactly the direct product of each finding's likelihood ratios (3.00 × 2.50 × 8.00 = 60.0 for f₁, the same LR_total as Scenario B in Section 6), confirming that the log-domain matrix formulation is algebraically equivalent to sequential multiplication, with the advantage of solving the entire portfolio in a single operation.

9.3 Spectral Decomposition: Systemic Risk Concentration in the Portfolio

To detect whether the three findings share a common root cause, which would reduce the marginal value of fixing them in isolation, the model builds the cosine-similarity matrix C ∈ ℝ^3×3 between the feature vectors of each finding (CWE pattern, technology stack, endpoint pattern),

C = ( 1.00000.98510.73570.98511.00000.71240.73570.71241.0000 )

C is real and symmetric, therefore diagonalizable with real eigenvalues by the spectral theorem. By power iteration, the dominant eigenvalue converges to λ_max ≈ 2.63. The concentration ratio λ_max/n = 2.63/3 ≈ 0.877 indicates that almost 88% of the portfolio's risk variance is explained by a single common latent factor, in this case, a systemic input-validation flaw shared by the three vulnerability classes, and not three independent causes. This reading changes the remediation recommendation delivered to the client, fixing the structural root cause (the input-validation layer) reduces the combined portfolio risk far beyond what the sum of the individual remediation of each finding would suggest in isolation.

9.4 Complex Number: Risk Plane of Magnitude and Phase of the Dominant Finding

For finding f₁, the model represents simultaneously the expected business loss and the historical pattern correlation as a single complex number in the risk plane,

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

The phase θ(f₁) ≈ 0.832 radians (approximately 47.7°) sits near the diagonal of the plane, indicating balance between the two axes, projected financial loss and historical correlation of real exploitation, which reinforces the Critical classification of Scenario B along two mathematically independent and simultaneous lines of evidence, not just one. Findings with θ close to 0 are dominated by isolated financial impact and prioritize immediate compensating control, findings with θ close to π/2 are dominated by historical exploitation pattern and prioritize confirmation retest, and findings near the diagonal, like this one, justify both actions in parallel.

10. Conclusion

The final criticality assigned to a vulnerability being different from its technical origin score is not a defect of YAGA's methodology, it is the evidence that the methodology is doing exactly what an isolated technical-severity score was never designed to do, translate an intrinsic characteristic of the vulnerability into a real risk estimate for a specific asset, in a specific environment, at a specific moment. CVSS 4.0, when available, remains one of the indispensable inputs of technical impact magnitude, and YAGA fills it with real threat and environment evidence instead of accepting the conservative “Not Defined” defaults that inflate the severity of practically every market scanner. When there is a cataloged CVE, KEV and EPSS take on the role of estimating the probability of exploitation based on real market evidence updated daily, instead of relying on subjective heuristics. Over those inputs, probability and impact, YAGA's risk-context engine applies an entirely transparent and auditable mathematical pipeline, ARO adjusted to the real exposure window, Bayesian update with exposure, controls and sector-correlation evidence, business value of the asset, exposure factor net of compensating controls, single and adjusted expected loss (SLE/ALE) in the FAIR tradition of risk quantification, environment multiplier, correlation with the history of more than 30,000 findings already validated by the platform, and a technical-severity floor that prevents today's favorable context from permanently erasing a technically serious defect that could become critical as soon as the environment changes.

The presented case study numerically demonstrates the central argument of this article, the same CVE, with the same technical origin signals (CVSS 9.8 and EPSS 0.61), produces a real probability of exploitation of 1.81% in an isolated staging environment and 93.65% in a payment gateway in production, a difference of more than 50 times in probability and more than 2,100 times in expected loss, resulting in final bands of Medium and Critical respectively. Neither of the two results contradicts those origin signals, both complement them with the probability and business-context information that an isolated technical score never intended to carry.

No probabilistic model, however rich in variables, eliminates the possibility of a rare, not-yet-observed event single-handedly redefining the real risk of a finding, that is the lesson “The Black Swan” and “Antifragile” bring out of the financial domain where Taleb originally formulated them and that YAGA incorporates structurally through the technical-severity floor, it does not try to predict the black swan, it ensures the system does not collapse silently should one appear [9], [10]. And none of these computations exists in isolation from the broader adversarial-risk picture of the engagement, they are the per-finding criticality layer within the attack-chain and business-impact mapping methodology that HackerSec had already formalized as ARMA [1], detailed here in mathematical depth to answer the specific question that motivates this document, how the final criticality of a finding forms from combined technical, threat and business-context signals.

This is the transparency this document set out to deliver, the reasoning, the order of magnitude of each variable and the source of each external foundation are here, in an auditable and questionable form item by item, even though the exact production operational calibration, by nature, keeps evolving and is not published in full, precisely because the one that computes the final criticality of each real finding, with all the evidence of that specific engagement, is YAGA's AI model, not a static formula that a third party could re-run outside it.

11. References