Esimene Cyber Resilience Act'i (CRA) tähtaeg, mis puudutab tootemeeskondi, on 11. september 2026, mil hakkavad kehtima aruandluskohustused. Peamised kohustused järgnevad 11. detsembril 2027. Aruandlus sõltub protsessidest ja inimestest ning nende üles ehitamine võtab aega, mistõttu tuleb sellega alustada enne kõike muud.
Mis millal kehtib
CRA on määrus (EL) 2024/2847. Euroopa Komisjoni CRA lehe kohaselt kehtestab see tootjatele kohustuslikud küberturvalisuse nõuded digielemente sisaldavate toodete planeerimisele, kavandamisele, arendamisele ja hooldusele. Samuti peavad tootjad käsitlema haavatavusi kogu toote elutsükli vältel.
| Kuupäev | Mis juhtub |
|---|---|
| 10. detsember 2024 | CRA jõustus |
| 11. september 2026 | Hakkavad kehtima aruandluskohustused |
| 11. detsember 2027 | Hakkavad kehtima peamised kohustused |
Nõuetele vastavad tooted kannavad CE-märgist ning reegleid jõustavad riiklikud turujärelevalveasutused. Mõne küberturvalisuse seisukohast eriti oluline toote puhul võib enne ELi turule viimist olla vaja teavitatud asutuse (notified body) tehtavat kolmanda osapoole hindamist. Selgitage varakult välja, kummal pool seda piiri teie toode asub, sest see mõjutab teie ajakava.
Komisjon avaldas 27. juulil 2026 tootjatele ka praktilised juhised. Lugege need läbi enne, kui otsustate allpool kirjeldatud protsesside lahenduse üle.
Turvalise arenduse tõendid
Reguleerijad ja kliendid küsivad, mida te olete teinud. Koostage dokumendid seetõttu tavalise töö kõrvalproduktina, mitte ei rekonstrueeri neid hiljem. Abiks on tunnustatud raamistik.
NIST Secure Software Development Framework, SP 800-218 on kõrgetasemeliste põhitavade kogum, mille lisate oma praegusele SDLC-le. Selle väljakuulutatud eesmärgid on vähendada väljastatud tarkvara haavatavusi, leevendada allesjäävate haavatavuste mõju ja kõrvaldada algpõhjused, et need ei kordu. Samuti annab see ostjate ja tarnijatega suhtlemiseks ühise sõnavara. See on USA dokument, mitte CRA kontrollnimekiri, seega kasutage seda toestikuna.
Iga väljalaske kohta tasub säilitada järgmist:
- ohumudel või disainiülevaatus, mis muudatust hõlmas
- koodiülevaatuse ja testide tulemused, sealhulgas turvatestid
- sõltuvuste nimekirjad versioonidega ning otsused, mille tegite neis leiduvate teadaolevate probleemide kohta
- väljalaske kinnitus nime ja kuupäevaga
CISA Secure by Design materjal lisab kaks praktilist punkti. Vastutus peab asuma juhtkonna tasandil ning vaikeseadistused on olulised: MFA, logimine ja SSO peaksid olema kasutatavad karbist välja võttes ja lisatasuta. Kui teie toode müüb neid tasulise lisana, valmistuge selle küsimärgi alla seadmiseks. CISA avaldab ka juhiseid mäluturvalisuse teekaartide kohta, mida tasub lugeda, kui teie kood on kirjutatud C või C++ keeles.
Haavatavuste käsitlus ja aruandlus
Alates 11. septembrist 2026 peavad tootjad teatama aktiivselt ära kasutatavatest haavatavustest ning teistest Komisjoni aruandluslehel loetletud asjaoludest. Täpse ulatuse ja kasutatava kanali leiate sellelt lehelt. Ärge tuginege kokkuvõttele, kaasa arvatud sellele.
Mida on vaja ettevõttesiseselt, olenemata lõplikest üksikasjadest:
- Üks vastuvõtupunkt. Jälgitav turvakontakt toote veebilehel ja dokumentatsioonis, kus on nimetatud vastutaja ja tema asendaja.
- Triaažirutiin. Keegi otsustab kindlas tähtajas, kas teade on põhjendatud, kas haavatavust kasutatakse ära ning milliseid tooteid ja versioone see mõjutab. Ühtne tõsiduse hinnang kiirendab seda tööd, meie CVSS kalkulaator sobib hindepunktide kokkuleppimiseks meeskonnas.
- Aruandlusotsuse tee. Kirjutage üles, kes otsustab, et ärakasutatav haavatavus toob kaasa aruandekohustuse, ja kes aruande esitab. Harjutage seda korra läbi väljamõeldud juhtumiga, vajadusel väljaspool tööaega, kui päriselus juhtuks see just siis.
- Iga otsuse register. Sealhulgas teated, mille luges te ulatusest väljapoole jäävaks, koos põhjendusega.
Aruandlus ei toimi, kui te ei tea, mis teie toote sees on. Hoidke iga väljastatud versiooni kohta ajakohast komponentide nimekirja, sest uue haavatavuse mõju ei saa hinnata mälu järgi.
Uuendusprotsessid
Komisjon nimetab õigeaegsete turvauuenduste puudumist üheks probleemiks, mida CRA lahendab. Tooted tuleb kavandada, uuendada ja hooldada nii, et kasutajad oleksid kaitstud. Praktikas tähendab see, et uuenduskanalit tuleb testida sama tõsiselt kui funktsioone.
Kontrollige igal tootesarjal järgmist:
- Te saate turvaparanduse välja anda eraldi funktsionaalsuse väljalaskest.
- Kliendid saavad teada, et uuendus on olemas, ja selle paigaldamiseks ei ole vaja toele helistada.
- Vanadel versioonidel on teatatud toe lõppkuupäev, mille kliendid näevad enne ostmist.
- Riistvara puhul olete testinud aasta aega võrguühenduseta olnud seadme uuendamist ning pooleldi ebaõnnestunud uuenduse järel seadme taastamist.
Levinud puudujääk ei ole tehnoloogia, vaid vastutus. Paljud meeskonnad suudavad paranduse valmis teha ühe päevaga ja kulutavad seejärel kolm nädalat, et välja selgitada, kellel on õigus see välja anda.
Tehniline dokumentatsioon
Minu kasutatud allikad ei loetle tehnilise toimiku nõutavat sisu, seega võtke see õigusaktist ja Komisjoni juhistest. Praktiline mõte on, et dokumentatsioon tuleks koostada pidevalt ülalkirjeldatud tõenditest, mitte kirjutada viimasel veerandil enne tähtaega.
Looge igale tootele dokumentatsioonikaust või hoidlasektsioon, millel on vastutaja. Pange sinna disain ja riskihinnang, komponentide nimekiri, testitulemused, haavatavuste käsitlemise kord ning uuenduspoliitika. Versioonige seda koos tootega. Kui audiitor või ametiasutus toimikut küsib, peate suutma selle eksportida, mitte tellima.
Kui teie suhtes kehtib ka NIS2 direktiiv, mida CRA Komisjoni sõnul täiendab, kasutage samu intsidentide ja haavatavuste protseduure uuesti, mitte ärge pidage kahte komplekti.
Kust alustada
- Lugege läbi Komisjoni 27. juuli 2026 juhised ja aruandeleht ning kirjutage üles, millised teie tooted jäävad reguleerimisalasse ja kas mõni neist võib vajada teavitatud asutust.
- Nimetage haavatavuste vastuvõtu ja ärakasutatavatest haavatavustest teatamise vastutaja, avaldage turvakontakt ja korraldage sel kvartalil üks harjutus.
- Koostage komponentide nimekiri iga toetatud väljalaske kohta ja muutke selle genereerimine osaks oma buildist.
- Võrrelge oma praegust SDLC-d SSDF-i tavadega, fikseerige lüngad ning hakake säilitama iga väljalaske ülevaatuse, testide ja kinnituse dokumente.
- Testige oma uuenduskanalit algusest lõpuni ja avaldage iga toote toe lõppkuupäevad.
- Looge tootepõhine dokumentatsioonikaust ja täitke see olemasoleva materjaliga. Kui soovite lünkadest välist hinnangut, katavad just seda meie konsultatsiooniteenus ja turvalise tarkvaraarenduse teenus.
