CRA 2026: toote turvatoimik ISO 27001 toel

Ühendatud seadmete tootja kutsub oma infoturbejuhi Maria reede pärastlõunasele koosolekule. Müügitiim on äsja sõlminud Euroopa turustuslepingu. Õigusosakond küsib, kas ettevõte suudab toetada Cyber Resilience Acti nõuetelevastavust. Arendusmeeskond ütleb, et turvaline arendus on „suures osas kaetud“, sest olemas on koodi läbivaatus, SAST ja paikamine. Hankeosakond ütleb, et tarnijad tegutsevad „konfidentsiaalsuslepingu alusel“. Tootetiimidel on püsivara sõltuvused ühes tööriistas, pilve-API-de registrid teises ning haavatavuste piletid Jiras. Vastavusfunktsioonil on ISO/IEC 27001:2022 sertifitseerimise tõendusmaterjal, kuid see on korraldatud ettevõtte ISMS-i, mitte iga EL-i turule lastava toote ümber.

Siis kõlab ebamugav küsimus: „Kui EL-i asutus, klient, teavitatud asutus või oluline turustaja küsib 2026. aastal toote turvatoimikut, kas suudame selle ühe nädalaga esitada?“

Paljude tarkvaratarnijate, nutiseadmete tootjate ja ühendatud teenuste pakkujate aus vastus on ei. Mitte seetõttu, et neil puuduvad turbekontrollid, vaid seetõttu, et toote turvalisuse tõendusmaterjal on laiali. Turvalise arenduse kirjed on arendusmeeskonnas. SBOM-id genereeritakse iga ehituse kohta, kuid neid ei hallata. Koordineeritud haavatavuste avalikustamine on olemas veebilehena, kuid see ei ole alati seotud triaaži, paranduste, turvateadete ja turule laskmise järgse seirega. Tarnijate turve on peidetud hankelepingutesse. Intsidentidest teatamine kuulub turbeoperatsioonidele, samas kui vastavusdokumentatsioon kuulub toote nõuetelevastavuse valdkonda.

EL-i Cyber Resilience Act muudab tegevusmudelit. Toote küberturvalisus ei ole enam üksnes hea tava ega lepinguline lubadus. Sellest saab elutsüklipõhine tõendamiskohustus. Organisatsioonid peavad suutma näidata, kuidas küberturvalisuse nõuded on lõimitud kavandamisse, arendusse, väljalaskesse, haavatavuste käsitlemisse, uuendustesse ja seiresse pärast toote turule jõudmist.

Siin muutub ISO/IEC 27001:2022 õigel kasutamisel tugevaks tööriistaks. See ei ole eraldiseisev toote sertifitseerimisskeem, kuid selle ISMS-i, riskide, varade, tarnijate, turvalise arenduse, haavatavuste ja intsidentide kontrollimeetmed võivad anda CRA toote turvatoimikule selgroo. Eesmärk ei ole luua järjekordset vastavussilot. Eesmärk on muuta olemasolev ISMS tootetaseme tõendamissüsteemiks.

Nagu Claryseci Zenith Blueprint: audiitori 30-sammuline tegevuskava ütleb 2. faasis, 8. sammus „Tõendusmaterjali arhitektuur“:

„Tõendusmaterjali ei tule koguda auditi tsükli lõpus. See tuleb kavandada kontrollimeetmesse, määrata omanikule, ajatembeldada protsessi poolt ning muuta taaskasutatavaks iga kohustuse jaoks, mis küsib sama küsimust erinevas sõnastuses.“

See lause võtab kokku CRA valmisoleku tuuma. Küsimus ei ole üksnes: „Kas meil on turvaline arendus?“ Küsimus on: „Kas suudame tõendada turvalist arendust, komponentide teadlikkust, haavatavuste käsitlemist ja turule laskmise järgset seiret selle toote, selle versiooni, selle väljalaske ja selle turu kohta?“

CRA toote turvatoimik on elav tõendussüsteem

CRA toote turvatoimikut ei tohiks käsitleda staatilise PDF-failina, mis koostatakse üks kord enne väljalaset ja seejärel unustatakse. See peab olema struktureeritud toimik, mis kirjeldab toote turvalisuse lugu alates kontseptsioonist kuni toe lõppemiseni.

Kasulik toimik selgitab:

1. Mis toode on ja kuidas seda on ette nähtud kasutada.
2. Millist tarkvara, püsivara, pilveteenuseid ja kolmandate osapoolte sõltuvusi see sisaldab.
3. Milliseid küberturvalisuse riske hinnati.
4. Milliseid turbenõudeid rakendati.
5. Kuidas turvaline arendus läbi viidi.
6. Kuidas haavatavusi vastu võetakse, neile triaaž tehakse, need parandatakse ja avalikustatakse.
7. Kuidas turvalisi uuendusi tarnitakse.
8. Kuidas tarnijaid ja avatud lähtekoodiga komponente kontrollitakse.
9. Kuidas intsidente ja aktiivselt ärakasutatavaid haavatavusi eskaleeritakse.
10. Kuidas toodet pärast turule laskmist seiratakse.

Infoturbejuhi jaoks on see ISMS-i tõendusmaterjali väljakutse. Toote vastavusjuhi jaoks on see tehniline dokumentatsioon. Arenduse jaoks on see DevSecOps ja väljalasete juhtimine. Tippjuhtide jaoks on see turulepääs ja vastutuse kontroll.

Viga on käsitleda neid eraldi töövoogudena. Parem mudel on luua tootetaseme tõendustoimik, mis seostub ISO/IEC 27001:2022 ja ISO/IEC 27002:2022 kontrollimeetmetega ning mille sama tõendusmaterjal seostatakse vajaduse korral ka NIS2, DORA, GDPR, NIST ja COBIT 2019 nõuetega.

Claryseci Zenith Controls: ristvastavuse juhend kirjeldab seda kontrollimeetmest tõendusmaterjali ja audiitorini kulgeva ahelana:

„Ristvastavuse tõendustoimik peab seostama iga kohustuse toimiva kontrollimeetme, korduva tõendusobjekti, vastutava omaniku ja auditi vaatenurgaga, mille kaudu seda vaidlustatakse.“

Just sellist distsipliini vajab CRA ettevalmistus. Toote turvatoimik ei ole pelgalt kaust. See on tõlkekiht tootearenduse, turbejuhtimise, vastavushindamise ja klientidele kindluse andmise vahel.

Esmalt loo toote tõendusmaterjali selgroog

Toimik vajab järjepidevat struktuuri enne, kui meeskonnad hakkavad kirjeid üles laadima. Ilma selge selgroota muutub tõendusmaterjal ekraanitõmmiste, eksportide ja poliitika-PDF-ide kuhjaks, mida ükski audiitor ei suuda jälgida.

CRA valmisoleku töötubades soovitab Clarysec tavaliselt järgmist toote turvatoimiku struktuuri organisatsioonidele, kellel juba toimib ISO/IEC 27001:2022 ISMS.

See tabel ei asenda õiguslikke tehnilise dokumentatsiooni kohustusi. See annab ettevõttele tegevusmudeli nende tõendamiseks.

Zenith Blueprintis keskendub 1. faasi 3. samm kohaldamisala ja piiride määratlemisele. CRA puhul muutub see samm tootespetsiifiliseks. Määratlege tooteperekond, tarkvaraversioonid, juurutuseeldused, kasutajarollid, ühendatud teenused, uuenduskanalid ja toe periood. Kui ISMS-i kohaldamisala on „ettevõtte SaaS ja seadmehaldusplatvorm“, peab CRA toimik ikkagi vastama kitsamale küsimusele: „Milline digitaalsete elementidega toode lastakse EL-i turule ja mis selle toote hulka kuulub?“

Seo turvaline arendus tootetaseme kirjetega

Toote turvatoimiku keskmes on tõendusmaterjal turvalisus kavandamisel põhimõtte rakendamise kohta. ISO/IEC 27001:2022 annab juhtimissüsteemi. ISO/IEC 27002:2022 annab rakendussuunised selliste kontrollimeetmete kaudu nagu A.8.25 turvaline arenduse elutsükkel, A.8.27 turvalise süsteemiarhitektuuri ja inseneeria põhimõtted, A.8.28 turvaline programmeerimine ning A.8.29 turbetestimine arenduses ja vastuvõtmisel.

Oluline nihe on üldistelt turvalise arenduse väidetelt väljalaskepõhistele kirjetele. „Me teeme koodi läbivaatust“ ei ole piisav. Toimik peab näitama, milline väljalase üle vaadati, milliseid riske arvestati, millised turbetestid läbiti, millised haavatavused aktsepteeriti või parandati ning kes väljalaske kinnitas.

Claryseci Enterprise turvalise arenduse poliitika on kavandatud sellise auditijälje nõudmiseks. Punktis 6.1 „Turvalise arenduse elutsükli nõuded“ on kirjas:

„Iga toote või teenuse väljalaske kohta tuleb enne tootmiskeskkonda juurutamist säilitada dokumenteeritud tõendusmaterjal turbenõuete, disaini ülevaatuse, turvalise programmeerimise tegevuste, turbetestimise, haavatavuste parandamise otsuste ja väljalaske kinnitamise kohta.“

See punkt on CRA jaoks kasulik, sest muudab turvalise arenduse korduvaks tõendusmustriks. Audiitor ei pea järeldama, et turvaline arendus toimus. Ta saab kontrollida väljalaske kirjet.

Nutika termostaadi, meditsiinilise IoT-seadme, tööstusanduri või SaaS-iga ühendatud toote puhul peaks turvalise arenduse tõendusmaterjal sisaldama järgmist:

• Toote turbenõuded seostatuna tuvastatud riskidega.
• Toote ja ühendatud teenuste ohumudel või väärkasutusjuhtumite analüüs.
• Arhitektuuri ülevaatus, sealhulgas usalduspiirid ja välisliidesed.
• Turvalise programmeerimise standard ning tõend arendaja kinnituse või koolituse kohta.
• SAST, DAST, tarkvarakompositsiooni analüüs (SCA), saladuste skannimine ja püsivara analüüs, kui kohaldatav.
• Paranduspiletid kõrge riskiga leidude kohta.
• Riski aktsepteerimise kirjed koos äri- ja turbevaldkonna kinnitusega.
• Väljalaske kontrollvärava kontrollnimekiri, mis näitab, et turbekriteeriumid on täidetud.
• Krüptograafilise allkirjastamise ja uuenduste tervikluse tõendusmaterjal.
• Toe perioodi ja elutsükli lõpu eeldused.

Teised standardid aitavad meetodit tugevdada. ISO/IEC 27005 toetab nende kirjete aluseks olevat riskipõhist lähenemist. ISO/IEC 27017 on kasulik, kui pilveteenused moodustavad osa toote ökosüsteemist. ISO/IEC 27035 toetab intsidentide käsitlemist. ISO/IEC 29147 ja ISO/IEC 30111 on eriti asjakohased haavatavuste avalikustamise ja haavatavuste käsitlemise jaoks. ISO/IEC 27036 toetab tarnijate turvet, mis on oluline, kui toode sisaldab allhanketarkvara, manustatud mooduleid, hallatud pilveteenuseid või kolmandate osapoolte teeke.

Zenith Controlsis seostatakse CRA turvalise arenduse tõendusmaterjal tavaliselt ISO/IEC 27002:2022 kontrolliteemadega, nagu infoturve projektijuhtimises, turvaline arenduse elutsükkel, turvaline programmeerimine, turbetestimine, muudatuste juhtimine ja tehniliste haavatavuste haldus. Juhend seob need ka varade nimistu ja tarnijakontrollidega, sest ükski turvalise arenduse protsess ei ole täielik, kui organisatsioon ei suuda tuvastada komponente, mida ta tarnib.

Käsitle SBOM-i reguleeritud toote tõendusmaterjalina

Tarkvara koostise loendit käsitletakse sageli tehnilise artefaktina. CRA valmisoleku jaoks tuleb seda käsitleda toote tõendusmaterjalina.

Kasulik SBOM näitab, millised komponendid on tootes, milliseid versioone kasutatakse, kust need pärinevad, millised litsentsid kehtivad, millised haavatavused neid mõjutavad ja millised väljalasked neid sisaldavad. Püsivara ja manussüsteemidega toodete puhul võib see hõlmata operatsioonisüsteemi pakette, alglaadureid, teeke, draivereid, konteinereid, kolmandate osapoolte mooduleid ja toote toimimiseks vajalikke pilvepoole sõltuvusi.

Probleem on selles, et paljud organisatsioonid genereerivad SBOM-e, kuid ei halda neid. Ehitustorustik võib luua SPDX- või CycloneDX-faili, kuid keegi ei valideeri täielikkust. Turbetööriistad võivad haavatavusi märgistada, kuid tulemused ei ole seotud tooteversioonidega. Hange võib tarnija heaks kiita, kuid selle tarnija komponentide loendit ei viida kokku välja lastud tootega.

Claryseci Enterprise varahalduse poliitika käsitleb seda juhtimispuudust punktis 5.2 „Teabe ja seotud varade register“:

„Teabevarad ja seotud tehnoloogiakomponendid tuleb tuvastada, määrata omanikule, vajaduse korral klassifitseerida ning hoida registris, mis toetab riskihindamist, haavatavuste haldust, muudatuste juhtimist ja audititõendust.“

CRA puhul muutub see punkt tootespetsiifiliseks. SBOM on osa seotud tehnoloogiakomponentide registrist. Sellel peab olema omanik, säilitamisreegel, valideerimisprotsess ja seos haavatavuste haldusega.

Praktiline SBOM-i tõendusreegel on lihtne: igal välja lastud tooteversioonil peab olema kinnitatud komponentide register, mida saab siduda väljalaske artefaktiga. Kui organisatsioon ei suuda siduda SBOM-i täpse püsivarakujutise, rakenduspaketi, konteineri digesti või SaaS-i väljalaskega, on SBOM nõrk tõendusmaterjal.

Kui enam kui kaks rida ei läbi kontrolli, ei ole probleem tavaliselt SBOM-i tööriistas. Probleem on juhtimises. Toote turvatoimik peab registreerima ISMS-is parandusmeetme, sest CRA tõendusmaterjali nõrkus on ühtlasi ISO/IEC 27001:2022 kontrollimeetmete tõhususe probleem.

Seo CVD haavatavuste käsitlemise ja väljalasete juhtimisega

Koordineeritud haavatavuste avalikustamine on üks nähtavamaid CRA valmisoleku valdkondi, sest välised uurijad, kliendid ja asutused saavad seda otse testida. Haavatavuste avalikustamise lehe või security.txt-faili avaldamine on kasulik, kuid see on ainult välisuks. Toote turvatoimik peab tõendama, et taustaprotsess toimib.

Õiguslikult ja auditi seisukohast kaitstav CVD ja haavatavuste käsitlemise tõendusmaterjal peaks sisaldama järgmist:

• Avalik avalikustamiskanal ja esitamisjuhised.
• Uurijale kinnituse saatmise protsess.
• Triaažikriteeriumid, sealhulgas tõsiduse ja ärakasutatavuse hindamine.
• Toote mõjuhinnang.
• Parandamise omanik ja sihtajad.
• Klienditeadete ja uuenduste kommunikatsioonimallid.
• Tõendusmaterjal turvalise paiga arendamise ja testimise kohta.
• Koordineeritud avaldamise kirjed, kui kohaldatav.
• Õppetunnid ja korduvate haavatavuste trendianalüüs.

Claryseci Enterprise haavatavuste halduse poliitika punkt 6.3 „Haavatavuste vastuvõtt, triaaž ja parandamine“ sätestab:

„Teatatud haavatavused tuleb logida, hinnata mõjutatud varade ja toodete suhtes, prioriseerida riski ja ärakasutatavuse alusel, määrata vastutavale omanikule ning jälgida kuni parandamise, verifitseerimise, teavitamise ja sulgemiseni.“

See punkt seob CVD SBOM-i, varade registri, arenduspiletite, väljalasete juhtimise ja turule laskmise järgse seirega. See on ka punkt, mida audiitorid loomulikult testivad: näidake vastuvõtukirjet, näidake mõjutatud tooteid, näidake triaaži, näidake parandust, näidake kliendisuhtlust, näidake sulgemist.

Olemasolevat infoturbeintsidentide halduse poliitikat tuleb samuti laiendada, et see hõlmaks tootehaavatavusi, mis muutuvad intsidentideks või nõuavad välist teavitamist. ISO/IEC 27002:2022 A.5.24 käsitleb intsidentide halduse planeerimist ja ettevalmistust, A.5.25 infoturbesündmuste hindamist ja otsustamist, A.5.26 infoturbeintsidentidele reageerimist ning A.5.27 intsidentidest õppimist.

Zenith Controlsis käsitletakse haavatavuste haldust nii ennetava kui ka korrigeeriva tegevusena. Ennetav pool hõlmab registrit, turvalist arendust, tarnijate seiret ja turvalist seadistamist. Korrigeeriv pool hõlmab tuvastamist, triaaži, paikamist, teabevahetust ja intsidendi eskaleerimist. See eristus on oluline, sest turule laskmise järgne haavatavuste käsitlemine on osa toote elutsükli kohustusest, mitte järelmõte.

Tarnijate tõendusmaterjal on varjatud nõrkus

Toote turvatoimikut seatakse sageli kõige tugevamalt kahtluse alla seal, kus tootja sõltub teistest. See hõlmab manustatud mooduleid, allhanke korras tehtud püsivara arendust, white-label-komponente, pilvemajutust, mobiilseid SDK-sid, makseteenuseid, krüptograafilisi teeke ja hallatud tugiteenuse pakkujaid.

Levinud ebaõnnestumise muster on lepinguline abstraktsioon. Tootja ütleb: „Meie tarnija vastutab selle eest.“ Toote turvalisuse kontrolli all ei ole see piisav. Organisatsioon peab näitama, et tarnijarisk on tuvastatud, turbenõuded on edastatud, tõendusmaterjal on kogutud, haavatavused koordineeritakse ja muudatusi kontrollitakse.

Claryseci Enterprise kolmandate osapoolte ja tarnijate turbepoliitika punkt 7.1 „Tarnijate turbenõuded“ sätestab:

„Tarnijaid, kes arendavad, käitavad, töötlevad, toetavad või mõjutavad oluliselt infosüsteeme, tooteid või teenuseid, tuleb hinnata riskipõhiselt ning neile tuleb kohaldada turbenõudeid, mis hõlmavad juurdepääsu, haavatavuste haldust, intsidenditeavitust, alltöövõttu, talitluspidevust ja tõendusmaterjali esitamist.“

CRA jaoks on väljend „mõjutavad oluliselt tooteid“ kriitiline. Kui tarnijakomponent võib tekitada haavatavuse, häirida uuendusi, avaldada kliendiandmeid või kompromiteerida seadme terviklust, kuulub see toote turvatoimikusse.

Sama poliitika saab toetada ka SBOM-i lepingulist nõudmist. Punkt 7.3 sätestab:

„Kõigi kolmandate osapoolte tarkvarakomponentide, teekide või operatsioonisüsteemide puhul, mis integreeritakse ettevõtte „digitaalsete elementidega toodetesse“, peab tarnija taotluse korral esitama masinloetava tarkvara koostise loendi (SBOM) standardses vormingus, näiteks SPDX või CycloneDX. See nõue tuleb lisada kõigisse hanke- ja tarnijalepingutesse.“

Tugev tarnijate tõenduspakett peaks sisaldama tarnijate klassifikatsiooni toote mõju alusel, lepingutes sätestatud turbenõudeid, kriitiliste komponentide tarnijapoolse turvalise arenduse tõendusmaterjali, tarnijate haavatavuste avalikustamise kohustusi, SBOM-i või komponentide deklaratsioone, kui teostatav, paikamistoetuse ja elutsükli lõpu ajakavasid, perioodilisi läbivaatamise kirjeid ning eskaleerimisteid tarnijast pärinevate haavatavuste jaoks.

ISO/IEC 27002:2022 A.5.19, A.5.20 ja A.5.21 annavad peamised tarnijakontrollide teemad. ISO/IEC 27036 lisab sügavust tarnijasuhete turvalisusele. Ristvastavuse mõttes rõhutab NIS2 tarneahelat ja haavatavuste käsitlemist. DORA rõhutab IKT kolmandate osapoolte riski finantssektori üksuste jaoks. GDPR muutub asjakohaseks, kui toode või selle pilveteenused töötlevad isikuandmeid. COBIT 2019 raamib tarnijate juhtimise ettevõtte tehnoloogiajuhtimise küsimusena, mitte üksnes turbeoperatsioonide küsimusena.

Turule laskmise järgne seire muudab tõendusmaterjali operatsioonideks

Kõige küpsemad tooteturbe organisatsioonid mõtlevad väljalaskest kaugemale. Nad küsivad: „Kuidas saame teada, et see toode on pärast kasutusele võtmist muutunud riskantseks?“

Turule laskmise järgne seire peab koguma signaale haavatavusvoogudest, ärakasutusteabe allikatest, klienditoest, telemeetriast, bug bounty või uurijate teadetest, tarnijate teavitustest, pilvelogidest, intsidendikirjetest ja välitingimustes toimivuse andmetest. See peab hõlmama ka perioodilist tooteriski läbivaatust, kui ohukeskkond muutub.

Claryseci Enterprise logimis- ja seirepoliitika punkt 5.4 „Turvaseire ja läbivaatamine“ sätestab:

„Turvalisusega seotud sündmusi tuleb koguda, läbi vaadata, eskaleerida ja säilitada viisil, mis toetab õigeaegset tuvastamist, uurimist, intsidendihaldust, vastavusaruandlust ja pidevat täiustamist.“

Ühendatud toodete puhul tuleb seda tõlgendada hoolikalt. Seire peab austama privaatsust, andmete minimaalsust ja õiguslikke piiranguid, eriti kui telemeetria sisaldab isikuandmeid või kliendi operatiivandmeid. GDPR-i vastendus on oluline. Tooteturbe meeskonnad peavad töötama koos andmekaitse meeskondadega, et määratleda, milline telemeetria on turvalisuse jaoks vajalik, kuidas seda minimeeritakse, kui kaua seda säilitatakse ja kuidas kliente teavitatakse.

Turule laskmise järgse seire tõendusmaterjal peaks sisaldama toote turvaseire plaani, haavatavusteabe allikaid, klienditeadete vastuvõtukanaleid, tarnijate teavitamiskanaleid, telemeetria või logide läbivaatuse ulatust, perioodiliste tooteriski ülevaatuste protokolle, paikade kasutuselevõtu jälgimist, intsidentide trendianalüüsi ja juhtkonna läbivaatuse sisendeid.

Zenith Blueprintis keskendub 5. faasi 30. samm pidevale täiustamisele ja järelevalveks valmisolekule. CRA puhul on see koht, kus toote turvatoimikust saab elav toimik. Iga tooteväljalase, haavatavus, tarnijamuudatus ja välitingimuste signaal peab uuendama tõenduskirjet.

Üks tõendustoimik, mitu vastavusküsimust

Hästi kavandatud CRA toote turvatoimik vähendab dubleerimist, sest sama tõendusmaterjal vastab mitmele vastavusküsimusele. Sõnastus muutub, kuid kontrollide tegelikkus on sageli sarnane.

Zenith Controls on loodud selliseks taaskasutuseks. See seostab ISO/IEC 27002:2022 kontrolliteemad atribuutidega, nagu ennetava, tuvastava ja korrigeeriva kontrolli eesmärk, küberturvalisuse kontseptsioonid, operatiivsed võimekused ja turbeomadused. CRA puhul aitab see infoturbejuhil selgitada, miks üks tõendusobjekt, näiteks väljalaske turvaülevaatus, toetab turvalist arendust, riskikäsitlust, muudatuste juhtimist, haavatavuste haldust ja auditivalmidust.

Valmistu eri audiitorivaadete jaoks

CRA toote turvatoimikut võivad vaidlustada ISO audiitor, siseauditi meeskond, klientidele kindluse andmise meeskond, toote vastavuse ülevaataja, regulaator, NIST-il põhinev hindaja või ISACA koolitusega COBIT audiitor. Igaüks küsib sarnaseid küsimusi erineva vaatenurga kaudu.

Sama nõrk koht paljastub erinevalt. Kui SBOM-id genereeritakse, kuid neid ei säilitata, näeb ISO audiitor kirjete kontrolli ja operatiivkontrolli probleemi. NIST-i hindaja näeb varade ja haavatavuste halduse nõrkust. COBIT audiitor näeb nõrka juhtimist teabevarade üle. Toote ülevaataja näeb ebapiisavat tehnilist dokumentatsiooni.

30-sammuline tegevuskava CRA valmisoleku jaoks

Zenith Blueprint takistab vastavusmeeskondadel hüppamast otse dokumentide kogumisse. CRA puhul muutub 30-sammuline tegevuskava tooteturbe tõendusmaterjali programmiks.

1. faas algab kohustuste ja kohaldamisala kaardistamisega. Tuvastage, millised tooted, versioonid, komponendid, pilveteenused ja tugiprotsessid kuuluvad kohaldamisalasse. Kinnitage ettenähtud kasutus, kasutajakategooriad, turud ja turbetoe periood.

2. faas loob tõendusmaterjali arhitektuuri. Määratlege toote turvatoimiku indeks, tõendusmaterjali omanikud, säilitamisnõuded, hoidla struktuur ja kinnitamise töövoog. Joondage see arendussüsteemidega, selle asemel et nõuda käsitsi üleslaadimisi.

3. faas rakendab toimivad kontrollid. Turvaline arendus, SBOM-i genereerimine, haavatavuste käsitlemine, tarnijate tõendusmaterjal, väljalaske kontrollväravad, turvalised uuendused ja intsidentide eskaleerimine peavad toimima tegelike protsessidena.

4. faas testib auditivalmidust. Valige üks tooteväljalase ja tehke prooviaudit. Kas meeskond saab SBOM-i kätte? Kas nad saavad tõendada turbetestimist? Kas nad saavad näidata, kuidas haavatavusele triaaž tehti? Kas nad saavad ühendada tarnijate tõendusmaterjali tootekomponentidega?

5. faas kinnistab järelevalve ja täiustamise. Turule laskmise järgne seire, haavatavuste trendianalüüs, tarnijate läbivaatused ja juhtkonna läbivaatuse sisendid hoiavad toimiku ajakohasena.

See sprint paljastab tõe tavaliselt kiiresti. Organisatsioonid ebaõnnestuvad harva seetõttu, et neil puuduvad kõik kontrollid. Nad ebaõnnestuvad seetõttu, et kontrollid ei ole tootetasemel ühendatud.

Levinud CRA valmisoleku puudujäägid enne 2026. aastat

Tarkvaratarnijate, seadmetootjate ja ühendatud teenuste pakkujate seas korduvad samad puudujäägid.

Esiteks on ISMS-i kohaldamisala liiga ettevõttekeskne. See katab organisatsiooni, kuid mitte piisavalt toote elutsükli detaile. Lahendus on luua tootetaseme lisad ja tõendustoimikud.

Teiseks on SBOM-id olemas, kuid neid ei usaldata. Tööriistad genereerivad neid, kuid neid ei vaadata üle, kinnitata, säilitata ega seota haavatavuste otsustega. Lahendus on SBOM-i haldus, mitte üksnes SBOM-i tootmine.

Kolmandaks on CVD avalikkusele nähtav, kuid operatiivselt ebaküps. Teated saabuvad, kuid triaažikriteeriumid, reageerimise sihtajad, turvateadete kinnitused ja sulgemise tõendusmaterjal on ebaühtlased. Lahendus on integreerida CVD haavatavuste halduse, intsidendihalduse ja väljalasete juhtimisega.

Neljandaks on tarnijate tõendusmaterjal liiga pinnapealne. Kriitilised tarnijad kinnitatakse äriliselt, kuid neid ei hinnata tooteturbe mõju alusel. Lahendus on tarnijate klassifitseerimine tooteriski järgi ja kohustuslik tõendusmaterjal kriitiliste komponentide kohta.

Viiendaks on turule laskmise järgne seire reaktiivne. Meeskonnad reageerivad kiireloomulistele haavatavustele, kuid ei tee perioodilisi tooteriski ülevaatusi. Lahendus on plaaniline turule laskmise järgne turvaülevaatus, mis on seotud juhtkonna aruandlusega.

Kuuendaks on audititõendus liiga käsitöine. Vastavusmeeskonnad ajavad taga ekraanitõmmiseid. Lahendus on tõendusmaterjal kavandamisel põhimõte, kasutades arendussüsteeme, piletihalduse töövooge ja hoidlaid autoriteetsete allikatena.

Koosta tõendustoimik enne, kui tähtaeg sunnib seda sinu eest tegema

Cyber Resilience Act soosib organisatsioone, kes suudavad tõendada tooteturvet toimiva juhtimisdistsipliinina. See tekitab riski organisatsioonidele, kes käsitlevad tõendusmaterjali viimase hetke vastavusharjutusena.

Alustage ühest tootest. Koostage üks toote turvatoimik. Seostage see ISO/IEC 27001:2022 ja ISO/IEC 27002:2022-ga. Lisage turvalise arenduse tõendusmaterjal, SBOM, CVD kirjed, tarnijate kinnitus ja turule laskmise järgne seire. Tehke auditisimulatsioon enne, kui keegi väline seda teie eest teeb.

Clarysec saab aidata seda teekonda kiirendada järgmiste vahenditega: Zenith Blueprint, Zenith Controls, Enterprise turvalise arenduse poliitika, haavatavuste halduse poliitika, varahalduse poliitika, kolmandate osapoolte ja tarnijate turbepoliitika, logimis- ja seirepoliitika ning infoturbeintsidentide halduse poliitika.

Teie kõige olulisem CRA 2026 küsimus ei ole: „Kas meil on turbekontrollid?“

See on: „Kas suudame tõendada tooteturvet väljalase väljalaske, komponent komponendi ja haavatavus haavatavuse kaupa ka pärast seda, kui toode on juba turul?“

Koostage tõendustoimik nüüd, ühendage see oma ISMS-iga ja muutke iga tulevane tooteväljalase kavandatult auditivalmiks.