Vulnerability Evidence as a Product

Under Rev5, continuous monitoring ran on a monthly rhythm. A provider scanned its system, updated its Plan of Action and Milestones (POA&M), filed deviation requests for the findings it could not fix on time, logged monthly check-ins for the ones waiting on a vendor, and sent the package to its agency. Reviewers read it, asked questions, and approved or rejected the requests. The cycle was slow, but every exception passed in front of a person.

The FedRAMP Consolidated Rules for 2026 (CR26) change the rhythm and move the burden. Reporting is persistent and machine-readable. Deviation requests are gone. The provider evaluates every finding itself, in the context of its own system, and the evaluation sets the deadline. Agencies are told to process the results automatically, and FedRAMP recommends they review mainly the overdue and accepted findings above a set impact rating (VER-AGM-RVR). The reviewer who used to judge each exception now relies on the output of a process.

That process is a chain of decisions, and it runs for every finding.

Each link is a judgment the provider makes thousands of times a year. CR26 defines carefully what each judgment must decide, and leaves the method to the provider on purpose. On likely exploitability, FedRAMP “will not recommend a specific framework for approaching this beyond these rules” (VER-EVA-ELX).

Now multiply the chain by a portfolio. An Authorizing Official (AO) at a mid-sized agency oversees twenty cloud services. A widely used library turns out to have a flaw that attackers are already using, and an emergency directive gives the agency days to respond. The AO needs one answer across all twenty providers. Where is the flaw? How exposed is it? How soon will it be fixed, and what is each provider doing about it?

Every provider’s chain produced an answer, and the answers do not combine. Providers name components differently: by package, by hostname, by virtual machine. They decide reachability from different signals. They calibrate exploitability against different thresholds, often unpublished. They record their exceptions in different shapes. Each choice can be defended. Together they produce twenty reports that pass the same schema and still cannot be compared.

This article proposes a method for the whole chain. It borrows its architecture from data mesh, which Zhamak Dehghani introduced in 2019 to manage analytical data that many teams produce and many people use. I start with the divide between operational and analytical data, because vulnerability evidence sits on the analytical side of it. Then I follow a finding down the chain in Figure 1: where it comes from, how it lands on a component, how its reachability, exploitability and impact are decided, how its clock runs, and what happens when it cannot be fixed in time. Most of these sections close with a short note, Through the mesh, that names the data mesh principle at work. The last sections assemble the pieces into a logical architecture that scales from one system to a portfolio. Two short sections cover how a provider can adopt the method in stages and what an assessor checks. A section on related work sets the method beside other proposals for the same rules and beside what providers in the 20x pilot have published. The appendices restate the method as numbered requirements and conformance tests, and list example tools.

The method names no particular scanner, feed or scale value. FedRAMP will tune its scales and timeframes, and tools come and go. Appendix C lists example tools, outside the method. Where a concrete value helps, it appears in a box labeled Scenario. Scenario values are illustrative. They are not rules.

In several places the method asks for more than CR26 does. Each is marked in a box labeled Beyond CR26 that says what the method adds and why. Each follows the intent the rules state, even where their letter would allow less.

The requirements in this article belong to the method. They are not FedRAMP’s. CR26 says what must be true of a provider’s evidence and leaves the provider to choose how. This is one way. A MUST in the appendices defines conformance to the method, and meeting it is not a FedRAMP determination.

A working pipeline on this site illustrates parts of the method for one small system. That system holds no federal data, has no agency sponsor and is not authorized. Where the system and this article differ, the article defines the method.

The great divide of vulnerability evidence

Dehghani separates two kinds of data. Operational data runs the business. It is current state, held behind the applications that use it, and it changes constantly. Analytical data is derived from operational data over time. It is shaped for people who need to make decisions.

Vulnerability evidence follows the same divide. Cloud configuration, infrastructure state, scanner output and probe results are operational. They describe the system as it is right now, and most of them are overwritten by the next run. The canonical inventory, the provider’s single list of every component in the offering, from which every other product is derived, is analytical. So are the vulnerability report, the disposition records and the history of all three. They are derived, they carry time, and they exist so that someone can decide something. An AO reading a vulnerability report is an analytical consumer. So is an assessor. So is the provider’s own engineer deciding what to patch first.

Dehghani wrote about large companies whose central data teams pulled data from many sources into one lake. Adding one new feature meant changing every stage of the pipeline. The central team understood the data less well than the teams that produced it, and the people who needed it waited. Federal compliance has the same shape. Providers produce evidence in their own formats. Agencies and assessors rebuild it into spreadsheets they can compare. Every rebuild loses context, and every request for clarification adds weeks.

Her answer rests on four principles that she calls “collectively necessary and sufficient”. Domain ownership puts data in the hands of the people closest to it. Data as a product makes those owners publish it for others, with the care a product deserves. A self-serve platform handles the hard infrastructure so that each domain can do this without building everything itself. Federated computational governance sets the few global rules that make the products work together and enforces them in code.

What CR26 asks

Two rule families cover this ground. Vulnerability Evaluation and Reporting (VER) says how to judge and report a finding. Vulnerability Detection and Response (VDR) says how to find it and how fast to act.

Detection must be systematic, persistent and prompt. Providers “MUST systematically, persistently, and promptly discover and identify vulnerabilities” using any technique that fits, from scanning and penetration testing to disclosure programs and supply chain monitoring (VDR-CSO-DET). Response carries the same words: providers must “track, evaluate, monitor, mitigate, remediate, assess exploitation of, report, and otherwise manage all detected vulnerabilities” (VDR-CSO-RES). Failures in either process count as vulnerabilities themselves (VDR-CSO-FAV). Between detection and response sits the evaluation, which CR26 defines with three terms.

An internet-reachable vulnerability (IRV) is “a vulnerability in a machine-based information resource that might be exploited or otherwise triggered by a payload originating from a source on the public internet” (FRD-IRV). The definition reaches past the network edge. It “includes machine-based information resources that have no direct route to/from the internet but receive payloads or otherwise take action triggered by internet activity,” and it “applies only to the specific vulnerable machine-based information resources processing the payload.” Its opposite is NIRV.

A likely exploitable vulnerability (LEV) is “a vulnerability that is not fully mitigated AND is reachable by a likely threat actor; AND a likely threat actor with knowledge of the vulnerability would likely gain unauthorized access, cause harm, disrupt operations, or otherwise have an undesired adverse impact within the cloud service offering by exploiting the vulnerability” (FRD-LEV). There is a floor. “At the absolute minimum, any vulnerability that an automated unauthenticated system can exploit over the internet is a likely exploitable vulnerability.” Its opposite is NLEV.

The Potential Agency Impact N-rating (PAIN) places the likely effect of exploitation on an ordered scale, from no adverse effect up to a debilitating effect on more than one agency (VER-EVA-EPA).

The deadline is a lookup. For each certification class (A through D), the rules give a timeframe for every combination of impact rating, reachability and exploitability. Some combinations carry no fixed timeframe, and for findings that are not likely exploitable, reachability does not change the answer (VDR-TFR-PVR). Known exploited vulnerabilities also follow CISA’s due dates, even when fully mitigated (VDR-TFR-KEV). A finding that is not, or will not be, fully mitigated or remediated within a maximum overdue period becomes an accepted vulnerability whether or not anyone decided to accept it (VER-TFR-MAV).

That lookup suggests the first mechanism. FedRAMP publishes its rules in machine-readable form, timeframes included. The pipeline reads the timeframes, the maximum overdue period and the evaluation windows from that file and records which version it used. Nothing in the method depends on a particular number. When FedRAMP adds a rating level or shortens a timeframe, the provider updates the pinned version, and the next build applies the change everywhere at once.

The two yes-or-no answers carry real weight in that lookup. For the same impact rating, a finding that is both reachable and likely exploitable gets a much shorter timeframe than one that is not likely exploitable. That is why the method for answering them matters.

Each finding is reported with a defined set of fields (VER-RPT-VDT), among them the reachability answer, the exploitability answer and the impact rating over time. Accepted vulnerabilities are reported separately, with an explanation of why they were accepted (VER-RPT-AVI). FedRAMP publishes a JSON schema for each report, and agencies “SHOULD use automated processing and filtering of machine readable information” (VER-AGM-RVR).

Not every finding comes from a scanner

CR26 defines a vulnerability broadly. The term “includes gaps in Rev5 Controls and 20x Key Security Indicators, software vulnerabilities, misconfigurations, exposures, weak credentials, insecure services, and all other such potential weaknesses in protection” (FRD-VUL). Detection “is NOT limited to traditional vulnerability scanning or testing,” and the rules give an example: “An out-of-date control statement in the Security Decision Record is a vulnerability that must be detected and remediated just like any other vulnerability” (VDR-CSO-DET). The same rule notes that historical FedRAMP guidance “generally focused only on CVE-type vulnerabilities.”

So the method takes findings from every source into one stream.

• Scanners. Software composition, infrastructure, configuration and dynamic scanners.
• People. Penetration tests, bug bounty and disclosure reports, assessor findings and incident reviews.
• Records. A Rev5 control or Key Security Indicator whose status shows a gap, and a control statement that no longer matches the system.
• Non-machine resources. Processes, procedures and roles, which the provider must verify and validate on a schedule the rules set (VDR-TFR-NMV).

Each source has an adapter that turns its output into findings with the same fields. A penetration test report becomes one finding per weakness, each with its source, its detection date and its target. A Rev5 control recorded as Partially Implemented or Planned becomes a finding on the day the status is recorded. Each finding keeps its source’s detection time, such as the date of the report, and not the time it reached the pipeline. Evaluation follows within the window the rules set, and the clock runs from evaluation, whatever the source.

A finding about software, a resource or a URL lands on an inventory component, as the next section describes. Most penetration test and bug bounty findings name a host or a URL and resolve the same way. A finding about a control, an indicator or a process lands on that rule’s entry in the Security Decision Record (SDR), by the rule, indicator or control identifier. Those identifiers are the shared keys for this kind of finding. Its reachability and impact come from the components the control covers, evaluated at the most exposed and most sensitive of them. A gap in input validation on the public API is evaluated at the API. A gap in a procedure that touches no machine-based resource is NIRV, because the IRV definition covers only machine-based resources (FRD-IRV).

A stale control statement is detected the way drift in intent is. Each statement names the inventory components and settings it depends on. A change to any of them opens a finding against the statement until someone reviews it and either confirms or rewrites it.

Every finding lives in the vulnerability report and keeps its clock there, whatever its source. That is where the reachability, exploitability, impact and timeframe fields are, and where FedRAMP’s report schemas expect them. The SDR is where the provider explains how each rule is followed, or “the reason and resulting risk to customers for not following the rule” (SDR-CSO-FRR), and gives each Rev5 control an implementation status (SDR-CSF-CTF). The SDR entry for a rule lists the open findings against it by identifier. A reader of the SDR sees each control’s weaknesses beside its statement. A reader of the vulnerability report sees each weakness’s clock. Neither copies the other.

Through the mesh The vulnerability report and the SDR are two products from the same domain. They join on the finding identifier, the way products in a mesh join on shared identifiers. Each stays the source of truth for what it owns.

Every finding lands on a component

Every later link depends on knowing which component a finding affects. Reachability comes from the component’s design. Impact comes from the component’s needs. The portfolio query joins on the component’s identifier. Scanners describe what they found in their own terms. A software composition scanner reports a package. An infrastructure scanner reports a resource address. A dynamic scanner reports a URL. Each must be joined to one inventory component, by exact match on a shared identifier. For software that identifier is the Package URL (PURL). For infrastructure it is the cloud provider’s native resource identifier. Keyword matching on descriptions is not good enough. It works until the day it matches the wrong thing.

Some resources do not live long enough to be named one by one. An autoscaled instance, a container or a function version can appear and vanish within the hour. For these, the component is the template that creates them: the infrastructure-as-code module, the service or the deployment unit. The template’s identifier is stamped on each instance as a label when it is provisioned, and a finding on the instance resolves through that label. Intent, classification and flows are declared once, on the template, and every instance inherits them. An instance with no template label and no exact match is unresolved, like any other finding that matches nothing.

A finding that matches no component is unresolved. It is treated as IRV, rated with the fail-safe classification (PII, CUI, Mission Critical and multi-agency), and queued for a person. A finding that matches several components is treated as one group, as VER-EVA-GRV allows, and evaluated at its most exposed member.

Through the mesh Shared identifiers are the smallest global standard in the mesh, and everything else rests on them. A provider that names components its own way can still publish a correct report. Nobody else can join it to anything.

Reachability is a design decision

Most tools compute reachability from the network. Does the resource have a public address? Does a firewall rule admit traffic from anywhere? Is it behind an internet-facing load balancer? These are useful facts. They describe what the network allows. CR26 asks something else. VER-EVA-EIR says FedRAMP “focuses on internet-reachable (rather than internet-accessible) to ensure that any service that might receive a payload from the internet is prioritized.” Its two examples make the point. SQL injection reaches a database “that can only be accessed by an authorized connection from the application server on a private network.” Log4Shell was exploitable “deep in the application stack” on resources that “were often not internet-accessible themselves.”

A database behind a public application has no public address and no open firewall rule. It is reachable because it was built to store what users send. That is a fact about the design, and the people who designed the system know it best. So the method starts there.

Three intent classes

Every component in the inventory declares an exposure intent, one of three classes, with a sentence saying why.

• public-edge components are designed to accept connections initiated from the public internet. A content delivery network, an internet-facing load balancer, an API gateway, a public website bucket.
• public-backed components accept no connection from the internet by design, but they process payloads derived from internet input. A database behind a public application, a queue consumer, a log pipeline that parses request data, an application function behind a gateway.
• internal components neither accept internet connections nor process internet-derived payloads. A deploy role, an encryption key, a scheduled job that reads only provider-controlled data.

Reachability for a finding then follows from the component it sits on. A finding on a public-edge or public-backed component is IRV. A finding on an internal component is NIRV. The declaration does the work that network inference cannot, because it captures the payload paths drawn with dashed lines in Figure 4.

The data flows in the inventory keep the declarations honest. Call a component public if it is public-edge or public-backed. If a component receives a declared flow from a public component and parses what arrives, it is public-backed by definition. A component declared internal that receives such a flow contradicts itself, and the deploy fails. The contradiction is caught in the change that introduced it, and the author fixes the intent or the flow before it merges.

That check only sees flows someone declared. Suppose a team adds a queue that carries public requests to a component declared internal, and forgets to declare the flow. The component has no internet path for the observers to find, and the gate sees no declared flow, so nothing fires. The method closes that gap with telemetry. Service-mesh traffic records, network flow logs and queue or topic subscriptions show which components actually exchange data. An observed flow from a public component that nobody declared is drift. Into a component declared internal, it is treated as undeclared exposure. Anywhere else, it goes to the decision queue.

The method assumes the people declaring intent act in good faith. A team could understate exposure to earn longer clocks. That would be a failure of culture, and the method does not try to engineer around it. Good faith is the price of entry for any provider in a program built on self-attestation. Bad faith is also easy to see here. Every declaration is published with its rationale beside the observations, the flow telemetry and the assessor’s sample, and a pattern of understated intent stands out.

Changing a component’s intent is a design change. Moving a component from internal to public-edge exposes it to the internet. The rules require providers to “evaluate all potential significant changes to determine the type of significant change” (SCN-CSO-EVA). A change of intent toward more exposure is evaluated that way, in the same review that approves it.

There are two ways for a finding on a public component to become NIRV. The first is deflection. VER-EVA-EIR allows a provider to “intercept, inspect, filter, sanitize, reject, or otherwise deflect triggering payloads before they are processed by the vulnerable resource; once this prevention is in place the vulnerability should no longer be considered an internet-reachable vulnerability.” The method accepts this when the deflection is specific to the vulnerability and a test proves it. The test sends a triggering payload from outside and confirms it is stopped. A generic perimeter control without that test does not qualify.

The second is narrower. Intent says a component processes internet-derived payloads. It does not say that every vulnerable code path in the component does. A flaw in a database’s replication protocol, or in an administrative tool shipped in the same image, can sit on a public-backed component where no user payload ever reaches it. The rules anticipate this. Internet reachability “applies only to the specific vulnerable machine-based information resources processing the payload” (FRD-IRV). The method allows such a finding to be narrowed to NIRV through a disposition record that shows the trigger is off the payload path. Acceptable evidence includes a call-graph analysis showing the vulnerable function is never invoked from request handling, and published analysis of which inputs can trigger the flaw. Intent sets the default, and only evidence narrows it. The record is published, and it lapses when the artifact or the component’s flows change.

irv(finding):
    if finding is unresolved:           return true   # assume reachable
    c = component(finding)
    if c has an undeclared exposure:    return true   # drift, Figure 6
    if c.exposure_intent == "internal": return false
    if deflection recorded and tested:  return false  # VER-EVA-EIR
    if narrowing recorded with evidence: return false # trigger off the payload path
    return true                         # public-edge or public-backed

Seeing what attackers see

A declaration is a claim. It needs a check, or it drifts away from reality the first time someone opens a firewall rule to debug a problem. CR26 already frames drift this way. It defines drift as “changes to information resources that cause deviations from the intended and assessed state” (FRD-DFT). Detection includes “persistently verifying and validating that information resources and processes are operating as intended” (VDR-CSO-DET). Intent is the baseline the rules already assume.

The check uses two observers that do not depend on each other. A declaration can mark a component as more exposed than the observers find it. It can never make a component less exposed than they find it.

The inside-out observer reads the cloud control plane with read-only credentials, on every deploy and on a schedule between deploys. The deploy-time read catches a change as it is made (VDR-CSO-DAC). The scheduled read catches the change nobody deployed. It looks for the configuration that opens a path: a public address, an ingress rule that admits any source, an internet-facing load balancer, a storage policy that grants anonymous access, a function or API endpoint with no authentication, a CDN origin, and a public DNS record that points at the resource.

At large scale a sweep is slow and costly. Reading every resource in a large estate runs into the control plane’s request quotas, and a daily read can leave an exposure open for a day. Cloud platforms publish change events through their audit logs and configuration feeds. The inside-out observer can subscribe to them and re-evaluate a component within minutes of a change. The sweep remains as the backstop for missed events and as the cadence floor.

The outside-in observer works from a vantage point on the public internet, against every public name and address in the inventory. It runs port and service discovery, TLS and HTTP fingerprinting, and dynamic application testing against the public-edge endpoints. This is the attacker’s view, and it tests the actual implementation instead of the intended one. It also runs at least daily, and never less often than the rules require machine-based resources to be verified (VDR-TFR-MVX for 20x, VDR-TFR-MVF for Rev5). The rules advise against weakening a resource to scan it (VDR-CSO-MSP), and neither observer does.

Two cautions apply to the outside-in view. Behind a shared, multi-tenant edge, such as a content delivery network or an anycast front end, one address serves many products. A probe result is attributed by hostname and TLS server name, never by address alone. And a provider’s own defenses may throttle or block its scanner. Allowlisting the scanner fixes that, but an allowlisted probe no longer sees what an attacker sees. Each result records whether its probe was allowlisted, so a reader knows which view it represents.

When intent and observation disagree

Reconciliation compares the declaration with what the observers found. Six outcomes are possible, and they fall into three kinds.

Undeclared exposure is the dangerous case. Something is reachable that the design says is not. It is drift under FRD-DFT, and it is treated as a vulnerability on the component. It is fixed by removing the path, or by changing the declared intent in a reviewed change. A disposition cannot close it. While it stands, every finding on the component is IRV.

Over-declaration is the safe case. The design says a component is public, and nobody can reach it. Perhaps the intent is out of date. Perhaps a route is broken. Either way it needs a person, so it goes to the decision queue, a published list of choices that belong to a person rather than to the pipeline, instead of failing the deploy. Findings stay IRV until the decision is made, because missing evidence should never lower a rating.

Everything else is consistent, and reachability follows the declaration.

Through the mesh Intent is a fact that only the domain knows, which is why domain ownership matters here. Published beside the observations, it turns reachability into a product other people can check. An AO filtering twenty providers’ reports on the IRV field can rely on it meaning the same thing in every one.

Likely exploitability

Reachability asks whether an attacker can deliver a payload. Exploitability asks whether one is likely to try and succeed. CR26 admits this is hard. “The simple reality is that most traditional vulnerabilities discovered by scanners or during assessment are not likely to be exploitable.” It also warns that providers who mark findings NLEV “without careful consideration are more likely to suffer from an adverse impact” (VER-EVA-ELX). And it sets a default: providers “MUST assume the exploitation of vulnerabilities can be automated UNLESS they have evidence proving otherwise” (VER-EVA-AIA).

The method uses evidence that other parties publish. Four kinds matter.

• A known-exploited catalog records exploitation that has already happened. CISA’s KEV catalog is the one the rules name.
• An exploit-prediction score estimates the probability of exploitation activity in the near future. EPSS is the common one today.
• Threat intelligence and incident response report what is happening now, including against the provider itself.
• The severity vector published with the vulnerability says whether exploitation needs network access, privileges or a user’s help.

The method checks these signals in a fixed order, after first asking whether a control already stops exploitation. Each check stands on its own, and the first one that fires decides.

lev(finding):
    if fully_mitigated(finding):           return false  # FRD-LEV
    if finding.known_exploited:            return true
    if finding.exploitation_observed:      return true
    if irv(finding) and vector.network and not vector.privileges \
                    and not vector.user_interaction:
                                           return true   # floor
    if finding.prediction is not None:     return finding.prediction >= theta
    return true                                          # no score: fail safe

Three choices in this sequence deserve explanation.

The floor check comes before the prediction score. A low score means the vulnerability looks like others that were rarely exploited. It does not prove exploitation cannot be automated, and VER-EVA-AIA puts that burden of proof on the provider. If a reachable vulnerability needs no login and no user action, it meets the FRD-LEV floor regardless of its score. Apache Struts CVE-2017-5638 shows why the order matters. It needed no login and no user action. Apache published its advisory on March 6, 2017. On March 10, two days after the U.S. Computer Emergency Readiness Team flagged it, attackers scanned Equifax for it and got into the company’s online dispute portal. From May 13 they used that access to take personal data (GAO-18-559). Findings without a severity vector, such as configuration and dynamic-test findings, apply the same check from what the scanner reports about access and authentication. If neither is known, the finding is LEV.

The threshold θ is a local decision, and no value is right for everyone. A prediction score is a probability. EPSS estimates the chance that exploitation activity will be observed in the next 30 days. FIRST, which publishes it, says “there is no universal threshold” and that the right one “depends on your remediation capacity, risk tolerance, and asset context.” A lower θ marks more findings LEV. It catches more of what will be exploited and costs more remediation work. A higher θ costs less and misses more. The scores also sit mostly near zero, because only a few percent of published vulnerabilities see exploitation activity in any 30-day period. FIRST warns that a threshold at 50% “deprioritizes the 98.8% of all published vulnerabilities.”

In this method θ decides less than it would on its own. It runs last, after the catalog, observed exploitation and the floor, so it only sees findings no other check has marked LEV. The provider sets it from its mission’s tolerance for each kind of error and its capacity to remediate, and writes down why. A mission that cannot afford a missed exploit sets it lower. The provider versions θ, publishes it with its rationale beside the report, and revisits it as the score’s record in its own system builds up. The date and model version of the score feed are recorded on each finding, so anyone can see what the provider knew when it decided.

The last step covers a finding with no prediction score. Prediction feeds score published CVEs, usually within a day, so the gap is short for a new CVE. It is permanent for an advisory with no CVE identifier, such as one published only in a package ecosystem’s own database. Most scanners report an advisory’s aliases, so the method looks up the CVE first. Missing data must not lower a rating, so a finding with no score is LEV until one arrives. That costs some noise. The provider can override the result, but only through a disposition record that carries the justification, who decided and a review date. An advisory often lands on many components at once, so the record names the advisory and a selector for the components it covers, such as every component built with a given package. One decision then covers them all. A component that later matches the selector inherits the override, and a component the justification does not fit is excluded by name. The override is published like any other record and lapses at its review date. When a score does exist and the floor does not apply, the score is trusted, even when that makes a high-severity finding NLEV.

Through the mesh The catalog, the score and the severity vector are products that other domains publish. The provider consumes them as a downstream customer and records which version it read. That is federated governance in practice. The global products are shared, and the local threshold is owned and visible.

Impact

CR26 asks for the likely impact on agencies, on an ordered scale whose levels are described as effects on customers. A scanner’s severity label cannot answer this alone. A denial-of-service flaw rated low by its vendor can be debilitating on a component whose availability is the mission. A high-severity flaw can be minor on a component that holds only public data.

The method splits the rating into three layers so that each can change without disturbing the others.

1. Inputs. The vulnerability’s technical impact on confidentiality, integrity and availability comes from its published severity vector. The component’s needs come from its declared classification: what data it holds, whether the mission depends on it, and whether it serves one agency or several.
2. The method. A governed function combines the two into a single measure of effect. One good choice is the environmental approach from CVSS, which weights each impact by how much the component needs that property. A provider could choose a different function and publish it.
3. The scale. A governed mapping places the measure on whatever scale the current rules define. It also assigns the scale’s lowest level to a fully mitigated finding.

pain(finding):
    if fully_mitigated(finding):  return scale.lowest
    need   = requirements(component.classification)   # governed map
    effect = combine(finding.technical_impact, need)   # governed method
    return scale.place(effect, component.agency_scope) # governed mapping

Findings with no severity vector, such as configuration findings, use a published fallback from the scanner’s severity to the scale. An unresolved finding uses the fail-safe classification. Ratings change over time, and CR26 wants the history. Each change is appended to the finding with its time and reason. A reduction from a control added later makes the finding a partially mitigated vulnerability, one where “the likelihood or Potential Agency Impact N-rating has been reduced from the original evaluation but the risk of exploitation still exists” (FRD-PMV).

Classification is declared intent

A component’s needs are declared, the same way its exposure is. The team that owns a component records its classification in the inventory, on the component or on the template or service it comes from, and is accountable for keeping it true. The determinations behind it come from the people who own them: whether data is PII or CUI from the information and privacy owners, and whether the mission depends on a component from the mission owner, often the agency. Each declaration names who made those determinations, the same way a disposition names who decided. Like exposure intent, classification describes the design. Observation checks it.

Classification has two kinds of terms. Flags stack: a component can carry any combination of them. Attributes are exclusive: a component has exactly one value.

• Data is required. It is public, internal, or one or both of PII and CUI. Public data excludes the rest, and PII and CUI are never public. A component with no data classification fails the deploy, as one with no exposure intent does.
• Mission Critical is a flag. It says the mission depends on the component staying correct and available. A component can be Mission Critical with any data, or sensitive without being Mission Critical.
• Agency scope is an attribute, single-agency or multi-agency. A component with no declared scope is treated as multi-agency, because a shared component is assumed to serve every customer until shown otherwise.

A governed map turns the classification into the three needs the impact method weighs. The vocabulary and the default map are global, so a rating means the same thing across providers. A provider that deviates from the default map publishes the deviation.

Each flaw is weighed only on the properties it affects. A flaw that only affects availability, on a CUI component that is not Mission Critical, meets the Medium availability need, however sensitive the data. Agency scope does not change the weights. It enters at the last layer, where the measure is placed on the scale, because the rules describe the top levels as effects on more than one agency.

The flags are declared at the component because that is where the architecture is known. They record where sensitive data lives in the system. How much an agency has at stake is a separate question. It can be answered rigorously by mapping the federal information types a service is meant to hold, and the ones each agency places in it, through NIST SP 800-60 and FIPS 199 to a ceiling on that agency’s needs, and the related work points to a worked method. That derivation works at the level of the service and of each agency’s intended use, and it needs each agency to confirm that use. This method keeps one rating per finding across all of a provider’s agencies, so that a rating means the same thing to every reader, and it takes the flags as its input. A provider can still use the derivation to decide which data to flag. The PII and CUI flags themselves need no catalog of information types, because both are categories providers already have to identify.

Flows carry classification too. A component that holds PII sends many kinds of data, and most of it is not PII. A scanning agent on a PII database sends host names and package versions, and no records. So each declared flow states what it carries: some of its source’s data flags, or metadata only, with a sentence saying why. Three cases follow.

• Contradiction. A flow declared to carry a flag reaches a component that does not have it. The declarations disagree with each other, and the deploy fails, as it does when an internal component receives a public flow.
• Declared metadata. A flow declared to carry metadata only leaves a sensitive component. It is accepted as declared, and its reason is published beside it.
• Unknown contents. A flow from a sensitive component with no declared contents, or one seen only in flow telemetry, goes to the decision queue. Until someone decides, the receiving component is rated as if it carried the source’s data flags.

Through the mesh The two halves of this calculation come from two products. The vulnerability’s technical impact is published by the vulnerability ecosystem. The component’s needs are published by the provider’s inventory. Joined on a shared identifier, they produce a rating neither could produce alone. And because the scale is data, FedRAMP can change it without breaking either product.

The clock

A finding’s deadline is set at evaluation by the lookup in Figure 3. The rules measure it from evaluation and set a window within which evaluation should happen after detection (VER-TFR-EVU). A pipeline that evaluates in the same run as detection can start the clock at detection. That is never later than the true evaluation time, so it never extends a deadline.

rules = load(machine_readable_rules, pinned_version)

# clock_start: the first evaluation, or the last verified mitigation
#              that changed the rating
due(f)       = f.clock_start + rules.timeframe(cls, pain(f), irv(f), lev(f))
if f.known_exploited:
    due(f)   = min(due(f), f.catalog_due_date)            # VDR-TFR-KEV
accept_by(f) = f.first_evaluated_at + rules.max_overdue   # VER-TFR-MAV, never reset

Four rules keep the clock honest.

• History carries forward. The first detection and first evaluation times come from the last published report, so a rebuild never resets them.
• A verified mitigation starts a new clock. FedRAMP has said this is the intent. Asked whether a mitigated finding keeps its original deadline, it answered that “the clock is intended to reset when mitigations have meaningfully reframed the vulnerability,” because “the goal is to encourage mitigation as the highest priority.” The method counts a mitigation as meaningful when its record names a control by inventory identifier, an observer or re-test confirms the control works, and the rating changes. A rating that falls for any other reason, such as a lower prediction score, selects a new timeframe from the same start.
• A lapse withdraws the reset. When a mitigation’s control lapses, the finding goes back to the rating and the clock it had before the mitigation, as if the mitigation had never been recorded. The section on where the reason lives explains how a lapse is detected.
• The outer bound never moves. The maximum overdue period counts from the first evaluation. A finding not fully mitigated or remediated within it is reported as accepted, however many resets came before (VER-TFR-MAV). No disposition pauses any clock.

CR26 distinguishes overdue from accepted by intent. An overdue vulnerability is one the provider “intends to fully mitigate or remediate but has not or will not do so within the time frames” (FRD-ODV). An accepted vulnerability is one the provider “does not intend to fully mitigate or remediate,” or one that “has not or will not be fully mitigated or remediated within the maximum overdue period” (FRD-ACV). VER-RPT-VDT also asks of each finding, “Is it currently or is it likely to become an overdue vulnerability or not? If so, explain.” A finding that will miss its deadline is reported before the deadline passes.

The most severe combinations can also become incidents. The rules name a rating above which a reachable, likely exploitable finding may be treated as a FedRAMP Reportable Incident until it is partially mitigated below that line. For the higher certification classes the word is SHOULD (VER-TFR-IRI). A second, higher line applies to likely exploitable findings that are not reachable. It is optional for most classes and SHOULD for the highest (VER-TFR-NRI). Like the timeframes, the thresholds are read from the rules.

From deviation requests to records

Rev5 practitioners know four exceptions to the remediation clock, each a column on the Rev5 POA&M. Three were deviation requests that the agency reviewed: False Positive (FP), Risk Adjustment (RA) and Operational Requirement (OR). The fourth, Vendor Dependency (VD), was not a request. The provider flagged the item and checked in with the vendor at least every 30 days. For low and moderate findings, as long as the fix was still pending and the check-ins continued, the item did not count as late. A high finding waiting on a vendor had to be mitigated to moderate within 30 days. CR26 uses none of these terms. The decisions behind them still exist, and they have moved.

Vendor dependency changes the most. CR26 has no equivalent of the monthly check-in. The finding becomes overdue when its deadline passes, the provider explains why in the report, and the finding becomes accepted if the maximum overdue period runs out.

False positive or mitigated: where the reason lives

Many findings are not exploitable. Why they are not decides how they are recorded, and the test is simple. Ask where the reason lives.

If the reason lives inside the scanned artifact, the finding is a false positive. The scanner matched a package by name, but the artifact carries a patched build. The package sits in a build stage and never reaches the runtime image. A reason like this can change only when the artifact changes, and every change to the artifact produces a new scan and a new evaluation. It is re-checked automatically.

If the reason lives outside the artifact, the finding is mitigated. A gateway rule, a network policy, a runtime flag or an environment setting stops exploitation. Each of these can change while the artifact stays exactly the same, and the scan would never notice. The vulnerable code is still there, so the scanner keeps reporting it. CR26 writes this into its definitions. Fully and partially mitigated vulnerabilities are both ones where “the vulnerability is still detected” (FRD-FMV, FRD-PMV).

CR26 adds one condition of its own. A false positive “only applies if the vulnerability is not and was not present” (FRD-FPV). A flaw that was ever exploitable in the offering cannot become a false positive later. If the artifact changed to remove it, it is remediated. If something around it changed, it is mitigated.

A mitigation is a declaration with a dependency, the same shape as exposure intent, and the method treats it the same way. Every mitigation record names the control it depends on by its inventory identifier. The gateway route, the network policy and the feature flag are inventory components like any other. Any change to that control voids every mitigation that names it, and so does a failed re-test on the outside-in cadence. A voided mitigation returns the finding to the rating it held before, taken from its rating history, in the same build.

The finding also returns to the clock it had before the mitigation, and the reset the mitigation earned is withdrawn with it. In practice, a lapse on a long-mitigated finding fails the deadline gate in the same build, so the change that caused it cannot merge quietly. If the maximum overdue period from the first evaluation has passed, the finding is reported as accepted until it is fixed.

What a disposition record must carry

A disposition is a provider’s decision about a finding, or about one advisory across the findings a published selector matches, published as a record. Every record names the findings and the components by their shared identifiers. It states the CR26 status, the reason, who decided, when, and when the decision must be reviewed. A record past its review date counts as absent. A field nobody recorded is published as not recorded and never filled in with a default.

CR26 publishes report schemas but names no format for the records underneath them. The natural choice is a Vulnerability Exploitability eXchange (VEX) format inside a bill-of-materials standard, so that the dispositions travel with the software and cryptographic inventories they describe. Whatever format is chosen, the encoding must keep three distinctions that are easy to lose.

• Not present is different from protected. VEX formats can say “not affected” for both. CR26 cannot. A finding protected by a control is fully mitigated, names its control, and stays on the clock for known-exploited due dates. Only a finding that was never present in an exploitable state is a false positive. A finding whose trigger is off the payload path is neither. It is narrowed to NIRV and stays listed.
• Not yet known is different from known and waiting. “Under investigation” means the provider does not yet know whether it is affected. A vendor dependency is known and exploitable. It is recorded as exploitable, with a response saying the provider cannot fix it yet and will update when it can.
• Will not fix is different from cannot fix yet. The first is an accepted vulnerability and needs the acceptance explanation. The second is overdue once the deadline passes and needs the evidence that no fix exists.

At publication, each record is projected into FedRAMP’s report schemas.

Computing vendor dependency

Whether a vendor has shipped a fix is a fact about the outside world. It can be checked on every scan. Most software composition scanners report a fix state for each match, usually some version of fixed, not fixed, will not fix, or unknown, along with the fixed versions. Vendors that publish machine-readable advisories, such as CSAF, state the same thing as remediation categories.

vendor_fix(finding):                   # runs on every scan
    s = scanner fix state + vendor advisory remediation
    if s says a fix is released:       return AVAILABLE
    if s says no fix is planned:       return NONE_PLANNED
    if s says no fix is available yet: return PENDING
    return AVAILABLE                   # unknown counts as fixable

A vendor-dependency disposition is valid only while the answer is PENDING. The first scan that finds a fix ends it automatically. Because the clock never paused, the finding is judged against its original deadline, which has usually passed. The gate fails and someone patches. NONE_PLANNED means waiting will not help. The finding must be accepted with an explanation, mitigated, or removed by replacing the component.

"analysis": {
  "state": "exploitable",
  "response": ["can_not_fix", "update"],
  "detail": "No fix released. Scanner: not-fixed (2026-10-21). Advisory: none_available."
}

Through the mesh Under Rev5, three of the exceptions were requests sent to a reviewer and the fourth was a monthly check-in. Here they are records the provider owns and publishes before anyone asks. Vendor dependency goes one step further. It is computed from another domain’s product, the vendor’s advisory, so it closes itself when the facts change.

Gates

The pipeline enforces the method with gates. A gate is a global rule written as code. It runs on every build and on every scheduled run.

Unresolved findings, over-declared intent and flows of unknown content do not fail a gate. They go to the decision queue and are evaluated conservatively until someone decides. Each queue item names what must be decided, when it was opened, why the decision belongs to a person, and the options. The share of decisions that reach the queue, the escalation rate, is published too. A rising rate means the declarations or the method need attention.

Each gate runs in one of two modes. Fail-closed blocks the deploy or the publication. Detect-and-recover lets it through, opens a queue item and starts a recovery clock. The right mode depends on mission risk and need. A system whose availability is the mission may not be able to block an urgent fix because an unrelated gate failed. The provider chooses and publishes the mode of each gate. A change of mode is a decision record like any other, with who decided, when, why and a review date, and it is published with the provider’s other records. Release pressure pushes hardest on gate modes. A gate moved quietly to detect-and-recover would hide a change in how much risk the provider is willing to carry.

A gate failure blocks the domain that owns the failing component. In a provider with many products, one console change on one build server should not freeze every other team’s deploys. Each finding, queue item and gate result carries its owning domain from the inventory, and a failure holds deploys and publication for that domain’s product only. Two kinds of failure block everyone. G6 protects the evidence every reader relies on. A G7 failure in a shared part of the platform, such as a stale vulnerability database, means no product’s detection can be trusted.

One thing is never traded away: transparency into risk. Mission owners can make risk-based decisions only when they can see the risk, so no gate mode, disposition or format may hide it. Detect-and-recover is acceptable because the risk stays in view. The finding is published, the queue item is published, and the recovery clock runs where everyone can see it. G6 is different. A product that fails integrity would show the AO a picture of risk that is not true, so G6 is always fail-closed. The failure itself is published at once as a status record, so the gap in evidence is visible the moment it opens. Nobody has to wait for a freshness alarm to find it.

The logical architecture

The sections above describe what the method decides. This section describes how it is built: the product, the platform under it and the governance over it. Then it shows how the pieces scale from one system to many.

The evidence product

Dehghani calls the data product the architectural quantum of a mesh, the smallest unit that can be deployed on its own and still have everything it needs to work. It encapsulates three structural components: code, data and metadata, and infrastructure. Figure 12 draws it with its inputs on the left and its outputs on the right. The vulnerability evidence for one cloud service offering fits that description.

Dehghani’s 2019 article lists six qualities a data product must have. Each translates into something a builder can test.

The last quality needs two tiers, and CR26 already supplies their frame. Vulnerability reports “are FedRAMP Certification Data and are subject to FedRAMP Certification Data Sharing rules” (VER-RPT-PER). Those rules set both limits at once. Certification data must be sufficient “to support agency authorization decisions,” but “SHOULD NOT include sensitive information that would likely enable a threat actor to gain unauthorized access” (CDS-CSO-RIS). The reporting rules ask for the same balance (VER-RPT-NID).

The full tier is the certification data. It goes to all necessary parties, such as the AO, the agency security team and the assessor, through a FedRAMP-compatible trust center (CDS-CSO-UTC). The trust center logs access (CDS-TRC-ACL), offers programmatic access (CDS-TRC-PAC) and keeps snapshots for the life of the certification (CDS-CSO-HAD). The evidence product’s machine-readable output is what it serves, and the human-readable report is rendered from the same data, which keeps the two consistent (CDS-CSO-CBF). The full tier carries every finding and every field the reports require. Those parties make the risk decisions, so they see all of the risk. It does not carry what an attacker would need beyond that, such as payloads or exploit steps.

The public tier is what the provider shares beyond them. The rules allow sharing package information publicly when doing so “will NOT likely have an adverse effect” (CDS-CSO-RPS), and vulnerabilities when it “will NOT likely lead to exploitation” (VER-RPT-RPD). It shows counts by rating, whether findings are within their deadlines, and what was fixed and when. It leaves out open findings that are both reachable and likely exploitable, counts included. A list of those is a targeting guide, and on a small system even a count tells an attacker that a hole is open. The necessary parties see such a finding at once in the full tier. The public sees it when it is fixed, when its full entry joins the public tier. A provider may also publish the full tier openly if it judges that doing so will not likely lead to exploitation (VER-RPT-RPD). The system on this site does. It is a proof of concept that holds no federal or other sensitive data, and being read by anyone is its purpose. A certified system holding agency data would keep two tiers.

The self-serve platform

No provider should build all of this from scratch, and inside a large provider no product team should either. Dehghani describes the platform in three planes. Each maps onto vulnerability evidence.

• The data infrastructure provisioning plane runs the scanners, the inside-out collector, the outside-in probes, the flow telemetry, signing identities and storage. Product teams never touch it directly.
• The data product developer experience plane gives a team a simple way to declare a component’s intent, classification and flows, record a disposition, and get a signed product out. Declaring a new component is a change to one file.
• The data mesh supervision plane watches across products. It checks freshness from outside the pipeline, alerts when a product goes stale (VDR-CSO-FAV), tracks the decision queue and the escalation rate, and runs portfolio queries.

Cadence belongs to the platform too. The rules set minimum frequencies for evaluation (VER-TFR-EVU), verification (VDR-TFR-MVX, VDR-TFR-MVF, VDR-TFR-NMV), detection (VDR-TFR-PDD, VDR-TFR-PCD, VDR-TFR-PSD), historical updates (VER-TFR-MRH) and human-readable reports (VER-TFR-MHR). The platform reads them from the pinned rules, schedules every product to meet them, and alerts when a schedule slips. Evidence usually needs refreshing more often than anyone deploys, so some refreshes run with nobody watching. Such a refresh should hold only the permission to rescan and republish vulnerability products. Changes to the inventory or the infrastructure stay on the reviewed deploy path, so an unattended run can update the evidence but never the system it describes.

Much of this matters only at large scale. A provider with hundreds of products and thousands of short-lived resources needs template inheritance, event-driven observation and flow telemetry to keep its declarations true. A small provider can declare each component by hand and run the sweeps alone. The method is the same either way. A small provider needs less of the platform.

Federated computational governance

Governance in a mesh decides which rules are global and which are local, then enforces the global ones in the platform. For vulnerability evidence the split is clear.

Local values live in a schema-validated configuration file under version control. The build fails if it is missing or invalid. Every report records the rules version and the configuration version it used. Nothing global is copied into configuration, so nothing global can drift there.

From one system to a portfolio

The payoff comes when many domains follow the same global rules. Return to the AO with twenty services and an emergency directive.

The query the AO needs is now short. Find every finding for the vulnerability in question across the agency’s providers, using the same package identifier. Show the component, its exposure intent, whether reconciliation found it consistent, the IRV and LEV answers, the rating and the due date. Because each provider used the same identifiers and the same definitions, the rows mean the same thing. Because each product is signed and bound to an inventory, the AO can trust them without asking for screenshots. Because intent is declared and checked, a provider’s IRV answer can be audited by anyone who can read the inventory beside it. And because every product names the rules version it used, a change in FedRAMP’s scales shows up in the portfolio as a version number the AO can see. Nothing shifts in meaning silently.

Today an agency extracts evidence from each provider and rebuilds it. In a mesh, each provider publishes evidence the agency can use as it arrives. CR26 already defines the terms and the schemas, and publishes its own rules as data. The method in this article supplies the rest.

Getting there

Few providers start from a clean slate. Most run scanners they already own, keep exceptions in a spreadsheet POA&M, have partial infrastructure as code and no inventory of data flows. The method can be adopted in four stages. Each stage is useful on its own, and each makes the next one cheaper.

The order follows dependency. Nothing can be checked until findings land on components, and nothing can be reconciled until the components declare what they are. Gates come last because a gate that fails on bad data teaches a team to switch it off.

What an assessor checks

An assessor does two things. It verifies that the measures a provider implemented match the ones it documented (IVV-IAS-VIM), and it validates that they have the intended outcome (IVV-IAS-VEF). The provider supplies evidence of implementation and of effectiveness (IVV-CSO-SEI, IVV-CSO-SEE), and technical explanations where they help (IVV-CSO-STE). The method produces most of that evidence as a side effect.

The assessor’s findings become findings in the same stream, on the SDR entry for the rule they concern, and the assessor’s summary for each practice goes into the SDR (IVV-IAS-SUM). Nothing about the assessment sits outside the product.

Related work

Three bodies of work sit closest to this article: FedRAMP’s own answers to questions about the rules, proposals for how to meet them, and what providers, assessors and vendors have published from practice.

FedRAMP’s own reading

FedRAMP answers questions about its rules in a public community forum. Four answers bear directly on this method, and it follows each.

• Automation. “Humans should not be looking at scan reports and making decisions based off the output” (August 2025). The pipeline in this article is one way to get there.
• Impact. The impact rating “is intended to be part of a tripod” with exploitability and reachability, so neither should lower it. Evaluation should “start by assuming the worst, then understand the mitigating circumstances that would make it less bad” (September 2026). The three impact layers and the fail-safe classification follow both.
• The clock. A mitigation that “meaningfully reframed the vulnerability” should reset the clock (September 2026). The clock section adopts this and adds a fixed outer bound.
• False positives. Their exploitability, reachability and impact are “null,” and FedRAMP suggests reporting them in a “false positive” grouping (October 2026). The method keeps them in the report that way.

Proposals

The most complete proposals are by Matt Venne of stackArmor, published in 2026 as rfc-fedramp-vdr. They take the CR26 vulnerability rules one function at a time. This article borrows from them in several places and agrees with them where they overlap.

• Impact. A deterministic method derives the impact rating from the CVSS environmental metrics. A companion paper derives each component’s security requirements from the federal information types it is meant to hold, using NIST SP 800-60 and FIPS 199. A third calibrates the boundaries between ratings. This article treats the impact function as a governed choice and names his as one good choice. The derivation of requirements answers a different question from the classification flags, and the section on classification explains how the two fit.
• Mitigation. PAIN Relief pairs machine-verified controls with the weakness classes they counter and the reduction each pairing earns. Its rule that a control earns relief “only when enforcement infrastructure applies it and a collector can read it” is the same rule this article applies to mitigation records.
• Dispositions. A CycloneDX VEX profile maps dispositions and responses to the VER report fields, and is a good starting point for the encoding. This article reaches the same format and states three distinctions the encoding must keep.
• Reachability. Internet reachability at scale works from the finding. It computes direct exposure, promotes CVEs whose trigger is known to travel with internet content, follows attack-pattern chains between findings, and uses standing prevention assertions backed by existing testing. This article works from the component’s declared intent, checked by two observers and flow telemetry. The two fit together. Intent says which components receive internet-derived content. Finding-level evidence of the kind Venne describes says which findings on them a payload can reach.
• Exploitability and compliance findings. A proposal for a finer gradation splits exploitability into three bands. Another extends the impact method to benchmark and configuration findings. This article keeps CR26’s two exploitability answers.

The difference is mostly one of level. Venne’s papers specify the functions that turn a finding into answers. This article specifies the data architecture around those functions: who owns the inputs, which identifiers they share, how declarations are checked against reality, and which rules are global. A provider could adopt both.

Practice

FedRAMP’s 20x Phase Two pilot ran from November 2025 to March 2026 and drew 14 qualifying submissions. The FedRAMP Marketplace lists the resulting Class C offerings. Providers, assessors and tool vendors have since published how they approach the vulnerability rules. Much of it is general. What follows is the material specific enough to compare, grouped by topic, as of October 2026.

• Field report. Isaac Teuscher, who led Paramify’s Phase One pilot submissions, describes 20x in a field report as the NIST Risk Management Framework carried out through the software development life cycle. Evidence comes from artifacts the pipeline already produces, such as infrastructure-as-code state and CI/CD output, and “the goal is an accurate, continuous risk assessment, not a perfect score.” The report predates the CR26 vulnerability rules and does not address them. Both of its central ideas are premises of this article.
• Reachability. InfusionPoints, whose XBU40 platform is listed as FedRAMP Certified at Class C, reads reachability through the data flow. On its podcast it describes an application whose front-end actions reach a database, so “the database is likely considered internet reachable,” and it carries that architecture context in resource tags. Fortreum and Stratus Cyber make the same point in their guides: a payload “relayed into your stack” counts, and one deflected or sanitized before it reaches the resource does not. Knox Systems adds a warning this method shares: “A resource is not treated as unreachable simply because it is not intended to be public.” Declared intent here never narrows exposure on its own, and an observed path to an internal component fails a gate. Endor Labs narrows from inside the code: “A vulnerability that isn’t reachable in code cannot be internet-reachable.” Call-graph evidence of that kind is what a finding-level narrowing record can carry.
• Exploitability. Most published approaches take the burden of proof in VER-EVA-AIA as their default. Meridian Knowledge Solutions states it in its daily report: exploitation “is assumed automatable unless evidence proves otherwise.” Knox classifies a finding as not likely exploitable “only when affirmative technical evidence supports that conclusion.” On prediction scores, practice splits. Knox uses a 10% EPSS cut, which it calls “a Knox operating threshold.” 38North Security rejects a fixed cut, judges each finding against the evaluation factors and records “the evidence behind each claim rather than just the conclusion.” This method keeps the threshold and makes it a local, published choice.
• Impact. Boundera rates the customer effect and the number of agencies separately, and points out that the lowest rating does not make a finding a false positive, because the false-positive definition has conditions of its own. This method keeps the two apart the same way: a fully mitigated finding takes the lowest rating and is never a false positive.
• Exceptions. Paramify’s open-source fetchers build the accepted-vulnerability and detail reports from tracked issues, carrying Rev5’s exception kinds (operational requirement, vendor dependency, risk adjustment) into CR26. InfusionPoints asks that accepted risk have “an expiration or review point” and stay “visible, current, and reviewable.” Knox puts it shortly: “Acceptance is not concealment.” Schellman, an assessor, calls the published list of accepted vulnerabilities “a forced transparency mechanism.” Endor Labs generates VEX documents to back each determination. The disposition records in this article share all of this and add one thing: a record lapses when the control it names changes.
• Evidence. Meridian publishes its vulnerability report daily in a public repository, pinned to a CR26 version and drawing on cloud scanning, external scans, software composition analysis and a penetration test, with a content hash. InfusionPoints’ public package from the earlier Low pilot records, for each check, the commands it ran, the source it read and a hash of the code that ran it, so stakeholders can “track a full chain of custody of an artifact to their source within the environment.” On another episode it describes checking inventory in both directions, so that “everything that you hit with a vulnerability scanner is actually inventoried.” AWS’s reference pipeline gives its JSON and human-readable reports the same identifier, timestamp and data hash, and stores them under object lock. Tarly publishes its nightly results to a public repository, “including KSIs we do not yet meet.”
• Rules as data. A plugin for The Analogy Platform starts every evaluation factor at its worst case and lowers it “only when evidence is attached.” It seeds FedRAMP’s timeframe tables as data, each row “quoting the page cell it was read from.” A deadline calculator posted to FedRAMP’s forum reads the rules file directly and found timeframes stated only in prose, which FedRAMP then added to the data.

Practice already converges on much of the method: a pinned rules version, findings from many sources, a default toward exploitability, reachability read through the data flow, accepted risk kept in view, and machine-readable reports. Two ideas from practice are worth borrowing outright. A hash of the code that produced each finding answers a question a signature alone does not. A public, versioned history of the evidence gives anyone an audit trail for free. In the public material I found, three parts of the method are not yet there: exposure intent declared and checked against observation, exception records that lapse when their control changes, and evidence signed by the provider and bound to a single inventory. Those are the parts this article argues for most.

Appendix A. Requirements

The requirements below restate the method in testable form. The key words MUST, SHOULD and MAY are used as in RFC 2119 and as CR26 uses them. A value described as governed is local, versioned and published by the provider. A value described as from the rules is read from FedRAMP’s machine-readable rules at a pinned version. A + marks a requirement that goes beyond CR26. The matching Beyond CR26 box in the text gives the reason. These requirements define conformance to this method. They are not FedRAMP requirements.

Appendix B. Conformance tests

Each test states its setup in terms of the method. Where a test needs a timeframe or threshold, it uses whatever the pinned rules and governed configuration say.

Appendix C. Example tools

This appendix is not part of the method. It lists kinds of tools that can fill each part of the architecture, with examples, to make the method easier to picture. Each row names a kind of tool and a few common examples. The list is not exhaustive, a listing is not an endorsement, and tools change faster than rules. Any tool that meets the requirements in Appendix A will do.

References

1. Dehghani, Z. (2019). “How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh.” martinfowler.com, May 20, 2019. martinfowler.com/articles/data-monolith-to-mesh.html
2. Dehghani, Z. (2020). “Data Mesh Principles and Logical Architecture.” martinfowler.com, December 3, 2020. martinfowler.com/articles/data-mesh-principles.html
3. FedRAMP. Consolidated Rules for 2026, machine-readable edition. github.com/FedRAMP/rules. Rendered with anchors per rule at fedramp.gov/2026/rules. Quotations in this article are from version 2026.10.13.01.
4. FedRAMP. Report schemas for vulnerability detail, accepted vulnerabilities and historical activity, versions dated 2026-06-24.
5. FIRST. Common Vulnerability Scoring System v4.0: Specification Document, Environmental metric group. first.org/cvss/v4.0/specification-document
6. FIRST. Exploit Prediction Scoring System (EPSS). first.org/epss, including the FAQ and Using EPSS on choosing a threshold.
7. CISA. Known Exploited Vulnerabilities Catalog. cisa.gov/known-exploited-vulnerabilities-catalog
8. OWASP Foundation. CycloneDX Specification: vulnerability analysis (VEX) and bills of materials. cyclonedx.org/capabilities/vex
9. OASIS. Common Security Advisory Framework (CSAF) Version 2.0, remediation categories. docs.oasis-open.org/csaf/csaf/v2.0
10. FedRAMP. Legacy documentation: Plan of Action and Milestones and Continuous Monitoring Performance Management playbook pages. fedramp.gov/legacy, reference only.
11. FedRAMP. Plan of Action and Milestones (POA&M) Template Completion Guide, version 2.2, 2021, and Continuous Monitoring Strategy Guide, version 3.2, 2018. Retired from fedramp.gov; archived copies: POA&M guide, strategy guide.
12. U.S. Government Accountability Office (2018). Data Protection: Actions Taken by Equifax and Federal Agencies in Response to the 2017 Breach, GAO-18-559. Archived copy.
13. Graham-Cumming, J. and Martinho, C. (2021). “Exploitation of Log4j CVE-2021-44228 before public disclosure and evolution of evasion and exfiltration.” Cloudflare, December 14, 2021.
14. Netflix (2019). Security bulletin NFLX-2019-002, HTTP/2 denial-of-service vulnerabilities. August 13, 2019.
15. Venne, M. (2026). Proposals for FedRAMP VDR/VER, stackArmor, June–July 2026: “A Deterministic, CVSS-Environmental Method for FedRAMP VDR/VER Vulnerability Prioritization”; “Before the PAIN Equation: Deriving Security-Requirements Ceilings from Intended Federal Information Types”; “Calibrating PAIN Without Abandoning CVSS”; “PAIN Relief: A Verified-Control Method for Reducing FedRAMP VDR/VER PAIN and Exploitability”; “A CycloneDX VEX Profile for FedRAMP VDR/VER Disposition and Response”; “Internet Reachability at Scale under the FedRAMP VDR/VER Rules”; “A Finer Exploitability Gradation (VLEV) for FedRAMP VDR/VER”; “A Deterministic PAIN and Remediation Method for FedRAMP Compliance and Security-Benchmark Findings”. Sources at github.com/stackArmor/rfc-fedramp-vdr.
16. FedRAMP. FedRAMP 20x and the FedRAMP Marketplace, including the InfusionPoints XBU40 listing. Accessed October 2026.
17. InfusionPoints. fedramp20x-low-pilot-final (20x Low pilot package); “FedRAMP VDR and VER: From Monthly Scans to Continuous Trust,” July 9, 2026; Behind the Shield podcast, “Meet ‘Vader’,” July 21, 2026, and “From Monthly Scans to Continuous Monitoring,” April 7, 2026; and “InfusionPoints Achieves FedRAMP 20x Class C (Moderate),” April 10, 2026.
18. Meridian Knowledge Solutions. fedramp-trust-center, daily vulnerability report. Accessed October 23, 2026.
19. Paramify. paramify-fetchers, accepted-vulnerability and vulnerability-detail report fetchers. Accessed October 2026.
20. FedRAMP. Answers in the FedRAMP community forum: on automation, discussion #60 (August 2025); on impact, the clock and false positives, discussion #146 (September–October 2026); on timeframes in the rules data, discussion #164 (August 2026).
21. Teuscher, I. H. (2025). “Automating the RMF: Lessons from the FedRAMP 20x Pilot.” SiRAcon ’25, Boston, September 2025. arXiv:2510.09613.
22. Practitioner guides and rubrics, accessed October 2026: Knox Systems, “Open by Design: Knox’s FedRAMP 20x Vulnerability Management Rubric,” August 4, 2026; Endor Labs, “FedRAMP 2026 vulnerability rules make reachability a requirement,” August 26, 2026; 38North Security, “Process Spotlight: Judging Whether a Vulnerability Is Actually Exploitable,” September 30, 2026; Boundera, “FedRAMP 20x: Assign Vulnerability PAIN Ratings from Customer Effects,” October 10, 2026; Fortreum, “FedRAMP’s New Vulnerability Detection and Response Standard,” September 15, 2025; Stratus Cyber, “Vulnerability Detection and Response: What VDR Requires and How to Automate It,” updated August 17, 2026; Schellman, “The FedRAMP Consolidated Rules for 2026: What Rev 5 Certification Holders Need to Know,” August 18, 2026.
23. Evidence implementations, accessed October 2026: Amazon Web Services, “Building machine-readable FedRAMP 20x evidence on AWS,” August 19, 2026; Tarly, trust-center; Unified-Systems, fedramp-20x-vdr-tap, a plugin for The Analogy Platform.
24. Bradner, S. (1997). RFC 2119, “Key words for use in RFCs to Indicate Requirement Levels.” rfc-editor.org/rfc/rfc2119
25. Package URL specification. github.com/package-url/purl-spec.
26. Aydlette, S. (2026). “Pearls, PURLs and the FedRAMP 20x Inventory Problem.” samaydlette.com.