Czym się różnimy

Narzędzia, które znasz, dają zwykle jedną warstwę: skaner zwraca listę podatności, platforma BAS odgrywa gotowy scenariusz, pentest kończy się raportem, a usługa red-team zależy od dostępności zespołu. CYRBER łączy sześć rzeczy w jedną rządzoną pętlę i różnica bierze się z ich połączenia.

Rozumuje, zamiast odgrywać skrypt. MENS, agentowy narząd organizmu, prowadzi misję tak, że na każdej iteracji przechodzi OBSERVE, THINK, ACT, LEARN i sam wybiera następny ruch. Operator nie pisze playbooka pod konkretny cel, lecz obserwuje rozumowanie i pieczętuje wnioski. Skaner odpala stałą listę wtyczek, a platforma BAS odgrywa z góry ułożony scenariusz. MAMY

Celuje w realny dostęp. Misja dąży do udowodnienia, że łańcuch da się przejść, a nie do wydrukowania rejestru podatności, przy czym domyślnie zatrzymuje się na udowodnionym dostępie, a ekstrakcję czy eksfiltrację włączasz osobnym, bramkowanym trybem. MAMY

Domyka detekcję na SIEM-ie klienta. Wynik ataku trafia na SIEM klienta, obsługiwany konektorem (Wazuh, Splunk, QRadar albo Microsoft Sentinel), więc atak i obrona uczą się na tym samym zdarzeniu, a luka w detekcji się zamyka. To purple, czyli red i blue w jednej pętli, a nie sam red team, który zostawia raport. Konektor SIEM i stały pomiar wykrywalności MAMY, a gotowy stack Wazuh dla on-prem bez własnego SOC DOŁOŻYMY

Zostawia dowód. Każde znalezisko jest zahashowane i zamknięte w drzewie Merkle, a korzeń drzewa każdej misji rejestrujemy w kalendarzu OpenTimestamps (kotwica w Bitcoinie dochodzi po potwierdzeniu w bloku), więc werdykt sprawdzisz sam, bez dostępu do naszej bazy. MAMY

Należy do klienta. Platforma stoi u klienta on-prem, dane oraz przebieg misji zostają na jego infrastrukturze, a my nie trzymamy żadnej kopii. Rozumowanie może działać na lokalnym modelu w trybie air-gap. On-prem i air-gap dla organizacji MAMY, wymuszenie air-gapu dla całej instancji DOŁOŻYMY.

Żyje, zamiast stać. Organizm sam leczy własny stan działania, uczy się z każdej zamkniętej misji i pilnuje, żeby jego własny opis pozostawał prawdziwy, więc sam utrzymuje się w dobrym stanie. MAMY

CYRBER wiąże te sześć rzeczy w jedną rządzoną pętlę: od polowania w granicach prawa, przez domknięcie detekcji, aż po dowód pod regulację, i to w całości pod kontrolą klienta.

Opisujemy tylko to, co dziś potrafimy uzasadnić kodem, a znaczniki DOŁOŻYMY zostawiamy widoczne. To jednak nie jest system zamrożony, ponieważ przez FORUM zgłaszasz własny postulat, brak albo potrzebę, a jeśli obroni się technicznie i biznesowo, trafia do decyzji i rozważamy go w planie. Listę DOŁOŻYMY współtworzysz więc razem z nami. FORUM z panelem postulatów i decyzji MAMY

How we differ

The tools you know usually give one layer: a scanner returns a list of vulnerabilities, a BAS platform replays a canned scenario, a pentest ends in a report, and a red-team service depends on a team's availability. CYRBER binds six things into one governed loop, and the difference comes from combining them.

It reasons instead of replaying a script. MENS, the agentic organ of the organism, runs a mission so that on every iteration it walks OBSERVE, THINK, ACT, LEARN and picks its own next move. The operator writes no per-target playbook and instead watches the reasoning and seals the conclusions. A scanner fires a fixed list of plugins; a BAS platform replays a scenario laid out in advance. SHIPPED

It aims at real access. A mission works to prove that the chain can be walked, not to print a register of vulnerabilities, and by default it stops at proven access; you turn extraction or exfiltration on through a separate, gated mode. SHIPPED

It closes detection on the client's SIEM. The result of an attack lands on the client's SIEM via a connector (Wazuh, Splunk, QRadar or Microsoft Sentinel), so attack and defence learn from the same event and the detection gap closes. This is purple: red and blue in one loop, not red alone leaving a report. The SIEM connector and continuous detection measurement are SHIPPED, while a ready-made Wazuh stack for on-prem sites without their own SOC is PLANNED

It leaves a proof. Every finding is hashed, closed inside a Merkle tree whose root, for every mission, is committed to the OpenTimestamps calendar (the Bitcoin anchor follows once a block confirms it), so you check the verdict yourself, without access to our database. SHIPPED

It belongs to the client. The platform stands at the client's site on-prem, the data and the mission run stay on their infrastructure, and we keep no copy. Reasoning can run on a local model in air-gap mode. On-prem and per-organisation air-gap are SHIPPED; enforcing air-gap for the whole instance is PLANNED.

It lives instead of sitting still. The organism repairs its own running state, learns from every mission that closes, and keeps its own account of itself true, so it keeps itself in good order. SHIPPED

CYRBER binds these six things into one governed loop: from hunting within legal scope, through closing detection, to a proof fit for regulation, and all of it under the client's control.

We describe only what we can justify in code today, and we leave the PLANNED markers visible. Yet it is not a frozen system, because through FORUM you raise your own request, a gap or a need, and if it holds up technically and in business terms, it goes to a decision and we consider it for the plan. You help shape the PLANNED list with us. FORUM, with its request and decision panel, is SHIPPED

Szybki start

Od logowania aż po zapieczętowany raport prowadzą Cię poniższe kroki, które przechodzą przez jedną pełną misję od początku do końca.

1. Zaloguj się

Wejdź na app.cyrber.com jako OPERATOR lub ADMIN. Sesja to ciasteczko HTTP-only, ważne cztery godziny; po wygaśnięciu logujesz się ponownie, token nie leży w localStorage.

2. Ustaw zakres

Na stronie /lex ustaw politykę LEX dla celu: zakres CIDR, tryb autonomii (poziom LIBER pozwala systemowi działać samodzielnie w tej klasie ryzyka) i flagę requires_consent dla wyższych poziomów ryzyka, gdzie krok wymaga Twojego podpisu przed wykonaniem. Samo pokrętło autonomii, ile wolności ma organizm, kręcisz na stronie /organism.

3. Uruchom misję

Misję MENS zlecasz w oknie rozmowy z CYRBER: podajesz cel, a platforma stosuje politykę LEX ustawioną dla tego celu. Jeśli krok w planie wymaga wyższego poziomu zgody, zatwierdzasz go, zanim MENS ruszy. Po starcie MENS buduje graf ataku i sam dobiera moduły skanujące. Przycisk na stronie Misje uruchamia osobno skan OpenVAS.

4. Oglądaj na żywo

W KOKPICIE, w trybie Battle Mode, widzisz aktywną iterację: który moduł pracuje, na jakim celu, licznik znalezisk i EKG, które pulsuje kolorem zależnym od stanu misji.

5. Odbierz raport i pieczęć

Po zamknięciu misji TESTIMONIUM pieczętuje wynik: drzewo Merkle oraz podpis, a stąd eksportujesz raport misji do PDF w języku polskim lub angielskim. Taki sam raport, z nazwą organizacji, genomem i pieczęcią werdyktu zgodności, pobierzesz też dla pojedynczego skanu, na przykład OpenVAS. Raport składa się w tle: pierwszy trwa od kilkunastu sekund wzwyż, a przycisk pokazuje, ile już czekasz; kolejne pobrania tego samego raportu przychodzą od razu. Zgodność pobierasz osobno, jako JSON dla NIS2, DORA i RODO albo jako PDF dla samego NIS2. Pieczęć sprawdzisz bez naszej bazy, z pakietu audytora, jak pokazuje rozdział Weryfikacja publiczna.

Ten sam zapieczętowany dowód nie musi czekać, aż ktoś go ręcznie pobierze, ponieważ wypychasz go wprost do Twojego systemu GRC, tam gdzie audytor już pracuje: assessment-results w standardzie OSCAL, plan działań naprawczych i PDF zgodności lądują jako załączniki przy kontroli, a komentarz notuje root drzewa Merkle, który audytor przelicza samodzielnie i porównuje z pieczęcią. Dowód opuszcza pieczęć tylko do systemu, który należy do Ciebie, a sam wypływ bramkujemy krokiem MFA. MAMY

Quick start

From login to a sealed report, no detours in between. The steps below walk one mission from start to finish.

1. Log in

Go to app.cyrber.com as OPERATOR or ADMIN. The session runs on an HTTP-only cookie, good for four hours; once it expires, you log in again, and the token never touches localStorage.

2. Set the scope

On /lex, write a LEX policy for the target: a CIDR range, an autonomy tier (LIBER lets the system act on its own within that risk class), and a requires_consent flag for the higher tiers, where a step waits for your signature before it fires. The autonomy dial itself, how much latitude the organism gets, lives on /organism.

3. Launch the mission

You order a MENS mission in the CYRBER chat window: you give the target, and the platform applies the LEX policy set for that target. If a planned step needs a higher level of consent, you approve it before MENS moves. Once launched, MENS builds an attack graph and picks the scan modules itself. The button on the Missions page runs a separate OpenVAS scan.

4. Watch it live

In KOKPIT, Battle Mode shows the running iteration: which module is active, against which target, a running finding count, and a heartbeat trace that shifts colour with the mission's state.

5. Collect the report and the seal

Once the mission closes, TESTIMONIUM seals the result with a Merkle tree and a signature, and from there you export the mission report to PDF in Polish or English. You get the same report, with the organisation name, the genome and the seal over the compliance verdict, for a single scan too, an OpenVAS one for instance. The report is built in the background: the first one takes from a dozen or so seconds upwards and the button shows how long you have been waiting; later downloads of the same report arrive at once. Compliance is a separate export, as JSON for NIS2, DORA and GDPR or as PDF for NIS2 alone. You can check the seal without our database, from the auditor bundle, as the Public verification chapter shows.

That same sealed proof does not have to wait for someone to download it by hand, because you push it straight into your own GRC, where the auditor already works: the OSCAL assessment-results, the plan of action and milestones, and the compliance PDF land as attachments on the control, and a comment records the Merkle tree root that the auditor recomputes independently and checks against the seal. The proof leaves the seal only for a system that belongs to you, and the egress itself is gated by an MFA step. SHIPPED

Wdrożenie

CYRBER stawiasz na dwa sposoby: model managed prowadzimy my na własnych serwerach, podczas gdy on-prem stoi w całości u klienta, na jego infrastrukturze i pod jego kontrolą. Ten rozdział mówi wprost, czym oba modele się różnią, co jest gotowe już dziś i co jeszcze dokładamy.

Dwa modele

Managed. Instancję prowadzimy my na infrastrukturze CYRBER, dzięki czemu dostajesz gotowe konto i zaczynasz pracę w kilka minut, bez stawiania własnego serwera, a wiele organizacji dzieli tę samą instancję z twardą izolacją per-org na poziomie bazy danych, tak że dane jednego klienta nigdy nie widzą danych drugiego, i właśnie w tym modelu działa dziś app.cyrber.com. MAMY

On-prem. Cały stos stoi wtedy u klienta, na jego serwerach i na jego licencji, przez co przebieg misji oraz wszystkie dane zostają na jego infrastrukturze, a my nie trzymamy żadnej kopii; jest to model dla tych, którzy potrzebują pełnej suwerenności, a w trybie air-gap także rozumowanie zostaje w murach klienta, na lokalnym modelu. On-prem i air-gap dla organizacji MAMY.

Wybór modelu nie zmienia samego produktu, lecz jedynie to, gdzie on stoi i kto trzyma nad nim kontrolę, dlatego reszta rozdziału opisuje już wyłącznie stos, jednakowy w obu wariantach.

Edycje

Produkt jest jeden, a cztery edycje różnią się limitem hostów i organizacji, zakresem modułów, wsparciem i czasem przechowywania misji. Zakres handlowy i ceny pakietów podaje cennik na cyrber.com. Tutaj opisujemy to, co edycja egzekwuje w kodzie. Aktywne misje SPECULATOR przechowuje przez trzydzieści dni, EXCUBITOR przez dziewięćdziesiąt, HARUSPEX przez rok. Raporty zostają dłużej: dziewięćdziesiąt dni, rok i trzy lata. W PRAEFECTUS okres przechowywania misji i raportów określa umowa. Tryb impact, czyli dowód skutku za pięcioma bramkami, otwiera dopiero najwyższa edycja. Okna retencji per edycja oraz mapowanie licencji na pakiet MAMY.

Egzekwowanie licencji

Wygaśnięcie edycji egzekwuje sam system, i to stopniowo. Dopóki licencja jest ważna, pracujesz bez ograniczeń, natomiast po jej wygaśnięciu wchodzisz najpierw w okres karencji, w którym blokujemy jedynie zakładanie nowych misji, podczas gdy cała reszta pracy toczy się dalej, a gdy i ten okres minie, platforma przechodzi w tryb tylko do odczytu, w którym żaden zapis już nie przejdzie, aż wreszcie w tryb zamrożenia danych. Nawet w tym ostatnim trybie eksport dowodów, czyli raport PDF, wykonawczy i techniczny, nadal działa, więc nieopłacona faktura nie odcina Cię od dowodów. Każdą z tych blokad system zgłasza operatorowi komunikatem z nazwą trybu. Stopniową degradację po wygaśnięciu wraz z zawsze otwartym eksportem MAMY

Architektura

Rdzeń stanowią FastAPI oraz Celery, osadzone nad PostgreSQL 16 i Redis, a całość ukryta jest za nginx, podczas gdy zadania w tle chodzą czterema izolowanymi kolejkami, z których scanning obsługuje moduły MENS, reporting generuje PDF, intel zasila się ze źródeł KEV, ATT&CK i EPSS, a maintenance pilnuje arsenału, licencji i sprzątania. Ponieważ wszystko składa jeden plik Compose z profilami, ciężkie narzędzia, takie jak Kali, przeglądarkę czy garak, włączasz jednym profilem. MAMY

Wymagania i tryby

Na start wystarcza pojedynczy węzeł on-prem, na którym stoi Docker, znajduje się dysk na dane i raporty oraz otwarty port dla nginx, a trybem domyślnym jest instalacja u klienta, przy której przebieg misji i dane zostają na jego infrastrukturze. Całość podnosi jeden instalator uruchamiany pojedynczym poleceniem, natomiast obraz przygotowany pod prywatny rejestr, skracający postawienie środowiska całkowicie odciętego do kilku minut, dokładamy osobno. Stos Compose oraz instalator jednego polecenia MAMY, a obraz pod prywatny rejestr DOŁOŻYMY.

Wymagania sprzętowe

Wymagań sprzętowych nie zgadujemy, ponieważ rdzeń stacku deklaruje w Compose twarde limity zasobów, więc wyprowadzamy je wprost z tego, ile realnie biorą kontenery, a baza, Redis, API, worker Celery, beat oraz most Matrix sumują się w szczycie do około ośmiu gigabajtów pamięci i siedmiu rdzeni, natomiast każdy cięższy profil narzędziowy, taki jak ZAP czy Kali, dokłada do tego kolejne dwa gigabajty i dwa rdzenie. Poniżej opisujemy trzy poziomy, prowadzące od progu, na którym system w ogóle ruszy, aż po konfigurację z zapasem na pełny arsenał, przy czym pod samym poziomem minimalnym leży jeszcze niższy próg absolutny rzędu sześćdziesięciu gigabajtów dysku, którego instalator pilnuje i poniżej którego odmawia startu, lecz trzymamy go wyłącznie na ewaluację, a nie na realną pracę. MAMY

Do zasobów obliczeniowych dochodzą zasoby dyskowe, ponieważ organizm z czasem rośnie i uczy się na własnej historii, a na dysku odkładają się dane PostgreSQL, wygenerowane raporty PDF, artefakty skanów, łańcuch pieczęci oraz korpus instytucjonalny z osadzeniami, z których CORTEX i LIBER czerpią przy kolejnych misjach, dlatego dysk traktuj jako zasób rosnący, a nie stały, i przewiduj zapas ponad wartości podane w powyższych poziomach. MAMY

Zupełnie osobną możliwością systemu jest UMBRA. Dziś to precyzyjny blueprint środowiska klienta: migawka topologii i powierzchni ataku wraz z migawkami ryzyka oraz sześciogodzinnym cooldownem. Na dysku waży tyle, ile metadane, rzędy megabajtów na organizację, i nie rezerwuje pod siebie osobnych maszyn. Celem, do którego zmierzamy, jest pełny cyfrowy bliźniak: postawiona z tego blueprintu, działająca replika środowiska wraz z Active Directory i siecią, na której puszczasz testy destrukcyjne najgorszego scenariusza, nie narażając ani jednego żywego systemu. Taki bliźniak potrzebuje własnej puli rdzeni, pamięci i dysku, skalowanej wprost z liczbą odwzorowanych hostów i dobranej do skali celu oraz budżetu klienta. Blueprint z cooldownem MAMY. Automatyczne stawianie pełnej, działającej umbry pod skalę całego środowiska DOŁOŻYMY.

Jeśli nie chcesz stawiać sprzętu samodzielnie, przygotowujemy gotowy appliance CYRBER, czyli maszynę z zainstalowanym i zestrojonym systemem, którą wystarczy wpiąć w sieć, aby ruszyć bez własnej roboty infrastrukturalnej. DOŁOŻYMY

Retencja i dane do uczenia

Wzrost dysku nie jest nieokreślony, ponieważ część danych porządkuje w tle retencja: telemetria pulsu znika po sześćdziesięciu dniach, misje przechodzą do archiwum po oknie właściwym dla pakietu, a nocne zadanie trwale usuwa zakończone misje po upływie okna pakietu, nie wcześniej niż po dziewięćdziesięciu dniach. Okno wynosi trzydzieści dni w SPECULATOR, dziewięćdziesiąt w EXCUBITOR oraz trzysta sześćdziesiąt pięć w HARUSPEX, a raporty trzymamy odpowiednio dłużej. Okres z umowy (od 90 do 3650 dni) superadmin wpisuje w panelu administratora, w zakładce Licencja, i ma on pierwszeństwo przed oknem edycji, także w PRAEFECTUS. Po jego upływie nocne zadanie trwale usuwa zakończone misje, raporty razem z plikami oraz osadzenia znalezisk. Bez okresu z umowy PRAEFECTUS niczego sam nie usuwa. MAMY

Retencja misji nie obejmuje pamięci, na której organizm się uczy: genomu bezpieczeństwa z migawkami i trendem, osadzeń znalezisk, korpusu instytucjonalnego LIBER i wzorców CORTEX. Po usunięciu surowych misji ta pamięć zostaje, a dzięki niej system z każdym miesiącem ocenia trafniej. Osadzenia powstają z treści znalezisk, dlatego okres z umowy obejmuje je razem z misjami, a Ty wpisujesz je do rejestru czynności przetwarzania. Bez okresu z umowy ta pamięć zostaje bez czyszczenia. Ta warstwa rośnie razem z historią, więc przy instalacji na lata zaplanuj zapas dysku ponad wartości z poziomów sprzętowych. MAMY

Instalacja krok po kroku

Najkrótsza droga to jedno polecenie, ponieważ instalator sprawdza wymagania systemu, w razie potrzeby dokłada Dockera, generuje wszystkie sekrety oraz plik .env, wystawia certyfikat TLS, zakłada rolę bazy pod izolację RLS, podnosi stos, migruje schemat bazy do najnowszej wersji, czeka na zdrowe API, a na końcu wypisuje adres panelu wraz z odciskiem maszyny do aktywacji licencji. Ścieżkę ręczną, czyli klon repozytorium, wypełnienie .env (baza, Redis, sekret JWT o długości co najmniej trzydziestu dwóch znaków oraz klucz szyfrujący kolumny), postawienie stosu i migracje, zostawiamy dla tych, którzy wolą prowadzić każdy krok samodzielnie, przy czym po jednej i drugiej drodze zakładasz konto administratora, włączasz MFA i od tego momentu logujesz się już wyłącznie ciasteczkiem HTTP-only. MAMY

Kreator pierwszego uruchomienia

Po postawieniu stosu nie zostajesz przed pustym panelem, bo pierwsze logowanie otwiera kreator wdrożenia, który w pięciu krokach prowadzi Cię od świeżej instalacji do pierwszej misji. Zaczynasz od profilu sektora: wybór instytucji, na przykład samorząd, finanse, przemysł albo zdrowie, ustawia rozsądne wartości domyślne pakietu, polityki i macierzy autonomii. Potem zakładasz organizację i wybierasz jej tryb połączenia: podłączony, planowy albo całkowicie odcięty. Następnie podajesz zakres celu jako adresy CIDR i domeny, a kreator zapisuje na tej podstawie politykę LEX z oknami czasowymi i progami zgody. Na końcu odpala pierwszą misję MENS i przenosi Cię prosto na jej podgląd. MAMY

Model rozumowania

Rozumowanie działa w jednym z dwóch trybów. W trybie chmurowym głównym dostawcą jest Mistral, zapasowym Claude, a na końcu łańcucha stoi Groq. Pozostali dostawcy są domyślnie wyłączeni. W pętli rozumowania MENS, zanim prompt trafi do chmurowego modelu, maskujemy publiczne adresy IP oraz nazwy hostów deterministycznym hashem liczonym osobno dla każdej misji, więc model rozumuje nad strukturą, nie widząc realnych adresów, a prywatne zakresy testowe zostawiamy nietknięte. Router robi to samo maskowanie przed każdym wywołaniem modelu, także przy narracji po misji, więc adres celu nie wychodzi z platformy. W trybie air-gap rozumowanie idzie wyłącznie do lokalnego modelu, czyli Ollamy na serwerze GPU w Twojej sieci, a router nie wywołuje żadnego dostawcy zewnętrznego. Tryb ustawiasz dla organizacji. Wymuszenie go dla całej instancji jednym przełącznikiem dokładamy. Chmurę z maskowaniem adresów i tryb air-gap z lokalnym modelem MAMY.

Stąd bierze się wymóg karty z co najmniej dwudziestoma czterema gigabajtami pamięci. Model, który zamykamy w murach klienta, należy do klasy od kilkunastu do około trzydziestu miliardów parametrów: do rozumowania qwen3 klasy trzydziestu miliardów (MoE, około trzech miliardów aktywnych), do zadań badawczych Qwen czternastu miliardów. Jeden taki model po kwantyzacji mieści się razem z kontekstem w dwudziestu czterech gigabajtach. Jeśli chcesz trzymać oba załadowane równolegle, wygodną pracę daje dopiero około czterdziestu ośmiu gigabajtów pamięci GPU, czyli jedna karta 48 GB (na przykład RTX 6000 Ada) albo dwie karty po 24 GB. MAMY

Sieć i egress

Od strony sieci obraz jest przejrzysty. Do środka prowadzi tylko nginx, przez który wchodzi ruch HTTPS operatorów, i żaden inny port nie musi być wystawiony na świat. Na zewnątrz domyślna konfiguracja, bez włączonych integracji, sięga do czterech miejsc, które nazywamy wprost, bo od nich zależy cała rozmowa o air-gapie. Rozumowanie idzie do chmurowego dostawcy LLM, źródła wywiadu (Intel Sync) pobierają kanały zagrożeń z CISA KEV, MITRE ATT&CK, FIRST EPSS i NVD, a most Matrix wysyła alerty na serwer domowy. Pieczęć TESTIMONIUM wysyła sam root_hash do publicznych serwerów kalendarza OpenTimestamps po kotwicę czasową w łańcuchu Bitcoin. MAMY

Każde z tych czterech wyjść daje się domknąć, a suwerenność polega na ich świadomym odcięciu. Rozumowanie zamykasz w murach klienta lokalnym modelem na GPU w trybie air-gap. Źródła wywiadu (Intel Sync) zastępujesz pakietem wywiadu offline, który eksportujesz z instancji podłączonej i wgrywasz do odciętej. Most Matrix wyłączasz jednym przełącznikiem albo kierujesz na własny serwer domowy klienta. Kotwicę OpenTimestamps też zdejmujesz jednym przełącznikiem: pieczęć dalej domyka się drzewem Merkle i podpisem Ed25519 korzenia, a traci tylko publiczne zakotwiczenie w łańcuchu Bitcoina. Odcięcie wywiadu, mostu, kotwicy OpenTimestamps i rozumowania lokalnym modelem MAMY.

Kopia i odtwarzanie

Kopia zapasowa to zrzut PostgreSQL szyfrowany GPG, zamknięty w trybie fail-closed, w którym pozbawiony klucza skrypt produkcyjny raczej przerwie pracę, niż zapisze jawny plik na dysku, a do tego dochodzi retencja domyślnie trzydziestodniowa oraz odcisk migracji, który przy odtwarzaniu pilnuje parytetu wersji, więc wystarczy uruchamiać ją zwykłym cronem. MAMY

Pakiet to więcej niż baza. Obok zrzutu PostgreSQL zamykamy w nim wygenerowane raporty i odcisk wersji migracji, a na życzenie także plik konfiguracyjny z kluczem szyfrującym kolumny, bez którego odtworzenie bazy nie miałoby sensu. Gotowy pakiet domyślnie zapisuje się na dysku węzła. Gdy wskażesz zdalny magazyn, kopiuje się dodatkowo poza serwer, a w modelu on-prem to miejsce zostaje w pełni pod kontrolą klienta. MAMY

Rytm kopii ustawiasz własnym cronem, a my zalecamy przebieg nocny. Punkt odtworzenia, czyli ile danych najwyżej stracisz przy awarii, równa się wtedy odstępowi między kopiami i wynosi co najwyżej dobę. Świeżości ostatniej kopii pilnuje osobny sprawdzian zdrowia, a odtwarzalność potwierdza skrypt testu odtworzenia, więc kopię naprawdę sprawdzamy. Kopię, monitoring jej świeżości i test odtworzenia MAMY, a ciągłą archiwizację skracającą punkt odtworzenia poniżej doby DOŁOŻYMY.

Wysoka dostępność

O odporności mówimy wprost, ponieważ dziś stawiamy CYRBER na pojedynczym węźle, a to, co chroni go w codziennej pracy, działa wewnątrz tego węzła, gdyż kontenery pod nadzorem wstają po zawieszeniu, osobne zadania w tle wykrywają i podnoszą utknięte misje oraz cofają nieudane naprawy, tak że pojedyncza usługa, która się potknie, wraca do formy bez udziału operatora. Samoleczenie w obrębie węzła MAMY.

Nie udajemy natomiast prawdziwej wysokiej dostępności, ponieważ utrata całego węzła nie przełącza dziś ruchu na zapasowy samoczynnie, lecz sprowadza się do odtworzenia z kopii na nowym sprzęcie, którego czas zależy od rozmiaru bazy, dlatego gorący standby bazy, automatyczny failover oraz układ pozbawiony pojedynczego punktu awarii traktujemy jako osobny, świadomie nazwany etap. Odtworzenie po utracie węzła MAMY, a gorący standby z automatycznym przełączeniem DOŁOŻYMY.

Izolacja i hardening

Wiele organizacji utrzymywanych na jednej instancji rozdziela izolacja per-org na poziomie bazy danych, wejście chroni ciasteczko HTTP-only wsparte MFA/TOTP oraz SSO/OIDC, a każde wywołanie zdolności trafia do łańcucha audytu, natomiast formalny przewodnik hardeningu, spięty w jeden dokument, dopiero dokładamy. Izolację i audyt MAMY, a spójny przewodnik hardeningu DOŁOŻYMY.

To, jak prowadzić misje, czytać werdykt i eksportować dowód, opisuje rozdział Obsługa.

Deployment

You stand CYRBER up in two ways. We run the managed model on our own servers, while on-prem stands entirely at the client. This chapter says plainly how they differ, what is ready today and what we are still adding.

Two models

Managed. We run the instance on CYRBER infrastructure; you get an account and start in a few minutes, with no server of your own. Many organisations share one instance with hard per-org isolation at the database level, so one client's data never sees another's. This is how app.cyrber.com runs today. SHIPPED

On-prem. The whole stack stands at the client, on their own servers, under their licence. The mission run and the data stay on their infrastructure, and we keep no copy. This is the model for full sovereignty, and in air-gap mode the reasoning stays inside the client's walls as well, on a local model. On-prem and per-organisation air-gap are SHIPPED.

The choice does not change the product; it changes where it stands and who holds it. The rest of this chapter describes the stack itself, identical in both models.

Editions

The product is one, and the four editions differ in host and organisation limits, module scope, support and how long missions are kept. The commercial scope and prices of each package are in the pricing page on cyrber.com. Here we describe what an edition enforces in the code. SPECULATOR keeps active missions for thirty days, EXCUBITOR for ninety, HARUSPEX for a year. Reports stay longer: ninety days, a year and three years. In PRAEFECTUS the contract sets how long missions and reports are kept. Impact mode, the proof of consequence behind five gates, opens only in the top edition. The retention windows per edition and the licence-to-package mapping are SHIPPED.

Licence enforcement

The system enforces an edition's expiry itself, and it does so gradually. While the licence is valid you work without limits, whereas once it expires you enter a grace period first, in which we block only the starting of new missions while the rest of the work carries on, and when that period too runs out the platform moves into a read-only mode where no write goes through any longer, and finally into a data-frozen mode. Even in that last mode the evidence export, the PDF, executive and technical reports, still runs, so an unpaid invoice never locks you out of your evidence. The system reports each of these blocks to the operator with a message naming the mode. The gradual degradation on expiry together with an always-open export is SHIPPED

Architecture

The core is FastAPI and Celery over PostgreSQL 16 and Redis, behind nginx. Background work runs on four isolated queues: scanning for the MENS modules, reporting for PDFs, intel for the KEV, ATT&CK and EPSS feeds, and maintenance for the arsenal, licensing and cleanup. One Compose file with profiles assembles the whole thing, so heavy tools like Kali, the browser or garak come up by profile, not by hand. SHIPPED

Requirements and modes

One on-prem node is enough to start: Docker, disk for data and reports, a port for nginx. The default mode is an install at the client, the mission run and the data stay on their infrastructure. A single installer brings the whole thing up with one command, while an image built for a private registry, which cuts standing up a fully severed environment down to minutes, we add separately. The Compose stack and the one-command installer are SHIPPED, the private-registry image is PLANNED.

Hardware requirements

We do not guess the hardware, because the core stack declares hard resource limits in Compose, so we derive the sizing straight from what the containers actually take, and the database, Redis, the API, the Celery worker, beat and the Matrix bridge add up at peak to roughly eight gigabytes of memory and seven cores, while each heavier tool profile, such as ZAP or Kali, adds another two gigabytes and two cores. Below we describe three levels, leading from the threshold where the system runs at all to the configuration with headroom for the full arsenal, and below the minimum level itself sits an even lower absolute floor, around sixty gigabytes of disk, which the installer enforces and below which it refuses to start, though we keep it for evaluation only, not for real work. SHIPPED

On top of the compute come the disk resources, because the organism grows over time and learns from its own history, and the disk accumulates PostgreSQL data, generated PDF reports, scan artefacts, the seal chain and the institutional corpus with embeddings that CORTEX and LIBER draw on across later missions, so treat the disk as a growing resource rather than a fixed one and plan headroom above the figures in the levels above. SHIPPED

A wholly separate capability of the system is UMBRA. Today it is a precise blueprint of the client's environment: a snapshot of topology and attack surface with risk snapshots and a six-hour cooldown. On disk it weighs what metadata weighs, on the order of megabytes per organisation, and it reserves no machines of its own. What we are building towards is a full digital twin: a running replica stood up from that blueprint, Active Directory and network included, where you run worst-case destructive tests without exposing a single live system. Such a twin needs its own pool of cores, memory and disk, scaling directly with the number of mirrored hosts and matched to the target and the client's budget. The blueprint with its cooldown is SHIPPED. Standing up a full, running umbra automatically at the scale of a whole environment is PLANNED.

If you would rather not stand up the hardware yourself, we are preparing a ready-made CYRBER appliance, a machine with the system installed and tuned, which you only plug into the network to start, with no infrastructure work of your own. PLANNED

Retention and the learning data

Disk growth is not open-ended, because retention orders part of the data in the background: pulse telemetry is gone after sixty days, missions move to the archive after the window that fits the package, and a nightly job permanently deletes completed missions once that window has passed, never before ninety days. The window is thirty days on SPECULATOR, ninety on EXCUBITOR and three hundred and sixty-five on HARUSPEX, and reports are kept correspondingly longer. A superadmin enters the contract period (90 to 3,650 days) in the admin panel, on the Licence tab, and it takes precedence over the edition window, PRAEFECTUS included. Once it has passed, the nightly job permanently deletes completed missions, reports with their files and finding embeddings. Without a contract period, PRAEFECTUS deletes nothing on its own. SHIPPED

Mission retention does not cover the memory the organism learns from: the security genome with its snapshots and trend, the finding embeddings, the LIBER institutional corpus and the CORTEX patterns. After the raw missions are deleted this memory remains, and it is what makes the system judge more accurately each month. Embeddings are derived from finding content, so the contract period covers them together with missions, and you list them in your record of processing activities. Without a contract period this memory stays uncleaned. This layer grows with the history, so for an install meant to run for years plan disk headroom above the figures in the hardware levels. SHIPPED

Install, step by step

The shortest path is one command, because the installer checks the system requirements, adds Docker if it is missing, generates every secret and the .env file, issues a TLS certificate, sets up the database role for RLS isolation, brings the stack up, migrates the schema with Alembic to head, waits for a healthy API, and finally prints the panel address together with the machine fingerprint for licence activation. The manual path, cloning the repo, filling in .env (database, Redis, a JWT secret of at least thirty-two characters, the column encryption key), bringing the stack up and running migrations, we leave for those who prefer to drive every step themselves, and down either path you create an admin account, turn on MFA and from there log in with an HTTP-only cookie and nothing else. SHIPPED

First-run wizard

Once the stack is up you are not left staring at an empty panel, because the first login opens a deployment wizard that walks you in five steps from a fresh install to the first mission. You start with the sector profile: the choice of institution, local government, finance, industry or health for instance, sets sensible defaults for the package, the policy and the autonomy matrix. Then you create the organisation and pick its connection mode: connected, scheduled or fully severed. Next you give the target scope as CIDR addresses and domains, and the wizard writes a LEX policy with time windows and consent thresholds from it. Finally it launches the first MENS mission and takes you straight to its view. SHIPPED

The reasoning model

Reasoning runs in one of two modes. In cloud mode Mistral is the primary provider, Claude the fallback and Groq the last in the chain. Other providers are off by default. In the MENS reasoning loop, before a prompt reaches the cloud model, we mask the public IP addresses and hostnames inside it with a deterministic hash computed per mission, so the model reasons over the structure without seeing the real addresses, while private test ranges are left untouched. The router applies the same masking before every model call, including the narrative written after a mission ends, so the target address does not leave the platform. In air-gap mode the reasoning goes only to the local model, Ollama on a GPU server in your network, and the router calls no external provider. You set the mode per organisation. Enforcing it for the whole instance with a single switch is being added. The cloud with address masking and air-gap mode with a local model are SHIPPED.

This is where the requirement of a card with at least twenty-four gigabytes of memory comes from. The model we shut inside the client's walls sits in the class of a dozen or so to about thirty billion parameters: a qwen3 in the thirty-billion class (MoE, roughly three billion active) for reasoning and a Qwen of fourteen billion for research tasks. Quantised, one such model fits together with its context in twenty-four gigabytes. If you want to keep both loaded in parallel, comfortable work starts only around forty-eight gigabytes of GPU memory, that is, one 48 GB card (an RTX 6000 Ada, for example) or two 24 GB cards. SHIPPED

Network and egress

On the network side the picture is clean. The only way in is nginx, through which the operators' HTTPS traffic enters, and no other port has to face the world. Outbound, the default configuration, with no integrations enabled, reaches four places, which we name plainly, because the whole air-gap conversation turns on them. The reasoning goes to a cloud LLM provider, Intel Sync pulls threat feeds from CISA KEV, MITRE ATT&CK, FIRST EPSS and NVD, and the Matrix bridge sends alerts to a homeserver. The TESTIMONIUM seal sends the bare root_hash to the public OpenTimestamps calendar servers for a timestamp anchor on the Bitcoin chain. SHIPPED

Each of these four exits can be closed, and sovereignty means severing them deliberately. You shut the reasoning inside the client's walls with a local model on the GPU in air-gap mode. You replace Intel Sync with an offline intelligence package, exported from a connected instance and imported into the severed one. You turn the Matrix bridge off with a single switch or point it at the client's own homeserver. You drop the OpenTimestamps anchor with a switch as well: the seal still closes over its Merkle tree and the Ed25519 signature of the root, and loses only the public Bitcoin anchoring. Severing the intelligence, the bridge, the OpenTimestamps anchor and the reasoning with a local model is SHIPPED.

Backup and restore

The backup is a PostgreSQL dump encrypted with GPG and fail-closed (with no key in production the script refuses to write a plaintext file), and it comes with a default thirty-day retention and a migration fingerprint for restore parity. You schedule it with cron and it runs on its own. SHIPPED

The bundle is more than the database. Alongside the PostgreSQL dump we seal in the generated reports and the migration-version fingerprint, and on request the configuration file with the column encryption key, without which restoring the database would be pointless. By default the bundle lands on the node's disk. If you name a remote store, it is also copied off the server, and in the on-prem model that location stays entirely under the client's control. SHIPPED

You set the backup rhythm with your own cron, and we recommend a nightly run. The recovery point, meaning the most data you can lose in a failure, then equals the interval between backups and is at most one day. A separate health check watches the freshness of the latest backup, and a restore-test script proves it can be restored, so the backup is actually verified. The backup, the freshness monitoring and the restore test are SHIPPED, continuous archiving that shortens the recovery point below a day is PLANNED.

High availability

We talk about resilience plainly, because today we stand CYRBER on a single node, and what protects it in daily work runs inside that node, since supervised containers come back up after a stall, separate background tasks detect and revive stuck missions and roll back failed remediations, so a single service that trips returns to form with no hand from an operator. Self-healing within the node is SHIPPED.

What we do not pretend, on the other hand, is true high availability, because the loss of a whole node does not switch traffic to a spare on its own today, but comes down to restoring from backup on new hardware, whose time depends on the database size, so we treat a hot standby of the database, automatic failover and a layout with no single point of failure as a separate, deliberately named stage. Recovery after a node loss is SHIPPED, a hot standby with automatic failover is PLANNED.

Isolation and hardening

Many organisations on one instance are kept apart by per-org isolation at the database level. The entrance is guarded by an HTTP-only cookie, MFA/TOTP and SSO/OIDC, and every capability call lands in the audit chain. A formal hardening guide, gathered into one document, is still to come. Isolation and audit are SHIPPED, the hardening guide is PLANNED.

The Operating chapter covers how to run missions, read the verdict and export the proof.

Obsługa

Szybki start przeprowadza jedną misję od loginu aż po pieczęć, natomiast ten rozdział zbiera całą obsługę codzienną, na którą składają się role i dostęp, cykl misji, pokrętło autonomii, naprawa oraz eksport dowodu.

Role i dostęp

Role nadajesz w Administracji, przy dodawaniu użytkownika, i każda widzi tyle, ile powinna. ADMIN zarządza swoją organizacją: użytkownikami, kluczami API, SSO i dziennikiem audytu, i widzi wszystkie ekrany. OPERATOR prowadzi misje, znaleziska, operacje, naprawy, raporty i zgodność. AUDITOR ma wgląd tylko do odczytu w zgodność, weryfikację i podsumowanie dla zarządu, bez misji i operacji. CEO widzi podsumowanie dla zarządu, ryzyko i genom organizacji, przegląd znalezisk oraz stan zgodności. VIEWER ogląda znaleziska, zgodność i stan organizmu wyłącznie do odczytu. Ponad rolami stoi superadministrator, który prowadzi wszystkie organizacje, a konto demonstracyjne dostaje taki podgląd jak VIEWER. MAMY

Cykl misji

Misja zaczyna się od polityki LEX, która wyznacza zasięg oraz klasę ryzyka, po czym MENS iteruje pętlą OBSERVE, THINK, ACT, LEARN i samodzielnie dobiera następny ruch, a gdy tylko się domknie, uruchamia się łańcuch hooków, na który składają się profil SPECULUM, pieczęć TESTIMONIUM, migawka UMBRA, prognoza ANNALES, kolejka naprawy oraz pamięć LIBER. MAMY

Pokrętło autonomii

To, ile wolności otrzymuje organizm, ustawiasz na stronie /organism, gdzie dla niższej klasy ryzyka system działa samodzielnie, natomiast dla wyższej każdy krok czeka na Twoją zgodę, a opcjonalnie na bramę MFA, zanim w ogóle się wykona, więc pokrętło ma kilka klas ryzyka. MAMY

Werdykt i naprawa

Znaleziska trafiają na stronę Znaleziska z poziomem ważności i ryzykiem biznesowym, a samą naprawę prowadzi MEDICUS, który proponuje konkretny krok, którego wykonanie zatwierdzasz kodem TOTP na miejscu, bez opuszczania ekranu. MAMY

Zgodność i eksport

Wynik mapuje się na NIS2, DORA oraz RODO, a sam raport misji, w języku polskim lub angielskim i opatrzony brandingiem klienta, eksportujesz do PDF jednym kliknięciem, natomiast eksport zgodności pobierasz osobno: dla całej trójki wychodzi jako JSON, a do PDF renderuje się dziś wyłącznie NIS2, ponieważ wariantu dla DORA i RODO jeszcze nie dołożyliśmy. Każdy skan pieczętuje przy tym TESTIMONIUM drzewem Merkle oraz podpisem, dzięki czemu samą pieczęć sprawdzisz publicznie, bez dostępu do naszej bazy. Raport misji w PDF, eksport zgodności w JSON dla NIS2, DORA i RODO oraz PDF dla NIS2 MAMY, a PDF dla DORA i RODO DOŁOŻYMY (szczegóły w rozdziale Zgodność).

Podgląd na żywo

KOKPIT w trybie Battle pokazuje aktywną iterację wraz z EKG misji, natomiast żywotność organizmu, w którym każdy z 19 komponentów pozostaje pod rygorem niezmiennika I-9, obserwujesz na stronach Organizm oraz Status. MAMY

Najczęstsze pytania

Gdzie konkretnie werdykt zapada w rytuale, opisuje akt Werdykt w rozdziale Rytuał, natomiast to, jak sprawdzić pieczęć bez naszej bazy, pokazuje rozdział Weryfikacja publiczna.

Operating

Quick start walks one mission from login to seal. This is the full operation: roles, the mission cycle, the autonomy dial, remediation and the evidence export.

Roles and access

You assign roles under Administration when you add a user, and each role sees what it should. ADMIN runs their own organisation: users, API keys, SSO and the audit log, and sees every screen. OPERATOR runs missions, findings, operations, remediation, reports and compliance. AUDITOR has read-only access to compliance, verification and the executive summary, without missions or operations. CEO sees the executive summary, the organisation's risk and genome, a findings overview and the compliance status. VIEWER sees findings, compliance and the organism state, read-only. Above the roles stands the superadmin, who runs every organisation, and a demo account gets the same view as VIEWER. SHIPPED

The mission cycle

A mission starts from a LEX policy that sets the scope and the risk class. Then MENS iterates the OBSERVE, THINK, ACT, LEARN loop and picks its own next move. On close a hook chain fires: the SPECULUM profile, the TESTIMONIUM seal, the UMBRA snapshot, the ANNALES forecast, the remediation queue and the LIBER memory. SHIPPED

The autonomy dial

You set how much latitude the organism gets on /organism. For a lower risk class the system acts on its own, for a higher one a step waits for your signature (consent, optionally an MFA gate) before it fires. The dial has several risk classes, not just on and off. SHIPPED

Verdict and remediation

Findings land under Threats with a severity level and a business risk. Remediation runs through MEDICUS: it proposes a step, and you arm its execution with an inline TOTP signature, without leaving the screen. SHIPPED

Compliance and export

The result maps to NIS2, DORA and GDPR, and the mission report itself, in Polish or English and with the client's branding, exports to PDF in one click, while the compliance export is separate: it comes out as JSON for all three, and only NIS2 renders to PDF today, since we have not yet added that variant for DORA and GDPR. Every scan is sealed by TESTIMONIUM with a Merkle tree and a signature, so you can check the seal publicly, without our database. The mission report PDF, the JSON compliance export for all three and the NIS2 PDF are SHIPPED, a PDF for DORA and GDPR is PLANNED (details in the Compliance chapter).

Live view

KOKPIT in Battle Mode shows the running iteration and the mission heartbeat, and the organism's liveness, where each of the 19 components sits under the I-9 invariant, is what you see on Organism and Status. SHIPPED

Frequent questions

The Verdict act of the Mission ritual chapter shows where the verdict is reached, and the Public verification chapter shows how to check the seal without our database.

Suwerenność

Suwerenność w CYRBER znaczy, że platforma, dane oraz dowód zostają po Twojej stronie. Ten rozdział opisuje, co zostaje u Ciebie, co może wyjść na zewnątrz i jak to odciąć. Przy każdym twierdzeniu podajemy, czy działa dziś, czy dopiero je dokładamy.

On-prem

Platforma stoi u klienta, a dane i przebieg misji zostają na jego infrastrukturze, my zaś nie trzymamy żadnej kopii, ponieważ deployment on-prem działa już dziś. MAMY

Twoje dane i RODO

Z Twoimi danymi, w tym z danymi osobowymi w rozumieniu RODO, platforma pracuje u Ciebie. Wyniki skanów, znaleziska, raporty i konta użytkowników leżą w bazie na Twojej infrastrukturze. Na zewnątrz wychodzi tylko tekst, nad którym rozumuje model w chmurze. Zanim wyjdzie, platforma zamienia w nim publiczne adresy IP i nazwy domen na skróty liczone z solą danej misji, więc dostawca modelu nie widzi adresów i nie połączy dwóch misji tego samego celu. Adresy prywatne z sieci wewnętrznej przechodzą bez zmian, bo bez nich wynik skanu traci sens. Uwzględnij to w ocenie skutków dla ochrony danych. Maskowanie adresów przed wysłaniem do modelu MAMY.

Raz na dobę misje starsze niż okno Twojej edycji (30, 90 albo 365 dni) przechodzą do archiwum, a zakończone misje po upływie tego okna, nie wcześniej niż po 90 dniach, platforma trwale usuwa. W PRAEFECTUS okres przechowywania określa umowa. Po usunięciu misji zostają skróty pieczęci oraz wiedza wyprowadzona z misji: genom, wzorce i osadzenia znalezisk. Osadzenia powstają z treści znalezisk, więc uwzględnij je w rejestrze czynności, a okres ich przechowywania określa umowa. Prawo do usunięcia danych z art. 17 RODO wykonuje superadmin: anonimizuje konto użytkownika, czyli login, adres e-mail i hasło. Łańcuch audytu zostaje nienaruszony, bo dokumentuje, kto i kiedy działał w systemie. Rejestr czynności przetwarzania z art. 30 i ocenę skutków (DPIA) prowadzisz w platformie obok dowodów technicznych. Archiwizację i usuwanie według edycji, anonimizację konta i rejestr czynności MAMY.

Komunikacja i wideo bez trzeciej strony

Suwerenność nie kończy się na danych, bo dotyczy również tego, jak się komunikujesz. Szyfrowany serwer Matrix, czyli Synapse z klientem Element, oraz wideorozmowa przez Jitsi stoją jako osobne stosy obok rdzenia CYRBER, na tym samym serwerze, tak jak działają dziś w naszej własnej produkcji pod adresami meet.cyrber.com i matrix.cyrber.com. Rozmowa audio i wideo prowadzona wprost w pokoju Matrix idzie przez własny serwer mediów, szyfrowana end-to-end, więc poza mury nie wychodzi ani treść wiadomości, ani głos.

Te dwie drogi dzieli warunek tożsamości i stąd bierze się podział ról. Jitsi obsługuje każdego, kto dostanie link, bez konta i bez rejestracji, więc prowadzisz na nim demo albo umówione spotkanie z kimś z zewnątrz. Rozmowa głosowa w Matriksie wymaga konta na Twoim serwerze. Gość bez konta pisze więc do Ciebie wiadomość, a ludzie pracujący już w danym pokoju rozmawiają tam, gdzie leży historia sprawy. Alert z platformy trafia na Twój serwer Matrix, a media płyną przez Twoją maszynę, więc nawet warstwa łączności zostaje bez pośrednika i bez cudzej chmury. Są to stosy towarzyszące rdzeniowi, a nie część instalatora jednego polecenia, i tak je opisujemy, żeby nie obiecać wygody, której jeszcze nie ma. Samodzielny serwer Matrix, rozmowy audio i wideo w jego pokojach oraz wideo Jitsi MAMY, a ich złożenie w jeden instalator DOŁOŻYMY.

Lokalny model

W trybie air-gap całe rozumowanie zostaje w murach klienta. Lokalny model działa przez Ollamę na serwerze GPU, uruchamianą nakładką compose dla kart NVIDIA albo AMD, a router w tym trybie nie wywołuje żadnego dostawcy zewnętrznego. Potrzebujesz do tego serwera z kartą o co najmniej 24 GB pamięci, a opis sprzętu znajdziesz w rozdziale Wdrożenie. MAMY

Klucze u klienta

Klucz podpisujący pieczęcie jest dziś jeden na instancję, po stronie serwera. Żeby klient sam trzymał swój klucz i sam decydował o podpisie, dokładamy BYOK. DOŁOŻYMY

Pełny air-gap

Pełny air-gap wymaga odcięcia wszystkich wyjść opisanych w sekcji Sieć i egress: rozumowanie przechodzi na lokalny model, wywiad na pakiet offline, a most alertów i kotwicę OpenTimestamps wyłączasz przełącznikami. Strony aplikacji, na których pracujesz, nie pobierają fontów ani bibliotek z zewnętrznych CDN. Odcięcie wszystkich wyjść MAMY.

Każde z tych ustawień sprawdzisz sam w logach zapory swojej instalacji. Jak ten sam werdykt zweryfikujesz bez naszej bazy, pokazuje Glass House, a gdzie werdykt zapada w rytuale, opisuje akt Werdykt w rozdziale Rytuał.

Sovereignty

Sovereignty in CYRBER means the platform, the data and the proof stay on your side. This chapter describes what stays with you, what can leave and how to cut it off. Each claim says whether it works today or is still being added.

On-prem

The platform stands at the client's site. The data and the mission run stay on their infrastructure, and we keep no copy. On-prem deployment works today. SHIPPED

Your data and the GDPR

Your data, including personal data under the GDPR, stays with you. Scan results, findings, reports and user accounts sit in a database on your infrastructure. The only thing that leaves is the text the cloud model reasons over. Before it leaves, the platform replaces public IP addresses and domain names in it with hashes salted per mission, so the model provider does not see the addresses and cannot link two missions against the same target. Private addresses from the internal network pass unchanged, because without them a scan result loses its meaning; account for that in your data protection impact assessment. Address masking before the model is SHIPPED.

Once a day, missions older than your edition's window (30, 90 or 365 days) move to the archive, and the platform permanently deletes completed missions once that window has passed, never before 90 days. In PRAEFECTUS the contract sets the retention period. After a mission is deleted, the seal hashes remain, together with the knowledge derived from missions: the genome, the patterns and the finding embeddings. Embeddings are derived from finding content, so include them in your record of processing; the contract sets their retention period. A superadmin carries out the right to erasure under GDPR Article 17 by anonymising the user account (login, email address and password). The audit chain stays intact, because it records who did what in the system and when. You keep the Article 30 record of processing activities and the DPIA in the platform, next to the technical evidence. Archiving and deletion by edition, account anonymisation and the record of processing are SHIPPED.

Comms and video with no third party

Sovereignty does not stop at the data, because it also covers how you communicate. An encrypted Matrix server, Synapse with the Element client, and video calls over Jitsi run as separate stacks beside the CYRBER core, on the same metal, exactly as they run in our own production today at meet.cyrber.com and matrix.cyrber.com. A call placed inside a Matrix room goes through your own media server, end-to-end encrypted, so neither the message nor the voice leaves your walls.

What separates the two routes is the question of identity, and that is where the division of labour comes from. Jitsi serves anyone who receives a link, with no account and no registration, which makes it the route for a demo or a booked call with an outsider. A voice call in Matrix requires an account on your server. A guest without one sends you a message instead, while the people already working in a room talk where the history of the case lives. An alert from the platform reaches your Matrix server, and the media flows through your machine, so even the connectivity layer stays free of intermediaries and outside clouds. These are companion stacks, not part of the one-command installer, and we describe them that way so as not to promise a convenience that is not there yet. A self-hosted Matrix server, audio and video calls inside its rooms and Jitsi video are SHIPPED, folding them into a single installer is PLANNED.

The local model

In air-gap mode all of the reasoning stays inside the client's walls. The local model runs through Ollama on a GPU server, started with a compose overlay for NVIDIA or AMD cards, and in this mode the router calls no external provider. You need a server with a card of at least 24 GB of memory; the Deployment chapter describes the hardware. SHIPPED

Keys at the client

The key that signs the seals is, for now, one per instance, on the server side. For the client to hold their own key and own the signature, we add BYOK. PLANNED

Full air-gap

A full air-gap means cutting every exit described in the Network and egress section: the reasoning moves to the local model, intelligence to the offline package, and you switch off the alert bridge and the OpenTimestamps anchor. The application pages you work in load no fonts or libraries from external CDNs. Cutting every exit is SHIPPED.

You can check each of these settings yourself in your installation's firewall logs. The Glass House chapter shows how you check the same verdict without our database, and the Verdict act of the Mission ritual chapter shows where the verdict is reached.

Zaufanie i bezpieczeństwo

Każdą gwarancję poniżej pokazujemy tam, gdzie mieszka w kodzie, a tam, gdzie coś jest jeszcze przed nami, mówimy to wprost znacznikiem DOŁOŻYMY, zamiast to chować. Kliknij „udowodnij” przy dowolnym znaczniku MAMY, żeby zobaczyć ścieżkę pliku w kodzie. Repozytorium nie jest publiczne, a wgląd w kod udostępniamy klientom w ramach umowy o poufności.

Sondy brzegowe uwierzytelniają się podpisem. Sonda łączy się podpisem HMAC na osobnym sekrecie, ze znacznikiem czasu i porównaniem stałoczasowym, a sonda związana z własnym kluczem odrzuca zejście na współdzielony sekret, więc skradziony sekret nie podszyje się pod cudzą sondę. MAMY

Klucz nie zaleje wrażliwych tras. Trasy wrażliwe, jak zlecanie działań ofensywnych czy pobieranie raportów, mają limit tempa liczony per adres, więc skradziony klucz nie zamieni się tam w zalew żądań, a globalny limit domyślny obowiązuje na każdym wejściu API. Limit na trasach wrażliwych MAMY, globalny limit domyślny MAMY.

Jedna organizacja nie sięgnie danych drugiej. Baza odmawia dostępu domyślnie i przepuszcza wyłącznie wiersze pasujące do organizacji z kontekstu, a wyjątek jest wpięty jedynie w sygnał przeduruchomieniowy zadania, więc izolacja trzyma nawet przy błędzie w warstwie wyżej. MAMY

Nic destrukcyjnego bez człowieka w pętli. Narzędzia ofensywne wymagają jawnej zgody, polityka LEX pilnuje zakresu, moratorium wygasza nadmiar postulatów, a krok o realnym skutku czeka na zatwierdzenie po stronie klienta, więc autonomia kończy się tam, gdzie zaczyna się decyzja o szkodzie. MAMY

Pieczęć dowodu. Każde znalezisko jest zahashowane, zamknięte w drzewie Merkle i zakotwiczone przez OpenTimestamps, przy czym kalendarz łączy tysiące hashy w jedną transakcję, więc koszt pojedynczego dowodu jest bliski zeru, na łańcuch trafia sam hash bez powiązania z organizacją, a dowód wstępny masz od ręki i domykasz go później. MAMY

Klucz podpisu nigdy nie leży w kodzie. Klucz Ed25519 jest wymagany ze zmiennej środowiskowej w produkcji i platforma odmawia startu bez niego, a osobne przechowanie w module sprzętowym oraz rotację klucza dokładamy. Klucz poza kodem MAMY, moduł sprzętowy i rotacja DOŁOŻYMY.

O tym, kiedy dane wychodzą, decydujesz Ty. Dane mają politykę retencji i cykliczne czyszczenie, swoje znaleziska wyeksportujesz do CSV oraz JSON, a ślad audytu do CSV, więc zakończenie umowy nie zostawia niczego w zawieszeniu. MAMY

Widać, kto i co uruchomił. Każde wywołanie zdolności oraz zdarzenie uwierzytelnienia trafia do audytu, a łańcuch audytu jest kryptograficzny, więc przebieg jest odtwarzalny; formalne zasady dostępu do produkcji dokładamy. Ślad audytu MAMY, dokument governance DOŁOŻYMY.

Trust & Security

Every guarantee below is shown where it lives in the code, and wherever something is still ahead of us we say so plainly with a PLANNED badge rather than hide it. Click ‘prove it’ on any SHIPPED badge to see the file path in the code. The repository is not public; we give clients access to the code under a non-disclosure agreement.

Edge probes authenticate with a signature. A probe connects with an HMAC signature over a dedicated secret, with a timestamp and a constant-time comparison, and a key-bound probe refuses to fall back to the shared secret, so a stolen secret cannot impersonate another probe. SHIPPED

A key cannot flood the sensitive routes. Sensitive routes, such as dispatching offensive actions or downloading reports, are rate limited per address, so a stolen key does not turn into a flood there, and a global default limit applies on every API entry. Rate limit on sensitive routes SHIPPED, global default limit SHIPPED.

One organisation cannot reach another's data. The database denies access by default and passes only rows matching the organisation from context, and the bypass is wired solely into a task's prerun signal, so isolation holds even on a bug in the layer above. SHIPPED

Nothing destructive without a human in the loop. Offensive tools require explicit consent, LEX policy holds the scope, a moratorium damps a surplus of proposals, and a step with real impact waits for client-side approval, so autonomy ends where the decision to cause harm begins. SHIPPED

The proof seal. Every finding is hashed, sealed in a Merkle tree and anchored through OpenTimestamps, and the calendar folds thousands of hashes into a single transaction, so the cost of one proof is near zero, only the hash reaches the chain with no link to the organisation, and you hold a pending proof at once and upgrade it later. SHIPPED

The signing key never lives in code. The Ed25519 key is required from an environment variable in production and the platform refuses to start without it, and separate storage in a hardware module plus key rotation is what we add next. Key out of code SHIPPED, hardware module and rotation PLANNED.

You decide when your data leaves. Data has a retention policy and periodic cleanup, you export your findings to CSV and JSON and your audit trail to CSV, so ending the contract leaves nothing in limbo. SHIPPED

You see who ran what. Every capability call and authentication event lands in the audit, and the audit chain is cryptographic, so the run is replayable; a formal production-access governance document is what we add next. Audit trail SHIPPED, governance document PLANNED.

Weryfikacja publiczna

Każde znalezisko dostaje zobowiązanie HMAC-SHA256 liczone z solą organizacji, więc liść drzewa nie zdradza treści znaleziska. Liście łączą się w drzewo Merkle, a korzeń drzewa podpisujemy kluczem Ed25519. Zmiana jednego znaku w jednym znalezisku zmienia korzeń, a wtedy podpis przestaje się zgadzać. MAMY

Droga 1: pakiet audytora, bez sieci

Administrator albo audytor z dostępem do platformy pobiera pakiet ZIP misji (GET /api/auditor/bundle/{org_id}). W środku są: pieczęć mission_seal.json z korzeniem i podpisem, klucz publiczny PUBKEY.txt, weryfikator cyrber-verify.py (Python i PyNaCl) oraz manifest.json z sumami SHA-256 plików. Weryfikacja nie potrzebuje internetu ani naszego serwera:

python cyrber-verify.py seal mission_seal.json --pubkey $(cat PUBKEY.txt)

Wynik VERDICT: VERIFIED oznacza, że podpis jest prawidłowy, a pieczęć niezmieniona. Klucz z PUBKEY.txt możesz dodatkowo porównać z kluczem i odciskiem opublikowanym na trust.cyrber.com. MAMY

Droga 2: pojedyncze znalezisko przez API

Gdy audytor chce potwierdzić jedno znalezisko, a nie ma dostępu do platformy, dostaje własny klucz X-Proof-Key. Klucz jest imienny, ma datę ważności i uprawnienie wyłącznie do weryfikacji, więc odwołasz go jednemu audytorowi bez wpływu na pozostałych. Przekaż go kanałem innym niż poczta. MAMY

Z raportu audytor wypisuje scan_id i finding_id i pyta API:

curl -H "X-Proof-Key: $PROOF_KEY" \
  https://api.cyrber.com/api/proof/verify/{scan_id}/{finding_id}

{
  "valid": true,
  "root_hash": "3f2b7a9e1c4d8f60b52e77a1d9c3f048e91a5c0d7b2e6f39a18c4d5e7f60b2a1",
  "finding_hash": "9c7d5e1a0b3f6428d715c9a02b8e4f017e3c5a9d1b6f4e28c0a7d3b95e1f6c42",
  "verified_at": "2026-07-18T10:03:11Z"
}

W tej drodze ścieżkę Merkle przelicza nasz serwer, a pole valid podaje wynik. Audytor porównuje root_hash z korzeniem w pakiecie albo w raporcie, a finding_hash z hashem znaleziska. Kto chce przeliczyć ścieżkę sam, znajdzie ją przy każdym liściu pod GET /api/proof/trees/{scan_id} (pole merkle_path, dostęp operatorski). W instalacji on-prem adres API to adres Twojej instancji. MAMY

Public verification

Each finding gets an HMAC-SHA256 commitment computed with the organisation's salt, so a leaf of the tree reveals nothing about the finding's content. The leaves join into a Merkle tree, and we sign the tree's root with an Ed25519 key. Change one character in one finding and the root changes, so the signature no longer matches. SHIPPED

Path 1: the auditor bundle, no network

An administrator or an auditor with platform access downloads the mission's ZIP bundle (GET /api/auditor/bundle/{org_id}). It holds the seal mission_seal.json with the root and signature, the public key PUBKEY.txt, the verifier cyrber-verify.py (Python and PyNaCl) and manifest.json with SHA-256 sums of the files. Verification needs neither the internet nor our server:

python cyrber-verify.py seal mission_seal.json --pubkey $(cat PUBKEY.txt)

VERDICT: VERIFIED means the signature is valid and the seal unchanged. You can also compare the key in PUBKEY.txt with the key and fingerprint published at trust.cyrber.com. SHIPPED

Path 2: a single finding through the API

When an auditor wants to confirm one finding and has no platform access, they get their own X-Proof-Key. The key is personal, has an expiry date and carries the verification right only, so you can revoke it for one auditor without affecting the others. Hand it over through a channel other than email. SHIPPED

The auditor takes scan_id and finding_id from the report and queries the API:

curl -H "X-Proof-Key: $PROOF_KEY" \
  https://api.cyrber.com/api/proof/verify/{scan_id}/{finding_id}

{
  "valid": true,
  "root_hash": "3f2b7a9e1c4d8f60b52e77a1d9c3f048e91a5c0d7b2e6f39a18c4d5e7f60b2a1",
  "finding_hash": "9c7d5e1a0b3f6428d715c9a02b8e4f017e3c5a9d1b6f4e28c0a7d3b95e1f6c42",
  "verified_at": "2026-07-18T10:03:11Z"
}

On this path our server walks the Merkle path and the valid field gives the result. The auditor compares root_hash with the root in the bundle or the report, and finding_hash with the finding's hash. Anyone who wants to walk the path themselves finds it on each leaf at GET /api/proof/trees/{scan_id} (the merkle_path field, operator access). In an on-prem installation the API address is your own instance. SHIPPED

Zgodność

TESTIMONIUM mapuje znaleziska na kontrole regulacyjne: coverage per wymóg, poziom ryzyka tam, gdzie kontrola nie jest spełniona, i luka do zamknięcia w naprawie. MAMY

Frameworki

NIS2 (art. 21 ust. 2), DORA (ryzyko ICT oraz rekordy autoryzacji TLPT), RODO (środki techniczne i podsumowanie ochrony danych), ISO/IEC 27001:2022. Wszystkie cztery widzisz w panelu zgodności organizacji, a eksporty opisane niżej obejmują NIS2, DORA i RODO. MAMY

Eksport per misja

Endpoint zwraca wszystkie trzy frameworki naraz, nie jeden wybrany filtrem ?framework=: nie ma takiego parametru, ponieważ oceniamy misję jednym zapytaniem pod NIS2, DORA i RODO równolegle. MAMY

GET /api/proof/mission/4821/compliance

Przykładowa odpowiedź. Nazwa organizacji i wartości pokrycia są ilustracyjne, nie są benchmarkiem produktu ani realnym wynikiem klienta.

{
  "organization": "Acme Sp. z o.o.",
  "mission_id": 4821,
  "overall_status": "PARTIALLY_COMPLIANT",
  "frameworks": {
    "NIS2": {
      "overall_status": "PARTIALLY_COMPLIANT",
      "risk_level": "MEDIUM",
      "coverage_percentage": 56,
      "requirements": {
        "21_2_b": {
          "name": "Obsługa incydentów",
          "article": "Art. 21(2)(b)",
          "status": "COVERED_WITH_FINDINGS",
          "covering_modules": ["nuclei", "mens_loop"],
          "high_critical_findings": 1
        },
        "21_2_e": {
          "name": "Bezpieczeństwo nabywania i utrzymania systemów, obsługa podatności",
          "article": "Art. 21(2)(e)",
          "status": "NOT_TESTED",
          "covering_modules": [],
          "high_critical_findings": 0
        }
      },
      "summary": {"total_requirements": 9, "covered": 5, "covered_with_findings": 2, "not_tested": 4}
    },
    "DORA": {"overall_status": "PARTIALLY_COMPLIANT", "coverage_percentage": 55},
    "GDPR": {"overall_status": "PARTIALLY_COMPLIANT", "coverage_percentage": 84}
  },
  "coverage_summary": {"NIS2": 56, "DORA": 55, "GDPR": 84}
}

Eksport per organizacja

/api/proof/export/{nis2|dora|gdpr}/{org_id} zwraca zagregowany JSON po wszystkich misjach organizacji dla każdego z trzech frameworków, natomiast wariant PDF renderuje WeasyPrint na razie tylko dla NIS2 (/api/proof/export/nis2/{org_id}/pdf), podczas gdy DORA i RODO zostają przy JSON. Eksport JSON całej trójki oraz PDF dla NIS2 MAMY, a PDF dla DORA i RODO DOŁOŻYMY.

Eksport w otwartym standardzie OSCAL

CYRBER eksportuje dowód badania w otwartym standardzie NIST OSCAL 1.1.2, w dwóch modelach, przy czym pierwszy z nich, assessment-results, niesie wyniki badania, w którym każda obserwacja daje się zweryfikować względem korzenia Merkle danej misji, a drugi, plan-of-action-and-milestones, zbiera otwarte zadania naprawcze. Ponieważ dokument przechodzi walidację oficjalnym narzędziem oscal-cli instytutu NIST, nabywca wczytuje go wprost do własnego systemu GRC, nie pisząc ani nie utrzymując własnego tłumacza formatu, i właśnie dlatego oparcie się o standard branżowy jest dla odbiorcy wygodniejsze niż kolejny format zamknięty w jednym produkcie. Eksport OSCAL, zarówno dla pojedynczej misji (/api/proof/mission/{id}/oscal/assessment-results oraz /api/proof/mission/{id}/oscal/poam), jak i zbiorczo dla całej organizacji (parametr ?format=oscal na trasach eksportu), MAMY. Natywny push tego dokumentu do ServiceNow IRM (Table API i Attachment API, ten sam rekord przy ponownym wysłaniu) MAMY. Natywne REST API Eramba Enterprise DOŁOŻYMY. Poszczególne znaleziska wiążą się z konkretnymi artykułami regulacji przez mapowanie modułu skanującego, który je wykrył, na wymaganie NIS2, DORA lub RODO, dzięki czemu przeważająca część dowodu wskazuje wprost artykuł, którego dotyczy, natomiast jeżeli ustalenie pochodzi z modułu spoza mapy, trafia do dokumentu jako niezmapowane, co jest w jego treści widoczne wprost i świadomie nie jest maskowane, ponieważ dokument dowodowy nie może twierdzić więcej, niż zostało zbadane.

Prawo, dane i samodoskonalenie

CYRBER ocenia odporność ludzi na socjotechnikę na podstawie zachowania w kontrolowanej kampanii, a nie cech osobistych. Ocena jest deterministyczna i liczona z tego samego materiału, bez zewnętrznego wejścia. Każde działanie wobec pracownika wymaga zgody organizacji i zatwierdzenia przed wysyłką, wynik służy doborowi szkolenia, nie decyzjom kadrowym, i nie jest podstawą zautomatyzowanej decyzji w rozumieniu art. 22 RODO. Administratorem danych pracowników pozostaje organizacja klienta.

Publiczny, zakotwiczony dowód to jednokierunkowy skrót kryptograficzny (korzeń Merkle, podpis Ed25519, kotwica OpenTimestamps), a nie treść znalezisk. Surowe znaleziska, które mogą zawierać dane osobowe, pozostają w bazie organizacji i podlegają usunięciu. Zakotwiczony skrót nie ujawnia treści, więc usunięcie surowych ustaleń nie przerywa łańcucha dowodowego. Ocenę, czy skrót jest dla Ciebie daną osobową, zostaw inspektorowi ochrony danych.

Pętla samodoskonalenia proponuje zmiany, nie wprowadza ich sama. Wnioski trafiają do kolejki decyzyjnej FORUM i czekają na rozstrzygnięcie. System nie zmienia własnego kodu, promptów ani reguł bez tego kroku.

Licencja i dostęp do kodu: Business Source License 1.1, wgląd w kod w ramach umowy o poufności.

Compliance

TESTIMONIUM maps findings onto regulatory controls: coverage per requirement, a risk level wherever a control is not met, and a gap to close through remediation. SHIPPED

Frameworks

NIS2 (Art. 21(2)), DORA (ICT risk plus TLPT authorisation records), GDPR (technical measures and a data protection summary), ISO/IEC 27001:2022. You see all four in the organisation's compliance panel, while the exports described below cover NIS2, DORA and GDPR. SHIPPED

Per-mission export

The endpoint returns all three frameworks at once, not one picked through a ?framework= filter: there is no such parameter, one call assesses the mission under NIS2, DORA and GDPR in parallel. SHIPPED

GET /api/proof/mission/4821/compliance

Example response. The organisation name and coverage figures are illustrative, not a product benchmark or a real customer result.

{
  "organization": "Acme Sp. z o.o.",
  "mission_id": 4821,
  "overall_status": "PARTIALLY_COMPLIANT",
  "frameworks": {
    "NIS2": {
      "overall_status": "PARTIALLY_COMPLIANT",
      "risk_level": "MEDIUM",
      "coverage_percentage": 56,
      "requirements": {
        "21_2_b": {
          "name": "Incident handling",
          "article": "Art. 21(2)(b)",
          "status": "COVERED_WITH_FINDINGS",
          "covering_modules": ["nuclei", "mens_loop"],
          "high_critical_findings": 1
        },
        "21_2_e": {
          "name": "Recovery plan testing",
          "article": "Art. 21(2)(e)",
          "status": "NOT_TESTED",
          "covering_modules": [],
          "high_critical_findings": 0
        }
      },
      "summary": {"total_requirements": 9, "covered": 5, "covered_with_findings": 2, "not_tested": 4}
    },
    "DORA": {"overall_status": "PARTIALLY_COMPLIANT", "coverage_percentage": 55},
    "GDPR": {"overall_status": "PARTIALLY_COMPLIANT", "coverage_percentage": 84}
  },
  "coverage_summary": {"NIS2": 56, "DORA": 55, "GDPR": 84}
}

Per-org export

/api/proof/export/{nis2|dora|gdpr}/{org_id} returns aggregated JSON across every mission the organisation ran, for each of the three frameworks, while the PDF variant renders through WeasyPrint for NIS2 alone for now (/api/proof/export/nis2/{org_id}/pdf), whereas DORA and GDPR stay JSON. The JSON export of all three and the NIS2 PDF are SHIPPED, a PDF for DORA and GDPR is PLANNED.

Export in the open OSCAL standard

CYRBER exports its assessment evidence in the open NIST OSCAL 1.1.2 standard across two models, where the first one, assessment-results, carries the findings of the assessment in which every observation can be verified against the mission Merkle root, and the second one, plan-of-action-and-milestones, gathers the open remediation tasks. Because the document passes validation with the official NIST oscal-cli tool, a buyer loads it straight into their own GRC system without writing or maintaining a bespoke format translator, and that is precisely why relying on an industry standard is more convenient for the recipient than yet another format locked inside a single product. OSCAL export, both for a single mission (/api/proof/mission/{id}/oscal/assessment-results and /api/proof/mission/{id}/oscal/poam) and aggregated for the whole organisation (the ?format=oscal parameter on the export routes), is SHIPPED. Native push of that document into ServiceNow IRM (Table API and Attachment API, the same record on a repeat send) is SHIPPED. A native Eramba Enterprise REST API is PLANNED. Individual findings tie to concrete regulatory articles through a mapping of the scanning module that surfaced them onto a NIS2, DORA or GDPR requirement, so the majority of the evidence points straight at the article it concerns, whereas a finding coming from a module outside the map enters the document as unmapped, which is shown plainly in its contents and is deliberately not masked, because an evidence document must never claim more than what was actually examined.

Law, data and self-improvement

CYRBER assesses people's resilience to social engineering from behaviour in a controlled campaign, not from personal traits. The scoring is deterministic and computed from the same material, with no external input. Every action toward an employee requires the organisation's consent and approval before it is sent, the result guides training rather than HR decisions, and it is not a basis for an automated decision within the meaning of Article 22 GDPR. The controller of employee data remains the client organisation.

The public, anchored proof is a one-way cryptographic digest (a Merkle root, an Ed25519 signature, an OpenTimestamps anchor), not the content of the findings. Raw findings, which may contain personal data, stay in the organisation's database and can be erased. The anchored digest reveals no content, so erasing the raw findings does not break the evidence chain. Leave the question of whether a digest counts as personal data for you to your data protection officer.

The self-improvement loop proposes changes, it does not apply them on its own. Proposals land in the FORUM decision queue and wait for a ruling. The system does not change its own code, prompts or rules without that step.

Licence and access to the code: Business Source License 1.1, access to the code under a non-disclosure agreement.

Reakcja na incydent

Przy znalezisku o poziomie CRITICAL lub HIGH system wysyła zdarzenie do zewnętrznego SIEM-a automatycznie, przez webhook, bez czekania na operatora. MAMY

Payload

{
  "source": "CYRBER",
  "event_type": "finding_detected",
  "title": "Finding Detected",
  "color": "#ff4444",
  "timestamp": "2026-07-18T10:15:00Z",
  "payload": {
    "severity": "CRITICAL",
    "target": "10.0.0.5",
    "finding": "SQL Injection",
    "cve_id": "CVE-2024-1234",
    "organization_id": 1,
    "mission_id": "m-4821",
    "message": "Parametr id podatny na wstrzyknięcie SQL"
  }
}

Podpis

Każde zdarzenie niesie nagłówek X-CYRBER-Signature, HMAC-SHA256 nad surowym ciałem payloadu, liczony współdzielonym sekretem ustalonym z góry przy konfiguracji webhooka. SOC weryfikuje go offline: liczy ten sam HMAC-SHA256 nad otrzymanym ciałem tym samym sekretem i porównuje wynik z nagłówkiem, bez odpytywania naszego API. MAMY

Korelacja i air-gap

Operator SOC koreluje event z własnym logiem po polach payloadu, przede wszystkim po mission_id oraz target, a sam podpis HMAC sprawdza offline współdzielonym sekretem, bez żadnego wywołania do CYRBER. Pieczęć całej misji sprawdza offline z pakietu audytora, a pojedyncze znalezisko przez API z kluczem X-Proof-Key, jak opisuje rozdział Weryfikacja publiczna. Weryfikację podpisu webhooka i pieczęci misji offline MAMY, a wzbogacenie samego eventu o gotowy verify_url i merkle_root, żeby SOC nie sięgał po nie osobno, DOŁOŻYMY.

Incident response

A CRITICAL or HIGH finding sends an event to the external SIEM on its own, over a webhook, with no operator needed to trigger it. SHIPPED

Payload

{
  "source": "CYRBER",
  "event_type": "finding_detected",
  "title": "Finding Detected",
  "color": "#ff4444",
  "timestamp": "2026-07-18T10:15:00Z",
  "payload": {
    "severity": "CRITICAL",
    "target": "10.0.0.5",
    "finding": "SQL Injection",
    "cve_id": "CVE-2024-1234",
    "organization_id": 1,
    "mission_id": "m-4821",
    "message": "id parameter vulnerable to SQL injection"
  }
}

Signature

Every event carries an X-CYRBER-Signature header, an HMAC-SHA256 over the raw payload body, computed with a shared secret agreed when the webhook was configured. The SOC verifies it offline, computing the same HMAC-SHA256 over the received body with that same secret and comparing it against the header, no call back to our API required. SHIPPED

Correlation and air-gap

The SOC operator correlates the event against their own log by the payload fields, chiefly mission_id and target, and checks the HMAC signature offline with the shared secret, with no call to CYRBER at all. They check the whole mission's seal offline from the auditor bundle, and a single finding through the API with an X-Proof-Key, as the Public verification chapter describes. Verifying the webhook signature and the mission seal offline are SHIPPED, while enriching the event itself with a ready verify_url and merkle_root, so the SOC need not fetch them separately, is PLANNED.

Obowiązki regulacyjne

Regulacje wymagają, żebyś potrafił pokazać, co i kiedy zrobiłeś. Poniższe powierzchnie istnieją właśnie po to, aby odpowiedź na takie pytanie dało się wydrukować, zamiast opowiadać ją na spotkaniu.

Walidacja u siebie

Osobną sprawą jest pytanie, czy Twoje własne systemy bezpieczeństwa w ogóle zobaczyły to, co robiliśmy. Integracja z Energy Logserver pozwala sprawdzić, czy zdarzenie wygenerowane przez misję dotarło do Twojego magazynu logów, ponieważ test detekcji ma sens tylko wtedy, gdy potwierdzisz go po swojej stronie, a nie po naszej. MAMY

Regulatory duties

Regulations require you to show what you did and when. The surfaces below exist so that the answer to such a question can be printed rather than told at a meeting.

Validation on your side

A separate question is whether your own security systems saw any of what we did. The Energy Logserver integration lets you check that an event generated by a mission reached your log store, because a detection test only means something once you confirm it on your side rather than on ours. SHIPPED

Integracje

Po zamknięciu misji łańcuch hooków rozsyła znaleziska na zewnątrz, a konfiguracja tego rozsyłu żyje w panelu admin → Integrations, osobno dla każdej organizacji.

Kanały wychodzące

Matrix (czat w czasie rzeczywistym), webhook (POST JSON pod dowolny endpoint, w tym Slack, Teams czy Discord, z opcjonalnym podpisem HMAC), Jira (automatyczne zgłoszenie na znalezisko), GitLab (issue tracker), Wazuh (korelacja SIEM), Splunk (push HEC), QRadar (cele i CVE do reference setu, korelacja SOC), Microsoft Sentinel (znaleziska z technikami ATT&CK przez Logs Ingestion), Energy SOAR (alerty do containmentu), MS Teams (powiadomienia), MISP i TheHive (threat intel, IOC), ELS (zewnętrzny strumień logów, syslog CEF oraz Elasticsearch). To trzynaście kanałów, którymi platforma wypycha znaleziska na zewnątrz. MAMY

Jeśli nie masz SIEM-a, CYRBER działa bez niego, a znaleziska dostajesz w raportach i kanałach wymienionych wyżej. Drogę od ataku do jego wykrycia w jednym zdarzeniu pokazujemy na demo Wazuha, a wdrożenie Wazuha u Ciebie jest osobną usługą, poza licencją.

Matrix

Pokoje alertów, zgód i porannego podsumowania zakładasz osobno dla każdej organizacji, więc alerty jednego klienta nie trafiają do pokoju innego. Organizacja bez własnych pokoi korzysta z pokoi wspólnych instalacji. Pokoje systemowe operatora platformy (System, Admin, Incydenty, Postulaty) są wspólne dla całej instancji. MAMY

Jira i GitLab

Do trackera trafiają dziś wyłącznie znaleziska o severity CRITICAL oraz HIGH, ponieważ ten próg jest zaszyty w łańcuchu hooków po misji, a severity mapuje się na priorytet Jira wprost, gdzie dla CRITICAL zakładamy ticket o priorytecie Highest, a dla HIGH o priorytecie High. GitLab dostaje issue tą samą ścieżką, natomiast MEDIUM, LOW oraz INFO nie trafiają do trackera wcale. MAMY

Próg konfigurowalny osobno dla każdej organizacji, a więc wybór, od którego poziomu severity zakładamy ticket, DOŁOŻYMY.

Integracje wejściowe

Rozsył znaleziska biegnie na zewnątrz, natomiast platforma przyjmuje też połączenia z drugiej strony, a każde z nich ma w panelu administratora osobną zakładkę, niezależną od kanałów. Tożsamość wpinasz przez SSO/OIDC, gdzie logowanie prowadzi zewnętrzny dostawca, taki jak Okta, Microsoft Entra ID albo Google, a przepływ domyka standardowy OpenID Connect z weryfikacją podpisu tokena. Dane o zagrożeniach dostarczają źródła wywiadu (Intel Sync), które zaciągają kanały zagrożeń z CISA KEV, NVD, FIRST EPSS oraz MITRE ATT&CK, a w trybie odciętym zastępujesz go pakietem wywiadu offline. Podatności celu dociągasz z Tenable.io, skąd platforma pobiera znane CVE hosta i wpuszcza je do rozumowania MENS na etapie OBSERVE, wzbogacając ocenę, zanim ruszą moduły skanujące. Dostęp maszyna do maszyny otwierasz kluczem API w nagłówku X-API-Key, obwarowanym zakresami uprawnień, przy czym tą samą bramą stoi serwer MCP, przez który zewnętrzny agent sięga po narzędzia platformy. MAMY

Silniki skanujące

Obok modułów, którymi MENS dysponuje w trakcie misji, CYRBER prowadzi też zewnętrzny silnik skanowania podatności Greenbone, znany szerzej jako OpenVAS, wpięty protokołem GMP do osobnego serwera skanera, a nie do jednego z kontenerów platformy. Codzienny harmonogram sam uruchamia głęboki skan każdego hosta, który mieści się w zakresie polityki LEX, raz na noc, nawet jeśli ten sam host ma w zakresie kilka organizacji; każda z nich dostaje własny wynik z tego jednego przebiegu. Skaner nie rusza sieci laboratorium platformy. Pełny skan hosta trwa zwykle kilka godzin, a ostatnie procenty postępu stoją długo, bo skaner domyka wtedy wolne testy; kokpit pokazuje taki skan w stopce jako skan w tle, z czasem trwania. Osobny cykl dociąga wynik, a raport ma dla niego własną sekcję i wlicza znaleziska do poziomu ryzyka na okładce. Gdy skaner nie dotrze do hosta, wynik brzmi „nie oceniono”, a nie „zero znalezisk”, więc cisza nie udaje czystego systemu. MAMY

Konfiguracja

Każdy kanał włączasz zmienną środowiskową albo wpisem na poziomie organizacji, który trafia do bazy i wczytuje się dopiero w chwili rozsyłu, dzięki czemu pojedynczej integracji nie musisz przypłacać restartem całej platformy. MAMY

Integrations

Once a mission closes, the hook chain fans findings out to your stack. Configuration lives under admin → Integrations, per organisation.

Outbound channels

Matrix (real-time chat), webhook (POST JSON to any endpoint, Slack, Teams or Discord included, with an optional HMAC signature), Jira (an issue per finding, automatic), GitLab (issue tracker), Wazuh (SIEM correlation), Splunk (HEC push), QRadar (targets and CVEs into a reference set, SOC correlation), Microsoft Sentinel (findings with ATT&CK techniques via Logs Ingestion), Energy SOAR (containment alerts), MS Teams (notifications), MISP and TheHive (threat intel, IOCs), ELS (external log stream, syslog CEF and Elasticsearch). This is a set of thirteen channels through which the platform pushes findings out. SHIPPED

If you have no SIEM, CYRBER runs without one and findings reach you through the reports and the channels listed above. We show the path from an attack to its detection in a single event on our Wazuh demo, and deploying Wazuh on your side is a separate service, outside the licence.

Matrix

You set up the alerts, approvals and morning briefing rooms separately for each organisation, so one client's alerts never reach another client's room. An organisation without its own rooms uses the installation's shared rooms. The platform operator's system rooms (System, Admin, Incidents, Requests) are shared across the instance. SHIPPED

Jira and GitLab

Only CRITICAL and HIGH findings reach the tracker today, because that threshold is baked into the post-mission hook chain, and severity maps straight onto a Jira priority, where CRITICAL opens a Highest-priority ticket and HIGH a High one. GitLab gets an issue down the same path, while MEDIUM, LOW and INFO never reach the tracker at all. SHIPPED

Making the threshold configurable per organisation, so you pick the severity level at which a ticket opens, is PLANNED.

Inbound integrations

The finding fan-out runs outward, yet the platform also takes connections from the other side, and each of them has its own tab in the admin panel, separate from the channels. Identity plugs in through SSO/OIDC, where an external provider such as Okta, Microsoft Entra ID or Google drives the login and standard OpenID Connect closes the flow with token-signature verification. Intelligence is fed by Intel Sync, which pulls threat feeds from CISA KEV, NVD, FIRST EPSS and MITRE ATT&CK, and in the severed mode you replace it with an offline intelligence bundle. Target vulnerabilities come in from Tenable.io, from which the platform pulls the host’s known CVEs and feeds them into MENS reasoning at the OBSERVE stage, enriching the assessment before the scanning modules run. Machine-to-machine access opens with an API key in the X-API-Key header, fenced by permission scopes, and the same gate carries the MCP server, through which an external agent reaches the platform's tools. SHIPPED

Scanning engines

Beyond the modules MENS dispatches during a mission, CYRBER also drives an external Greenbone vulnerability scanner, known more widely as OpenVAS, wired over the GMP protocol to a separate scanner server rather than to one of the platform's own containers. A daily schedule launches a deep scan of every host that falls inside a LEX policy's scope, once a night, even when several organisations have the same host in scope; each of them gets its own result from that single run. The scanner leaves the platform's lab network alone. A full host scan usually takes a few hours, and the last few percent of progress stand still for a long time because the scanner is finishing its slow tests; the cockpit shows such a scan in its footer as a background scan, with its running time. A separate cycle pulls the result, and the report gives it a section of its own and counts its findings into the risk level on the cover. When the scanner cannot reach the host, the result reads "not assessed" rather than "zero findings", so a missing result never looks like a clean system. SHIPPED

Configuration

Each channel turns on through an environment variable or an organisation-level entry that lands in the database and loads only at dispatch time, so a single integration never costs you a full platform restart. SHIPPED

API

Powierzchnię API dzielą trzy warstwy dostępu, z których każda ma inny próg zaufania i inne wymagania wobec tego, kto do niej puka.

Publiczne

/api/public/* nie wymaga uwierzytelnienia i ma otwarty CORS. Tu znajdziesz status komponentów oraz dane, które CYRBER pokazuje na zewnątrz bez logowania. MAMY

X-Proof-Key

/api/proof/verify/* i /api/proof/feed wymagają nagłówka X-Proof-Key, imiennego klucza audytora z datą ważności. To ścieżka dla kogoś, kto ma sprawdzić dowód, a nie zarządzać kontem. Pełny opis znajdziesz w rozdziale Weryfikacja publiczna. MAMY

Bearer i cookie

Reszta API stoi za sesją operatora: ciasteczko HTTP-only jako pierwszy wybór, nagłówek Bearer jako zapasowy oraz klucz API (X-API-Key) dla integracji maszyna-maszyna. MAMY

Status publiczny

GET /api/public/status zwraca migawkę zdrowia ośmiu komponentów, złożoną w jeden wynik po najgorszym przypadku, i trzyma ją w cache 30 sekund, żeby nie obciążać bazy przy każdym zapytaniu. Ten sam status napędza status.cyrber.com. MAMY

curl https://api.cyrber.com/api/public/status

Przykładowa odpowiedź. Przy schedulerze latency_ms to odstęp między kolejnymi cyklami jego pętli, a nie czas odpowiedzi widziany przez użytkownika, więc wyższa wartość jest tu normalna.

{
  "generated_at": "2026-07-18T09:12:00Z",
  "overall": "operational",
  "components": [
    {"name": "api", "status": "operational"},
    {"name": "database", "status": "operational", "latency_ms": 4.2},
    {"name": "redis", "status": "operational", "latency_ms": 1.1},
    {"name": "scheduler", "status": "operational", "latency_ms": 812.5},
    {"name": "llm-router", "status": "operational"},
    {"name": "glass-house-verify", "status": "operational"},
    {"name": "matrix-bridge", "status": "operational"},
    {"name": "jitsi", "status": "operational", "latency_ms": 210.4}
  ],
  "incidents": [],
  "maintenance": []
}

Dokumentacja API

Interaktywny Swagger oraz surowy openapi.json pod generatory kodu klienta budują się z tras FastAPI, natomiast w trybie produkcyjnym wyłączamy je z rozmysłu, żeby nie wystawiać powierzchni na zewnątrz, dlatego publiczny api.cyrber.com/docs odpowiada dziś 404. Klient on-prem włącza je u siebie jedną zmienną środowiskową (CYRBER_ENV na wartość inną niż production), po czym /docs, /redoc i /openapi.json stają się dostępne w jego instancji. MAMY

API

Three access tiers, each with its own trust threshold and its own demands on whoever knocks.

Public

/api/public/* needs no authentication and runs open CORS. Component status and anything CYRBER shows to the outside world without a login live here. SHIPPED

X-Proof-Key

/api/proof/verify/* and /api/proof/feed require an X-Proof-Key header, a personal auditor key with an expiry date. This tier is for someone checking a proof, not managing an account. Full detail sits in the Public verification chapter. SHIPPED

Bearer and cookie

Everything else runs behind an operator session: an HTTP-only cookie first, a Bearer header as fallback, and an API key (X-API-Key) for machine-to-machine integrations. SHIPPED

Public status

GET /api/public/status returns a health snapshot of eight components, rolled up to a single worst-case reading, and caches it for 30 seconds so a poll does not hit the database every time. The same status feeds status.cyrber.com. SHIPPED

curl https://api.cyrber.com/api/public/status

Example response. For the scheduler, latency_ms is its beat-loop tick, not a user-facing response time, so a higher value there is normal.

{
  "generated_at": "2026-07-18T09:12:00Z",
  "overall": "operational",
  "components": [
    {"name": "api", "status": "operational"},
    {"name": "database", "status": "operational", "latency_ms": 4.2},
    {"name": "redis", "status": "operational", "latency_ms": 1.1},
    {"name": "scheduler", "status": "operational", "latency_ms": 812.5},
    {"name": "llm-router", "status": "operational"},
    {"name": "glass-house-verify", "status": "operational"},
    {"name": "matrix-bridge", "status": "operational"},
    {"name": "jitsi", "status": "operational", "latency_ms": 210.4}
  ],
  "incidents": [],
  "maintenance": []
}

Reference

The interactive Swagger and a raw openapi.json for client codegen are built from the FastAPI routes, yet in production we disable them on purpose, to keep that surface off the public edge, which is why api.cyrber.com/docs answers 404 today. An on-prem customer turns them on with a single environment variable (CYRBER_ENV set to anything other than production), after which /docs, /redoc and /openapi.json become available in their own instance. SHIPPED

Dlaczego organizm

Cerber strzeże granicy między światami i ma trzy głowy, żeby nie mieć martwego pola. Jedna pamięta każdego, kto już przekroczył próg, druga patrzy na tego, kto stoi u bramy teraz, trzecia wypatruje tego, kto dopiero nadchodzi. Nazwa CYRBER bierze się właśnie stąd, bo jak Cerber pilnuje trzech czasów naraz.

Motto Videt omnia. Meminit omnia. Iudicat omnia. rozkłada się na te trzy czasy: MEMINIT trzyma przeszłość, VIDET teraźniejszość, IUDICAT przyszłość. To warstwa znaczenia, a nie etykiety podzespołów, ponieważ anatomicznie realizują ją trzy głowy rozumowania, czyli RATIO, ANIMUS i FATUM, wsparte pięcioma filarami opisanymi niżej.

Agent czeka na polecenie, wykonuje je i milknie, a kiedy skończy, zapomina. Organizm żyje dalej: nosi pamięć poprzednich starć w korpusie LIBER i w łańcuchu pieczęci, czuwa przez VIGIL, choć nikt mu nie kazał, i osądza przyszłość przez FATUM oraz ANNALES. Dlatego dokumentacja nie opisuje CYRBER jako agenta, bo agent to jeden narząd, a nie cały ustrój.

Precyzyjnie rzecz ujmując, agentem jest silnik rozumowania MENS, który prowadzi misję przez cykl OBSERVE, THINK, ACT, LEARN. Wokół niego stoją narzędzia rozpoznania i ataku, pamięć zapieczętowana kryptograficznie, pętla samosprawdzająca oraz ludzie, bez których żadne uderzenie nie ruszy, ponieważ to operator daje zgodę, a dyrektor bezpieczeństwa akceptuje działanie o realnym skutku. Sztuczna inteligencja jest tu jednym z narządów, nie całą istotą, i tak też ją opisujemy.

Why an organism

Cerberus guards the border between worlds and has three heads so that nothing escapes him. One remembers everyone who already crossed the threshold, the second watches whoever stands at the gate now, the third looks out for whoever is yet to come. The name CYRBER comes from exactly there, because this is no scanner fired on demand, but a guard watching three tenses at once.

The motto Videt omnia. Meminit omnia. Iudicat omnia. maps onto those three tenses precisely: MEMINIT holds the past, VIDET the present, IUDICAT the future. This is a layer of meaning rather than a set of component labels, because anatomically it is carried out by the three heads of reasoning, RATIO, ANIMUS and FATUM, supported by the five pillars described below.

An agent waits for an order, carries it out and falls silent, and once it is done, it forgets. An organism lives on: it carries the memory of earlier encounters in the LIBER corpus and in the chain of seals, it watches through VIGIL although nobody told it to, and it judges the future through FATUM and ANNALES. This is why these docs do not describe CYRBER as an agent, because an agent is one organ and not the whole body.

To be precise, the agent here is the MENS reasoning engine, which runs a mission through the OBSERVE, THINK, ACT, LEARN cycle. Around it stand recon and attack tooling, cryptographically sealed memory, a self-auditing loop, and people without whom no strike moves at all, because the operator grants consent and the security director signs off on anything with real impact. Artificial intelligence is one organ here, not the whole being, and that is how we describe it.

Filozofia

Łacina kompresuje pojęcie w jedno słowo i nie pozwala marketingowi go rozmyć. MENS to umysł, SPECULUM zwierciadło, TESTIMONIUM świadectwo, ANNALES kroniki, UMBRA cień. Trzymamy się tych nazw, a pierwsze użycie tłumaczy ich sens.

Pod tymi nazwami stoi pięć zasad, z których żadna nie jest metaforą doklejoną dla efektu, ponieważ każda pokrywa się z konkretnym miejscem w kodzie.

Rozumowanie biegnie na bieżąco. Silnik MENS, czyli agentowy narząd organizmu, prowadzi misję tak, że na każdej iteracji przechodzi cykl OBSERVE, THINK, ACT, LEARN i sam decyduje o następnym ruchu. Operator nie pisze playbooków pod cel; obserwuje rozumowanie i pieczętuje wnioski. MAMY

Organy mają puls, bo potrafią zasnąć. Niezmiennik I-9 jest jednoznaczny: każdy z 19 unikalnych komponentów, czyli dwunastu organów, pięciu filarów i dwóch głów (trzecia głowa, FATUM, jest zarazem organem, więc puls liczy ją raz), musi wysłać puls w ciągu doby, a komponent, który milczy dłużej, uznajemy za niedziałający. Puls jest przy tym mechanizmem utrzymania: organizm sam melduje, który komponent przestał działać, zanim ktoś to zauważy. MAMY

Filary żywią się nawzajem w łańcuchu. Kiedy misja MENS się domyka, rusza łańcuch hooków: SPECULUM liczy genom, TESTIMONIUM zakłada pieczęć, UMBRA odświeża blueprint środowiska, ANNALES stawia prognozę, CORTEX mierzy trafność, dalej FATUM, COMES, LIBER i ITERUM. Filary tworzą łańcuch pokarmowy: każdy zjada wynik poprzedniego, a po sukcesie bije własny puls. MAMY

Sygnał jednego organu uruchamia łuk odruchowy. Capability bus jest układem nerwowym: 336 zdolności w jednym rejestrze, a szyna organism_feedback przenosi zdarzenia między organami. Kaskady biegną wieloma hopami, ponieważ exploit_available budzi risk_spike, ten z kolei wywołuje drift_detected, a następnie dimension_stale, aż decide_and_act zamyka odruch, a autonomiczny krok pieczętuje liść w TESTIMONIUM, co w sumie daje do sześciu hopów od bodźca aż do dowodu. MAMY

Autonomia to pokrętło, nie przełącznik. Operator nie wybiera między trybem ręcznym a w pełni automatycznym, lecz kręci pokrętłem po macierzy klas ryzyka i ustawia, co system robi samodzielnie, co wymaga zgody, a co zostaje zablokowane, a jest to wola świadoma, sprawowana pod prawem LEX oraz pod polityką zapisaną osobno dla każdego celu. MAMY

Tych pięć zasad składa się w jedną tezę. Jedna rządzona pętla, od polowania po zapieczętowany werdykt: realna eksploatacja, zamknięcie luki w detekcji na własnym SIEM-ie klienta, kryptograficznie zapieczętowany dowód wspierający raportowanie testów odporności cyfrowej pod DORA, oraz praca w murach klienta. Platforma, baza wyników i dowody stoją u klienta już dziś. Do modelu w chmurze trafiają domyślnie prompty rozumowania MENS i narracji raportu, a przed wysłaniem maskujemy w nich publiczne adresy IP i nazwy hostów (szczegóły w rozdziale Model rozumowania). W trybie air-gap rozumowanie działa na lokalnym modelu, a tryb ustawiasz dla organizacji MAMY. Pełny obraz akt po akcie znajdziesz w rozdziale Rytuał misji. CYRBER każe weryfikować zamiast wierzyć na słowo, więc tę samą miarę stosujemy do dokumentacji: każda zasada wskazuje miejsce w kodzie, a znaczniki MAMY i DOŁOŻYMY oddzielają to, co już bije, od tego, co dopiero powstaje.

Philosophy

Latin compresses a concept into a single word and keeps marketing from watering it down. MENS is the mind, SPECULUM the mirror, TESTIMONIUM the witness, ANNALES the chronicles, UMBRA the shadow. The docs keep these names throughout, and every first use spells out what it means.

Five rules sit under those names, and none of them is a metaphor glued on for effect, because each maps to a specific place in the code.

Reasoning happens during the run. The MENS engine, the agentic organ of the organism, runs a mission so that on every iteration it walks OBSERVE, THINK, ACT, LEARN and picks its own next move. The operator writes no per-target playbook, but instead watches the reasoning and seals the conclusions. SHIPPED

Organs carry a pulse because they can fall asleep. Invariant I-9 is unambiguous: each of the 19 unique components, twelve organs, five pillars and two heads (the third head, FATUM, is also an organ, so the pulse counts it once), must emit a pulse within a day, and one that stays quiet longer counts as down. The pulse is a maintenance mechanism: the organism reports on its own which component stopped working, before anyone notices. SHIPPED

The pillars feed on one another in a chain. When a MENS mission closes, a hook chain fires: SPECULUM scores the genome, TESTIMONIUM sets the seal, UMBRA refreshes the twin, ANNALES casts the forecast, CORTEX measures accuracy, then FATUM, COMES, LIBER and ITERUM. The pillars form a food chain: each consumes the previous result, and each beats its own pulse once it succeeds. SHIPPED

One organ's signal fires a reflex arc. The capability bus is the nervous system: 336 capabilities in a single registry, with the organism_feedback bus carrying events between organs. Cascades run many hops deep: exploit_available wakes risk_spike, which trips drift_detected, then dimension_stale, until decide_and_act closes the loop and the autonomous step seals a leaf in TESTIMONIUM, which comes to as many as six hops from stimulus to proof. SHIPPED

Autonomy is a dial, not a switch. The operator does not pick between manual and fully automatic, but turns a dial across a matrix of risk classes, setting what the system does alone, what needs consent and what stays blocked, and that is deliberate will, exercised under the LEX policy engine and under a policy recorded per target. SHIPPED

The five rules resolve into one thesis: a single governed loop, running from the hunt to a sealed verdict, with real exploitation, the detection gap closed on the client's own SIEM, a cryptographically sealed proof that supports digital-resilience test reporting under DORA, and work inside the client's walls. The platform, the results database and the proofs already sit at the client. By default the MENS reasoning prompts and the report narrative go to a cloud model, and before they are sent we mask the public IP addresses and hostnames in them (details in The reasoning model chapter). In air-gap mode the reasoning runs on a local model, and you set the mode per organisation: SHIPPED. The full act-by-act picture waits in the Mission ritual chapter. CYRBER tells you to verify rather than take its word, so we hold these docs to the same standard: every rule points at a place in the code, and the SHIPPED and PLANNED markers separate what already runs from what is still being built.

Anatomia

Anatomy

Organizm ma anatomię, którą policzysz na żywo, ponieważ kafle wyżej biją własnym tętnem, obejmując moduły skanujące, zdolności na szynie oraz grupy zdolności, a te trzy rejestry składają się na całość. Pięć filarów niesie kręgosłup rozumowania, dwanaście organów utrzymuje i osądza, a trzy głowy dzielą atak po domenie, przy czym wszystko spina Capability Bus.

Pięć filarów

Filary tworzą kolumnę kręgową, z której każdy trzyma jeden wymiar misji i ma swoje miejsce w kodzie.

Dwanaście organów

Organy utrzymują organizm i pilnują osądu, a każdy z nich robi jedną, ściśle wyznaczoną rzecz.

• VIGIL trzyma ciągły monitoring powierzchni.
• MEDICUS proponuje, weryfikuje i w razie potrzeby wycofuje naprawy, a przy okazji odzyskuje uszkodzone usługi.
• CORTEX rozpoznaje wzorce i uczy się z misji.
• AUDIT prowadzi kryptograficzny łańcuch audytu.
• FORUM prowadzi przepływ postulatów i decyzji.
• LEX egzekwuje zakres i politykę.
• AURUM śledzi koszt tokenów LLM i ekspozycję ryzyka biznesowego w euro.
• TESTIS zaświadcza i weryfikuje każdy krok, żeby dowód dało się sprawdzić także później.
• FATUM przewiduje, jak ryzyko rozłoży się w czasie i kiedy exploit stanie się dostępny.
• COMES towarzyszy misji i porządkuje kolejkę.
• LIBER pamięta jako korpus instytucjonalny.
• ITERUM odtwarza i wariantuje przebyte misje.

Cała dwunastka jest obecna i wpięta, trzymana pod naszym rygorem ALIVE. MAMY

Trzy głowy

Głowy dzielą atak według domen, przy czym one same jedynie planują, natomiast nad wykonaniem czuwa już MENS.

Szyna zdolności

Bus jest fundamentem, a nie kolejnym organem ani filarem, ponieważ stanowi jeden płaski rejestr zdolności, po którym rozmawiają ze sobą filary, organy i głowy. Każda zdolność niesie scope (owner, admin, operator, client), wpis w audit logu, opcjonalną zgodę przez HMAC lub bramkę MFA i udokumentowany pendant defensywny, czyli odpowiednik mówiący, jak SPECULUM albo UMBRA to samo wykrywa lub odzwierciedla. Liczbę zdolności, modułów i grup zobaczysz w kaflach wyżej, liczone na żywo. MAMY

Kiedy komponent jest żywy

Nasz rygor ALIVE stawia trzy warunki naraz, a samo istnienie pliku nie liczy się do niczego. Po pierwsze kod musi wywoływać produkcja, a sam import modułu nie wystarcza. Po drugie test end-to-end musi przechodzić tę samą ścieżkę i kończyć się sukcesem w pełnym zestawie testów. Po trzecie działanie musi mieć opisany odpowiednik obronny. Gdy brakuje choćby jednego warunku, nazywamy stan wprost: wpięty bez testu, uśpiony (wyłączony w konfiguracji), niewpięty albo szkielet. To właśnie ten rygor utrzymuje organizm w uczciwości, ponieważ żywotność liczy się co dobę, a komponent, który milczy dłużej niż dobę, uznajemy za niedziałający. MAMY

The organism has an anatomy you can count live, because the tiles above beat with their own pulse across scan modules, capabilities on the bus and capability groups, and those three registers make up the whole. Five pillars carry the spine of reasoning, twelve organs keep it running and judging, and three heads split the attack by domain, with the Capability Bus wiring them together.

Five pillars

The pillars are the backbone. Each holds one dimension of a mission and has its own place in the code.

Twelve organs

The organs keep the body running and guard its judgement, and each of them does one strictly assigned thing.

• VIGIL watches the surface without pause.
• MEDICUS proposes, verifies and, when needed, rolls back fixes, and recovers broken services along the way.
• CORTEX recognises patterns and learns from missions.
• AUDIT keeps the cryptographic audit chain.
• FORUM runs the request and decision flow.
• LEX enforces scope and policy.
• AURUM tracks LLM token cost and business-risk exposure in EUR.
• TESTIS witnesses and verifies each step, so the proof can be checked later too.
• FATUM predicts how risk unfolds over time and when an exploit becomes available.
• COMES rides with the mission and orders its queue.
• LIBER remembers as an institutional corpus.
• ITERUM replays and varies past missions.

All twelve are present and wired, held to our ALIVE bar. SHIPPED

Three heads

The heads split the attack by domain. They plan; MENS owns the execution.

The Capability Bus

The bus is the foundation, not another organ or pillar. It is a single flat registry of capabilities that pillars, organs and heads all speak through. Every capability carries a scope (owner, admin, operator, client), an audit-log entry, optional consent via HMAC or an MFA gate, and a documented defensive counterpart, which says how SPECULUM or UMBRA detects or reflects the same thing. The count of capabilities, modules and groups sits in the tiles above, computed live. SHIPPED

When a component is alive

Our ALIVE bar sets three conditions at once, and a file simply existing counts for nothing. First, production has to call the code; importing the module is not enough. Second, an end-to-end test has to run the same path and pass in the full test suite. Third, the action needs a documented defensive counterpart. If any one is missing, we name the state plainly: wired but untested, dormant (switched off in configuration), unwired or skeleton. This rigour keeps the organism honest. Liveness is counted every day, and a component silent for more than a day counts as down. SHIPPED

Rytuał misji

Cała praca organizmu układa się w jeden rytuał pięciu aktów. To rdzeń całego CYRBER: jedna rządzona pętla od polowania po zapieczętowany werdykt. Część aktów już bije pełnym tętnem, część dopiero dokładamy, co oznaczamy wprost, akt po akcie.

1 · Puls

Akt czuwania. VIGIL trzyma baseline powierzchni, niezmiennik I-9 liczy żywotność 19 komponentów, a stały harmonogram skanów wyznacza rytm pracy. Zanim zacznie się polowanie, organizm już wie, co ma pod ręką i co usnęło. MAMY

2 · Polowanie

Akt rozumowania. MENS iteruje pętlę i dysponuje modułami skanującymi głowy RATIO pod prawem LEX, celując w realny dostęp, nie w samą listę podatności. Flotą celów rządzi pokrętło autonomii, a każdy cel niesie własny postulat zakresu. MAMY

3 · Pojedynek

Akt konfrontacji. CYRBER uruchamia realną eksploatację modułami ofensywnymi (loot z głowy RATIO oraz Sliver z głowy ANIMUS), a wynik trafia na własny SIEM klienta, obsługiwany konektorem (Wazuh, Splunk, QRadar albo Microsoft Sentinel), z opcjonalnym stackiem Wazuh dla on-prem bez SOC, żeby domknąć luki detekcji. To purple w czystej postaci: atak i obrona uczą się na tym samym zdarzeniu. Domyślnie dowodzimy dostępu, nie skutku, ponieważ sama eksploatacja pokazuje, że łańcuch da się przejść, a ekstrakcję danych włącza dopiero osobny tryb impact, który przechodzi przez pięć bramek naraz, od licencji i polityki LEX po autoryzację klienta oraz zgodę na każdy krok. Konektor SIEM (Wazuh, Splunk, QRadar, Microsoft Sentinel), siedmiodniowa miara wykrywalności oraz domyślny dowód dostępu z bramkowanym trybem impact MAMY. Gotowy stack Wazuh dla on-prem bez SOC oraz dwupanelowy widok purple spięty w jeden rytuał DOŁOŻYMY.

4 · Werdykt

Akt świadectwa. TESTIMONIUM pieczętuje dowód drzewem Merkle oraz kotwicą OpenTimestamps w łańcuchu Bitcoina, a werdykt zmapowany na zgodność, podpisany kluczem Ed25519, trafia do zapieczętowanego PDF. Paczka dowodowa układa pieczęcie i dowód dostępu jako materiał na zamknięcie testów odporności wymaganych przez DORA. Test prowadzi uprawniony niezależny zespół, a my dostarczamy dowód, który sprawdzisz offline. Ponowny test po poprawce, który sam zamyka zgłoszenie, jest w planie. Łańcuch pieczęci i PDF zgodności MAMY. Paczka dowodowa z publicznym weryfikatorem w pliku ZIP MAMY, a zamknięcie zgłoszenia po ponownym teście to DOŁOŻYMY.

5 · Pamięć

Akt uczenia. Po misji łańcuch hooków karmi organizm: LIBER indeksuje do korpusu instytucjonalnego, CORTEX mierzy trafność, ANNALES odświeża prognozę, ITERUM przygotowuje replay. Organizm pamięta misję i wraca do niej mądrzejszy. MAMY

Tych pięć aktów tworzy jedną pętlę, którą sterujesz pokrętłem, którą udowodnisz regulatorowi i która w całości należy do klienta. Suwerenność, czyli on-prem i lokalny model LLM, sprawia, że dane i przebieg zostają u klienta. Jak działa dowód dla sceptyka, opisuje rozdział Glass House; skąd bierze się wykrywalność zmian, rozdział Suwerenność. Aspiracje z aktów Pojedynek i Werdykt oznaczamy DOŁOŻYMY, żeby było jasne, co należy do planu, a co już bije.

Mission ritual

Everything the organism does resolves into one ritual of five acts. This is the core of CYRBER: a single governed loop from the hunt to a sealed verdict. Some acts already beat at full pulse; some we are still building, and we say which is which, act by act.

1 · Pulse

The act of watching. VIGIL holds a baseline of the surface, invariant I-9 counts the liveness of 19 components, and a fixed scan schedule sets the pace. Before the hunt begins, the organism already knows what it has to hand and what has gone quiet. SHIPPED

2 · Hunt

The act of reasoning. MENS iterates its loop and dispatches the RATIO head's scan modules under the LEX policy engine, aiming at real access rather than a bare list of vulnerabilities. The autonomy dial governs the fleet of targets, and each target carries its own scope request. SHIPPED

3 · Duel

The act of confrontation. CYRBER runs real exploitation through its offensive modules (loot from the RATIO head and Sliver from the ANIMUS head), and the result lands on the client's own SIEM via a connector (Wazuh, Splunk, QRadar or Microsoft Sentinel), with an optional Wazuh stack for on-prem without a SOC, to close the detection gap. This is purple in its pure form: attack and defence learn from the same event. By default we prove access, not impact, because the exploitation itself shows the chain can be walked, while data extraction turns on only through a separate impact mode that passes five gates at once, from the licence and the LEX policy to the client's authorisation and consent on every step. The SIEM connector (Wazuh, Splunk, QRadar, Microsoft Sentinel), the seven-day detection measurement and the default proof-of-access with a gated impact mode are SHIPPED. A ready-made Wazuh stack for on-prem without a SOC and a two-panel purple view fused into one ritual are PLANNED.

4 · Verdict

The act of witness. TESTIMONIUM seals the proof with a Merkle tree and an OpenTimestamps anchor on the Bitcoin chain, and the compliance-mapped verdict, signed with an Ed25519 key, lands in a sealed PDF. An evidence pack lays out the seals and the proof of access as material for the close of the resilience tests DORA requires. An authorised independent team runs the test and we supply the proof, which you can check offline. A retest after the fix, which closes the ticket on its own, is planned. The seal chain and compliance PDF are SHIPPED. An evidence pack with the public verifier inside the ZIP export is SHIPPED, while closing the ticket after a retest is PLANNED.

5 · Memory

The act of learning. Once a mission closes, the hook chain feeds the organism: LIBER indexes into the institutional corpus, CORTEX measures accuracy, ANNALES refreshes the forecast, ITERUM prepares a replay. The organism remembers the mission and comes back to it wiser. SHIPPED

These five acts are one loop. You steer it with a dial, you can prove it to a regulator, and it belongs to the client in full. Sovereignty, meaning on-prem plus a local LLM, keeps the data and the run at the client. The Glass House chapter shows how the proof works for a sceptic, and the Sovereignty chapter shows where the tamper evidence comes from. We mark the aspirations in the Duel and Verdict acts as PLANNED, so it stays clear which parts belong to the plan and which already run.

Samoleczenie

Samodoskonalenie w CYRBER dzieje się na trzech poziomach naraz: organizm naprawia własny stan działania, wyciąga wnioski z każdej zamkniętej misji oraz pilnuje, żeby jego własny opis samego siebie pozostawał prawdziwy. Nie kończy więc pracy na samym wykryciu usterki, lecz zauważa ją, naprawia, zapamiętuje płynący z niej wniosek, a tę samą pętlę domyka na dokumentacji, którą właśnie czytasz.

Jak się naprawia

Jak się uczy

Jak leczy się ta dokumentacja

Ta strona podlega tej samej zasadzie. Liczby i statusy, które tu widzisz, nie są przepisane ręcznie, lecz renderują się z żywego API organizmu, dzięki czemu nie zestarzeją się po cichu. Nad samą prozą czuwa strażnik dryfu, ponieważ każde twierdzenie, oznaczone jako MAMY albo DOŁOŻYMY, trzyma kotwicę w konkretnym miejscu kodu, którą sprawdzasz przyciskiem „udowodnij”, a nocny przebieg weryfikuje, czy kod wciąż to twierdzenie potwierdza, i robi to na trzech warstwach: czy pliki, symbole oraz endpointy z kotwicy nadal istnieją, czy liczby zgadzają się z API, a wreszcie czy sam sens twierdzenia trzyma się kodu. Gdy organizm wyprzedzi opis, strażnik sam zakłada zgłoszenie w GitHubie z konkretem, tym samym trybem, którym self-test już dziś zamyka zgłoszenia po naprawie, i sam je domyka, gdy proza wróci do prawdy. To Glass House przyłożony do dokumentu: nie każemy Ci wierzyć, że opis pozostaje aktualny, lecz utrzymujemy mechanizm, który tę aktualność wymusza. Żywe fakty z API oraz strażnika dryfu prozy MAMY.

Te trzy poziomy, naprawa stanu, nauka z misji oraz uczciwość własnego opisu, składają się na jedną ideę: system, który sam utrzymuje się w dobrym stanie, a każdy taki krok zostawia ślad, który możesz sprawdzić.

Self-healing

Self-improvement in CYRBER runs on three levels at once: the organism repairs its own running state, draws lessons from every mission that closes, and keeps its own account of itself true. It therefore does not stop at spotting a fault, but notices it, repairs it and keeps the lesson, and then the same loop closes on the documentation you are reading now.

How it repairs itself

How it learns

How this documentation heals

This page lives by the same rule. The numbers and statuses you see here are not typed in by hand. They render from the organism's live API, so they cannot age in silence. A drift guard watches the prose itself, because every claim, marked SHIPPED or PLANNED, holds an anchor at a specific place in the code that you check with the "prove it" button, and a nightly run verifies that the code still bears the claim out, across three layers: whether the files, symbols and endpoints from the anchor still exist, whether the numbers match the API, and finally whether the meaning of the claim still holds against the code. When the organism runs ahead of the description, the guard opens a GitHub issue with the specifics, by the same route the self-test already uses to close issues after a repair, and closes it again once the prose returns to the truth. This is the Glass House turned on a document: a mechanism keeps the description current and flags the moment it drifts. Live facts from the API and the prose drift guard are SHIPPED.

These three levels, repairing the state, learning from missions and keeping its own account honest, make one idea: a system that does not merely run but keeps setting itself right, and every such step leaves a trace you can check.

Glass House

CYRBER daje dowód, który sprawdzisz samodzielnie, bez najmniejszego wglądu w jego bazę.

Pieczęć

Każde znalezisko dostaje zobowiązanie HMAC-SHA256 z solą organizacji, po czym liście łączą się parami w drzewo Merkle, a ponieważ zmiana choćby jednego znaku w jednym znalezisku rozsypuje root tego drzewa, każda podmiana zostaje natychmiast widoczna. Korzeń drzewa podpisujemy kluczem Ed25519, a datę pieczęci potwierdza kotwica opisana niżej. MAMY

Kotwica

Korzeń drzewa znalezisk każdej misji oraz hash dziennego snapshotu kotwiczymy w bloku łańcucha Bitcoina przez OpenTimestamps. Zmiana historii wymagałaby przepisania bloków Bitcoina, co od razu byłoby widoczne. MAMY

Weryfikacja bez zaufania

Pojedyncze znalezisko audytor sprawdza przez API z kluczem audytora: serwer przechodzi ścieżkę Merkle aż do korzenia, co kosztuje O(log N) kroków, a nie kopię całej bazy. Pieczęć całej misji sprawdzi bez naszego serwera, z pakietu audytora i klucza publicznego, jak opisuje rozdział Weryfikacja publiczna. MAMY

Łańcuch pieczęci

Łańcuch pieczęci trzyma pieczęcie kolejnych misji, jedna za drugą. Liczba pieczęci rośnie z każdą zamkniętą misją: 1513. MAMY

Paczka dowodowa

Paczka dowodowa składa w jeden plik pieczęcie, zamknięte reguły wykrywania i dowód dostępu. Służy jako materiał na zamknięcie testów odporności wymaganych przez DORA. Test prowadzi uprawniony zespół, a my dostarczamy dowód. Publiczny weryfikator jedzie w pliku ZIP i sprawdza dowód offline, bez naszej bazy. MAMY

Stąd bierze się zasada, którą trzymamy tu i w produkcie: masz sprawdzić werdykt, a nie zawierzyć mu. To decyzja architektoniczna, która przesądziła, jak wygląda każda pieczęć. Skąd bierze się nienaruszalność u klienta, mówi rozdział Suwerenność.

Glass House

CYRBER gives you a proof that you can check without looking into its database.

The seal

Every finding gets an HMAC-SHA256 commitment with the organisation's salt. The leaves join in pairs into a Merkle tree. Change one character in one finding and the tree's root falls apart, so tampering stays visible. We sign the tree's root with an Ed25519 key, and the anchor described below confirms the date of the seal. SHIPPED

The anchor

We anchor each mission's Merkle root and the hash of the daily snapshot into a Bitcoin block through OpenTimestamps. To rewrite history, you would have to rewrite the blocks, and nobody does that quietly. SHIPPED

Verification without trust

An auditor checks a single finding through the API with an auditor key: the server walks the Merkle path to the root, which takes O(log N) steps, not a copy of the database. They check the whole mission's seal without our server, from the auditor bundle and the public key, as the Public verification chapter describes. SHIPPED

The seal chain

The seal chain holds the seals of successive missions, one after another. The count grows with every mission that closes: 1513. SHIPPED

The evidence pack

The evidence pack puts the seals, the closed detection rules and the proof of access into one file. It is material for the close of the resilience tests DORA requires. An authorised team runs the test and we supply the proof. The public verifier travels in the ZIP file and checks the proof offline, without our database. SHIPPED

This is where the rule we keep here and in the product comes from: verify the verdict, do not trust it. It is an architectural decision that shaped every seal, not a marketing line. Where the tamper-resistance comes from at the client's site is the Sovereignty chapter.

Ludzie

Napastnik rzadko zaczyna od portu, częściej od wiadomości, więc zespół jest powierzchnią ataku tak samo jak serwer, tyle że nikt go nie skanuje nmapem. CYRBER traktuje ten obszar jedną pętlą: mierzy odsłonięcie konkretnych odbiorców, kieruje szkolenie najpierw do najbardziej narażonych, a wynik zamyka rekordem zgodności, który da się przedłożyć audytorowi.

Kampanie i phishing

SUASOR, czyli miara odsłonięcia

SUASOR zamienia przebieg kampanii w liczbę na osobę. Punktacja odsłonięcia bierze najdalszy osiągnięty etap, impulsywność kliknięcia oraz bierną obecność w otwartych źródłach, a wynik rośnie wraz z narażeniem, więc czyta się go tak samo jak poziom ryzyka. Sam mechanizm jest deterministyczny i pozbawiony wejścia z sieci, dzięki czemu ten sam materiał zawsze daje ten sam wynik, co ma znaczenie, gdy rozmawiasz o ludziach, a nie o hostach. Każde działanie wobec pracownika wymaga zgody organizacji, a propozycje czekają na zatwierdzenie, zanim cokolwiek wyjdzie na zewnątrz. MAMY

LUDUS, czyli szkolenie zakończone dowodem

Pracownik dostaje link, który działa bez logowania i bez zakładania konta, ponieważ próg wejścia decyduje o tym, czy ćwiczenie w ogóle się odbędzie. Po drugiej stronie czeka krótki dryl osadzony w realiach jego roli, a nie kurs ogólny dla wszystkich. Wynik liczy się deterministycznie, więc ocena nie zależy od humoru modelu językowego, a na końcu powstaje imienny certyfikat z identyfikatorem, którego autentyczność sprawdzisz po samym identyfikatorze. Ty dostajesz rekord, który dokumentuje realizację obowiązku szkoleniowego z NIS2 i DORA. MAMY

Te cztery elementy tworzą jedną pętlę: kampania wskazuje osoby najbardziej odsłonięte, szkolenie trafia najpierw do nich, kolejny pomiar pokazuje, czy coś się zmieniło, a całość zostawia ślad, który obroni się przed audytorem.

People

An attacker rarely starts at a port and usually starts at a message, so your team is an attack surface exactly as a server is, except nobody scans it with nmap. CYRBER treats this ground as one loop: it measures the exposure of specific recipients, sends training to the most exposed first, and closes the result with a compliance record you can put in front of an auditor.

Campaigns and phishing

SUASOR, the measure of exposure

SUASOR turns a campaign run into a number per person. The footprint score takes the furthest stage reached, the impulsivity of the click and passive presence in open sources, and it rises with exposure, so it reads the same way a risk level does. The mechanism itself is deterministic and performs no network I/O, so the same material always yields the same score, which matters when the subject is a person rather than a host. Every action aimed at an employee needs the organisation's consent, and proposals wait for approval before anything leaves the building. SHIPPED

LUDUS, training that ends in proof

The employee gets a link that works without a login and without creating an account, because the entry barrier decides whether the exercise happens at all. On the other side waits a short drill set in the reality of their role, not a general course for everyone. Scoring is deterministic, so the mark does not depend on a language model's mood, and at the end there is a named certificate whose authenticity you check by its identifier alone. You get a record that documents how you met the training duty under NIS2 and DORA. SHIPPED

These four parts form one loop: the campaign points at the most exposed people, training reaches them first, the next measurement shows whether anything changed, and the whole thing leaves a trace that holds up in front of an auditor.

Sondy brzegowe

Część sieci nie jest widoczna z miejsca, w którym stoi platforma, ponieważ siedzi za NAT, w odległym oddziale albo w segmencie odciętym od reszty świata celowo. Sonda rozwiązuje to bez otwierania dziury w zaporze: mały appliance w kontenerze albo na komputerze jednopłytkowym sam melduje się do platformy, pobiera zadanie, wykonuje je lokalnie i odsyła wynik.

Sonda działa według tych samych zasad co skan lokalny. Wynik z odległego oddziału wchodzi do tego samego łańcucha dowodowego co skan wykonany lokalnie, a Ty nie musisz w zamian wystawiać żadnego portu na świat.

Edge probes

Part of a network is invisible from wherever the platform stands, because it sits behind NAT, in a distant branch, or in a segment deliberately cut off from the rest of the world. A probe solves that without opening a hole in the firewall: a small appliance in a container or on a single-board computer checks in to the platform on its own, pulls a job, runs it locally and sends the result back.

A probe follows the same rules as a local scan. A result from a distant branch enters the same evidence chain as a scan run locally, and you do not have to expose a single port to the world in return.

Rozpoznanie

Zanim napastnik wybierze narzędzie, zbiera wiedzę, a robi to wyłącznie ze źródeł, do których nie musi się włamywać. CYRBER przechodzi tę samą drogę, żeby pokazać Ci własną organizację oczami kogoś z zewnątrz, wraz z tym, co z tej wiedzy wynika.

Od wiedzy do drogi ataku

Rozpoznanie samo w sobie jest tylko materiałem. Wartość pojawia się, gdy z pojedynczych ustaleń złoży się przejście: otwarta usługa prowadzi do konta, konto do uprawnienia, uprawnienie do danych. Widok ścieżki ataku pokazuje to przejście jako łańcuch, a topologia rysuje sieć tak, jak widzi ją silnik misji, dzięki czemu rozmowa przestaje dotyczyć listy podatności, a zaczyna dotyczyć drogi, którą ktoś realnie przejdzie. MAMY

Reconnaissance

Before an attacker picks a tool they gather knowledge, and they do it purely from sources they never have to break into. CYRBER walks the same road to show you your own organisation through an outsider's eyes, along with what follows from that knowledge.

From knowledge to a path of attack

Reconnaissance on its own is only material. The value appears when single findings compose into a passage: an exposed service leads to an account, the account to a privilege, the privilege to data. The attack path view shows that passage as a chain, and the topology draws the network as the mission engine sees it, so the conversation stops being about a list of vulnerabilities and starts being about the road someone would actually walk. SHIPPED

Widoki i stan

Te same znaleziska wyglądają inaczej z fotela operatora, inaczej z fotela zarządu, a jeszcze inaczej z perspektywy kogoś, kto pyta o zdrowie samej platformy. Zamiast zmuszać wszystkich do jednego ekranu, CYRBER podaje ten sam materiał w kilku ujęciach.

Zdrowie platformy i jej łańcucha dostaw

Osobno stoi pytanie o kondycję samego narzędzia, bo system, który bada bezpieczeństwo, sam bywa celem. Widok zdrowia zbiera podatności zależności, ważność certyfikatów, spójność łańcucha audytowego, stan kopii zapasowych i wynik samoskanowania, natomiast rejestr składników oprogramowania (SBOM w formacie CycloneDX, ekran /sbom dla administratora) mówi, z czego platforma jest zbudowana, i daje się pobrać jako plik dla Twojego zespołu bezpieczeństwa. Nexus dokłada obraz węzłów i strumień zdarzeń, przydatny przy większych wdrożeniach. MAMY

Ćwiczenia przeciwstawne

Do tego dochodzą ujęcia ofensywne, po które sięga się świadomie i pod nadzorem: symulacja przeciwnika obejmująca scenariusz ransomware, starcie modelu z modelem oraz atak przez łańcuch dostaw, a obok osobny warsztat czerwonego zespołu wymierzony w modele językowe, czyli ai-redteam, gdzie model dostaje serię prób obejścia zabezpieczeń i widać, które z nich przechodzą. To narzędzia dla kogoś, kto chce sprawdzić reakcję, a nie tylko listę. MAMY

Views and state

The same findings look one way from an operator's chair, another from the board's, and different again to someone asking about the health of the platform itself. Rather than forcing everyone onto one screen, CYRBER serves the same material in several framings.

Health of the platform and its supply chain

The condition of the tool itself stands apart, because a system that examines security is a target too. The health view gathers dependency vulnerabilities, certificate expiry, audit chain integrity, backup state and self-scan results, while the software bill of materials (an SBOM in CycloneDX format, the /sbom screen for administrators) shows what the platform is built from and downloads as a file for your security team. Nexus adds a picture of nodes and a stream of events, useful in larger deployments. SHIPPED

Adversarial exercises

There are also offensive framings, reached for deliberately and under supervision: an adversary simulation covering a ransomware scenario, model against model, and a supply chain attack, plus a separate red team workbench aimed at language models, the ai-redteam surface, where a model is put through a run of jailbreak attempts and you see which ones get through. These are for someone who wants to test the reaction, not only the list. SHIPPED

Słowniczek

Silnik i głowy

MENS łac. umysł. Silnik rozumowania. Prowadzi misję w pętli: obserwuje, myśli, działa i uczy się.

RATIO łac. rozum. Głowa analityczna z katalogiem modułów skanujących.

ANIMUS łac. wola. Głowa narzędzi, które uruchamiasz tylko po wyrażeniu zgody.

FATUM łac. przeznaczenie. Głowa prognozy: ocenia, jak ryzyko rozłoży się w czasie.

Filary

SPECULUM łac. zwierciadło. Genom bezpieczeństwa, czyli profil obrony w siedmiu wymiarach.

TESTIMONIUM łac. świadectwo. Pieczęć dowodu i mapowanie wyniku na NIS2, DORA, RODO i ISO 27001.

ANNALES łac. kroniki. Historia i prognoza ryzyka na 30, 60 i 90 dni.

UMBRA łac. cień. Migawka powierzchni ataku po każdej misji i model Twojego środowiska.

Organy

VIGIL łac. straż. Ciągły monitoring powierzchni.

MEDICUS łac. lekarz. Proponuje, sprawdza i w razie potrzeby wycofuje naprawy.

CORTEX łac. kora mózgowa. Uczy się z misji i mierzy trafność prognoz.

AUDIT Kryptograficzny łańcuch audytu: kto, co i kiedy uruchomił.

FORUM Postulaty i decyzje. Tu zgłaszasz własne potrzeby.

LEX łac. prawo. Zakres i polityka celu. Nie pozwala wyjść poza zakres.

AURUM łac. złoto. Koszt modelu LLM i ekspozycja ryzyka wyrażona w euro.

TESTIS łac. świadek. Podpisuje i weryfikuje dokumenty zgodności.

COMES łac. towarzysz. Pilnuje misji czekających na zatwierdzenie i ich limitów czasu.

LIBER łac. księga. Pamięć instytucjonalna, czyli sprawdzone sposoby postępowania z poprzednich misji. Poziom autonomii LIBER oznacza z kolei, że system działa samodzielnie w danej klasie ryzyka.

ITERUM łac. ponownie. Porównanie dwóch misji i ich powtórzenie.

Ludzie

SUASOR łac. doradca. Miara odsłonięcia pracowników po ćwiczeniu.

LUDUS łac. szkoła. Szkolenie zakończone imiennym potwierdzeniem.

Widoki

KOKPIT Główny widok misji na żywo.

Theatrum Przebieg misji krok po kroku, z rozumowaniem.

Nexus Obraz węzłów i strumień zdarzeń przy większych wdrożeniach.

CERTAMEN łac. zawody. Publiczna, minutowa gra na zapieczętowanej misji, bez zakładania konta.

Pojęcia

Pieczęć Drzewo Merkle znalezisk z korzeniem podpisanym kluczem Ed25519, opcjonalnie z kotwicą OpenTimestamps.

Glass House CYRBER pokazuje publicznie własne wyniki i pozwala je sprawdzić na trust.cyrber.com.

Tryb air-gap Rozumowanie na lokalnym modelu w Twojej sieci, bez żadnych wyjść na zewnątrz.

Puls Sygnał życia komponentu. Brak pulsu dłużej niż dobę oznacza, że komponent stoi.

MAMY / DOŁOŻYMY Oznaczenia przy twierdzeniach w dokumentacji: działa dziś albo jest w planie.

Pakiety SPECULATOR (obserwator), EXCUBITOR (strażnik), HARUSPEX (wróżbita), PRAEFECTUS (dowódca).

Glossary

Engine and heads

MENS Latin for mind. The reasoning engine. It runs a mission in a loop: observe, think, act and learn.

RATIO Latin for reason. The analytical head with the catalogue of scanning modules.

ANIMUS Latin for will. The head for tools you run only after giving consent.

FATUM Latin for fate. The forecasting head: it estimates how risk will unfold over time.

Pillars

SPECULUM Latin for mirror. The security genome, a defence profile across seven dimensions.

TESTIMONIUM Latin for testimony. The proof seal and the mapping of results onto NIS2, DORA, GDPR and ISO 27001.

ANNALES Latin for annals. Risk history and a forecast for 30, 60 and 90 days.

UMBRA Latin for shadow. A snapshot of the attack surface after each mission and a model of your environment.

Organs

VIGIL Latin for watch. Continuous monitoring of the surface.

MEDICUS Latin for physician. Proposes, checks and if needed rolls back fixes.

CORTEX Latin for cortex. Learns from missions and measures forecast accuracy.

AUDIT The cryptographic audit chain: who ran what and when.

FORUM Requests and decisions. This is where you raise your own needs.

LEX Latin for law. The target's scope and policy. It keeps the system inside the scope.

AURUM Latin for gold. LLM cost and risk exposure expressed in euros.

TESTIS Latin for witness. Signs and verifies compliance documents.

COMES Latin for companion. Watches missions waiting for approval and their time limits.

LIBER Latin for book. Institutional memory, the proven ways of working from earlier missions. The LIBER autonomy level, separately, means the system acts on its own within a given risk class.

ITERUM Latin for again. Comparing two missions and replaying them.

People

SUASOR Latin for adviser. A measure of staff exposure after an exercise.

LUDUS Latin for school. Training that ends with a named confirmation.

Views

KOKPIT Polish for cockpit. The main live view of a mission.

Theatrum A step-by-step view of a mission run, with its reasoning.

Nexus A view of nodes and an event stream for larger deployments.

CERTAMEN Latin for contest. A public one-minute game on a sealed mission, with no account needed.

Terms

Seal A Merkle tree of findings whose root is signed with an Ed25519 key, optionally with an OpenTimestamps anchor.

Glass House CYRBER shows its own results publicly and lets you check them at trust.cyrber.com.

Air-gap mode Reasoning on a local model in your network, with no outbound exits.

Pulse A component's sign of life. No pulse for more than a day means the component is down.

SHIPPED / PLANNED Labels on claims in this documentation: works today, or is planned.

Packages SPECULATOR (observer), EXCUBITOR (sentinel), HARUSPEX (soothsayer), PRAEFECTUS (commander).

Historia zmian

Pełna, bieżąca historia zmian żyje na cyrber.com/zmiany. Ta sekcja odsyła tam celowo: release notes trzymamy poza tym dokumentem, żeby proza tutaj nie starzała się przy każdym wydaniu.

Release notes

The full, current change history lives at cyrber.com/zmiany. This section points there on purpose: we keep release notes outside this document so the prose here does not go stale with every release.

Zapytaj o dokumentację

Ask the documentation