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 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 | MITM on data feeds | TLS 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 |
- CycloneDX or SPDX SBOM generated at every build
- SBOM published alongside release artifacts
- Downstream consumers can audit all transitive dependencies
- SBOM tooling:
syft,cdxgen, or equivalent open-source tool
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.
pip-audit/npm audit/cargo auditrun in every CI pipeline- High and critical vulnerabilities block the build
- Known-false-positive exceptions require documented justification
- Human users: OAuth2/OIDC via Keycloak (or equivalent)
- Service workloads: SPIFFE/SPIRE SVID where available; service accounts elsewhere
- Devices: Certificate-based device identity
- 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, config changes
- Policy audit log: every policy decision is recorded with input, output, and timestamp
- Each service runs with the minimum OS and network permissions required
- Plugin capability declarations are enforced at load time
- Data access scoped to declared mission roles
- No wildcard permissions; no ambient authority
| 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 |
- All canonical entities carry a
classificationfield (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
- 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
- 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
| 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 |
- 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
- Plugin manifest signature verified at load
- Plugin sandbox prevents direct filesystem and network access
- Event bus messages validated against typed schemas before routing
- 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
- Test harnesses run in isolated environments
- Red-team scenarios use synthetic data only (no real operational data)
- Test results stored with integrity checksums
- Minimal base images (distroless or Alpine)
- No root processes in containers
- Network policies restrict pod-to-pod communication to declared dependencies
- Secrets injected at runtime, never baked into images
| Phase | Controls |
|---|---|
| Code | Linting, 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 |
For security vulnerabilities in OMEN, follow the process in docs/contributing.md.
Do not file public GitHub issues for security vulnerabilities.