A Comparison of Kubernetes Compliance Standards and Configuration Scanners Michael Krieger1 , Markus Gierlinger2 , Farooq Shaikh1 , and Mario Kahlhofer1
arXiv:2606.24438v1 [cs.CR] 23 Jun 2026
1
Dynatrace Research, Linz, Austria {michael.krieger, farooq.shaikh, mario.kahlhofer}@dynatrace.com https://research.dynatrace.com 2 Independent Researcher, Linz, Austria [email protected]
Abstract. Kubernetes has become the industry standard for orchestrating containers in microservice-based software architectures. While several hardening guidelines and scanning tools for securing Kubernetes clusters and deployments have emerged in recent years, their differing guidance and outputs often lead to inconsistent configuration and prioritization decisions. This work presents a systematic comparison of eight commonly used Kubernetes hardening guidelines. Through this comparison and the inclusion of best practices, we established a benchmark of 79 Kubernetes configuration recommendations and conducted the a structured empirical evaluation of ten popular static configuration scanning tools and their scoring outputs. Our findings reveal substantial disparities in the coverage of configuration issues across hardening guidelines and scanners, as well as inconsistencies in how configuration issues are scored and ranked by different scanners. These results highlight the need for more standardized, transparent, and consistent approaches to risk and severity assessment of Kubernetes configuration issues. Keywords: Kubernetes · Security Configuration · Hardening Guidelines · Static Analysis · Configuration Scanning
1
Introduction
Kubernetes (k8s) is an open-source platform for automating the deployment, scaling, and management of containerized applications. Its resiliency and flexibility have driven widespread adoption across diverse domains, including 5G networks [8,42] and Internet of Things (IoT) environments such as software-defined vehicles [45]. Its greatest impact, however, has been in cloud environments, where it has become the de facto standard for service deployment. In Kubernetes, application workloads are defined declaratively using manifests that describe a desired system state, which Kubernetes continuously reconciles with the actual cluster state. While this model integrates well with automation and simplifies operations, it requires substantial expertise. Developers
2
M. Krieger et al.
must understand numerous configuration options, their defaults, and their security implications. Consequently, secure system configuration remains challenging beyond writing secure code [16], and misconfigurations often surface only after deployment in complex environments. These challenges have led to the emergence of multiple Kubernetes hardening guidelines and standards, including the CIS Kubernetes Benchmark [10], the NSA/CISA Kubernetes Hardening Guide [36], and the Kubernetes Security Technical Implementation Guide (STIG) [1]. Developed by different organizations, these guidelines vary in scope, level of detail, update frequency, and focus, ranging from high-level best practices to detailed configuration recommendations. The challenges posed by this fragmented landscape manifest in two ways. First, practitioners who rely on a single hardening guideline or scanner may develop a false sense of security, unaware of the significant coverage gaps that individual guidelines and tools exhibit. Second, achieving broad coverage requires combining multiple guidelines and tools, which substantially increases the operational workload. Depending on regulatory and organizational requirements, practitioners may further need to satisfy additional standards, compounding this effort. Prior work has studied Kubernetes security practices and scanner performance [47,40,7,28], but has neither systematically compared hardening guidelines nor benchmarked scanner coverage against them. Moreover, while vulnerability scoring has been extensively researched [3,33,29], risk assessment approaches for Kubernetes configuration issues remain largely unexplored. To address these gaps, this paper presents a comparative analysis of Kubernetes hardening guidelines and benchmarks static configuration scanners with respect to coverage, detection accuracy, and risk assessment. We investigate the following research questions: – RQ1: Do different hardening guidelines and benchmarks provide the same configuration recommendations for Kubernetes? – RQ2: How accurately do different scanners detect common configuration issues in Kubernetes workloads? – RQ3: Do different scanners provide comparable risk assessments for common configuration issues? The primary contributions of our work are: – Structured comparison of Kubernetes hardening guidelines: We present a systematic comparison of hardening guidelines published by prominent organizations, identifying duplications, inconsistencies, and contradictions within and across guidelines. – Comprehensive empirical evaluation framework: We introduce a datadriven framework for evaluating scanner accuracy, coverage, and severity scoring with respect to Kubernetes hardening guidelines. – Reusable benchmark manifests: We develop benchmark manifests that enable reproducible evaluation of scanner accuracy, coverage, and severity scoring.
Kubernetes Compliance Standards and Scanners
3
Kubernetes Cluster Control Plane
Worker Nodes
Scheduler
Pods Cntr.
Cntr.
etcd
Controller Managers API Server
A A A
Manifests 1
Fig. 1. Typical components of a Kubernetes cluster.
– Actionable insights for practitioners: We highlight substantial disparities in scanner coverage and scoring behavior, providing guidance for practitioners selecting tools to identify configuration issues in Kubernetes deployments.
2
Kubernetes Architecture, Hardening Guidelines, and Scanners
This section provides an overview of the architecture of Kubernetes and a description of selected hardening guidelines and scanners. 2.1
Kubernetes
Kubernetes is an open-source platform for automating the deployment, scaling, and management of containerized applications. Application workloads and supporting resources are defined declaratively using manifests, which describe a desired state that Kubernetes continuously reconciles with the actual cluster state. Architecturally, a Kubernetes cluster is divided into a control plane and a data plane. The control plane provides orchestration and management functionality through components such as the API server, controller managers, scheduler, and etcd. It enforces authentication and authorization (typically via role-based access control) and uses controllers to reconcile the desired state defined in manifests with the cluster’s current state. The data plane hosts application workloads on worker nodes. Containers run within pods, the smallest deployable units in Kubernetes, while higher-level resources such as deployments and services manage replication, fault tolerance,
ar CI
S
K8
O
sB
M
en ch m
1.0 et es rn be Ku
2015
2016
2017
2018
S T W hre AS at DI P C Mat rix SA he ST ats h IG ee BS t I A NSA PC PP.4 -CI SA I C .4 on & S Gu ta YS ide in er .1.6 s
M. Krieger et al.
k
4
2019
2020
2021
2022
2023
Kubernetes Security Checklist 1
Fig. 2. Timeline of first releases of K8s security standards.
load balancing, and stable network endpoints. Each worker node runs a kubelet agent that manages the lifecycle of workloads assigned to that node [31]. 2.2
Compliance and Security Guidelines
The Kubernetes Policy Working Group emphasizes the importance of adhering to both internal and external regulatory standards, as well as security best practices, particularly for Kubernetes workloads that process sensitive data or perform critical functions [41]. Because data and computing resources in Kubernetes environments are often globally distributed, achieving regulatory compliance is especially challenging, as requirements frequently depend on the specific jurisdictions in which data is processed. For our study, the selection of standards followed a systematic process. First, we examined the security scanners analyzed in Section 2.3 to identify the regulatory frameworks they support. We then reviewed widely recognized regulatory standards, including PCI DSS, HIPAA, GDPR, and SOC 2, together with their associated technical guidance. In addition, we considered recommendations issued by authoritative institutions in the United States and the European Union, such as the NSA, NIST, ENISA, and the PCI Security Standards Council (PCI SSC). Vendor-specific guidelines were excluded to avoid productspecific bias. This study does not aim to provide an exhaustive survey of all existing frameworks or guidelines; instead, we focus on widely adopted, reputable, and influential sources used by practitioners. The following section provides an overview of the eight security standards selected for analysis (Figure 2). Additional sources reviewed (e.g., ENISA container security guidance, Docker CIS Benchmark) either fell outside Kubernetes scope or repeated recommendations already captured, suggesting thematic saturation. 1. CIS Kubernetes Benchmark: Since 2017, the Center for Internet Security (CIS) has maintained a dedicated benchmark for Kubernetes, covering Kubernetes distributions and managed Kubernetes services. The CIS Kubernetes Benchmark is regularly updated and currently includes 131 recommendations (version 1.12).
Kubernetes Compliance Standards and Scanners
5
2. Microsoft Threat Matrix for Kubernetes: In 2020, Microsoft released the Threat Matrix for Kubernetes [52], which builds on the MITRE ATT&CK framework and identifies 35 mitigation actions mapped to 40 attack techniques. The threat matrix does not assign explicit risk or severity levels to the identified threats or mitigations. 3. OWASP Kubernetes Security Cheat Sheet: In 2020, the Open Worldwide Application Security Project (OWASP) published the initial version of the Kubernetes Security Cheat Sheet [49], which has since been updated regularly. Eight sections cover the full lifecycle of a Kubernetes deployment. 4. DISA Kubernetes STIG: Since 2021, the Defense Information Systems Agency (DISA) maintains a dedicated Security Technical Implementation Guide (STIG) for Kubernetes [1], which is updated regularly. Each of its 91 configuration rules includes a description, rationale, audit procedures, and remediation actions and an assignment to a severity category (Category I to III), corresponding to high, medium, and low severity. 5. NSA-CISA Kubernetes Hardening Guideline: In 2022, the National Security Agency (NSA) and the Cybersecurity and Infrastructure Security Agency (CISA) jointly published the Kubernetes Hardening Guide [36]. While an appendix provides concrete configuration examples, the main body of the guide — comprising 34 sections — focuses on general hardening strategies rather than prescriptive configuration rules. 6. BSI APP.4.4 and SYS.1.6: In 2022, the German Federal Office for Information Security (BSI) first published Kubernetes-related guidance as part of its IT-Grundschutz Compendium in sections APP.4.4 Kubernetes [25], comprising 21 requirements, and SYS.1.6 Containerisierung [26], comprising 26 requirements and categorized into basic, standard, and increased protection levels. 7. PCI Guidance for Containers and Container Orchestration Tools: In 2022, the PCI Security Standards Council (PCI SSC) released a supplement providing best practices for containers and container orchestration tools [13]. The document identifies 42 potential threats and proposes 49 technology-agnostic best practices to mitigate these threats. 8. Kubernetes Security Checklist: The Kubernetes project maintains several security hardening resources, including a general security checklist [6] and an application security checklist [5]. Together, these checklists comprise 76 recommendations, ranging from high-level guidance to specific configuration settings, including references to 12 recommended admission controllers. 2.3
Scanners
Many recommendations from the hardening guidelines described above can be verified automatically. This work focuses on tools for static analysis of Kubernetes manifests, which can be integrated into the development and predeployment phases of Kubernetes clusters and applications. To identify relevant tools, we conducted a comprehensive search across multiple sources, including the CNCF Landscape [12], GitHub repositories, and on-
6
M. Krieger et al.
n
er ub
K 2015
s ete
2016
1.0
2017
bes Ku
2018
ec
sc b e-
ku
ore is lar
Po
2019
2020
Checkov
yk Sn
vy Tri er int beL
Ku S KIC
b Ku
2021
2022
esc
ape
2023
Terrascan 1
Fig. 3. Timeline of first releases of K8s security scanners.
line materials such as blog posts and industry reports. We used targeted search terms—including “Kubernetes”, “k8s”, “security”, “misconfiguration”, “compliance”, and “scanner” — to ensure broad coverage. In addition, we reviewed industry analyses such as the Gartner Application Security Testing Magic Quadrant [21], the Forrester Wave Software Composition Analysis [19], and the Forrester Wave Static Application Security Testing [20] to identify prominent tools and industry trends. We limited our scope to open-source tools, including open-source offerings maintained by commercial vendors, as these tools are freely available to the Kubernetes community and often incorporate guidance derived from established security standards. We also added commercial tools with open-source CLI wrappers to our scope, but excluded purely proprietary and paid solutions. We acknowledge that this scope restriction means our findings are specific to the open-source scanner ecosystem; commercial scanners may exhibit different coverage and scoring behavior, which warrants separate investigation. Tools requiring a running cluster (e.g., kube-bench, KubiScan) were also excluded. Table 1 provides an overview of the 10 scanners analyzed in this study. The selected tools are listed below: 1. Kubesec [14] validates Kubernetes manifests using kubeconform [22] and can be run as a standalone tool. 2. kube-score [53] is a community-driven project with a single person serving as publisher and main contributor, distinguishing it from corporate-backed alternatives. 3. Polaris [17] functions as a policy engine that can be deployed as a dashboard, admission controller, or standalone scanner, with rules focusing on pod configuration. 4. Snyk [48] is a broader (commercial) security platform where Kubernetes scanning is part of its Infrastructure-as-Code (IaC) capabilities, which also requires connectivity to Snyk’s platform. Snyk can scan Kubernetes manifests and Helm charts. 5. Checkov [11] is an IaC and software composition analysis (SCA) tool from Palo Alto. Checkov supports scanning different technologies, including Kubernetes manifests and Helm charts.
Kubernetes Compliance Standards and Scanners
7
6. Terrascan [50] has been available as an archived project since November 2025, meaning it no longer receives active development. Terrascan scans manifests and Helm charts. 7. KICS [9] (Keeping Infrastructure as Code Secure) operates fully offline without requiring connectivity to external services and can scan multiple different technologies. 8. KubeLinter [23], sponsored by Red Hat and maintained by the StackRox community, can be run as a standalone tool on manifests and Helm charts. It provides no severity ratings. 9. Trivy [44] combines multiple scanning capabilities for manifests and Helm charts, including detecting vulnerable dependencies, sensitive data, secrets, and IaC misconfigurations. 10. Kubescape [4], originally developed by ARMO, is a CNCF incubating project that can run as standalone IaC scanner but also be used as admission controller or vulnerability scanner. Its severity scores are similar to CCSS [32] and CVSS [18].
Table 1. Overview of Kubernetes Security Scanning Tools Name
Year
Maintainer
Kubesec [14]
2017
ControlPlane
kube-score [53]
2018
Community
Polaris [17] Snyk [48] Checkov [11] Terrascan [50] KICS [9] KubeLinter [23] Trivy [44] Kubescape [4]
2019 2020 2020 2020 2020 2020 2021 2021
Fairwinds Snyk Palo Alto Tenable Checkmarx StackRox Aqua Security Armo / CNCF
3
OSS
Severity Ratings -30 to 1 (critical to low) 1/5/7/10 (critical/warning/low/ok) danger/warning low/medium/high/critical low/medium/high low/medium/high info/low/medium/high — low/medium/high/critical 0 to 10 (low to critical)
Rules 20+ 30+ 40+ 40+ 110+ 30+ 140+ 60+ 160+ 260+
Experiment Setup
This section describes the experiment design: how we categorized recommendations (Section 3.1), defined benchmark manifests (Section 3.2), derived severity scores (Section 3.3), and analyzed results (Section 3.4). 3.1
Identification of unique configuration recommendations
To address RQ1 (consistency across hardening guidelines), we identified recommendations recurring across multiple hardening guidelines. While the Common
8
M. Krieger et al.
Configuration Enumeration (CCE) [35] provides a standardized mechanism for uniquely identifying configuration recommendations, and NIST maintains a registry of assigned identifiers3 , no CCEs are currently defined for Kubernetes configuration recommendations. Moreover, only a small subset of guidelines assigns unique identifiers to Kubernetes recommendations (e.g., STIG). We therefore manually compared all selected guidelines, checked the individual recommendations for equivalence, and compiled a unified set of unique recommendations. For guidelines providing explicit configuration checks, we validated equivalence based on: (i) the configuration parameter described, and (ii) the recommended value or check procedure. For guidelines providing higher-level recommendations, we assessed whether our extracted configuration recommendations were covered by these statements. Where guidelines provided unique identifiers, we used these for cross-referencing. Given our focus on cluster and workload configuration, we aligned only recommendations focusing on Kubernetes architectural components. We adopted the categorization scheme of the CIS Kubernetes Benchmark, distinguishing recommendations related to the control plane, worker nodes, and policies. Recommendations not directly attributable to a specific component but still relevant to Kubernetes were classified as General Policies. Recommendations outside the scope of Kubernetes cluster and workload configuration — such as those related to CI/CD pipelines, image registries, or third-party tools — were excluded. This categorization enables a structured comparison of hardening guidelines by (i) separating control-plane and data-plane recommendations, (ii) identifying thematic emphases across guidelines, and (iii) consolidating configuration recommendations across multiple sources.
3.2
Definition of Benchmark Manifests
Our benchmark focuses on configuration issues expressible in Kubernetes manifest files for data-plane resources, including aspects of role-based access control (RBAC), service accounts, deployments, and network policies. We acknowledge this as a limitation. Future work should address control-plane security through complementary runtime analysis approaches. For generating benchmark manifests we started with 67 configuration recommendations for data-plane resources extracted from hardening guidelines. We added 12 additional security-relevant recommendations derived from operational best practices identified through the authors’ combined experience in Kubernetes security engineering. These additional recommendations were validated through the same expert review process described in Section 3.3 and are documented in the benchmark repository, resulting in a total of 79 configuration recommendations. For each recommendation, we created manifests violating exactly one configuration rule. When multiple violation variants existed for a single recommendation, we encoded each variant in a separate manifest. This process resulted 3
https://ncp.nist.gov/cce
Kubernetes Compliance Standards and Scanners
9
in a total of 241 manifests used for scanner benchmarking. All manifests were created using the AWS Cloud Development Kit for Kubernetes (cdk8s) [39] with Python bindings, which is a simple wrapper facilitating syntactically correct manifest generation. We first created secure default configurations (non-root, disabled host namespaces, read-only root filesystem, explicit resource limits) and then introduced a single deliberate violation per manifest by modifying the relevant parameter to a less secure setting. Each manifest was annotated with metadata, including (i) references to the corresponding hardening guideline recommendations, (ii) the exact manifest paths containing the configuration issue, (iii) an expectation of whether a scanner should report the issue, (iv) an expert-assigned severity category, and (v) an expert-assigned severity score (see Section 3.3). To enable consistent evaluation across all scanners, we developed an application that orchestrates test executions and analyzes scanner outputs. The application includes a wrapper for each scanner to extract metadata such as version information, supported execution modes, and output formats. Because several scanners produced multiple findings or lacked sufficient information to distinguish true from false positives, we incorporated scanner-specific metadata into the evaluation process. For example, when a scanner did not report precise manifest locations for findings, we manually mapped scanner rules to the corresponding manifest paths. We used JSON to represent these mappings in a machine-readable format and added appropriate post-processing to the scanner wrappers. This mapping and post-processing are implemented as part of a unified evaluation pipeline. All scanners were evaluated using their default configurations and built-in rule sets without custom policies or security overrides. 3.3
Scoring Configuration Issues
We started with a literature review of configuration scoring systems. The most relevant contribution is the work on the Common Configuration Scoring System (CCSS) by Scarfone and Mell [43] published by the National Institute of Standards and Technology (NIST) in 2010 [32]. CCSS was designed to complement established vulnerability scoring systems such as the Common Vulnerability Scoring System (CVSS) and the Common Misuse Scoring System (CMSS) [30]. For this study, we applied CCSS to the identified configuration recommendations. As no official CCSS scores are available for Kubernetes configurations, we engaged three domain experts with demonstrable hands-on experience in Kubernetes security engineering to independently assess each configuration recommendation. Following individual assessments, the experts resolved disagreements through a majority-vote consensus process to derive a final expert-curated CCSSbased severity score for each recommendation. We acknowledge that CCSS has not been revised since its initial publication in 2010; however, it remains the only standardized scoring framework designed specifically for configuration issues, and we use it here as a structured comparative baseline rather than as an authoritative ground truth.
10
M. Krieger et al.
To enable comparison with scanner-reported severities, we normalized the severity outputs of all scanners. This normalization involved (i) identifying the severity categories used by each scanner, (ii) mapping them to the qualitative severity scale defined by CVSS, and (iii) translating these qualitative ratings into representative values within CVSS severity ranges. The resulting normalized scanner scores and the expert-curated CCSS scores were then used in the experimental analysis to assess the consistency of severity assessments across scanners and their alignment with expert judgment. 3.4
Data Analysis
RQ1 (consistency across hardening guidelines): We mapped recommendations across guidelines following the methodology described in Section 3.1. RQ2 (detection quality of different scanners): To answer this question, we scanned our curated set of benchmark manifests using the selected scanners. We identified true positives, false positives, and false negatives by comparing the YAML path of each injected configuration issue in the benchmark manifests with the YAML path referenced by the scanner findings. From the resulting TP/FP/FN counts, we computed precision (fraction of alerts that are true positives) and recall (fraction of benchmark issues detected) for each tool, along with two aggregate metrics: – Coverage, defined as the fraction of benchmark configuration issues detected by a tool (i.e., the overlap between detected issues and the full benchmark set). Low coverage indicates that a tool is specialized in specific categories or implements only a limited set of checks. – F1-score, defined as the harmonic mean of precision and recall, summarizing detection performance in a single metric that weights false positives and false negatives equally. RQ3 (alignment of severity scoring): To address this question, we built on the benchmark used for RQ2. We included only results where the scanner provided a severity assessment. For scanners reporting qualitative severity categories, we mapped categories to numeric values as follows: critical to a score of 9.5, high or danger to 8.0, medium or warning to 6.0, low to 2.0, info or ok to 0.1 and skip to 0.0, following the CVSS guideline. For each finding, we computed the similarity (s) between a scanner severity score (cs ) and the expert score (ce ) using: s=1−
abs(cs − ce ) 10
(1)
The resulting similarity score ranges from 0 (maximally different) to 1 (equal). For each scanner, we then computed the mean and variance of similarity scores to quantify how consistently the scanner’s severity assessments align with expert
Kubernetes Compliance Standards and Scanners
11
scores. To identify potential scoring bias, we also computed the mean signed deviation (MSD) between scanner scores and expert scores. MSD captures whether a scanner’s severity assessments are, on average, higher or lower than the CCSSbased scores curated by the expert group.
CIS 1.12
NSA-CISA
STIG
BSI
PCI
MS TM.
K8s Chklst.
OWASP
extracted
Table 2. Overview of the analyzed hardening guidelines, number of recommendations or sections aligned to Kubernetes’ architectural components and concepts, identified unique recommendations across all analyzed hardening guidelines, and total number of recommendations/section which were mapped to architectural components and concepts.
Control
Master Node API Server Controller Manager Scheduler etcd AuthN & AuthZ Logging
21 30 7 2 7 3 2
2 7 3 2 1 1 2
12 26 6 3 9 – 2
1 3 1 – 1 1 –
1 5 6 2 3 2 2
1 6 1 1 1 1 1
– 15 1 – 3 – 1
1 4 1 1 1 1 3
24 47 9 4 8 3 4
Worker
Worker Node Kubelet kube-proxy
10 14 1
2 4 –
15 11 –
1 2 –
1 6 1
– – –
– 1 –
– 3 –
15 18 1
RBAC Pod Security Network Policies Secrets Management Ext. Adm. Control General Policies
13 12 2 2 1 4
4 5 3 – – 3
– 3 – 1 – 5
3 4 2 1 1 4
6 5 1 3 2 5
3 5 3 2 1 2
10 15 6 3 2 5
2 5 2 2 1 3
18 17 7 3 2 10
Policies
Rules
Total Mapped Mapped (in %)
131 34 91 47 49 35 76 53 190 131 23 88 15 31 22 60 24 100% 68% 97% 32% 63% 63% 79% 45%
4
Evaluation of Guidelines and Scanners
4.1
RQ1: Evaluating consistency of recommendations
Following the methodology outlined in Section 3.1, we mapped all extracted recommendations to Kubernetes architectural components (Table 2), excluding peripheral aspects such as CI/CD pipelines and image registries. In contrast, only
12
M. Krieger et al.
32% of the recommendations in BSI APP.4.4 Kubernetes and 45% of those in the OWASP Kubernetes Security Cheat Sheet could be mapped to our categorization. In total, we identified 190 distinct recommendations across the selected hardening guidelines. As shown in Table 2, most recommendations target the API server (47), the master node (24), the kubelet (18), RBAC and the use of service accounts (18), pod security (17), and the worker node (15). The least covered component is kube-proxy, with only a single recommendation. We did not identify any conflicting recommendations across guidelines published by different organizations. However, when examining individual guidelines, we identified contradictory statements within the Kubernetes Security Checklists published by the Kubernetes project. Specifically, the general security checklist states that memory limits should be set for the workloads with a limit equal or inferior to the request, whereas the application security checklist states that Memory limit should be set for the workloads with a limit equal to or greater than the request. In addition, analysis of the Kubernetes STIG v2R4 revealed several duplicate rules. For example, rules CNTR-K8-000860 and CNTR-K8003110 both address ownership of files in the /etc/kubernetes/manifests/ directory. Similarly, rules CNTR-K8-000880 and CNTR-K8-003240 both concern ownership of the kubelet configuration file, while rules CNTR-K8-000890 and CNTR-K8-003230 both address file permissions for the kubelet configuration file. Overall, our analysis indicates that the CIS Kubernetes Benchmark — currently the most widely adopted hardening guideline — provides a solid baseline in the sense that it achieves the broadest categorical coverage across Kubernetes components and is most frequently referenced by the scanners evaluated in this study. However, more than 50 additional recommendations for hardening Kubernetes clusters and deployments can be derived from the other analyzed guidelines. We identified no contradictions across different guidelines and only three duplicates and one contradiction within single guidelines, indicating a generally high degree of consistency across existing hardening guidelines. 4.2
RQ2: Detection quality and coverage of different scanners
We evaluated a total of 10 scanners using the benchmark manifests. For the calculation of coverage and F1-score, alerts were treated as binary classifications. An alert was considered a true positive only if the YAML path reported by the scanner matched the YAML path of the injected configuration issue in the manifest. If multiple alerts were raised for a manifest, the result was considered a true positive if at least one alert matched the correct path. Alerts without a matching path were classified as false positives. If a recommendation was represented by multiple variant manifests, a scanner was credited with detecting the issue if it successfully flagged at least one of the variants. If a scanner failed to raise an alert for all manifest variants representing a recommendation, the result was classified as a false negative and, consequently, as a lack of coverage. As shown in Table 3, only two scanners — Trivy and KICS — achieved an F1score of 0.69 or higher, representing the strongest overall balance of precision and
Kubernetes Compliance Standards and Scanners
13
recall among all evaluated scanners, while also achieving coverage of at least 50%. Both scanners include more than 140 Kubernetes-specific rules, suggesting a mature rule set. An outlier in this analysis is Polaris, which achieved competitive F1-score and high coverage despite providing fewer than 50 rules. This result indicates that Polaris’s rules are well-targeted at the configuration categories represented in the benchmark, with fewer spurious alerts compared to larger rule sets — suggesting that rule quality and specificity are more important than rule count for overall detection performance. All remaining scanners with fewer than 100 rules achieved coverage of 32% or less. Conversely, Kubescape illustrates that a larger rule set does not necessarily yield better results: despite providing the largest number of built-in rules, it did not achieve the highest coverage or F1-score. Additionally, we grouped benchmark manifests by category. More than half of the scanners included checks for exposed secrets (via environment variables or ConfigMaps). RBAC and service account configurations — represented by 26 configuration recommendations — showed particularly low coverage, with no scanner exceeding 40%. Network policy configurations were supported by many scanners, yet none correctly identified more than 50% of the corresponding benchmark manifests. In the area of workload and deployment definitions, six scanners detected more than 60% of configuration issues. No scanner detected missing pod-security labels in namespace definitions.
Network (5)
Secrets (2)
Admission (2)
General (11)
Checkov KICS kube-score KubeLinter Kubescape Kubesec Polaris Snyk Terrascan Trivy
0.550 5 18 0.705 12 22 0.354 – 11 0.466 2 15 0.481 3 20 0.388 2 15 0.589 7 23 0.420 5 15 0.481 1 16 0.694 10 25
– – 2 1 1 – 2 – – –
– 1 1 1 2 – 2 – – 1
1 1 2 1 2 – 2 1 1 1
6 7 4 4 6 2 5 1 7 5
Built-in rules Coverage(%) F1-Score 113 142 39 63 262 22 44 45 35 169
38.0 54.4 25.3 30.4 43.0 24.1 51.9 27.8 31.6 53.2
RBAC (26)
Scanner
Pod Security (33)
Table 3. List of scanners in alphabetical order with number of built-in rules for Kubernetes, calculated coverage and F1 scores, and details for different recommendation categories, with the number of manifests per category in parentheses.
14
4.3
M. Krieger et al.
RQ3: Alignment of severity scoring
Nine of the ten evaluated scanners provided a risk or severity assessment for identified configuration issues. KubeLinter did not provide a severity score, while Kubescape was the only scanner to report numeric scores in the range of 0.0 to 10.0, consistent with the CCSS scale. All other scanners reported qualitative severity categories (e.g., critical, high, danger, medium, warning, low, info, ok, skip). Across the benchmark, scanners provided severity assessments for 61 of the 79 configuration recommendations. Only one configuration issue received an assessment from all scanners, while 17 configuration issues were assessed by only a single scanner. After normalizing severity categories to CCSS scores, substantial discrepancies became evident. For 20 configuration issues, the difference between the lowest and highest assigned severity score was 5.0 or greater, and for nine issues the difference exceeded 7.0. The largest severity disagreements clustered around security context configurations (average range of 7.5 CCSS points) and resource limit definitions (average range of 5.2 points). For example, the missing readOnlyRootFilesystem specification in a container’s security context received severity ratings ranging from info (0.1, Kubesec) to critical (9.5, kube-score) — a 9.4-point spread for the same configuration issue. In contrast, RBAC permission checks showed the highest cross-scanner agreement, with an average severity range of 2.6 CCSS points. Notably, security context checks were the worst-aligned category for four of nine scanners (Checkov, KICS, kube-score, Terrascan) yet the best for Snyk and Trivy, revealing fundamental disagreement on how to classify these issues. When mapped to CVSS v3/v4 qualitative levels (Critical, High, Medium, Low, None), these differences would span at least three severity levels for the same configuration issue. We further compared scanner-assigned severity scores with the expert-curated CCSS scores, where the expert scores serve as a relative reference baseline. Four scanners produced, on average, higher severity ratings than the experts, while five scanners produced lower ratings (see Table 4). Terrascan showed the closest overall alignment with expert ratings, with a mean signed deviation (MSD) of 0.086. The most stable scanners in terms of similarity to expert ratings were Kubescape (similarity=0.857, MSD=0.786, variance=0.010), Polaris (similarity=0.845, MSD=0.984, variance=0.013), and Terrascan (similarity=0.830, MSD=0.086, variance=0.013).
5
Threats to Validity
We follow well-established guidelines for experimentation in software engineering [54] and discuss four types of threats to validity: conclusion validity, internal validity, construct validity, and external validity. Internal validity does not apply to our work, as it concerns incorrect cause-effect relationships, which are not the focus of this study. The remaining threats apply as follows:
Kubernetes Compliance Standards and Scanners
15
Table 4. List of scanners with number of findings, average similarity score, variance of similarity, and mean signed deviation (MSD) of similarity Scanner Checkov KICS kube-score Kubescape Kubesec Polaris Snyk Terrascan Trivy
Findings
Avg. Similarity
Sim. Variance
Sim. MSD
27 35 13 25 17 31 19 21 38
0.743 0.784 0.624 0.857 0.653 0.845 0.802 0.830 0.784
0.023 0.028 0.033 0.010 0.059 0.013 0.018 0.013 0.018
-2.341 -1.074 2.515 0.786 -2.647 0.984 -1.521 0.086 -0.700
– Conclusion validity: Our benchmark contains only configuration checks related to the data plane. Consequently, coverage does not extend to all possible Kubernetes configuration issues. While completeness cannot be demonstrated conclusively, the benchmark remains extensible to include controlplane configurations in future work. Furthermore, vertical-specific compliance regulations such as PCI DSS, HIPAA, and similar standards were intentionally excluded, as their scope is highly domain-specific and only indirectly related to the objectives of this study. Also, as our benchmark is derived from existing compliance frameworks and established tools, the results are inherently biased toward known and widely adopted controls. – Construct validity concerns the appropriateness of conclusions drawn from the underlying measurements. In our case, the catalog of configuration recommendations is intended to support a more systematic implementation and evaluation of compliance benchmarks. Assessing whether this goal is achieved would require a separate empirical investigation, which is beyond the scope of this work and represents an avenue for future research. – External validity relates to the generalizability of the findings. Our study is specific to Kubernetes and may not directly apply to other container management or orchestration technologies. Moreover, the benchmark encodes exactly one configuration issue per check, while providing multiple variants for certain issues, all of which are weighted equally in the analysis. This introduces an inherent bias in the resulting performance metrics, favoring categories with a larger number of checks or variants. Beyond these categories, a general threat to validity arises from temporal currency. The benchmark represents a snapshot in time and must be continuously maintained to remain relevant, as Kubernetes and its ecosystem evolve rapidly. For example, at the beginning of this research, Kubernetes supported Pod Security Policies (PSP) as a native admission control mechanism. During the course of this study, PSPs were deprecated and are no longer viable. Current best practices instead recommend the use of third-party admission controllers or, at a minimum, the enforcement of Pod Security Standards (PSS).
16
6
M. Krieger et al.
Discussion
The main findings of this study are the limited overlap among Kubernetes hardening guidelines, the fragmented coverage and detection accuracy of configuration scanners, and the lack of a coordinated approach to configuration risk assessment. This section summarizes these findings and derives implications for practitioners and future research. 6.1
Key findings
1. Lack of a centralized configuration knowledge base: There is no coordinated effort to harmonize Kubernetes configuration recommendations across standardization bodies, nor are vendors required to contribute to a shared repository comparable to vulnerability databases such as NVD4 , EUVD5 , or OSV6 . Consequently, multiple hardening guidelines coexist, differing in scope, level of detail, and focus areas (RQ1). Consolidating these heterogeneous recommendations requires substantial manual effort, which is currently delegated to practitioners operating Kubernetes environments. 2. Fragmented detection coverage of configuration scanners: In the absence of a central source of configuration issues, scanner vendors maintain proprietary rule sets. As a result, different tools detect different subsets of configuration issues, with only partial overlap (RQ2). The choice of scanner therefore directly determines which configuration issues are identified, leading to systematic blind spots when a single tool is used. 3. Non-standardized configuration risk assessment: Configuration scanners also differ significantly in their risk assessment approaches. Although the Common Configuration Scoring System (CCSS) defines a standardized method for assessing configuration risk, it has neither evolved nor been widely adopted for more than 15 years. The limited adoption of CCSS, including by organizations publishing hardening guidelines (e.g., CIS), has resulted in proprietary, non-comparable risk models across scanners (RQ3). We adopted CCSS for its structured scoring methodology—the systematic decomposition into access vector, complexity, and impact—rather than the currency of its specification. An updated configuration scoring framework remains an open research need. 6.2
Implications for practitioners
Practitioners should not rely on a single hardening guideline, as individual guidelines cover only subsets of relevant configuration issues and often provide insufficient guidance on concrete configuration values. Combining multiple guidelines is therefore necessary to improve coverage. https://nvd.nist.gov/ https://euvd.enisa.europa.eu/ 6 https://osv.dev/ 4 5
Kubernetes Compliance Standards and Scanners
17
Similarly, scan results obtained from a single static configuration scanner should be treated as incomplete. Coverage can be improved by using multiple scanners or by extending existing tools with custom rules aligned with selected hardening guidelines. Finally, scanner-provided risk assessments should not be used in isolation. Given the absence of standardized scoring, organizations should perform contextual risk assessments that account for asset criticality, threat models, and potential business impact. 6.3
Research gaps and future work
First, configuration issues defined across guidelines and scanners lack usable identifiers, preventing systematic alignment and comparison. Although the Common Configuration Enumeration (CCE) standard provides a suitable identification mechanism, it has not been adopted for Kubernetes configurations. Future work should investigate adoption barriers and alternative identification schemes. Second, configuration risk scoring remains underdeveloped compared to vulnerability scoring. Future research should evaluate whether existing scoring systems can be adapted to configuration issues or whether new models are required. Third, structured and reproducible methods for assessing the impact of configuration issues are largely missing. Developing systematic impact assessment methodologies is a prerequisite for reliable configuration risk scoring and prioritization.
7
Related Work
Existing literature on Kubernetes security primarily focuses on categorizing configuration issues, analyzing security smells, and evaluating tool performance in limited contexts. Quantitative and qualitative studies on structuring configuration issues Shamim et al. [47] identified eleven security practices as a result of a literature review analyzing 104 internet artifacts. The dataset consists of documentation and presentations and mostly blog posts [46]. In Bose et al. [7], the authors performed a qualitative analysis on the frequency of appearance of security defects. They did so by looking at over 5000 commits from 38 open source repositories and determining if a commit was security-related. They do not attempt to identify the actual configuration issues or categorize them. Rahman et al. [40] conducted an empirical study analyzing over 2000 Kubernetes manifests mined from 92 open source software repositories to systematically categorize configuration issues in Kubernetes manifests. Additionally, they created a static analysis tool (SLI-KUBE) to quantify the frequency of the identified configuration issues. As a result, they have uncovered eleven categories, which are represented by eleven specific rules in their tool.
18
M. Krieger et al.
Ponce et al. [37] conducted a review of 58 scientific and non-scientific literature publications on security smells in microservice-based applications and distilled ten common smells that violate security properties. In the subsequent work by Dell’Immagine et al. [15], they translated these ten security smells to Kubernetes deployments. For this, they implemented their own tool to analyze these smells both statically and dynamically. They build upon two open-source tools (Checkov and Kubesec.io) for the analysis, which we also evaluated individually against our benchmark. Their work provides a good analysis of smells in microservice-based applications. They do not inspect issues in adjacent areas in a Kubernetes environment, like sensitive RBAC configurations, multi-tenancy, or admission control in general. A comprehensive study on compliance models, security controls, and threats in a cloud environment was done by Hendre and Joshi [24]. The authors then created an ontology based on these controls and threats, which in turn could be used to recommend cloud security policies. Our work is more focused on technical controls specific to Kubernetes clusters. An analysis of configuration issues and vulnerabilities and their impact on the runtime security of a container was conducted by Pothula et al. [38]. Following the analysis, they propose a mapping of security controls for the runtime security of containers, linking the aforementioned vulnerabilities to a set of controls and best practices. Theodoropoulos et al. [51] provide a comprehensive survey on cloud security in general. They perform an exploratory analysis that identifies key security aspects in the cloud and map these onto available security features. These, in turn, are mapped to numerous contemporary solutions to implement them. Compared to our work, which focuses on Kubernetes, their identified aspects are focused on the cloud service provider (CSP). Consequently, their solution encompasses technologies not native to Kubernetes, and they do not discuss the specific configuration issues in Kubernetes in detail. Environments for structured security analysis and evaluation of security tools To address the shortage of environments to test security attacks and defenses Minna and Massacci [34] created a testbed, which can generate and deploy test cloud environments. Kubernetes is one of the supported technologies. In this work, the authors focus on the generation of susceptible cloud environments in general, where it’s possible to deploy vulnerable Kubernetes components and nodes. Kamieniarz et al.[27] analyzed the security posture of four different Kubernetes cluster deployments using different Kubernetes security tools. Their analysis is focused on identifying security issues in default deployments of Kubernetes comparing deployments using EKS, GKE, RKE2 and K3s. As part of their study they also investigated CIS compliance. However, they stated that their results were inconclusive due to shortcomings of the open-source tools they used for their experiments. Kapetanidou et al. [28] evaluated six Kubernetes security tools, which are also covered in our study. However, their analysis is focused on performance and resource consumption, with only a high-level estimate on the number of detected
Kubernetes Compliance Standards and Scanners
19
threats in a single environment. For their research they relied on Kubernetes Goat [2], which is vulnerable by design to educate about Kubernetes security and is not intended for benchmarking a broad spectrum of configuration issues. Our work examines the same tools and additional ones, focusing on the depth and breadth of their security checks and the configuration issues they cover.
8
Conclusions
This paper presents a comprehensive study of Kubernetes hardening guidelines and benchmarks, identifying common configuration recommendations and highlighting differences across guidelines from multiple organizations. Based on this analysis, we encode representative configuration issues in Kubernetes manifests and benchmark 10 popular open-source static scanners with respect to coverage, detection accuracy, and risk assessment. Our study addresses a gap in prior work, which has primarily focused on discovering new configuration issues or evaluating scanner performance in isolation. Our findings reveal a lack of consolidation of Kubernetes configuration issues and the absence of a coordinated approach to risk assessment. As a result, scanners detect different subsets of configuration issues and assign divergent risk scores even for similar or identical findings. This fragmentation directly impacts the effectiveness of configuration scanning tools. The core implication of this work is that Kubernetes hardening efforts suffer from limited coordination across guidelines and tools. We therefore recommend that practitioners consult multiple hardening guidelines, use more than one scanner, and apply context-aware risk assessments for identified issues. More broadly, our results highlight the need for the research community to develop standardized methods for consolidating and scoring configuration issues that align with the practical demands of modern cybersecurity operations.
References 1. Agency, D.I.S.: Kubernetes stig (Sep 2025), https://ncp.nist.gov/checklist/996 2. Akula, M.: Kubernetes goat: A kubernetes security learning playground (2026), https://github.com/madhuakula/kubernetes-goat 3. Allodi, L., Massacci, F.: Comparing vulnerability severity and exploits using casecontrol studies. ACM Transactions on Information and System Security 17(1), 1–20 (Aug 2014). https://doi.org/10.1145/2630069 4. Authors, K.: Kubescape (Dec 2025), https://github.com/kubescape/kubescape/ 5. Authors, T.K.: Application security checklist (Nov 2024), https://kubernetes.io/ docs/concepts/security/application-security-checklist/ 6. Authors, T.K.: Security checklist (Feb 2025), https://kubernetes.io/docs/ concepts/security/security-checklist/ 7. Bose, D.B., Rahman, A., Shamim, S.I.: ‘under-reported’ security defects in kubernetes manifests. In: 2021 IEEE/ACM 2nd International Workshop on Engineering and Cybersecurity of Critical Systems (EnCyCriS). p. 9–12. IEEE, Madrid, Spain (Jun 2021). https://doi.org/10.1109/EnCyCriS52570.2021.00009, https://ieeexplore.ieee.org/document/9476056/
20
M. Krieger et al.
8. Carrión, C.: Kubernetes as a standard container orchestrator - a bibliometric analysis. Journal of Grid Computing 20(4), 42 (Dec 2022). https://doi.org/10.1007/ s10723-022-09629-8 9. Checkmarx: Kics (Dec 2025), https://github.com/Checkmarx/kics 10. CIS: CIS Kubernetes Benchmark v.1.12.0. CIS Benchmarks (Sep 2025), https: //www.cisecurity.org/benchmark/kubernetes 11. Cloud, P.: Checkov (Dec 2025), https://github.com/bridgecrewio/checkov 12. Cloud Native Computing Foundation: Cncf landscape (2026), https://landscape. cncf.io/ 13. for Container Orchestration Special Interest Group, B.P.: Guidance for containers and container orchestration tools (Sep 2022), https://docs-prv.pcisecuritystandards.org/Guidance% 20Document/Containers%20and%20Container%20Orchestration%20Tools/ Guidance-for-Containers-and-Container-Ochestration-Tools-v1_0.pdf 14. ControlPlane: kubesec (Dec 2025), https://github.com/controlplaneio/kubesec/ 15. Dell’Immagine, G., Soldani, J., Brogi, A.: Kubehound: Detecting microservices’ security smells in kubernetes deployments. Future Internet 15(7), 228 (Jun 2023). https://doi.org/10.3390/fi15070228 16. Dietrich, C., Krombholz, K., Borgolte, K., Fiebig, T.: Investigating system operators’ perspective on security misconfigurations. In: Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security. p. 1272–1289. ACM, Toronto Canada (Oct 2018). https://doi.org/10.1145/3243734.3243794, https://dl.acm.org/doi/10.1145/3243734.3243794 17. Fairwinds: polaris (Dec 2025), https://github.com/FairwindsOps/polaris 18. FIRST.Org, Inc.: Common Vulnerability Scoring System v4.0: Specification Document. https://www.first.org/cvss/v4.0/specification-document (Nov 2023), Accessed: 2025-12-16 19. Forrester Research, Inc.: The forrester wave™: Software composition analysis software (Nov 2024), https://www.forrester.com/report/ the-forrester-wave-tm-software-composition-analysis-software-q4-2024/ RES181655 20. Forrester Research, Inc.: The forrester wave™: Static application security testing solutions (Sep 2025), https://www.forrester.com/report/ the-forrester-wave-tm-static-application-security-testing-solutions-q3-2025/ RES185613 21. Gartner, Inc.: Gartner magic quadrant for application security testing (Oct 2025), https://www.gartner.com/en/documents/7027498 22. Hamon, Y.: kubeconform (Dec 2025), https://github.com/yannh/kubeconform 23. Hat, R.: Kubelinter (Dec 2025), https://github.com/stackrox/kube-linter 24. Hendre, A., Joshi, K.P.: A semantic approach to cloud security and compliance. In: 2015 IEEE 8th International Conference on Cloud Computing. p. 1081–1084. IEEE, New York City, NY, USA (Jun 2015). https://doi.org/10.1109/CLOUD.2015.157, http://ieeexplore.ieee.org/document/7214167/ 25. für Sicherheit in der Informationstechnik, B.: App.4.4 kubernetes (edition 2023) (Feb 2023), https://www.bsi.bund.de/SharedDocs/Downloads/ DE/BSI/Grundschutz/IT-GS-Kompendium_Einzel_PDFs_2023/06_APP_ Anwendungen/APP_4_4_Kubernetes_Edition_2023.html 26. für Sicherheit in der Informationstechnik, B.: Sys.1.6 containerisierung (edition 2023) (Feb 2023), https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/ Grundschutz/IT-GS-Kompendium_Einzel_PDFs_2023/07_SYS_IT_Systeme/ SYS_1_6_Containerisierung_Edition_2023.html
Kubernetes Compliance Standards and Scanners
21
27. Kamieniarz, K., Mazurczyk, W.: A comparative study on the security of kubernetes deployments. In: 2024 International Wireless Communications and Mobile Computing (IWCMC). p. 0718–0723. IEEE, Ayia Napa, Cyprus (May 2024). https://doi.org/10.1109/IWCMC61514.2024.10592468, https://ieeexplore. ieee.org/document/10592468/ 28. Kapetanidou, I.A., Nizamis, A., Votis, K.: An evaluation of commonly used kubernetes security scanning tools. In: Proceedings of the 2nd International Workshop on MetaOS for the Cloud-Edge-IoT Continuum. p. 20–25. ACM, Rotterdam Netherlands (Mar 2025). https://doi.org/10.1145/3721889.3721924, https: //dl.acm.org/doi/10.1145/3721889.3721924 29. Koscinski, V., Nelson, M., Okutan, A., Falso, R., Mirakhorli, M.: Conflicting scores, confusing signals: An empirical study of vulnerability scoring systems. In: Proceedings of the 2025 ACM SIGSAC Conference on Computer and Communications Security. p. 1904–1918. ACM, Taipei Taiwan (Nov 2025). https://doi.org/10.1145/ 3719027.3765210, https://dl.acm.org/doi/10.1145/3719027.3765210 30. LeMay, E., Scarfone, K., Mell, P.: The Common Misuse Scoring System (CMSS): Metrics for Software Feature Misuse Vulnerabilities. No. NIST IR 7864, Gaithersburg, MD, 0 edn. (Jul 2012). https://doi.org/10.6028/NIST.IR.7864, https:// nvlpubs.nist.gov/nistpubs/ir/2012/NIST.IR.7864.pdf 31. Martin, A., Hausenblas, M.: Hacking Kubernetes. O’Reilly Media, Inc., 1st edition edn. (2021) 32. Mell, P., Scarfone, K.: The common configuration scoring system (ccss): Metrics for software security configuration vulnerabilities (2010-12-27 2010). https://doi. org/https://doi.org/10.6028/NIST.IR.7502 33. Milousi, K., Kiriakidis, P., Mengidis, N., Rizos, G., Mazi, M.S., Voulgaridis, A., Votis, K., Tzovaras, D.: Evaluating cybersecurity risk: A comprehensive comparison of vulnerability scoring methodologies. In: Proceedings of the 19th International Conference on Availability, Reliability and Security. p. 1–11. ACM, Vienna Austria (Jul 2024). https://doi.org/10.1145/3664476.3670915, https://dl.acm.org/doi/10. 1145/3664476.3670915 34. Minna, F., Massacci, F.: An open-source cloud testbed for security experimentation. In: 2022 22nd IEEE International Symposium on Cluster, Cloud and Internet Computing (CCGrid). p. 756–759. IEEE, Taormina, Italy (May 2022). https:// doi.org/10.1109/CCGrid54584.2022.00086, https://ieeexplore.ieee.org/document/ 9826094/ 35. National Institute of Standards and Technology: Common configuration enumeration (cce) (2026), https://ncp.nist.gov/cce 36. NSA/CISA: Kubernetes Hardening Guide. Cybersecurity Technical Report (aug 2022), https://media.defense.gov/2022/Aug/29/2003066362/-1/-1/0/CTR_ KUBERNETES_HARDENING_GUIDANCE_1.2_20220829.PDF 37. Ponce, F., Soldani, J., Astudillo, H., Brogi, A.: Smells and refactorings for microservices security: A multivocal literature review. Journal of Systems and Software 192, 111393 (Oct 2022). https://doi.org/10.1016/j.jss.2022.111393 38. Pothula, D.R., Kumar, K.M., Kumar, S.: Run time container security hardening using a proposed model of security control map. In: 2019 Global Conference for Advancement in Technology (GCAT). p. 1–6. IEEE, Bangalore, India (Oct 2019). https://doi.org/10.1109/GCAT47503.2019.8978433, https://ieeexplore.ieee. org/document/8978433/ 39. cdk8s Project Authors: cdk8s (Dec 2025), https://github.com/cdk8s-team/cdk8s
22
M. Krieger et al.
40. Rahman, A., Shamim, S.I., Bose, D.B., Pandita, R.: Security misconfigurations in open source kubernetes manifests: An empirical study. ACM Transactions on Software Engineering and Methodology 32(4), 1–36 (Oct 2023). https://doi.org/ 10.1145/3579639 41. Ramanathan, J., Bugwadia, J., Krishnamurthy, R., Parvin, G., Lamba, P., Watanabe, Y., Suderman, A., Keller, B., Sailer, A., Ficcaglia, R., Zeolla, J.: Kubernetes Governance, Risk, and Compliance. Policy GRC (oct 2023), https://github.com/kubernetes/sig-security/blob/main/sig-security-docs/ papers/policy_grc/Kubernetes_Policy_WG_Paper_v1_101123.pdf 42. Ruiz, Y.: Harnessing the potential of 5g with kubernetes (Feb 2023), https:// ubuntu.com/blog/harnessing-the-potential-of-5g-with-kubernetes 43. Scarfone, K., Mell, P.: Vulnerability scoring for security configuration settings. In: Proceedings of the 4th ACM workshop on Quality of protection. p. 3–8. ACM, Alexandria Virginia USA (Oct 2008). https://doi.org/10.1145/1456362.1456365, https://dl.acm.org/doi/10.1145/1456362.1456365 44. Security, A.: trivy (Dec 2025), https://github.com/aquasecurity/trivy 45. Shamim, A.: Containerization for the software-defined vehicle. ATZelectronics worldwide 18(12), 58–58 (Dec 2023). https://doi.org/10.1007/s38314-023-1560-7 46. Shamim, M.S.I., Bhuiyan, F.A., Rahman, A.: Kubernetes security best practices (May 2020), https://figshare.com/s/548f0f90a0f2744cf33a 47. Shamim, M.S.I., Bhuiyan, F.A., Rahman, A.: Xi commandments of kubernetes security: A systematization of knowledge related to kubernetes security practices. In: 2020 IEEE Secure Development (SecDev). p. 58–64. IEEE, Atlanta, GA, USA (Sep 2020). https://doi.org/10.1109/SecDev45635.2020.00025, https://ieeexplore. ieee.org/document/9230176/ 48. Snyk: Snyk (Dec 2025), https://snyk.io/ 49. Team, C.S.S.: Kubernetes security cheat sheet (Nov 2025), https:// cheatsheetseries.owasp.org/cheatsheets/Kubernetes_Security_Cheat_Sheet.html 50. Tenable: Terrascan (Nov 2025), https://github.com/tenable/terrascan 51. Theodoropoulos, T., Rosa, L., Benzaid, C., Gray, P., Marin, E., Makris, A., Cordeiro, L., Diego, F., Sorokin, P., Girolamo, M.D., Barone, P., Taleb, T., Tserpes, K.: Security in cloud-native services: A survey. Journal of Cybersecurity and Privacy 3(4), 758–793 (Oct 2023). https://doi.org/10.3390/jcp3040034 52. Weizman, Y., Patrich, D., Pliskin, R.: Threat matrix for kubernetes (Jan 2023), https://microsoft.github.io/Threat-Matrix-for-Kubernetes/ 53. Westling, G.: kube-score (Dec 2025), https://github.com/zegl/kube-score 54. Wohlin, C., Runeson, P., Höst, M., Ohlsson, M.C., Regnell, B., Wesslén, A.: Experimentation in Software Engineering. Springer Berlin Heidelberg, Berlin, Heidelberg (2024). https://doi.org/10.1007/978-3-662-69306-3, https://link.springer.com/10. 1007/978-3-662-69306-3