Requirement ID: VER-EVA-EIR
The requirement
Providers MUST evaluate detected vulnerabilities, considering the context of the cloud service offering, to determine if they are internet-reachable vulnerabilities. (force: MUST)
What does this mean?
Once your team has detected a vulnerability, this requirement asks you to take a second step: figure out whether that vulnerability can actually be reached or triggered by something coming from the public internet.
An internet-reachable vulnerability, in FedRAMP terms, is a weakness in a machine-based resource that might be exploited or triggered by a payload originating from a source on the public internet. The evaluation is not done in the abstract. It must consider the context of your specific cloud service offering, meaning how your systems are actually built and the security context around your data flows. Machine-based resources that receive payloads from the internet may have security services and devices that inspect and filter external traffic that make vulnerabilities on the devices they protect not internet reachable. Examining your traffic flows to your machine-based resources and determining which resources get unaltered and uninspected traffic payloads from the internet will help determine where internet reachable vulnerabilities’ will be present.
In short, you are not just listing vulnerabilities. You are classifying each one based on whether an outside attacker could plausibly touch it.
This article is also a LinkedIn newsletter. If you would like to receive it straight to your inbox, subscribe here.
Why does this matter?
Not every vulnerability carries the same real-world risk. A flaw buried in an internal component with no path from the outside world is very different from the same flaw on a public-facing service.
Treating all vulnerabilities as equal can waste effort and, more importantly, can bury the ones that matter most. If a genuinely internet-reachable vulnerability is not identified as such, it may not get the urgency or prioritization it deserves. That gap is exactly what an external attacker looks for.
By evaluating reachability in the context of your offering, you surface the vulnerabilities most likely to be exploited from outside, so remediation and reporting can be prioritized accordingly.
What could implementation look like?
The requirement does not mandate a specific method, so teams have flexibility. One approach could be to build reachability evaluation into the existing vulnerability triage workflow.
A workflow might look like this:
- A vulnerability is detected through scanning, disclosure, threat intelligence, or another detection source.
- The affected resource is identified and mapped against network topology, firewall and security group rules, load balancer and gateway exposure, and authentication boundaries.
- Based on that context, the vulnerability is tagged as internet-reachable or not, with a short rationale recorded.
- The classification feeds into prioritization and any downstream reporting steps.
Some teams may automate parts of this using asset inventories and network exposure data, while others may rely on analyst review. Both can be valid as long as the evaluation genuinely considers the offering’s context.
Example scenario
A mid-sized provider runs a multi-tier cloud analytics platform. A scan flags a vulnerable library in two places: a public API gateway and an internal batch-processing service that sits behind a private subnet with no inbound internet path.
During evaluation, the team maps each instance against network exposure. The API gateway instance is reachable from the public internet, so it is classified as an internet-reachable vulnerability and moved to the top of the queue. The batch-processing instance is documented as present but not internet-reachable, with a note explaining the network isolation.
Both are tracked, but the classification makes it clear which one an outside attacker could actually reach.
What evidence could demonstrate implementation?
Examples may include:
- Vulnerability records or tickets that include an internet-reachability determination and a supporting rationale.
- A documented procedure describing how reachability is evaluated in the context of the offering.
- Network topology, asset inventory, or exposure data referenced during evaluation.
- Triage or review logs showing the evaluation step occurred after detection.
These are illustrative examples, not a checklist mandated by the source.
Common pitfall
A frequent weak pattern is treating reachability as a static label copied from the vulnerability’s generic severity score, rather than an evaluation grounded in your own environment. A vulnerability rated critical in general may not be internet-reachable in your offering, and a modest-looking one may be exposed at your edge. Skipping the context-specific step defeats the purpose of the requirement.
Question for your team
When a new vulnerability is detected, what specific data sources do we consult to decide whether it is internet-reachable, and is that decision consistently recorded?
Key takeaway
This requirement is about applying real-world environmental context to each detected vulnerability so that those exposed to the public internet are clearly identified.
Related requirements
None listed in the source data.
Have a question about putting this requirement into practice?
38North Security can help you turn the requirements into an operating model that works in practice. Talk to us →
The quoted requirement above is from the provided FedRAMP CR-26 JSON. The implementation ideas, example scenario, and evidence examples are general guidance and should be validated against official FedRAMP guidance.
