Some checks failed
security-scan / secret-scan (push) Failing after 3s
Extends the existing ATLAS/OWASP/EU-AI-Act compliance module with three new control-framework mappers (NIS2 Art. 21(2), ISO/IEC 27001 Annex A, SOC 2 Trust Services Criteria), each honestly marking what ShieldX covers vs. what remains an organizational/legal gap. ComplianceRobot aggregates all four frameworks into a single prioritized, owned action plan. EUAIActAgent adds active workflows on top of the existing static reporter: Art. 6/Annex III risk pre-screening, Annex IV technical documentation scaffolding, Art. 72 post-market monitoring plan, and the corrected 2027/2028 enforcement timeline. Adds docs/flexoptix-os/ — a broader consolidation concept covering the current state (Magatama/ShieldX, EO Global Pulse), target architecture for BEO (LibreChat/Presidio-based), a Transceiver Intelligence Platform architecture recommendation, and RunWork OS externalization strategy, grounded in adversarially-verified research citations.
68 lines
4.2 KiB
Markdown
68 lines
4.2 KiB
Markdown
# Ist-Zustand
|
||
|
||
## Magatama = ShieldX (vollständig bekannt)
|
||
|
||
ShieldX (`@shieldx/core`, v0.5.0, Apache 2.0) ist die Sicherheitsbarriere, die im Gespräch
|
||
"Magatama" genannt wurde. Das ist keine Vermutung — dieses Repo ist die Arbeitsgrundlage
|
||
dieser Session.
|
||
|
||
**Was heute produktiv funktioniert:**
|
||
|
||
- 10-Layer-Pipeline (L0–L9): Preprocessing, Rule Engine (547+ Regeln, 50+ Sprachen),
|
||
Sentinel-Klassifikator, Embedding-Scan (pgvector), Entropie-/Attention-Analyse,
|
||
Verhaltens-Monitoring, MCP-Guard, Sanitisierung, Output-Validierung.
|
||
- 7-Phasen Kill-Chain-Mapping (Schneier et al. 2026) mit automatischer Selbstheilung.
|
||
- Bio-immunes Self-Evolution-System: `EvolutionEngine`, `ImmuneMemory` (pgvector),
|
||
`FeverResponse`, `RedTeamEngine`, `DriftDetector`, `ActiveLearner`.
|
||
- Compliance-Modul (`src/compliance/`): MITRE-ATLAS-Mapping (90 Techniken),
|
||
OWASP-LLM-Top-10-Mapping, EU-AI-Act-Reporter (Art. 9/12/14/15).
|
||
**Neu in diesem Branch ergänzt:** NIS2-, ISO/IEC-27001- und SOC-2-Mapper sowie ein
|
||
`ComplianceRobot` und `EUAIActAgent` — siehe [03-qm-compliance-euaiact.md](./03-qm-compliance-euaiact.md).
|
||
- Benchmarks (v0.5.0): TPR 91,9 %, FPR 2,4 %, P50-Latenz 0,49 ms.
|
||
- Integrationen: Next.js, Ollama, Anthropic Claude, n8n (Community Node), sowie ein
|
||
generischer HTTP-Proxy (`proxy/server.js`, Port 11435) zum transparenten Schutz von
|
||
Ollama-Aufrufen.
|
||
|
||
**Bekannte Lücken (aus `CONCEPT-shieldx-v1.0.md`, internem Reifegrad-Assessment):**
|
||
Einige L2/L3/L5-Scanner sind noch Stubs (Semantic Contrastive Scanner, Embedding-Scanner,
|
||
YARA, Canary-Wiring), Pattern-Persistenz ist an eine PostgreSQL-Anbindung gebunden, und die
|
||
Testabdeckung lag zum Zeitpunkt des Konzeptdokuments bei ca. 32 % der Module. Das ist
|
||
wichtig für die Priorisierung: **Magatama sollte gehärtet werden, bevor es zur tragenden
|
||
Sicherheitsschicht von ganz Flexoptix OS gemacht wird.**
|
||
|
||
## EO Global Pulse — der konkrete Integrationsbeweis
|
||
|
||
`integrations/eo-global-pulse-middleware.ts` ist eine fertige Drop-in-Middleware für ein
|
||
Next.js-Projekt namens **EO Global Pulse**. Sie:
|
||
|
||
- schaltet ShieldX als Proxy vor Ollama (`OLLAMA_URL` → `:11435` statt `:11434`),
|
||
- scannt jede Nutzereingabe vor der Verarbeitung (`scanWithShieldX()`),
|
||
- blockt bei `action: 'block' | 'incident'` mit HTTP 403,
|
||
- **fail-open bei Ausfall** (Netzwerkfehler oder Proxy down → Anfrage wird durchgelassen,
|
||
nicht blockiert) — das ist eine bewusste Verfügbarkeits-Entscheidung, aber im
|
||
Compliance-Kontext (NIS2 Art. 21.2.b Incident Handling, EU-AI-Act Art. 12 Logging)
|
||
ein Punkt, den man explizit dokumentieren sollte: *"Fail-open bedeutet, ein
|
||
ShieldX-Ausfall ist selbst ein meldepflichtiges Ereignis, kein stiller Fallback."*
|
||
|
||
**Arbeitsannahme:** "EO Global Pulse" ist entweder identisch mit dem, was du "BEO" nennst,
|
||
oder sein unmittelbarer Vorläufer/Zwilling. Falls das nicht stimmt, ändert sich Kapitel 02
|
||
grundlegend — das gehört auf die Klärungsliste in
|
||
[07-roadmap-offene-fragen.md](./07-roadmap-offene-fragen.md).
|
||
|
||
## Alles andere: Fossy, Lupo/Lobu, FoCI, BIO, RunWork OS
|
||
|
||
Für diese Systeme liegen aus dieser Session heraus **keine Repo-Inhalte** vor. Was im
|
||
Gespräch beschrieben wurde:
|
||
|
||
| System | Beschreibung laut Gespräch | Vermutete Rolle |
|
||
|---|---|---|
|
||
| **Fossy / FO-OS** | Wird im gleichen Atemzug wie Flexoptix OS genannt | Möglicherweise ein Vorläufername für Flexoptix OS selbst, oder ein separates Analyse-Tool |
|
||
| **FoCI** | "Auswertung/Empfehlungen für Geschäftsabteilungen, Analyse von Geschäftsabläufen (ITSM, Datacenter)" | Business-Intelligence-/Empfehlungs-Engine für Fachabteilungen |
|
||
| **Lupo / Lobu** | "Ressourcen" — im Kontext von Netzwerk-/Transceiver-Infrastruktur | Netzwerk-Ressourcenverwaltung (DCIM/IPAM-artig) |
|
||
| **EO Pulse** | Separat von BEO genannt, aber Namensüberschneidung mit "EO Global Pulse" | Siehe Arbeitsannahme oben |
|
||
| **BIO** | "Transceiver Intelligence Plattform" | Diagnose/Monitoring für optische Transceiver — siehe Kapitel 04 |
|
||
| **RunWork OS** | Geplantes Produkt: dieselbe Erfahrung als schnelle Geschäftsprozess-Analyse für externe Kunden anbieten | Externalisierungsprodukt — siehe Kapitel 05 |
|
||
|
||
Diese Zeilen sind **Zitate/Paraphrasen aus dem Gespräch, keine verifizierten Fakten.** Sie
|
||
dienen als Platzhalter, bis die Repo-Zuordnung geklärt ist.
|