Cyber Resilience Act: prijavljivanje je obavezno od 11. septembra 2026.

Većina EU uredbi daje datum usklađenosti i period prilagođavanja u kome se svi tiho organizuju. Cyber Resilience Act radi nešto drugo. Njegova prva čvrsta obaveza je sat za prijavu od 24 časa i teče od 11. septembra 2026.

Sat od 24 časa ne možete uvoditi postepeno. Ili je proces spreman kada se pojavi iskorišćena ranjivost, ili propuštate rok.

Šta je CRA

Uredba (EU) 2024/2847 postavlja zahteve sajber bezbednosti za proizvode sa digitalnim elementima stavljene na tržište EU. Taj izraz obuhvata mnogo više nego što se u početku pretpostavlja: svaki softverski ili hardverski proizvod i njegova rešenja za daljinsku obradu podataka, čija predviđena ili razumno predvidljiva upotreba uključuje direktnu ili indirektnu podatkovnu vezu.

Povezani uređaji su obuhvaćeni. Kao i većina komercijalnog softvera, operativni sistemi, pregledači, mobilne aplikacije, firmver i komponente unutar drugih proizvoda.

Uredba je objavljena u novembru 2024. i primenjuje se u fazama:

• 11. jun 2026: obaveze tela za ocenjivanje usaglašenosti.
• 11. septembar 2026: obaveze prijavljivanja aktivno iskorišćenih ranjivosti i ozbiljnih incidenata.
• 11. decembar 2027: puna primena, uključujući suštinske zahteve sajber bezbednosti, CE oznaku, tehničku dokumentaciju i spisak softverskih komponenti.

Srednji datum je onaj koji već važi, i zavisi od sposobnosti koje možda nemate.

Šta važi od 11. septembra 2026.

Od tog datuma proizvođači moraju da prijave:

Aktivno iskorišćene ranjivosti u svojim proizvodima sa digitalnim elementima i

ozbiljne incidente koji utiču na bezbednost tih proizvoda.

Prijava ide preko jedinstvene platforme za prijavljivanje CRA, koju vodi ENISA, ka CSIRT-u određenom u državi članici glavnog sedišta proizvođača, koji potom deli sa drugim zahvaćenim CSIRT-ovima i sa ENISA-om. ENISA je prvu verziju platforme pustila u rad 11. septembra 2026, na dan kada je obaveza počela da važi, i najavljuje nove funkcije u narednim mesecima.

Rokovi:

• U roku od 24 sata od saznanja: rano upozorenje.
• U roku od 72 sata: potpuna prijava, uključujući preduzete korektivne ili ublažavajuće mere.
• U roku od 14 dana od dostupnosti korektivne mere: završni izveštaj za aktivno iskorišćenu ranjivost.
• U roku od mesec dana: završni izveštaj za ozbiljan incident.

Dvadeset četiri sata od saznanja, ne od potvrde niti od otklanjanja. Ako se ranjivost u komponenti vašeg proizvoda iskorišćava u divljini u subotu, sat kuca u subotu.

Zašto je ovo teže nego što izgleda

Sama obaveza prijavljivanja je formular. Teškoća je u svemu što treba imati pre nego što ga možete popuniti.

Morate znati šta je u vašem proizvodu

Da biste prijavili da se ranjivost u vašem proizvodu aktivno iskorišćava, morate znati da je ranjiva komponenta u vašem proizvodu. Za savremenu aplikaciju sa stotinama tranzitivnih zavisnosti, to nije nešto na šta čovek odgovara napamet.

Zato timovi sada grade pipeline za spisak softverskih komponenti, više od godinu dana pre formalnog zahteva za SBOM iz decembra 2027. SBOM nije cilj. Cilj je moći odgovoriti na pitanje „da li se to nas tiče?" u roku od nekoliko sati, a SBOM čini to pitanje odgovorivim.

Neugodno je što se ovo odnosi i na proizvode isporučene pre više godina. Ako imate podržane uređaje na terenu sa firmverom napravljenim 2022. iz stabla zavisnosti koje niko nije zapisao, rekonstrukcija je stvaran posao.

Morate posmatrati

Saznanje pokreće sat, a očekuje se da bude aktivno, a ne slučajno. To znači praćenje kanala o ranjivostima, prijavu na obaveštenja za svoje komponente, praćenje kataloga poznatih iskorišćenih ranjivosti i postojanje kanala kojim vas istraživači bezbednosti mogu dosegnuti i dobiti odgovor.

Morate imati putanju odlučivanja

Neko mora moći da odluči, u bilo koje doba, da li incident prelazi prag i da li je sat krenuo. Bez imenovane uloge i putanje eskalacije, prvi sati odlaze na utvrđivanje ko sme da donese odluku.

Zavisnosti van podrške postaju obaveza

Ako komponenta u vašem proizvodu više ne dobija bezbednosne ispravke, i dalje nosite obavezu prijave kada bude iskorišćena, a nemate ispravku uzvodno na koju možete pokazati. Provera zavisnosti van podrške jedna je od korisnijih stvari koje možete uraditi sada, jer odgovor ponekad nameće migraciju sa sopstvenim rokom.

Šta donosi puna primena u decembru 2027

Obaveze iz decembra 2027. su veći program i treba ih započeti mnogo ranije.

Bezbednost po dizajnu i podrazumevano. Proizvodi moraju biti projektovani, razvijeni i proizvedeni tako da obezbede odgovarajući nivo sajber bezbednosti zasnovan na riziku. Bez podrazumevanih lozinki. Bezbedna konfiguracija odmah. Minimizacija napadne površine. Zaštita podataka u prenosu i u mirovanju.

Postupanje sa ranjivostima. Dokumentovan proces koji pokriva identifikaciju, ispravku, testiranje, distribuciju i objavljivanje. Bezbednosna ažuriranja moraju biti isporučena bez odlaganja i besplatno, za period podrške koji odražava očekivani vek proizvoda, pri čemu je pet godina česta referenca.

Spisak softverskih komponenti. U mašinski čitljivom formatu, koji pokriva bar zavisnosti najvišeg nivoa i održava se ažurnim.

Tehnička dokumentacija i ocena usaglašenosti. Većina proizvoda se samoocenjuje. Važne i kritične kategorije, koje uključuju menadžere lozinki, VPN-ove, operativne sisteme i industrijske upravljačke sisteme, traže učešće treće strane.

CE oznaka. Digitalni ekvivalent fizičke oznake, kojim izjavljujete usaglašenost.

Politika koordinisanog objavljivanja ranjivosti. Objavljena, sa kontakt tačkom koja radi.

Ko je zaista u opsegu

Nekoliko graničnih slučajeva stalno se pojavljuje.

Slobodan i otvoren softver razvijen izvan komercijalne delatnosti uglavnom je izvan opsega. Uredba uvodi pojam staraoca softvera otvorenog koda sa lakšim obavezama. Ali ako komercijalizujete otvoreni kod ili ga isporučujete unutar proizvoda koji prodajete, obaveze za proizvod su vaše.

Softver kao usluga obično je izvan CRA i spada pod NIS2, mada se rešenja za daljinsku obradu podataka koja su sastavni deo proizvoda sa digitalnim elementima uvlače unutra. Ako vaš uređaj za rad zavisi od vašeg cloud backenda, taj backend putuje sa proizvodom.

Uvoznici i distributeri takođe nose obaveze. Ako stavite proizvod treće strane na tržište EU pod svojim imenom ili žigom, tretirate se kao proizvođač.

Proizvodi regulisani drugde, poput medicinskih sredstava, vozila i vazduhoplovne opreme, obrađuju se u sopstvenim okvirima.

Pitanja opsega zaista nisu trivijalna i to je mesto gde sat sa pravnicima štedi mesece pogrešno usmerene inženjerije.

Šta bismo uradili sada

Ako ste u opsegu i počinjete sada, ovaj redosled radi:

Prvo, uspostavite popis proizvoda. Šta zaista imate na tržištu EU? Uključujući stare verzije još na terenu, varijante pod tuđim brendom i proizvode koje distribuirate za nekog drugog. Ta lista je obično duža nego što iko očekuje.

Drugo, ugradite generisanje SBOM u CI. Generišite SBOM pri svakom buildu, u CycloneDX ili SPDX, čuvajte uz artefakt izdanja i držite ga pretraživim. Poenta je moći pitati „koja od naših isporučenih izdanja sadrže ovu biblioteku?" i dobiti odgovor za nekoliko minuta.

Treće, povežite praćenje ranjivosti. Uvedite podatke iz SBOM u skener koji prati obaveštenja i kataloge poznatih iskorišćenih ranjivosti, a upozorenja usmerite na kanal koji neko čita.

Četvrto, napišite priručnik za incidente. Ko proglašava, ko procenjuje, ko prijavljuje, ko komunicira. Imenovani ljudi, zamenici i kontakti van radnog vremena. Zatim uvežbajte jednom sa lažnim obaveštenjem. Na vežbi otkrijete da je osoba sa pristupnim podacima za platformu za prijavu na odmoru.

Peto, objavite politiku objavljivanja ranjivosti. Fajl security.txt, adresu koju neko prati i objavljeno vreme odgovora. To je popodne posla i razlika između saznanja o problemu od istraživača ili od novinara.

Šesto, započnite posao za decembar 2027. Bezbedne podrazumevane postavke, mehanizmi ažuriranja, odluke o periodu podrške i dokumentacija su arhitektonska pitanja, a ne papirologija. Proizvodi koje projektujete 2026. biće na tržištu i 2028.

Preklapanje koje niko ne koristi

Između CRA i drugih režima postoji značajno dupliranje, a većina kompanija svaki tretira odvojeno, što je rasipanje.

SBOM napravljen za CRA odgovara na većinu pitanja o lancu snabdevanja iz NIS2. Priručnik za incidente preklapa se sa ranim upozorenjem od 24 sata iz NIS2 i sa prijavom povrede u 72 sata iz GDPR-a. Procesi postupanja sa ranjivostima direktno hrane bezbednosne upitnike klijenata i korporativne nabavke.

Izgradite ovo jednom kao platformsku sposobnost. Alternativa su tri tima koja grade tri verzije istog popisa resursa.

Gde potražiti pomoć

Gradimo i održavamo softver za kompanije koje prodaju u EU, što sve više znači graditi vidljivost lanca snabdevanja i infrastrukturu ažuriranja koju CRA pretpostavlja. Ako utvrđujete da li ste u opsegu, ili obaveza prijavljivanja već važi za vas, a ništa ne prati vaše komponente, javite se na office@c9group.dev.

Naša usluga održavanja nasleđenih sistema često je polazna tačka, jer proizvodi sa najlošijom vidljivošću zavisnosti obično su najstariji. Šira regulatorna slika je u našem vodiču kroz EU digitalnu usklađenost 2026.

Mi smo inženjeri, a ne pravnici. Odluke o opsegu i klasifikaciji pripadaju vašim pravnicima, a mi gradimo prema odgovoru koji daju.