3 kwietnia 2026 r. weszła w życie znowelizowana ustawa o krajowym systemie cyberbezpieczeństwa. Tekstów wyjaśniających “kogo to dotyczy” jest sporo. Ten pokazuje, jak konkretne wymogi techniczne UKSC przełożyć na narzędzia i procesy w pipeline CI/CD.
UKSC to regulacje obejmujące zarządzanie ryzykiem, raportowanie, ciągłość działania, łańcuch dostaw, szkolenia i wiele innych obszarów. W VirtusLab specjalizujemy się w obszarach wokół bezpiecznego wytwarzania oprogramowania (SSDLC – Secure Software Development Lifecycle). Jako 400-osobowy software house z certyfikatem ISO 27001, podlegający UKSC i DORA jako dostawca ICT dla sektora krytycznego i finansowego, te wymagania znamy z własnej kuchni.
Jeżeli Twoja organizacja sama wytwarza albo zamawia oprogramowanie, ten artykuł jest dla Ciebie. Jeżeli utrzymuje systemy wymagające testowania, przeczytaj koniecznie sekcję o pentestach AI.
Terminy i czego naprawdę dotyczy art. 8
Ustawa operuje pojęciami podmiotu kluczowego i podmiotu ważnego. Takie podmioty muszą zacząć od wpisu do wykazu (do 3 października 2026 r.). Pełne wdrożenie Systemu Zarządzania Bezpieczeństwem Organizacji (SZBI) i podłączenie do systemu S46 oczekiwane jest do 3 kwietnia 2027 r. Pierwszy obowiązkowy audyt dla podmiotów kluczowych: do 3 kwietnia 2028 r. Daty wymagające, ale nie one są największym wyzwaniem.
Realnym wyzwaniem jest art. 8 ust. 1, czyli katalog środków technicznych i organizacyjnych, które musi obejmować system zarządzania bezpieczeństwem informacji. Ministerstwo Cyfryzacji w FAQ pisze wprost:
"Kupiona dokumentacja, podpisana przez zarząd i schowana w 'szafie NIS2' nie zapewni realnego cyberbezpieczeństwa".
Przepisy wprowadzane przez ustawę wymagają o wiele więcej. Niejeden podmiot ma sporo do nadrobienia, zwłaszcza, że raz zaimplementowane SZBI trzeba systematycznie rozwijać i audytować. Nie ma tutaj miejsca na “malowanie trawy na zielono” i to akurat bardzo dobrze świadczy o autorach przepisów. SZBI, podobnie jak w przypadku normy ISO 27001, jest tak pomyślane, by faktycznie zwiększyć bezpieczeństwo, monitorować je i dostosować organizację do współczesnych realiów. W skrócie: przepisy wymagają, aby bezpieczeństwo było mierzalne, monitorowane i ciągle utrzymywane. Przyjrzyjmy się wybranym, konkretnym wymaganiom wobec procesów i narzędzi w procesie wytwórczym oprogramowania.
SDLC a konkretne wymagania
Po pierwsze, art. 8 ust. 1 pkt 2 lit. b: bezpieczeństwo w procesie nabywania, rozwoju, utrzymania i eksploatacji systemu informacyjnego, w tym testowanie. Po ludzku: jeśli sami wytwarzamy oprogramowanie albo zamawiamy je u dostawców, musimy mieć udokumentowany, powtarzalny proces wykrywania i usuwania m. in. podatności zanim kod trafi na produkcję. Dodatkowo: art. 8 ust. 1 pkt 3 oraz pkt 5 lit. d: zbieranie informacji o cyberzagrożeniach i podatnościach oraz niezwłoczne podejmowanie działań po dostrzeżeniu podatności. Konkretne działania, które mogą to zapewnić, to:
- SAST, czyli statyczna analiza kodu źródłowego, uruchamiana na repozytoriach, Pull Requestach, ale też w samym IDE,
- SCA, analiza zależności (biblioteki open source, paczki systemowe i nie tylko),
- skanowanie obrazów kontenerów, zanim trafią do rejestru,
- PR i release gating, czyli automatyczne blokowanie merge'a lub buildu powyżej zdefiniowanego progu,
- IaC scanning, kontrola konfiguracji Terraform, Kubernetes czy Helm.
Zwróćmy uwagę na dwa istotne wymagania: zbieranie informacji o podatnościach i niezwłoczne podejmowanie działań. Trzeba więc skutecznie katalogować podatności, wyszukiwać je, filtrować, przydzielać zespołom i powiadamiać o nich, czasem błyskawicznie i na różnych kanałach. Kiedy organizacje próbują zestawić takie rozwiązanie z wielu połączonych narzędzi, natychmiast pojawiają się dwa problemy:
- Ta sama CVE w bibliotece używanej przez dziesięć serwisów generuje dziesięć ticketów w JIRA, każde narzędzie punktuje ją inaczej, a zespół traci dzień na ustalenie, czy to jedno zgłoszenie, czy dziesięć osobnych.
- Narzut utrzymania: wiele osobnych integracji z CI, wiele zestawów reguł, wiele paneli uprawnień, wiele kontraktów licencyjnych. Całość jest chaotyczna i wymaga dedykowanego specjalisty do zmagań z wieczną niestabilnością. Żeby móc sprawnie zarządzać takimi podatnościami, potrzebny jest jeden spójny system, którego utrzymanie będzie miało minimalny narzut.
Po drugie, art. 8 ust. 1 pkt 2 lit. e: bezpieczeństwo i ciągłość łańcucha dostaw produktów ICT, usług ICT i procesów ICT. To jeden z najczęściej niedoszacowanych obszarów. UKSC wymaga, by podmiot kluczowy lub ważny znał swój łańcuch dostaw i potrafił reagować na podatności u dostawców.
Na szczęście wiemy, jak można zaadresować to wymaganie. Odpowiedzią jest właściwe narzędzie bezpieczeństwa oprogramowania. Jednym z nich jest Aikido Security, którego jesteśmy partnerem. Pozwól więc, że opowiem Ci, w jaki sposób Aikido pozwala spełnić wymagania z powyższego artykułu ustawy:
- Aktualny SBOM dla każdej aplikacji, żeby w chwili publikacji nowego CVE odpowiedzieć natychmiast na pytanie "czy nas to dotyczy". Wykorzystanie AI przez hakerów powoduje, że tempo pojawiania się nowych krytycznych luk w OSS wzrosło ostatnio gwałtownie, podobnie jak gwałtownie maleje bezpieczny czas na reakcję.
- Reachability analysis pozwala automatycznie odfiltrować podatności jeśli nie są faktycznie osiągalne w kodzie. Jeśli jest potrzeba ręcznej analizy - wizualizacja tranzytywnego grafu dla podatnej zależności obsługuje dowolną głębokość.
- Scoring uwzględniający kontekst: Aikido wylicza poziom krytyczności uwzględniając o wiele więcej niż CVSS: EPSS, ekspozycję na Internet, dostępność exploita i różne inne czynniki. To drastycznie ogranicza zalewanie zespołów fałszywie “krytycznymi” alertami.
- Ryzyko licencyjne OSS, czyli wykrycie, że w drzewie zależności pojawiły się problematyczne licencje np. AGPL czy licencje płatne.
Redukcja fałszywych alarmów
Zupełnie osobno wypada wspomnieć o mechanizmie, który nazywamy killer feature Aikido: auto-ignore engine. Typowa bolączka narzędzi typu SAST/SCA to fałszywe alerty (false positives), co prowadzi najczęściej do przeciążenia, frustracji i przeoczeń. Autorski silnik automatycznego ignorowania odsiewa nawet do 80% podatności, które nie są istotne w kontekście konkretnego projektu. Zrozumienie tego kontekstu i ocena takich fałszywych pozytywów to coś, co Aikido potrafi zrobić na podstawie różnych informacji pozyskanych z projektu, zdejmując ten ciężar z inżynierów.
Wspomniane wcześniej zbieranie informacji o cyberzagrożeniach i podatnościach powinno obejmować jak najwięcej elementów SDLC, również:
- Secret scanning z przejściem przez pełną historię repozytorium, bo klucze API i tokeny wyciekają zwykle nie w bieżącym kodzie, lecz w commitach sprzed miesięcy.
- Monitoring powierzchni ataku: Aikido skanuje domeny i assety od strony Internetu, dając obraz tego, co widzi atakujący i wyłapując błędy konfiguracji, poddomeny oraz wiele różnych innych typowych podatności na tym poziomie.
- DAST, czyli testy aplikacji uruchomionej – cykliczne automatyczne atakowanie testowych systemów, dopasowując próby SQL injection, wymuszania błędów walidacji i całego wachlarza typowych ataków na API.
Endpoint Protection
Wreszcie Endpoint Protection – zabezpieczenie poważnej białej plamy w łańcuchu dostaw – bibliotek i wtyczek IDE na maszynach developerów. Ataki na łańcuch dostaw przez złośliwe pakiety npm/pythonowe albo zainfekowane rozszerzenia IDE to nowa i niezwykle skuteczna fala działań hakerów. VS Code Marketplace zalewają wtyczki z malware, co doprowadza do kompromitacji takich jak chociażby niedawny atak na wewnętrzne repozytoria samego GitHuba. Aikido Endpoint Protection blokuje złośliwe wersje zależności i skompromitowane wtyczki na maszynach deweloperskich. Nie tylko pomaga to pokryć art. 8 ust. 1 pkt 2 lit. e (łańcuch dostaw) oraz lit. m (zarządzanie aktywami), ale przede wszystkim skutecznie zabezpiecza obszary, które są poważną dziurą w wielu organizacjach wytwarzających oprogramowanie, nie objętą ochroną żadnych standardowych EDRów.
Jak to spiąć z innymi narzędziami? Bez podłączenia do GitHub Actions, GitLab CI, Jenkinsa, Bitbucket, JIRA, Harbor, Slacka/Teams czy dostawców tożsamości (Entra ID, Okta) każde narzędzie tej klasy staje się kolejnym silosem. W przypadku Aikido katalog możliwych integracji zapewnia dopasowanie do niemal każdego środowiska specyficznego w organizacji.
Dowiedz się więcej o możliwościach Aikido Security i VirtusLab.
A co z audytem?
Art. 15 wymaga od podmiotów kluczowych audytu co 3 lata. Organ właściwy w ramach nadzoru ex ante może żądać dowodów działania SZBI, w tym logów, konfiguracji, ewidencji obsłużonych podatności. Aikido generuje logi audytowe, raporty z mapowaniem na ISO 27001 oraz wymogi NIS2: eksport, podpis, dowód, że proces działa. Do tego dostarcza SBOM eksportowalny do standardów CycloneDX/SPDX, czyli konkretnych artefaktów obsługiwanych przez audytorów.
Testowanie, które nadąża za zmianami: AI pentest
Wróćmy na moment do art. 8 ust. 1 pkt 2 lit. b - bezpieczeństwo w eksploatacji systemu, w tym testowanie. Pierwszy niuans: to nie musi być wyłącznie obowiązek wytwórcy. Jeśli utrzymujesz działający system, może to być też i Twój obowiązek.
Ustawa nie nakazuje przy tym "testuj ciągle". Wskazuje testowanie jako środek i każe dobrać go proporcjonalnie do ryzyka oraz do aktualnego stanu wiedzy. Przy systemie zmienianym co tydzień trudno bronić tezy, że pentest sprzed roku spełni taki warunek.
W systemie Aikido Security autonomiczne agenty łączą kroki i wnioskują, jak aplikacja powinna się zachować, a potem próbują to złamać. AI pentest sięga po klasy podatności, które sygnaturowy skaner sprawdza albo powierzchownie, albo wcale: logikę autoryzacji, IDOR, wyciek danych cross-tenant i wiele innych. Łapie wieloetapowe nadużycia logiki biznesowej i łańcuchy ataku wymagające rozumienia tego, po co dany system istnieje. Raporty udostępnia w ciągu godzin, a nie tygodni, umożliwiając szybki skoncentrowany re-test po wdrożeniu poprawek.
Co zostaje dla audytu
Dla audytora liczy się to, co po takich testach organizacja może wykazać w dokumentacji. Aikido AI pentest generuje raport spójny z wymogami ISO 27001 - z potwierdzonymi podatnościami i dowodem ich wykorzystania.
Dlaczego VirtusLab?
Jesteśmy europejskim partnerem Aikido Security, firmy z siedzibą w Belgii. Dane mogą zostać w Polsce, bo Aikido działa w modelu on-prem dla lokalnych skanerów. Jako VirtusLab zatrudniamy ponad 400 inżynierów w Polsce i sami, jako dostawca ICT dla sektora krytycznego i finansowego, musimy spełniać UKSC oraz DORA. Mamy ISO 27001 i własne procesy SSDLC przepracowane na produkcyjnych projektach, a także wdrożenie Aikido on-prem w sektorze publicznym.
Nie sprzedajemy samych licencji, tylko profesjonalne wdrożenie: od dopasowania architektury przez integrację z istniejącymi pipeline'ami CI/CD, dostawcami tożsamości i systemami ticketowymi aż po szkolenia zespołów deweloperskich i dokumentację gotową do audytu. Po wdrożeniu zapewniamy wsparcie produktowe po polsku, w polskich godzinach pracy.
Na koniec warto podkreślić jedną istotną kwestię: samo wdrożenie narzędzia zabezpieczającego nie zapewni jeszcze 100% zgodności z wymaganiami ustaw. Jednakże dobrze skonfigurowane narzędzie i wpięte w działające procesy, oszczędza miesiące roboczogodzin na drodze do audytu, który dla podmiotów kluczowych nadejdzie do 3 kwietnia 2028 r.
