Słownik

Aktywnie wykorzystywana podatność

Podatność, którą atakujący realnie wykorzystują. Uruchamia obowiązek zgłoszenia do ENISA w 24 godziny.

Źródłem informacji jest katalog CISA KEV (Known Exploited Vulnerabilities) oraz oznaczenia w europejskiej bazie EUVD. Jeśli taka podatność występuje w komponencie, którego Twój produkt używa, powstaje obowiązek z art. 14 ust. 1 CRA.

W Meldorze takie dopasowania są oznaczone jako pilne, liczony jest termin 24 godzin od alertu, a przy włączonym automacie trafiają od razu do konsultanta.

Zobacz też: Art. 14 CRA: obowiązek zgłaszania, Wczesne ostrzeżenie (24 h), Powzięcie wiedzy

Art. 14 CRA: obowiązek zgłaszania

Producent zgłasza aktywnie wykorzystywane podatności i poważne incydenty w trzech etapach: 24 h, 72 h, 14 dni.

Terminy biegną od chwili, w której producent dowiaduje się o aktywnie wykorzystywanej podatności (albo o poważnym incydencie wpływającym na bezpieczeństwo produktu). Producent informuje też użytkowników produktu o podatności i środkach zaradczych.

Niewypełnienie obowiązków z art. 13 i 14 grozi karą administracyjną do 15 mln euro lub 2,5% rocznego światowego obrotu (art. 64 CRA).

Zobacz też: Wczesne ostrzeżenie (24 h), Powiadomienie o podatności (72 h), Raport końcowy (14 dni), Powzięcie wiedzy, Poważny incydent

CSIRT koordynator

Krajowy zespół reagowania wyznaczony przez państwo, który otrzymuje zgłoszenie równolegle z ENISA; w Polsce rolę krajowego CSIRT pełni m.in. CSIRT NASK.

Gdy platforma SRP nie działa, producent kontaktuje się z CSIRT-em telefonicznie, a zgłoszenie uzupełnia na platformie po przywróceniu jej działania. Zanotuj godzinę próby i treść rozmowy w dzienniku zlecenia.

Zobacz też: Single Reporting Platform (SRP)

CVE

Publiczny identyfikator podatności, np. CVE-2021-44228.

Common Vulnerabilities and Exposures: rejestr prowadzony przez MITRE. Każda publicznie znana podatność dostaje numer, który jest wspólny dla wszystkich baz i narzędzi. W UE równolegle działa baza EUVD z własnymi identyfikatorami i odniesieniami do CVE.

Zobacz też: EUVD, NVD, OSV, GitHub Advisories, CVSS

CVSS

Ocena wagi podatności w skali 0–10: niska (do 3,9), średnia (4–6,9), wysoka (7–8,9), krytyczna (9–10).

Common Vulnerability Scoring System opisuje, jak groźna jest podatność w teorii: czy da się ją wykorzystać zdalnie, bez uwierzytelnienia, jaki ma wpływ. Nie mówi, czy dotyczy Twojego produktu ani czy ktoś jej używa; o tym decydują ocena konsultanta i katalog KEV.

Zobacz też: Aktywnie wykorzystywana podatność, EPSS

Cyber Resilience Act (CRA)

Rozporządzenie UE 2024/2847 o cyberbezpieczeństwie produktów z elementami cyfrowymi.

Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2024/2847 w sprawie horyzontalnych wymogów cyberbezpieczeństwa produktów z elementami cyfrowymi. Obowiązuje bezpośrednio w całej UE, bez ustawy krajowej.

Obowiązki zgłaszania podatności i incydentów (art. 14) stosuje się od 11 września 2026 r. Pozostałe wymagania (bezpieczeństwo produktu, obsługa podatności przez cały okres wsparcia, oznakowanie CE) od 11 grudnia 2027 r.

Zobacz też: Art. 14 CRA: obowiązek zgłaszania, Produkt z elementami cyfrowymi, Producent

CycloneDX

Format SBOM rozwijany przez OWASP, najczęściej używany w narzędziach bezpieczeństwa.

Format JSON lub XML z listą komponentów, metadanymi produktu (nazwa, wersja) i opcjonalnie podatnościami (VEX). Zalecany w Meldorze, bo zawiera wersję produktu w metadanych, dzięki czemu nowy SBOM sam trafia do właściwej wersji.

Zobacz też: SBOM (Software Bill of Materials), VEX

Czas na raport (SLA)

Termin z umowy, w którym konsultant publikuje raport: pilne w godzinach, pozostałe w dniach roboczych.

Dni robocze liczymy bez sobót, niedziel i polskich świąt ustawowych. Gdy konsultant zada pytanie, które blokuje ocenę, termin zostaje wstrzymany do Twojej odpowiedzi; widać to w dzienniku zlecenia.

Zobacz też: Zlecenie raportu, Dziennik zlecenia

Decyzja klienta

Co robisz z dopasowaniem: wysyłasz konsultantowi albo pomijasz jako nieistotne.

„Wyślij do konsultanta” tworzy zlecenie oceny eksperta. Cenę widzisz przed wysłaniem: ocena jest w cenie pakietu albo płatna za pozycję, według umowy. „Nieistotne, pomiń” zamyka dopasowanie bez raportu; decyzję możesz cofnąć. W trybie automatycznym wszystkie nowe dopasowania trafiają do konsultanta bez pytania.

Zobacz też: Zlecenie raportu, Tryb wysyłki

Dopasowanie

Para: komponent z Twojego SBOM i podatność, która dotyczy jego wersji.

Dopasowanie nie oznacza jeszcze, że produkt jest podatny: biblioteka może być obecna, ale podatna funkcja nieużywana albo niedostępna z sieci. Dlatego przy każdym dopasowaniu podejmujesz decyzję, a konsultant ocenia wpływ.

Zobacz też: Decyzja klienta, Ocena konsultanta

Dziennik zlecenia

Chronologiczny zapis zdarzeń: kto, kiedy i co zrobił. Dowód na wypadek kontroli.

Zawiera chwilę wykrycia, powzięcia wiedzy, pytania i odpowiedzi, publikację raportu i potwierdzenia wysłania do ENISA z numerami zgłoszeń. Jest załącznikiem do pobieranego raportu. Wpisów nie da się edytować ani usuwać.

Zobacz też: Powzięcie wiedzy, Zlecenie raportu

ENISA

Agencja Unii Europejskiej ds. Cyberbezpieczeństwa, która prowadzi platformę zgłoszeń.

Zgłoszenie z art. 14 CRA trafia jednocześnie do ENISA i do CSIRT-u koordynatora w państwie, w którym producent ma główną siedzibę. Jedna platforma obsługuje oba adresaty.

Zobacz też: Single Reporting Platform (SRP), CSIRT koordynator

EPSS

Prawdopodobieństwo, że podatność zostanie wykorzystana w ciągu 30 dni (0–100%).

Exploit Prediction Scoring System publikowany przez FIRST. Uzupełnia CVSS: podatność z wysokim CVSS, ale EPSS 1% jest w praktyce mniej pilna niż podatność z EPSS 90%. Meldora pokazuje EPSS, gdy silnik ma te dane.

Zobacz też: CVSS, Aktywnie wykorzystywana podatność

EUVD

Europejska baza podatności prowadzona przez ENISA.

European Union Vulnerability Database działa od 2025 r. Zbiera podatności z CVE i innych źródeł, dodaje własne identyfikatory (EUVD-RRRR-NNNNN) i oznacza te wykorzystywane. Meldora synchronizuje ją kilka razy dziennie.

Zobacz też: CVE, Aktywnie wykorzystywana podatność, ENISA

Kontakt awaryjny

Osoba w Twojej firmie, do której konsultant dzwoni przy aktywnie wykorzystywanej podatności.

Powinna mieć numer telefonu i włączone SMS-y. Przy terminie 24 godzin e-mail może zostać przeoczony, dlatego pilne alerty idą też SMS-em, a konsultant dzwoni, gdy klient nie reaguje.

Zobacz też: Aktywnie wykorzystywana podatność

MFA, TOTP, passkey

Drugi składnik logowania: kod z aplikacji (TOTP), klucz sprzętowy albo passkey.

Każde konto w Meldorze wymaga MFA. Klienci mogą używać aplikacji uwierzytelniającej (np. Microsoft Authenticator, Google Authenticator, Aegis) lub passkey. Konsultant loguje się wyłącznie kluczem sprzętowym lub passkey. Sesja wygasa po 30 minutach bezczynności.

Zobacz też: Token API i wgrywanie z CI

NVD, OSV, GitHub Advisories

Publiczne bazy podatności, z którymi porównujemy Twoje komponenty.

NVD (National Vulnerability Database, NIST) dodaje do CVE oceny CVSS i listy podatnych wersji. OSV (Google) opisuje podatności pakietów open source z dokładnymi zakresami wersji. GitHub Advisories obejmują ekosystemy npm, PyPI, Maven, NuGet, Go i inne.

Zobacz też: CVE, Silnik dopasowań

Ocena konsultanta

Dotyczy, nie dotyczy albo w analizie, z uzasadnieniem.

„Dotyczy”: podatny kod jest używany i podatność ma wpływ na produkt; trzeba ją usunąć w aktualizacji. „Nie dotyczy”: kod nieobecny, nieosiągalny albo chroniony; konsultant podaje powód w kodach VEX. „W analizie”: konsultant czeka na informację od Ciebie.

Zobacz też: VEX, Dopasowanie

Okres wsparcia

Czas, przez który producent dostarcza aktualizacje bezpieczeństwa; CRA wymaga co najmniej 5 lat, chyba że produkt jest używany krócej.

Datę końca wsparcia podajesz użytkownikom przy sprzedaży i w zgłoszeniu do ENISA (pole „okres wsparcia”). Po jej upływie obowiązek obsługi podatności wygasa, ale sprzedaż produktu nadal wymaga aktualizacji. Meldora przypomina 90 dni przed końcem.

Zobacz też: Produkt z elementami cyfrowymi, Wersja wspierana i wycofana

Oznakowanie CE i deklaracja zgodności

Od 11 grudnia 2027 r. produkty z elementami cyfrowymi muszą spełniać wymagania CRA, aby nosić znak CE.

Deklaracja zgodności UE obejmuje też wymagania cyberbezpieczeństwa z załącznika I CRA, w tym obsługę podatności. Dokumentacja techniczna zawiera SBOM i opis procesu obsługi podatności. Meldora dostarcza część dowodów: SBOM, monitoring, raporty i dziennik.

Zobacz też: Cyber Resilience Act (CRA), SBOM (Software Bill of Materials)

Planowane wydanie

Numer i data wersji, w której usuniesz podatności. Trafia do raportów i tekstów dla ENISA.

Gdy wgrasz SBOM tej wersji, Meldora oznaczy plan jako wykonany i wstawi wersję z datą do raportu końcowego dla ENISA. Jeśli termin minie bez nowego SBOM, konsultant dostanie przypomnienie.

Zobacz też: Raport końcowy (14 dni)

Poważny incydent

Incydent, który wpływa na bezpieczeństwo produktu; również podlega zgłoszeniu w 24 h, 72 h i 1 miesiąc.

Art. 14 ust. 3 CRA: np. przejęcie infrastruktury aktualizacji, wyciek kluczy podpisujących firmware, złośliwy kod w wydaniu. Meldora monitoruje podatności komponentów; o incydencie informujesz konsultanta sam, a on pomoże przygotować zgłoszenie.

Zobacz też: Art. 14 CRA: obowiązek zgłaszania

Powiadomienie o podatności (72 h)

Drugi etap: ogólne informacje o produkcie, charakter wykorzystania, wstępna ocena wagi i podjęte środki.

Termin 72 godzin liczy się od powzięcia wiedzy, nie od wysłania wczesnego ostrzeżenia. Licznik widoczny na platformie SRP może pokazywać inny czas; Meldora liczy termin zgodnie z rozporządzeniem i zapisuje chwilę powzięcia wiedzy w dzienniku.

Zobacz też: Wczesne ostrzeżenie (24 h), Raport końcowy (14 dni)

Powzięcie wiedzy

Chwila, od której liczą się terminy. W Meldorze to czas alertu o aktywnie wykorzystywanej podatności.

Zapisujemy go w dzienniku zlecenia razem z osobą, która podjęła decyzję. Jeśli dowiedziałeś się o podatności wcześniej innym kanałem (np. od badacza), powiedz o tym konsultantowi, bo wtedy terminy biegną od tamtej chwili.

Zobacz też: Art. 14 CRA: obowiązek zgłaszania, Dziennik zlecenia

Producent

Podmiot, który wprowadza produkt na rynek UE pod własną nazwą lub marką; na nim ciążą obowiązki CRA.

Producentem jest także importer lub dystrybutor, który wprowadza produkt pod własną marką albo istotnie go zmienia. Zgłoszenie do ENISA wysyła producent i on odpowiada za jego treść.

Zobacz też: Cyber Resilience Act (CRA), Art. 14 CRA: obowiązek zgłaszania

Produkt z elementami cyfrowymi

Urządzenie lub oprogramowanie, które łączy się z siecią lub innym urządzeniem, wprowadzone na rynek UE.

Każdy produkt sprzętowy lub programowy, którego działanie obejmuje bezpośrednie lub pośrednie połączenie logiczne albo fizyczne z innym urządzeniem lub siecią. W praktyce: sterowniki, bramki, czujniki IoT, firmware, aplikacje, biblioteki dostarczane klientom.

W Meldorze każdy produkt ma własny SBOM, wersje, rynki UE i okres wsparcia. Jeśli sprzedajesz warianty z różnym oprogramowaniem, załóż je jako osobne produkty.

Zobacz też: SBOM (Software Bill of Materials), Okres wsparcia

PURL (package URL)

Jednoznaczny identyfikator pakietu, np. pkg:deb/debian/openssl@3.0.13.

Zapis typu pkg:ekosystem/nazwa@wersja pozwala bez pomyłek dopasować komponent do bazy podatności. Narzędzia generujące SBOM (Syft, cdxgen) dodają PURL automatycznie; w SBOM-ach pisanych ręcznie często go brakuje.

Zobacz też: SBOM (Software Bill of Materials)

Raport końcowy (14 dni)

Trzeci etap: szczegółowy opis podatności, podmiot wykorzystujący (jeśli znany) i udostępniona aktualizacja.

Termin 14 dni liczy się od udostępnienia środka naprawczego lub łagodzącego, np. aktualizacji firmware. Gdy wgrasz SBOM wersji oznaczonej jako planowana poprawka, Meldora sama wstawi jej numer i datę do raportu końcowego.

Zobacz też: Powiadomienie o podatności (72 h), Planowane wydanie

Raport z monitoringu

Miesięczne podsumowanie: nowe dopasowania, stan źródeł, zlecenia. W ramach abonamentu.

Dokumentuje, że monitoring był prowadzony w sposób ciągły, co jest jednym z obowiązków producenta w okresie wsparcia. Znajdziesz go w zakładce Zlecenia i raporty.

Zobacz też: Okres wsparcia

Raport z oceny podatności

Dokument konsultanta: decyzja, czy zgłaszać do ENISA, uzasadnienie, rekomendacje i teksty do formularza.

Po publikacji treść raportu jest zamrożona i dołączona do dziennika zlecenia. Raport pobierasz jako plik HTML (do druku lub PDF). Jeśli zgłoszenie jest wymagane, każde pole formularza ENISA ma przycisk „Kopiuj”.

Zobacz też: Zlecenie raportu, Single Reporting Platform (SRP)

SBOM (Software Bill of Materials)

Lista komponentów oprogramowania w produkcie, z wersjami. Podstawa monitoringu.

Wykaz wszystkich bibliotek, pakietów i modułów (także zagnieżdżonych), z których składa się oprogramowanie produktu, wraz z numerami wersji i, najlepiej, identyfikatorami PURL. CRA wymaga, aby producent sporządził SBOM co najmniej dla zależności najwyższego poziomu.

Meldora przyjmuje SBOM w formatach CycloneDX i SPDX (JSON). Im pełniejszy SBOM (wersje, PURL), tym mniej fałszywych i pominiętych dopasowań.

Zobacz też: CycloneDX, SPDX, PURL (package URL), Składnik

Silnik dopasowań

Część Meldory, która porównuje SBOM z bazami podatności (Dependency-Track).

Każdy produkt i wersja to osobny projekt w silniku. Po każdej synchronizacji baz silnik sprawdza komponenty ponownie, dlatego dopasowanie może pojawić się wiele miesięcy po wgraniu SBOM. Stan synchronizacji widzisz w przeglądzie.

Zobacz też: Dopasowanie, NVD, OSV, GitHub Advisories

Single Reporting Platform (SRP)

Platforma ENISA, przez którą producent wysyła zgłoszenia. Działa od 11 września 2026 r., po angielsku, bez API.

Logowanie przez EU Login z MFA. Firma wyznacza przedstawiciela głównego i do 20 dodatkowych (Assigned Representatives). Jedno zgłoszenie dotyczy jednej podatności. Szkic widzi tylko osoba, która go utworzyła. Po wysłaniu raportu końcowego zgłoszenia nie można już edytować.

Platforma nie ma API, dlatego Meldora przygotowuje teksty do wklejenia, w kolejności pól formularza, i nie wysyła nic sama. Pola obowiązkowe są oznaczone gwiazdką.

Zobacz też: ENISA, Wczesne ostrzeżenie (24 h), Powiadomienie o podatności (72 h), Raport końcowy (14 dni)

Składnik

Pojedyncza biblioteka lub pakiet w SBOM, np. openssl 3.0.13.

Każdy komponent ma nazwę i wersję. Dopasowania do podatności powstają przez porównanie nazwy i wersji z bazami podatności. Komponent bez wersji nie może być monitorowany.

Zobacz też: SBOM (Software Bill of Materials), Dopasowanie

Skoordynowane ujawnianie podatności (CVD)

Polityka przyjmowania zgłoszeń od badaczy, wymagana przez CRA.

Producent musi mieć adres kontaktowy do zgłaszania podatności (np. security@, plik security.txt) i procedurę ich obsługi. Zgłoszenie od badacza o podatności w Twoim produkcie, która jest wykorzystywana, również uruchamia terminy z art. 14. Konsultant pomoże przygotować politykę CVD.

Zobacz też: Art. 14 CRA: obowiązek zgłaszania

SPDX

Format SBOM Linux Foundation, standard ISO/IEC 5962.

Powstał do opisu licencji, dziś obsługuje też bezpieczeństwo. Meldora rozpoznaje pakiet opisywany przez dokument (relacja DESCRIBES) jako produkt, a resztę pakietów jako komponenty. Jeśli dokument nie wskazuje produktu, poprosimy o wersję.

Zobacz też: SBOM (Software Bill of Materials), CycloneDX

Token API i wgrywanie z CI

Klucz, którym Twój pipeline wysyła SBOM do Meldory po każdym wydaniu.

Token tworzysz w ustawieniach; jest widoczny tylko raz. Przechowuj go jako sekret w CI (GitLab: Settings → CI/CD → Variables; GitHub: Settings → Secrets). Token daje tylko prawo wgrania SBOM do produktów Twojej firmy (produkt wskazujesz w adresie); nie pozwala czytać raportów ani niczego zmieniać. Unieważnij go, gdy zmieniasz CI albo odchodzi osoba, która go znała.

Zobacz też: SBOM (Software Bill of Materials), MFA, TOTP, passkey

Tryb wysyłki

Ręczny: sam decydujesz o każdym dopasowaniu. Automatyczny: wszystko trafia do konsultanta.

W trybie ręcznym możesz włączyć automat tylko dla pilnych podatności; zalecamy to, bo przy terminie 24 godzin liczy się każda godzina. Zmiana trybu dotyczy nowych dopasowań; o już wysłanych decyzja pozostaje.

Zobacz też: Decyzja klienta, Aktywnie wykorzystywana podatność

VEX

Dokument mówiący odbiorcom produktu, które znane podatności go nie dotyczą i dlaczego.

Vulnerability Exploitability eXchange. Twoi klienci, którzy skanują Twój SBOM, zobaczą te same dopasowania co Ty. VEX pozwala im odróżnić podatności realne od pozornych. Meldora eksportuje VEX w formacie CycloneDX na podstawie ocen konsultanta.

Kody uzasadnienia pochodzą ze standardu CycloneDX, np. code_not_present (kod nieobecny), code_not_reachable (kod nieosiągalny), protected_by_mitigating_control (chroni inny środek).

Zobacz też: Ocena konsultanta, CycloneDX

Wczesne ostrzeżenie (24 h)

Pierwszy etap zgłoszenia: krótka informacja, że podatność jest wykorzystywana, w 24 godziny od powzięcia wiedzy.

Wymaga tylko podstawowych danych: rodzaj zgłoszenia, tytuł, streszczenie, państwa członkowskie, nazwa i wersja produktu, data powzięcia wiedzy. Lepiej wysłać je szybko z niepełnymi danymi niż spóźnić się, czekając na analizę.

Zobacz też: Art. 14 CRA: obowiązek zgłaszania, Powiadomienie o podatności (72 h)

Wersja wspierana i wycofana

Monitorujemy każdą wersję, której używają Twoi klienci; wersję, której nikt nie używa, oznaczasz jako wycofaną.

Urządzenia w terenie często pracują na starszym firmware. Dlatego Meldora trzyma SBOM każdej wersji i sprawdza je wszystkie. Najnowsza wersja jest zawsze monitorowana. Gdy wgrasz SBOM z tym samym numerem wersji, zastąpi poprzedni.

Zobacz też: Okres wsparcia, SBOM (Software Bill of Materials)

Zlecenie raportu

Przekazanie dopasowań konsultantowi do oceny; kończy się raportem.

Zlecenie ma numer (RAP/RRRR/MM/NNN), termin z umowy, dziennik zdarzeń i wątek wiadomości. Ocenę liczymy za pozycję, czyli jedną lukę w jednym produkcie, także gdy pozycja dołącza do zlecenia w toku. Pilne dopasowania tworzą osobne zlecenie z krótszym terminem.

Zobacz też: Raport z oceny podatności, Czas na raport (SLA), Dziennik zlecenia