Odločanje, odgovornost in organizacija
ČIGAVA RANLJIVOST, ČIGAVA PRIJAVA?
Kako proizvajalec digitalnega izdelka ugotovi, kdaj mora prijaviti aktivno izrabljeno ranljivost ali resen varnostni incident
Varnostno opozorilo lahko prispe hkrati proizvajalcu programske opreme, distributerju in organizaciji, ki izdelek uporablja. Vsi trije imajo razlog, da ga obravnavajo, vendar od njih ni mogoče zahtevati enake prijave zgolj zato, ker so prejeli isti dokument. Evropski Akt o kibernetski odpornosti (Cyber Resilience Act, CRA) obveznost poročanja navezuje na pravno vlogo pri izdelku in na natančno določene okoliščine varnostnega dogodka. Če je prva presoja napačna, je lahko napačen tudi naslovnik obvestila.
To vprašanje je od 11. septembra 2026 praktično. Takrat so se začele uporabljati obveznosti proizvajalcev iz 14. člena Uredbe (EU) 2024/2847. Uredba je začela veljati 10. decembra 2024, večina njenih zahtev pa se začne uporabljati 11. decembra 2027. Različen začetek uporabe ne pomeni odloga poročanja do leta 2027; prav tako ne pomeni, da je treba evropskim organom prijaviti vsako novo odkrito napako. [1][2][4]
Pod isto varnostno opozorilo niso podpisani isti zavezanci
Proizvajalec po členu 3(13) ni nujno tisti, ki je fizično napisal programsko kodo ali sestavil napravo. Pomembno je, kdo izdelek razvije ali izdela oziroma naroči njegov razvoj ali izdelavo in ga trži pod svojim imenom ali znamko. Uredba zajema tudi primere trženja brez neposrednega plačila. Organizacija, ki kupi omrežno napravo in jo vključi v lastno infrastrukturo, zgolj zaradi uporabe naprave ne postane njen proizvajalec. Njene naloge pri zaščiti omrežja in morebitne obveznosti po drugih predpisih je treba presojati ločeno. [1]
Položaj distributerja ali uvoznika ni vedno tako preprost. Člena 21 in 22 določata primere, ko zaradi trženja pod lastno znamko ali bistvene spremembe izdelka za tak subjekt veljajo proizvajalčeve obveznosti. Ker se navedena člena začneta uporabljati šele 11. decembra 2027, ju ni dopustno brez dodatne pravne presoje uporabiti kot samostojno podlago za prijavo v prehodnem obdobju leta 2026. Že zdaj pa je odločilno, ali subjekt po opredelitvi iz člena 3(13) dejansko nastopa kot proizvajalec. [1]
Preden se odpre postopek prijave, je treba ugotoviti tudi, ali predmet sploh sodi med izdelke z digitalnimi elementi, za katere velja CRA. Področje uporabe vključuje strojno in programsko opremo, pri kateri predvideni namen ali razumno predvidljiva uporaba vključuje neposredno ali posredno podatkovno povezavo z napravo ali omrežjem. Uredba hkrati določa izključitve in posebna razmerja do sektorskih predpisov. Splošna oznaka »IT-storitev« ali »program« zato sama ne pove dovolj. [1]
Ko obstaja ranljivost, dokaza o napadu pa še ni
Predstavljajmo si izdelovalca namizne aplikacije za upravljanje naprav. Raziskovalec mu pošlje opis napake in prikaz, s katerim je v dogovorjenem laboratorijskem okolju dosegel izvajanje neželenega ukaza. Preizkus je ponovljiv, napaka je lahko nevarna in razvijalci imajo dovolj razlogov za popravek. Iz takšnega dokaznega gradiva pa še ne izhaja, da je prišlo do aktivne izrabe v pomenu, ki ga za obvezno prijavo uporablja CRA.
Uradno slovensko besedilo v členu 3(42) opredeljuje aktivno izrabljeno ranljivost z zanesljivimi dokazi, da jo je zlonamerni akter uporabil v sistemu brez dovoljenja njegovega lastnika. Člen 3(41) posebej pozna izrabljivo ranljivost: takšno, ki jo je mogoče učinkovito izkoristiti v praktičnih pogojih delovanja. Uresničljivost napada in dokazana nedovoljena izraba imata torej različen pravni pomen. Niti javno objavljen opis napake niti oznaka CVE sama zase ne nadomestita dokaza, zahtevanega za prvi sprožilec iz člena 14(1). [1]
Nato proizvajalec prejme drugo sporočilo. Prizadeta organizacija priloži preverljive dogodke iz dnevnikov, časovne podatke in analizo, ki povezuje isto ranljivost z nepooblaščenim ravnanjem zlonamernega akterja v nameščenem izdelku. Če so podatki zanesljivi in je presoja njihovega pomena utemeljena, je položaj drugačen: nastopil je lahko sprožilec obveznega poročanja o aktivno izrabljeni ranljivosti. Primer je hipotetičen; ne predstavlja resničnega incidenta, laboratorijskega preizkusa ali ugotovljenega CVE. [1]
Prvo sporočilo kljub temu ne sme obtičati v predalu. Proizvajalec lahko potrebuje takojšnje tehnične ukrepe, ne da bi bil za obvezno prijavo po 14. členu že izpolnjen predpisani pogoj. Uredba v členu 15 predvideva tudi prostovoljno poročanje o širšem naboru varnostnih pojavov. ENISA je 15. oktobra 2026 pojasnila, da prostovoljni del platforme SRP tedaj še ni bil na voljo. Tehnična obravnava napake, prostovoljno razkritje in obvezna zakonska prijava zato zahtevajo vsak svojo presojo. [1][3]
Resen incident je samostojen razlog za prijavo
Pri drugem sprožilcu morda sploh ni mogoče pokazati na aktivno izrabljeno ranljivost. Proizvajalec na primer ugotovi, da je bil posežen postopek priprave njegove programske izdaje in da bi posledica lahko bilo izvajanje zlonamerne kode v izdelku, ki ga prejmejo uporabniki. Če okoliščine dosegajo merila iz člena 14(5), gre lahko za resen incident, ki vpliva na varnost izdelka z digitalnimi elementi, za katerega obveznost poročanja določa člen 14(3). [1]
Uredba pri tem ne govori o vsaki informacijski motnji pri proizvajalcu. Resnost povezuje z dejanskim ali možnim negativnim vplivom na zmožnost izdelka, da varuje razpoložljivost, avtentičnost, celovitost ali zaupnost občutljivih oziroma pomembnih podatkov ali funkcij, ali z nastankom oziroma možnostjo vnosa ali izvajanja zlonamerne kode v izdelku ali uporabnikovem informacijskem okolju. Okužba nepovezane pisarniške naprave sama po sebi teh pogojev še ne dokazuje. [1]
Preiskovalna vprašanja so zato usmerjena v izdelek: katera njegova funkcija je prizadeta, ali bi lahko prišla do uporabnika zlonamerna koda, kaj je bilo dejansko distribuirano in na čem temelji presoja vpliva. Ni treba umetno iskati aktivne izrabe ranljivosti, če so dokazi pomembni za drug zakonski sprožilec. Prav tako dveh dogodkov ni pravilno združiti zgolj zato, ker ju je zaznala ista varnostna skupina.
Odločitev pred oddajo: kaj je treba razčistiti
Koristno je vzpostaviti kratek vrstni red vprašanj, ki se začne zunaj poročevalskega obrazca. Kdo nastopa kot proizvajalec in za kateri izdelek? Ali je izdelek zajet s področjem uporabe uredbe? Katero dejstvo sproži člen 14? Zanesljiv dokaz o aktivni izrabi ali resen incident s predpisanim vplivom na varnost izdelka? Kdaj je proizvajalec izvedel za to dejstvo? In nazadnje: kdo ima pooblastilo in podatke za oddajo obvestila pristojnemu koordinatorju?
Prezgodnja klasifikacija lahko iz dovoljenega raziskovalnega preizkusa naredi navidezno zakonsko obveznost. Prepozna odločitev pa lahko povzroči zamudo, čeprav je proizvajalec že imel zanesljive podatke za prijavo. Poznejša formalna odobritev sama po sebi ne spremeni pravno pomembnega trenutka seznanitve. [1][3]
Za časovnico ga označimo s T0. Z njim ni treba enačiti datuma, ko je nastala ranljivost, ko je bil objavljen CVE ali ko je prvič zazvonil nadzorni sistem. Ugotoviti je treba, kdaj so bile proizvajalcu na voljo informacije, ki izkazujejo ustrezni zakonski dogodek. Kadar se dokazna slika spreminja, je pomembno ohraniti razlog, zakaj je bil takrat izbran določen začetek rokov.
Zgodnje opozorilo in dva različna zaključka
Za aktivno izrabljeno ranljivost in za resen incident člen 14 določa zgodnje opozorilo brez nepotrebnega odlašanja, najpozneje 24 ur po seznanitvi. Naslednje obvestilo sledi brez nepotrebnega odlašanja, najpozneje 72 ur po isti seznanitvi. Drugi rok ne začne teči šele po oddaji prvega opozorila. V zgodnji fazi ni treba zatrjevati, da je vzrok že dokončno ugotovljen; uredba predvideva dopolnjevanje podatkov, in če so določene informacije že bile posredovane, jih ni treba neupravičeno podvajati. [1]
Če je T0 denimo ponedeljek ob 10. uri, je zadnji mejnik zgodnjega opozorila torek ob 10. uri, naslednjega obvestila pa četrtek ob 10. uri. To je zgolj prikaz računanja relativnih rokov, ne opis resničnega dogodka ali dovoljenje za čakanje do zadnje minute. Zahteva »brez nepotrebnega odlašanja« velja tudi takrat, ko je podatke mogoče poslati prej.
Končni poročili sta urejeni različno. Pri aktivno izrabljeni ranljivosti proizvajalec končno poročilo predloži najpozneje 14 dni po tem, ko je na voljo popravni ali blažilni ukrep. Pri resnem incidentu ga predloži v enem mesecu po oddaji 72-urnega obvestila o incidentu. Če je popravni ukrep na voljo precej pozneje od prvega opozorila, se štirinajstdnevni rok ne izteče avtomatično štirinajsti dan po T0. Pri incidentu pa je za končni rok pomemben dejanski čas oddaje obvestila iz druge faze. Pristojni CSIRT lahko zahteva še vmesno poročilo. [1][2]
SRP pozna proizvajalca; rok mora poznati proizvajalec
Prijava se predloži prek enotne platforme za poročanje, Single Reporting Platform (SRP), ki jo upravlja ENISA. Proizvajalec izbere skupino CSIRT, imenovano za koordinatorja, po naveznih okoliščinah iz člena 14(7), praviloma glede na svoj glavni sedež v Uniji. Oddaja je povezana s proizvajalcem in njegovimi pooblaščenimi predstavniki, ne s splošnim uporabniškim računom organizacije, ki je napako odkrila. [1][3]
Po operativnih navodilih ENISA predstavnik dostopa z osebnim računom EU Login in večfaktorsko avtentikacijo. Primarni predstavnik lahko poveže proizvajalca s sekundarnimi predstavniki; pooblaščeni predstavniki lahko nadaljujejo že predloženo prijavo, osnutki pa ostanejo v osebnem računu tistega, ki jih je ustvaril. Če se med obravnavo zamenja dežurna oseba, je ta razlika pomembna: nedokončan osnutek in že predloženo obvestilo nista enako dostopna. Gre za dokumentirano delovanje platforme, ne za dodatno zahtevo iz besedila uredbe. [3]
Posebno previdnost zahteva prikaz rokov. ENISA je v različici pojasnil z dne 15. oktobra 2026 zapisala, da je takratni števec za 72-urno obvestilo izhajal iz 48 ur po predložitvi zgodnjega opozorila, ne neposredno iz T0. Zato je lahko v določenih primerih sporočal zamudo, čeprav zakonskih 72 ur od seznanitve še ni poteklo. Agencija je napovedala spremembo izračuna. To je časovno določena ugotovitev o platformi; zakonska obveznost se ravna po uredbi, ne po prikazani barvi opozorila. [3]
ENISA je obenem pojasnila, da tedanja različica ni samodejno računala končnega roka za aktivno izrabljeno ranljivost, ker je ta odvisen od razpoložljivosti ukrepa. Za resen incident je prikazovala en mesec po predložitvi ustreznega obvestila. Pravilno časovno evidenco mora zato proizvajalec voditi tudi zunaj SRP. Smiselno je shraniti potrditve oddaje in podatek, na katerem temelji izračun; opozorilo v uporabniškem vmesniku je lahko pomoč pri delu, ne dokaz pravne zamude. [3]
Obvestilo organu in opozorilo uporabniku imata različna naslovnika
Prek SRP je prijava namenjena pristojnemu CSIRT in, ob običajnem poteku, agenciji ENISA. Koordinator nato informacije razpošlje relevantnim skupinam CSIRT drugih držav članic, v katerih je izdelek na voljo. V posebej izjemnih okoliščinah lahko pristojni CSIRT odloči o omejitvi ali odlogu nadaljnjega posredovanja občutljivih informacij. Izjema iz člena 16(2) ne pomeni, da sme proizvajalec samovoljno opustiti prvotno prijavo ali jo nadomestiti z javno objavo. [1][2][3]
Člen 14(8) ureja tudi ravnanje do uporabnikov. Proizvajalec mora po seznanitvi z ustreznim dogodkom obvestiti prizadete uporabnike, kadar je ustrezno pa tudi vse uporabnike, ter jih po potrebi seznaniti z ukrepi za zmanjšanje tveganja. Prijava v sistemu SRP uporabniku sama po sebi ne pove, ali mora določeno funkcijo začasno izključiti, namestiti posodobitev ali uporabiti drug blažilni ukrep. Sporočanje organom in zaščitno obveščanje uporabnikov sta povezani, vendar ločeni opravili. [1]
Če SRP začasno ni dosegljiv, ENISA priporoča oddajo po ponovni vzpostavitvi. Proizvajalec lahko vmes, kadar oceni, da je potrebno takojšnje obveščanje, neposredno kontaktira pristojni CSIRT, vendar mora prijavo pozneje še vedno predložiti prek platforme. To operativno pojasnilo ne ustvarja splošne izjeme od zakonske dolžnosti poročanja; pokaže, zakaj je treba vedeti, kako ukrepati tudi ob izpadu portala. [3]
Starejši izdelek, odprtokodna podpora in meja začetka uporabe
Obveznosti iz 14. člena se od 11. septembra 2026 nanašajo tudi na starejše izdelke z digitalnimi elementi, če sodijo na področje CRA. Ni odločilen datum, ko je bila naprava prodana ali programska oprema prvič izdana. Prav tako se ne nalaga splošno naknadno poročanje o že znani aktivni izrabi pred tem datumom. Če je proizvajalec vedel za ranljivost, dokaze o njeni aktivni izrabi pa je prejel šele po začetku uporabe člena 14, nova seznanitev lahko sproži poročanje. [2][3]
Pri odprtokodnih projektih je treba razlikovati med avtorjem, proizvajalcem in upravljavcem odprtokodne programske opreme po členu 3(14). Za slednjega člen 24(3) določa posebna pravila: prijavljanje aktivno izrabljenih ranljivosti v obsegu njegovega sodelovanja pri razvoju, pri resnih incidentih pa v povezavi z omrežji in informacijskimi sistemi, ki jih zagotavlja za razvoj teh izdelkov. Te obveznosti se na podlagi člena 71(2) začnejo uporabljati 11. decembra 2027. Objava izvorne kode pod odprto licenco sama ne odloči o statusu zavezanca. [1][2]
Dokument, s katerim je mogoče pojasniti prijavo
Pri končanem postopku morajo biti razvidni vsaj predmet in pravna vloga proizvajalca, dokazi o aktivni izrabi oziroma vplivu incidenta na varnost izdelka, prvotni in pozneje prejeti podatki, odločilni trenutek seznanitve ter datumi obvestil. Uporabno je dodati identifikacijo prizadetih izdaj, pristojnega koordinatorja, potrditve iz SRP, datum razpoložljivosti popravnega ali blažilnega ukrepa in besedila opozoril uporabnikom. Gre za predlagan način urejanja dokaznega gradiva, ne za dodatni obrazec, ki bi ga CRA predpisoval v takšni obliki. [1][3]
Najzahtevnejši primer ni nujno pravočasno oddana prijava. Lahko je prvotna odločitev, da prijava še ni bila obvezna, po kateri prispe nov dokaz in se pravni položaj spremeni. Takrat mora evidenca pokazati, zakaj laboratorijski prikaz ob prvem obvestilu ni zadoščal ter kateri kasnejši podatek je omogočil drugačno presojo. Zgolj oznaka »ranljivost obravnavana« tega ne pove.
Če bo pristojni organ pozneje zahteval pojasnilo, zgolj potrditveno sporočilo iz SRP ne bo razjasnilo začetne odločitve. Poiskati bo treba prvotne dokaze o izdelku, o izrabi ali vplivu incidenta ter o času, ko jih je proizvajalec prejel. Ti podatki določijo, katera prijava je bila potrebna in kdaj.
EVIDENCE PROFILE
Dokazni profil članka
Profil pokaže vrsto dokazne podlage in omejitve osrednjega argumenta.
Viri
- 01PRIMARY DOCUMENTATIONEvropski parlament in Svet Evropske unijeUredba (EU) 2024/2847 – Akt o kibernetski odpornosti
Uradno slovensko besedilo, 20. 11. 2024. Členi 2, 3(13), 3(14), 3(41)–(42), 14(1)–(8), 15, 16, 21, 22, 24(3), 71(2). Pravno zavezujoči vir.
Odpri vir ↗ - 02PRIMARY DOCUMENTATIONEvropska komisija (DG CNECT)Cyber Resilience Act – Reporting obligations
Uradno pojasnilo, posodobljeno 11. 9. 2026. Razdelka »What are the main rules?« in »Where should manufacturers submit their notifications?«.
Odpri vir ↗ - 03PRIMARY DOCUMENTATIONENISAFrequently Asked Questions: All you need to know about the CRA Single Reporting Platform
Operativna dokumentacija, stanje 15. 10. 2026. Vprašanja 7–9, 12–14, 21, 25–27 in 29–30. Opisane posebnosti SRP so časovno omejene.
Odpri vir ↗ - 04PRIMARY DOCUMENTATIONUrad Vlade Republike Slovenije za informacijsko varnostAkt o kibernetski odpornosti: 11. septembra 2026 se začnejo uporabljati obveznosti poročanja
Uradno slovensko pojasnilo, 1. 9. 2026. Začetek uporabe poročevalskih obveznosti in slovenski institucionalni okvir.
Odpri vir ↗