Notifications
Clear all
Topic starter
12/06/2026 9:42 pm
TL;DR: AI-assisted discovery and weaponization are compressing exploit timelines to hours while Aqua argues that FAIR can translate container exposure into annual loss expectancy the board can use, according to Aqua Security. The practical shift is that runtime enforcement, not CVE counts, becomes the control that makes risk math credible and auditable.
NHIMG editorial — based on content published by Aqua Security: How Do You Measure FAIR Risk in the Mythos Era?
Questions worth separating out
Q: How should security teams quantify container risk in dollars?
A: Security teams should start by linking workload exposure to business impact, then calculate annual loss expectancy from event frequency and loss magnitude.
Q: Why do CVE counts and CVSS scores fail as board risk metrics?
A: They fail because they describe technical severity, not business loss.
Q: How do you know if runtime enforcement is actually reducing risk?
A: You know it is working when the control changes the expected loss curve rather than just generating logs.
Practitioner guidance
- Map workloads to business value before quantifying risk Group container and workload exposures by line of business criticality so that annual loss expectancy reflects what the business would actually lose if the workload were compromised.
- Separate audit-mode evidence from enforce-mode controls Review which security policies only generate alerts and which ones actually block drift, stop exploitation, or restrict network reach during the exposure window.
- Rebuild board reporting around residual loss, not vulnerability counts Replace top-line CVE totals with residual annual loss expectancy, exposure window assumptions, and the dollar value of the controls that reduce that number.
What's in the full article
Aqua Security's full blog covers the operational detail this post intentionally leaves for the source:
- The exact FAIR calculation flow used to turn container telemetry into annual loss expectancy
- The domain-based control stacking method used to combine image, network, runtime, and access controls
- The worked example showing how runtime enforcement changes the residual dollar value of risk
- The dashboard inputs used to map workloads to line-of-business labels and asset values
👉 Read Aqua Security's analysis of FAIR risk for container security in the Mythos era →
Container risk in dollars: are your controls keeping up?
Explore further
12/06/2026 11:58 pm
FAIR becomes necessary when technical severity no longer tracks business loss. The article is right to shift the conversation away from CVE counts because vulnerability volume does not tell a board what a compromise will cost. In cloud-native environments, the meaningful question is which workload identities and runtime paths create the largest annual loss expectancy. Practitioners should use FAIR to prioritise by financial exposure, not by raw defect count.
A few things that frame the scale:
- 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months, according to The State of Non-Human Identity Security.
- Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.
A question worth separating out:
Q: Who should own FAIR-based risk reporting in a cloud security programme?
A: Ownership should sit with security leadership working alongside finance, platform, and application owners because the model depends on both technical exposure data and business valuation. If no one is accountable for the assumptions behind frequency, loss magnitude, and control effectiveness, the resulting number will look precise but not be trustworthy.
👉 Read our full editorial: FAIR risk in the Mythos era changes how boards read container exposure
