Nawet 4 na 10 aplikacji trafia na rynek bez testów bezpieczeństwa. Tak działa ponad połowa firm IT

Presja konkurencji, konsumentów i inwestorów sprawia, że szybkość wydania aplikacji staje się ważniejsza od jej bezpieczeństwa. Badania potwierdzają, że już niemal 60 proc. organizacji wdraża kod codziennie. Prawie tyle samo respondentów (blisko 62 proc.) przyznaje jednak, że nie testuje aż 4 spośród 10 rozwiązań wypuszczonych na rynek^[1]. Na problem ten zwracają uwagę sami użytkownicy aplikacji. Aż 69 proc. z nich uważa, że organizacje technologiczne wprowadzają innowacje zbyt szybko, nie poświęcając wystarczającej uwagi ograniczaniu ryzyka^[2]. Skutkiem takiej sytuacji może być pogorszenie reputacji firmy, utrata przychodów, a także kary finansowe spowodowane niespełnieniem wymogów regulacyjnych.

Luka w automatyzacji

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^[3]. 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ą – dodaje Marek Najmajer, Product Director Linux Polska.

– 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 i – 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 Linux Polska.

Programiści zagubieni w alertach

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^[4]. 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. Jak wyjaśnia Damian Traczuk, inżynier ds. observability w Linux Polska, samo wdrożenie DevSecOps faktycznie nie rozwiązuje tych problemów.

– Uwzględnienie kwestii bezpieczeństwa 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 ds. observability w Linux Polska.

Ukrycie ostrzeżeń nie eliminuje ryzyka

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^[5]. Dochodzi do sytuacji, na którą podczas konferencji DevOps Cup 2026 zwrócił uwagę Kamil Kwiatkowski, Solution Architect w Linux Polska.

– 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.

Coraz bardziej rygorystyczne przepisy prowadzą do ewolucji DevSecOps 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