Kibernetinio atsparumo aktas (CRA): 14 straipsnio pranešimų parengimas gamintojams

Nuo 2026 m. rugsėjo 11 d. įsigalioja viena griežčiausių ir arčiausiai esančių Europos Sąjungos (ES) kibernetinio saugumo prievolių gamintojams. Kibernetinio atsparumo aktas (CRA, angl. Cyber Resilience Act, Reglamentas (ES) 2024/2847) nuo šios datos reikalauja per griežtus terminus pranešti apie aktyviai išnaudojamus pažeidžiamumus ir sunkius saugumo incidentus. Tai nėra rekomendacija ar 2027-ųjų reikalas – tai teisinė pareiga, prasidedanti jau dabar. Šiame straipsnyje paaiškiname, ką konkrečiai reikalauja CRA 14 straipsnis, kam jis taikomas ir kaip pasiruošti, kol dar nekilo pirmasis incidentas.

Kas yra Kibernetinio atsparumo aktas (CRA)?

Kibernetinio atsparumo aktas nustato vienodus kibernetinio saugumo reikalavimus visiems produktams su skaitmeniniais elementais, pateikiamiems į ES rinką – nuo daiktų interneto (IoT, angl. Internet of Things) prietaisų ir programinės įrangos iki pramoninės automatikos komponentų. Iš esmės, jeigu produktas turi mikroprocesorių ir gali su kažkuo susisiekti, jis beveik neabejotinai patenka į reglamento taikymo sritį. Nors visos techninės ir dokumentacinės prievolės (CE ženklinimas, techninė dokumentacija, palaikymo laikotarpis) taps privalomos tik nuo 2027 m. gruodžio 11 d., pranešimų prievolė pradedama taikyti anksčiau – nes reglamentu siekiama užtikrinti, kad rinkoje jau išnaudojami pažeidžiamumai būtų greitai identifikuojami, nelaukiant visos atitikties sistemos subrandinimo.

Ką reikalauja CRA 14 straipsnis: 24/72/14 terminai

14 straipsnis nustato du pranešimo veiksnius: aktyviai išnaudojamą pažeidžiamumą (pažeidžiamumą, dėl kurio yra patikimų įrodymų, kad juo pasinaudojo piktavalis) ir sunkų saugumo incidentą. Įvykus tokiam įvykiui, gamintojas privalo laikytis vadinamosios 24/72/14 kadencijos:

• Per 24 valandas nuo sužinojimo – pateikti išankstinį įspėjimą (angl. early warning).
• Per 72 valandas – pateikti išsamesnį pranešimą su turima informacija ir taikomomis priemonėmis.
• Galutinė ataskaita – dėl pažeidžiamumo ne vėliau kaip per 14 dienų nuo tada, kai tampa prieinama taisomoji priemonė; dėl sunkaus incidento – per vieną mėnesį nuo 72 valandų pranešimo.

Šalia to gamintojas privalo informuoti paveiktus naudotojus, o jeigu pažeidžiamumas kyla iš integruoto trečiosios šalies ar atvirojo kodo komponento – vis tiek pats atsako už pranešimą. Svarbu suprasti, ko 14 straipsnis nereikalauja: iki 2026 m. rugsėjo nebūtina turėti visos pažeidžiamumų valdymo sistemos. Tačiau praktikoje gamintojas negali pranešti apie tai, ko neaptinka – todėl minimalus gebėjimas aptikti pažeidžiamumus (per programinės įrangos medžiagų sąrašą – SBOM, angl. Software Bill of Materials – reguliarų testavimą ar atskleidimo kanalą) yra būtina sąlyga prievolei įvykdyti.

Kam taikoma prievolė

Dažna klaidinga nuomonė, kad pranešimų prievolė galios tik naujiems produktams. Iš tikrųjų 14 straipsnis taikomas ir produktams, jau pateiktiems į rinką iki 2027 m. gruodžio 11 d. Praktiškai tai reiškia, kad net prieš kelerius metus išleistas ir daugiau neatnaujinamas produktas nuo 2026 m. rugsėjo turi turėti veikiantį 24 valandų pranešimo pajėgumą. Būtent dėl to daugelis gamintojų šią prievolę įvertina per vėlai – pasiruošimas apima visą aktyvų produktų portfelį, o ne tik naujus leidimus.

ENISA bendroji pranešimo platforma (SRP)

Pranešimai teikiami per vieną elektroninį kanalą – bendrąją pranešimo platformą (SRP, angl. Single Reporting Platform), kurią administruoja Europos Sąjungos kibernetinio saugumo agentūra (ENISA, angl. European Union Agency for Cybersecurity). Vienu pateikimu pranešimas iš karto nukreipiamas ir ENISA, ir nacionalinei kompiuterinių incidentų tyrimo tarnybai (CSIRT, angl. Computer Security Incident Response Team). Būtina žinoti esminį niuansą: platforma iki šiol dar nėra paleista, o jos viešas adresas iki galo nepaskelbtas – ENISA yra įsipareigojusi, kad ji veiks nuo 2026 m. rugsėjo 11 d. Terminai galioja neatsižvelgiant į tai, ar visa platformos aplinka bus galutinai parengta, todėl protingiausias žingsnis – pasiruošti vidinį procesą iš anksto, kad incidento dieną vienintelis naujas dalykas būtų prisijungimo langas.

CRA reikalavimai Lietuvoje

Lietuvoje pagrindinę priežiūros funkciją vykdys rinkos priežiūros institucijos, glaudžiai koordinuojamos su Nacionaliniu kibernetinio saugumo centru (NKSC). NKSC taip pat veiks kaip nacionalinė CSIRT – įstaiga, kuriai gamintojai teiks pranešimus per ENISA administruojamą platformą. Detalus nacionalinis reglamentavimas dar tikslinamas, todėl gamintojams verta sekti NKSC ir ENISA skelbiamas gaires. Šis neapibrėžtumas nėra pretekstas atidėti pasiruošimą – priešingai, jis rodo, kad pačiam gamintojui tenka atsakomybė turėti savo veiksmų planą.

Kaip pasiruošti 14 straipsnio pranešimams

Didžioji dalis to, kas nulemia sklandų pirmą pranešimą, gali būti padaryta jau dabar, be prisijungimo prie platformos:

1. Produktų inventorizacija – kiekvienas parduodamas produktas, programinės aparatinės įrangos versija ir komponentas susiejamas su identifikatoriumi, kurį būtų galima nurodyti pranešime.
2. Aptikimo gebėjimas – SBOM ir pažeidžiamumų atskleidimo kanalas, kad būtų apie ką pranešti.
3. Sprendimų priėmimo procesas – aiškiai paskirtas atsakingas asmuo, turintis įgaliojimus pateikti 24 valandų įspėjimą, kol teisinė peržiūra vyksta lygiagrečiai (produktų saugumo incidentų reagavimo komandos – PSIRT, angl. Product Security Incident Response Team – veiksmų aprašas).
4. Registracija ir bandomasis pateikimas – išankstinė registracija per ES prisijungimo paskyrą, kurią galima susikurti iš anksto.

CRA pranešimų parengties paketas

Būtent šiam terminui skirta mūsų fiksuotos apimties paslauga – CRA 14 straipsnio pranešimų parengties paketas. Per 4–5 darbo dienas įvertiname, ar jūsų produktai patenka į reglamento sritį, parengiame pranešimų procesą ir vidinį veiksmų planą, pritaikytą 24/72/14 kadencijai, bei pasiruošiame registracijai ENISA platformoje. Rezultatas – aiškus, dokumentuotas pasirengimas, kad rugsėjo 11-oji jūsų komandai būtų eilinė diena, o ne skubotas gaisro gesinimas.

Kodėl rinktis mus?

• Reali atitikties patirtis – dirbame tiek su informacinių technologijų (IT), tiek su operacinių technologijų (OT, angl. Operational Technology) aplinkomis.
• ISO/IEC 27001 Lead Auditor (vadovaujančiojo auditoriaus) kompetencija – tarptautiškai pripažinta metodika.
• Techninis pagrindas – programinės aparatinės įrangos sąrankos, SBOM ir pažeidžiamumų valdymo įrankių išmanymas.
• Skaidrumas ir lankstumas – fiksuota apimtis, aiškūs terminai ir konfidencialiai tvarkomi duomenys.

Turime savo programuotojų — kam mums išorės CRA konsultantas?

• Programavimo įgūdis nėra tas pats, kas CRA (Cyber Resilience Act, Reglamentas (ES) 2024/2847) atitikties kompetencija: jūsų inžinieriai kuria produktą, o atitikčiai reikia atskiro darbo su esminiais reikalavimais, technine dokumentacija ir atitikties vertinimo procedūromis. Vietoj to, kad ištrauktumėte senior inžinierius iš produkto kelio kelis mėnesius, mes vieną kartą pastatome pasikartojantį procesą — SBOM (Software Bill of Materials) generavimą, pažeidžiamumų valdymą ir Article 14 reporting'ą — kurį jūsų komanda toliau valdo savarankiškai. Taip gaunate greitesnį rezultatą, nepriklausomą atitikties patvirtinimą ir apsisaugote nuo rizikos prarasti ES rinką po 2027-12-11.

Nelaukite rugsėjo 11-osios

CRA 14 straipsnio pranešimų prievolė yra pirmasis realus reglamento terminas ir tikėtina pirmoji vieta, kur atsiras patikrinimai bei baudos. Ankstyvas pasiruošimas kainuoja kelias dienas darbo – nepasiruošimas gali kainuoti nesuvaldytą incidentą praleistų terminų fone. Jei gaminate produktus su skaitmeniniais elementais, susisiekite dėl nemokamo pirminio taikymo srities įvertinimo: nustatysime, kurios prievolės jums aktualios ir ką reikia padaryti iki termino.

Taip pat kviečiame susipažinti su mūsų paslaugomis puslapiuose CISO paslaugos ir Kibernetinio saugumo auditas.