Cyber Katalog

Ponad sto zweryfikowanych firm w ośmiu kategoriach, słownik pojęć i kilkadziesiąt walidatorów pilnujących każdego builda - tyle waży dziś Cyber Katalog, serwis o polskim rynku cyberbezpieczeństwa. Pod cyberkatalog.pl stoi wyszukiwarka firm razem z zapleczem wiedzy: aktualnościami, ofertami pracy, słownikiem i narzędziami. API odpowiada pod api.cyberkatalog.pl, a osobne proxy pod cert.cyberkatalog.pl doprowadza Listę Ostrzeżeń CSIRT NASK.

Skąd biorą się dane

Redakcyjna część katalogu żyje z kanałów RSS, instytucjonalnych i branżowych. Powstają z nich aktualności, zbierane cyklicznie i wiązane z identyfikatorami CVE, bez ręcznego kroku po drodze.

Każdy profil niesie dane rejestrowe. Pochodzą z GUS/REGON oraz z białej listy podatników VAT Ministerstwa Finansów, dociągane po numerze NIP. Osobne, cykliczne zadanie sprawdza, czy firma nadal istnieje w rejestrze, więc katalog nie zbiera martwych wpisów.

Oferty pracy zbierane są automatycznie. Każda zmiana treści oferty zapisuje nową wersję rekordu z odsyłaczem do poprzedniej, po skrócie treści, więc historia oferty nie znika przy edycji.

Frontend, mapa i telefon

Frontend napisany jest w SvelteKit z adapter-static (Svelte 5, Tailwind CSS 4, TypeScript, Vite) i renderuje się w całości statycznie na etapie builda. Cloudflare Workers serwuje gotowe pliki przez Static Assets, a build stoi na Node 24.

Rozmieszczenie firm na mapie obsługuje Leaflet. To jedyne miejsce w interfejsie, gdzie cały katalog widać naraz w układzie geograficznym, a nie w postaci listy z filtrami.

Zaplecze wiedzy domyka słownik. Linkują do jego haseł artykuły i profile narzędzi, więc czytelnik nie musi wychodzić z serwisu, żeby sprawdzić skrót.

Architektura na Cloudflare

Na Cloudflare stoją trzy usługi. Serwis pod cyberkatalog.pl jest w całości prerenderowany i serwowany przez Workers Static Assets. API pod api.cyberkatalog.pl czyta z trzech baz D1, rozdzielonych według rodzaju danych: aktualności, oferty pracy i firmy. Trzecia usługa to proxy Listy Ostrzeżeń CSIRT NASK pod cert.cyberkatalog.pl. Stoi osobno, bo ma inne źródło danych i inny cykl życia niż API firm.

API działa w trybie Smart Placement, z włączoną obserwowalnością. Runtime nie trzyma żadnych sekretów: build jest statyczny, Worker serwuje pliki, a dane idą z API. Im mniej rzeczy potrafi wyciec z runtime, tym mniej trzeba pilnować. Od takiego podziału odpowiedzialności zaczynamy przegląd architektury u klienta.

Harmonogram i pipeline

Cała warstwa danych stoi na zaplanowanych przebiegach GitHub Actions, wyzwalanych cronem. Każde źródło ma własny przebieg i własny harmonogram, rozsunięty względem pozostałych, żeby zadania nie konkurowały o te same zasoby, a awaria jednego źródła nie zatrzymywała reszty. Osobne przebiegi zajmują się utrzymaniem: weryfikacją wpisów w rejestrach, audytem domen i czyszczeniem tego, co wygasło. Ten sam wzorzec zaplanowanych zadań wchodzi u nas w automatyzację procesów.

Nieudany przebieg dowolnego z tych zadań woła na Slacka, więc awaria źródła nie czeka, aż ktoś zajrzy do logów.

Bramki jakości

CI uruchamia się na każdym pull requeście, osobno dla backendu i frontendu. W backendzie walidatory pilnują rzeczy, które łatwo przeoczyć przy ręcznym review: przypięcia akcji GitHuba do konkretnej wersji, pokrycia ponawianiem zapytań do D1, podpięcia migracji D1 i tras sitemapy. Do tego typy i testy.

Frontend ma osobne etapy: walidatory źródeł i wyniku, lint z progiem zero, testy oraz pełny build z generowaniem obrazków Open Graph. Bramka zbiorcza na końcu przepuszcza tylko komplet zielonych etapów.

Co z tego wynika

Każda z tych decyzji ma swoją cenę. Harmonogram bez ręcznych kroków wymaga alarmu, który ktoś odbierze. Bramka, która nie przepuszcza kompromisów, czasem zatrzyma pilną zmianę. Ten sam rachunek robimy przy cyberbezpieczeństwie i zgodności.