Należyta staranność dostawców CRA: kwestionariusz i alerty

Należyta staranność wobec komponentów jest obowiązkiem producenta na podstawie art. 13 ust. 5 aktu o cyberodporności. Pełny tekst urzędowy:

„W celu wypełnienia obowiązku określonego w ust. 1 producenci dokładają należytej staranności przy integrowaniu z produktami z elementami cyfrowymi komponentów pochodzących od stron trzecich, aby komponenty takie nie naruszały cyberbezpieczeństwa produktu z elementami cyfrowymi, w tym w przypadku zintegrowania komponentów wolnego i otwartego oprogramowania, które nie zostały udostępnione na rynku w ramach działalności komercyjnej."

Ta strona jest operacyjnym uzupełnieniem zestawu obowiązków producenta. Ramy regulacyjne, granice ról i kontrole po stronie importera opisują przewodniki klastrowe: producent, importer, dystrybutor oraz kogo dotyczy CRA. Poniżej znajduje się kwestionariusz, scenariusze dla typów dostawców, których nie obejmują strony klastra (FOSS, chmura, sprzęt bez oprogramowania, opiekunowie OSS, zmodyfikowane firmware COTS), a także sytuacje operacyjne, które uderzają w zespoły zakupowe w praktyce (brak odpowiedzi dostawcy, wspólny komponent upstream, zaległości po fuzjach i przejęciach, widoczność wielowarstwowa).

Dlaczego należyta staranność wobec dostawców ma znaczenie

Nawet jako producent własnego produktu, dostarczasz wyrób zawierający komponenty od dostawców: biblioteki oprogramowania, komponenty sprzętowe, moduły firmware, usługi chmurowe. Podatności w tych komponentach stają się twoimi podatnościami, a ocena zgodności musi uwzględniać ryzyko łańcucha dostaw.

Art. 13 ust. 5 czyni tę ocenę wyraźnym obowiązkiem. Rozporządzenie nie narzuca formatu kwestionariusza, ale spisany kwestionariusz jest praktycznym sposobem udokumentowania, że przed integracją sprawdzono bezpieczeństwo komponentu, obsługę podatności, dostępność SBOM, zobowiązania wsparcia i ścieżki kontaktu z dostawcą. Bez datowanych zapisów nie masz czym odpowiedzieć organowi nadzoru rynku, który zapyta, jak zarządzono ryzykiem na poziomie komponentu.

Jeżeli na danym produkcie pełnisz również rolę importera (wprowadzasz na rynek UE produkt producenta spoza UE), cztery kontrole przedrynkowe importera są odrębnym obowiązkiem weryfikacji. Niniejszy przewodnik skupia się na należytej staranności wobec komponentów po stronie producenta.

Ramy należytej staranności

Podejście warstwowe

Nie wszyscy dostawcy wymagają tego samego poziomu kontroli:

OCENA WARSTW DOSTAWCÓW

WARSTWA 1 (Krytyczna):
- Komponenty z funkcjami bezpieczeństwa (krypto, uwierzytelnianie, zapory)
- Podstawowe zależności oprogramowania
- Sprzęt z firmware
Ocena: Pełny kwestionariusz + przegląd dokumentacji + ciągłe monitorowanie

WARSTWA 2 (Znacząca):
- Komponenty głównej funkcjonalności
- Elementy podłączone do sieci
- Komponenty przetwarzające dane
Ocena: Standardowy kwestionariusz + przegląd dokumentacji

WARSTWA 3 (Standardowa):
- Komponenty niezwiązane z bezpieczeństwem
- Biblioteki narzędziowe
- Sprzęt peryferyjny
Ocena: Podstawowy kwestionariusz + kontrole wyrywkowe

WARSTWA 4 (Minimalna):
- Komponenty towarowe
- Ugruntowane projekty OSS
- Sprzęt bez łączności
Ocena: Podstawowa weryfikacja + włączenie do SBOM

Obszary oceny

Należyta staranność powinna obejmować:

Ramy są generyczne, ale dowody, które każdy typ dostawcy faktycznie potrafi przedstawić, różnią się. Kolejnych pięć sekcji omawia najczęstsze profile dostawców i ścieżkę należytej staranności pasującą do każdego z nich.

Należyta staranność wobec dostawców FOSS

Art. 13 ust. 5 wymienia komponenty FOSS wprost: komponenty wolnego i otwartego oprogramowania, które nie zostały udostępnione na rynku w ramach działalności komercyjnej. Obowiązek prawny obowiązuje niezależnie od tego, czy zmieniają się pieniądze. Kwestionariusz podpisany krwią przez komercyjnego dostawcę nie jest właściwym modelem, gdy upstream to projekt na GitHubie utrzymywany przez trzech opiekunów.

Dla niekomercyjnych komponentów FOSS zestaw dowodów przesuwa się z dokumentów poświadczonych przez dostawcę na sygnały obserwowalne w projekcie, które możesz zebrać samodzielnie.

LISTA KONTROLNA NALEŻYTEJ STARANNOŚCI DLA KOMPONENTÓW FOSS

KONDYCJA PROJEKTU:
[ ] Aktywne commity w ostatnich 90 dniach
[ ] Liczba odrębnych kontrybutorów (>1 = ulga w bus-factorze)
[ ] Kadencja wydań zadeklarowana lub obserwowalna
[ ] System zgłoszeń reaguje (mediana czasu do komentarza)

POSTAWA BEZPIECZEŃSTWA:
[ ] SECURITY.md obecny z adresem ujawniania
[ ] Polityka CVD (prywatny kanał security advisory, nie tylko zgłoszenie)
[ ] Historia CVE przejrzana (NVD, GitHub Security Advisories, OSV)
[ ] Składniki SBOM są same w sobie rozpoznawalne, nie głębokie forki

LICENCJA I POCHODZENIE:
[ ] Identyfikator SPDX zgadza się z deklaracją w metadanych paczki
[ ] Brak zależności tranzytywnej niezgodnej licencyjnie
[ ] Wydane artefakty mają weryfikowalne pochodzenie (np. SLSA, sigstore)

TWÓJ PLAN AWARYJNY:
[ ] Wskazany cel forka, jeśli upstream zamilknie
[ ] Zadeklarowane zdolności łatania wewnątrz firmy (który inżynier, jaki kod)
[ ] Wymienione kandydaci na zamiennik, oszacowany koszt podmiany

Dwie zasady operacyjne. Po pierwsze, art. 13 ust. 6 wymaga, aby podatności wykryte w komponencie FOSS były zgłaszane projektowi upstream i aby każda wypracowana łatka była dzielona z powrotem, w stosownych przypadkach w formacie nadającym się do odczytu maszynowego. Pozycja kwestionariusza, którą sprawdzasz, to nie zobowiązanie upstreamu wobec ciebie, lecz twoje własne zobowiązanie do przepływu podatności i łatek z powrotem. Po drugie, cichy upstream nie wygasza twojego obowiązku. Jeżeli projekt staje się nieaktywny, twój plan awaryjny (fork, łatanie wewnątrz firmy, zamiennik) jest częścią rejestru należytej staranności, nie problemem na przyszłość.

Dla projektów utrzymywanych przez fundację lub podmiot prawny działający jako opiekun otwartego oprogramowania, wzorzec należytej staranności znów się zmienia. Ten przypadek opisuje kolejna sekcja.

Opiekun OSS a komercyjny dostawca

Niewielka, ale ważna klasa upstreamów jest prowadzona przez opiekuna otwartego oprogramowania: podmiot prawny, zazwyczaj fundację, której zasadniczym celem jest utrzymywanie konkretnych projektów otwartego oprogramowania przeznaczonych do zastosowań komercyjnych. Linux Foundation, Eclipse Foundation i Apache Software Foundation są typowymi przykładami. Opiekunowie podlegają art. 24, nie art. 13. Zestaw obowiązków jest węższy (udokumentowana polityka cyberbezpieczeństwa, obowiązek współpracy z organem nadzoru rynku, częściowe stosowanie zgłaszania incydentów z art. 14), a opiekun nie jest producentem żadnego komercyjnego produktu w dół łańcucha.

Granicę producent-opiekun omawia sekcja opiekunowie otwartego oprogramowania.

Konsekwencja dla ciebie jako integratora w dół łańcucha jest taka, że kształt kwestionariusza staje się inny.

Co dalej robisz: kontrole kondycji projektu, ingest SBOM, monitorowanie CVE, własny plan awaryjny z forkiem i łataniem. Czego przestajesz oczekiwać: umownych SLA na powiadomienia o podatnościach, płatnych warstw wsparcia, klauzul audytowych. Rejestr należytej staranności dla komponentu utrzymywanego przez opiekuna jest cieńszy po stronie papieru od dostawcy i grubszy po stronie twoich własnych kontroli niż dla komercyjnego dostawcy. To kształt prawnie poprawny.

Należyta staranność wobec komponentu usług chmurowych

Kiedy „komponentem" wewnątrz produktu jest API lub usługa zarządzana (uwierzytelnianie SaaS, zarządzany broker komunikatów, funkcja serverless, baza chmurowa), wzorzec dowodowy znów wygląda inaczej. Nie ma DoC, nie ma SBOM, nie ma kodu źródłowego, który dostarczasz. Jest umowa, portfel atestacji bezpieczeństwa i model współdzielonej odpowiedzialności.

NALEŻYTA STARANNOŚĆ WOBEC KOMPONENTU USŁUGI CHMUROWEJ

ATESTACJE BEZPIECZEŃSTWA:
[ ] Raport SOC 2 Type II (aktualny)
[ ] Certyfikat ISO/IEC 27001 (aktualny, weryfikacja zakresu)
[ ] ISO/IEC 27017 (kontrole specyficzne dla chmury) gdy adekwatne
[ ] ISO/IEC 27018 (dane osobowe w chmurze publicznej) gdy w zakresie

DOWODY OPERACYJNE:
[ ] Strona statusu z historią incydentów i analizami post-mortem
[ ] Opublikowane RTO/RPO oraz data ostatniego testu DR
[ ] Lista subprocesorów i proces powiadamiania o zmianach
[ ] Umowa o przetwarzaniu danych z lokalizacją w UE, gdy adekwatna

WSPÓŁDZIELONA ODPOWIEDZIALNOŚĆ:
[ ] Udokumentowany zakres odpowiedzialności dostawcy
[ ] Potwierdzony zakres twojej odpowiedzialności (konfiguracja, tożsamość,
    sekrety, sieć)
[ ] Dostęp do logów i ścieżki audytu w zakresie twojej odpowiedzialności

OKOLICE CRA:
[ ] Ścieżka ujawniania podatności samego API
[ ] Zegar powiadomień o naruszeniu w umowie (godziny, nie „niezwłocznie")
[ ] Okno wypowiedzenia usługi (zazwyczaj 12 miesięcy)

Rozporządzenie nie reguluje wprost dostawcy chmury, jeżeli ten nie wprowadza do obrotu produktu z elementami cyfrowymi. Twój obowiązek z art. 13 ust. 5 polega na udowodnieniu, że zależność chmurowa nie narusza cyberbezpieczeństwa twojego produktu. Dostarczalnym artefaktem jest portfel atestacji wraz z pisemnym oświadczeniem o współdzielonej odpowiedzialności, nie kwestionariusz w kształcie CRA.

Należyta staranność wobec dostawcy sprzętu i ODM

Kiedy producent kontraktowy (ODM, EMS, montażysta typu OEM) wysyła płytki fizyczne, a firmware jest twój, dostawca dostarcza podłoże sprzętowe, ale nie kopertę bezpieczeństwa. Rozporządzenie umieszcza kopertę bezpieczeństwa po twojej stronie: jednostce, która programuje i podpisuje firmware trafiające na płytkę.

Kwestionariusz w tym przypadku jest cieńszy po stronie pytań o oprogramowanie, a grubszy po stronie zaufania sprzętowego i integralności łańcucha dostaw.

NALEŻYTA STARANNOŚĆ DLA SPRZĘTU / ODM

ZAUFANIE SPRZĘTOWE:
[ ] BOM z identyfikacją komponentów klasy kryptograficznej
[ ] Kontrole przeciw podrobionym komponentom (audyt źródeł komponentów)
[ ] Źródło bezpiecznego elementu i metoda preprovisioningu
[ ] Proces wstrzykiwania kluczy fabrycznych i ślad audytowy

INTEGRALNOŚĆ MONTAŻU:
[ ] Wdrożony system jakości ISO 9001
[ ] Plomby zabezpieczające stosowane podczas montażu i wysyłki
[ ] Identyfikowalność partii i numerów seryjnych od fabryki do magazynu

PRZEKAZANIE FIRMWARE:
[ ] Kto podpisuje firmware: ty, ODM, czy oboje
[ ] Stan provisioningu przy pierwszym uruchomieniu (ustawienia
    fabryczne, przeniesienie własności)
[ ] Bootloader i łańcuch secure boot, kto odpowiada za każde ogniwo

PO WYSYŁCE:
[ ] Okno wypowiedzenia EOL dla platformy sprzętowej
[ ] Zobowiązanie last-time-buy i jego długość
[ ] Dostępność części zamiennych przez deklarowany okres wsparcia

Częsty błąd operacyjny: podpisanie wieloletniego okresu wsparcia z ODM, którego okno EOL dla sprzętu wynosi 18 miesięcy. Zegar okresu wsparcia CRA startuje w chwili wprowadzenia produktu na rynek UE; jeżeli leżący niżej krzem trafi na EOL wewnątrz tego okna, obowiązek wsparcia nie przechodzi na tolerancję twojego klienta.

Firmware COTS, które modyfikujesz

Jeżeli bierzesz produkt komercyjny dostępny z półki, modyfikujesz firmware i wprowadzasz wynik na rynek UE, art. 22 traktuje cię jako producenta zmodyfikowanego produktu w odniesieniu do części objętej istotną modyfikacją lub w odniesieniu do całego produktu, jeżeli modyfikacja dotyka koperty cyberbezpieczeństwa.

„Osoba fizyczna lub prawna – inna niż producent, importer lub dystrybutor – która dokonuje istotnej modyfikacji produktu z elementami cyfrowymi i udostępnia ten produkt na rynku, uważana jest za producenta do celów niniejszego rozporządzenia."

Konsekwencja dla należytej staranności jest poważna: pierwotna deklaracja zgodności i ocena zgodności producenta przestają obejmować produkt w postaci, w jakiej wprowadzasz go na rynek. Dziedziczysz zestaw obowiązków producenta dla części objętej modyfikacją lub dla całości. Pierwotny dostawca staje się nieistotny dla teczki CRA; twój własny zespół inżynierski staje się stroną odpowiadającą.

Krok należytej staranności to tu zatem nie kwestionariusz do pierwotnego dostawcy. To wewnętrzna ocena wpływu modyfikacji. Udokumentuj zakres modyfikacji, zdecyduj, czy jest istotna, i potraktuj całość jako pracę w zakresie producenta, jeżeli modyfikacja dotyka uwierzytelniania, szyfrowania, powierzchni sieciowej albo mechanizmu aktualizacji. Czysty zapis tego, która modyfikacja została zastosowana do której partii urządzeń, to artefakt, o który organ nadzoru rynku zapyta najpierw.

Kwestionariusz

Użyj tego kwestionariusza jako punktu wyjścia dla komercyjnych dostawców oprogramowania i sprzętu. Wcześniejsze sekcje opisują warianty dla FOSS, opiekunów OSS, API chmurowych, sprzętu od ODM i zmodyfikowanego firmware COTS.

Sekcja 1: Informacje o firmie

KWESTIONARIUSZ NALEŻYTEJ STARANNOŚCI WOBEC DOSTAWCY
Sekcja 1: Informacje o firmie

1.1 Dane firmy
    Nazwa firmy: _________________________________
    Adres prawny: ________________________________
    Kraj rejestracji: ____________________________
    Kontakt główny: ______________________________
    Kontakt bezpieczeństwa: ______________________

1.2 Informacje biznesowe
    Lata działalności: ___________________________
    Liczba pracowników: __________________________
    Roczny przychód (przedział): _________________

1.3 Reprezentacja w UE (jeśli spoza UE)
    Upoważniony przedstawiciel UE, nazwa + adres: _
    (Pełny opis kaskady AR i routingu importera,
    gdy brak siedziby w UE, znajduje się w przewodniku
    klastra importera:
    /cra-compliance/importer#if-the-non-eu-manufacturer-has-no-eu-establishment)

1.4 Certyfikaty (dołącz kopie)
    [ ] ISO 9001 (zarządzanie jakością)
    [ ] ISO 27001 (bezpieczeństwo informacji)
    [ ] ISO 27701 (prywatność)
    [ ] SOC 2
    [ ] Inne: __________________________________

Sekcja 2: Zgodność produktu

Sekcja 2: Zgodność produktu

2.1 Identyfikacja produktu
    Nazwa/model produktu: ________________________
    Wersja/rewizja: ______________________________
    Kategoria produktu: __________________________

2.2 Klasyfikacja CRA
    [ ] Domyślna
    [ ] Ważna klasa I (Załącznik III, część I)
    [ ] Ważna klasa II (Załącznik III, część II)
    [ ] Krytyczna (Załącznik IV)
    [ ] Jeszcze niesklasyfikowany

2.3 Ocena zgodności
    [ ] Moduł A (samoocena)
    [ ] Moduł B+C (badanie typu UE)
    [ ] Moduł H (pełne zapewnienie jakości)
    [ ] Jeszcze nieukończona

    Jeśli moduł B, C lub H:
    Nazwa jednostki notyfikowanej: _______________
    Numer certyfikatu: ___________________________
    Data certyfikatu: ____________________________

2.4 Deklaracja zgodności UE
    [ ] DoC dostępna (dołącz kopię)
    [ ] DoC jeszcze niewydana
    Data DoC: ____________________________________

2.5 Oznakowanie CE
    [ ] Oznakowanie CE naniesione
    [ ] Oznakowanie CE jeszcze nienaniesione
    Jeśli naniesione, miejsce na produkcie: ______

2.6 Dokumentacja techniczna
    [ ] Dokumentacja techniczna dostępna na żądanie
    [ ] SBOM dostępny (format: __________________)
    [ ] Dokumentacja oceny ryzyka dostępna
    [ ] Instrukcje użytkownika/bezpieczeństwa dostępne

Sekcja 3: Praktyki bezpieczeństwa

Sekcja 3: Praktyki bezpieczeństwa

3.1 Bezpieczny cykl wytwarzania
    Czy stosujecie bezpieczny cykl wytwarzania?
    [ ] Tak, opisz: ______________________________
    [ ] Nie

    Czy przeprowadzacie testy bezpieczeństwa?
    [ ] Analiza statyczna (SAST)
    [ ] Analiza dynamiczna (DAST)
    [ ] Testy penetracyjne
    [ ] Testy fuzz
    [ ] Inne: __________________________________

    Czy istnieje standard bezpiecznego kodowania?
    [ ] Tak, jaki: _______________________________
    [ ] Nie

3.2 Zarządzanie komponentami
    Jak śledzicie komponenty stron trzecich?
    [ ] Utrzymywany SBOM
    [ ] Narzędzie śledzenia zależności (nazwa: __)
    [ ] Śledzenie ręczne
    [ ] Brak systematycznego śledzenia

    Jak monitorujecie podatności w zależnościach?
    [ ] Automatyczne skanowanie (narzędzie: ____)
    [ ] Ręczne monitorowanie CVE
    [ ] Poleganie na powiadomieniach dostawcy
    [ ] Brak systematycznego monitorowania

3.3 Architektura bezpieczeństwa
    Opisz kluczowe funkcje bezpieczeństwa produktu:
    _____________________________________________

    Jakie standardy kryptograficzne są stosowane?
    _____________________________________________

    Jak zaimplementowano uwierzytelnianie?
    _____________________________________________

    Jak chronione są dane w spoczynku i w transmisji?
    _____________________________________________

Sekcja 4: Zarządzanie podatnościami

Sekcja 4: Zarządzanie podatnościami

4.1 Ujawnianie podatności
    Czy istnieje polityka skoordynowanego ujawniania
    podatności (CVD)?
    [ ] Tak, URL: ________________________________
    [ ] Nie

    Czy istnieje plik security.txt?
    [ ] Tak, URL: ________________________________
    [ ] Nie

    Jaka jest metoda kontaktu bezpieczeństwa?
    [ ] E-mail: __________________________________
    [ ] Formularz web: ___________________________
    [ ] Platforma bug bounty: ____________________
    [ ] Inne: __________________________________

4.2 Zobowiązania czasowe
    Czas potwierdzenia przyjęcia zgłoszenia?
    [ ] W ciągu 24 godzin
    [ ] W ciągu 72 godzin
    [ ] W ciągu 7 dni
    [ ] Brak zobowiązania

    Typowy czas wydania łatki dla:
    Podatności krytycznych: ______________________
    Podatności wysokich: _________________________
    Podatności średnich: _________________________

4.3 Zgłaszanie do ENISA
    Czy jesteście przygotowani na zgłaszanie do
    ENISA (wrzesień 2026 r.)?
    [ ] Tak, proces ustanowiony
    [ ] W trakcie
    [ ] Nie
    [ ] Nie dotyczy (nie producent)

4.4 Historyczne podatności
    Ile podatności bezpieczeństwa zgłoszono
    w tym produkcie w ciągu ostatnich 24 miesięcy? __

    Jak zostały rozwiązane?
    [ ] Wszystkie załatane w zadeklarowanych terminach
    [ ] Pewne opóźnienia (wyjaśnij): ______________
    [ ] Niektóre pozostają niezałatane (wyjaśnij): _

Sekcja 5: Aktualizacje i wsparcie

Sekcja 5: Aktualizacje i wsparcie

5.1 Okres wsparcia
    Zadeklarowany okres wsparcia od chwili wprowadzenia
    na rynek?
    [ ] 5 lat (minimum CRA)
    [ ] 7 lat
    [ ] 10 lat
    [ ] Inny: __________________________________
    [ ] Nieokreślony

    Kiedy produkt został po raz pierwszy wprowadzony
    na rynek UE?
    Data: ______________________________________

    Kiedy kończy się okres wsparcia?
    Data: ______________________________________

5.2 Mechanizm aktualizacji
    Jak dostarczane są aktualizacje bezpieczeństwa?
    [ ] Automatyczne aktualizacje (OTA)
    [ ] Ręczne pobieranie z portalu
    [ ] Nośnik fizyczny
    [ ] Inne: __________________________________

    Czy aktualizacje bezpieczeństwa są oddzielne od
    aktualizacji funkcjonalnych?
    [ ] Tak
    [ ] Nie, łączone razem

    Czy użytkownicy mogą odraczać lub pomijać aktualizacje?
    [ ] Tak
    [ ] Nie, obowiązkowe
    [ ] Konfigurowalne

5.3 Weryfikacja aktualizacji
    Czy aktualizacje są podpisane?
    [ ] Tak, metoda: ____________________________
    [ ] Nie

    Czy użytkownicy mogą zweryfikować autentyczność
    aktualizacji?
    [ ] Tak, w jaki sposób: _____________________
    [ ] Nie

5.4 Planowanie końca wsparcia
    Czy istnieje udokumentowany proces EOL?
    [ ] Tak
    [ ] Nie

    W jaki sposób klienci będą powiadamiani o EOL?
    _____________________________________________

    Co dzieje się po zakończeniu okresu wsparcia?
    [ ] Produkt nadal funkcjonuje
    [ ] Produkt traci funkcjonalność
    [ ] Produkt wymaga migracji

Sekcja 6: Wymagania dokumentacyjne

Sekcja 6: Wymagania dokumentacyjne

6.1 Dostępna dokumentacja
    Zaznacz całą dokumentację, którą możesz dostarczyć:

    [ ] Deklaracja zgodności UE
    [ ] Dokumentacja techniczna (lub odpowiednie wyciągi)
    [ ] Software Bill of Materials (SBOM)
        Format: [ ] CycloneDX [ ] SPDX [ ] Inny
    [ ] Podsumowanie oceny ryzyka
    [ ] Dokument architektury bezpieczeństwa
    [ ] Instrukcje użytkownika (związane z bezpieczeństwem)
    [ ] Polityka ujawniania podatności
    [ ] Warunki wsparcia i utrzymania

6.2 Dostarczanie dokumentacji
    W jaki sposób dokumentacja będzie dostarczana?
    [ ] Na żądanie (czas odpowiedzi: ____________)
    [ ] Przez bezpieczny portal
    [ ] Dołączona do produktu
    [ ] Inne: __________________________________

6.3 Szczegóły SBOM (jeśli dostępny)
    SBOM obejmuje:
    [ ] Tylko bezpośrednie zależności
    [ ] Włączone zależności tranzytywne
    [ ] Komponenty sprzętowe (jeśli dotyczy)

    Częstotliwość aktualizacji SBOM:
    [ ] Przy każdym wydaniu
    [ ] Na żądanie
    [ ] Nieaktualizowany systematycznie

Sekcja 7: Zobowiązania umowne

Sekcja 7: Zobowiązania umowne

7.1 Gwarancja zgodności
    Czy zagwarantujecie zgodność z CRA w umowie?
    [ ] Tak
    [ ] Nie
    [ ] Do negocjacji

7.2 Przechowywanie dokumentacji
    Czy będziecie przechowywać dokumentację techniczną
    przez 10 lat?
    [ ] Tak
    [ ] Nie
    [ ] Krótszy okres: __________________________

7.3 Obowiązki powiadamiania
    Czy powiadomicie nas o:
    [ ] Podatnościach bezpieczeństwa w produkcie
    [ ] Zmianach statusu zgodności
    [ ] Decyzjach o zakończeniu wsparcia
    [ ] Istotnych zmianach w architekturze bezpieczeństwa

7.4 Prawa audytu
    Czy umożliwicie audyty zgodności?
    [ ] Tak, bez ograniczeń
    [ ] Tak, z wyprzedzeniem
    [ ] Nie

7.5 Rekompensata
    Czy zapewnicie rekompensatę za niezgodność z CRA?
    [ ] Tak
    [ ] Nie
    [ ] Do negocjacji

Sekcja 8: Oświadczenie

Sekcja 8: Oświadczenie

Oświadczam, że informacje podane w niniejszym kwestionariuszu
są zgodne ze stanem mojej wiedzy dokładne i kompletne.

Rozumiem, że [Twoja Firma] polega na tych informacjach
dla celów zgodności z CRA i że istotne wprowadzenie w błąd
może skutkować rozwiązaniem umowy.

Wypełnił(a): _____________________________________
Stanowisko: ______________________________________
Data: ____________________________________________
Podpis: __________________________________________

Sygnały ostrzegawcze (przed zawarciem umowy)

Te sygnały ostrzegawcze należy wychwytywać w trakcie przeglądu kwestionariusza i negocjacji umowy, zanim zostanie podpisane jakiekolwiek zamówienie. Lustrzane sygnały po stronie importera, stosowane w momencie wprowadzania na rynek UE produktu producenta spoza UE, opisuje sekcja co odrzucić i dlaczego na stronie klastra importera.

Krytyczne sygnały ostrzegawcze (dyskwalifikują relację)

Poważne sygnały ostrzegawcze (wymagają wynegocjowanej mitygacji)

Żółte flagi (monitoruj w trakcie relacji)

Proces weryfikacji i monitorowania

Wstępna weryfikacja

1. Zbieranie dokumentów

   • Poproś o kopię DoC
   • Poproś o SBOM (lub potwierdzenie dostępności)
   • Poproś o dane kontaktowe bezpieczeństwa
   • Poproś o zobowiązanie dotyczące okresu wsparcia

2. Przegląd dokumentów

   • Zweryfikuj, że DoC jest podpisana i kompletna
   • Sprawdź, czy identyfikacja produktu się zgadza
   • Zweryfikuj deklaracje dotyczące oznakowania CE
   • Przejrzyj format i kompletność SBOM

3. Wyrywkowe kontrole zgodności

   • Sprawdź, czy istnieje security.txt (jeśli dostępny przez web)
   • Sprawdź, czy polityka CVD jest opublikowana
   • Przetestuj, czy kontakt bezpieczeństwa odpowiada
   • Zweryfikuj deklaracje okresu wsparcia w dokumentacji

Ciągłe monitorowanie

HARMONOGRAM MONITOROWANIA DOSTAWCÓW

Miesięcznie:
[ ] Sprawdź opublikowane biuletyny bezpieczeństwa
[ ] Zweryfikuj, że kontakt bezpieczeństwa nadal działa
[ ] Przejrzyj wszelkie ujawnienia podatności

Kwartalnie:
[ ] Poproś o zaktualizowany SBOM (przy znaczących wydaniach)
[ ] Zweryfikuj, że polityka CVD jest nadal dostępna
[ ] Sprawdź nowe certyfikaty i ich wygaśnięcia

Rocznie:
[ ] Pełne odświeżenie kwestionariusza
[ ] Przegląd statusu okresu wsparcia
[ ] Zweryfikuj, że dokumentacja jest nadal dostępna
[ ] Przegląd stabilności biznesowej

Wyzwalane zdarzeniem:
[ ] Poważny incydent bezpieczeństwa → natychmiastowy przegląd
[ ] Zmiana właściciela → pełna ponowna ocena
[ ] Wycofanie produktu → planowanie EOL
[ ] Odnowienie umowy → ponowna weryfikacja zgodności

Gdy dostawca nie odpowiada

Najczęstszą operacyjną porażką w należytej staranności wobec dostawców nie jest nieudana odpowiedź na kwestionariusz, lecz brak jakiejkolwiek odpowiedzi. Dostawca znika z radaru, przeciąga sprawę miesiącami albo odsyła jednowierszową odpowiedź „spełniamy wszystkie obowiązujące regulacje". Nie istnieje sankcja ustawowa wobec dostawcy (nie ciąży na nim obowiązek CRA odpowiadania na twój kwestionariusz), więc ścieżka eskalacji musi być komercyjna i proceduralna.

ESKALACJA BRAKU ODPOWIEDZI DOSTAWCY

TYDZIEŃ 1: Wysłany kwestionariusz wstępny.
           Rozsądne okno odpowiedzi: 15 dni roboczych dla Warstwy 1,
           30 dni roboczych dla Warstwy 2, 45 dla Warstwy 3-4.

TYDZIEŃ 3: Pierwsze przypomnienie do wskazanego kontaktu bezpieczeństwa
           i głównego kontaktu komercyjnego. DW na lidera zakupów.

TYDZIEŃ 5: Eskalacja do account executive dostawcy oraz do
           dyrektora zakupów po stronie własnej. Wyznacz twardy termin.

TYDZIEŃ 7: Jeżeli nadal brak merytorycznej odpowiedzi:
           a) Udokumentuj brak odpowiedzi w teczce dostawcy
           b) Oznacz komponent jako „zgodność niezweryfikowana"
           c) Uruchom ocenę dostawcy zastępczego
           d) Powiadom właścicieli produktów zależnych od komponentu

TYDZIEŃ 9: Brama decyzyjna.
           Otrzymano merytoryczną odpowiedź → przejdź do przeglądu.
           Brak odpowiedzi → przełącz na dostawcę zastępczego
           i udokumentuj przełączenie jako decyzję wymuszoną przez CRA.

Brak odpowiedzi sam w sobie jest dowodem należytej staranności. Organ nadzoru rynku pytający, dlaczego zerwano współpracę z dostawcą, znacznie chętniej zaakceptuje udokumentowaną ścieżkę eskalacji i decyzję o zmianie niż mgliste „trudno się z nimi pracowało". Artefakt, który zachowujesz, to datowany dziennik eskalacji wraz z notatką decyzyjną.

Wspólny komponent upstream i skoordynowana weryfikacja

Kiedy wielu producentów integruje ten sam komponent upstream (powszechnie stosowana biblioteka kryptograficzna, popularny SDK do przetwarzania obrazu, popularny wbudowany system operacyjny), każdy producent w dół łańcucha ponosi własny obowiązek z art. 13 ust. 5. Obowiązek nie przechodzi na najbardziej staranne rówieśnictwo, a „wszyscy inni go używają" nie jest linią obrony.

Istnieją dwa wzorce koordynacji, które ograniczają duplikację pracy bez zrzucania obowiązku:

Rejestr należytej staranności powinien wprost nazywać źródło wspólnej weryfikacji: „raport z przeglądu [grupa robocza], data [X], przejrzany i zaakceptowany [Y], luki śledzone w [system]". Kopia z teczki kolegi po fachu nie zastępuje twojej własnej decyzji zapisanej w rejestrze.

Po fuzji lub przejęciu: odziedziczone relacje z dostawcami

Kiedy twoja spółka przejmuje inną spółkę, dziedziczysz również jej listę dostawców. Częstą rzeczywistością po fuzji lub przejęciu są dziesiątki lub setki relacji z dostawcami bez żadnego rejestru należytej staranności w kształcie CRA. Pracy nie da się wykonać z dnia na dzień, ale segregacja jest osiągalna w obrębie jednego kwartału.

SEGREGACJA DOSTAWCÓW PO FUZJI/PRZEJĘCIU (90 DNI)

DNI 1-15: Inwentaryzacja
[ ] Pobierz listę dostawców z systemu ERP/zakupów przejmowanego podmiotu
[ ] Sparuj z aktualnymi BOM produktów
[ ] Zidentyfikuj, którzy dostawcy zasilają produkty w zakresie CRA
[ ] Wypuść poza segregację dostawców spoza zakresu

DNI 15-30: Warstwowanie
[ ] Zastosuj swój model warstw do odziedziczonej listy
[ ] Oznacz dostawców bez istniejącego rejestru należytej staranności
[ ] Wyróżnij dostawców, których produkty mieszczą się w Ważnej klasie II
    lub w Krytycznej

DNI 30-60: Kwestionariusze Warstwy 1
[ ] Wyślij kwestionariusz do każdego dostawcy Warstwy 1 bez rejestru
[ ] Ponów wysyłkę do każdego dostawcy Warstwy 1, którego rejestr
    jest starszy niż 24 miesiące
[ ] Zbieraj odpowiedzi centralnie

DNI 60-90: Brama decyzyjna
[ ] Dostawcy Warstwy 1 z pomyślnymi odpowiedziami → włączeni
[ ] Dostawcy Warstwy 1 z sygnałami ostrzegawczymi → plan mitygacji
    lub zamiana
[ ] Dostawcy Warstwy 2/3 → wpisani w standardowy cykl roczny

NA BIEŻĄCO:
[ ] Wprowadź odziedziczonych dostawców w normalny harmonogram monitorowania
[ ] Oznacz w rejestrze dostawcy pochodzenie z fuzji/przejęcia dla celów audytu

Rozporządzenie nie daje okresu przejściowego po fuzji ani przejęciu; podmiot przejmujący dziedziczy obowiązek producenta w dniu zamknięcia transakcji, na komponentach obecnych w już wysyłanym produkcie. Powyższa segregacja jest praktycznym kompromisem: dowodem, że działa program możliwy do obrony, nawet jeśli pełny rejestr jest odbudowywany.

Widoczność w n warstwach podwykonawców

Twój dostawca Warstwy 1 może sam podzlecać dostawcy Warstwy 2, który z kolei integruje komponenty od upstreamu Warstwy 3. Obowiązek CRA jest twój niezależnie od tego, gdzie w łańcuchu powstaje podatność. Praktyczna widoczność jednak gwałtownie spada poza Warstwą 1.

Trzy konkretne mechanizmy kontroli, które dają realną widoczność w n warstwach:

• Klauzula tranzytywnego SBOM. Umowa wymaga, aby SBOM dostawcy obejmował zależności tranzytywne, nie tylko bezpośrednie. SBOM tylko z bezpośrednimi zależnościami ukrywa niemal całą faktyczną powierzchnię ryzyka.
• Lista subprocesorów lub podwykonawców. Umowa wymaga, aby dostawca ujawniał i aktualizował listę imiennych podwykonawców, którzy dotykają części komponentu istotnych dla bezpieczeństwa. Klauzula nie daje ci prawa weta, ale daje widoczność.
• Przepływ podatności (vulnerability pass-through). Umowa wymaga, aby dostawca przekazywał ci podatności wykryte w komponentach zintegrowanych tranzytywnie w tym samym terminie, co podatności w kodzie wytworzonym bezpośrednio.

Bez tranzytywnego SBOM nie da się uruchomić skanów drzewa zależności na komponencie i nie da się wykazać organowi nadzoru rynku, że ryzyko w n warstwach zostało ocenione. Bez listy subprocesorów zmiana podwykonawcy w upstreamie (z własną proweniencją, kontrolami i bus-factorem) jest dla ciebie niewidoczna. Bez przepływu podatności milczenie dostawcy Warstwy 1 w sprawie problemu Warstwy 2 staje się twoim milczeniem w sprawie incydentu bezpieczeństwa.

Klauzule umowy z dostawcą

Włącz te postanowienia do umów z dostawcami. Każda klauzula jest umownym zaczepieniem dla jednego z opisanych powyżej rezultatów należytej staranności.

Oświadczenie o zgodności:

Dostawca oświadcza i gwarantuje, że Produkt(y)
są zgodne z Rozporządzeniem (UE) 2024/2847 (akt o
cyberodporności) oraz że Dostawca przeprowadził
wymaganą ocenę zgodności.

Dostarczanie dokumentacji:

Dostawca dostarczy na żądanie:
(a) Kopię Deklaracji zgodności UE
(b) Software Bill of Materials w formacie [CycloneDX/SPDX],
    obejmujący zależności tranzytywne
(c) Dokumentację techniczną istotną dla obowiązków
    zgodności Kupującego
Czas odpowiedzi: [5 dni roboczych]

Powiadamianie o podatnościach:

Dostawca powiadomi Kupującego w ciągu [24/48] godzin od
chwili uzyskania wiedzy o jakiejkolwiek podatności
bezpieczeństwa w Produkcie(ach) lub w jakimkolwiek
komponencie zintegrowanym tranzytywnie, która:
(a) Jest aktywnie wykorzystywana, lub
(b) Ma wynik CVSS 7,0 lub wyższy, lub
(c) Podlega publicznemu ujawnieniu

Zobowiązanie do okresu wsparcia:

Dostawca zobowiązuje się do dostarczania aktualizacji
bezpieczeństwa dla Produktu(ów) przez minimalny okres
[5/7/10] lat od daty pierwszego wprowadzenia na rynek UE.

Aktualizacje SBOM:

Dostawca dostarczy zaktualizowany SBOM w ciągu [10]
dni roboczych od każdego wydania produktu, które
obejmuje zmiany w bezpośrednich lub tranzytywnych
komponentach stron trzecich.

Prawa audytu:

Kupujący może przeprowadzić audyt zgodności Dostawcy
z niniejszą Umową i obowiązującymi wymaganiami CRA
po [30-dniowym] pisemnym powiadomieniu, nie częściej
niż raz w roku, chyba że audyt zostanie wywołany
obawą o zgodność.

Ujawnianie podwykonawców:

Dostawca prowadzi i udostępnia na żądanie listę
podwykonawców, którzy uczestniczą w wytwarzaniu
lub mają dostęp do komponentów Produktu(ów) istotnych
dla bezpieczeństwa. Dostawca powiadomi Kupującego
o każdej istotnej zmianie tej listy w ciągu [30] dni.

Częste błędy

Poleganie na samooświadczeniu

Problem: Akceptowanie ustnych zapewnień dostawcy bez dokumentacji.

Naprawa: Zawsze uzyskaj pisemny dowód. Brak kopii DoC, brak zakupu. Podpisany kwestionariusz jest podłogą, nie sufitem.

Jednorazowa ocena

Problem: Należyta staranność wyłącznie przy podpisywaniu umowy.

Naprawa: Wdróż harmonogram monitorowania opisany powyżej. Stan zgodności zmienia się, kwestionariusze tracą ważność.

Ignorowanie dostawców Warstwy 3-4

Problem: Ocenianie wyłącznie „głównych" dostawców przy pomijaniu mniejszych.

Naprawa: Nawet drobne komponenty wprowadzają podatności (lekcja log4j). Skaluj ocenę, nie pomijaj warstwy.

Brak podstawy umownej

Problem: Poleganie na dobrej woli dostawcy bez warunków umownych.

Naprawa: Umieść obowiązki zgodności na piśmie. Powyższe klauzule są podłogą.

Czekanie do grudnia 2027 r.

Problem: Rozpoczynanie ocen dostawców tuż przed datą stosowania CRA.

Naprawa: Zacznij teraz. Odpowiedzi dostawców się opóźniają. Niezgodni dostawcy potrzebują miesięcy na naprawę albo zostają zamienieni.

Lista kontrolna należytej staranności wobec dostawców

LISTA KONTROLNA NALEŻYTEJ STARANNOŚCI WOBEC DOSTAWCÓW

PRZED ZAANGAŻOWANIEM:
[ ] Określona warstwa dostawcy (1/2/3/4)
[ ] Określony typ dostawcy (komercyjny, FOSS, opiekun OSS,
    chmura, sprzęt, zmodyfikowane COTS)
[ ] Wybrany odpowiedni wariant kwestionariusza
[ ] Przydzielony wewnętrzny recenzent

OCENA WSTĘPNA:
[ ] Wysłany kwestionariusz
[ ] Otrzymany i przejrzany kwestionariusz
[ ] Zidentyfikowane i rozwiązane sygnały ostrzegawcze
[ ] Zebrana dokumentacja:
    [ ] Deklaracja zgodności UE (lub powód „nie dotyczy")
    [ ] SBOM z zależnościami tranzytywnymi (lub potwierdzona dostępność)
    [ ] Polityka CVD
    [ ] Zobowiązanie do okresu wsparcia
[ ] Wykonane kontrole wyrywkowe:
    [ ] Zweryfikowany security.txt
    [ ] Przetestowany kontakt bezpieczeństwa
    [ ] Zweryfikowane oznakowanie CE

NEGOCJACJE UMOWY:
[ ] Włączone klauzule zgodności
[ ] Uzgodnione postanowienia dotyczące dokumentacji
[ ] Ustalone warunki powiadamiania o podatnościach (godziny,
    nie „niezwłocznie")
[ ] Zabezpieczone zobowiązanie do okresu wsparcia
[ ] Włączone prawa audytu
[ ] Uzgodniony harmonogram aktualizacji SBOM
[ ] Włączona klauzula ujawniania podwykonawców

PO ZAWARCIU UMOWY:
[ ] Ustanowiony harmonogram monitorowania
[ ] Potwierdzone pierwsze dostarczenie dokumentacji
[ ] Kontakty zarejestrowane w systemie zarządzania dostawcami
[ ] Daty przeglądów wpisane do kalendarza

NA BIEŻĄCO:
[ ] Wykonane miesięczne kontrole
[ ] Wykonane kwartalne przeglądy
[ ] Wykonana roczna ponowna ocena
[ ] Obsłużone zdarzenia wyzwalające (incydent, zmiana właściciela, EOL)

Powiązane przewodniki

• Jak wygenerować SBOM zgodny z CRA: narzędzia, formaty i integracja CI/CD
• Przewodnik producenta CRA
• Lista kontrolna dystrybutora CRA

Niniejszy artykuł służy wyłącznie celom informacyjnym i nie stanowi porady prawnej. W celu uzyskania szczegółowych wskazówek dotyczących zgodności należy skonsultować się z wykwalifikowanym doradcą prawnym.