W świecie software’u długo funkcjonowało wygodne przekonanie: najpierw dowozimy funkcje, potem zajmiemy się bezpieczeństwem. Cyber Resilience Act przesuwa tę rozmowę w zupełnie inne miejsce. Bezpieczeństwo nie jest już dodatkiem do produktu. Coraz bardziej staje się częścią samego produktu.
CERT Polska opublikował praktyczny materiał o Cyber Resilience Act, wskazując m.in. na obowiązki producentów związane z zarządzaniem podatnościami, dokumentacją, zgłaszaniem incydentów i aktualizacjami bezpieczeństwa.
Najważniejsza zmiana nie polega na tym, że pojawia się kolejna regulacja. Chodzi o to, że bezpieczeństwo produktu trzeba projektować, utrzymywać i komunikować przez cały jego cykl życia.
Czego dowiesz się z tego tekstu?
- dlaczego CRA jest ważny dla producentów oprogramowania i produktów cyfrowych,
- co zmienia podejście do podatności i aktualizacji,
- dlaczego maintenance i SLA będą coraz bardziej security-heavy,
- co startup lub software house powinien uporządkować wcześniej.
CRA to rozmowa o cyklu życia produktu
Najważniejsza zmiana polega na tym, że bezpieczeństwo nie kończy się w dniu wdrożenia. Produkt trzeba:
- projektować z uwzględnieniem ryzyka,
- dokumentować,
- monitorować,
- aktualizować,
- reagować na podatności,
- komunikować użytkownikom istotne poprawki.
CERT Polska wskazuje, że CRA będzie stosowany etapami, a od 11 września 2026 r. zaczną obowiązywać przepisy dotyczące zgłaszania aktywnie wykorzystywanych podatności i poważnych incydentów.
To oznacza, że aktualizacja bezpieczeństwa przestaje być czymś, co dzieje się „przy okazji”. Coraz częściej będzie elementem oferty, architektury, dokumentacji i odpowiedzialności za produkt.
Dlaczego to ważne dla software house’u?
Software house nie zawsze będzie producentem w rozumieniu CRA. Ale to nie znaczy, że CRA go nie dotknie. Regulacja może działać pośrednio przez:
- wymagania klienta,
- umowy wdrożeniowe,
- maintenance,
- SLA,
- odpowiedzialność za poprawki,
- dokumentację techniczną.
Klient może zacząć oczekiwać, że dostawca nie tylko napisze kod, ale też pomoże w utrzymaniu zgodnego i bezpiecznego produktu. To zmienia negocjacje.
Nie wystarczy już powiedzieć: „poprawki bezpieczeństwa w ramach dobrej współpracy”. Trzeba ustalić:
- kto monitoruje podatności,
- kto klasyfikuje ich krytyczność,
- kto przygotowuje fix,
- w jakim czasie,
- kto komunikuje zmianę użytkownikom,
- co dzieje się po zakończeniu wsparcia.
Ten kierunek dobrze łączy się z praktyką obsługi podatności, o której pisałem przy okazji tekstu o CVE w PAC4J i procesie reakcji na podatności.
Startupowy problem: MVP, beta czy produkt?
CRA zwraca też uwagę na temat wersji testowych i nieukończonego oprogramowania. To bardzo startupowy problem.
Founderzy często mówią: „to jeszcze tylko MVP”. Klienci często słyszą: „to już działa, można używać”. I tutaj zaczyna się ryzyko.
Jeżeli produkt trafia do realnych użytkowników, przetwarza dane, obsługuje proces biznesowy albo wpływa na bezpieczeństwo klienta, samo nazwanie go „betą” nie rozwiązuje problemu.
W startupie trzeba jasno ustalić:
- do czego produkt jest przeznaczony,
- jakie ma ograniczenia,
- czy jest używany produkcyjnie,
- jaki jest poziom wsparcia,
- jak obsługiwane są błędy i podatności.
Etykieta „beta” może pomóc opisać etap rozwoju produktu, ale nie zastąpi realnych zasad odpowiedzialności, wsparcia i reakcji na ryzyka bezpieczeństwa.
Maintenance jako element compliance
W umowach IT coraz ważniejsze będą postanowienia dotyczące:
- aktualizacji bezpieczeństwa,
- zgłaszania podatności,
- współpracy przy incydentach,
- okresu wsparcia,
- dokumentacji technicznej,
- odpowiedzialności za komponenty third-party i open source.
To nie jest prawnicze komplikowanie umowy. To jest opis realnego procesu, który i tak będzie musiał istnieć.
Lepiej ustalić go przed incydentem niż po nim. W przeciwnym razie zespół zaczyna odpowiadać na najtrudniejsze pytania wtedy, gdy klient już czeka na fix, użytkownicy pytają o ryzyko, a komunikacja musi być szybka i spójna.
Co warto uporządkować wcześniej?
- zakres maintenance i SLA,
- procedurę obsługi podatności,
- zasady aktualizacji bezpieczeństwa,
- odpowiedzialność za komponenty third-party i open source,
- komunikację z klientem i użytkownikami,
- zakończenie wsparcia,
- dokumentację techniczną i bezpieczeństwa,
- podział odpowiedzialności między klientem, producentem i dostawcą.
Warto też połączyć ten przegląd z pytaniami o IP, komponenty zewnętrzne i repozytoria. Przy większym kliencie albo inwestorze temat bezpieczeństwa często idzie w parze z pytaniem, czy firma naprawdę kontroluje swój produkt. Szerzej pisałem o tym w tekście o tym, dlaczego zdanie „kod jest nasz” często nie wytrzymuje due diligence.
Na koniec
Cyber Resilience Act to dobry moment, żeby przestać traktować bezpieczeństwo jako załącznik do produktu. Bezpieczeństwo staje się częścią wartości produktu, a czasem także częścią jego ceny.
Jeżeli budujesz software, sprzedajesz produkt cyfrowy albo utrzymujesz rozwiązanie dla klienta, warto sprawdzić, czy Twoje umowy, procesy i dokumentacja nadążają za tym kierunkiem.
Klient coraz częściej nie będzie pytał tylko: „czy to działa?”. Będzie pytał: „jak długo będzie działało bezpiecznie?”
Tworzysz lub utrzymujesz produkt cyfrowy?
Warto sprawdzić, czy umowy, maintenance, SLA, dokumentacja techniczna i proces obsługi podatności nadążają za kierunkiem wyznaczanym przez Cyber Resilience Act. Pomagam software house’om i startupom porządkować odpowiedzialność za produkt, aktualizacje, bezpieczeństwo, IP i dane.