Architecture Overview

opensecstack is structured as three concentric layers: the 11 security platforms that do the work, the opensecstack/sdk that connects them through typed contracts, and two cross-cutting infrastructure layers — sinauth for identity and CITADEL for cryptographic governance. Every privileged action across the stack passes through CITADEL; every user and operator authenticates through sinauth.

Overview

The platforms cover the full security lifecycle: API security testing, NIS2 compliance, incident response, threat intelligence, DDoS mitigation, security training, attack simulation, CSIRT operations, AI-attack defence, and a developer knowledge hub. They communicate exclusively through the SDK — never through ad-hoc HTTP calls or shared database tables.

All platforms share a single PostgreSQL 16 persistence model, a single sinauth identity provider (single sign-on), and a single CITADEL governance engine (append-only WORM audit chain). There is no vendor lock-in and no required SaaS dependency.

Three layers

Platform layer — the 11 security platforms

Each platform has a defined scope and emits typed SDK events when significant things happen (scan completed, incident opened, compliance control updated, and so on). A full list with stacks and licences is on the Platforms Overview page.

SDK contract layer

The opensecstack/sdk provides typed clients in Go, Python, TypeScript, and Rust. All inter-platform communication uses the typed event schemas defined in the SDK. This means a consumer of a ScanResult never needs to know which version of APIGuard produced it — the contract absorbs the change. See SDK & Contracts for the full event schema table and usage examples.

Cross-cutting layers

Beneath the platforms and SDK sit the two layers every platform depends on:

• sinauth — the identity layer. An OAuth 2.0 / OpenID Connect authorization server: RS256-signed ID and access tokens, JWKS endpoint at https://auth.sin.to/.well-known/jwks.json, authorization-code + PKCE (S256) flow, TOTP MFA, and social login (Google, GitHub). Every platform validates sinauth-issued tokens against the JWKS endpoint instead of maintaining its own user credentials. See Identity (sinauth).
• CITADEL — the governance layer. Every privileged action is evaluated by the MARSHAL 5-gate engine (Authority → Scope → Determinism → Evidence → Schema) and the outcome — EXECUTE, REFUSE, or HARD STOP — is written into an append-only WORM audit chain with TripleHash integrity (SHA-256 + SHA-512 + BLAKE3) and Ed25519-signed chain anchors every 100 entries. See Governance (CITADEL).

Language per layer

opensecstack uses the right language for each concern rather than a single runtime. This is formalised in ADR-001 (Rust for parsing) and ADR-002 (Go for HTTP/orchestration).

Data persistence

Every platform uses PostgreSQL 16+ as its primary store. CITADEL uses append-only WORM tables enforced at the database level — rows can be inserted but never updated or deleted, which provides the tamper-resistance the audit chain requires. Flexible event payloads are stored as JSONB columns, and row-level security isolates multi-tenant data where applicable.

Data flow example

A typical integration — from an API security scan to a NIS2 compliance evidence record — looks like this:

1. A developer pushes an OpenAPI spec to the CI pipeline.
2. APIGuard scans it and produces a ScanResult with findings and CVSS scores.
3. APIGuard emits a scan_completed event to the CITADEL WORM log.
4. APIGuard exports a NIS2 evidence bundle.
5. NIS2 Compass receives the bundle and attaches it to the Art. 21(2)(e) control.
6. NIS2 Compass emits a control_updated event to the CITADEL WORM log.
7. An auditor verifies the unbroken chain in CITADEL.

Parallel flows include: APIGuard CRITICAL findings auto-creating incidents inIRFlow; ThreatFlow IOC bundles triggering automatic IP blocks in OpenScrub; andCyberPath training completions providing NIS2 Art. 21(2)(g) evidence records. The full data-flow map is in ECOSYSTEM.md in the repository.

Time Dimension Segmentation

All platforms classify operations by latency tier (Time Dimension Segmentation, ADR-009) to ensure the runtime profile matches the operation's urgency: