Container Security Risk Ontology

• Container Security Risk Ontology is a formal, machine-readable specification that automates the identification and assessment of security risks in containerized deployments.
• It operationalizes risk evaluation with SPARQL-based inference, deterministic scoring, and detailed mappings from container traits to regulatory controls.
• The framework addresses challenges of complex hybrid IT/OT architectures, fragmented stakeholder knowledge, and dynamic deployment changes, validated through industrial case studies.

The Container Security Risk Ontology (CSRO) is a formal, machine-readable specification for representing and automating the identification, assessment, and treatment of security risks in containerized deployments, particularly within operational technology (OT) environments. The CSRO integrates adversarial behavior models, contextual deployment assumptions, explicit attack scenarios, formalized risk assessment rules, and container security artefacts into a comprehensive OWL 2 / RDF ontology, enabling deterministic and reproducible risk calculation from deployment artefacts up to actionable mitigations (Landeck et al., 7 Jan 2026).

1. Objectives and Foundational Challenges

CSRO was developed to address three principal challenges in OT container environments:

• C1 Complexity: Hybrid IT/OT architectures and the necessity for elevated container privileges demand context-aware, granular threat modelling due to reduced container isolation (e.g., access to host-level network interfaces or ptrace capabilities).
• C2 Knowledge Exchange: Stakeholder knowledge is fragmented, and artefacts (such as Docker Compose and Dockerfiles) are disconnected from security policies, requiring a semantically-rich and interpretable knowledge representation.
• C3 Continuous Changes: The operational environment is subject to frequent changes, necessitating deterministic, automated, and technically integrated risk identification that remains robust against ongoing system evolution.

The intention is to formalize container security knowledge, ensure interpretability across technical and stakeholder domains, and provide deterministic support for both automated reasoning and auditability (Landeck et al., 7 Jan 2026).

2. Ontological Structure and Core Concepts

CSRO extends the container security modelling domain by introducing specialized classes and properties, building upon ATT&CK and STRIDE-inspired schemas. Table 1 summarizes the main ontological elements.

Main Class	Definition	Example Instance
ContainerAttackTechnique	ATT&CK-style attack technique	T1055.008 (Process Injection: ptrace)
ContainerDeploymentTrait	Concrete container configuration trait	cap-add=SYS_PTRACE
ContainerSecurityAssumption	Deployment security assumption	"Run as non-root"
ContextScenario	Scenario aggregating assumptions/components	HardenedScenario
AttackAction	Instantiated attack technique in a context	AttackAction_Basic
Impact	Damage/impact category	"Disastrous"
Risk	Concrete instantiation of a risk	--
RiskTreatment	Mitigation target/implementation	Use read_only_fs
ContainerSecurityGuideline	Human-readable recommendation	CIS Docker Benchmark

The CSRO graph structure embodies the relationship between attack techniques, deployment context, assumptions, impacts, risk quantification, and mapped countermeasures. Notable object/data properties include hasRequiredTrait, hasAssumptionWeight, hasLikelihoodRating, hasRiskLevel, and mitigatedBy, directly supporting explainability and automation.

3. Domain Integration: Adversarial, Contextual, and Artefactual Alignment

CSRO achieves domain integration across five knowledge areas:

• Adversarial Behaviors: Models container-focused ATT&CK techniques (e.g., process injection via ptrace) via ContainerAttackTechnique, leveraging mappings to projects such as MITRE d3fend.
• Contextual Assumptions: Encapsulates deployment premises (e.g., "containers run as non-root") within ContainerSecurityAssumption and aggregates them into ContextScenario instances such as BasicScenario and HardenedScenario.
• Attack Scenarios: Binds adversarial techniques and contexts as AttackAction, enabling granular mapping of impacts and subsequent risks.
• Risk Rules: Formalizes scoring through ExploitabilityCalculationRule and ExposureCalculationRule, each containing weights and interpretation logic over assumptions.
• Container Security Artefacts: Extracts real deployment traits and aligns them to guideline sections (e.g., NIST SP 800-190, CIS Docker Benchmark) for standards-compliant risk mitigation.

This modular domain modelling establishes traceability from observed artefacts (Docker Compose, Dockerfiles), through contextual scenario fit, to risk assessment and control selection (Landeck et al., 7 Jan 2026).

4. Formal Risk Assessment and Calculation

CSRO provides an explicit, algorithmic approach to risk quantification:

• Assumption Evaluation: For each relevant context assumption $i$, its satisfaction state $s_i$ is assigned as 1.0 (Satisfied), 0.5 (Unknown), or 0.0 (Dissatisfied).
• Weighted Scoring: For a set of assumptions $A$ with weights $w_i$:

$$S = \sum_{i \in A} s_i w_i, \qquad W = \sum_{i \in A} w_i$$

Thresholds $\theta_1 = W/3$, $\theta_2 = 2W/3$ partition the score domain: - Low if $S \geq \theta_2$ - Medium if $\theta_1 \leq S < \theta_2$ - High if $S < \theta_1$

• Likelihood and Risk Level Assignment: Exploitability and exposure ratings are mapped via a 3×3 matrix to a LikelihoodRating. Impact is incorporated through a 5×5 risk matrix consistent with ISO 31000.
• SPARQL-based Inference: All risk inferences (ratings, levels, treatments) are computed as SPARQL CONSTRUCT queries over the OWL 2/RDF graph, enforcing determinism and auditability. No SWRL or SPIN rules are used in this architecture.

This methodology enforces reproducibility and traceability of risk decisions, with structured factsheets linking back to assumptions and their mapped guidelines (Landeck et al., 7 Jan 2026).

5. Automated Risk Identification Workflow

The automated CSRO workflow is as follows:

1. Artefact Parsing: Container deployment artefacts (docker-compose.yml, Hadolint-analyzed Dockerfiles) are parsed to extract observed ContainerDeploymentTraits.
2. Context Scenario Selection: Observed traits are evaluated against predefined ContextScenario definitions; the scenario with maximal assumption satisfaction is selected.
3. Attack Technique Instantiation: All ContainerAttackTechniques for which required traits are present are instantiated as AttackAction objects in context.
4. Risk Calculation: For each AttackAction, retrieve relevant calculation rules, compute exploitability and exposure, assign ratings, map likelihood and risk level, and enumerate applicable risk treatments.
5. Output Generation: Produce a machine-readable factsheet (JSON/OWL) detailing risks, ratings, and traceable remediation steps.

Pseudocode Overview

\begin{algorithm}[htb] \caption{Automated Risk Identification} \Input{CSRO KG, Container Artefacts} \Output{Risk Factsheet} \ForEach{scenario ∈ ContextScenario}{ score_s ← matchScore(scenario, observedTraits) } selectedScenario ← argmax_s(score_s) observedAssumptions ← evalAssumptions(selectedScenario, observedTraits) ForEach{technique ∈ ContainerAttackTechnique}{ if technique.requiredTraits ⊆ observedTraits then action ← new AttackAction(technique, selectedScenario) S_expl ← ∑ sᵢ·wᵢ (ExploitabilityRule) explRating ← mapToRating(S_expl) S_expo ← ∑ sᵢ·wᵢ (ExposureRule) expoRating ← mapToRating(S_expo) L ← lookupLikelihood(explRating, expoRating) I ← technique.impactRating R ← lookupRiskLevel(L, I) treatments ← fetchTreatments(R) appendFacts(action, explRating, expoRating, L, R, treatments) } \end{algorithm}

This algorithm operationalizes the mapping from technical artefacts to security posture, bridging the gap between static policy checks and dynamic, context-aware risk assessment (Landeck et al., 7 Jan 2026).

6. Case Study Evaluation and Effectiveness

Application of CSRO to an industrial OT environment (>80 unique container configurations) demonstrated the ontology’s expressiveness and utility:

• Risks Identified: Shellcode injection via ptrace, tainted filesystem mounts, privilege escalation via container flags, among others.
• Risk Scores Achieved: Scenarios with medium-high exploitability/exposure and disastrous impact were rated ‘Major’. Low-low scenarios were rated ‘Minor’.
• Comprehensiveness: All existing policy checks were reproduced as AttackActions. Notably, 15 risks arising from combined container traits (not previously covered by blacklists) were newly identified.
• Stakeholder Validation: 90% agreement on correctness among participants; assessment time reduced by 60%.

This suggests CSRO supports not only high-coverage automated policy enforcement, but also novel risk discovery through trait interaction analysis (Landeck et al., 7 Jan 2026).

7. Extensions and Future Directions

The modular design of CSRO enables extensibility beyond container-level controls:

• Host-Level and OT Control Modelling: Introduction of HostSystemAssumption, hasHostConfigTrait, and expansion of calculation rules to NT/host-level artefacts (e.g., kernel hardening).
• Organizational Risk Factors: New classes for organizational controls, policy documents, and training programs, permitting multi-layered risk modelling and treatment (i.e., risk mitigation beyond technical countermeasures).
• Rule Generalization and ML Integration: Clustering of ATT&CK techniques by tactics to allow shared weighting templates, and potential incorporation of ML-based calibration for dynamic rule generation.
• Generative AI Harnessing: Use of LLMs for summarizing factsheets, generating remediation code, and automating risk questionnaire workflows, with outputs strictly bounded by the CSRO ontology terms for determinism.

A plausible implication is that such extensions would enable CSRO to serve as a unified risk reasoning framework spanning technical, architectural, and organizational domains, further bridging semantic gaps in security operations (Landeck et al., 7 Jan 2026).

---

For foundational alignment with threat modeling frameworks (e.g., STRIDE) and container ecosystem threat taxonomies, see (Wong et al., 2021), which presents a complementary but less granular OWL specification mapping vulnerabilities, threat instances, and mitigation strategies to container system components, facilitating automated risk queries and integration with CSRO-like approaches.