4crypto.eu
Bezpłatna konsultacja
Kompetencja · Vulnerability management · 2026

Skanowanie podatności w 2026 r. - od CVE i CVSS 4.0 po EPSS i CISA KEV

Autor: dr inż. Adam CzubakCzas czytania: 12 minAktualizacja: 2026-05-13

Skanowanie podatności (ang. vulnerability scanning, vulnerability assessment) to systematyczne, najczęściej zautomatyzowane wykrywanie znanych podatności w systemach, aplikacjach i komponentach sieciowych - z wykorzystaniem baz CVE (ang. Common Vulnerabilities and Exposures) i sygnatur z baz NVD [1]. To podstawowy, tani i ciągły mechanizm wykrywania ryzyk, fundamentalnie różny od pentestu: skaner mówi "znalazłem znaną dziurę", pentester mówi "wykorzystałem ją i ukradłem dane".

W 2026 r. krajobraz zmienił się istotnie. CVSS 4.0 [2] wszedł do produkcji w czerwcu 2023. EPSS [3] pozwala przewidzieć prawdopodobieństwo wykorzystania w 30 dni. CISA Known Exploited Vulnerabilities Catalog (KEV) [4] daje listę luk realnie wykorzystywanych w atakach. Te trzy źródła razem zastępują naiwne "łatamy wszystko CVSS ≥ 7" podejściem opartym na realnym ryzyku.

Skanowanie vs pentest vs audyt

Te trzy techniki różnią się celem, kosztem i głębokością.

  • Skanowanie podatności - automatyczny silnik (Nessus, Qualys, OpenVAS, Tenable, Rapid7 InsightVM, Greenbone) porównuje wykrytą wersję oprogramowania / konfigurację z bazą CVE i regułami. Niskie false negative dla znanych luk, ale zero zdolności do wykrycia luk biznesowych (logika autoryzacji, nadużycie funkcji, eskalacja przez procesy biznesowe). Cena: niska, tygodnie pracy.
  • Pentest - manualna symulacja ataku przez specjalistę. Wykrywa luki, których skaner nie widzi (logika, łańcuchy ataków, abuse of legitimate functionality). Cena: wysoka, kilkanaście do kilkudziesięciu osobodni. Szczegóły w osobnym artykule o testach penetracyjnych.

Złota zasada: skanowanie uzupełnia pentest i audyt, nie zastępuje. Operator usługi kluczowej (NIS2 [5], DORA [6]) musi mieć wszystkie trzy w cyklu.

Architektura skanowania

Profesjonalne skanowanie podatności składa się z czterech faz powtarzanych cyklicznie.

  1. Discovery (inwentaryzacja). Skaner identyfikuje, co jest w sieci. Bez świadomości pełnego inwentarza nie ma sensu mówić o pokryciu skanami. Typowa luka: shadow IT - urządzenia spoza zarządzania CMDB. Microsoft DDR 2024 [7] szacuje, że organizacje znają tylko 70-80% swoich zasobów IT.
  2. Identyfikacja podatności. Skaner wysyła charakterystyczne zapytania (banner grabbing, version detection, configuration check), porównuje wyniki z bazą CVE/NVD [1], wypisuje listę obserwacji. Dla aplikacji webowych: dedykowany skaner DAST (Burp Pro, Acunetix, ZAP, Invicti) symuluje typowe ataki OWASP Top 10 [8].
  3. Walidacja. Filtrowanie false positives (skaner alarmuje o CVE, którego faktycznie nie ma - bo np. patch backported w dystrybucji Linux, ale wersja w bannerze nadal wygląda na podatną). Ten krok decyduje o jakości raportu - bez walidacji raport ma 30-50% szumu.
  4. Priorytetyzacja i raportowanie. Łączenie CVSS, EPSS, KEV, kontekst biznesowy → kolejka patchowania.

Dwa tryby skanowania:

  • Authenticated scan - z konta uprzywilejowanego w systemie. Widzi wersje pakietów, konfigurację, reguły firewalla, polityki haseł. Dramatycznie wyższa dokładność (mniej FP), ale wymaga zaufania do skanera (poświadczenia jednak gdzieś trafiają).
  • Unauthenticated scan - bez poświadczeń, jak atakujący z zewnątrz. Pokazuje, co widzi napastnik niezalogowany. Niższa dokładność, ale realniejsze wnioski.

Najlepsza praktyka: oba - authenticated wewnątrz organizacji, unauthenticated z zewnątrz (lub z DMZ).

CVSS 4.0 - co się zmieniło

CVSS (ang. Common Vulnerability Scoring System) to skala 0-10 oceniająca teoretyczne nasilenie luki. Wersja 4.0 [2] (publikacja czerwiec 2023, w produkcji od 2024) wprowadziła kluczowe ulepszenia względem 3.1:

  • Czwarty wymiar - Supplemental metrics. Dotychczas CVSS miał Base, Temporal i Environmental. CVSS 4.0 dodaje wymiar opisujący wpływ na bezpieczeństwo fizyczne (Safety) i odporność odzyskiwania (Recovery). Krytyczne dla OT/ICS i medycyny.
  • Zniesienie Scope. Złożona w 3.1 metryka "czy luka wpływa na coś poza komponentem" została zastąpiona dwoma osobnymi metrykami: Vulnerable System i Subsequent System. Łatwiej liczyć, trudniej manipulować.
  • Threat Metrics z CTI. CVSS 4.0 jawnie zaprasza do uwzględnienia, czy luka jest faktycznie wykorzystywana (ang. Threat Maturity). To krok w kierunku zbliżenia CVSS do EPSS i KEV.

Praktyczna implikacja: wynik 8.4 w CVSS 4.0 może oznaczać znacznie wyższe realne ryzyko niż 8.4 w CVSS 3.1 - bo komponent Subsequent System uwypukla lateralny ruch.

EPSS i KEV - od teorii do prawdopodobieństwa

Problem czystego CVSS: ze 200 000+ CVE w bazie NVD [1] tylko 2-5% jest faktycznie wykorzystywanych w atakach. Patchowanie według samego CVSS skutkuje paniką: zespół IT goni krytyczne CVSS, których nikt nigdy nie wykorzysta.

  • EPSS (ang. Exploit Prediction Scoring System) [3] to model uczenia maszynowego publikujący codziennie prawdopodobieństwo, że dana CVE zostanie wykorzystana w ciągu 30 dni. Skala 0-1 (0 = niemal niemożliwe, 1 = praktycznie pewne). Jacobs et al. udowodnili, że kombinacja EPSS + KEV zwiększa skuteczność patchowania o ponad rząd wielkości wobec patchowania wg samego CVSS.
  • CISA KEV [4] to kuratorowana lista luk realnie obserwowanych w atakach (ponad 1100 CVE na 2024-2025). Dla podmiotów federalnych USA - obowiązek patchowania w ustalonych terminach (BOD 22-01). W praktyce najmocniejszy sygnał ryzyka, jakim dziś dysponujemy.

Praktyczna polityka priorytetyzacji w 2026 r.:

  1. Krytyczna kolejka (patch w 7-14 dni): luki w KEV niezależnie od CVSS.
  2. Pilna kolejka (patch w 30 dni): CVSS ≥ 9.0 lub EPSS ≥ 0.5.
  3. Standardowa kolejka (patch w cyklu kwartalnym): CVSS 7.0-8.9 i EPSS 0.1-0.5.
  4. Niska kolejka (patch w cyklu rocznym lub akceptacja): pozostałe.

Ta strategia, oparta na realnych danych z DBIR 2024 [9], skraca eksploatowalny zakres o 60-80% przy tej samej pracy zespołu.

Najczęstsze błędy programów vulnerability management

Z naszej praktyki audytowej:

  1. Skanowanie raz w roku, "pod audyt". Nowe CVE pojawiają się dziennie (DBIR 2024 [9] notuje rekordowy wzrost ataków na luki w urządzeniach brzegowych). Skanowanie roczne to security theater, nie program.
  2. Brak ownera dla każdej obserwacji. Skaner produkuje 50 000 alertów; bez przypisania do osoby/zespołu patrzymy na wodospad. Praktyka: zintegrowanie skanera z Jirą/GLPI/ServiceNow - każda krytyczna luka generuje ticket.
  3. Patch w produkcji = ryzyko biznesowe. Działy biznesowe blokują patche, bo "nie ma okna". Bez strategii excepcji (kompensujące kontrole, izolacja sieciowa, monitoring SOC) i bez zarządu zatwierdzającego decyzję - luki zostają na lata.
  4. Skanowanie tylko serwerów. Stacje robocze (zwłaszcza Linux developerów), urządzenia sieciowe, kamery IP, drukarki - wszystko ma luki. Verizon DBIR 2024 [9] pokazuje rosnący trend ataków na edge devices (firewalle, VPN concentrators) - często niełatane.
  5. Vulnerability ≠ Risk. Luka ma znaczenie dopiero w kontekście aktywa: serwer testowy bez danych produkcyjnych z CVE 9.8 to mniejsze ryzyko niż serwer plików z PESEL i CVE 6.5. Klasyfikacja aktywów musi poprzedzać priorytetyzację łatania.

Regulacje i wymogi

Skanowanie podatności jest wprost lub pośrednio wymagane przez:

  • KSC art. 8 ust. 2 [19] - operatorzy usług kluczowych i dostawcy usług cyfrowych muszą wdrożyć "odpowiednie i proporcjonalne środki techniczne i organizacyjne" zapewniające bezpieczeństwo systemu informacyjnego. Po nowelizacji UC59 (transpozycja NIS2, projekt 2024) wymóg jest doprecyzowany przez art. 21 (1) lit. e dyrektywy - "procedury oceny skuteczności środków", czyli regularne skanowanie podatności. Najtwardszy polski wymóg krajowy dla podmiotów objętych krajowym systemem cyberbezpieczeństwa.
  • NIS2 art. 21 (1) lit. e [5] - "procedury oceny skuteczności środków zarządzania ryzykiem cyberbezpieczeństwa". Skanowanie jest tu najtwardszym i najtańszym dowodem.
  • DORA art. 9 [6] - ciągłe identyfikowanie ICT risk, w tym podatności. Dla sektora finansowego od 17 stycznia 2025.
  • RODO art. 32 (1) lit. d [10] - "regularne testowanie skuteczności środków". PUODO w raportach [11] wskazuje brak skanowania jako wagonek przy oszacowaniu kary.
  • KRI § 20 [13] - wymóg utrzymania systemu informatycznego "w stanie pełnej sprawności i bezpieczeństwa" - interpretowany przez NIK jako wymóg systematycznego skanowania.
  • PCI DSS v4.0 - sektor obsługi kart płatniczych - kwartalny skan z autoryzowanego dostawcy (ASV).

Trendy 2025-2027

Trzy kierunki rozwoju:

  1. Risk-Based Vulnerability Management (RBVM) jako standard. Łączenie CVE + CVSS + EPSS + KEV + kontekst aktywa (klasyfikacja, dostępność z internetu, dane wrażliwe) w jeden ranking. Platformy Tenable Lumin, Qualys VMDR, Rapid7 InsightVM Risk-Based Analytics, Nucleus Security.
  2. Software Bill of Materials (SBOM). Po Log4Shell - wymóg wiedzy, które komponenty open-source są w naszym oprogramowaniu. CISA i Komisja Europejska (Cyber Resilience Act, w mocy od końca 2024) wymuszają SBOM dla dostawców software. Skanery uczą się czytać SBOM i mapować na CVE zamiast polegać na version detection.
  3. Continuous Threat Exposure Management (CTEM). Paradygmat Gartnera (od 2022, dojrzewający 2024-2025) łączący vulnerability scanning, attack surface management (ASM), breach and attack simulation (BAS) i pentest w jeden program. Zamiast "skanuj raz na kwartał" - "modeluj atakującego ciągle".

Checklist: 10 pytań do programu vulnerability management

Ocena dojrzałości - bez tego dokumentu zarząd nie wie, czy program istnieje, czy tylko płaci za licencję skanera.

  1. Inwentarz aktywów. Czy istnieje CMDB lub równoważne źródło prawdy - z minimum 95% pokrycia? Skanowanie bez pełnego inwentarza pomija najgorsze ryzyka (shadow IT, zapomniane serwery).
  2. Częstotliwość. Authenticated scan minimum co tydzień dla krytycznych aktywów, co miesiąc dla pozostałych. Unauthenticated scan z internetu - codziennie.
  3. Priorytetyzacja. Czy oprócz CVSS używamy EPSS i KEV? Czy klasyfikacja aktywów wchodzi do scoringu?
  4. SLA na patchowanie. KEV: 14 dni. Krytyczne (CVSS ≥ 9 lub EPSS ≥ 0.5): 30 dni. Średnie: 90 dni. Z odpowiedzialnym właścicielem.
  5. Integracja z ticketingiem. Każda obserwacja → ticket w Jira/GLPI/ServiceNow z właścicielem, terminem i statusem. Bez tego nie ma egzekwowania.
  6. Wyjątki. Formalna procedura zatwierdzania wyjątków (patch niemożliwy → kompensująca kontrola → zatwierdzenie zarządu → re-evaluacja co 6 miesięcy).
  7. Coverage walidacja. Czy skaner faktycznie obejmuje wszystkie segmenty sieci (VLAN-y, chmurę, OT, DMZ)? Próby skanowania różnych obserwacji w czasie (gdy IP ma rotację).
  8. Container i image scanning. Czy skanujemy obrazy Dockera w rejestrze (Trivy, Snyk, Clair, Anchore) przed wdrożeniem do produkcji?
  9. SBOM. Czy mamy SBOM dla każdego dostarczanego/wdrażanego oprogramowania? CycloneDX lub SPDX - format nie ma znaczenia, ale musi istnieć.
  10. Metryki dla zarządu. Czy raportujemy miesięcznie: średni czas patchowania krytycznych (MTTR-patch), zaległość (open critical), trend miesięczny? Bez metryk nie ma poprawy.

Najczęściej zadawane pytania

Jaki skaner polecacie?

Zależy od skali. Dla JST i małych organizacji: Greenbone (OpenVAS) - bezpłatny, open-source, wystarczający dla 100-300 hostów. Dla średnich i dużych: Tenable Nessus Professional, Qualys VMDR lub Rapid7 InsightVM. Dla aplikacji webowych: Burp Pro + OWASP ZAP.

Skanowanie zatrzyma działające usługi?

Authenticated scan praktycznie nigdy. Unauthenticated scan agresywny może zakłócić wrażliwe usługi (stare IoT, OT/SCADA, drukarki). Dlatego OT/ICS skanuje się ostrożnie - preferencyjnie pasywnie (Claroty, Nozomi, Dragos) zamiast aktywnie.

Jak interpretować EPSS, gdy mam 1000 luk?

Sortuj malejąco po EPSS i ucinaj na progu 0.1 (10% prawdopodobieństwa wykorzystania w 30 dni). Luki z EPSS ≥ 0.5 traktuj jak krytyczne niezależnie od CVSS. Luki z EPSS < 0.05 - kolejka standardowa.

Czy CISA KEV obejmuje wszystkie aktywne ataki?

Nie. KEV to lista potwierdzonych przez CISA - istnieją luki wykorzystywane, które nie trafiły na listę (zwłaszcza w Europie, gdzie CISA nie ma jurysdykcji). Wzbogacaj o CERT.PL [14] i ENISA Threat Landscape [15] dla kontekstu regionalnego.

Ile kosztuje program vulnerability management dla średniej JST?

Greenbone OSS + 4-8 osobodni roczne analityka = ok. 6-12 tys. zł rocznie. Tenable lub Qualys dla 100 hostów = 30-60 tys. zł rocznie. Outsourcing do MSSP (4crypto SOC + VM module): od 2 zł/host/m-c.

Czy skanowanie wystarczy do spełnienia NIS2?

Nie. NIS2 wymaga pełnego cyklu zarządzania ryzykiem - skanowanie jest jednym z mechanizmów oceny. Potrzebne są jeszcze: procedury reagowania, raportowanie do CSIRT, threat intelligence, szkolenia personelu. Skanowanie to minimum 30-40% tego, czego oczekuje audytor NIS2.

Co zrobić, gdy luka jest w urządzeniu OT, którego nie można zatrzymać?

Strategia kompensujących kontroli (zgodnie z IEC 62443 [16]): segmentacja sieci OT, firewall ograniczający komunikację OT z IT, strict allow-list portów, monitoring NDR. Plan wymiany urządzenia w cyklu 1-3 lat. Akceptacja ryzyka musi być formalnie zatwierdzona przez zarząd, z udokumentowaną oceną.

Skaner pokazał 50 000 alertów - od czego zacząć?

Najczęstsze pytanie na forach branżowych - przytłaczająca liczba to standard. Filtracja priorytetyzacyjna w trzech krokach:

  1. Wyłącz nieaplikowalne: luki w komponentach niezainstalowanych, w sieciach testowych, false positives. To zwykle redukuje listę o 60-70%.
  2. KEV first: każda CVE z CISA Known Exploited Vulnerabilities Catalog [4] niezależnie od CVSS. Listy KEV są aktualizowane na bieżąco.
  3. EPSS ≥ 0.5 lub CVSS ≥ 9.0 (luka na maszynie eksponowanej): pilna kolejka 30 dni.

Po tej filtracji typowo zostaje 150-500 realnie ważnych pozycji - manageable. NIST SP 800-40 Rev. 4 [17] potwierdza ten model w sekcji 4.2 (ang. risk-based prioritization).

Czy authenticated scan to ryzyko - daje poświadczenia adminowi skanera?

Tak, ale to akceptowalny kompromis dla większości środowisk. Best practices:

  • Konto dedykowane do skanowania (nie konto adminstratora osobistego), z minimalnymi uprawnieniami niezbędnymi do walidacji (np. local admin na konkretnej maszynie, nie domain admin).
  • MFA dla konta skanera (jeśli technicznie możliwe).
  • Vault dla poświadczeń (np. CyberArk, HashiCorp Vault, BeyondTrust) - skaner pobiera poświadczenia just-in-time.
  • Audit log każdego użycia konta skanera w SIEM.

Zgodne z NIST SP 800-53 Rev. 5 IA-2, AC-6 [18]. OWASP w wytycznych DAST/SAST nie wykluczają authenticated scanningu.

Patchowanie firmware - jak często?

NIST SP 800-40 Rev. 4 [17] nie odróżnia firmware od software - obowiązują te same SLA: KEV 14 dni, krytyczne 30 dni. Realnie firmware jest trudniejszy: wymaga restartu, czasami wymiany hardware, vendor lock-in. Strategia 2026 r.:

  • Firewall, switch, router brzegowy: patche krytyczne w 30 dni (DBIR 2024 [9]: 68% wzrost ataków na edge devices).
  • Drukarki, kamery IP, IoT: kwartalnie + przy zgłoszonej KEV.
  • PLC, RTU, urządzenia OT: według wytycznych producenta (Siemens, Rockwell mają własne SLA); zgodnie z IEC 62443 [16] - "planned downtime" w trakcie planowanych przeglądów.
Czy mogę skanować adresy IP, które nie są moją własnością?

Nie bez zgody. Skanowanie zewnętrzne adresów nie należących do organizacji to potencjalnie czyn z art. 267a kodeksu karnego (uzyskiwanie bez uprawnienia informacji o systemie informatycznym). Wyjątek: skanowanie własnej infrastruktury hostowanej u dostawcy chmurowego - wymaga sprawdzenia polityki dostawcy (AWS: pre-authorization dla niektórych typów, Azure: dozwolone bez powiadomienia w ramach Microsoft Customer Support Penetration Testing rules, GCP: bez powiadomienia). Dla SaaS - zwykle zabronione w Acceptable Use Policy.

Potrzebujesz konsultacji w tym obszarze?

Bezpłatna 30-60 minutowa konsultacja. Bez zobowiązań. Omawiamy potrzeby, skalę i ramowy harmonogram.

Zadzwoń: +48 691 122 312office@4crypto.eu

Powiązane treści

Pozostałe obszary kompetencyjne

Bibliografia i źródła

Wszystkie cytowane źródła są publicznie dostępne. Standardy ISO/IEC, RFC IETF, dyrektywy UE i akty krajowe odsyłają do oryginalnych dokumentów.

  1. [1]standardNational Institute of Standards and Technology (2024). National Vulnerability Database (NVD). NIST · https://nvd.nist.gov/
  2. [2]standardFIRST (Forum of Incident Response and Security Teams) (2023). Common Vulnerability Scoring System v4.0 Specification. FIRST, czerwiec 2023 · https://www.first.org/cvss/v4.0/specification-document
  3. [3]peer-reviewedJacobs, J., Romanosky, S., Edwards, B., Adjerid, I., Roytman, M. (2021). Exploit Prediction Scoring System (EPSS). Digital Threats: Research and Practice, vol. 2, no. 3, art. 20 · DOI: 10.1145/3436242
  4. [4]reportCybersecurity and Infrastructure Security Agency (CISA) (2024). Known Exploited Vulnerabilities Catalog (KEV). CISA, na bieżąco aktualizowany · https://www.cisa.gov/known-exploited-vulnerabilities-catalog
  5. [5]regulationParlament Europejski, Rada UE (2022). Dyrektywa (UE) 2022/2555 (NIS2) w sprawie środków na rzecz wysokiego wspólnego poziomu cyberbezpieczeństwa. Dziennik Urzędowy UE, L 333, 27.12.2022 · https://eur-lex.europa.eu/legal-content/PL/TXT/?uri=CELEX:32022L2555
  6. [6]regulationParlament Europejski, Rada UE (2022). Rozporządzenie (UE) 2022/2554 (DORA) w sprawie operacyjnej odporności cyfrowej sektora finansowego. Dziennik Urzędowy UE, L 333, 27.12.2022 · https://eur-lex.europa.eu/legal-content/PL/TXT/?uri=CELEX:32022R2554
  7. [7]reportMicrosoft (2024). Microsoft Digital Defense Report 2024. Microsoft Threat Intelligence · https://www.microsoft.com/en-us/security/security-insider/microsoft-digital-defense-report-2024
  8. [8]guidelineOpen Worldwide Application Security Project (OWASP) (2021). OWASP Top 10:2021 - Most Critical Web Application Security Risks. OWASP Foundation · https://owasp.org/Top10/
  9. [9]reportVerizon Business (2024). 2024 Data Breach Investigations Report (DBIR). Verizon, 17th edition · https://www.verizon.com/business/resources/reports/dbir/
  10. [10]regulationParlament Europejski, Rada UE (2016). Rozporządzenie (UE) 2016/679 (RODO) w sprawie ochrony osób fizycznych w związku z przetwarzaniem danych osobowych. Dziennik Urzędowy UE, L 119, 4.5.2016 · https://eur-lex.europa.eu/legal-content/PL/TXT/?uri=CELEX:32016R0679
  11. [11]reportPrezes UODO (2024). Sprawozdanie roczne z działalności Prezesa UODO za 2023 r.. UODO, Warszawa · https://uodo.gov.pl/pl/138/3270
  12. [12]standardInternational Organization for Standardization (2022). ISO/IEC 27001:2022 - Information security, cybersecurity and privacy protection - Information security management systems - Requirements. ISO/IEC · https://www.iso.org/standard/27001
  13. [13]regulationRada Ministrów RP (2012). Rozporządzenie Rady Ministrów z 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności (KRI). Dz.U. 2012 poz. 526 (z późn. zm.) · https://isap.sejm.gov.pl/isap.nsf/DocDetails.xsp?id=WDU20120000526
  14. [14]reportCERT Polska / NASK (2024). Raport roczny CERT Polska 2023. NASK PIB, Warszawa · https://www.cert.pl/publikacje/raport-roczny-cert-polska/
  15. [15]reportEuropean Union Agency for Cybersecurity (ENISA) (2024). ENISA Threat Landscape 2024. ENISA, Heraklion · DOI: 10.2824/0710888
  16. [16]standardInternational Electrotechnical Commission (2018). IEC 62443 - Industrial communication networks - Network and system security. IEC · https://www.iec.ch/cyber-security
  17. [17]standardSouppaya, M., Scarfone, K. (2022). NIST SP 800-40 Rev. 4: Guide to Enterprise Patch Management Planning. National Institute of Standards and Technology · DOI: 10.6028/NIST.SP.800-40r4
  18. [18]standardJoint Task Force (2020). NIST SP 800-53 Rev. 5: Security and Privacy Controls for Information Systems and Organizations. National Institute of Standards and Technology · DOI: 10.6028/NIST.SP.800-53r5
  19. [19]regulationSejm RP (2018, z projektem nowelizacji UC59 z 2024 r.). Ustawa z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa (KSC) - z projektem nowelizacji transponującym dyrektywę NIS2 (UC59, Rządowy Proces Legislacyjny). Dz.U. 2018 poz. 1560 z późn. zm. · https://isap.sejm.gov.pl/isap.nsf/DocDetails.xsp?id=WDU20180001560