Embedded 24,0%, IoT 12,8%. Czy producent urządzenia mówi, gdzie zgłosić błąd w firmware?

Co mówią te dwie liczby

Producent płytek, modułów komunikacyjnych czy SoM-ów jest dostawcą komponentu dla innych producentów. Jeśli integrator znajdzie podatność w module, w BSP albo w stosie sieciowym, CRA nakazuje mu zgłosić ją producentowi komponentu (art. 13 ust. 6). Musi więc wiedzieć, dokąd napisać. W tym segmencie plik security.txt ma prawie co czwarta firma (18 z 75). To najlepszy wynik w przeglądzie, ale wciąż trzy firmy na cztery nie podają tej informacji w standardowym miejscu.

Segment IoT i smart home/budynek jest w próbie największy (392 firmy). Plik ma w nim 50 firm, czyli mniej więcej co ósma. To urządzenia pracujące u klientów latami, więc błąd w firmware może wyjść na jaw długo po sprzedaży.

Przedziały 95% (15,8…34,8% dla embedded, 9,8…16,4% dla IoT) nakładają się nieznacznie, a grupa embedded jest mała, więc różnicę traktujemy jako wyraźny sygnał, nie dokładny pomiar. Przegląd nie wyjaśnia, skąd się bierze.

Pomiar w skrócie

• Co sprawdzaliśmy: czy producent publikuje plik security.txt zgodny z RFC 9116, czyli plik tekstowy pod adresem /.well-known/security.txt, który mówi, gdzie zgłosić podatność.
• Kogo: 1 691 producentów z 30 krajów Europy, którzy pod własną marką wytwarzają sprzęt lub oprogramowanie z elementami cyfrowymi. Firmy pochodzą z publicznych list wystawców targów (m.in. embedded world, SPS, Hannover Messe, MTP Poznań) i członków stowarzyszeń branżowych, bez doboru pod kątem bezpieczeństwa. Wybraliśmy 1 752 firmy, a 61 wyłączyliśmy, bo ich strony nie odpowiadały.
• Kiedy i jak: stan na 30.09.2026 (Expires sprawdzone ponownie 1.10.2026); jedna domena na firmę, 1…2 zapytania HTTPS GET (do 4 z wariantem www.), najpierw /.well-known/security.txt, potem /security.txt. Bez logowania, testów podatności i skanowania portów. Plik liczy się, gdy serwer zwraca kod 200, a w treści jest pole Contact. Plik kompletny ma dodatkowo pole Policy i ważne pole Expires.

Ograniczenia. To przegląd, a nie badanie reprezentatywne. Wystawcy targów to częściej większe firmy, a Niemcy stanowią 48,7% próby. Odpowiedzi 403, 429 i 5xx (62 domeny) liczymy jako brak pliku, choć mogą oznaczać blokadę automatów; bez nich wynik ogólny wynosi 17,2% zamiast 16,6%. Sprawdzamy obecność pól, a nie to, czy adres z pola Contact działa. Publikujemy tylko wyniki zbiorcze, bez nazw firm.

Najważniejsze: brak security.txt nie oznacza niezgodności z CRA. Firma może przyjmować zgłoszenia przez stronę PSIRT, formularz albo adres podany gdzie indziej. security.txt to jedyny sygnał, który da się u każdej firmy sprawdzić z zewnątrz w ten sam sposób.

Wyniki

Segmenty

Tuż za embedded jest automatyka przemysłowa i OT (23,3%, 67 z 287). Poniżej średniej dla całej próby (16,6%) wypadają IoT (12,8%), ładowanie EV i urządzenia energetyczne (10,0%) oraz inne urządzenia podłączone (7,8%). Sprzęt sieciowy i telekomunikacyjny ma 18,8% (9 z 48), ale przy tak małej grupie przedział jest szeroki (10,2…31,9%) i wynik nie odróżnia się wyraźnie od średniej.

Plik kompletny i częściowy

Plik security.txt ma 16,6% sprawdzonych firm (280 z 1 691), ale kompletny, czyli z polem Policy i ważną datą Expires, tylko 7,7% (130). Pole Policy ma 8,9% firm, ważne Expires 14,2%. Ponad połowa znalezionych plików (150 z 280) nie spełnia więc kryterium kompletności. Co siódmy plik (14,3%, 40 z 280) ma problem z datą ważności. Podpis OpenPGP ma 34 pliki, a wzmiankę o CRA tylko 10 (0,6% firm).

Polska i Niemcy

Wśród 15 krajów z co najmniej 20 firmami w próbie Polska ma obok Włoch (3,9%) najniższy wynik: 4,0% (5 ze 126). Niemcy: 19,9% (164 z 823). Polskie firmy pochodzą częściowo z innych źródeł, dlatego porównaliśmy też wyłącznie wystawców tych samych targów międzynarodowych: 4,8% (2 z 42) wobec 19,9% (155 z 778), (test Fishera, p = 0,014). Polska część próby jest mała, więc to wyraźny sygnał, a nie dokładny pomiar. Różnice między Niemcami, Austrią, Szwajcarią i Holandią mieszczą się w niepewności i nie tworzą rankingu.

Rysunek 1. Udział firm z plikiem security.txt według segmentu. Źródło: AnnexProof, Indeks CRA, runda 2 (stan na 30.09.2026)

Jak wygląda poprawny plik

Przykład pliku zgodnego z RFC 9116 (domena przykładowa):

• Contact (wymagane, może się powtarzać): mailto:, tel: albo strona https://.
• Expires (wymagane, dokładnie raz): data i czas w formacie RFC 3339, z godziną i strefą czasową. RFC zaleca datę nie dalszą niż rok naprzód.
• Policy (opcjonalne): link do polityki skoordynowanego ujawniania podatności (CVD): co zgłaszać, jak i kiedy firma odpowie.
• Preferred-Languages (opcjonalne, raz): języki zgłoszeń; bez tego pola badacz może przyjąć angielski.
• Canonical (opcjonalne): adres, pod którym plik ma się znajdować. Zalecane przy podpisanym pliku.

Gdzie go umieścić. Pod https://<domena>/.well-known/security.txt, tylko przez HTTPS, z nagłówkiem Content-Type: text/plain; charset=utf-8. Stary adres /security.txt może przekierowywać do /.well-known/, ale nie zastępuje go. Plik dotyczy tylko domeny, w której leży, więc warto go dodać także np. w domenie portalu chmurowego urządzeń.

Podpis. RFC 9116 zaleca (nie wymaga) podpis OpenPGP w formie cleartext. Obejmuje on cały plik, który leży w tym samym miejscu: treść zaczyna się od -----BEGIN PGP SIGNED MESSAGE-----, a kończy blokiem -----BEGIN PGP SIGNATURE-----. Pole Canonical w podpisanej treści potwierdza lokalizację pliku.

Rysunek 2. Plik security.txt, jego pola i plik kompletny. Źródło: AnnexProof, Indeks CRA, runda 2 (stan na 30.09.2026)

Pięć najczęstszych błędów w danych (z 280 znalezionych plików):

1. Brak pola Policy: 130 plików. RFC nie wymaga tego pola, ale bez niego badacz nie zna zasad zgłaszania. Polityki CVD wymaga natomiast CRA (zał. I cz. II pkt 5, stosowany od 11 grudnia 2027 r.).
2. Brak wymaganego pola Expires: 19 plików (6,8%).
3. Plik tylko pod starym adresem /security.txt: 15 plików. RFC 9116 wymaga lokalizacji /.well-known/.
4. Data Expires minęła: 14 plików (5,0%). RFC ostrzega, że nieaktualny plik może być gorszy niż żaden.
5. Data Expires w złym formacie: 7 plików (2,5%).

Osobno: 162 domeny zwróciły kod 200 bez pola Contact, np. stronę HTML zamiast pliku tekstowego. Nie wiemy, ile z nich to nieudane próby publikacji.

24 godziny w praktyce producenta urządzeń

Co mówi przepis. Chodzi o aktywnie wykorzystywaną podatność, czyli taką, co do której są wiarygodne dowody, że podmiot działający w złych zamiarach wykorzystał ją w systemie bez zgody właściciela (art. 3 pkt 42). Producent wysyła wczesne ostrzeżenie najpóźniej w 24 godziny od powzięcia wiadomości, z informacją, w których państwach członkowskich udostępnił produkt (art. 14 ust. 2 lit. a), zgłoszenie podatności najpóźniej w 72 godziny (lit. b) i sprawozdanie końcowe najpóźniej 14 dni po udostępnieniu środka naprawczego lub ograniczającego ryzyko (lit. c). Zgłoszenia trafiają jednocześnie do CSIRT wyznaczonego jako koordynator i do ENISA, przez pojedynczą platformę sprawozdawczą (art. 14 ust. 1 i art. 16). Właściwy CSIRT wskazuje główna siedziba producenta w UE (art. 14 ust. 7).

Obowiązek obejmuje także produkty wprowadzone do obrotu przed 11 grudnia 2027 r. (art. 69 ust. 3). Osobno regulowane są poważne incydenty (ust. 3) i informowanie użytkowników (ust. 8).

Kto decyduje. Rozporządzenie nie wskazuje stanowiska, odpowiada producent. W praktyce potrzebna jest imiennie wyznaczona osoba i zastępca, którzy mogą wysłać wczesne ostrzeżenie bez zwoływania zarządu, także w nocy i w weekend. Decyzja jest techniczna (czy podatność dotyczy naszego produktu, których wersji i czy są dowody wykorzystania), więc ta osoba potrzebuje szybkiego dostępu do inżynierów znających firmware.

Rysunek 3. Udział firm z plikiem security.txt według kraju siedziby. Źródło: AnnexProof, Indeks CRA, runda 2 (stan na 30.09.2026)

Co trzeba mieć, żeby zdążyć:

• Inwentarz komponentów każdej wydanej wersji firmware (SBOM). Nie repozytorium, tylko to, co faktycznie jest w obrazie: SDK producenta układu, RTOS, bootloader, stos TLS i sieciowy, biblioteki, binarne bloby. Do tego mapa wersja, modele, rynki, bez której trudno wskazać państwa członkowskie we wczesnym ostrzeżeniu. SBOM obejmującego co najmniej zależności najwyższego poziomu wymaga zał. I cz. II pkt 1, stosowany od 11 grudnia 2027 r. Do decyzji w 24 godziny inwentarz potrzebny jest jednak już dziś.
• Monitorowanie podatności w tych komponentach. Źródła to m.in. CVE, europejska baza podatności ENISA (EUVD), katalog podatności wykorzystywanych w praktyce CISA KEV i biuletyny producentów układów. Automat dopasuje wpisy do SBOM, ale ocenia człowiek.
• Rejestr decyzji. Kiedy informacja dotarła, kto ją ocenił, na jakiej podstawie, co postanowiono i kiedy wysłano zgłoszenie. Termin liczy się od powzięcia wiadomości, więc ten moment trzeba umieć później wykazać.

Dlaczego najpierw kanał zgłoszeń. SBOM i monitoring wyłapią znane podatności w cudzych komponentach. Błąd we własnym firmware albo ślady jego wykorzystania może jednak zauważyć ktoś z zewnątrz: klient, integrator, badacz. Jeśli nie wie, dokąd pisać, wiadomość może trafić za późno, do działu sprzedaży albo najpierw do CERT-u. Od 11 grudnia 2027 r. polityka CVD i adres do zgłaszania podatności będą wymaganiem zasadniczym (zał. I cz. II pkt 5 i 6). security.txt to najprostszy sposób, żeby ten adres dało się znaleźć. Trudniejsze od pliku jest to, żeby ktoś czytał skrzynkę.

Lista kontrolna

• Plik pod https://<domena>/.well-known/security.txt, kod 200, text/plain; charset=utf-8.
• Contact działa i ma właściciela (sprawdzone wiadomością testową).
• Expires w formacie RFC 3339, mniej niż rok naprzód, z przypomnieniem przed wygaśnięciem.
• Policy prowadzi do polityki CVD.
• Preferred-Languages i Canonical; opcjonalnie podpis OpenPGP; plik także w innych domenach produktów.
• Osoba i zastępca z prawem decyzji o wczesnym ostrzeżeniu.
• SBOM każdej wydanej wersji firmware i mapa wersja, model, rynki.
• Monitoring podatności w komponentach z SBOM i rejestr decyzji z czasem powzięcia wiadomości.
• Ustalony właściwy CSIRT i sprawdzony dostęp do pojedynczej platformy sprawozdawczej ENISA.

Michał Kosiorek

Źródła

• Rozporządzenie (UE) 2024/2847 (Cyber Resilience Act), art. 3 pkt 42, art. 13 ust. 6, art. 14, art. 16, art. 69 ust. 3, art. 71 ust. 2, zał. I cz. II: https://eur-lex.europa.eu/eli/reg/2024/2847/oj
• RFC 9116, A File Format to Aid in Security Vulnerability Disclosure: https://www.rfc-editor.org/rfc/rfc9116
• Metodyka i wyniki przeglądu (Indeks CRA, runda 2, stan na 30.09.2026): https://annexproof.com/indeks/metodyka
• ENISA, Single Reporting Platform: https://www.enisa.europa.eu/topics/product-security-and-certification/single-reporting-platform-srp
• ENISA, European Vulnerability Database: https://euvd.enisa.europa.eu/
• CISA, Known Exploited Vulnerabilities Catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog