Producenci portfeli kryptowalut w UE mają 24 godziny na zgłaszanie exploitów
Najważniejsze informacje
- •Od 11 września producenci portfeli kryptowalut sprzedawanych w UE muszą zgłaszać aktywnie wykorzystywane luki i poważne incydenty bezpieczeństwa w ciągu 24 godzin na podstawie art. 14 Aktu o cyberodporności, na długo przed wejściem w życie głównych obowiązków CRA 11 grudnia 2027 roku.
- •Wstępne ostrzeżenia należy przesyłać za pośrednictwem Single Reporting Platform ENISA do CSIRT w państwie członkowskim, w którym producent ma główną siedzibę; szczegółowe zgłoszenie musi trafić do organów w ciągu 72 godzin.
- •Obowiązek obejmuje produkty objęte przepisami, które były już dostępne w UE przed grudniem 2027 roku. Zakresem mogą zostać objęte komercyjne portfele sprzętowe oraz aplikacje portfeli na komputery i urządzenia mobilne, choć portfele kryptowalut nie są wymienione wprost.
- •24-godzinny termin zaczyna biec, gdy producent dowie się o aktywnym wykorzystywaniu luki lub poważnym incydencie bezpieczeństwa, a nie w momencie prywatnego zgłoszenia błędu przez badacza; wstępne zgłoszenie trafia do organów, a nie obowiązkowo do opinii publicznej.
- •Projekty portfeli open source nie są objęte pełnym zwolnieniem, ponieważ wytyczne Komisji Europejskiej wskazują, że producent wprowadzający na rynek bezpłatny produkt open source nadal podlega obowiązkom producenta.

Producenci portfeli kryptowalut i innych produktów zawierających elementy cyfrowe muszą od 11 września rozpocząć zgłaszanie aktywnie wykorzystywanych luk w zabezpieczeniach oraz poważnych incydentów bezpieczeństwa dotyczących produktów udostępnianych w Unii Europejskiej. Wstępne zgłoszenie należy przesłać za pośrednictwem Single Reporting Platform obsługiwanej przez ENISA do CSIRT w państwie członkowskim, w którym producent ma główną siedzibę, a w normalnych okolicznościach także do ENISA.
Wymóg wynikający z art. 14 unijnego Aktu o cyberodporności (CRA) zaczyna obowiązywać przed większością pozostałych przepisów rozporządzenia. Szersze ramy CRA, w tym wymogi dotyczące projektowania produktów, dokumentacji i zgodności, zaczną mieć zastosowanie głównie od 11 grudnia 2027 roku. Wcześniejsze przepisy dotyczące zgłaszania oznaczają jednak, że firma zajmująca się portfelami może już podlegać ustawowemu terminowi, gdy exploit jest aktywny.
Zasada obejmuje także produkty objęte zakresem przepisów, które zostały udostępnione w UE przed grudniem 2027 roku, a nie tylko przyszłe urządzenia i wydania oprogramowania. Komisja Europejska opublikowała dodatkowe wytyczne dotyczące zgłaszania luk i incydentów na podstawie CRA.
Portfele sprzętowe i programowe mogą być objęte przepisami
CRA ma zastosowanie do produktów sprzętowych i programowych udostępnianych komercyjnie w UE, jeżeli ich zamierzone lub racjonalnie przewidywalne zastosowanie obejmuje bezpośrednie lub pośrednie logiczne albo fizyczne połączenie z urządzeniem lub siecią. Komercyjne portfele sprzętowe, a także aplikacje portfeli na komputery stacjonarne i urządzenia mobilne, mogą zatem być objęte zakresem przepisów.
Obowiązek prawny spoczywa na producencie — osobie lub firmie, która opracowuje produkt albo zleca jego opracowanie i wprowadza go do obrotu pod własną nazwą lub znakiem towarowym. Firma sprzedająca urządzenie sprzętowe lub dystrybuująca oprogramowanie portfela w UE jest wyraźniejszym przykładem niż osoba wnosząca wkład do niezwiązanego z tym projektu open source.
Portfele kryptowalut nie zostały wskazane w CRA wprost, dlatego ustalenie, czy konkretny produkt podlega przepisom, może nadal wymagać oceny prawnej.
Pierwsze zgłoszenie należy przesłać w ciągu 24 godzin
Pierwsze zgłoszenie ma formę wstępnego ostrzeżenia, a nie zakończonego dochodzenia technicznego. Gdy producent dowie się o aktywnie wykorzystywanej luce w zabezpieczeniach, musi bez zbędnej zwłoki, nie później jednak niż w ciągu 24 godzin, powiadomić organy. W stosownych przypadkach wstępne ostrzeżenie musi wskazywać państwa członkowskie, w których firma wie, że dany produkt został udostępniony.
Ten sam termin dotyczy poważnego incydentu wpływającego na bezpieczeństwo produktu. W takiej sytuacji wstępne ostrzeżenie musi co najmniej określać, czy producent podejrzewa, że incydent został spowodowany bezprawnym lub złośliwym działaniem, oraz wskazywać właściwe rynki, na których produkt jest dostępny.
Bardziej szczegółowe zgłoszenie należy przesłać w ciągu 72 godzin. Zgodnie z wytycznymi Komisji Europejskiej musi ono zawierać dostępne informacje o produkcie oraz ogólny charakter exploitu i luki w zabezpieczeniach. Zgłoszenie powinno również opisywać podjęte już działania naprawcze lub ograniczające skutki, kroki, które mogą podjąć użytkownicy, oraz — w stosownych przypadkach — ocenę producenta dotyczącą wrażliwości tych informacji.
Aktywne wykorzystanie uruchamia bieg terminu
24-godzinny termin nie rozpoczyna się za każdym razem, gdy badacz prywatnie zgłasza błąd. Ma zastosowanie, gdy producent dowie się, że luka jest aktywnie wykorzystywana przeciwko produktowi, lub gdy dowie się o poważnym incydencie wpływającym na bezpieczeństwo produktu.
Firma może otrzymać zgłoszenie luki, zbadać ją i przygotować poprawkę bez automatycznego wejścia w proces zgłaszania na podstawie art. 14. Regulowany termin zaczyna biec, gdy firma dowie się, że atakujący wykorzystują lukę, zanim poprawka zostanie ukończona.
Niedawne informacje dotyczące Coldcard pokazują, dlaczego to rozróżnienie ma znaczenie. W ostrzeżeniu z lipca dotyczącym potencjalnie słabego generowania seedów praktyczne ryzyko wykraczało poza samo zidentyfikowanie luki. Użytkownicy, których to dotyczyło, musieli ustalić, czy ich seed został ujawniony, i w razie potrzeby przenieść środki. Sprawę opisał Coindoo.
Zgłoszenia trafiają do organów, a nie automatycznie do opinii publicznej
Wymóg 24-godzinnego zgłoszenia nie oznacza, że producent musi natychmiast opublikować szczegóły niezałatanej luki w portfelu. Wstępne zgłoszenie jest przesyłane do właściwego CSIRT i ENISA za pośrednictwem Single Reporting Platform. Nie jest ono automatycznie publicznym ostrzeżeniem ani obowiązkowym wpisem na blogu zawierającym techniczne informacje o exploicie.
CRA wymaga od organów i innych podmiotów zaangażowanych w stosowanie rozporządzenia ochrony informacji poufnych, w tym kodu źródłowego, tajemnic handlowych oraz informacji, które mogłyby zaszkodzić dochodzeniu. W przypadkach skoordynowanego ujawniania luk CSIRT może opóźnić przekazanie innym CSIRT powiadomienia o wykorzystywanej luce, jeżeli istnieją ku temu uzasadnione względy cyberbezpieczeństwa.
Publiczne ujawnienie pozostaje możliwe, gdy jest konieczne do zapobieżenia poważnemu incydentowi lub ograniczenia jego skutków, zajęcia się trwającym incydentem albo ochrony interesu publicznego. Po konsultacji z producentem CSIRT może poinformować opinię publiczną lub zobowiązać producenta do tego działania. Producenci portfeli muszą przekazać organom wystarczające informacje do oceny ryzyka, jednocześnie wyjaśniając użytkownikom, jak mogą się chronić, bez ujawniania szczegółów, które mogłyby pomóc atakującemu.
Portfele open source nie są automatycznie zwolnione
CRA nie ma zastosowania do bezpłatnego oprogramowania open source, które nie jest udostępniane na rynku w ramach działalności komercyjnej. Nie dotyczy również osób, które jedynie wnoszą kod do oprogramowania open source pozostającego poza ich odpowiedzialnością.
Przepisy te nie tworzą jednak pełnego zwolnienia dla projektów portfeli open source. Wytyczne Komisji Europejskiej dotyczące oprogramowania open source w ramach CRA stwierdzają, że producent wprowadzający na rynek bezpłatny produkt open source nadal podlega obowiązkom producenta. To, że produkt jest bezpłatny, nie oznacza automatycznie, że jego dostarczanie ma charakter niekomercyjny.
CRA ustanawia także odrębną kategorię opiekunów oprogramowania open source — podmiotów prawnych zapewniających stałe wsparcie dla konkretnego produktu open source przeznaczonego do działalności komercyjnej. Podmioty te nie podlegają administracyjnym karom CRA, ale art. 14 może nadal wymagać zgłaszania, gdy uczestniczą w rozwoju produktu lub gdy poważne incydenty dotyczą systemów deweloperskich, które zapewniają.
Poprawka może nie wyeliminować istniejącego ryzyka dla użytkowników portfeli
W przypadku portfeli kryptowalut zakończenie incydentu technicznego nie musi przypadać na moment udostępnienia aktualizacji bezpieczeństwa. Aktualizacja może zapobiec nowemu narażeniu, a jednocześnie pozostawić klucze, frazy seed lub konfiguracje portfeli utworzone przy użyciu oprogramowania, którego dotyczy problem, zagrożone.
To rozróżnienie było widoczne, gdy Coldcard wydał aktualizację bezpieczeństwa dotyczącą wcześniejszego problemu z generowaniem seedów. Aktualizacja urządzenia nie sprawiła, że wcześniej wygenerowane zagrożone seedy stały się bezpieczne; użytkownicy nadal musieli utworzyć nowe klucze i przenieść środki. Informację Coldcard opisał również Coindoo.
Zgodnie z zasadami zgłaszania określonymi w CRA taka reakcja operacyjna może teraz przebiegać równolegle z obowiązkowym powiadomieniem organów, gdy zostanie stwierdzone aktywne wykorzystanie luki. Producenci portfeli potrzebują więc udokumentowanego procesu ustalania, czy luka jest aktywnie wykorzystywana, powiadamiania organów w ciągu 24 godzin, przygotowywania działań ograniczających skutki oraz ostrzegania użytkowników, podczas gdy dochodzenie w sprawie incydentu i pełny plan naprawczy są nadal opracowywane. Proces ten powinien również łączyć techniczne rejestry incydentów z informacjami o tym, które produkty zostały udostępnione na poszczególnych rynkach UE, ponieważ wstępne ostrzeżenie może wymagać od producentów wskazania tych państw członkowskich.
Pierwotny artykuł „EU Crypto Wallet Makers Now Have 24 Hours to Report Exploits” został opublikowany przez Coindoo.