Odprtokodne komponente po CRA: kdo odgovarja za ranljivost v digitalnem proizvodu?
Odprta koda ni avtomatično izvzeta iz CRA; odločilni so komercialni kontekst in vloga proizvajalca končnega proizvoda.
AI-ilustracija
Akt EU o kibernetski odpornosti določa varnostne obveznosti za proizvode z digitalnimi elementi skozi njihov življenjski cikel. Odprta koda ni avtomatično izvzeta: pomembno je, ali se razvija ali daje na trg v komercialni dejavnosti ter kdo jo vključi v končni proizvod.
Sodobna programska oprema temelji na stotinah zunanjih paketov. Proizvajalec končnega proizvoda ne more prenesti celotne odgovornosti na prostovoljnega vzdrževalca knjižnice. Potrebuje popis komponent, spremljanje ranljivosti, varne posodobitve in postopek razkritja.
1. Ali CRA velja za vso odprto kodo?
Ne na enak način. Programska oprema, razvita ali dobavljena zunaj komercialne dejavnosti, je posebej obravnavana, komercialna ponudba pa lahko pade v polni režim. Odločilni so dejanski način razvoja, distribucije in monetizacije.
Sama brezplačna licenca ne dokazuje nekomercialnosti. Plačljiva podpora, nadzor podjetja ali vključitev v tržni proizvod lahko spremenijo vlogo posameznega subjekta.
2. Kdo je proizvajalec končnega proizvoda?
Podjetje, ki razvije ali trži proizvod pod svojim imenom ali znamko, praviloma nosi obveznosti proizvajalca. To velja tudi, ko večino programske opreme sestavljajo zunanje komponente.
Pogodba z izvajalcem lahko razdeli delo in regres, ne odpravi pa zakonske odgovornosti do trga. Proizvajalec mora imeti dovolj tehničnega nadzora za posodobitve in incidente.
AI-ilustracija3. Kaj je programski seznam sestavin?
SBOM je strukturiran popis programskih komponent in njihovih različic. Omogoča hitro ugotovitev, kateri proizvodi vsebujejo ranljivo knjižnico.
Popis mora nastajati v procesu izdelave in biti posodobljen ob izdaji. Ročna tabela, ki ne sledi dejanski različici proizvoda, daje lažen občutek nadzora.
KOMU POROČATI O KIBERNETSKEM INCIDENTU
4. Kako podjetje spremlja ranljivosti?
Poveže popis komponent z zanesljivimi viri obvestil, oceni izpostavljenost in določi rok ukrepanja. Visoka splošna ocena še ne pomeni enakega tveganja v vsaki konfiguraciji.
Odločitev o neukrepanju mora biti dokumentirana. Če komponenta ni dosegljiva napadalcu, to dokažite in ponovno preverite ob spremembi arhitekture.
5. Kaj mora podjetje zahtevati od dobavitelja?
Informacije o komponentah, politiko ranljivosti, roke popravkov, varno dostavo posodobitev in obveščanje o incidentih. Pri kritičnem dobavitelju je pomembna tudi možnost nadaljevanja vzdrževanja.
Odprtokodna licenca pogosto ne daje jamstva. Podjetje mora zato samo oceniti projekt, skupnost, pogostost izdaj in možnost notranjega popravka.
AI-ilustracija6. Kako se prijavljajo ranljivosti in incidenti?
Proizvajalci od 11.09.2026 poročajo o aktivno izrabljenih ranljivostih in resnih incidentih; za skrbnike odprtokodne programske opreme se posebna obveznost poročanja začne uporabljati 11.12.2027. Zgodnje opozorilo se odda v 24 urah, popolnejša prijava pa v 72 urah prek enotne platforme CRA.
Končno poročilo o aktivno izrabljeni ranljivosti je treba oddati najpozneje 14 dni po razpoložljivosti korektivnega ali omilitvenega ukrepa, pri resnem incidentu pa v enem mesecu po 72-urni prijavi. Javna objava pred popravkom lahko poveča škodo, zato naj postopek usklajenega razkritja poveže raziskovalca, vzdrževalca, proizvajalca in pristojni organ.
7. Kako začeti s skladnostjo?
Popišite proizvode, vloge, komponente, podporno obdobje in kanal za prijavo ranljivosti. Nato določite pravila za izbor novih paketov ter odstranitev opuščenih odvisnosti.
Najprej obravnavajte komponente z visokimi privilegiji, omrežnim dostopom in veliko razširjenostjo. Popoln popis brez prednostnega ukrepanja ni upravljanje tveganja.
Brezplačna komponenta ima lahko zelo drag življenjski cikel
Odprta koda pospeši razvoj in omogoča preglednost, vendar nekdo še vedno mora spremljati spremembe, popravljati ranljivosti ter dostaviti posodobitev uporabniku.
Podjetje naj pri izbiri komponente ocenjuje tudi vzdrževanje, ne samo funkcionalnosti. Najcenejša odvisnost ob vgradnji je lahko najdražja ob prvem incidentu.
