Ten przegląd zbiera 14 modułów warstwy enterprise (P0/P1/P2) w jedno miejsce. Każdy moduł
jest napisany, wczytany do procesu i posiada własną flagę środowiskową — domyślna wartość każdej flagi
to off (fail-safe: gdy flaga wyłączona, moduł zachowuje się jak nieaktywny/zwraca 404,
nie zmienia zachowania reszty systemu). To jest stan „LIVE-w-kodzie, OFF w konfiguracji" — nie
twierdzimy, że którykolwiek moduł działa dziś na produkcji dla realnego ruchu.
require() nie rzuca wyjątku) i eksponuje
funkcję statusu, którą można wywołać na żywo pod /api/ip3/v1/waves/status. Rzeczywiste
włączenie wymaga świadomej zmiany zmiennej środowiskowej przez operatora — nic tu nie włącza się samo.
Doktryna claim ≤ proof: to, czego moduł faktycznie potrzebuje z zewnątrz (prod IdP, PKI dla mTLS,
kwalifikowany QTSP, klucze API NVD/GitHub/SIEM, trwały storage Postgres/S3) i czego dziś NIE ma — jest
jawnie oznaczone jako ROADMAP, nie jako gotowa funkcja.
Fale odpowiadają priorytetowi domknięcia luk opisanych na stronie
/known-limitations: P0 — blokuje wdrożenie enterprise,
P1 — wymagane dla banku/partnera, P2 — rozszerza zakres (CTI, red-team AI, observability).
Każdy moduł ma osobny plik w routes/, własną flagę IP3_* (domyślnie off)
i jest raportowany przez wspólny, tylko-do-odczytu router routes/ip3-waves-mount.js — ten router
niczego nie włącza, wyłącznie odpytuje stan załadowania i flagi każdego modułu.
Zasada: NIE mieszać LIVE z DEMO. Żaden
z 14 modułów nie jest dziś LIVE_PROD —
wszystkie mają kod + test, ale działają za flagą domyślnie off na danych demo/in-memory, więc status
to LIVE_CONTROLLED lub
LIVE_DEMO, nigdy samo „LIVE".
Dwa moduły domykają największe luki z rejestru ograniczeń: kto może mieć konto i czy zmiany w kodzie przechodzą bramkę bezpieczeństwa przed scaleniem.
| Moduł | Po co | Status flagi | Dowód |
|---|---|---|---|
| access-model IP3-P0-04 LIVE_CONTROLLED |
Model dostępu invite-only (RBAC + wygasanie zaproszenia + audit) zamiast kont demo lub
samorejestracji. Konto powstaje wyłącznie przez invite() → accept(token). |
Flaga IP3_ACCESS_MODEL, domyślnie off. To warstwa „życia konta"
(rola, ważność, aktywność) — nie pełny system logowania (hasło/OIDC/OTP, patrz P0 „Auth" w
known-limitations). |
routes/ip3-access-model.js · /waves/access-model/status |
| ci-gate IP3-P0-05 LIVE_CONTROLLED |
Bramka bezpieczeństwa w CI: SAST (semgrep lub reguły zastępcze), skan zależności
(npm audit critical/high), skan sekretów, regresja auth/RBAC — przed scaleniem zmian. |
Skrypt scripts/ip3-ci-gate.sh, nie flaga runtime — uruchamiany jako krok CI, nie
moduł serwera. Wynik to sygnał zagregowany (media_signal), nie certyfikacja bezpieczeństwa kodu. |
scripts/ip3-ci-gate.sh · /waves/ci-gate/status |
Sześć modułów odpowiada bezpośrednio pozycjom P1 z rejestru ograniczeń: tenancy, formalny dowód czasu, kanonikalizacja dowodu, świeżość CVE, integracja SIEM i cykl życia ticketu.
| Moduł | Po co | Status flagi | Dowód |
|---|---|---|---|
| rls-enforce IP3-P1-01 LIVE_CONTROLLED |
Trzecia, samodzielna warstwa dowodowa egzekwowania multi-tenant: asercje
assertNoCrossTenant, audit log per-tenant, wrapper withTenant — działa
zarówno nad realnym PostgreSQL, jak i in-memory (bez DB brak tenant_id = DENY). |
Flaga IP3_RLS, domyślnie off. Nie edytuje istniejących warstw 1 (app-scope)
i 2 (PostgreSQL RLS) — dokłada tylko asercję i dziennik. |
routes/ip3-rls-enforce.js · /waves/rls-enforce/status |
| tsa IP3-P1-02 LIVE_DEMO |
Znacznik czasu RFC 3161 dla evidence-package/Board Pack (buduje TSQ, parsuje TSR), z fallbackiem
lokalnego zegara wyraźnie oznaczonym jako UNVERIFIED_LOCAL. |
Flaga IP3_TSA (off | on | live), domyślnie
off. Tryb live łączy się z publicznym serwerem TSA (np. freetsa.org) —
kwalifikowany QTSP komercyjny to osobny ROADMAP. |
routes/ip3-tsa.js · /waves/tsa/status |
| canonical IP3-P1-03 LIVE_DEMO |
Kanonikalizacja JSON dowodu (JCS / RFC 8785) dla stabilnego, deterministycznego SHA-256 niezależnego od kolejności kluczy i formatowania. | Flaga IP3_CANONICAL_V2, domyślnie off. To nie podpis kryptograficzny
ani cały łańcuch tamper-evident (ten jest osobno, w ip3-audit-chain.js) — wyłącznie
kanonikalizacja + hash pojedynczego obiektu. |
routes/ip3-canonical.js · /waves/canonical/status |
| cve-enrich IP3-P1-04 LIVE_DEMO |
Wzbogacanie znaleziska po CVE-ID o CVSS + EPSS + KEV z myślą o przyszłej świeżości danych (dziś offline z seedu, patrz known-limitations). | Flaga IP3_CVE_ENRICH (off | on), domyślnie off
(zero połączeń sieciowych). Dane to sygnał (media_signal) o istnieniu/prawdopodobieństwie eksploatacji,
nie dowód naprawy hosta. |
routes/ip3-cve-enrich.js · /waves/cve-enrich/status |
| siem-guard IP3-P1-05 LIVE_CONTROLLED |
Warstwa transportowa nad parserem webhooka SIEM: weryfikacja podpisu HMAC-SHA256 w czasie stałym
+ deduplikacja po alert_id/fingerprint. |
Flaga IP3_SIEM_GUARD, domyślnie off. To nie mTLS ani WAF — nie chroni
przed przechwyceniem sekretu ani atakiem na warstwę transportową (TLS to osobna sprawa). |
routes/ip3-siem-guard.js · /waves/siem-guard/status |
| ticket-sync IP3-P1-06 LIVE_CONTROLLED |
Rejestr stanu ticketu nad bezstanowymi builderami Jira/GitHub: workflow open→in_progress→resolved→closed, przypisanie właściciela, timer SLA wg dotkliwości, audit trail. | Flaga IP3_TICKET_SYNC, domyślnie off. Stan trzymany in-memory,
per-proces — trwały storage (Postgres) to ROADMAP. |
routes/ip3-ticket-sync.js · /waves/ticket-sync/status |
Sześć modułów rozszerza pokrycie: import CTI, dodatkowe formaty skanowania kodu, raport zarządu, wieloetapowa zgoda zamknięcia, rejestr testów red-team AI i metryki operacyjne.
| Moduł | Po co | Status flagi | Dowód |
|---|---|---|---|
| stix IP3-P2-01 LIVE_DEMO |
Parser importu CTI/threat-intel STIX 2.1 (bundle) + TAXII 2.1 (collection, fixture offline) → znormalizowane findingi. Korelacja indicator↔attack-pattern jako wzbogacenie kontekstu TTP. | Flaga IP3_STIX, domyślnie off. Import to media_signal — sygnał
narzędzia/feedu CTI, nie dowód eksploatacji ani naprawy. |
routes/ip3-stix.js · /waves/stix/status |
| scm-ingest IP3-P2-02 LIVE_DEMO |
Parser SARIF 2.1.0 (GitHub/GitLab code-scanning) + podstawowy import CycloneDX SBOM →
znormalizowane findingi/assety. Endpointy docelowe (wiring przez integratora): /imports/sarif,
/imports/sbom-cyclonedx. |
Flaga IP3_SCM_INGEST (off | shadow | on),
domyślnie off. Wynik skanera statycznego wymaga triage człowieka — możliwe fałszywe alarmy. |
routes/ip3-scm-ingest.js · /waves/scm-ingest/status |
| board-report IP3-P2-03 LIVE_DEMO |
Generator raportu zarząd/regulator (board pack) na bazie znormalizowanych incydentów/findingów: residual risk, control effectiveness, trend, RAG. | Flaga IP3_BOARD_REPORT (off | on), domyślnie off.
Heurystyczne podsumowanie dostarczonych danych, nie certyfikowany GRC-score ani audyt zgodności —
jakość wyniku zależy wyłącznie od jakości wejścia. |
routes/ip3-board-report.js · /waves/board-report/status |
| approval IP3-P2-04 LIVE_DEMO |
Wieloetapowy workflow zgody na zamknięcie incydentu (analyst → owner → CISO/compliance), maszyna stanów wymagająca kompletu akceptacji + dowodu retestu przed zamknięciem. | Flaga IP3_APPROVAL, domyślnie off. canClose() odmawia,
dopóki brakuje wymaganej roli lub retest_evidence_ref — wymuszone w kodzie, nie tylko
w opisie procesu. |
routes/ip3-approval.js · /waves/approval/status |
| redteam IP3-P2-05 LIVE_DEMO |
Rejestr test-case'ów AI red-team (prompt-injection, agent-hijack, tool-misuse, hallucination-impact) — WYŁĄCZNIE dokumentacja przeprowadzonego/zaplanowanego testu obronnego, po RoE, na danych syntetycznych. | Flaga IP3_REDTEAM, domyślnie off. Rejestracja to media_signal (opis testu),
nie dowód że system jest bezpieczny. Wynik bez dowodu (evidence ref) jest fail-safe traktowany
jako nieuznany. Zero payloadów/instrukcji ataku w module — opisujemy co testowane i jaki dowód sukcesu. |
routes/ip3-redteam.js · /waves/redteam/status |
| observability IP3-P2-06 LIVE_CONTROLLED |
Endpoint metryk w formacie Prometheus text exposition (konwencja OTel/Prometheus), np.
ip3_http_request_duration_seconds. |
Flaga IP3_OBSERVABILITY, domyślnie off — /metrics zwraca 404
gdy wyłączone (zachowanie fail-safe). Metryka to sygnał operacyjny dla człowieka/alertingu, nie dowód
że incydent został naprawiony. |
routes/ip3-observability.js · /waves/observability/status |
Zbiorczy status wszystkich 14 modułów jednym zapytaniem, bez logowania:
GET /api/ip3/v1/waves/status
→ { module:"ip3-waves", total:14, loaded:<N>, enabled:<N>, waves:{ P0:[...], P1:[...], P2:[...] } }
GET /api/ip3/v1/waves/<id>/status (np. /waves/tsa/status)
→ { id:"tsa", wave:"P1", task:"IP3-P1-02", loaded:true, flag:"off", enabled:false, detail:{...} }
loaded = moduł wczytał się bez błędu (kod istnieje i działa). enabled =
flaga tego konkretnego modułu jest ustawiona na on/shadow — jeśli
enabled:false, moduł jest nieaktywny niezależnie od tego, co widać w tabelach powyżej.
Router statusu (routes/ip3-waves-mount.js) jest wyłącznie do odczytu — nie potrafi niczego
włączyć ani zmienić stanu żadnego modułu.
Sam kod 14 modułów nie zastępuje zasobów, których dostarczyć może wyłącznie operator lub zewnętrzna instytucja. Bez nich włączenie flagi na produkcji byłoby przedwczesne:
OIDC/Keycloak z realnym provisioningiem kont — dziś testowo na staging (patrz known-limitations, pozycja Auth).
Certyfikaty klienckie i wzajemne uwierzytelnianie TLS między klientem a API — brak dziś.
Moduł tsa potrafi rozmawiać z serwerem RFC 3161 — komercyjny, kwalifikowany dostawca
znacznika czasu to osobna umowa, nie kod.
NVD/CISA KEV online, GitHub/Jira produkcyjne, SIEM webhook realnego klienta — dziś offline/seed lub buildery bez wysyłki.
Moduły rls-enforce, ticket-sync, redteam i inne trzymają stan
in-memory, per-proces. Postgres/S3 dla trwałości między restartami — osobny sprint.
/api/ip3/v1/waves/status w danej chwili,
nie tym, co napisano w tabeli powyżej dla celów opisowych.
redteam dokumentuje wyłącznie testy defensywne,
na danych syntetycznych, po pisemnych Rules of Engagement —
zero payloadów, zero instrukcji ataku. Moduł board-report to wsparcie decyzji
(decision-support), nie audyt zgodności ani porada prawna.
Powiązane: pełny rejestr znanych ograniczeń → /known-limitations · autoprezentacja produktu → /prezentacja · rejestr maszynowy stron → /pages.json.