Akt o kibernetičkoj otpornosti: uključite obveze u razvoj proizvoda

Akt o kibernetičkoj otpornosti (CRA) uvodi obveze kibernetičke sigurnosti u životni ciklus obuhvaćenih proizvoda s digitalnim elementima. Za CTO-a je praktična zadaća povezati ono što inženjerski tim gradi, isporučuje i održava s dokazima potrebnima za dokazivanje ispunjenja tih obveza.

Ta veza mora funkcionirati na razini proizvoda i verzije. Sigurnosna politika na razini cijele tvrtke ne objašnjava ima li određeno izdanje sigurne zadane postavke, koje ovisnosti sadrži ili kako će klijenti primiti sigurnosno ažuriranje. Zadatak za ranjivost označen kao „ispravljeno“ ne utvrđuje koje podržane verzije ostaju izložene.

Korisna polazna točka stoga je model životnog ciklusa proizvoda: opseg, sigurnosni zahtjevi, dokazi o izdanju, postupanje s ranjivostima, obveze podrške i odluke s jasnom odgovornošću. Taj model ugradite u razvoj, umjesto da ga zasebno sastavljate prije ocjenjivanja.

Definirajte granicu proizvoda prije dodjeljivanja kontrola

CRA se odnosi na proizvode s digitalnim elementima unutar njegova opsega, uključujući obuhvaćeni hardver i softver. To nije univerzalno pravilo za svaku SaaS uslugu. Hostirana usluga i softver koji se distribuira klijentima mogu zahtijevati različite analize, a potrebno je ispitati i obradu na daljinu koja je sastavni dio proizvoda.

Kao polaznu referencu upotrijebite smjernice Europske komisije o CRA-u, a zatim razriješite pravna pitanja specifična za proizvod. Zabilježite zaključak, umjesto da se oslanjate na neformalnu pretpostavku tima.

Za svaki proizvod koji dolazi u obzir utvrdite:

• Što klijenti dobivaju: hardver, instalirani softver, komponente za preuzimanje ili njihovu kombinaciju.
• Koje su funkcije obrade na daljinu potrebne kako bi proizvod obavljao svoje funkcije.
• Kako se proizvod isporučuje na tržište EU-a i koji ga subjekt isporučuje.
• Svoju ulogu gospodarskog subjekta: proizvođač, uvoznik, distributer ili neka druga relevantna uloga.
• Primjenjiva izuzeća, zakonodavstvo specifično za proizvod i pitanja povezana s otvorenim kodom.
• Kategoriju proizvoda i zahtjeve za ocjenjivanje sukladnosti koji iz nje proizlaze.

Otvoreni kod zahtijeva posebnu pažnju. Način postupanja sa softverom koji se isporučuje izvan komercijalne djelatnosti ne znači da komercijalni proizvođač može zanemariti komponente otvorenog koda ugrađene u svoj proizvod. Razlikujte položaj uzvodnog suradnika od svoje odgovornosti za proizvod koji isporučujete.

Inženjerski rezultat treba biti kratak zapis o opsegu s arhitektonskim dijagramom, identifikatorima proizvoda, relevantnim komercijalnim subjektima, pretpostavkama i odobrenim zaključkom. Imenujte osobu odgovornu za ponovno otvaranje tog zaključka kada se promijene funkcionalnost ili distribucija.

Na primjer, aplikacija za upravljanje koja se preuzima i njezina hostirana analitička usluga ne bi automatski trebale dobiti jednu nediferenciranu odluku o opsegu. Utvrdite koje funkcije rade lokalno, koje ovise o usluzi i pripada li ta obrada na daljinu unutar granice proizvoda. Ta razlika utječe na procjenu rizika, zapise o ovisnostima i vlasništvo nad incidentima.

Polazite od aktualnih datuma primjene

Komisija navodi 11. rujna 2026. za obveze izvješćivanja i 11. prosinca 2027. za glavne zahtjeve CRA-a. Na dan 7. listopada 2026. datum za izvješćivanje već je prošao. Spremnost za izvješćivanje tretirajte kao aktualan operativni zahtjev, a ne kao zadatak odgođen do pripreme za sukladnost.

Držite vidljivima dva tijeka rada:

Proizvodi isporučeni prije glavnog datuma primjene zahtijevaju pozornost u pogledu prijelaznih odredbi i bitnih izmjena. Nemojte pretpostaviti da je stariji proizvod nevažan za izvješćivanje samo zato što je njegovo izvorno izdanje prethodilo prosincu 2027.

Održavajte datirani registar pravnih zahtjeva. Za pragove događaja, postupne rokove izvješćivanja, primatelje i postupke podnošenja provjerite aktualni pravni tekst i službene provedbene smjernice. Nemojte postupak specifičan za CRA zamijeniti generičkim predloškom za odgovor na incidente.

Pretvorite sigurnosne zahtjeve u kriterije dizajna i izdanja

Bitni zahtjevi CRA-a obuhvaćaju sigurnosna svojstva proizvoda i postupanje s ranjivostima. Njihova implementacija treba slijediti procjenu kibernetičkih sigurnosnih rizika proizvoda, a ne univerzalni kontrolni popis primijenjen bez arhitektonskog konteksta.

Počnite s načinom na koji proizvod može prouzročiti štetu. Opišite korisnike, okruženja primjene, izložena sučelja, privilegirane operacije, osjetljive podatke i predvidivu zlouporabu. Uključite operativne pretpostavke klijenta: uređaj postavljen u industrijsku mrežu ima drukčiju izloženost i ograničenja oporavka od uslužnog programa za stolno računalo.

Praktična vježba modeliranja prijetnji može podržati taj rad; OWASP-ove smjernice za modeliranje prijetnji pružaju utvrđen pristup. Rezultat treba povezati prijetnje s konkretnim zahtjevima, odlukama o implementaciji i testovima.

Razmotrite kako poznati zahtjevi postaju provjerljivi:

To su praktični primjeri implementacije, a ne zamjena za primjenjive zahtjeve. Relevantnost i dostatnost utvrdite procjenom rizika.

Kriterije sigurnosnog prihvaćanja dodajte radu na funkcijama. Novi administrativni API treba stići s odlukama o autentifikaciji, autorizaciji, obradi ulaza i zapisivanju, a ne s obećanjem da će ga sigurnosni tim kasnije pregledati. Ponovno pregledajte model prijetnji pri dodavanju udaljenog sučelja, privilegirane komponente ili nove granice povjerenja.

Odobrenje izdanja treba utvrditi neriješene ranjivosti, njihovu iskoristivost, pogođene konfiguracije i postupanje s njima. Primijenite zahtjev CRA-a da se proizvodi stavljaju na raspolaganje na tržištu bez poznatih iskoristivih ranjivosti, uzimajući u obzir procjenu rizika i primjenjive bitne zahtjeve; samo bilježenje ili prihvaćanje rizika ne ispunjava taj zahtjev. Rezultat skenera sam po sebi ne može donijeti tu odluku: važni su dostupnost ranjivog koda, preduvjeti i ponašanje proizvoda. S druge strane, niska brojčana ocjena ozbiljnosti nije dovoljan razlog za zanemarivanje ranjivosti koja je značajna u vašem modelu primjene.

Zapis o izdanju treba povezati odobrenu reviziju izvornog koda, artefakt izgradnje, inventar ovisnosti, rezultate testova i sigurnosnu odluku. Time procjena postaje ponovljiva kada klijent ili tijelo kasnije postavi pitanje o određenoj verziji.

Učinite dubinsku analizu komponenti dijelom procesa izgradnje

Komponente trećih strana stvaraju obveze koje se ne mogu ispuniti prosljeđivanjem uzvodne sigurnosne obavijesti. Morate razumjeti što ste isporučili, je li to pogođeno i kako to možete otkloniti.

CRA u okviru zahtjeva za postupanje s ranjivostima uključuje zahtjev za softverskim popisom materijala (SBOM): u uobičajeno korištenom, strojno čitljivom formatu koji obuhvaća barem ovisnosti najviše razine. Kao praktičnu preporuku, bilježite dublje informacije o ovisnostima gdje god vaši alati za izgradnju mogu dati pouzdane rezultate. Tranzitivne ovisnosti često određuju izloženost.

SBOM je koristan samo kada odgovara stvarnom artefaktu proizvoda. Povežite ga s identifikatorom izdanja i izgradnjom te razlikujte isporučene komponente od alata koji se koriste samo u razvoju. Gdje je relevantno, uključite firmver, pakete operacijskog sustava, priložene biblioteke i komercijalne komponente; izvoz iz upravitelja paketa može propustiti nekoliko njih.

Pregled komponenti izgradite oko pitanja koja mijenjaju inženjerske odluke:

• Održava li se komponenta i je li njezin podržani vijek trajanja usklađen s našim?
• Možemo li brzo dobiti informacije o ranjivostima i sigurnosna ažuriranja?
• Imamo li pristup izvornom kodu, put za zakrpe od dobavljača ili strategiju zamjene?
• Uvodi li komponenta privilegirano izvršavanje ili novu vanjsku vezu?
• Može li se proizvod i dalje održavati ako dobavljač prestane podržavati komponentu?

Za komercijalne komponente nabava treba utvrditi sigurnosne kontakte, aranžmane obavješćivanja i pristup ispravcima. Rokovi dobavljača moraju ostaviti prostor za vašu vlastitu procjenu i obveze izvješćivanja. Proizvođaču proizvoda i dalje je potreban interni put eskalacije kada je odgovor dobavljača nepotpun.

Za ovisnosti otvorenog koda sačuvajte podrijetlo i realan plan održavanja. Javna dostupnost repozitorija nije dokaz da će netko izraditi kompatibilnu zakrpu tijekom vašeg razdoblja podrške.

Razdoblje podrške i mehanizam ažuriranja dizajnirajte zajedno

Podrška je inženjerska obveza s komercijalnim posljedicama. CRA u pravilu zahtijeva razdoblje podrške od najmanje pet godina, osim ako je očekivano razdoblje korištenja proizvoda kraće. Primjenjivo razdoblje utvrdite prema kriterijima Uredbe, a ne odabirom proizvoljnog datuma koji odgovara planu razvoja.

Zabilježite obrazloženje, priopćite klijentima potrebne informacije o podršci i povežite ih s održavanim verzijama proizvoda. Obveza podrške mora uzeti u obzir sposobnost isporuke sigurnosnih ažuriranja, a ne samo zadržavanje adrese službe za pomoć.

Prije odobravanja plana podrške za proizvod pitajte možete li:

• Ponovno izgraditi starije podržane grane s održavanim skupovima alata.
• Sigurno izraditi, autentificirati i distribuirati sigurnosna ažuriranja.
• Testirati ispravke na podržanom hardveru i konfiguracijama primjene.
• Održavati ključeve za potpisivanje i sigurno se oporaviti od njihove kompromitacije.
• Zadržati dostupnima informacije o ažuriranjima i sigurnosti namijenjene klijentima.
• Postupati s ovisnostima čija uzvodna podrška završava prije vaše.

Sigurnosna ažuriranja u pravilu se tijekom razdoblja podrške moraju pružati besplatno, u skladu s odredbama Uredbe. Svako sigurnosno ažuriranje izdano tijekom tog razdoblja mora ostati dostupno najmanje deset godina od izdavanja ili do kraja razdoblja podrške, ovisno o tome što je dulje. Sigurnosne ispravke planirajte odvojeno od razvoja funkcija kako klijenti ne bi bili nepotrebno prisiljeni na nepovezane funkcionalne promjene.

Testirajte više od idealnog scenarija. Prekinuta instalacija, nedovoljno prostora za pohranu, istekle vjerodajnice i neuspjela provjera mogu valjanu zakrpu pretvoriti u problem dostupnosti. Odlučite koji su mehanizmi oporavka potrebni za profil rizika proizvoda.

Na kraju podrške komunikacija s klijentima i interni zapisi trebaju biti usklađeni. Nemojte ostaviti stranicu za preuzimanje koja implicira nastavak sigurnosnog održavanja kada registar proizvoda navodi da je obveza završila.

Izradite operativni priručnik za izvješćivanje koji funkcionira i u nesigurnosti

Uobičajeni nalaz o ranjivosti, aktivno iskorištavana ranjivost i ozbiljan sigurnosni incident nisu međusobno zamjenjivi. Postupak izvješćivanja prema CRA-u zahtijeva dokumentiranu procjenu relevantnog okidača, a ne automatsko prijavljivanje svakog upozorenja skenera niti automatsko odbacivanje svega bez dovršene forenzičke istrage.

Operativni priručnik treba početi zaprimanjem. Istraživači, korisnička podrška, dobavljači i inženjerski timovi trebaju poznat put do funkcije sigurnosti proizvoda. Sačuvajte izvornu prijavu i zabilježite kada su relevantne informacije postale poznate; nemojte ponovno postavljati vremenske oznake saznanja kada zadatak prijeđe u drugi tim.

Za događaje koji bi mogli podlijegati izvješćivanju prikupite:

• Identifikatore proizvoda i pogođene podržane verzije.
• Dokaze o iskorištavanju ili učinku incidenta, s razinom pouzdanosti i nesigurnostima.
• Poznate uvjete napada, pogođene funkcije i pretpostavke o primjeni.
• Dostupne mjere ublažavanja i status korektivnih mjera.
• Procjenu okidača, vlasnika izvješćivanja i izračune primjenjivih rokova.
• Podnesene obavijesti, potvrde primitka, naknadna ažuriranja i komunikaciju s klijentima.

Provjerite postupne rokove obavješćivanja, zahtjeve za završno izvješće, primatelje i aktualni postupak izvješćivanja u službenim izvorima. Aktivno iskorištavane ranjivosti i ozbiljni incidenti imaju različite pojedinosti izvješćivanja; jedno kopirano polje za rok nije dovoljno.

Dodijelite primarnog vlasnika izvješćivanja i zamjenika s ovlašću koordiniranja inženjerske, pravne i klijentske komunikacije. Unaprijed osigurajte pristup primjenjivom mehanizmu izvješćivanja. Pravni pregled treba biti dostupan unutar roka za izvješćivanje, a ne postati neograničeni red čekanja na odobrenje.

Vježbajte postupak s nepotpunim informacijama. Korisna proba počinje vjerodostojnom prijavom iskorištavanja, nesigurnim popisom pogođenih verzija i nedostupnim dobavljačem komponente. Tim treba moći donijeti pravodobnu, dokumentiranu odluku o izvješćivanju dok istraga traje.

Izvješćivanje prema CRA-u ne zamjenjuje druge primjenjive obveze. Događaj povezan s proizvodom mogao bi zahtijevati i procjenu prema propisima o zaštiti podataka ili prema ugovoru s klijentom. Koordinirajte te procjene, ali sačuvajte njihove zasebne okidače, primatelje i zapise o odlukama.

Potvrdite klasifikaciju prije odabira plana ocjenjivanja

Klasifikacija proizvoda utječe na dostupan postupak ocjenjivanja sukladnosti. Nemojte pretpostaviti da svaki povezani proizvod treba isto vanjsko ocjenjivanje ni da se svaki proizvođač može osloniti na interno ocjenjivanje.

Primjenjivu kategoriju utvrdite na temelju funkcija proizvoda te definicija i priloga Uredbe. Zatim potvrdite dopušteni postupak, uključujući sve uvjete koji se odnose na usklađene norme, priznate specifikacije, programe certifikacije ili ocjenjivanje treće strane.

Planiranje normi zahtijeva izričit registar ovisnosti: koje su reference primjenjive, kakav je njihov aktualni status i što se mijenja ako očekivani postupak nije dostupan. Izbjegavajte da plan izdanja ovisi o nepotvrđenoj pretpostavci o normama ili kapacitetu za ocjenjivanje.

Ponovno pregledajte klasifikaciju kada se funkcionalnost promijeni. Dodavanje mogućnosti upravljanja sigurnošću ili kontrole mreže može utjecati na analizu, ali sam naziv funkcije ne određuje kategoriju. Procijenite stvarnu funkciju i dokumentirajte zaključak.

Klasifikaciju, odabrani postupak i rezultate povezane sa sukladnošću držite povezanima s tehničkom dokumentacijom. Oznaka CE i EU izjava o sukladnosti moraju slijediti primjenjivi postupak; one nisu zamjena za implementaciju temeljnih zahtjeva.

Održavajte paket dokaza koji može objasniti izdanje

Tehnička dokumentacija treba opisati i proizvod i obrazloženje njegovih sigurnosnih odluka. Čuvajte procjene rizika i dokumentaciju kako se proizvod mijenja i primijenite zakonske zahtjeve čuvanja na relevantne zapise.

Koristan paket dokaza o proizvodu uključuje odluku o opsegu, arhitekturu, procjenu rizika, sigurnosne zahtjeve, informacije o komponentama, rezultate provjere, postupke za postupanje s ranjivostima, obrazloženje podrške i zapise o sukladnosti. Svaka stavka treba vlasnika i prepoznatljivu verziju.

Za povezivanje tih zapisa koristite stabilne identifikatore. Zapis o ranjivosti treba objasniti pogođene verzije, izloženost, postupanje, izdanje i potrebnu komunikaciju. „Ispravljeno“ bez konteksta verzije ostavlja dokaze o proizvodu nepotpunima.

Postojeći ISMS procesi mogu pružiti korisne dokaze o upravljanju, dobavljačima i sigurnom razvoju. Međutim, ISO 27001 odnosi se na sustav upravljanja informacijskom sigurnošću s definiranim opsegom; certifikacija ne dokazuje sukladnost pojedinačnog proizvoda s CRA-om. Ponovno upotrijebite relevantne dokaze, ali mapiranja okvira nemojte tretirati kao pravnu istovjetnost.

Razrađeni primjer: greška u ovisnosti podržanog uređaja

Razmotrimo ilustrativnog proizvođača koji u EU-u isporučuje uređaj povezan s mrežom. Pretpostavimo da su njegov opseg i klasifikacija pregledani, da dvije grane izdanja ostaju podržane i da je za priloženu biblioteku prijavljeno da se negdje drugdje aktivno iskorištava.

Prva zadaća nije zatvoriti uzvodno sigurnosno upozorenje. Inženjerski tim utvrđuje koje izgradnje uređaja sadrže ranjivu biblioteku i je li pogođena funkcija dostupna. SBOM upućuje na to da je obje grane sadrže, ali analiza konfiguracije pokazuje različitu izloženost. Ta se razlika bilježi zajedno s popratnim dokazima.

Vlasnik sigurnosti proizvoda zatim procjenjuje ispunjavaju li dostupne činjenice primjenjivi okidač za izvješćivanje prema CRA-u. Nesigurnost u vezi s jednom konfiguracijom primjene bilježi se; ona ne opravdava ostavljanje donositelja odluke neimenovanim. Operativni priručnik za izvješćivanje pruža aktualne faze i postupak obavješćivanja.

Inženjerski tim razvija privremenu mjeru ublažavanja i izgradnju sa zakrpom za svaku pogođenu granu. Testovi obuhvaćaju ranjivi put, uobičajeni rad i autentificiranu instalaciju ažuriranja. Ako jedna grana ne može koristiti uzvodnu zakrpu, tim bilježi alternativno postupanje i preostali rizik, umjesto da cijeli proizvod označi ispravljenim.

Komunikacija s klijentima navodi pogođene verzije, neposredne zaštitne radnje i način dobivanja ažuriranja. Vrijeme objave usklađuje se s primjenjivim zahtjevima za postupanje s ranjivostima i svim opravdanim sigurnosnim razlozima.

Dovršeni zapis povezuje sigurnosno upozorenje, analizu pogođenih izgradnji, odluku o izvješćivanju, podneske kada su potrebni, commitove sa zakrpama, rezultate testova, artefakte izdanja i komunikaciju. Revizor sada može rekonstruirati i inženjerski odgovor i odluku o usklađenosti.

Počnite s jednim proizvodom i jednim potpunim lancem dokaza

Odaberite reprezentativan podržani proizvod i pratite jedno nedavno izdanje i jednu ranjivost kroz životni ciklus. Nedostajuće veze s verzijama, nejasne obveze podrške i nedostupni postupci izvješćivanja brzo će postati vidljivi. Svaku prazninu pretvorite u zadatak s vlasnikom, a zatim proširite model na cijeli portfelj.

Secani može podržati ovaj tijek rada s dokazima povezivanjem zahtjeva, dokaza, vlasnika, zadataka i odluka o pregledu. Inženjerski alati ostaju operativni izvori za izgradnje, izdanja i ranjivosti; radni prostor za usklađenost povezuje te zapise s primjenjivom obvezom. Za mapiranja i zaključke zadržite izričito ljudsko odobrenje te sačuvajte sljedivost izvora pri korištenju nacrta potpomognutih umjetnom inteligencijom.

Neposredni sljedeći korak je testiranje operativnog priručnika za izvješćivanje. Usporedno zahtijevajte da sljedeće izdanje proizvoda sadrži povezanu odluku o opsegu, aktualnu procjenu rizika, inventar komponenti i sigurnosno odobrenje. Time se stvara ponovljiva inženjerska praksa dok priprema za sukladnost napreduje.