Szybkość wydania aplikacji staje się ważniejsza od jej bezpieczeństwa. 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 – według raportu Black Duck, „Balancing AI usage and risk in 2025”.

Na problem ten zwracają uwagę także użytkownicy aplikacji. Otóż 69 proc. respondentów w badaniu Deloitte uważa, że innowacje dostawcy wprowadzają zbyt szybko, nie poświęcając wystarczającej uwagi ograniczaniu ryzyka.

Potrzebna zmiana podejścia i automatyzacja

Deweloperzy pomijają procedury bezpieczeństwa bo są czasochłonne. Według Black Duck 45 proc. firm nowy kod wprowadzana manualnie do narzędzi testowych, co spowalnia wypuszczenie aplikacji na rynek.

Sposobem na rozwiązanie problemu jest odejście od postrzegania testowania jako ostatniego etapu projektowania rozwiązań – twierdzi Linux Polska. W modelu DevSecOps bezpieczeństwo stanowi zautomatyzowaną część procesu dostarczania oprogramowania.

„DevSecOps sprawia, że luki w bezpieczeństwie są wykrywane automatycznie po napisaniu kodu. Dzięki temu można je od razu wyeliminować” – zapewnia Marek Najmajer, Product Director Linux Polska.

„Pozostawienie tych działań na ostatni etap wytwarzania oprogramowania podnosi koszty przyszłych napraw i odsuwa w czasie wydanie aplikacji. Dodatkowym wyzwaniem jest brak spójnych standardów bezpieczeństwa. Różne zespoły przeprowadzają testy przy pomocy innych narzędzi i praktyk. Kolejnym argumentem na rzecz automatyzacji jest duża złożoność środowisk IT, która w zasadzie uniemożliwia przeprowadzenie testów manualnych” – przekonuje dyrektor.

Programiści gubią się w alertach

Skalę problemu zwiększa zmęczenie zbyt dużą ilością alertów bezpieczeństwa. Ponad 71 proc. deweloperów w badaniu Black Duck uważa, że 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 narzędzi do analizy ryzyka, powielane są informacje o zagrożeniach. Sprzeczne wyniki mogą rozmywać rzeczywisty obraz bezpieczeństwa kodu.

Czas na “shift smart”

Jak wyjaśnia Damian Traczuk, inżynier ds. observability w Linux Polska, samo wdrożenie DevSecOps nie rozwiązuje tych problemów.

„Konieczne jest podejście określane jako “shift smart”. Mianowicie 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.

Programiści ukrywają podatności

Złe doświadczenia związane z manualną analizą kodu i fałszywe alerty przekładają się na negatywny stosunek deweloperów do testów. Ponad 8 na 10 specjalistów DevSecOps uważa, że spowalniają one tworzenie oprogramowania.

„Zdarza się, że programiści definiują wyjątki i ukrywają podatności, w celu redukcji zbyt dużej liczby alertów. Jednak nadużywanie tej funkcji zwiększa ryzyko 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.

Grożą konsekwencje w zwiazku z NIS2 i DORA

Skutki ukrywania ostrzeżeń mogą być dla organizacji poważne, zwłaszcza w podmiotach objętych przepisami NIS2 i DORA. Regulatorzy mogą wymagać dokumentacji analizy zagrożeń i podejścia secure by design. Chodzi o zapewnienie bezpieczeństwa oprogramowania już od początkowych etapów jego wytwarzania. Brak DevSecOps i pozostawienie testów na koniec grozi naruszeniem regulacji i karami finansowymi – twierdzi ekspert.

Sprawa jest szczególnie istotna w sytuacji, gdy wykrywanie luk w zabezpieczeniach przez AI dyrektorzy pytani przez Gartnera uznali za największe aktualnie zagrożenie dla firm.