„Wrzucimy patcha po wdrożeniu”. Co Cyber Resilience Act zmienia w utrzymaniu produktu?

Produkt trzeba dowieźć, demo dla klienta jest w przyszłym tygodniu, a sprint już dawno przestał się spinać. Zespół odkrywa problem z bezpieczeństwem, ale ktoś uspokaja:

„Teraz wypuśćmy wersję, a patcha wrzucimy po wdrożeniu”.

W świecie software’u takie podejście nie jest szczególnie egzotyczne. Najpierw funkcje i premiera, później hardening, dokumentacja oraz porządki w podatnościach.

Cyber Resilience Act może sprawić, że ten model stanie się znacznie bardziej ryzykowny.

CRA przesuwa cyberbezpieczeństwo z poziomu „dobrej praktyki zespołu IT” na poziom odpowiedzialności za produkt. Bezpieczeństwo trzeba nie tylko zaprojektować przed wdrożeniem, ale również utrzymywać, dokumentować i komunikować przez cały okres wsparcia.

Czym właściwie jest Cyber Resilience Act?

Cyber Resilience Act, czyli CRA, to unijne rozporządzenie określające wymagania cyberbezpieczeństwa dla produktów z elementami cyfrowymi.

Do tej kategorii mogą należeć między innymi:

1. aplikacje instalowane na urządzeniach;
2. systemy operacyjne;
3. urządzenia IoT;
4. routery i inne urządzenia sieciowe;
5. oprogramowanie komputerowe;
6. komponenty software’owe i hardware’owe wprowadzane na rynek oddzielnie;
7. powiązane rozwiązania zdalnego przetwarzania danych, jeżeli bez nich produkt nie mógłby wykonywać jednej ze swoich funkcji.

Nie każdy system IT i nie każda usługa cyfrowa automatycznie podlegają CRA. Znaczenie ma sposób oferowania produktu, jego funkcje, przeznaczenie oraz związek między oprogramowaniem a usługami działającymi po stronie dostawcy.

W szczególności oprogramowanie świadczone wyłącznie jako usługa, czyli SaaS, co do zasady nie jest objęte CRA tylko z tego powodu, że działa online. Inaczej może wyglądać sytuacja, gdy usługa zdalna jest niezbędna do działania produktu z elementami cyfrowymi i stanowi jego powiązane rozwiązanie w zakresie zdalnego przetwarzania danych.

Dlatego ocena nie powinna kończyć się na stwierdzeniu: „sprzedajemy SaaS, więc CRA nas nie dotyczy”.

Najpierw trzeba ustalić, co właściwie jest produktem, gdzie działa jego oprogramowanie, które funkcje są wykonywane lokalnie, a które zdalnie oraz co dokładnie trafia do klienta.

Bezpieczeństwo nie kończy się w dniu wdrożenia

Najważniejszy kierunek wynikający z CRA można sprowadzić do jednej zasady:

bezpieczeństwo trzeba umieć utrzymać przez cały cykl życia produktu.

Producent powinien uwzględnić cyberbezpieczeństwo nie tylko podczas tworzenia rozwiązania. Znaczenie ma cały proces:

1. projektowanie architektury produktu;
2. dobór komponentów i bibliotek;
3. development oraz testy;
4. wprowadzenie produktu na rynek;
5. monitorowanie informacji o podatnościach;
6. przygotowywanie aktualizacji bezpieczeństwa;
7. komunikacja z użytkownikami;
8. zakończenie okresu wsparcia.

Nie wystarczy więc przeprowadzić jednego pentestu przed premierą, odłożyć raport do folderu i uznać temat za zamknięty.

Produkt może być bezpieczny w dniu wdrożenia, a kilka miesięcy później stać się podatny z powodu błędu odkrytego w bibliotece, frameworku albo zewnętrznym komponencie.

Ktoś musi takie informacje monitorować, ocenić ryzyko i zdecydować, czy potrzebna jest aktualizacja. Jeżeli fix jest konieczny, trzeba go przygotować, przetestować, wydać i odpowiednio zakomunikować użytkownikom.

„Ktoś z devów się tym zajmuje” może nie wystarczyć

W wielu firmach proces obsługi podatności nie jest formalnie opisany. Działa dlatego, że jedna albo dwie osoby wiedzą:

1. z jakich bibliotek korzysta produkt;
2. gdzie pojawiają się informacje o nowych podatnościach;
3. które zgłoszenia są naprawdę istotne;
4. kto może przygotować poprawkę;
5. jak wydać aktualizację;
6. komu trzeba powiedzieć o problemie.

Dopóki te osoby pracują w firmie i są dostępne, system jakoś funkcjonuje. Problem pojawia się podczas urlopu, zmiany pracy, poważnego incydentu albo równoczesnej presji kilku klientów.

CRA wymusza bardziej uporządkowane podejście. Proces nie powinien „siedzieć w głowie” dwóch osób z zespołu. Powinno dać się ustalić, kto przyjmuje zgłoszenie, kto ocenia podatność, kto podejmuje decyzję o aktualizacji i kto odpowiada za komunikację.

Nie chodzi o stworzenie rozbudowanej procedury, której nikt nie przeczyta. Chodzi o to, żeby w razie realnego problemu zespół nie zaczynał od pytania: „kto właściwie miał się tym zająć?”.

Aktualizacje bezpieczeństwa stają się częścią produktu

CRA zakłada, że producent powinien obsługiwać podatności i udostępniać aktualizacje bezpieczeństwa w okresie wsparcia produktu.

Okres ten powinien odpowiadać przewidywanemu czasowi używania produktu. Co do zasady ma wynosić co najmniej pięć lat, chyba że przewidywany okres korzystania z danego produktu jest krótszy.

To zmienia kilka rzeczy.

Po pierwsze, producent musi już na etapie oferowania produktu zastanowić się, jak długo będzie go bezpiecznie utrzymywał.

Po drugie, okres wsparcia trzeba uwzględnić w cenie i zasobach zespołu. Pięć lat reagowania na podatności nie robi się samo.

Po trzecie, użytkownik powinien wiedzieć, przez jaki czas może liczyć na aktualizacje bezpieczeństwa.

Po czwarte, zakończenie wsparcia nie powinno być niespodzianką ogłoszoną klientowi tydzień przed wyłączeniem produktu.

Security update przestaje być więc wyłącznie techniczną poprawką. Staje się elementem oferty, dokumentacji, odpowiedzialności oraz ekonomii produktu.

Kiedy beta albo MVP stają się produktem?

CRA jest ciekawy także z perspektywy startupów, które rozwijają MVP, wersje beta i proof of concept.

Founderzy mówią: „to jeszcze tylko MVP”.

Klient słyszy: „system już działa, możemy na nim prowadzić normalny proces”.

No i pojawia się problem.

Nieukończone oprogramowanie może być udostępniane do celów testowych na ograniczony czas, jeżeli jest wyraźnie oznaczone jako niezgodne jeszcze z wymaganiami CRA i nieprzeznaczone do użytku produkcyjnego.

Samo wpisanie w regulaminie słowa „beta” nie zmienia jednak produkcyjnego systemu w środowisko testowe.

Jeżeli rozwiązanie:

1. jest używane przez realnych klientów;
2. obsługuje ich bieżące procesy;
3. przetwarza rzeczywiste dane;
4. jest oferowane odpłatnie;
5. ma działać stale, a nie wyłącznie podczas ograniczonych testów;
6. stanowi podstawę normalnej działalności użytkownika,

to nazwanie go wersją beta może nie oddawać rzeczywistości.

Etykieta powinna odpowiadać faktycznemu przeznaczeniu produktu. Nie może zastępować zasad bezpieczeństwa, odpowiedzialności i wsparcia.

Zgłaszanie podatności i poważnych incydentów

Od 11 września 2026 r. zaczyna być stosowany art. 14 CRA dotyczący zgłaszania aktywnie wykorzystywanych podatności oraz poważnych incydentów wpływających na bezpieczeństwo produktu.

Obowiązek nie dotyczy każdej drobnej usterki albo każdego błędu zauważonego podczas developmentu. Istotne będą między innymi podatności, co do których istnieją wiarygodne przesłanki, że są aktywnie wykorzystywane, oraz poważne incydenty wpływające na bezpieczeństwo produktu.

Zgłoszenie wymaga jednak wcześniejszego wykrycia i właściwej oceny problemu.

Firma powinna więc wiedzieć:

1. skąd otrzymuje informacje o podatnościach;
2. kto analizuje zgłoszenia klientów i badaczy bezpieczeństwa;
3. według jakich zasad ocenia ich istotność;
4. kto decyduje o dokonaniu zgłoszenia;
5. jakie informacje trzeba zebrać;
6. kto odpowiada za dalszą komunikację.

Jeżeli proces zacznie się dopiero po wykryciu aktywnie wykorzystywanej podatności, czasu na spokojne ustalanie ról raczej nie będzie.

Open source też wymaga kontroli

Współczesne produkty nie powstają wyłącznie z kodu napisanego przez własny zespół. Korzystają z bibliotek, frameworków, SDK, API, gotowych modułów oraz innych komponentów open source.

To pozwala budować szybciej, ale tworzy też zależności.

Jeżeli krytyczna podatność zostanie odkryta w jednej z używanych bibliotek, producent powinien umieć odpowiedzieć:

1. czy ten komponent znajduje się w naszym produkcie;
2. w której wersji go używamy;
3. które wersje produktu są nim dotknięte;
4. czy podatność może zostać wykorzystana w naszej konfiguracji;
5. czy dostępna jest bezpieczna aktualizacja;
6. jak szybko możemy ją wdrożyć.

Bez porządku w zależnościach nawet informacja o poważnej podatności niewiele daje. Zespół najpierw musi ustalić, czy w ogóle jej używa i gdzie została wdrożona.

Dlatego coraz większe znaczenie będą miały inwentaryzacja komponentów, kontrola wersji, zasady aktualizacji bibliotek oraz dokumentowanie zależności.

Co CRA oznacza dla software house’u?

Software house nie zawsze będzie producentem w rozumieniu CRA. Może stworzyć system na zlecenie klienta, przekazać kod i nie wprowadzać produktu na rynek pod własną marką.

To jednak nie oznacza, że CRA go ominie.

Klient będący producentem może przenieść wymagania na wykonawcę za pomocą umowy. W negocjacjach pojawią się pytania:

1. kto odpowiada za bezpieczny development;
2. kto kontroluje używane biblioteki;
3. kto monitoruje podatności po wdrożeniu;
4. kto i w jakim czasie przygotowuje poprawki;
5. czy aktualizacje bezpieczeństwa mieszczą się w cenie maintenance;
6. kto współpracuje przy zgłaszaniu incydentów;
7. kto przygotowuje potrzebną dokumentację;
8. jak długo wykonawca ma utrzymywać kompetencje do obsługi produktu.

Może się więc okazać, że software house formalnie nie jest producentem objętym konkretnym obowiązkiem, ale kontraktowo ma wykonać dużą część pracy potrzebnej klientowi do zachowania zgodności.

Warto ustalić to przed podpisaniem umowy. Zdanie „zapewniamy zgodność produktu z wszystkimi przepisami prawa” może wyglądać niewinnie, ale w praktyce może oznaczać bardzo szeroki i trudny do wyceny zakres odpowiedzialności.

Maintenance i SLA będą coraz bardziej „security-heavy”

CRA powinien skłonić firmy do ponownego spojrzenia na maintenance i SLA.

W umowie warto ustalić między innymi:

1. czy monitoring podatności jest objęty usługą utrzymania;
2. kto klasyfikuje poziom ryzyka;
3. jakie terminy dotyczą poprawek bezpieczeństwa;
4. czy terminy zależą od krytyczności podatności;
5. jak wygląda tryb awaryjnego wydania poprawki;
6. kto komunikuje się z klientami i użytkownikami;
7. co dzieje się, gdy poprawka wymaga aktualizacji komponentu zewnętrznego;
8. czy dostawca odpowiada za podatności znajdujące się poza jego kontrolą;
9. jakie obowiązki ma klient;
10. co dzieje się po zakończeniu okresu wsparcia.

Nie każda aktualizacja powinna być rozliczana tak samo. Zwykły rozwój produktu, poprawka błędu funkcjonalnego i pilny security patch mogą wymagać innych terminów, priorytetów oraz zasad wynagradzania.

Jeżeli umowa wrzuca wszystkie te prace do jednego worka pod nazwą „utrzymanie”, konflikt jest właściwie zaprogramowany. Klient będzie uważał, że poprawka mieści się w abonamencie, a wykonawca, że jest to dodatkowa zmiana wymagająca osobnej wyceny.

Czy SaaS może odczuć CRA „bocznymi drzwiami”?

Nawet jeżeli dany SaaS nie jest bezpośrednio objęty CRA, standardy wynikające z rozporządzenia mogą pojawić się w relacjach biznesowych.

Klienci enterprise mogą pytać o:

1. okres zapewniania aktualizacji bezpieczeństwa;
2. proces zgłaszania i obsługi podatności;
3. wykorzystywane komponenty open source;
4. dokumentację techniczną;
5. wyniki testów bezpieczeństwa;
6. terminy usuwania podatności;
7. zasady informowania o incydentach;
8. zakończenie wsparcia produktu.

Podobne pytania mogą pojawiać się w vendor assessment, due diligence, zamówieniach publicznych i negocjacjach umów.

CRA może więc oddziaływać na rynek szerzej niż tylko przez bezpośrednie obowiązki prawne. Jeżeli duzi klienci przyjmą jego standardy jako punkt odniesienia, mniejsi dostawcy zaczną spotykać je w ankietach, umowach i wymaganiach zakupowych.

Co warto uporządkować już teraz?

Zasadnicza część CRA zacznie być stosowana od 11 grudnia 2027 r. Nie oznacza to jednak, że pracę nad zgodnością warto rozpocząć miesiąc wcześniej.

Część wymagań dotyczy sposobu projektowania, dokumentowania i utrzymywania produktu. Tych elementów nie zawsze da się skutecznie dołożyć na samym końcu.

Na początek sprawdziłbym:

1. czy produkt może podlegać CRA i kto pełni rolę producenta;
2. jaki jest deklarowany okres wsparcia bezpieczeństwa;
3. kto monitoruje podatności;
4. jak przyjmowane i oceniane są zgłoszenia;
5. czy firma kontroluje używane komponenty i biblioteki;
6. jak wygląda proces wydawania pilnych poprawek;
7. kto odpowiada za komunikację z klientami i użytkownikami;
8. czy umowy z podwykonawcami zabezpieczają dostęp do potrzebnych informacji i wsparcia;
9. czy maintenance oraz SLA obejmują realny proces obsługi bezpieczeństwa;
10. które informacje istnieją w dokumentacji, a które nadal „siedzą w głowie” zespołu.

Cyber Resilience Act nie oznacza, że każdy produkt musi być wolny od błędów. Taka obietnica byłaby oderwana od realiów tworzenia software’u.

Zmienia się jednak oczekiwanie wobec producenta. Powinien wiedzieć, jak wykrywać podatności, jak na nie reagować, jak długo wspierać produkt i jak informować użytkowników o ryzyku.

Klienci nadal będą pytać: „czy ta funkcja działa?”. Coraz częściej zaraz po tym pojawi się jednak drugie pytanie: „czy jesteście w stanie bezpiecznie ją utrzymać?”.