Security

Defense-in-depth security model: threat model, supply chain, authentication, authorization, data protection, and audit logging

OMEN applies a defense-in-depth security model across all layers — from supply chain to runtime to data access to deployment. Security is not an add-on; it is a first-class design constraint.

Threat Model

Threat Category	Examples	Primary Controls
Supply chain compromise	Malicious dependency, tampered artifact	SBOM, Sigstore/Cosign signing, dependency audit
Unauthorized access	Unauthenticated API call, privilege escalation	OAuth2/OIDC, OPA policy, least-privilege service accounts
Data poisoning	Malformed CoT message, forged track	Schema validation, provenance tagging, CAL validation
Adversarial AI input	Prompt injection, model manipulation	Input sanitization, HITL gates, output provenance
Network interception	Man-in-the-middle on data feeds	TLS 1.3 everywhere, optional mTLS for service-to-service
Insider threat	Unauthorized plugin, config drift	Plugin signing, configuration governance, audit trail
DDIL exploitation	Attack during connectivity gap	Offline manifest verification, signed mission packages

Supply Chain Security

Software Bill of Materials (SBOM)

CycloneDX or SPDX SBOM generated at every build via ops/sbom/ tooling
SBOM published alongside release artifacts
Downstream consumers can audit all transitive dependencies
Tooling: syft, cdxgen, or equivalent open-source tools

Artifact Signing

Build → [SBOM generation] → [Image build] → [Cosign sign]
                                                    │
                                                    ▼
                                         Signed manifest in OCI registry
                                         Sigstore transparency log entry

All release artifacts — container images, plugin packages, mission kit schemas — are signed with Cosign and recorded in the Sigstore transparency log.

Dependency Auditing

pip-audit / npm audit / cargo audit run in every CI pipeline (ops/ci/ci.yaml)
High and critical vulnerabilities block the build
Known false-positive exceptions require documented justification

Authentication & Authorization

Identity

Actor Type	Mechanism
Human users	OAuth2/OIDC via Keycloak (or equivalent)
Service workloads	SPIFFE/SPIRE SVID where available; service accounts elsewhere
Devices	Certificate-based device identity

Authorization

Open Policy Agent (OPA) enforces authorization at every API boundary:

Policy bundles stored in engine/policy/
Policies evaluated for: data access, plugin capabilities, AI action approval, configuration changes
Policy audit log: every policy decision is recorded with input, output, and timestamp

Least Privilege

Each service runs with minimum OS and network permissions
Plugin capability declarations are enforced at load time
Data access scoped to declared mission roles
No wildcard permissions; no ambient authority

Data Security

Encryption

Data State	Control
In transit	TLS 1.3 minimum; mTLS for service-to-service where available
At rest (mission packages)	AES-256-GCM encrypted archives
At rest (local cache)	SQLite encrypted with SQLCipher where policy requires
Credentials and secrets	OpenBao / Vault-compatible; never in source code or config files

Data Classification

All canonical entities carry a classification field (default: UNCLASSIFIED)
Adapters may tag entities with higher classification levels
The CAL enforces redaction rules based on consumer trust level
Mission packages are labeled with their highest-classification content

Input Validation

Every adapter validates raw input against its declared source schema before processing
Schema violations are rejected and logged (not silently dropped)
The CAL normalization pipeline applies secondary validation on canonical entities
AI/agentic services receive only validated, provenance-tagged entities

Audit Logging

Requirements

All security-relevant events produce an immutable audit log entry
Audit log entries are signed at write time
Audit log cannot be deleted or modified by runtime processes
Log entries include: timestamp, actor identity, action, outcome, context hash

Auditable Events

Event Type	Examples
Authentication	Login, token refresh, logout, auth failure
Authorization	Policy allow, policy deny, capability check
Data access	Entity query, mission package load, data export
Plugin lifecycle	Plugin loaded, plugin rejected, plugin disabled
AI actions	Recommendation generated, HITL approval, HITL rejection
Configuration	Config change, profile switch, rollback
Deployment	Artifact deployed, version pinned, rollback executed

Security Controls by Layer

Layer A — Presentation (`map-app/`)

Content Security Policy (CSP) headers for web-based deployment
XSS prevention: strict output encoding, no dangerouslySetInnerHTML
No direct external network access from the map application

Layer B — Mission Engine (`engine/`)

Plugin manifest signature verified at load
Plugin sandbox prevents direct filesystem and network access
Event bus messages validated against typed schemas before routing

Layer C — CAL (`cal/`, `adapters/`)

Source authentication where protocol supports it (e.g., CoT signing)
Adapter isolation: each adapter runs in its own process/container
Provenance chain preserved through all normalization steps

Layer D — Evaluation (`evaluation/`)

Test harnesses run in isolated environments
Red-team scenarios use synthetic data only (no real operational data)
Test results stored with integrity checksums

Layer E — Infrastructure (`ops/`)

Minimal base images (distroless or Alpine)
No root processes in containers (USER omen with UID 1001)
Network policies restrict pod-to-pod communication
Secrets injected at runtime, never baked into images

Secure Development Lifecycle

Phase	Controls
Code	Linting (`ruff`), static analysis (Semgrep, Bandit, ESLint security rules)
Review	Mandatory code review; security-focused reviewer for sensitive changes
Build	Dependency audit, SBOM generation, artifact signing
Test	SAST, DAST (basic), secret scanning, license compliance check
Deploy	Signature verification, policy validation, SBOM attestation
Monitor	Anomaly detection, audit log review, vulnerability feed subscription

AI Governance

OMEN enforces strict governance over AI/agentic capabilities:

Approved AI Roles

Route risk scoring — numerical risk assessment for route segments
Anomaly detection — flagging unusual patterns in sensor data or tracks
Mission summarization — natural language summaries of mission state

Prohibited AI Behaviors

Autonomous weapons engagement
Unreviewed route changes
Classification-level modifications
Any action without human-on-the-loop approval for critical consequences

Technical Requirements

Model versioning with reproducible inference
Output provenance (model ID, version, input hash, timestamp)
HITL gates for high/critical consequence actions
Rollback capability for any AI-influenced decision

Responsible Disclosure

For security vulnerabilities in OMEN, follow the process in the Contributing Guide. Do not file public GitHub issues for security vulnerabilities.