k0nsult.cloud / ai-truth / ipIII / orchestrator / release-notes
ipIII v0.8 — controlled pilot (droga do v1.0)
Release notes Evidence & Resilience Orchestrator. Ta strona opisuje, co jest realnie LIVE w bieżącej wersji, jakie są znane ograniczenia oraz co dzieli nas od v1.0. Doktryna claim ≤ proof: każdy element „LIVE" ma dowód (kod + test + endpoint), reszta jest oznaczona ROADMAP. Kanon liczb testów = Evidence Matrix; kanon statusów = status-matrix.
Uczciwy zakres wersji. ipIII v0.8 to
controlled pilot — działający, dowodliwy system klasy GRC/blue,
przeznaczony do kontrolowanego pilotażu z partnerem instytucjonalnym. To
nie jest certyfikowany,
„produkcyjny bankowy" produkt enterprise ani deklaracja „pełnej zgodności" czy „100% bezpieczeństwa". Narzędzie
wspiera obronę i zgodność — nie wykonuje nieautoryzowanych testów ani działań ofensywnych poza pisemnymi
Rules of Engagement.
Wersja v0.8 · controlled pilot · status ≤ dowód
Rdzeń end-to-end działa na żywej bazie: import findings → normalizacja → incydent + evidence (hash, chain-of-custody)
→ close-with-evidence → pakiety DORA/TIBER i Legal Trigger Engine. Warstwa dostarczona jako MVP/v1 z testami. To, czego
brakuje do v1.0 (deduplikacja, pełny workflow remediacji, integracje produkcyjne, release/docs pack), jest jawnie wypisane
poniżej — bez ukrywania luk.
RDZEŃ:
import→normalizacja→incydent+evidence→close-with-evidence→evidence-package→DORA/TIBER + Legal Trigger
1 · Co jest LIVE teraz (v0.8)
Elementy poniżej mają pokrycie dowodowe (kod + test + endpoint na żywej bazie). Liczby testów świadomie nie są tu powielane — kanon to Evidence Matrix.
Import findings — realne parsery LIVE v1
Burp (XML) · OWASP ZAP (JSON/XML) · Nessus/Tenable (CSV) · Qualys (CSV/XML) · generic CSV/JSON · RE (reverse-engineering / manualny)
→ normalizacja severity (P0–P3) → incydent + evidence w PostgreSQL. Import jest oznaczany jako
MEDIA_SIGNAL
(sygnał, nie dowód naprawy). Zobacz
Connectors.
Evidence-package (board pack) LIVE v1
GET /reports/evidence-package/:id → JSON (manifest + package_sha256 + ślad audytowy + chain-of-custody)
oraz realny pobieralny PDF (bezzależnościowy generator). Integralność potwierdzana hashem sha256.
Close-with-evidence LIVE v1
Reguła egzekwowana w DB: brak dowodu CONFIRMED → odmowa zamknięcia (422). PATCH-bypass zamknięty (audyt F4).
Retest → CONFIRMED → close → evidence-package odzwierciedla zmianę (inny
package_sha256). Zobacz
Response & Retest.
DORA / TIBER — engagement + report-package LIVE MVP
Engagement (scope / crown-jewels / RoE) + white-team-log + evidence-register + final-report jako realne rekordy DB
(raport końcowy wymaga rejestru dowodów — claim ≤ proof).
GET /api/ip3/v1/engagements/:id/report-package?format=json|pdf
→ raport TLPT: timeline zdarzeń + evidence-register + final-report + manifest +
package_sha256. Zobacz
DORA / TIBER.
Legal Trigger Engine LIVE MVP
GET /api/ip3/v1/incidents/:id/legal-triggers — mapuje incydent na obowiązki
DORA art.19 / NIS2 (24h/72h)
/ RODO art.33-34 / AI Act art.73 z zegarami (deadline ISO od
created_at) i draftem powiadomienia.
Doktryna
DECISION-SUPPORT (nie porada prawna; terminy orientacyjne). Zobacz
Legal Engine.
MITRE ATT&CK — mapowanie TTP LIVE v1
Biblioteka technik + GET /api/ip3/v1/incidents/:id/ttp — mapowanie incydentu na techniki ATT&CK
(offline). STIX/TAXII + MISP/OpenCTI = ROADMAP.
Enrichment offline (CVE → CVSS / EPSS / KEV) LIVE v1
Wzbogacanie findingów przy imporcie na bazie hintów offline (KEV / CVSS / EPSS). Online lookup NVD/CISA =
ROADMAP.
Verify · anonymizer · deadline-clock LIVE v1
Weryfikacja integralności artefaktów (hash), anonimizacja danych wrażliwych w eksporcie oraz zegary terminów
(deadline-clock) liczone od czasu zdarzenia dla obowiązków notyfikacyjnych.
Coverage-score LIVE v1
Wskaźnik pokrycia dowodowego (nie „bezpieczeństwa") — mierzy udział twierdzeń mających dowód vs GAP. Doktryna:
100% = pokrycie dowodowe, nie nieprzenikalność systemu.
Status-matrix · trust-center · known-limitations LIVE
Jawne rejestry:
status-matrix (kanon statusów), trust-center oraz
known-limitations (jawny rejestr ograniczeń).
Split bank / dev / research LIVE
Rozdział ścieżek odbiorcy: perspektywa instytucji finansowej (bank), warstwa deweloperska (roadmap-dev, API) oraz
research — każda z własnym zakresem i statusami.
2 · Znane ograniczenia
Pełny, jawny rejestr ograniczeń bieżącej wersji (co system świadomie nie robi lub robi w ograniczonym zakresie)
jest utrzymywany osobno, aby claim nie przekraczał proof.
→ Zobacz pełny rejestr: known-limitations.
Znajdziesz tam m.in. granice importu (brak deduplikacji), zakres offline enrichment, brak podpisu PAdES/PQC na eksporcie,
brak realnego IdP OIDC oraz brak izolacji multi-tenant w bieżącej wersji.
3 · Droga do v1.0
Co dzieli v0.8 od v1.0. To lista zobowiązań przyrostowych — nie deklaracja, że są gotowe. Kryteria akceptacji i sprinty: roadmap-dev.
| Brakujący element | Co dowozi do v1.0 | Status |
| Deduplikacja importów |
Idempotencja i dedup findingów przy wielokrotnym imporcie (ten sam skan → brak duplikatów incydentów). |
ROADMAP |
| Pełny workflow remediacji |
Orkiestracja: przypisanie właściciela → SLA → dowód naprawy → retest regresyjny → control mapping → workflow zatwierdzeń. |
ROADMAP |
| 2–3 integracje produkcyjne |
Realne konektory: DefectDojo · Jira · SIEM (dwukierunkowa wymiana ticketów/detekcji). |
ROADMAP |
| Release / docs pack |
Wersjonowany pakiet wydania: dokumentacja operatora/integratora, changelog kanoniczny, instrukcje wdrożenia. |
ROADMAP |
4 · Uczciwy werdykt
~v0.7–0.8 · pilot-ready — NIE v1.0 enterprise.
ipIII jest realnym, dowodliwym systemem gotowym do kontrolowanego pilotażu z partnerem instytucjonalnym:
rdzeń end-to-end działa na żywej bazie, z testami i statusami ≤ dowód. Jednocześnie nie jest to certyfikowany,
„produkcyjny bankowy" produkt enterprise: brakuje deduplikacji importów, pełnego workflow remediacji, integracji
produkcyjnych (DefectDojo/Jira/SIEM) oraz release/docs pack. Nie deklarujemy „pełnej zgodności", „100% bezpieczeństwa"
ani „nieprzenikalności" — deklarujemy pokrycie dowodowe tego, co realnie działa.
WERDYKT:
rdzeń LIVE (dowód)→pilot-ready v0.7–0.8→4 elementy do v1.0→enterprise = po v1.0
Zasada nadrzędna. Release notes nie są deklaracją gotowości do produkcji bankowej. Są jawnym stanem: co
dostarczono z dowodem, co jest ograniczone i co pozostaje do zbudowania. Kanon liczb testów =
Evidence Matrix. Kanon statusów =
status-matrix. Bez kodu + testu + endpointu = nie LIVE.
Granica etyczna i prawna. Orchestrator jest narzędziem obrony i zgodności (GRC/blue). Nie wykonuje
nieautoryzowanych skanów, exploitacji ani hack-back. Działania o charakterze testu bezpieczeństwa (BAS, red-team)
wyłącznie w granicach pisemnych
Rules of Engagement. Ta strona nie zawiera
payloadów ani instrukcji ofensywnych. „Legal Trigger Engine" to wsparcie decyzji (DECISION-SUPPORT), nie porada prawna.
Linki: aktualizacje ·
status-matrix ·
known-limitations ·
roadmap-dev.