Cyberbezpieczeństwo dla producentów oprogramowania i wyposażenia morskiego
Statki działają dziś na oprogramowaniu od dziesiątek dostawców, a przepisy klasyfikacyjne i prawo UE oczekują, że każdy dostawca wie, co jest w jego oprogramowaniu, i utrzymuje je w bezpiecznym stanie. CRACI uruchamia Państwa buildy GitHub Actions i rejestruje każdy komponent trafiający do każdego wydania.
Jakie przepisy dotyczą jakich produktów morskich
Dostawca dla branży morskiej podlega trzem reżimom, które się nakładają, ale nie pokrywają: unijnemu prawu produktowemu, przepisom klasyfikacyjnym dla nowych statków i wytycznym IMO dla armatorów. Zanim zaplanują Państwo dowody, warto ustalić, co dotyczy każdego produktu.
CRA wyłącza wyposażenie objęte dyrektywą w sprawie wyposażenia morskiego
Art. 2 ust. 4 Cyber Resilience Act, rozporządzenia (UE) 2024/2847, stanowi: „Niniejszego rozporządzenia nie stosuje się do wyposażenia objętego zakresem stosowania dyrektywy 2014/90/UE.” Ta dyrektywa, dyrektywa w sprawie wyposażenia morskiego (Marine Equipment Directive, MED), obejmuje wyposażenie umieszczone lub przeznaczone do umieszczenia na pokładzie statku UE, dla którego konwencje IMO wymagają zatwierdzenia przez administrację państwa bandery: wyposażenie ze znakiem wheel mark (znak koła sterowego). Przykłady to wyposażenie nawigacyjne, takie jak radar, ECDIS, AIS i rejestratory danych z podróży, wyposażenie radiokomunikacyjne, ochrona przeciwpożarowa i środki ratunkowe. Proszę sprawdzić aktualny wykaz wykonawczy MED dla własnego wyrobu.
Co pozostaje objęte CRA
Produkty z elementami cyfrowymi wprowadzane na rynek UE, które nie są wyposażeniem MED: oprogramowanie pokładowe i lądowe sprzedawane jako produkt, instalowane lub pobierane; systemy do obsługi eksploatacji statku, zakwaterowania, cateringu i części hotelowej; systemy obsługi załogi i pasażerów; oprogramowanie do zarządzania flotą i podróżą; pokładowe czujniki i bramki IoT; urządzenia monitorowania i automatyki, które nie wymagają zatwierdzenia przez państwo bandery. Samo oprogramowanie jako usługa (SaaS) jest poza CRA, chyba że stanowi zdalne przetwarzanie danych produktu, choć do jego dostawcy może nadal mieć zastosowanie NIS2.
Niektóre przypadki wymagają opinii prawnej, a nie reguły: wyposażenie typu oznaczanego znakiem wheel mark sprzedawane na statki niepływające pod banderą UE oraz produkty łączące wyposażenie MED z modułami oprogramowania spoza MED.
IACS UR E26 i E27
Ujednolicone wymagania (unified requirements) International Association of Classification Societies obowiązują przez klasyfikację, a nie przez prawo UE. Rev.1 obu wymagań ma zastosowanie do statków, których umowa na budowę została zawarta 1 lipca 2024 lub później. Są obowiązkowe dla statków pasażerskich i jednostek szybkich w podróżach międzynarodowych, statków towarowych o pojemności 500 GT i większej w podróżach międzynarodowych, ruchomych morskich jednostek wiertniczych i niektórych samobieżnych jednostek offshore, a dla innych statków są wytycznymi. Produkt wyłączony z CRA ze względu na MED może nadal podlegać E26 i E27, i odwrotnie.
IMO
Rezolucja MSC.428(98) wzywa armatorów do uwzględnienia ryzyka cybernetycznego w systemach zarządzania bezpieczeństwem najpóźniej przy pierwszej corocznej weryfikacji Dokumentu zgodności (Document of Compliance) armatora po 1 stycznia 2021. Wytyczne IMO dotyczące zarządzania ryzykiem cybernetycznym w żegludze to niewiążące, ogólne wytyczne dla armatorów. Ich najnowsza rewizja, z maja 2026, stanowi, że zarządzanie ryzykiem cybernetycznym powinno uwzględniać zewnętrznych dostawców, systemy wbudowane oraz łańcuchy dostaw oprogramowania i sprzętu, i wzywa armatorów do ustanowienia zasad bezpieczeństwa łańcucha dostaw oprogramowania i sprzętu dla systemów krytycznych. Dlatego armatorzy przekazują to pytanie dalej swoim dostawcom.
| Przykładowy produkt | Znak wheel mark (MED)? | Cyber Resilience Act | IACS UR E26 i E27 | Co musi wykazać dostawca |
|---|---|---|---|---|
| ECDIS | Tak | Wyłączone (art. 2 ust. 4) | Tak, na nowych statkach objętych wymaganiami | Zatwierdzenie MED; dokumentacja E27 i inwentarz oprogramowania |
| System automatyki siłowni na nowo budowanym statku towarowym | Do sprawdzenia | Tak, chyba że jest wyposażeniem MED | Tak: napęd jest systemem objętym wymaganiami | Dokumentacja E27, inwentarz i cykl bezpiecznego wytwarzania; dokumentacja techniczna i SBOM dla CRA |
| Oprogramowanie do zarządzania częścią hotelową i cateringiem | Nie | Tak, gdy jest sprzedawane jako produkt | Do sprawdzenia: E26 obejmuje jego interfejs sieciowy do systemów objętych wymaganiami | SBOM i obsługa podatności dla CRA |
| Urządzenia sieciowe dla załogi | Nie | Tak | Do sprawdzenia: E26 obejmuje ich interfejs do systemów objętych wymaganiami | SBOM i obsługa podatności dla CRA |
| Oprogramowanie do zarządzania flotą jako usługa | Nie | Poza zakresem, chyba że stanowi zdalne przetwarzanie danych produktu | Nie: działa na lądzie | Odpowiedzi na kwestionariusze armatorów dla dostawców; do dostawcy może mieć zastosowanie NIS2 |
| Pokładowe czujniki monitorowania stanu | Do sprawdzenia | Tak, chyba że są wyposażeniem MED | Do sprawdzenia: objęte, gdy są częścią systemu objętego wymaganiami | SBOM dla CRA; dokumentacja E27, gdy są częścią systemu objętego wymaganiami |
Praktyczna reguła: jeśli produkt potrzebuje znaku wheel mark, CRA go nie dotyczy; jeśli trafia na statek z umową od lipca 2024, prawdopodobnie dotyczy go E27; jeśli sprzedają Państwo w UE oprogramowanie lub produkty połączone z siecią, należy założyć, że dotyczy ich CRA.
Czego E26 i E27 wymagają od dostawców
E27 to wymaganie, które dociera bezpośrednio do dostawców wyposażenia. Sekcja 3.1 wymienia dokumenty, które dostawca przedkłada towarzystwu klasyfikacyjnemu dla systemu komputerowego, między innymi:
- Inwentarz zasobów (3.1.1): komponenty sprzętowe z nazwą, wersją i poziomem poprawek ich oprogramowania systemowego, takiego jak system operacyjny i firmware, oraz komponenty oprogramowania, każdy ze sprzętem, na którym jest zainstalowany, producentem, modelem lub typem, przeznaczeniem i wersją oprogramowania.
- Opis funkcji bezpieczeństwa (3.1.3) wraz z procedurą ich testowania, wytyczne dotyczące konfiguracji bezpieczeństwa oraz plany konserwacji, reagowania na incydenty, odtwarzania i zarządzania zmianą.
- Dokumenty cyklu bezpiecznego wytwarzania (3.1.6), które opisują też, jak obsługiwane są aktualizacje oprogramowania i poprawki.
Sekcja 4 określa wymagane funkcje bezpieczeństwa na podstawie wybranych wymagań systemowych z IEC 62443-3-3, takich jak uwierzytelnianie i ochrona przed złośliwym kodem. Są to funkcje produktu.
Sekcja 5 wymaga cyklu bezpiecznego wytwarzania obejmującego wymagania, projekt, implementację, weryfikację, wydanie, utrzymanie i wycofanie, opisanego w dokumencie, który przegląda towarzystwo klasyfikacyjne. Musi on obejmować kontrole zaczerpnięte z IEC 62443-4-1: ochronę kluczy do podpisywania kodu (SM-8), dokumentowanie aktualizacji bezpieczeństwa dla użytkowników (SUM-2), dokumentowanie aktualizacji bezpieczeństwa komponentów zależnych lub systemu operacyjnego (SUM-3), autentyczne dostarczanie aktualizacji (SUM-4) oraz wytyczne dotyczące obrony w głąb i utwardzania (SG-1 do SG-3).
E26 zamyka pętlę na poziomie statku: inwentarz sprzętu i oprogramowania statku, z polami z inwentarza E27 każdego dostawcy, jest aktualizowany przez cały okres eksploatacji statku, a odnotowuje się w nim zmiany oprogramowania i sprzętu, które mogą wprowadzać nowe podatności.
Czego E27 nie mówi: nie wspomina o SBOM. SBOM dla każdego wydania to najdokładniejszy sposób na uzyskanie wersji oprogramowania do inwentarza i informacji SUM-3 o komponentach zależnych, ale wspiera on te wymagania, a nie jest jednym z nich.
| Wymaganie E26 lub E27 | Czego oczekuje towarzystwo klasyfikacyjne lub stocznia | Dowody z buildu | Co pozostaje po Państwa stronie |
|---|---|---|---|
| Inwentarz zasobów E27 (3.1.1) | Każdy komponent oprogramowania z przeznaczeniem i wersją oraz oprogramowanie systemowe każdego komponentu sprzętowego | SBOM dla każdego wydania, z każdym komponentem i jego wersją | Na którym sprzęcie zainstalowany jest każdy komponent, dane producenta i modelu |
| Dokumentacja aktualizacji SUM-2 i SUM-3 | Udokumentowane aktualizacje bezpieczeństwa, także dla komponentów zależnych i systemów operacyjnych | Rejestry podatności i historia buildów dla komponentów w każdym wydaniu | Informacje o aktualizacjach i biuletyny wysyłane użytkownikom |
| SM-8 i SUM-4 | Chronione klucze do podpisywania kodu i autentyczne dostarczanie aktualizacji | Brak: CRACI nie podpisuje oprogramowania | Państwa proces podpisywania i przechowywanie kluczy |
| Funkcje bezpieczeństwa z sekcji 4 | Uwierzytelnianie, ochrona przed złośliwym kodem i inne funkcje produktu | Brak: to funkcje produktu | Projekt produktu i jego testowanie |
| Dokument cyklu życia z sekcji 5 | Przejrzany opis tego, jak bezpieczeństwo jest obsługiwane w każdej fazie | Zapisy potwierdzające, że faza wydania jest kontrolowana: co zawierał każdy build i do czego mógł sięgnąć | Napisanie dokumentu i prowadzenie procesu |
| Inwentarz zasobów statku E26 | Inwentarz statku aktualizowany przez cały okres jego eksploatacji | Państwa eksporty SBOM przekazane integratorowi | Która wersja jest zainstalowana na którym statku oraz przekazanie stoczni lub integratorowi |
Dlaczego trudno zachować kontrolę nad oprogramowaniem morskim
Statki żyją dłużej niż projekty. Jednostka pływa przez dziesięciolecia, a obowiązek wsparcia oprogramowania na pokładzie trwa dłużej niż projekt, który je dostarczył, zespół, który je zbudował, a często także własna linia produktów dostawcy.
Wielu małych dostawców i integratorów. Na jednym statku jest oprogramowanie od dziesiątek dostawców, złożone przez integratora, a każde przekazanie to okazja do utraty wiedzy o tym, co jest w każdym wydaniu.
Systemów pokładowych nie można aktualizować w dowolnej chwili. Aktualizacje czekają na zawinięcie do portu, zatwierdzenie klasyfikacyjne lub okno serwisowe, więc stare wersje pozostają w użyciu długo po pojawieniu się poprawki. Trzeba wiedzieć, na których statkach nadal działa która wersja.
Odległe lokalizacje, ograniczona łączność. Do statków na morzu i odległych instalacji trudno dotrzeć, więc zapis tego, co zainstalowano, musi istnieć na lądzie, z buildu, a nie ze skanowania statku.
Arkusze kalkulacyjne jako źródło prawdy. Słyszymy od producentów oprogramowania morskiego, że SBOM-y i powiązane zapisy są przechowywane w wielu arkuszach prowadzonych ręcznie. Z każdym wydaniem coraz bardziej się dezaktualizują.
Jak się przygotować, krok po kroku
Funkcje bezpieczeństwa, takie jak uwierzytelnianie, należą do projektu produktu. Poniższe kroki dotyczą dowodów na temat oprogramowania, które do niego trafia.
- Przypisać każdy produkt do jego reżimu. Dla każdego produktu należy ustalić, czy jest wyposażeniem MED, produktem objętym CRA, czy podlega E26 i E27, czy kilku z tych reżimów naraz. Z tej mapy wynika plan dowodów.
- Generować SBOM dla każdego wydania. Należy rejestrować, co trafia do każdego wydania każdego budowanego produktu, łącznie z zależnościami przechodnimi, aby inwentarz oprogramowania pochodził z buildu, a nie z pamięci.
- Prowadzić inwentarz dla każdej instalacji. Trzeba śledzić, która wersja jest zainstalowana na którym statku i kiedy się zmieniła. To zasila inwentarz zasobów E27 i inwentarz statku E26 prowadzony przez integratora, który rejestruje zmiany przez cały okres eksploatacji statku.
- Monitorować podatności i zgłaszać. Dostarczone wydania należy ponownie sprawdzać w miarę publikowania nowych podatności. W przypadku produktów objętych CRA zgłaszanie aktywnie wykorzystywanych podatności i poważnych incydentów obowiązuje od 11 września 2026.
- Nie dopuszczać znanych podatnych pakietów do buildów. Należy blokować build, który dostarczyłby znaną podatność, aby nie wróciła przez aktualizację zależności.
- Dokumentować aktualizacje bezpieczeństwa dla klientów i integratorów. Klientom i integratorom trzeba przekazywać, co naprawia każda aktualizacja bezpieczeństwa, łącznie z poprawkami w komponentach zależnych i systemie operacyjnym, zgodnie z oczekiwaniami SUM-2 i SUM-3.
Gdzie pasuje CRACI
CRACI uruchamia Państwa buildy GitHub Actions na własnych runnerach i rejestruje, co trafia do każdego wydania. Ten zapis to wspólny dowód dla CRA, Państwa dokumentacji E27 i pytań klientów.
Każde wydanie zarejestrowane
Państwa buildy działają na runnerach GitHub Actions CRACI z runs-on: craci, a przebiegi nadal są widoczne w GitHub. Podczas każdego buildu CRACI rejestruje każdy pobrany pakiet, także z npm i PyPI, wraz z ukrytymi zależnościami, których nie wymienia żaden lockfile, i stanem kompletności dla każdego zadania. SBOM-y są eksportowane jako CycloneDX lub SPDX z zależnościami przechodnimi, zadeklarowanymi licencjami i podatnościami znalezionymi w komponentach: to materiał wyjściowy do części inwentarza zasobów E27 dotyczącej oprogramowania. Więcej o SBOM-ach z buildu.
Podatne pakiety pozostają poza buildem
Bramki polityk mogą blokować build zawierający konkretne CVE, a reguły polityki licencyjnej mogą blokować build ze względu na licencję. Znany problem zostaje wychwycony w CI, zanim wydanie trafi na statek.
Wiedza, których wydań to dotyczy
CRACI stale ponownie ocenia monitorowane SBOM-y, w miarę publikowania nowych podatności, a historia buildów pokazuje, które buildy zawierały podatną zależność, w ramach okresu przechowywania Państwa planu. Widok inwentarza pokazuje, które wersje oprogramowania są wdrożone w których produktach. Zespoły bezpieczeństwa przeprowadzają triaż każdego znaleziska i kierują je do zespołu odpowiedzialnego za poprawkę. W przypadku produktów objętych CRA CRACI przygotowuje treść zgłoszeń wymaganych przez CRA, a osoba w Państwa firmie składa je za pośrednictwem Single Reporting Platform.
Build, z którego nie wyciekną Państwa sekrety
Każde zadanie działa we własnej izolowanej maszynie wirtualnej w ramach polityki ruchu wychodzącego, którą mogą Państwo ustawić na domyślne blokowanie, walidowanej przed startem zadania i blokującej w razie błędu. Przy polityce z domyślnym blokowaniem połączenie z hostem, którego build nie potrzebuje, zostaje zablokowane i wywołuje alert.
Kiedy CRACI nie jest rozwiązaniem
CRACI jest dla zespołów, które budują oprogramowanie. Nie pasuje w tych przypadkach:
- Nie dla armatorów i właścicieli statków, którzy szukają monitorowania sieci pokładowej, wykrywania włamań, zgodności z E26 na poziomie statku lub dokumentacji do swojego systemu zarządzania bezpieczeństwem. CRACI jest dla tych, którzy budują oprogramowanie, a nie dla floty, która z niego korzysta.
- Nie program CRA dla producentów wyposażenia MED: wyposażenie ze znakiem wheel mark jest poza CRA. CRACI może jednak rejestrować stojące za nim buildy oprogramowania na potrzeby E27 i próśb klientów, jeśli działają w GitHub Actions.
- Nie dla dostawców, którzy nie budują w GitHub Actions, potrzebują maszyn buildu z Windows lub macOS albo runnerów we własnym koncie chmurowym. CRACI uruchamia dziś zarządzane runnery Linux na europejskiej infrastrukturze; inne systemy CI, runnery Windows i macOS oraz runnery hostowane przez klienta są w planach rozwoju.
- Nie dla zestawień materiałowych sprzętu. CRACI rejestruje oprogramowanie; nie zarządza zestawieniami BOM sprzętu.
- Nie funkcje bezpieczeństwa E27 ani zatwierdzenie klasyfikacyjne. CRACI nie implementuje uwierzytelniania, ochrony przed złośliwym oprogramowaniem ani innych funkcji produktu, nie podpisuje oprogramowania, nie pisze dokumentu cyklu bezpiecznego wytwarzania i nie kontaktuje się w Państwa imieniu z towarzystwem klasyfikacyjnym.
- Nie narzędzie do metryk usuwania podatności: CRACI nie raportuje średniego czasu usunięcia podatności ani terminów jej usunięcia.
Cyberbezpieczeństwo morskie w pytaniach i odpowiedziach
Częste pytania o CRA, IACS UR E26 i E27 oraz wytyczne IMO dla dostawców z branży morskiej
Czy Cyber Resilience Act dotyczy wyposażenia morskiego?
Nie dotyczy wyposażenia objętego dyrektywą w sprawie wyposażenia morskiego, 2014/90/UE. Art. 2 ust. 4 CRA wprost je wyłącza. Obejmuje to wyposażenie ze znakiem wheel mark, które wymaga zatwierdzenia przez państwo bandery na podstawie konwencji IMO. Inne połączone produkty i oprogramowanie sprzedawane na statki, takie jak systemy hotelowe, sieci dla załogi, czujniki i oprogramowanie flotowe instalowane na pokładzie, mogą nadal podlegać CRA.
Które produkty morskie są wyłączone z CRA?
Wyposażenie objęte dyrektywą w sprawie wyposażenia morskiego: wyposażenie umieszczane na statkach UE, dla którego konwencje IMO wymagają zatwierdzenia przez państwo bandery, takie jak radar, ECDIS, AIS, rejestratory danych z podróży, radiokomunikacja, ochrona przeciwpożarowa i środki ratunkowe. Proszę sprawdzić aktualny wykaz wykonawczy MED dla swojego wyrobu i uzyskać opinię prawną w przypadku produktów mieszanych lub statków pod innymi banderami.
Czym jest IACS UR E27 i kto musi je spełniać?
UR E27 to ujednolicone wymaganie International Association of Classification Societies dotyczące cyberodporności systemów i wyposażenia pokładowego. Rev.1 ma zastosowanie do statków, których umowa na budowę została zawarta 1 lipca 2024 lub później, i jest obowiązkowe dla statków pasażerskich, jednostek szybkich i statków towarowych o pojemności 500 GT i większej w podróżach międzynarodowych oraz niektórych jednostek offshore. Dostawcy systemów objętych wymaganiami spełniają je przez towarzystwo klasyfikacyjne.
Czego E26 i E27 wymagają od dostawców wyposażenia?
E27 wymaga od dostawców dokumentacji obejmującej m.in. inwentarz zasobów wymieniający każdy komponent oprogramowania z wersją, funkcje bezpieczeństwa zaczerpnięte z IEC 62443-3-3 oraz cykl bezpiecznego wytwarzania z kontrolami z IEC 62443-4-1, takimi jak dokumentowanie aktualizacji bezpieczeństwa. E26 to wymaganie na poziomie statku: inwentarz zasobów statku korzysta z tych samych pól i jest aktualizowany przez cały okres eksploatacji statku.
Czy UR E27 wymaga SBOM?
Nie. E27 nie wspomina o SBOM. Wymaga inwentarza zasobów wymieniającego każdy komponent oprogramowania z wersją oraz dokumentowania aktualizacji bezpieczeństwa komponentów zależnych i systemu operacyjnego. SBOM dla każdego wydania to najdokładniejszy sposób uzyskania tych informacji, ale nie jest wymogiem E27.
Czy wytyczne IMO dotyczące zarządzania ryzykiem cybernetycznym są obowiązkowe?
Nie. Wytyczne IMO dotyczące zarządzania ryzykiem cybernetycznym w żegludze to niewiążące wytyczne dla armatorów, zrewidowane w maju 2026. Oczekiwania wobec armatorów wynikają z rezolucji MSC.428(98), która wzywa ich do uwzględnienia ryzyka cybernetycznego w systemach zarządzania bezpieczeństwem, a wytyczne wzywają teraz armatorów do ustanowienia zasad bezpieczeństwa łańcucha dostaw oprogramowania i sprzętu.
Czy CRA dotyczy oprogramowania sprzedawanego armatorom?
Zwykle tak, jeśli jest sprzedawane na rynku UE jako produkt z elementami cyfrowymi, instalowane lub pobierane, i nie jest wyposażeniem MED. Oprogramowanie oferowane wyłącznie jako usługa jest poza CRA, chyba że stanowi zdalne przetwarzanie danych produktu, choć do jego dostawcy może mieć zastosowanie NIS2. Proszę sprawdzić klasyfikację każdego produktu.
Co trafia do Państwa wydań
Proszę umówić demo, a pokażemy każdy komponent pobierany przez Państwa buildy i których wydań dotyczy nowa podatność.
Umów demo