CRA ziņošanas pienākumi: skaidri nodalīt produkta pasi, drošības ziņojumu un atjauninājumu vēsturi

gada 11. septembrī ražotājiem, kas izgatavo produktus ar digitāliem elementiem, sākas viens no agrākajiem Cyber Resilience Act (CRA) operatīvajiem pienākumiem: par aktīvi izmantotām ievainojamībām un nopietniem drošības incidentiem jāziņo jaunajā centralizētajā ziņošanas platformā. Tas ir vairāk nekā jauns atbilstības termiņš. Dažu stundu laikā jāapkopo produkta identitāte, skartie tirgi, tehniskais novērtējums un veiktie pasākumi.

Digitālā produkta pase vai ar QR kodu saistīta produkta lapa var palīdzēt viennozīmīgi identificēt ierīci un vēlāk informēt lietotājus par atjauninājumu. Tomēr tā nav ne likumā noteiktais ziņošanas kanāls, ne piemērota glabātuve konfidenciālai informācijai par ekspluatāciju. Tāpēc ražotājiem jau tagad vajadzētu nodalīt trīs datu plūsmas: ziņojumu iestādēm, publisko produkta informāciju un iekšējo atjauninājumu vēsturi.

Jaunais iemesls: 27. un 31. jūlija vadlīnijas

Eiropas Komisija publicēja savas pirmās visaptverošās CRA vadlīnijas 2026. gada 27. jūlijā. Tajās cita starpā aplūkoti ziņošanas pienākumi, riska novērtēšana, atbalsta periodi un būtiskas izmaiņas. Vadlīnijas nav saistošas, tomēr ar 67 piemēriem tās konkretizē, kā uzņēmumi praktiski var piemērot regulu.

Pēc četrām dienām, 31. jūlijā, ENISA atjaunināja informāciju par Single Reporting Platform. Tajā tagad aprakstīta plānotā kārtība, paredzētie ievades lauki un reģistrācijas norādes. Platformai jābūt gatavai darbam līdz 2026. gada 11. septembrim; saskaņā ar Komisijas sniegto informāciju funkcionalitātes un drošības testi jau notiek.

Laika secība ir svarīga: CRA galvenie pienākumi kopumā stājas spēkā 2027. gada 11. decembrī. Tomēr 14. pants par ziņošanas pienākumiem ir piemērojams jau no 2026. gada 11. septembra. To apstiprina gan Regulas (ES) 2024/2847 71. pants, gan 31. jūlijā atjauninātais Komisijas pārskats par CRA ziņošanas procedūru.

Trīs datu telpas vienas pārslogotas produkta pases vietā

CRA ziņojumam un publiskai produkta lapai ir atšķirīgi mērķi. Ja abus attēlo vienā datu kopā, pastāv risks, ka incidentu komandai būs pieejams pārāk maz informācijas vai publiskajā tīmeklī nonāks pārāk daudz sensitīvu detaļu.

1. Konfidenciāls ziņojums SRP, CSIRT un ENISA

Single Reporting Platform ir likumā noteiktais iesniegšanas kanāls. Jāziņo par diviem notikumu veidiem: aktīvi izmantotu ievainojamību, par kuru ir ticamas norādes uz neatļautu izmantošanu, un nopietnu incidentu, kas ietekmē datu vai funkciju pieejamību, autentiskumu, integritāti vai konfidencialitāti.

Ziņojumā jānorāda ne tikai produkta nosaukums. ENISA cita starpā kā laukus uzskaita skartās dalībvalstis, sākotnējo novērtējumu, jau veiktos pretpasākumus, iespējamos lietotāja pasākumus un informācijas sensitivitāti. Vēlākajos posmos var būt jānorāda smaguma pakāpe, ietekme, informācija par uzbrucēju un tehniska informācija par drošības atjauninājumu. Šāda informācija automātiski nepieder brīvi pieejamai DPP lapai.

2. Publiska produkta un drošības informācija

Publiskā datu plūsma atbild uz citiem jautājumiem: Kāds produkts un versija man ir? Vai to joprojām atbalsta? Vai ir pieejams drošības atjauninājums? Kas tieši man kā lietotājam jādara? Šim nolūkam var būt lietderīga stabila produkta lapa aiz QR koda vai cita datu nesēja.

Publiskajā lapā jāparāda tikai apstiprināta informācija: skartie modeļu un versiju diapazoni, pieejamā drošā versija, instalēšanas norādes, atbalsta kontaktinformācija un publicēšanas laiks. Informācija par ekspluatāciju, iekšējie atklāšanas noteikumi, neizlaboti uzbrukuma ceļi vai ar incidentu saistīti personas dati paliek aizsargātajā procedūrā. Lēmumu par publisku brīdinājumu nepieņem QR kods: saskaņā ar CRA 17. pantu koordinējošais CSIRT var informēt sabiedrību vai aicināt to darīt ražotāju, ja tas nepieciešams novēršanai vai ierobežošanai.

3. Iekšējā atjauninājumu un pierādījumu vēsture

Trešā plūsma ir izsekojama darba lieta. Tā sasaista produkta ID, aparatūras un programmatūras versiju, programmatūras sastāvdaļu sarakstu, informācijas iegūšanas laiku, triāžas lēmumus, ziņošanas posmus, ielāpa apstiprināšanu un publisko paziņojumu. Šajā vēsturē izmaiņas jāversionē, nevis klusējot jāpārraksta iepriekšējie novērtējumi.

DPP darbībai šī atšķirība ir būtiska: publiskais skats rāda pašlaik apstiprināto stāvokli, savukārt iekšējā vēsture apliecina, kā tas izveidojies. Tie, kas produkta datus jau pārvalda notikumu veidā, var izmantot to pašu principu kā DPP atjauninājumos un tīmekļa āķos: notikums iedarbina turpmākos procesus, taču katrs saņēmējs saņem tikai savai lomai paredzētos laukus.

CRA pulkstenis sākas ar informētību

pantā noteikti pakāpeniski termiņi. Par aktīvi izmantotu ievainojamību bez nepamatotas kavēšanās, bet ne vēlāk kā 24 stundu laikā pēc tās konstatēšanas, jānosūta agrīnais brīdinājums. 72 stundu laikā seko detalizētāks ziņojums par ievainojamību. Noslēguma ziņojumam jābūt pieejamam ne vēlāk kā 14 dienas pēc tam, kad kļūst pieejams novēršanas vai mazināšanas pasākums.

Arī nopietna drošības incidenta gadījumā agrīnajam brīdinājumam paredzētas 24 stundas, bet ziņojumam par incidentu — 72 stundas. Noslēguma ziņojums jāiesniedz mēneša laikā pēc 72 stundu ziņojuma. Tātad termiņi nesākas ar CVE publicēšanu vai nākamo regulāro laidienu, bet gan ar brīdi, kad ražotājs tiek uzskatīts par informētu.

Praksē ieteicama skaidra kārtība:

Reģistrēt saņemto informāciju no atbalsta, uzraudzības, pētniecības vai piegādes ķēdes, pievienojot laika zīmogu.
Identificēt produktu un versiju, sasaistot tos ar stabilu iekšējo produkta ID.
Atbildīgajai komandai novērtēt izmantošanu vai incidenta smagumu.
No apstiprinātajiem minimālajiem datiem izveidot 24 stundu datu kopu un iesniegt to SRP.
Papildināt tehniskos secinājumus līdz 72 stundu posmam, nezaudējot sākotnējo stāvokli.
Atsevišķi apstiprināt ielāpu, lietotāja pasākumu un publisko informāciju.
Sasaistīt noslēguma ziņojumu ar iekšējo vēsturi.

Šī ķēde pirms septembra jāizspēlē kā mācību scenārijs. ENISA norāda, ka organizācijas var automatizēt iekšējos procesus un datubāzes, taču platforma darbības sākumā nepiedāvās API. Tāpēc eksporta un četru acu pārbaudes process ir reālistiskāks par nepārbaudītu tiešu integrāciju.

Vienots produkta ID, bet nošķirtas piekļuves tiesības

Nošķiršana nenozīmē trīs nesaistītu kopiju uzturēšanu. Labāka pieeja ir kopīga, nemainīga produkta atsauce ar lomām pielāgotiem skatiem.

Jābūt pieejamām vismaz šādām sasaistēm:

iekšējais produkta ID, kā arī modeļa, partijas vai sērijas atsauce;
aparatūras, aparātprogrammatūras un programmatūras versija;
dalībvalstis, kurās skartā versija ir darīta pieejama;
drošības novērtējuma statuss un informācijas iegūšanas laiks;
atsauces uz 24 un 72 stundu ziņojumu, kā arī noslēguma ziņojumu;
apstiprinātais lietotāja pasākums un drošā mērķa versija;
publiskās produkta lapas publicēšanas statuss.

Autorizācija jāveido pa laukiem. Incidentu komandai un CRA atbildīgajiem nepieciešama pilna lieta. Atbalstam un pārdošanai vajadzīga apstiprināta rīcības instrukcija. Lietotāji redz tikai publisko paziņojumu. QR kodam ideālā gadījumā jānodod tikai stabila produkta adrese; aiz tās esošā platforma, ņemot vērā statusu un lomu, izlemj, kāda informācija jānodrošina.

Kas ražotājiem jātestē līdz septembrim

Lietderīgam testa scenārijam nav vajadzīga īsta ievainojamība. Izvēlieties savienotu produktu, skartu aparātprogrammatūras versiju un trīs dalībvalstis. Simulējiet informācijas iegūšanu darba dienā un pārbaudiet:

Vai komanda 24 stundu laikā var apstiprināt produkta pārklājumu un minimālos datus?
Vai ir skaidrs, kuram pārstāvim, izmantojot EU Login, jāpiekļūst SRP?
Vai 72 stundu informāciju var papildināt, nepubliskojot konfidenciālas detaļas?
Vai ielāpa apstiprināšana nodrošina pārbaudītu lietotāja informāciju visās nepieciešamajās valodās?
Vai publiskais URL paliek nemainīgs, mainoties versijai un pasākumiem?
Vai ir izsekojams, kas, kad un kuru stāvokli apstiprinājis?

Pēdējā jautājuma risināšanai palīdz konsekventa, versionēta datu pārvaldība. qr3 raksts par nepārtrauktu DPP atjaunināšanu parāda pamatideju: identitāte paliek stabila, bet profesionālie dati tiek kontrolēti papildināti. CRA procesā tam pievienojas stingrāks konfidencialitātes un apstiprināšanas slānis.

Secinājums: produkta pase ir izplatīšanas kanāls, nevis ziņošanas vieta

Jaunās vadlīnijas padara septembra termiņu praktiski saprotamu. Ražotājiem savā digitālajā produkta pasē nav jāiekļauj konfidenciāla ievainojamību datubāze. Tā vietā nepieciešama uzticama pāreja starp trim skaidri nošķirtām jomām: ziņojumu iestādēm, iekšējiem pierādījumiem un apstiprinātu lietotāja informāciju.

Kopīgs produkta ID šīs jomas sasaista. Lomas, apstiprinājumi un versionēšana novērš konfidenciālu detaļu nonākšanu ārpusē vai situāciju, kad lietotāji par pieejamu pasākumu uzzina pārāk vēlu. QR kods joprojām ir noderīgs, taču apzināti neuzkrītošs: tas pastāvīgi ved uz pareizo produkta kontekstu. Īstā CRA atbilstība rodas aiz tā esošajos procesos.