Run FedRAMP 20x KSI Checks in CI: The Boundera GitHub Action

You can now validate your Terraform against FedRAMP 20x Key Security Indicators on every commit — without standing up any infrastructure or sending your evidence to a vendor. Boundera's open-source FedRAMP 20x KSI Action runs entirely inside your own GitHub Actions runner, posts a pass/fail Check Run on your commits, and produces a hash-verified evidence pack a 3PAO can review. It's MIT-licensed and live on the GitHub Marketplace.

Key takeaways

• The action evaluates your Terraform IaC against two KSIs today: KSI-MLA-EVC (Evaluating Configurations) and KSI-CNA-RNT (Restricting Network Traffic).
• No vendor server. Everything runs in your runner; your evidence never leaves GitHub-managed infrastructure — which avoids a real FedRAMP boundary problem.
• It posts a Check Run per commit and uploads an evidence pack with SHA-256 integrity hashes, retained as a workflow artifact.
• It's honestly alpha (v0.1.0) and covers 2 of the program's KSIs — a focused, free starting point, not full coverage.

What problem does it solve?

FedRAMP 20x expects security evidence to be machine-readable, regenerable on demand, and produced by a persistent, automated cycle rather than a once-a-year screenshot exercise. For the indicators that govern infrastructure configuration, the most natural place to prove that is the same CI pipeline that already builds and deploys your system. If your infrastructure is defined in Terraform, your IaC is the source of truth for whether logging is evaluated and whether network traffic is restricted — so checking it on every change is exactly the "persistent validation" the program is asking for.

The catch with most compliance tooling is that it phones home: evidence flows through a vendor-operated backend to render a dashboard or post a status. For a cloud service provider whose runtime is in scope for FedRAMP, routing in-scope evidence through non-authorized infrastructure is a boundary question you'd rather not answer. This action is designed so that question never comes up.

How it works (no server in the loop)

The action is a self-contained step that runs on your ubuntu-latest runner. On each run it detects Terraform, initializes and validates it, builds an inventory from the HCL, evaluates the in-scope KSIs against that inventory, assembles an evidence pack with integrity hashes, and posts the result as a Check Run using the workflow's built-in GITHUB_TOKEN. Its only outbound calls are to GitHub's own API and the Terraform registry — nothing transits a Boundera server.

Stage	What happens	Where it runs
Detect & validate	Find Terraform, terraform init/validate	Your runner
Inventory	Parse HCL into a resource + network inventory	Your runner
Evaluate	Score each in-scope KSI against the inventory	Your runner
Evidence pack	Manifest + inventories + SHA-256 hashes	Workflow artifact
Report	Pass/fail Check Run on the commit	GitHub API

Because the evidence pack is a structured manifest with hashes — not a screenshot — it's the kind of artifact you can hand directly to a 3PAO and regenerate on demand, which is what the KSI validation rules require.

Quick start

Add a workflow like this to any repo that contains Terraform:

name: FedRAMP KSI
on:
  schedule:
    - cron: '0 0 * * *'   # daily — supports the persistent-validation cadence
  workflow_dispatch:
permissions:
  contents: read
  actions: read
  checks: write           # required so the action can post a Check Run
jobs:
  evaluate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: Boundera/fedramp-20x-ksi-action@v1

That's the whole integration — no app to install, no webhook, no secret to configure. The scheduled run matters: persistent validation is about a recurring cadence, so the daily trigger is what makes the evidence "current" rather than a one-off.

What it covers today (and what it doesn't)

This is an early, deliberately narrow release. It maps the two infrastructure-configuration KSIs that Terraform can authoritatively answer:

KSI	Name	Theme
KSI-MLA-EVC	Evaluating Configurations	Monitoring, Logging & Auditing
KSI-CNA-RNT	Restricting Network Traffic	Cloud Native Architecture

The other 50-plus indicators across the remaining KSI families are out of scope for this action — many of them simply can't be proven from Terraform alone (they need runtime config, identity data, logs, or human-process evidence). Some of those are mapped in the companion open-source FedRAMP 20x toolkit, and full multi-cloud, automated coverage is what Boundera's commercial product is for. We'd rather ship a small thing that's honest about its scope than a big thing that overpromises.

Where it fits in a 20x program

Think of this action as one instrument in a larger evidence pipeline, not the whole thing. It's a clean, free way to start treating KSIs as continuously-validated checks in the place engineers already live — the pull request. For the architecture behind that idea, see our guide on implementing KSI checks as first-class objects, and for the broader picture of automating KSI evidence collection across your whole environment.

Frequently asked questions

Is the FedRAMP 20x KSI Action free?

Yes. It's open source under the MIT license and free to use from the GitHub Marketplace. It runs on your own GitHub Actions minutes.

Does my evidence get sent to Boundera?

No. The action runs entirely inside your GitHub Actions runner, and its only outbound calls are to GitHub's API (to post the Check Run) and the Terraform registry (during init). No evidence transits a Boundera-operated server.

Which KSIs does it check?

Two, as of v0.1.0: KSI-MLA-EVC (Evaluating Configurations) and KSI-CNA-RNT (Restricting Network Traffic), both evaluated against your Terraform IaC. Legacy numeric IDs are accepted and auto-mapped.

Can I hand the output to a 3PAO?

Yes. Each run uploads an evidence pack containing a machine-readable manifest, the Terraform and network inventories, and SHA-256 hashes over every file for integrity. A 3PAO reviews the artifact directly — there's no vendor portal in between.

Is it production-ready?

It's labeled alpha (v0.1.x). The evaluation criteria, evidence format, and Check Run output are stable enough for daily use, but interfaces may change before v1.0, and breaking changes get a SemVer major bump. Treat it as a strong starting point, not your entire compliance program.

What FedRAMP spec does it evaluate against?

It bundles the FedRAMP machine-readable (FRMR) documentation it scores against, pinned to a specific version, so evaluations are hermetic and reproducible. Mappings are updated shortly after FedRAMP publishes changes upstream.

Sources

• Boundera/fedramp-20x-ksi-action (GitHub)
• FedRAMP 20x KSI Action on the GitHub Marketplace
• FedRAMP 20x Key Security Indicators (fedramp.gov)
• FedRAMP 20x Persistent Validation and Assessment (fedramp.gov)

---

Last updated: June 2026. Written by the Boundera team.