Kyberresilienssisäädös: tuo velvoitteet osaksi tuotekehitystä

Kyberresilienssisäädös (Cyber Resilience Act, CRA) tuo kyberturvallisuusvelvoitteet osaksi sen soveltamisalaan kuuluvien digitaalisia elementtejä sisältävien tuotteiden elinkaarta. Teknologiajohtajalle (CTO) käytännön tehtävänä on kytkeä se, mitä tuotekehitys rakentaa, toimittaa ja ylläpitää, näyttöön, jota velvoitteiden osoittaminen edellyttää.

Tämän kytköksen on toimittava tuote- ja versiotasolla. Koko yrityksen kattava tietoturvapolitiikka ei kerro, onko tietyssä julkaisussa turvalliset oletusasetukset, mitä riippuvuuksia se sisältää tai miten asiakkaat saavat tietoturvapäivityksen. ”Korjattu”-tilaan merkitty haavoittuvuustiketti ei osoita, mitkä tuetut versiot ovat edelleen alttiita.

Hyödyllinen lähtökohta on siksi tuotteen elinkaarimalli: soveltamisala, tietoturvavaatimukset, julkaisunäyttö, haavoittuvuuksien käsittely, tukisitoumukset ja vastuulliset päätökset. Rakenna tämä malli osaksi kehitystyötä sen sijaan, että kokoaisit sen erikseen ennen arviointia.

Määrittele tuotteen raja ennen hallintakeinojen osoittamista

CRA koskee sen soveltamisalaan kuuluvia digitaalisia elementtejä sisältäviä tuotteita, mukaan lukien katettu laitteisto ja ohjelmisto. Se ei ole yleinen sääntö jokaiselle SaaS-palvelulle. Hostattu palvelu ja asiakkaille jaeltava ohjelmisto voivat edellyttää erilaisia analyyseja, ja myös tuotteen kiinteänä osana olevaa etäkäsittelyä on tarkasteltava.

Käytä lähtökohtana Euroopan komission CRA-ohjeistusta ja ratkaise sitten tuotekohtaiset oikeudelliset kysymykset. Kirjaa johtopäätös sen sijaan, että nojaisit tiimin epäviralliseen oletukseen.

Selvitä jokaisen ehdolla olevan tuotteen osalta:

• Mitä asiakkaat saavat: laitteiston, asennettavan ohjelmiston, ladattavia komponentteja vai näiden yhdistelmän.
• Mitkä etäkäsittelytoiminnot ovat välttämättömiä, jotta tuote voi suorittaa toimintonsa.
• Miten tuote saatetaan EU:n markkinoille ja mikä taho sen toimittaa.
• Roolinne talouden toimijana: valmistaja, maahantuoja, jakelija tai muu asiaankuuluva rooli.
• Sovellettavat poissulkemiset, tuotekohtainen lainsäädäntö ja avoimeen lähdekoodiin liittyvät näkökohdat.
• Tuoteluokka ja siitä johtuvat vaatimustenmukaisuuden arviointia koskevat vaatimukset.

Avoin lähdekoodi edellyttää erityistä huolellisuutta. Se, miten kaupallisen toiminnan ulkopuolella toimitettua ohjelmistoa kohdellaan, ei tarkoita, että kaupallinen valmistaja voisi sivuuttaa tuotteeseensa sisältyvät avoimen lähdekoodin komponentit. Erota ylävirran kehittäjän asema omasta vastuustanne toimittamastanne tuotteesta.

Teknisenä tuotoksena pitäisi olla lyhyt soveltamisalatietue, joka sisältää arkkitehtuurikaavion, tuotetunnisteet, asiaankuuluvat kaupalliset oikeushenkilöt, oletukset ja hyväksytyn johtopäätöksen. Nimeä henkilö, joka vastaa johtopäätöksen avaamisesta uudelleen, kun toiminnallisuus tai jakelu muuttuu.

Esimerkiksi ladattavalle hallintasovellukselle ja sen hostatulle analytiikkapalvelulle ei pitäisi automaattisesti tehdä yhtä erittelemätöntä soveltamisalapäätöstä. Yksilöi, mitkä toiminnot toimivat paikallisesti, mitkä riippuvat palvelusta ja kuuluuko kyseinen etäkäsittely tuotteen rajan sisäpuolelle. Tämä ero vaikuttaa riskinarviointiin, riippuvuustietueisiin ja poikkeamien omistajuuteen.

Toimi voimassa olevien täytäntöönpanopäivien mukaan

Komissio ilmoittaa raportointivelvoitteiden päivämääräksi 11.9.2026 ja CRA:n keskeisten vaatimusten päivämääräksi 11.12.2027. 7.10.2026 tilanteen mukaan raportointipäivä on jo ohitettu. Käsittele raportointivalmiutta ajankohtaisena operatiivisena vaatimuksena, ei tehtävänä, joka voi odottaa vaatimustenmukaisuuden valmistelua.

Pidä kaksi työvirtaa näkyvissä:

Ennen keskeisten vaatimusten soveltamispäivää toimitetut tuotteet edellyttävät huomiota siirtymäsäännöksiin ja olennaisiin muutoksiin. Älä oleta, että vanhempi tuote on raportoinnin kannalta merkityksetön vain siksi, että sen alkuperäinen julkaisu edelsi joulukuuta 2027.

Ylläpidä päivättyä oikeudellisten vaatimusten rekisteriä. Tarkista tapahtumakynnykset, vaiheittaiset raportointimääräajat, vastaanottajat ja toimittamismenettelyt voimassa olevasta säädöstekstistä ja virallisista täytäntöönpano-ohjeista. Älä korvaa CRA-kohtaista prosessia yleisellä poikkeamien hallinnan mallipohjalla.

Muunna tietoturvavaatimukset suunnittelu- ja julkaisukriteereiksi

CRA:n olennaiset vaatimukset kattavat tuoteturvallisuuden ominaisuudet ja haavoittuvuuksien käsittelyn. Niiden toteutuksen pitäisi perustua tuotteen kyberturvallisuusriskien arviointiin eikä universaaliin tarkistuslistaan, jota sovelletaan ilman arkkitehtuurista kontekstia.

Aloita siitä, miten tuote voi aiheuttaa vahinkoa. Kuvaa käyttäjät, käyttöympäristöt, paljaana olevat rajapinnat, etuoikeutetut toiminnot, arkaluonteiset tiedot ja ennakoitavissa oleva väärinkäyttö. Ota mukaan asiakkaan käyttöä koskevat oletukset: teollisuusverkkoon asennetulla laitteella on erilainen altistuminen ja erilaiset palautumisen rajoitteet kuin työpöytäapuohjelmalla.

Käytännön uhkamallinnusharjoitus voi tukea tätä työtä; OWASPin uhkamallinnusohjeistus tarjoaa vakiintuneen lähestymistavan. Tuotoksen pitäisi kytkeä uhat tiettyihin vaatimuksiin, toteutuspäätöksiin ja testeihin.

Tarkastele, miten tutuista vaatimuksista tulee testattavia:

Nämä ovat käytännön toteutusesimerkkejä, eivät sovellettavien vaatimusten korvike. Määritä merkityksellisyys ja riittävyys riskinarvioinnin avulla.

Lisää tietoturvan hyväksymiskriteerit ominaisuuskehitykseen. Uuden hallinnollisen rajapinnan pitäisi tulla todennus-, valtuutus-, syötteenkäsittely- ja lokituspäätöksineen, ei lupauksena siitä, että tietoturva tarkastaa sen myöhemmin. Palaa uhkamalliin, kun lisäät etärajapinnan, etuoikeutetun komponentin tai uuden luottamusrajan.

Julkaisun hyväksynnässä pitäisi yksilöidä ratkaisemattomat haavoittuvuudet, niiden hyödynnettävyys, koskevat konfiguraatiot ja käsittely. Sovella CRA:n vaatimusta, jonka mukaan tuotteet asetetaan saataville markkinoilla ilman tunnettuja hyödynnettävissä olevia haavoittuvuuksia, ottaen huomioon riskinarviointi ja sovellettavat olennaiset vaatimukset; riskin kirjaaminen tai hyväksyminen ei sellaisenaan täytä tätä vaatimusta. Pelkkä skannerin tulos ei voi tehdä tätä päätöstä: saavutettavuudella, edellytyksillä ja tuotteen toiminnalla on merkitystä. Toisaalta matala numeerinen vakavuuspistemäärä ei ole riittävä syy sivuuttaa haavoittuvuutta, jolla on merkitystä teidän käyttöönottomallissanne.

Julkaisutietueen pitäisi kytkeä toisiinsa hyväksytty lähdekoodiversio, käännösartefakti, riippuvuusluettelo, testitulokset ja tietoturvapäätös. Näin arviointi on toistettavissa, kun asiakas tai viranomainen myöhemmin kysyy tietystä versiosta.

Tee komponenttien huolellisuusvelvoitteesta osa käännösprosessia

Kolmansien osapuolten komponentit luovat velvoitteita, joita ei voi täyttää välittämällä ylävirran tietoturvatiedotteen eteenpäin. Teidän on ymmärrettävä, mitä toimititte, koskeeko haavoittuvuus sitä ja miten voitte korjata sen.

CRA:n haavoittuvuuksien käsittelyä koskeviin vaatimuksiin sisältyy ohjelmiston materiaaliluetteloa (SBOM) koskeva vaatimus: yleisesti käytetty, koneluettava formaatti, joka kattaa vähintään ylimmän tason riippuvuudet. Käytännön suosituksena tallenna syvempiä riippuvuustietoja aina, kun käännöstyökalunne pystyvät tuottamaan luotettavia tuloksia. Transitiiviset riippuvuudet määrittävät usein altistumisen.

SBOM on hyödyllinen vain, kun se vastaa todellista tuoteartefaktia. Liitä se julkaisutunnisteeseen ja käännökseen, ja erota toimitetut komponentit pelkästään kehitykseen käytetyistä työkaluista. Ota tarvittaessa mukaan laiteohjelmisto, käyttöjärjestelmäpaketit, mukana toimitetut kirjastot ja kaupalliset komponentit; paketinhallinnan vienti voi ohittaa useita näistä.

Rakenna komponenttikatselmointi sellaisten kysymysten ympärille, jotka muuttavat teknisiä päätöksiä:

• Ylläpidetäänkö komponenttia, ja onko sen tuettu elinkaari yhteensopiva omamme kanssa?
• Saammeko haavoittuvuustiedot ja tietoturvapäivitykset viipymättä?
• Onko meillä pääsy lähdekoodiin, toimittajan korjauspolku tai korvausstrategia?
• Tuoko komponentti mukanaan etuoikeutettua suoritusta tai uuden ulkoisen yhteyden?
• Voidaanko tuotetta edelleen ylläpitää, jos toimittaja lopettaa komponentin tuen?

Kaupallisten komponenttien osalta hankintatoimen pitäisi sopia tietoturvayhteyshenkilöistä, ilmoitusjärjestelyistä ja pääsystä korjauksiin. Toimittajan aikataulun on jätettävä tilaa omalle arvioinnillenne ja raportointivelvoitteillenne. Tuotteen valmistaja tarvitsee silti sisäisen eskalointipolun tilanteisiin, joissa toimittajan vastaus on puutteellinen.

Avoimen lähdekoodin riippuvuuksista säilytä alkuperätiedot ja realistinen ylläpitosuunnitelma. Se, että koodivarasto on julkisesti saatavilla, ei ole näyttöä siitä, että joku tuottaa yhteensopivan korjauksen tukijaksonne aikana.

Suunnittele tukijakso ja päivitysmekanismi yhdessä

Tuki on tekninen sitoumus, jolla on kaupallisia seurauksia. CRA edellyttää yleensä vähintään viiden vuoden tukijaksoa, ellei tuotteen odotettu käyttöaika ole lyhyempi. Määritä sovellettava jakso asetuksen kriteerien perusteella sen sijaan, että valitsisit tuotekehityssuunnitelmaan sopivan mielivaltaisen päivämäärän.

Kirjaa perustelut, toimita vaaditut tukitiedot asiakkaille ja kytke ne ylläpidettyihin tuoteversioihin. Tukisitoumuksessa on otettava huomioon kyky toimittaa tietoturvapäivityksiä, ei pelkästään asiakastuen osoitteen säilyttäminen.

Kysy ennen tuotteen tukisuunnitelman hyväksymistä, pystyttekö:

• Kääntämään vanhemmat tuetut haarat ylläpidetyillä työkaluketjuilla.
• Tuottamaan, todentamaan ja jakelemaan tietoturvapäivitykset turvallisesti.
• Testaamaan korjaukset tuetuissa laitteistoissa ja käyttöönottokonfiguraatioissa.
• Ylläpitämään allekirjoitusavaimia ja palautumaan turvallisesti avainten vaarantumisesta.
• Pitämään asiakkaille suunnatut päivitys- ja tietoturvatiedot saatavilla.
• Käsittelemään riippuvuuksia, joiden ylävirran tuki päättyy ennen omaanne.

Tietoturvapäivitykset on yleensä toimitettava maksutta tukijakson aikana asetuksen säännösten mukaisesti. Jokaisen tukijakson aikana julkaistun tietoturvapäivityksen on pysyttävä saatavilla vähintään kymmenen vuotta julkaisusta tai tukijakson loppuun, sen mukaan kumpi on pidempi. Suunnittele tietoturvakorjaukset erillään ominaisuuskehityksestä, jotta asiakkaita ei tarpeettomasti pakoteta toiminnallisiin muutoksiin, jotka eivät liity asiaan.

Testaa muutakin kuin onnistunut polku. Keskeytynyt asennus, riittämätön tallennustila, vanhentuneet tunnistetiedot ja epäonnistunut tarkistus voivat muuttaa pätevän korjauksen saatavuusongelmaksi. Päätä, mitä palautumismekanismeja tuotteen riskiprofiili edellyttää.

Tuen päättyessä asiakasviestinnän ja sisäisten tietueiden on oltava keskenään yhdenmukaisia. Älä jätä lataussivua antamaan ymmärtää, että tietoturvaylläpito jatkuu, kun tuoterekisterin mukaan sitoumus on päättynyt.

Laadi raportoinnin toimintaohje, joka kestää epävarmuuden

Tavallinen haavoittuvuushavainto, aktiivisesti hyödynnetty haavoittuvuus ja vakava tietoturvapoikkeama eivät ole keskenään vaihdettavissa. CRA:n raportointiprosessi edellyttää dokumentoitua arviota asiaankuuluvasta laukaisevasta tekijästä, ei jokaisen skannerihälytyksen automaattista raportointia eikä minkään asian automaattista sivuuttamista ilman valmista forensista tutkintaa.

Toimintaohjeen pitäisi alkaa vastaanotosta. Tutkijat, asiakastuki, toimittajat ja kehitystiimit tarvitsevat tunnetun reitin tuoteturvallisuustoiminnolle. Säilytä alkuperäinen ilmoitus ja kirjaa, milloin asiaankuuluvat tiedot tulivat tietoon; älä nollaa tietoon tulemisen aikaleimoja, kun tiketti siirtyy tiimiltä toiselle.

Kerää mahdollisesti raportoitavista tapahtumista:

• Tuotetunnisteet ja koskevat tuetut versiot.
• Näyttö hyödyntämisestä tai poikkeaman vaikutuksista sekä varmuustaso ja epävarmuudet.
• Tunnetut hyökkäysedellytykset, koskevat toiminnot ja käyttöönottoa koskevat oletukset.
• Saatavilla olevat lieventävät toimenpiteet ja korjaavien toimenpiteiden tila.
• Laukaisevan tekijän arviointi, raportoinnin omistaja ja sovellettavien määräaikojen laskelmat.
• Toimitetut ilmoitukset, vastaanottokuittaukset, myöhemmät päivitykset ja asiakasviestintä.

Tarkista vaiheittaiset ilmoitusmääräajat, loppuraporttia koskevat vaatimukset, vastaanottajat ja voimassa oleva raportointimenettely virallisista lähteistä. Aktiivisesti hyödynnetyillä haavoittuvuuksilla ja vakavilla poikkeamilla on omat raportointiyksityiskohtansa; yksi kopioitu määräaikakenttä ei riitä.

Nimeä ensisijainen raportoinnin omistaja ja varahenkilö, joilla on valtuudet koordinoida teknistä, oikeudellista ja asiakasviestintää. Järjestä etukäteen pääsy sovellettavaan raportointimekanismiin. Oikeudellisen katselmoinnin pitäisi olla saatavilla raportointi-ikkunan sisällä eikä muuttua rajattomaksi hyväksyntäjonoksi.

Harjoittele prosessia puutteellisilla tiedoilla. Hyödyllinen harjoitus alkaa uskottavasta hyödyntämisilmoituksesta, epävarmasta luettelosta koskevista versioista ja komponenttitoimittajasta, jota ei tavoiteta. Tiimin pitäisi pystyä tekemään oikea-aikainen, dokumentoitu raportointipäätös tutkinnan jatkuessa.

CRA-raportointi ei korvaa muita sovellettavia velvollisuuksia. Tuotteeseen liittyvä tapahtuma voi edellyttää myös arviointia tietosuojalainsäädännön tai asiakassopimuksen perusteella. Koordinoi nämä arvioinnit, mutta säilytä niiden erilliset laukaisevat tekijät, vastaanottajat ja päätöstietueet.

Vahvista luokitus ennen arviointisuunnitelman valintaa

Tuotteen luokitus vaikuttaa käytettävissä olevaan vaatimustenmukaisuuden arviointimenettelyyn. Älä oleta, että jokainen verkkoon kytketty tuote tarvitsee saman ulkoisen arvioinnin tai että jokainen valmistaja voi nojata sisäiseen arviointiin.

Määritä sovellettava luokka tuotteen toimintojen sekä asetuksen määritelmien ja liitteiden perusteella. Vahvista sitten sallittu menettely, mukaan lukien yhdenmukaistettuihin standardeihin, tunnustettuihin eritelmiin, sertifiointijärjestelmiin tai kolmannen osapuolen arviointiin liittyvät ehdot.

Standardien suunnittelu edellyttää nimenomaista riippuvuusrekisteriä: mitkä viittaukset ovat sovellettavissa, mikä niiden nykyinen tila on ja mikä muuttuu, jos odotettu menettely ei ole käytettävissä. Vältä tekemästä julkaisusuunnitelmaa riippuvaiseksi vahvistamattomasta oletuksesta standardeista tai arviointikapasiteetista.

Palaa luokitukseen, kun toiminnallisuus muuttuu. Tietoturvan hallinta- tai verkonhallintaominaisuuksien lisääminen voi vaikuttaa analyysiin, mutta pelkkä ominaisuuden nimi ei määritä luokkaa. Arvioi todellinen toiminto ja dokumentoi johtopäätös.

Pidä luokitus, valittu menettely ja vaatimustenmukaisuuden tuotokset kytkettyinä tekniseen dokumentaatioon. CE-merkinnän ja EU-vaatimustenmukaisuusvakuutuksen on noudatettava sovellettavaa prosessia; ne eivät korvaa taustalla olevien vaatimusten toteuttamista.

Ylläpidä näyttöpakettia, joka pystyy selittämään julkaisun

Teknisen dokumentaation pitäisi kuvata sekä tuote että sen tietoturvapäätösten taustalla olevat perustelut. Säilytä riskinarvioinnit ja dokumentaatio tuotteen muuttuessa ja sovella asiaankuuluviin tietueisiin lakisääteisiä säilytysvaatimuksia.

Hyödyllinen tuotteen näyttöpaketti sisältää soveltamisalapäätöksen, arkkitehtuurin, riskinarvioinnin, tietoturvavaatimukset, komponenttitiedot, varmennustulokset, haavoittuvuuksien käsittelymenettelyt, tukijakson perustelut ja vaatimustenmukaisuustietueet. Jokaisella kohteella on oltava omistaja ja tunnistettava versio.

Käytä pysyviä tunnisteita näiden tietueiden kytkemiseen. Haavoittuvuustietueen pitäisi selittää koskevat versiot, altistuminen, käsittely, julkaisu ja vaadittu viestintä. ”Korjattu” ilman versiokontekstia jättää tuotenäytön puutteelliseksi.

Olemassa olevat ISMS-prosessit voivat tuottaa hyödyllistä näyttöä hallinnosta, toimittajista ja turvallisesta kehityksestä. ISO 27001 koskee kuitenkin rajattua tietoturvallisuuden hallintajärjestelmää; sertifiointi ei osoita yksittäisen tuotteen CRA-vaatimustenmukaisuutta. Hyödynnä asiaankuuluvaa näyttöä uudelleen ilman, että pidät viitekehysten vastaavuuksia oikeudellisena vastaavuutena.

Esimerkki: riippuvuuden haavoittuvuus tuetussa laitteessa

Tarkastellaan havainnollistavaa valmistajaa, joka toimittaa verkkoon kytkettävää laitetta EU:ssa. Oletetaan, että sen soveltamisala ja luokitus on katselmoitu, kahta julkaisuhaaraa tuetaan edelleen ja mukana toimitetun kirjaston ilmoitetaan olevan aktiivisesti hyödynnetty muualla.

Ensimmäinen tehtävä ei ole ylävirran tiedotteen sulkeminen. Tuotekehitys selvittää, mitkä laitteen käännökset sisältävät haavoittuvan kirjaston ja onko haavoittuva toiminto saavutettavissa. SBOM viittaa siihen, että molemmat haarat sisältävät sen, mutta konfiguraatioanalyysi osoittaa altistumisen olevan erilainen. Ero kirjataan tukevan näytön kera.

Tuoteturvallisuuden omistaja arvioi sitten, täyttävätkö käytettävissä olevat tiedot sovellettavan CRA-raportoinnin laukaisevan ehdon. Yhteen käyttöönottokonfiguraatioon liittyvä epävarmuus kirjataan; se ei oikeuta jättämään päätöksen omistajaa nimeämättä. Raportoinnin toimintaohje kertoo voimassa olevat ilmoitusvaiheet ja menettelyn.

Tuotekehitys laatii väliaikaisen lieventävän toimenpiteen ja korjatun käännöksen jokaiselle haavoittuvalle haaralle. Testit kattavat haavoittuvan polun, normaalin toiminnan ja todennetun päivityksen asennuksen. Jos yhteen haaraan ei voida soveltaa ylävirran korjausta, tiimi kirjaa sen vaihtoehtoisen käsittelyn ja jäännösriskin sen sijaan, että merkitsisi koko tuotteen korjatuksi.

Asiakasviestinnässä yksilöidään koskevat versiot, välittömät suojaustoimet ja se, miten päivityksen saa. Julkistamisen ajoitus sovitetaan yhteen sovellettavien haavoittuvuuksien käsittelyvaatimusten ja mahdollisten perusteltujen tietoturvanäkökohtien kanssa.

Valmis tietue kytkee toisiinsa tiedotteen, haavoittuvien käännösten analyysin, raportointipäätöksen, tarvittaessa tehdyt ilmoitukset, korjausten commitit, testitulokset, julkaisuartefaktit ja viestinnän. Katselmoija pystyy nyt jäljittämään sekä teknisen reagoinnin että vaatimustenmukaisuuspäätöksen.

Aloita yhdestä tuotteesta ja yhdestä kokonaisesta näyttöketjusta

Valitse edustava tuettu tuote ja jäljitä yksi tuore julkaisu ja yksi haavoittuvuus elinkaaren läpi. Puuttuvat versiolinkit, epäselvät tukisitoumukset ja vaikeasti saavutettavat raportointimenettelyt tulevat nopeasti näkyviin. Muuta jokainen aukko omistajalle osoitetuksi tehtäväksi ja laajenna malli sitten koko tuotevalikoimaan.

Secani voi tukea tätä näyttötyönkulkua kytkemällä toisiinsa vaatimukset, näytön, omistajat, tehtävät ja katselmointipäätökset. Kehitystyökalut pysyvät käännösten, julkaisujen ja haavoittuvuuksien operatiivisina lähteinä; vaatimustenmukaisuuden työtila kytkee nämä tietueet sovellettavaan velvoitteeseen. Pidä ihmisen hyväksyntä nimenomaisena vastaavuuksien ja johtopäätösten osalta ja säilytä lähteiden jäljitettävyys tekoälyavusteisia luonnoksia käyttäessäsi.

Välitön seuraava askel on testata raportoinnin toimintaohje. Edellytä samanaikaisesti, että tuotteen seuraavaan julkaisuun liitetään soveltamisalapäätös, ajantasainen riskinarviointi, komponenttiluettelo ja tietoturvahyväksyntä. Näin syntyy toistettava tekninen käytäntö vaatimustenmukaisuuden valmistelun edetessä.