The Compliance and Security Frameworks domain is the smallest slice of the Kubernetes and Cloud Native Security Associate (KCSA) exam — roughly 10% — but it’s the one candidates most often treat as an afterthought, and it’s the one that quietly decides borderline passes. Every other KCSA domain teaches you a control: RBAC, NetworkPolicy, Pod Security Admission, image signing. This domain teaches you the language and structure that industry uses to decide which controls matter, how well they’re implemented, and how you prove it to an auditor or an attacker’s playbook.
This guide maps the entire domain the way a practitioner would, with the exam cues that tell you which framework a question is really testing. Remember the format first: the KCSA is 60 multiple-choice questions in 90 minutes, entirely conceptual — you won’t type commands in the exam. But knowing what each framework is for, who publishes it, and when you’d reach for it is exactly what these questions reward. Any commands below are for building intuition, not memorization.
If you’re just orienting yourself to the whole exam, start with the KCSA exam guide for 2026 and the KCSA exam topics breakdown, then come back here to go deep on frameworks.
What “Compliance and Security Frameworks” Actually Covers
The KCSA curriculum breaks this domain into a handful of connected ideas. Here’s the map, with where each fits into a real security program:
| Concept | What it is | Who publishes it | Exam cue |
|---|---|---|---|
| Compliance frameworks | Regulatory / industry obligations (PCI DSS, HIPAA, SOC 2, FedRAMP, GDPR) | Industry bodies, regulators | ”must meet a legal/industry requirement” |
| Threat modeling frameworks | Structured ways to enumerate threats (STRIDE, attack trees) | Academia, Microsoft | ”systematically identify what could go wrong” |
| Benchmarks & hardening guides | Prescriptive config baselines (CIS Kubernetes Benchmark) | Center for Internet Security | ”harden to a known baseline / audit config” |
| Security frameworks & catalogs | Control catalogs and risk frameworks (NIST CSF, NIST 800-53, NIST 800-190) | NIST | ”map controls / manage risk / container guidance” |
| Adversary knowledge bases | Real-world attacker tactics & techniques (MITRE ATT&CK for Containers) | MITRE | ”what techniques would an attacker use” |
| Supply-chain frameworks | Integrity levels for the build pipeline (SLSA, in-toto) | OpenSSF / Linux Foundation | ”prove build provenance / harden CI/CD” |
| Automation & tooling | Tools that measure against the above (kube-bench, kube-hunter, Trivy, OPA) | CNCF, open source | ”automate the check / continuously verify” |
The unifying idea: frameworks tell you what good looks like; tooling tells you how far you are from it. The KCSA loves questions that ask you to match a scenario to the right framework, or to identify which tool automates a given framework’s checks.
Compliance Frameworks: The “Why” Behind the Controls
Compliance frameworks are external obligations. They rarely say “use RBAC” in Kubernetes terms — instead they say “enforce least privilege” or “encrypt data in transit,” and it’s your job to translate that into cluster controls.
The ones worth recognizing on the exam:
- PCI DSS — payment card data. Drives network segmentation (think NetworkPolicy), encryption, and audit logging.
- HIPAA — US healthcare data. Drives access control, encryption at rest, and audit trails.
- SOC 2 — a trust/attestation report common for SaaS vendors, built around security, availability, confidentiality, processing integrity, and privacy.
- GDPR — EU personal-data protection; data minimization and the right to erasure.
- FedRAMP — US government cloud authorization, which layers on top of NIST 800-53.
The KCSA exam cue for compliance is almost always a business or legal driver: “A fintech must protect cardholder data across its clusters — which type of framework applies?” The answer is a compliance framework (PCI DSS), not a technical control. Don’t overthink it: compliance = external mandate.
A key mental model: compliance is an outcome, not a control. You achieve compliance by implementing the technical controls covered in the other KCSA domains — the Kubernetes security fundamentals like RBAC, Pod Security Standards, secrets management, and audit logging — and then proving it with evidence.
The CIS Kubernetes Benchmark: Your Hardening Baseline
If you remember one artifact from this domain, make it the CIS Kubernetes Benchmark, published by the Center for Internet Security (CIS). It’s the most exam-relevant framework because it’s Kubernetes-specific and prescriptive: a long list of concrete checks like “ensure the --anonymous-auth argument is set to false on the API server” or “ensure that the --protect-kernel-defaults argument is set to true on the kubelet.”
Two properties matter for the exam:
- It’s a baseline, not a law. CIS Benchmarks describe recommended configurations. They’re the reference you audit against.
- Findings are scored/leveled. Recommendations are grouped (e.g., Level 1 for broadly-safe hardening, Level 2 for stricter, higher-impact settings), and each has a rationale and a remediation.
The benchmark covers the control plane (API server, controller manager, scheduler, etcd), worker nodes (kubelet, container runtime), and Kubernetes policies (RBAC, Pod Security, NetworkPolicy, secrets). It maps almost one-to-one onto the cluster component security domain — which is exactly why studying them together pays off.
kube-bench: Automating the CIS Benchmark
You don’t check hundreds of CIS recommendations by hand — you run kube-bench, an open-source tool (originally from Aqua Security) that inspects a cluster and reports which CIS Benchmark checks pass, fail, or warn. This is the single most important tool ↔ framework pairing in the domain:
CIS Kubernetes Benchmark = the standard. kube-bench = the tool that measures you against it.
Conceptually, a run looks like this (you will not run it in the exam):
# Run kube-bench as a Job against the current node
kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job.yaml
kubectl logs job/kube-benchSample output distilled:
[INFO] 1 Control Plane Security Configuration
[PASS] 1.2.1 Ensure that the --anonymous-auth argument is set to false
[FAIL] 1.2.16 Ensure that the --profiling argument is set to false
[WARN] 1.2.35 Ensure that the --tls-cipher-suites argument is set as appropriate
...
== Summary ==
42 checks PASS
5 checks FAIL
8 checks WARNExam cue: whenever a question says “automatically audit a cluster against a hardening standard” or “check CIS compliance,” the answer is kube-bench.
NIST: The Control Catalog and Container Guidance
The National Institute of Standards and Technology (NIST) publishes several documents you should be able to recognize by role, not by number-memorization:
| Document | What it gives you |
|---|---|
| NIST Cybersecurity Framework (CSF) | Five high-level functions to organize a program: Identify, Protect, Detect, Respond, Recover (newer versions add Govern) |
| NIST SP 800-53 | A large catalog of security & privacy controls organizations map to |
| NIST SP 800-190 | Application Container Security Guide — the container-specific one |
| NIST SP 800-204 | Security strategies for microservices-based applications |
For the KCSA, the two highest-value NIST items are the CSF functions (great for “which phase does detection belong to?” style questions) and SP 800-190, because it’s explicitly about container risks: image vulnerabilities, image configuration defects, embedded secrets, registry trust, orchestrator (Kubernetes) hardening, and runtime threats. If a question references a NIST publication about container security specifically, it’s 800-190.
The distinction to hold: CIS gives you prescriptive settings; NIST gives you a control framework and risk guidance. CIS says “set this flag to false.” NIST says “here’s the category of risk and the control family that addresses it.”
MITRE ATT&CK for Containers: Thinking Like the Attacker
Where compliance and NIST describe defense, MITRE ATT&CK describes offense. It’s a continuously-updated knowledge base of real adversary tactics and techniques, organized as a matrix: columns are tactics (the attacker’s goal — Initial Access, Execution, Persistence, Privilege Escalation, Defense Evasion, Credential Access, Discovery, Lateral Movement, Impact) and cells are techniques (how they achieve it).
MITRE maintains a Containers matrix with Kubernetes-relevant techniques such as:
- Exposed Kubernetes API / kubelet as an initial access vector
- Deploying a container / exec into container for execution
- Privileged container and hostPath mount for privilege escalation and host escape
- Accessing the Kubernetes service account token for credential access
- Cluster-internal reconnaissance via the API for discovery
The exam cue for MITRE ATT&CK is adversary behavior: “Which framework catalogs the tactics and techniques attackers use against containerized environments?” → MITRE ATT&CK. Contrast it sharply with the KCSA threat model: a threat model is your own analysis of what could go wrong in your system; ATT&CK is a shared, real-world catalog you can map your threat model against.
STRIDE and Threat-Modeling Frameworks
You should also recognize STRIDE, a threat-modeling mnemonic (Microsoft) for categorizing threats:
| Letter | Threat | Property it violates |
|---|---|---|
| S | Spoofing | Authentication |
| T | Tampering | Integrity |
| R | Repudiation | Non-repudiation |
| I | Information disclosure | Confidentiality |
| D | Denial of service | Availability |
| E | Elevation of privilege | Authorization |
STRIDE is how you generate a threat model systematically; MITRE ATT&CK is how you ground it in real attacks. Both feed the defensive controls you learned in the 4Cs of cloud native security.
Supply-Chain Frameworks: SLSA and in-toto
Modern attacks increasingly target the build pipeline, not the running cluster. Two frameworks address this and both appear in KCSA-adjacent material:
- SLSA (Supply-chain Levels for Software Artifacts, pronounced “salsa”) — an OpenSSF framework that defines increasing levels of build integrity. Higher levels require things like a scripted/hermetic build, provenance that’s generated by the build platform (not the developer), and tamper resistance. The point: the higher your SLSA level, the harder it is to inject malicious code into an artifact unnoticed.
- in-toto — a framework for cryptographically verifying that every step of the supply chain was carried out by the right party, in the right order, producing the expected artifacts.
These connect directly to the supply-chain concepts (SBOMs, image signing, provenance/attestation) in the platform security domain. Exam cue: build/pipeline integrity and provenance levels → SLSA.
Automation and Tooling: How Frameworks Get Enforced
Frameworks are useless as PDFs. The KCSA expects you to know which open-source tools operationalize them. Keep this pairing table in your head:
| Tool | What it does | Maps to |
|---|---|---|
| kube-bench | Audits a cluster against the CIS Kubernetes Benchmark | CIS Benchmark |
| kube-hunter | Actively probes a cluster for exploitable weaknesses (attacker’s view) | Penetration testing / ATT&CK-style techniques |
| Trivy / Grype | Scan images for known CVEs and misconfigurations | NIST 800-190 image risks, vuln management |
| OPA / Gatekeeper & Kyverno | Policy-as-code admission control to enforce baselines | CIS policies, Pod Security, custom compliance |
| Falco | Runtime threat detection from syscalls | MITRE ATT&CK runtime techniques |
| kubescape | Scans against frameworks (NSA/CISA, MITRE ATT&CK, CIS) | Multiple frameworks in one tool |
A useful distinction the exam likes: kube-bench audits configuration (are you hardened?), while kube-hunter tests exploitability (can I break in?). One checks the baseline; the other simulates the adversary.
Policy engines are where compliance becomes continuous rather than a point-in-time audit. Instead of running kube-bench once a quarter, you encode “no privileged pods,” “images must come from our registry,” and “every namespace must have a NetworkPolicy” as admission policies that reject violations at creation time. That shift — from periodic audit to continuous enforcement — is the practical heart of this domain.
How These Frameworks Fit Together
Picture a single flow, because that’s how the exam reasons about it:
- A compliance framework (PCI DSS) sets the obligation: protect cardholder data.
- A security framework (NIST CSF / 800-53 / 800-190) organizes the obligation into control families and container-specific risks.
- A benchmark (CIS Kubernetes Benchmark) turns the relevant controls into concrete, checkable settings.
- A threat model (STRIDE) plus an adversary catalog (MITRE ATT&CK for Containers) tell you what you’re defending against.
- A supply-chain framework (SLSA) hardens how your artifacts are built.
- Automation tooling (kube-bench, Trivy, OPA/Kyverno, Falco) continuously measures and enforces all of it.
If you can narrate that chain, you can answer almost any question in this domain, because every question is really asking “which layer of this chain is being described?”
Common KCSA Traps in This Domain
- Confusing CIS with NIST. CIS = prescriptive Kubernetes settings you audit with kube-bench. NIST = control catalogs and container guidance (800-190). If the question mentions specific flag settings, think CIS.
- Confusing MITRE ATT&CK with a threat model. ATT&CK is a shared, real-world catalog of attacker techniques. A threat model is your analysis of your system. You map one onto the other.
- Assuming compliance = a technical control. Compliance is an outcome you demonstrate by implementing controls and collecting evidence.
- Mixing up kube-bench and kube-hunter. kube-bench audits config against CIS; kube-hunter actively hunts for exploitable weaknesses.
- Thinking SLSA protects the cluster. SLSA protects the build pipeline and artifact integrity, upstream of the cluster.
Study Strategy for the Frameworks Domain
Because it’s only ~10% of the exam, don’t over-invest — but don’t skip it either, since the questions are usually gimme points once you know the mappings. A focused plan:
- Memorize the pairings, not the paragraphs: CIS↔kube-bench, image CVEs↔Trivy, runtime↔Falco, admission policy↔OPA/Kyverno, attacker techniques↔MITRE ATT&CK, build integrity↔SLSA.
- Learn the NIST CSF functions (Identify, Protect, Detect, Respond, Recover) — they’re easy points and reusable across security certs.
- Read one or two CIS Benchmark recommendations end to end so you recognize the shape of a benchmark (recommendation → rationale → audit → remediation).
- Drill scenario questions that force you to pick the right framework or tool for a described situation — that recognition speed is what the exam rewards.
The last step is the highest-leverage one. Multiple-choice framework questions live or die on your ability to instantly match a scenario to the right acronym. The KCSA mock exam bundle is built for exactly that kind of reflex-building — scenario-style questions with explanations that reinforce why a given framework or tool is the right answer — and you can warm up for free on the KCSA practice questions page before committing to a full timed set. Pair that with the KCSA study plan to sequence this domain alongside the heavier ones.
Conclusion
The Compliance and Security Frameworks domain is small, but it’s the connective tissue of the whole KCSA. Every technical control you learn elsewhere exists because some compliance framework requires it, some security framework organizes it, some benchmark makes it checkable, some attacker technique motivates it, and some tool measures it. Learn the chain — obligation → framework → benchmark → threat → automation — and you’ll not only bank the easy 10% of points, you’ll understand why the other 90% of the exam is structured the way it is.
Master this domain and you’ve learned how real security teams decide what to do and prove they did it — which is the skill that outlasts any single exam.
FAQ
How much of the KCSA exam is Compliance and Security Frameworks?
The Compliance and Security Frameworks domain is roughly 10% of the KCSA exam. It’s the smallest domain, but the questions are usually straightforward once you know how the frameworks and tools map to each other.
What is the difference between the CIS Benchmark and kube-bench?
The CIS Kubernetes Benchmark is the standard — a prescriptive list of recommended hardening settings for the control plane, nodes, and Kubernetes policies. kube-bench is the open-source tool that runs those checks against a live cluster and reports pass/fail/warn. One is the ruler; the other is the measurement.
Is MITRE ATT&CK the same as a threat model?
No. MITRE ATT&CK is a shared, continuously-updated knowledge base of real-world attacker tactics and techniques (including a Containers matrix). A threat model is your own structured analysis — often built with a method like STRIDE — of what could go wrong in your specific system. You typically map your threat model against ATT&CK to ground it in real attacks.
What is SLSA and why does it matter for Kubernetes security?
SLSA (Supply-chain Levels for Software Artifacts) is an OpenSSF framework that defines increasing levels of build-pipeline integrity — hermetic builds, platform-generated provenance, and tamper resistance. It matters because many attacks target the build pipeline before an image ever reaches your cluster, so a higher SLSA level makes it much harder to slip malicious code into your artifacts unnoticed.
Which NIST document is specifically about container security?
NIST SP 800-190, the Application Container Security Guide. It covers container-specific risks like image vulnerabilities, embedded secrets, registry trust, orchestrator (Kubernetes) hardening, and runtime threats — distinct from the broader NIST Cybersecurity Framework or the SP 800-53 control catalog.
Do I need hands-on skills to pass this domain?
No. The KCSA is multiple choice and conceptual — you won’t run kube-bench or read an ATT&CK matrix during the exam. You need to recognize what each framework is for and which tool automates it. Drilling scenario questions with the KCSA mock exam bundle is the fastest way to make those mappings automatic.