Judee Sill recorded “The Pearl” on Heart Food in 1973. As I read the song, it’s about a kind of authenticity that can’t be performed. I’ve been thinking about that song while thinking about FedRAMP 20x, because we are, at heart, trying to build a community across agencies, CSPs, 3PAOs, and oversight bodies that have no other reason to trust each other except via the artifacts we exchange. Trust that will last must be grounded in what’s actually there. 20x is a serious attempt at putting that principle into practice, and it has a chance to fulfill it.

I’ve written before about why I’m excited for 20x. Continuous validation is the right paradigm shift, and the move from annual snapshots to live signal is overdue. But there’s a structural gap that I think could fragment the program if it isn’t closed: the bet that automated KSI validation makes inventory questions answerable without the need for a separate inventory deliverable. That bet only fully pays off if the KSIs themselves carry the references that make portfolio-level reasoning possible. They don’t yet.

KSIs produce real signal per system. But per-system signals don’t compose into a portfolio view, and risk management at scale is the actual job. This gap isn’t new. Rev 5 doesn’t make it easy either. 20x can be the answer, but only if the inventory problem is addressed.

This won’t fix itself, at least not anytime soon. Fortunately, there is a viable path forward that we can coalesce around today.

What the Authorizing Official actually does

Under FISMA, an Authorizing Official makes a risk-based determination that the security posture of the information systems in their portfolio is acceptable for their agency’s mission. “Acceptable for the mission” means an AO at a defense agency reasoning about what a compromise does to a warfighter’s confidence in their data, and an AO at a benefits agency reasoning about citizens who can’t afford a payment delay. It’s a hard job. Portfolios are large and the threat clock is short.

Now consider the AO’s job in motion. CISA drops an Emergency Directive that requires the AO to identify affected resources across their authorized footprint within hours. That footprint includes three or four IaaS systems, twenty SaaS systems, and the third-party SaaS dependencies behind those. The query they need to run is: across all of this, what’s the mission risk?

I have sat in rooms where Federal ISSOs working for an AO tried to do this via multiple open spreadsheets and an outdated list of CSP technical contacts on a 9-inch laptop screen. Using the Rev 5 packages, this involves digging into the Integrated Inventory Workbooks (IIW) and the raw vulnerability scans and attempting to put together a risk assessment from those deliverables across dozens of systems. A Herculean task.

Under the 20x paradigm, this problem remains. Ostensibly, the components being measured can be queried in near-real time. But this alone doesn’t empower agencies to answer the question in the above scenario easily. CSPs can make individually reasonable inventory modeling decisions that don’t reconcile across an agency’s portfolio. For example, is Terraform represented by the configuration, the resources it instantiates, or both? Are containers identified by PURL, image digest, or both? Are VMs identified by IP address, cloud resource ID, hostname, or some union of these? Are “internet reachable” components counted as public IPs, public subnets, permissive security group rules, or what’s actually receiving internet traffic? Each question has multiple defensible answers. Without a specification, every CSP picks differently. The AO querying across them gets lists that look comparable and aren’t.

The worst possible failure mode is when wrong or misleading answers are declared confidently.

There is no construct in the current 20x model for an AO to query across all authorized services and get back a single answer. The data exists but it doesn’t surface in a form that allows portfolio-level reasoning. So the real choice isn’t “KSI validation vs. inventory artifact.” It’s whether KSI signals carry standardized component references that compose across CSPs, or whether they stay locked inside per-vendor formats that don’t.

The future no one wants

As a consequence, AOs may demand supplementary instance-level context as a condition of agency ATO. The “reusable authorization” promise — the raison d’être of FedRAMP — could fragment back into bilateral arrangements. We could end up with the worst of both worlds: continuous validation the AO doesn’t actually use, plus per-agency artifact production that 20x was supposed to replace. The future of federal cloud compliance could be navigating a complex web of bilateral arrangements between large agencies and large CSPs, with smaller CSPs and agencies left to figure it out on their own. It’s likely that this is already happening in some cases.

The entire FedRAMP community has an incentive to prevent this. But addressing it requires a sustained degree of public/private coordination. The market has had roughly a decade to converge on cross-cloud inventory schemas and hasn’t. It’s unlikely to happen unless there is a concerted effort to do so.

What authentic looks like

Back to The Pearl. Authenticity isn’t a story you tell about yourself. It is what is actually there. A community built on stories that don’t match reality isn’t a community.

Federal cloud has the same property. What agencies need is the actual thing: KSI signals that name where they’re signaling from, in a form that composes across CSPs. Not “System X passed.” “System X passed, on these specific components, identified the same way everywhere.”

In the world of software supply chain, a PURL (Package URL) is an OSS standard that gives a uniform identifier for software components across ecosystems. PURLs are how the OSS community names what is actually there, in a form anyone can verify and compare. The pun is the point. PURL is one instance of the authentic identifier pattern this program needs. But the pattern has to extend across the stack.

What a group of CSPs that wanted to solve this could ship

None of what follows requires capabilities that don’t already exist.

SLSA L3 provenance and Sigstore signing OSS artifacts form the foundation. Many major CSPs are already doing this at scale, and the mechanics of implementing it are tractable. Every production deployment passes through CI that emits what was built, from what source, by what builder, using what inputs. The same CI emits an SBOM listing the components inside the artifact. Both are signed and pushed alongside the artifact. The cloud control plane records what came into existence with its native identifier. Each step references the prior step. The chain from commit to running pod is recorded as a side effect of normal operation.

What’s missing is the standard for how that chain gets surfaced inside the KSI signal itself. The hard part of knowing what’s running, proving it came from a known source, in a known build, at a known time, is already solved. The federal inventory problem is specifying how that existing signal gets attached to the KSIs that CSPs are already reporting under 20x.

Defining this standard is also tractable. Software components get identified by PURL. Cloud resources get identified by native cloud ID. For SaaS offerings built on cloud infrastructure, it really is that simple. For infrastructure-level hardware inventory, the path is less unified but real. CycloneDX HBOM extends the same schema already in scope for SBOM and is the most workable starting point; CISA’s 2023 HBOM Framework is the federal-aligned reference for what fields matter. Hardware identifiers ultimately rest on supplier-issued serials, so this won’t be as clean as the software side, but it still composes.

The change to the 20x model is subtle but consequential. A KSI today says a system passed a check. A KSI under this proposal says which specific components passed the check, named the same way across CSPs so they can be matched across systems and traced through dependencies. Inventory stops being a separate artifact and becomes a property of the validation signal itself. KSIs aggregate across CSPs because the components they evaluate are identified the same way everywhere.

FedRAMP or a CSP consortium could publish the component-type schema that maps native cloud identifiers into normalized types. An EC2 instance, an Azure VM, a GCP Compute Engine VM, and a bare-metal Kubernetes node all project into “compute instance” with comparable attributes. CSPs apply the schema when they report their KSIs. No central inventory deliverable is required.

Cross-portfolio queries still need to fan out across CSPs and compose the resulting agency-wide reporting. That can happen in agency tooling, in a federally-operated query service, or in third-party tools. This choice is about where the join happens, and with the inventory standard in place, it’s flexible.

With the above approach, if a CVE drops in a widely-used library, agencies are empowered to answer “what is the overall impact on my mission?” in minutes rather than weeks.

The pearl we’re actually building

20x is a bet on a community of practice where validation is continuous and shared rather than periodic and siloed. The bet is good. But it only works if the validation signals carry enough information about what they’re representing that an agency can compose them across their portfolio. That’s a small change to what KSI signals contain, but it’s the big difference. Otherwise the AO is structurally undercut, the program fragments, and the validation signal doesn’t compose into the portfolio view an agency needs.

The pearl is the thing you can’t fake and can’t borrow. The PURL is the technical version of the same idea. Without it, 20x risks becoming a simulacrum of continuous assurance. With it, FedRAMP fulfills its promise: a bridge that builds trust between organizations that would otherwise have no reason to extend it, but every reason to benefit when they do.