Moderne aplikacije i digitalni proizvodi danas prolaze kroz više razina provjere nego ikada prije. Code review je standardni dio razvoja, automatizirane sigurnosne provjere često su uključene u pipeline, a funkcionalno i sigurnosno testiranje postali su normalan dio release procesa.

Ipak, proizvodi koji prolaze takve provjere i dalje završavaju kompromitirani.

Razlog nije nužno u tome da sigurnosno testiranje ne postoji ili da razvojni timovi ignoriraju sigurnost. Problem je puno češće u tome što se sigurnost i dalje promatra preusko. Fokus ostaje na aplikaciji ili pojedinoj funkcionalnosti, dok stvarni napadni put često nastaje tek kada se promatra cijelo okruženje zajedno.

Aplikacija može imati siguran authentication flow, ali istovremeno otkrivati previše informacija kroz API odgovore. Može prolaziti interne sigurnosne provjere, a istovremeno imati deployment konfiguraciju koja izlaže debug informacije ili interne putanje. Može imati kvalitetnu validaciju unosa, ali uz to koristiti servise i integracije koje stvaraju neočekivani napadni put.

Upravo tu nastaje razlika između sigurnosti koda i sigurnosti proizvoda.

Jedan od obrazaca koji se redovito pojavljuje tijekom testiranja uključuje API-je koji tehnički rade ispravno, ali vraćaju više podataka nego što je potrebno. Endpoint vraća legitimne podatke za zahtjev, ali uz njih otkriva interne identifikatore, strukturu objekata ili način na koji su servisi povezani. Iz razvojne perspektive odgovor je ispravan. Iz perspektive napadača, to postaje alat za mapiranje sustava.

Slična situacija pojavljuje se kod autentikacije. Lozinke se validiraju, tokeni se ispravno obrađuju, sesije rade očekivano. No kada se više endpointa koristi zajedno, pojavljuje se mogućnost zaobilaženja ograničenja. Jedan endpoint potvrđuje postoji li korisnik, drugi dopušta previše pokušaja autentikacije, treći otkriva dodatni kontekst o računu. Svaki dio pojedinačno djeluje prihvatljivo. Zajedno stvaraju stvaran napadni put.

Konfiguracija i infrastruktura dodatno kompliciraju situaciju. Tijekom testiranja često se vidi da aplikacija sama po sebi nema ozbiljan problem, ali deployment okruženje otkriva interne informacije, environment varijable, reference na druge servise ili nepotrebno izložene administrativne funkcionalnosti.

Takve stvari često nisu problem razvoja aplikacije. Problem je što sigurnost proizvoda ne završava kodom.

U praksi AresISEC često vidi aplikacije koje prolaze interne sigurnosne provjere, ali i dalje imaju napadne putove koji postaju vidljivi tek kada se aplikacija, konfiguracija, infrastruktura i način korištenja promatraju zajedno.

Upravo zato sigurnost proizvoda danas postaje puno šira tema od samog testiranja aplikacije. To se sve više vidi i kroz regulatorne zahtjeve.

Cyber Resilience Act postupno uvodi obveze za proizvođače softvera i proizvoda s digitalnim elementima na razini cijele Europske unije. Većina zahtjeva počet će se primjenjivati krajem 2027. godine, dok obveze vezane uz prijavu aktivno iskorištenih ranjivosti i incidenata dolaze ranije. Regulativa će zahtijevati sustavan pristup sigurnosti proizvoda kroz cijeli životni ciklus, uključujući upravljanje ranjivostima, sigurnosna ažuriranja, dokumentaciju i procjenu rizika. Za organizacije koje razvijaju ili održavaju digitalne proizvode to znači da sigurnost više neće biti samo tehničko ili razvojno pitanje, nego i regulatorna obveza s potencijalno značajnim financijskim kaznama.

Cyber Resilience Act dodatno pomiče fokus sa same aplikacije na sigurnost proizvoda kroz cijeli životni ciklus. Za organizacije koje razvijaju softver ili proizvode s digitalnim elementima pitanje više neće biti samo prolazi li funkcionalnost testiranje, nego postoji li sustavan pristup sigurnosti tijekom dizajna, razvoja, implementacije, održavanja i upravljanja ranjivostima.

To mijenja način na koji se promatra sigurnost razvoja. Sigurnost više nije samo provjera pojedinog dijela sustava. Postaje pitanje načina na koji se cijeli proizvod ponaša u stvarnom okruženju i pod stvarnim uvjetima.

Ključna poanta nije da razvojni timovi ne rade sigurnosno testiranje. Većina ozbiljnih timova ga radi. Problem je u tome što nijedna pojedinačna provjera sama ne može pokriti sve perspektive.

Stvarna sigurnost proizvoda počinje tek kada se sustav promatra kao cjelina.

Izvori:
European Union – Cyber Resilience Act (Regulation (EU) 2024/2847)

OWASP – Web Security Testing Guide

OWASP – Top 10 Web Application Security Risks

NIST – Technical Guide to Information Security Testing and Assessment (SP 800-115)