Większość badanych firm testuje mniej niż 60 proc. aplikacji. 11 września rusza Cyber Resilience Act

Od 11 września 2026 r. producenci objęci Cyber Resilience Act będą musieli zgłaszać aktywnie wykorzystywane podatności i poważne incydenty, a część polskich firm ma czas tylko do 3 października na wpis do wykazu Krajowego Systemu Cyberbezpieczeństwa.

Tempo wydawania oprogramowania rośnie szybciej niż zasięg kontroli bezpieczeństwa. W globalnym badaniu Black Duck 62 proc. ankietowanych organizacji deklarowało, że testami obejmuje mniej niż 60 proc. swoich aplikacji. Nie jest to badanie polskiego rynku i nie dowodzi, że każda pominięta aplikacja zawiera lukę. Pokazuje jednak niedostatek wiedzy o ryzyku w chwili, gdy przedsiębiorcom przybywa obowiązków. 

Raport nie opisuje polskiego rynku IT

Tytułową liczbę trzeba czytać ostrożnie. Black Duck, dostawca narzędzi do ochrony aplikacji, opublikował raport oparty na odpowiedziach ponad tysiąca specjalistów zajmujących się tworzeniem oprogramowania i bezpieczeństwem. Ankietę przeprowadzono na świecie w lipcu i sierpniu 2025 r. Respondenci opisywali praktyki swoich organizacji.

Wynik nie pozwala zatem stwierdzić, że dokładnie cztery na dziesięć wszystkich aplikacji dostępnych na rynku nie przeszły żadnej kontroli. Ustalenie jest węższe: w blisko 62 proc. ankietowanych organizacji testy bezpieczeństwa obejmowały mniej niż 60 proc. portfela aplikacji. Oznacza to, że w tych firmach więcej niż cztery na dziesięć rozwiązań pozostawało poza deklarowanym zasięgiem testów.

Brak testu nie jest dowodem istnienia podatności. Jest jednak brakiem dowodu, że zespół szukał jej odpowiednią metodą. Także niewykrycie problemu podczas pojedynczego skanowania nie daje gwarancji bezpieczeństwa. Kontrola kodu, użytych bibliotek, konfiguracji, uprawnień i zachowania działającej aplikacji odpowiada na różne pytania. Dlatego bezpieczeństwa oprogramowania nie da się sprowadzić do jednego testu wykonywanego przed premierą.

Kod trafia na produkcję codziennie, kontrola nadal bywa ręczna

Niemal 60 proc. uczestników badania Black Duck podało, że ich organizacje wdrażają kod co najmniej raz dziennie. Jednocześnie 46 proc. firm nadal ręcznie kierowało nowe fragmenty kodu do kolejki testów bezpieczeństwa. Przy częstych wydaniach taki sposób pracy tworzy lukę organizacyjną: o tym, czy zmiana zostanie sprawdzona, może decydować pamięć człowieka, czas zespołu albo presja terminu.

Problem nie sprowadza się do niedostatku narzędzi. Aż 81 proc. ankietowanych specjalistów oceniło, że testy bezpieczeństwa spowalniają rozwój i dostarczanie oprogramowania. Ponad 71 proc. wskazało natomiast, że znaczną część generowanych ostrzeżeń stanowi szum - wyniki fałszywie dodatnie, niejasne komunikaty albo powtórzenia pochodzące z kilku systemów.

To tłumaczy frustrację programistów, lecz nie usprawiedliwia wyłączania kontroli. Podczas konferencji DevOps Cup 2026 Kamil Kwiatkowski, Solution Architect w Linux Polska, opisał praktykę oznaczania podatności jako wyjątków i ukrywania ich przed narzędziami bezpieczeństwa, aby ograniczyć liczbę komunikatów. Nadużycie takich funkcji zmniejsza hałas na ekranie, ale nie usuwa ryzyka z kodu.

AI może ustalać kolejność alertów, lecz potrzebuje kontroli

Jedną z odpowiedzi na przeciążenie ostrzeżeniami jest podejście określane jako shift smart. Testy statyczne, analiza zależności i kontrole dynamiczne są uruchamiane możliwie wcześnie, natomiast algorytmy pomagają oceniać znaczenie wyników oraz dostarczać programistom wskazówki w środowisku, w którym pracują.

Taka priorytetyzacja może skrócić kolejkę, lecz rodzi dodatkowe pytanie: kto i na jakiej podstawie uznał alert za nieistotny? Jeżeli model odfiltruje prawdziwe ostrzeżenie, firma otrzyma spokojniejszy pulpit i fałszywe poczucie bezpieczeństwa. Potrzebne są więc możliwość odtworzenia decyzji, okresowa kontrola odrzuconych wyników oraz reguły, które nie pozwalają automatycznie zamknąć najpoważniejszych spraw.

Prawo nie nakazuje DevSecOps z nazwy

DevSecOps włącza bezpieczeństwo do całego cyklu wytwarzania oprogramowania, zamiast pozostawiać je na ostatnią fazę projektu. Podobną logikę opisuje Secure Software Development Framework amerykańskiego NIST: praktyki ochronne powinny zostać zintegrowane z używanym modelem tworzenia oprogramowania. Ma to ograniczać liczbę podatności w wydawanych produktach, łagodzić skutki luk, których nie wykryto, oraz usuwać ich powtarzalne przyczyny.

Nie oznacza to jednak, że Cyber Resilience Act, polska ustawa o krajowym systemie cyberbezpieczeństwa albo DORA wprost nakazują wdrożenie metody nazwanej DevSecOps lub DevGovOps. Przepisy wymagają określonych rezultatów, procedur, testów, zarządzania ryzykiem, obsługi incydentów i dokumentacji. Organizacja może dobrać sposób działania do własnej architektury oraz skali zagrożeń. Sam zakup platformy oznaczonej etykietą DevSecOps nie przesądza o zgodności z prawem.

11 września rusza pierwszy obowiązek Cyber Resilience Act

Cyber Resilience Act obejmuje produkty z elementami cyfrowymi wprowadzane na rynek Unii Europejskiej, w tym oprogramowanie i sprzęt wraz z powiązanymi rozwiązaniami zdalnego przetwarzania danych. Regulacja przewiduje wyłączenia, między innymi dla niekomercyjnie rozwijanego otwartego oprogramowania oraz usług SaaS, które nie stanowią części produktu z elementami cyfrowymi. Zakres trzeba więc oceniać dla konkretnego produktu i modelu jego udostępniania.

Większość wymagań CRA, w tym zasad dotyczących projektowania, oceny zgodności i obsługi podatności w całym okresie wsparcia, zacznie być stosowana 11 grudnia 2027 r. Pierwszy ważny termin przypada jednak już 11 września 2026 r. Od tego dnia producenci będą zgłaszać aktywnie wykorzystywane podatności oraz poważne incydenty wpływające na bezpieczeństwo produktu. Obowiązek dotyczy także produktów udostępnionych na rynku Unii przed rozpoczęciem stosowania głównej części rozporządzenia.

Wczesne ostrzeżenie trzeba będzie wysłać w ciągu 24 godzin od uzyskania wiedzy o zdarzeniu, a pełne zgłoszenie - w ciągu 72 godzin. Przy aktywnie wykorzystywanej podatności raport końcowy powinien trafić do systemu najpóźniej 14 dni po udostępnieniu działania naprawczego lub ograniczającego ryzyko. W przypadku poważnego incydentu termin wynosi miesiąc od pełnego zgłoszenia.

Nie każda wykryta wada podlega temu obowiązkowi. Od 11 września raportowane będą podatności, wobec których istnieją wiarygodne dowody aktywnego wykorzystania, oraz poważne incydenty bezpieczeństwa. Aby rozpoznać taką sytuację i zmieścić się w 24 godzinach, producent musi jednak wiedzieć, których wersji produktu dotyczy problem, jakie zawierają komponenty, kto odpowiada za reakcję i gdzie znajdują się dane potrzebne do oceny skutków.

3 października upływa termin dla części podmiotów objętych KSC

W Polsce nowelizacja ustawy o krajowym systemie cyberbezpieczeństwa, wdrażająca NIS2, obowiązuje od 3 kwietnia 2026 r. Podmioty kluczowe i ważne, które już w dniu wejścia ustawy w życie spełniały kryteria, mają do 3 października 2026 r. na wpis do wykazu KSC. Do 3 kwietnia 2027 r. powinny między innymi wdrożyć system zarządzania bezpieczeństwem informacji, procedury obsługi i zgłaszania incydentów oraz wyznaczyć osoby odpowiedzialne za kontakty w krajowym systemie.

Termin nie dotyczy automatycznie każdej firmy informatycznej. Znaczenie mają sektor działalności, wielkość podmiotu i szczegółowe kryteria ustawy. Osobny reżim obowiązuje instytucje finansowe. DORA jest stosowana od 17 stycznia 2025 r. i obejmuje zarządzanie ryzykiem ICT, podstawowe oraz zaawansowane testy odporności, obsługę incydentów, ryzyko związane z zewnętrznymi dostawcami ICT i nadzór nad dostawcami uznanymi za krytycznych.

Klienci chcą innowacji, lecz tracą cierpliwość do ryzyka

Napięcie między szybkością a bezpieczeństwem widać również po stronie użytkowników. W badaniu Deloitte z drugiego kwartału 2025 r. 69 proc. z 3524 konsumentów w Stanach Zjednoczonych zgodziło się, że firmy technologiczne wprowadzają innowacje zbyt szybko i poświęcają za mało uwagi ograniczaniu ryzyka. Wynik został zważony do struktury amerykańskiej populacji, nie należy więc przenosić go wprost na polskich odbiorców. Pokazuje jednak, że bezpieczeństwo i prywatność stały się częścią oceny produktu, a nie wyłącznie zagadnieniem dla działu IT.

Wiarygodny proces powinien pozwolić odpowiedzieć na kilka prostych pytań: jaki kod i jakie zależności trafiły do konkretnego wydania, które kontrole wykonano, co pominięto i z jakiego powodu, kto zaakceptował ryzyko, kiedy usunięto podatność oraz czy zdarzenie przekroczyło próg ustawowego zgłoszenia. Jeśli firma nie potrafi tego odtworzyć, większa liczba skanerów lub alertów nie rozwiąże problemu. Automatyzacja przyspieszy wtedy proces, którego nikt w pełni nie kontroluje.

Pobierz ebook "Książka o Egipcie, jakiego nie pokazują wycieczki. Śladami starożytnych królowych i polskich archeologów"