Lähetä alustava tiedote muutamassa tunnissa, vahvistettu vastaus heti kun voit todistaa sen, ja jatkotiedote aina, kun jokin muuttuu. Kerro, mitä tiedät, mitä vielä tarkistat ja milloin päivität tietoja. Perusta jokainen ”ei vaikutusta” siihen, mitä buildisi todella asensivat hyökkäyksen aikaikkunassa, älä tämänpäiväiseen lukitustiedostoon.
Tämä kirjoitus käsittelee sitä, mitä sanoa, milloin ja millä perusteella. Itse selvitystyöstä eli siitä, miten selvität, onko haavoittuva komponentti tuotteissasi ja mistä lähtien, kerrotaan kirjoituksessa koskeeko CVE meitä?.
Miksi asiakkaat kysyvät sinulta eivätkä pakettirekisteriltä
Laajasti uutisoidun hyökkäyksen jälkeisellä viikolla asiakkaat lähettivät pienelle ohjelmistotoimittajalle tekstiviestejä, hän kertoi meille: onko teidän juttunne turvassa? Onko minun juttuni turvassa? Hänen asiakkaansa käsittelevät arkaluonteisia tietoja, hänen tiimissään ei ole tietoturva-asiantuntijaa, ja kysymykseen tarvittiin vastaus samana päivänä.
Asiakkaat eivät kysy, kaapattiinko paketti. Rekisteri ja tutkijat ovat jo kertoneet sen. He kysyvät, sisältääkö se, mitä toimitit heille, kaapatun paketin, koska sinun tuotteesi on heidän altistuksensa. Heiltä kysyvät samaa heidän omat asiakkaansa, auditoijansa tai viranomaisensa. Säännellyissä toimitusketjuissa, kuten puolijohteissa, teollisuuslaitteissa ja terveydenhuollossa, kysymys perustuu sopimukseen, ei uteliaisuuteen.
He kysyvät myös uudelleen, jos vastaustasi ei voi tarkistaa. ”Meihin ei kohdistu vaikutusta” ilman mitään perusteluja on lupaus; ”tarkistimme jokaisen julkaisubuildin 24.–31.3. välillä, eikä yksikään asentanut vaikutuksen alaisia versioita” on lausunto, johon he voivat luottaa.
Neljä tuoretta hyökkäystä ja kysymys, jonka kukin herätti
Oikea vastaus riippuu siitä, miten hyökkäys toimi, joten pelkkä mallipohja ei riitä. Kussakin näistä yksi tosiasia ratkaisee, mitä ”vaikutuksen alainen” tarkoittaa toimittajalle.
xz Utils -takaovi (CVE-2024-3094), julkistettu 29.3.2024. Andres Freund löysi takaoven xz:n versioista 5.6.0 ja 5.6.1. Julkaisujen tar-paketit sisälsivät koodia, jota Git-repositoriossa ei ollut, ja se lisäsi takaoven buildin aikana. NVD ja Red Hat antavat sille molemmat pistemäärän 10.0 CVSS 3.1:n mukaan. Se päätyi lähinnä jatkuvasti päivittyviin ja testausjakeluihin: Debianin testing-, unstable- ja experimental-haaroihin, Fedora Rawhideen ja 41:een, openSUSE Tumbleweediin ja Kaliin, kun taas vakaat julkaisut eivät olleet vaikutuksen alaisia. Sen herättämä kysymys: sisältääkö jokin toimittamamme kuva tai laite xz:n version 5.6.0 tai 5.6.1, ja mitä pohjakuvaa kukin buildi käytti?
Shai-Hulud-npm-mato, aaltoina syyskuusta 2025 lähtien. Saastuneet paketit ajavat asennuksen yhteydessä skriptin, joka varastaa npm-, GitHub- ja pilvitunnuksia ja käyttää niitä saastuneiden versioiden julkaisemiseen muista paketeista. Sen herättämä kysymys: asensiko jokin CI-jobi saastuneen version, ja paljastuivatko julkaisutokenimme, mikä tekisi meistä levittäjän? Shai-Hulud-merkintämme luettelee jokaisen aallon ja kertoo, miten tarkistat.
LiteLLM PyPI:ssä, 24.3.2026. Versiot 1.82.7 ja 1.82.8 ladattiin suoraan PyPI:hin tunnuksia varastavan koodin kanssa, jota ei koskaan ollut projektin GitHub-repositoriossa. Versiossa 1.82.8 .pth-tiedosto ajoi haittakoodin aina, kun mikä tahansa Python-tulkki käynnistyi, ei vain silloin, kun LiteLLM tuotiin; se keräsi ympäristömuuttujia, SSH-avaimia, pilvitunnuksia ja Kubernetes-salaisuuksia. HiddenLayer yhdistää hyökkäyksen TeamPCP:hen, joka iski samassa kuussa myös Trivy- ja Checkmarx-työkaluihin. LiteLLM:n oma tiedote antaa alkuperäiselle pääsylle kaksi selitystä: se jäljittää kaappauksen CI:n tietoturvaskannaustyönkulun Trivy-riippuvuuteen ja sanoo, että ylläpitäjän PyPI-tili on saatettu kaapata. Jopa altistusikkuna vaihtelee tiedotteen sisällä: yhdessä kohdassa noin 40 minuuttia, toisessa 10.39–16.00 UTC. Sen herättämä kysymys: sisältyivätkö nuo versiot buildiin tai toimitettuun konttiin, ja mitä salaisuuksia tuossa ympäristössä oli?
axios npm:ssä, 31.3.2026. Hyökkääjä kaappasi ylläpitäjän npm-tilin ja julkaisi axiosin versiot 1.14.1 ja 0.30.4, jotka lisäsivät riippuvuuden [email protected], jonka asennusskripti pudotti etäkäyttötroijalaisen macOS:lle, Windowsille ja Linuxille. Datadogin mukaan ikkuna oli 00.21–03.25 UTC; Snykin mukaan versiot poistettiin klo 03.29 UTC. Sen herättämä kysymys: ratkaisiko jokin buildi riippuvuuden noihin versioihin tuona aikana? Ennen ikkunaa commitoitu lukitustiedosto vastaa ”ei” niiden buildien osalta, jotka käyttivät sitä, eikä kerro mitään buildeista, jotka ajoivat npm install ilman sitä.
| Hyökkäys | Ekosysteemi | Vaikutuksen alaiset versiot | Aikaikkuna | Mitä ”vaikutuksen alainen” tarkoittaa toimittajalle |
|---|---|---|---|---|
| xz Utils | Linux-jakelut | 5.6.0, 5.6.1 | Viikkoja, julkistukseen 29.3.2024 asti | Toimitit sen kuvassa tai laitteessa, joka on rakennettu vaikutuksen alaisen jakelun päälle |
| Shai-Hulud | npm | Satoja paketteja aaltoa kohden | Tunneista päiviin aaltoa kohden | Buildasit sen kanssa, ja tokenisi ovat voineet levittää sitä; olet voinut myös toimittaa sen |
| LiteLLM | PyPI | 1.82.7, 1.82.8 | 24.3.2026, klo 10.39 UTC alkaen (lähteet eroavat lopusta) | Buildasit sen kanssa tai toimitit sen, ja tuon ympäristön salaisuudet ovat voineet vuotaa |
| axios | npm | 1.14.1, 0.30.4 | 31.3.2026, noin 00.21–03.25 UTC | Buildasit sen kanssa ikkunan aikana; troijalainen ajettiin buildikoneella |
Samat kysymykset nousevat esiin myös kriittisen haavoittuvuuden kohdalla, joka ei ole toimitusketjuhyökkäys. Kun PHP2Shell-haavoittuvuutta hyödynnettiin lokakuussa 2026, jokaisen PHP:tä sisältävän tuotteen asiakkaat kysyivät, missä heidän versioissaan on vaikutuksen alainen PHP. Alla olevat vaiheet pätevät sellaisinaan.
Vastauksessa on kolme vaihetta
| Vaihe | Milloin | Mitä lähetät |
|---|---|---|
| Alustava tiedote | Muutaman tunnin sisällä uutisesta | Mitä tiedät, mitä tarkistat, milloin päivität |
| Vahvistettu vastaus | Heti kun voit todistaa sen, yleensä ensimmäisenä päivänä | ”Ei vaikutusta” nimetyille versioille tai ”vaikutuksen alainen” ja toimintaohjeet |
| Jatkotiedote | Kun korjaus julkaistaan, kun saat uutta tietoa, kun suljet tapauksen | Sama tiedote päivitettynä |
Ensimmäinen tunti: alustava tiedote
Alustava tiedote on ensimmäinen julkinen lausuntosi ennen kuin tosiasiat ovat selvillä. Sano jotain totta, nopeasti. Hiljaisuus täyttyy oletuksilla, ja asiakas, joka ei kuule sinusta mitään, olettaa, ettet ole huomannut asiaa.
- Kuka ja missä. Yksi nimetty lähettäjä, siinä kanavassa, jota asiakas käytti, sekä tietoturvasivusi. Yksi yhteinen teksti on parempi kuin tapauskohtaiset vastaukset: se pysyy johdonmukaisena, ja lakiosasto tarkistaa sen kerran.
- Mitä se sisältää. Että tiedät hyökkäyksestä, että tarkistat tuotteesi ja buildijärjestelmäsi, mitä tiedät tähän mennessä, milloin seuraava päivitys tulee ja keneen ottaa yhteyttä.
- Mitä se ei saa sisältää. ”Meihin ei kohdistu vaikutusta” ennen kuin olet tarkistanut, spekulointia hyökkääjästä tai syyttelyä.
Mallipohja 1: alustava tiedote
Aihe: [Hyökkäyksen nimi]: alustava tiedotteemme
Olemme tietoisia raportoidusta [paketin tai projektin] kaappauksesta ([vaikutuksen alaiset versiot], julkaistu [päivämäärä]). Tietoturvatiimimme tarkistaa jokaisen [tuotteen] julkaisun ja buildijärjestelmämme vaikutuksen alaisten versioiden varalta. Tähän mennessä [emme ole löytäneet vaikutuksen alaisia versioita tarkistetuista tuotteista / emme ole vielä saaneet tarkistusta valmiiksi]. Lähetämme päivityksen viimeistään [päivämäärä ja kellonaika, aikavyöhyke]. Jos sinulla on sillä välin kysyttävää, ota yhteyttä: [nimi, tietoturvayhteyshenkilön osoite]. Emme spekuloi vaikutuksista ennen kuin tarkistus on valmis.Tekstiviestiin tai chattiin kaksi lausetta riittää:
Tiedämme [hyökkäyksen nimi] -kaappauksesta ja tarkistamme parhaillaan jokaisen [tuotteen] julkaisun ja buildimme. Saat meiltä vahvistetun vastauksen viimeistään [aika].Hyväksytä kaikki kolme mallipohjaa lakimiehellä ennen kuin tarvitset niitä.
Ensimmäinen päivä: vahvista, näytön kanssa
Lopputuloksia on kaksi, ja kumpikin tarvitsee oman näyttönsä. ”Ei vaikutusta” -vastausta varten kerää:
- vaikutuksen alainen paketti ja versiot tietoturvatiedotteesta tai tutkijoiden raportista
- tuotteesi ja versiot, joita asiakkaat todella käyttävät
- jokaiselle näistä versioista buildi, joka tuotti sen, ja tallenne siitä, mitä buildi asensi, ei nykyistä lukitustiedostoa
- jokainen hyökkäyksen aikaikkunassa ajettu buildi, myös CI-jobit, jotka eivät koskaan tuottaneet julkaisua
- tokeneita varastavien matojen osalta se, oliko CI-salaisuuksia jobeissa, jotka ovat voineet ajaa haitallisen koodin
Koskeeko CVE meitä? kertoo, miten selvität kunkin näistä.
Jokaisen antamasi lausunnon tueksi on oltava jotain, minkä voit näyttää:
| Lausunto | Mitä sinun on pystyttävä näyttämään | Mikä ei riitä |
|---|---|---|
| ”Tuotteen X versio Y ei sisällä pakettia Z” | Version Y julkaisubuildista tallennettu SBOM | Nykyisen repositorion skannaus |
| ”Yksikään buildimme ei asentanut kaapattuja versioita” | Asennustallenteet jokaisesta ikkunan aikaisesta buildista | Lukitustiedosto, jonka jotkin jobit ohittavat |
| ”Julkaisuputkeamme ei kaapattu” | Ikkunan aikaiset verkko- ja salaisuuksien käyttötallenteet | Hälytysten puuttuminen |
| ”Versiota Y käyttävät asiakkaat ovat turvassa päivityksen jälkeen” | Korjatun buildin tallenne ja vaihtamasi tunnukset | Muutoslokin merkintä |
Mallipohja 2: ei vaikutusta
Aihe: [Hyökkäyksen nimi]: [tuote] ei ole vaikutuksen alainen
Olemme saaneet valmiiksi [paketin] kaappausta ([vaikutuksen alaiset versiot]) koskevan tarkistuksemme. Seuraavat [tuotteen] versiot eivät ole vaikutuksen alaisia: [luettelo tarkistetuista tuotteista ja versioista]. Tarkistimme jokaisen julkaisubuildin ja CI-buildin, joka ajettiin [alkupäivämäärä] ja [loppupäivämäärä] välisenä aikana. Tämä lausunto perustuu tallenteeseen kunkin julkaisubuildin asentamista komponenteista, ei nykyisen lähdekoodimme skannaukseen. Yksikään näistä buildeista ei asentanut vaikutuksen alaisia versioita. Jos tarvitset näytön, voimme lähettää käyttämiesi versioiden SBOM:n tai VEX-lausunnon. Jos saamme tietoa, joka muuttaa tätä arviota, kerromme siitä sinulle. Yhteyshenkilö: [nimi, tietoturvayhteyshenkilön osoite].Sano ”ei vaikutusta” nimetyille versioille. Älä koskaan kirjoita ”100-prosenttisen turvallinen”. Jos asiakas pyytää sen jälkeen koko SBOM:n, katso vastaaminen asiakkaiden SBOM-pyyntöihin.
Mallipohja 3: vaikutuksen alainen, lievennystoimin
Aihe: [Hyökkäyksen nimi]: toimenpiteitä tarvitaan [tuotteen] versioille [x–y]
[Paketin] kaappausta koskeva tarkistuksemme osoitti, että [tuotteen] versiot [x–y] ovat vaikutuksen alaisia. Ensimmäinen vaikutuksen alainen buildi tuotettiin [päivämäärä]; versio [z], julkaistu [päivämäärä], ei enää sisällä [paketin versiota].
Mitä tämä tarkoittaa: [riski selkokielellä, esimerkiksi "näissä versioissa asennettu komponentti voi lähettää tunnuksia järjestelmästä, jossa se toimii, ulkopuoliselle palvelimelle"].
Mitä tehdä nyt: päivitä [tuotteen] versioon [z]. Jos et voi päivittää heti, [lievennystoimi, esimerkiksi estä lähtevät yhteydet luettelossa mainittuihin palvelimiin]. Jos käytit [tuotteen] versioita [x–y] ympäristössä [ympäristö], vaihda [tunnukset tai avaimet], jotka olivat sen käytettävissä.
Mitä olemme tehneet: poistimme vaikutuksen alaiset versiot buildeistamme, buildasimme [tuotteen] uudelleen puhtaista riippuvuuksista, vaihdoimme buildijärjestelmiemme käyttämät tunnukset ja [muut toimet]. [Olemme ilmoittaneet asiasta asianomaisille viranomaisille, kun se on vaadittu.]
Lähetämme seuraavan päivityksen viimeistään [päivämäärä] tai aiemmin, jos jokin muuttuu. Yhteyshenkilö: [nimi, tietoturvayhteyshenkilön osoite].”Vaikutuksen alainen” -ilmoitus voi olla myös lakisääteinen velvollisuus; katso raportointia käsittelevä osio alempana.
Mihin VEX ja CSAF sopivat. ”Ei vaikutusta”- tai ”korjattu”-lausunnon voi julkaista VEX-muodossa, jolloin asiakkaiden skannerit lakkaavat liputtamasta pakettia. Suuremmat asiakkaat voivat odottaa myös koneluettavaa tietoturvatiedotetta; CSAF on muoto, jota useimmat heistä pyytävät.
Jatkotiedote: sulje asia kunnolla
Lähetä jatkotiedote, kun korjaus julkaistaan, kun selvityksesi tuo esiin jotain uutta, ja loppuilmoitus, kun tapaus suljetaan. Pidä yksi tietoturvatiedote tapausta kohden ja päivitä sitä sen sijaan, että lähettäisit joka kerta uuden (päivitä, älä korvaa). Kirjaa, mitä kerroit kenellekin ja milloin: seuraava auditointi tai asiakkaan tietoturvakysely kysyy sitä.
Mitä sanoa, kun et vielä tiedä
”Emme vielä tiedä” rakentaa enemmän luottamusta kuin ”ei vaikutusta”, joka joudutaan perumaan. Ilmauksia, jotka ovat rehellisiä hälyttämättä ketään:
- ”Emme ole löytäneet [pakettia] [tähän mennessä tarkistetuista tuotteista]. Tarkistamme vielä [jäljellä olevat tuotteet tai buildijärjestelmät] ja päivitämme tilanteen viimeistään [aika].”
- ”Käyttämäsi versiot on buildattu ennen hyökkäyksen aikaikkunaa. Varmistamme, ettei mikään myöhempi buildi korvannut niitä.”
- ”Tarkistamme, ajoiko jokin buildijärjestelmistämme vaikutuksen alaisia versioita. Asennettu tuotteesi on eri kysymys, ja vastaamme molempiin.”
Vältettäviä ilmauksia:
- ”Ei minkäänlaista vaikutusta”
- ”Täysin turvallinen”
- ”Mikään toimitusketjuhyökkäys ei vaikuta meihin”
- ”Skannerimme ei löytänyt mitään”
Kun hyökkäyksestä tulee raportointivelvollisuus
Jos myyt EU:ssa digitaalisia elementtejä sisältäviä tuotteita, EU:n kyberkestävyyssäädöksen (Cyber Resilience Act, CRA) raportointivelvoitteita on sovellettu 11.9.2026 alkaen, samana päivänä kun ENISA otti keskitetyn raportointialustan käyttöön. Aktiivisesti hyödynnetty haavoittuvuus tuotteessasi tai sen tietoturvaan vaikuttava vakava poikkeama käynnistää ennakkovaroituksen 24 tunnin kuluessa siitä, kun olet saanut siitä tiedon, ilmoituksen 72 tunnin kuluessa ja loppuraportin, jotka toimitetaan alustan kautta koordinoivalle CSIRT-yksikölle ja ENISAlle. CRA-opas käy vaiheet läpi.
Täyttääkö toimittamasi kaapattu riippuvuus tai oman buildiputkesi kaappaus nämä määritelmät, on sinun ja lakimiehesi arvioitava, ei tämän kirjoituksen. Asetus määrittelee käsitteet:
- ”Aktiivisesti hyödynnetty haavoittuvuus” on ”haavoittuvuus, josta on luotettavaa näyttöä siitä, että pahantahtoinen toimija on hyödyntänyt sitä järjestelmässä ilman järjestelmän omistajan lupaa” (3 artiklan 42 alakohta).
- Poikkeama on vakava, jos ”se vaikuttaa tai voi vaikuttaa haitallisesti digitaalisia elementtejä sisältävän tuotteen kykyyn suojata arkaluonteisten tai tärkeiden tietojen tai toimintojen saatavuutta, aitoutta, eheyttä tai luottamuksellisuutta” tai jos ”se on johtanut tai voi johtaa haitallisen koodin käyttöönottoon tai suorittamiseen” tuotteessa tai käyttäjän järjestelmissä (14 artiklan 5 kohta).
14 artiklan 8 kohta lisää velvollisuuden käyttäjiä kohtaan: ilmoita asianomaisille käyttäjille ja tarvittaessa kaikille käyttäjille haavoittuvuudesta tai poikkeamasta sekä mahdollisista lievennystoimista, joita he voivat toteuttaa, ”tarvittaessa jäsennellyssä, koneluettavassa muodossa, joka on helposti automaattisesti käsiteltävissä”. Mallipohja 3 voi olla osa tämän velvollisuuden täyttämistä.
Myös muut säädökset ovat voimassa. NIS2-direktiivin mukaan keskeiset ja tärkeät toimijat ilmoittavat merkittävistä poikkeamista CSIRT-yksikölleen tai toimivaltaiselle viranomaiselle, ja monissa asiakassopimuksissa on omat ilmoituslausekkeensa omine määräaikoineen.
Ole valmis ennen seuraavaa kertaa
- Tallenne siitä, mitä kukin julkaisubuildi asensi, säilytettynä tuotteen tukiajan (buildin aikana tallennetut SBOM:t).
- Luettelo siitä, mitkä asiakkaat käyttävät mitäkin versioita.
- Edellä olevat kolme mallipohjaa lakiosaston hyväksyminä.
- Nimetty lähettäjä ja kanava kullekin asiakasryhmälle.
- Tietoturvasivu ja
security.txt-tiedosto, joihin päivitykset menevät (koordinoitu haavoittuvuuksien julkistaminen). - Lähtevän liikenteen hallinta CI:ssä, jotta kaapattu paketti ei voi lähettää salaisuuksia palvelimelle, jota buildi ei tarvitse (GitHub Actionsin egress-käytäntö).
Jos tapauksia tulee sadoittain eikä yksi kerrallaan, katso PSIRT-toiminnan skaalaaminen.
Miten CRACI sopii tähän
Yllä oleva näyttötaulukko pyytää toistuvasti yhtä asiaa: tallennetta siitä, mitä kukin julkaisubuildi asensi. Juuri sen CRACI säilyttää. CRACI ajaa GitHub Actions -buildisi omilla runnereillaan ja tallentaa jokaisen paketin, jonka kukin jobi todella haki, mukaan lukien asennusskriptien hakemat paketit ja välimuisteista palautetut paketit. Jokaisen aiemman buildin SBOM säilytetään, joten kysymykseen ”asensiko jokin buildi axiosin version 1.14.1 ikkunan aikana?” vastataan buildihistoriasta, altistusjakson kanssa, niin kauas taaksepäin kuin säilytysaikasi ulottuu.
Tunnetut haitalliset julkaisut, joilla on julkaistu CVE, kuten xz-takaovi, liputetaan kuten mikä tahansa muu haavoittuvuus, ja käytäntöportti voi estää buildit, jotka sisältävät niitä. CRACI ei tunnista uutta haitallista pakettia sen käyttäytymisen tai maineen perusteella.
CRACI:n egress-käytäntö estää yhteydet palvelimiin, joita buildi ei tarvitse, mikä rajoittaa sitä, mitä haitallinen asennusskripti voi lähettää ulos, myös hyökkäyksessä, jota kukaan ei ole ennen nähnyt. Kun asiakas pyytää näyttöä, voit viedä hänen käyttämiensä versioiden SBOM:n CycloneDX- tai SPDX-muodossa ja lähettää sen. CRACI tukee VEX:iä.
Vastaa kysymykseen ”koskiko se meitä?” buildihistoriastasi tai lue lisää siitä, miten toimitusketjuhyökkäykset toimivat.
Kun CRACI ei ole vastaus
- Tarvitset apua itse viestintään. Viestintä- ja oikeudellinen neuvonta on eri tehtävä.
- Vaikutuksen alaista ohjelmistoa ei buildattu CRACI:lla. CRACI tallentaa GitHub Actions -buildit, jotka ajetaan sen runnereilla; muut CI-järjestelmät ovat tiekartalla.
- Kysymys koskee toimittajan tuotetta, jota et itse buildannut. Toimittajien SBOM:eja voi lisätä CRACI:iin, mutta vastaus on vain yhtä hyvä kuin toimittajan SBOM.
- Sinun on havaittava upouusi haitallinen paketti ennen kuin mitään tietoturvatiedotetta on olemassa. CRACI liputtaa tunnetut haitalliset julkaisut, kun CVE:n sisältävä tiedote on julkaistu; se ei tunnista haittaohjelmia käyttäytymisen tai maineen perusteella (nollapäivähaavoittuvuuksiin reagoiminen).
Usein kysytyt kysymykset
Mitä kerron asiakkaille, kun toimitusketjuhyökkäys on uutisissa?
Lähetä alustava tiedote muutamassa tunnissa: tiedät hyökkäyksestä, tarkistat tuotteesi ja buildisi, mitä tiedät tähän mennessä ja milloin päivität tietoja. Lähetä sen perään vahvistettu vastaus nimetyille tuoteversioille heti kun voit perustella sen buildien tallenteilla, ja jatkotiedote, kun jokin muuttuu.
Mitä alustavassa tiedotteessa pitäisi sanoa?
Mitä tapahtui yhdellä lauseella, että tarkistat tuotteesi ja buildijärjestelmäsi, mitä olet löytänyt tähän mennessä, seuraavan päivityksen ajankohta ja yhteyshenkilö. Siinä ei saa sanoa ”ei vaikutusta” ennen kuin olet tarkistanut, spekuloida hyökkääjästä eikä syyttää ketään.
Miten sanon ”meihin ei kohdistu vaikutusta” lupaamatta liikoja?
Nimeä tarkistamasi tuotteet ja versiot, tarkistamiesi buildien aikaväli ja käyttämäsi näyttö, kuten tallenne kunkin julkaisubuildin asentamista komponenteista. Sano ”ei vaikutusta” näille versioille, tarjoa SBOM tai VEX-lausunto ja lupaa päivittää, jos jokin muuttuu. Vältä ilmauksia ”100-prosenttisen turvallinen” tai ”täysin turvallinen”.
Mitä asiakkaille lähetettävän ”vaikutuksen alainen” -ilmoituksen pitäisi sisältää?
Mitkä tuotteet ja versiot ovat vaikutuksen alaisia, mistä lähtien ja mihin korjattuun versioon asti, riski selkokielellä, mitä asiakkaan pitäisi tehdä nyt (päivittää, vaihtaa tunnukset, estää palvelimet), mitä olet jo tehnyt, milloin seuraava päivitys tulee ja keneen ottaa yhteyttä.
Millä näytöllä ”ei vaikutusta” -lausunto pitäisi perustella?
Jokaisen asiakkaiden käyttämän version osalta tallenteella siitä, mitä sen tuottanut buildi asensi, ei tämänpäiväisellä lukitustiedostolla. Lisää tallenteet jokaisesta hyökkäyksen aikaikkunassa ajetusta buildista ja tunnuksia varastavien hyökkäysten osalta tieto siitä, oliko salaisuuksia jobeissa, jotka ovat voineet ajaa haitallisen koodin.
Onko toimitusketjuhyökkäyksestä raportoitava kyberkestävyyssäädöksen (Cyber Resilience Act) nojalla?
Mahdollisesti. 11.9.2026 alkaen EU:ssa myytävien digitaalisia elementtejä sisältävien tuotteiden valmistajien on raportoitava aktiivisesti hyödynnetyistä haavoittuvuuksista ja tuotteen tietoturvaan vaikuttavista vakavista poikkeamista: ennakkovaroitus 24 tunnin kuluessa, ilmoitus 72 tunnin kuluessa ja loppuraportti. Täyttääkö tietty hyökkäys ehdot, on sinun ja lakimiehesi arvioitava.
Kuinka nopeasti asiakkaille pitäisi vastata?
Muutamassa tunnissa alustavalla tiedotteella, vaikka se kertoisi vain, että tarkistat asiaa ja milloin päivität tietoja. Vahvistettu vastaus seuraa heti kun voit todistaa sen. Nopea ja rehellinen ”tarkistamme asiaa” tekee luottamukselle enemmän kuin myöhäinen ”ei vaikutusta”.
