OSCAL Kubernetes Compliance

What it is

OSCAL (Open Security Controls Assessment Language) is NIST’s machine-readable format for expressing security control implementations and assessment results as structured data — not prose. The platform uses OSCAL 1.1.2 as the single source of truth for which NIST 800-53 Rev 5 controls are implemented and how.

Why machine-readable matters

A prose security plan tells an auditor what you intend to do. An OSCAL component-definition tells a tool what is actually deployed — and lets that tool check the live cluster against the spec automatically. The control mapping, severity classification, and enforcement intent all live in one place: platform/p3-compliance/oscal/component-definition.yaml.

Disclaimer. Not legal/compliance advice. Verify against your authorizing official’s requirements. Verified 2026-05-29.

Architecture overview

The compliance stack has two layers:

Kyverno Admission Controller — 48 ClusterPolicies enforce NIST 800-53 High baseline controls at the Kubernetes API server. Violations are logged (Audit mode) or blocked (Enforce mode) before resources are admitted.
Trivy Vulnerability Scanner — the Trivy Operator runs continuously, scanning container images for CVEs and checking cluster configuration. It produces VulnerabilityReport and ConfigAuditReport resources in-cluster.

Both layers are described in component-definition.yaml. Lula reads that file and validates the live cluster against each control’s evidence rules.

The component-definition.yaml file

platform/p3-compliance/oscal/component-definition.yaml contains:

Two components — Kyverno Admission Controller and Trivy Vulnerability Scanner
One implemented-requirement per NIST control ID — each requirement names the policy that implements it, its severity, and its enforcement mode
Back-matter Lula validations — one per Kyverno policy plus one for the Trivy Operator deployment; each embeds an OPA rule that confirms the resource exists in the cluster

Severity levels

Value	User term	Kyverno mode	Action when violated
`critical`	show-stopper	`Enforce`	Blocks admission or treat as P1
`high`	warn	`Audit`	Sprint-level remediation
`medium`	warn	`Audit`	Quarterly remediation
`low`	info	`Audit`	Periodic review

Only nist-db-production-backup-required ships in Enforce mode — it is the one control where a missing backup policy must hard-block at admission. All others are Audit.

Running Lula validation

Lula reads the component-definition, connects to the cluster, and runs each back-matter OPA rule against live resources.

# Install Lula
brew install defenseunicorns/tap/lula

# Run from the oscal directory
cd platform/p3-compliance/oscal
make validate

# Generate OSCAL assessment-results
make assess

make validate exits non-zero if any control’s evidence rule fails. Use make assess to write a full assessment-results.yaml that can be uploaded to a compliance dashboard or shared with auditors.

Updating controls

Adding a new Kyverno policy

Write the ClusterPolicy YAML in platform/p3-compliance/kyverno-policies/files/.
Add one implemented-requirement per NIST control ID in component-definition.yaml under the Kyverno component, using the next sequential ir UUID.
Add a back-matter resource entry for the policy (next sequential bm UUID) with the Lula validation block.
Update the relevant M3/Runbooks/Platform/Kubernetes page if the new policy needs Storybook-visible operator guidance.

Changing severity

Update props[name=severity].value in the relevant implemented-requirement entries. Use critical only when the control is a show-stopper that warrants blocking admission.

Promoting Audit to Enforce

Two steps — both must happen together:

In component-definition.yaml: set props[name=enforcement-mode].value to Enforce for the affected implemented-requirement entries.
In the Kyverno YAML: set spec.validationFailureAction: Enforce.

Doing only one of these creates a drift between the OSCAL record and live cluster behavior.

Linting the OSCAL file

compliance-trestle can validate the YAML structure against the OSCAL schema:

pip install compliance-trestle
cd platform/p3-compliance/oscal
make lint

What was removed

The prior setup used two bespoke non-OSCAL artifacts that are now deleted:

Removed file	What it was	Replaced by
`trivy-operator/files/trivy-nist-800-53-compliance-report.yaml`	Aquasecurity `ClusterComplianceReport` CRD mapping control IDs to Trivy check IDs	Lula OPA validation in OSCAL back-matter
`trivy-operator/files/trivy-nist-policies-configmap.yaml`	OPA/Rego rules in a ConfigMap	Lula OPA validations embedded in `component-definition.yaml`
`kyverno-policies/tools/generate_*.py`	Python scripts that generated the above	No longer needed — OSCAL is hand-authored and single-sourced
`kyverno-policies/data/SP_800-53_v5_1_XML.xml`	NIST XML catalog consumed by the generators	NIST OSCAL YAML catalog referenced by URL in `component-definition.yaml`

OSCAL Component Definition (Storybook) — rendered YAML view
NIST 800-53 — the control catalog this platform implements
Lula docs — validation toolchain reference
compliance-trestle — OSCAL authoring and linting

Sources (verified 2026-05-29)

Claim	Source
OSCAL 1.1.2 format	NIST OSCAL
NIST SP 800-53 Rev 5 catalog	NIST OSCAL content
Lula validation toolchain	Lula docs