Na problem ten zwracają uwagę sami użytkownicy aplikacji. Prawie 70 proc. z nas zauważa, że firmy IT i programiści wprowadzają innowacje zbyt szybko, bez uwzględnienia wystarczającej uwagi ograniczaniu ryzyka bezpieczeństwa. Skutkiem takiej sytuacji może być pogorszenie reputacji firmy, utrata przychodów, a także kary finansowe spowodowane niespełnieniem wymogów regulacyjnych. Unijna DORA w Polsce przewiduje kary nawet do 10% przychodu netto lub prawie 21 mln złotych.
Luka w automatyzacji testów bezpieczeństwa
Deweloperzy pomijają procedury bezpieczeństwa przede wszystkim dlatego, że ich przeprowadzenie jest zbyt żmudne i czasochłonne. Takie podejście nie dziwi w kontekście badań, zgodnie z którymi ponad 45 proc. firm nadal realizuje procesy z tego obszaru ręcznie. Gdy każdy nowy kod jest wprowadzany manualnie do narzędzi testowych, powstaje wąskie gardło – cały proces spowalnia, a moment wypuszczenia aplikacji na rynek się opóźnia.
Sposobem na rozwiązanie problemu jest odejście od postrzegania testowania jako ostatniego etapu projektowania rozwiązań. To naturalny efekt ewolucji zachodzącej w podejściu DevOps, którego istotą jest przyspieszenie prac nad oprogramowaniem poprzez współpracę programistów z zespołem operacyjnym. W niektórych branżach, zwłaszcza tych regulowanych (finanse, administracja publiczna), to za mało. Dlatego w modelu DevSecOps bezpieczeństwo stanowi integralną część procesu dostarczania. W pełni zautomatyzowaną. To podejście do praktyk bezpieczeństwa, w tym prowadzenia testów podatności jako bieżącego elementu tworzenia oprogramowania-aplikacji. Według przepisów NIS2 czy DORA, kary mogą wynieść kilka milionów euro lub nawet do 5% globalnego obrotu firmy. Praktyka tworzenia w systemie DevSecOps sprawia, że luki w bezpieczeństwie są wykrywane automatycznie po napisaniu kodu. Dzięki temu mogą być od razu wyeliminowane. Pozostawienie tych działań na ostatni etap wytwarzania oprogramowania podnosi koszty przyszłych napraw. Przede wszystkim wbrew niektórym opiniom, odsuwa w czasie moment wydania aplikacji. - Dodatkowym wyzwaniem jest brak spójnych standardów bezpieczeństwa – różne zespoły przeprowadzają testy przy pomocy innych narzędzi i praktyk, co utrudnia współpracę i opóźnia reakcję na realne zagrożenie. Kolejnym argumentem wskazującym na potrzebę automatyzacji tego procesu jest duża złożoność środowisk IT, która w zasadzie uniemożliwia przeprowadzenie testów manualnych – mówi Marek Najmajer, Product Director z Linux Polska.
Programiści zagubieni w alertach bezpieczeństwa
Skalę problemu zwiększa zmęczenie zbyt dużą ilością alertów bezpieczeństwa. Ponad 71 proc. deweloperów uważa, że wiele (nawet 6 spośród 10) ostrzeżeń jest nieistotnych, a ich obsługa stanowi spore obciążenie. Jeśli w firmie stosowanych jest wiele różnych narzędzi do analizy ryzyka, pojawiają się kolejne powody do niezadowolenia: zduplikowane dane o zagrożeniach oraz sprzeczne wyniki mogą rozmywać rzeczywisty obraz bezpieczeństwa kodu. Samo wdrożenie DevSecOps faktycznie nie rozwiązuje tych problemów. Potrzebne jest jasne określenie narzędzi i procedur, jednolitych dla wszystkich zespołów.
Uwzględnienie kwestii bezpieczeństwa w grafiku, już na początkowym etapie wytwarzania oprogramowania nie jest gwarantem przyspieszenia prac. Wykorzystywane narzędzia nadal mogą generować wiele niepotrzebnych powiadomień. Konieczne jest podejście, które praktycy DevSecOps określają jako “shift smart”. W dosłownym tłumaczeniu oznacza ono “mądre przesunięcie”. - Statyczna weryfikacja kodu, analiza zależności czy testy dynamiczne są wykonywane wcześniej, ale ich wyniki są priorytetyzowane przy pomocy narzędzi AI. - W praktyce fałszywe alerty są filtrowane, a programiści otrzymują informacje o rzeczywistych problemach w formie kontekstowych wskazówek w ich środowisku pracy – tłumaczy Damian Traczuk, inżynier w Linux Polska.
Ukrycie lub zignorowanie ostrzeżeń nie eliminuje ryzyka bezpieczeństwa
Doświadczenia związane z manualną analizą kodu, która zajmuje dużo czasu i fałszywe alerty przekładają się na negatywny stosunek deweloperów do przeprowadzania testów. Ponad 8 na 10 specjalistów DevSecOps uważa, że spowalniają one proces tworzenia oprogramowania. – Zdarza się, że programiści definiują wyjątki i ukrywają podatności w narzędziach bezpieczeństwa. Takie działanie ma na celu redukcję tzw. szumu, czyli zbyt dużej liczby alertów. Należy jednak pamiętać o tym, że nadużywanie tego typu funkcji może dawać pozorne poczucie bezpieczeństwa i zwiększa ryzyko wystąpienia incydentów. Dlatego warto korzystać z narzędzi, które nie pozwalają na wykonywanie takich operacji – wyjaśniał Kamil Kwiatkowski, Solution Architect w Linux Polska.
Jak dodaje ekspert, skutki ukrywania ostrzeżeń mogą być dla organizacji bardzo poważne. Nawet jedna pominięta podatność może wpłynąć na całą organizację. Szybkość wydania aplikacji na rynek miała być atutem, a w takiej sytuacji staje się źródłem niezadowolenia klientów i strat przychodów. - Ze szczególnie dużym wyzwaniem mogą spotkać się firmy objęte specjalnymi przepisami, takimi jak dyrektywa NIS2 (przedsiębiorstwa o kluczowym znaczeniu dla gospodarki kraju) czy rozporządzenie DORA (instytucje finansowe). Regulatorzy mogą wymagać dokumentacji analizy zagrożeń i podejścia secure by design, czyli zapewnienia bezpieczeństwa oprogramowania już od początkowych etapów jego wytwarzania. Brak DevSecOps i pozostawienie testów na koniec rodzi ryzyko naruszenia regulacji i otrzymania kar finansowych – podsumowuje Kamil Kwiatkowski.
Jak tworzyć aplikację zgodnie z wymogami prawa UE i zasadami bezpieczeństwa
Coraz bardziej rygorystyczne przepisy prowadzą do ewolucji DevSecOps (praktyk bezpieczeństwa, w tym prowadzenia testów podatności jako elementu tworzenia oprogramowania-aplikacji) w kierunku DevGovOps. W podejściu tym cykl życia oprogramowania jest zintegrowany ze zgodnością regulacyjną. Celem takiego działania jest zapewnienie dowodów na bezpieczeństwo wszystkich etapów tworzenia aplikacji, na przykład w postaci wyniku skanowania czy raportu z testów jakości. Wdrożenie DevGovOps oznacza spore zmiany w kulturze organizacyjnej. Będzie to szczególnie duże wyzwanie dla tych przedsiębiorstw, które jeszcze nie zdecydowały się na integrację bezpieczeństwa z procesem wytwarzania oprogramowania
Dziennikarz z zawodu i zamiłowania. Zajmuje się tematyką gospodarczą, prawną i finansową, szczególnie nowymi technologiami, i komunikacją oraz mediami. Poza dziennikarstwem zajmuje się fotografią, jeździ na nartach i uwielbia Hiszpanię. Z marką INFOR związany wcześniej, zaczynał przygodę z dziennikarstwem w Gazecie Prawnej. Od kwietnia 2026 r. już jako dziennikarz internetowy przygotowuje i publikuje artykuły na portalu Forsal.pl.