Skany podatności infrastruktury – uwierzytelnione czy nieuwierzytelnione, jak często i jak priorytetyzować wyniki (CVSS, EPSS, KEV)

Czym jest skan podatności infrastruktury? Skan podatności infrastruktury to zautomatyzowany proces, w którym skaner identyfikuje usługi sieciowe, systemy operacyjne i oprogramowanie na hostach, a następnie porównuje je z bazą znanych podatności (CVE) i błędów konfiguracji. Potrzebuje go każda organizacja utrzymująca serwery, urządzenia sieciowe lub stacje robocze, a regulacje takie jak PCI DSS, DORA i NIS2 wymagają go wprost lub pośrednio.

Skan jest pierwszym, najtańszym i najczęściej powtarzanym elementem programu testów bezpieczeństwa – ale tylko wtedy, gdy jest prawidłowo skonfigurowany, uruchamiany z właściwą częstotliwością i połączony z procesem usuwania podatności.

Definicja kanoniczna: Skan podatności to zautomatyzowana ocena systemów, sieci lub aplikacji polegająca na wykrywaniu znanych podatności i błędów konfiguracji poprzez porównanie zidentyfikowanych komponentów z bazami podatności, bez ich aktywnego wykorzystania.

Skany podatności infrastruktury – w skrócie:

1. Skan uwierzytelniony (z poświadczeniami do systemu) wykrywa zwykle kilkukrotnie więcej podatności niż nieuwierzytelniony, bo widzi zainstalowane pakiety i konfigurację, a nie tylko odpowiedzi usług sieciowych.
2. PCI DSS v4.0.1 wymaga skanów wewnętrznych co najmniej raz na 3 miesiące, od 31 marca 2025 uwierzytelnionych (wymóg 11.3.1.2), oraz zewnętrznych skanów ASV co kwartał (11.3.2).
3. DORA przez RTS 2024/1774 (art. 10) wymaga automatycznych skanów aktywów ICT wspierających funkcje krytyczne lub istotne co najmniej raz w tygodniu.
4. Sam wynik CVSS nie wystarcza do priorytetyzacji – łącz go z EPSS (prawdopodobieństwo wykorzystania) i katalogiem CISA KEV (podatności aktywnie wykorzystywane) oraz z kontekstem aktywa.
5. Według Verizon DBIR 2025 wykorzystanie podatności było wektorem wejścia w około 20 % naruszeń – skan bez procesu remediacji nie obniża tego ryzyka.
6. Patronusec realizuje skany podatności wewnętrzne i zewnętrzne, w tym skany ASV dla PCI DSS, konfigurując uwierzytelnienie i zakres tak, aby wyniki były akceptowalne dla audytora QSA i regulatora.

---

---

Czym jest skan podatności i czym różni się od testu penetracyjnego?

Skan podatności to zautomatyzowane wykrywanie znanych luk przez porównanie komponentów z bazami CVE, natomiast test penetracyjny to manualna próba wykorzystania podatności i połączenia ich w ścieżkę ataku. Skan odpowiada na pytanie „co jest podatne”, pentest – „co da się z tym zrobić”. Skan trwa godziny i powtarza się co tydzień lub kwartał; pentest trwa tygodnie i wykonuje się raz lub dwa razy w roku.

Kryterium	Skan podatności	Test penetracyjny
Metoda	automatyczna, oparta na sygnaturach i wersjach	manualna, z użyciem narzędzi, oparta na logice atakującego
Wykrywa	znane CVE, brakujące poprawki, słabe konfiguracje, domyślne hasła	błędy logiki, łańcuchy podatności, eskalację uprawnień, problemy segmentacji
Fałszywe alarmy	częste (wersja zgłoszona ≠ wersja z backportem poprawki)	rzadkie – każde ustalenie jest potwierdzone
Czas	godziny	1-4 tygodnie
Częstotliwość	tygodniowa do kwartalnej	roczna lub po istotnej zmianie
Koszt orientacyjny	0-30 tys. zł rocznie (licencja lub usługa)	20-150 tys. zł za projekt
Wynik	lista podatności z oceną CVSS	raport z narracją ataku i ryzykiem biznesowym

Skan podatności identyfikuje znane luki bez ich wykorzystywania, natomiast test penetracyjny weryfikuje, czy zidentyfikowane luki można realnie wykorzystać i połączyć w ścieżkę ataku.

Oba narzędzia są komplementarne i w programach zgodności występują obok siebie: PCI DSS wymaga i skanów (wymóg 11.3), i pentestów (11.4); DORA wymienia oba w art. 25 jako elementy programu testowania; ISO 27001:2022 w zabezpieczeniu A.8.8 wymaga uzyskiwania informacji o podatnościach technicznych i podejmowania odpowiednich działań, nie wskazując metody. Przegląd wszystkich metod znajdziesz w artykule o metodach testowania bezpieczeństwa IT.

W praktyce oznacza to: skan wykryje, że serwer ma OpenSSH w wersji z CVE o CVSS 9,8; pentest sprawdzi, czy ta wersja jest faktycznie podatna w Twojej konfiguracji, czy da się przez nią wejść i dokąd prowadzi dalej.

Jakie są rodzaje skanów podatności infrastruktury?

Skany infrastruktury dzielą się według czterech osi: perspektywy (zewnętrzny z internetu lub wewnętrzny z sieci LAN), uwierzytelnienia (z poświadczeniami lub bez), sposobu zbierania danych (agent na hoście lub skan sieciowy) oraz celu regulacyjnego (skan ASV dla PCI DSS wykonywany przez zatwierdzonego dostawcę). Kompletny program łączy co najmniej skan zewnętrzny nieuwierzytelniony i wewnętrzny uwierzytelniony.

Rodzaj	Perspektywa	Co pokazuje	Typowe zastosowanie
Zewnętrzny nieuwierzytelniony	z internetu, bez poświadczeń	powierzchnię ataku widoczną dla każdego: otwarte porty, wersje usług, certyfikaty, błędy konfiguracji usług publicznych	cotygodniowy monitoring perymetru, wymóg PCI DSS 11.3.2 (jako skan ASV)
Wewnętrzny nieuwierzytelniony	z sieci LAN, bez poświadczeń	to, co widzi atakujący po wejściu do sieci: usługi wewnętrzne, protokoły starsze, udziały sieciowe	ocena ruchu bocznego, weryfikacja segmentacji
Wewnętrzny uwierzytelniony	z sieci LAN, z kontem do systemu	brakujące poprawki, wersje pakietów, konfigurację, lokalne konta, polityki	wymóg PCI DSS 11.3.1.2, DORA RTS art. 10, podstawa zarządzania podatnościami
Agentowy	agent zainstalowany na hoście	jak uwierzytelniony, ale ciągle i także dla urządzeń mobilnych i pracy zdalnej	laptopy, chmura, środowiska dynamiczne
ASV (Approved Scanning Vendor)	zewnętrzny, wykonany przez podmiot zatwierdzony przez PCI SSC	zgodność zewnętrznej powierzchni ataku z wymogiem 11.3.2 PCI DSS	kwartalny „passing scan” dla wszystkich adresów IP w zakresie CDE
Skan konfiguracji (compliance)	uwierzytelniony, względem benchmarku (CIS, DISA STIG)	odchylenia od standardu hardeningu, nie tylko CVE	wymóg PCI DSS 2.2, ISO 27001 A.8.9

Skan ASV to zewnętrzny, nieuwierzytelniony skan podatności wykonywany przez dostawcę zatwierdzonego przez PCI SSC, wymagany przez wymóg 11.3.2 PCI DSS co najmniej raz na trzy miesiące dla wszystkich publicznie dostępnych adresów IP w zakresie środowiska danych kart.

Dwa rozróżnienia sprawiają najwięcej problemów. Po pierwsze, skan ASV nie zastępuje wewnętrznego skanu uwierzytelnionego – to dwa odrębne wymogi PCI DSS. Po drugie, skan konfiguracji względem benchmarku CIS to inny produkt niż skan CVE: pierwszy powie, że SMBv1 jest włączony, drugi – że system nie ma poprawki na konkretną lukę. Dojrzały program wymaga obu.

W praktyce oznacza to, że organizacja przetwarzająca karty płatnicze potrzebuje minimum trzech strumieni skanów: ASV co kwartał (zewnętrzny), wewnętrzny uwierzytelniony co kwartał (lub częściej) oraz skan po każdej istotnej zmianie.

Dlaczego skan uwierzytelniony wykrywa więcej i czego wymaga od organizacji?

Skan uwierzytelniony wykrywa więcej, bo loguje się do systemu i odczytuje zainstalowane pakiety, poziom poprawek, rejestr lub konfigurację, zamiast wnioskować o wersji z banerów usług sieciowych. Nieuwierzytelniony skan nie widzi podatności w oprogramowaniu bez otwartych portów (przeglądarki, pakiety biurowe, biblioteki) i generuje więcej fałszywych alarmów. Wymaga natomiast dedykowanego konta, bezpiecznego przechowywania poświadczeń i zgody właścicieli systemów.

Czego potrzebujesz, aby uruchomić skan uwierzytelniony:

1. Konto skanujące – dedykowane, z uprawnieniami do odczytu konfiguracji (Linux: konto z sudo do wybranych poleceń lub bez; Windows: konto z uprawnieniami administracyjnymi do odczytu rejestru i WMI, najlepiej przez gMSA lub konto zarządzane).
2. Bezpieczne przechowywanie poświadczeń – w sejfie skanera lub integracji z systemem PAM; hasła rotowane, dostęp logowany.
3. Wyjątki sieciowe – reguły na zaporach i EDR pozwalające skanerowi na SSH/WinRM/SMB do hostów; bez tego skan uwierzytelniony cicho degraduje się do nieuwierzytelnionego.
4. Weryfikację powodzenia uwierzytelnienia – skanery raportują, na których hostach logowanie się nie powiodło; ten raport trzeba czytać po każdym skanie.
5. Zgodę i okna czasowe – skan uwierzytelniony obciąża hosty; dla systemów produkcyjnych ustal okna i limity równoległości.

Skan uwierzytelniony podatności to skan wykonywany z poświadczeniami umożliwiającymi zalogowanie się do badanego systemu i odczyt zainstalowanego oprogramowania oraz konfiguracji – PCI DSS v4.0.1 wymaga go w wymogu 11.3.1.2 dla skanów wewnętrznych od 31 mar 2025.

Wymóg 11.3.1.2 PCI DSS v4.0.1 precyzuje: skany wewnętrzne wykonuje się z uwierzytelnieniem, poświadczenia są wystarczające do pełnego skanu, a dla systemów, które nie przyjmują poświadczeń, wyjątek musi być udokumentowany. Konta używane do skanowania, jeśli mają uprawnienia interaktywnego logowania, podlegają wymogowi 8.2.2 (zarządzanie kontami współdzielonymi i systemowymi).

W praktyce oznacza to, że najczęstszą przyczyną „czystego” raportu z wewnętrznego skanu nie jest bezpieczne środowisko, lecz nieudane uwierzytelnienie na 40 % hostów, którego nikt nie sprawdził.

Jak często skanować infrastrukturę według PCI DSS, DORA, NIS2 i dobrych praktyk?

Częstotliwość skanów wynika z regulacji i klasyfikacji aktywów: PCI DSS wymaga skanów co najmniej raz na 3 miesiące i po każdej istotnej zmianie, DORA (RTS 2024/1774) co najmniej raz w tygodniu dla aktywów wspierających funkcje krytyczne lub istotne, CIS Controls v8 co najmniej co kwartał. Dobrą praktyką jest skanowanie zewnętrzne co tydzień, wewnętrzne co 2-4 tygodnie i ciągłe (agentowe) dla stacji roboczych.

Źródło wymogu	Zakres	Minimalna częstotliwość	Dodatkowe warunki
PCI DSS v4.0.1 wymóg 11.3.1	skany wewnętrzne w zakresie CDE	co 3 miesiące	podatności wysokie i krytyczne usunięte, ponowny skan potwierdza usunięcie; od 31 mar 2025 skany uwierzytelnione (11.3.1.2)
PCI DSS v4.0.1 wymóg 11.3.1.3	skany wewnętrzne	po każdej istotnej zmianie	np. nowe systemy, zmiany topologii, aktualizacje produktów
PCI DSS v4.0.1 wymóg 11.3.2	skany zewnętrzne ASV	co 3 miesiące	wynik „passing” (brak podatności CVSS ≥ 4,0), ponowne skany do uzyskania wyniku pozytywnego
PCI DSS v4.0.1 wymóg 11.3.2.1	skany zewnętrzne	po każdej istotnej zmianie	mogą być wykonane wewnętrznie, nie muszą przez ASV
DORA – RTS (UE) 2024/1774 art. 10 ust. 2 lit. b	wszystkie aktywa ICT, proporcjonalnie do klasyfikacji	co najmniej raz w tygodniu dla aktywów wspierających funkcje krytyczne lub istotne	rejestrowanie każdej podatności i monitorowanie usunięcia; weryfikacja, czy dostawcy ICT zgłaszają podatności krytyczne
NIS2 art. 21 ust. 2 lit. e	podmioty kluczowe i ważne	nie określa liczbowo	„bezpieczeństwo w procesie nabywania, rozwoju i utrzymania systemów, w tym postępowanie w przypadku podatności i ich ujawnianie”
ISO/IEC 27001:2022 A.8.8	cały zakres ISMS	nie określa liczbowo	uzyskiwanie informacji o podatnościach, ocena narażenia, odpowiednie środki
CIS Controls v8 7.5 i 7.6	aktywa wewnętrzne i zewnętrzne	co najmniej co kwartał	skany wewnętrzne uwierzytelnione (7.5), skany zewnętrzne (7.6)
SOC 2 CC7.1	zakres systemu	nie określa liczbowo	procedury wykrywania podatności i zmian konfiguracji

Zgodnie z art. 10 ust. 2 lit. b rozporządzenia delegowanego (UE) 2024/1774 podmioty finansowe objęte DORA wykonują automatyczne skany podatności aktywów ICT wspierających funkcje krytyczne lub istotne co najmniej raz w tygodniu.

Rozbieżność między „co kwartał” (PCI DSS, CIS) a „co tydzień” (DORA) nie jest przypadkowa: PCI DSS określa minimum dla dowodu zgodności, DORA – rytm operacyjny dla sektora, w którym okno między publikacją exploita a jego masowym użyciem liczy się w dniach. Organizacja podlegająca obu reżimom przyjmuje tygodniowy rytm i traktuje kwartalny skan jako punkt kontrolny do dokumentacji.

Patronusec Insight: Z naszego doświadczenia projektowego wynika, że audytor QSA najczęściej kwestionuje nie samą częstotliwość, lecz ciągłość dowodów: cztery kwartalne skany muszą pokrywać każdy adres IP i każdy host w zakresie, a dla każdej podatności wysokiej lub krytycznej musi istnieć ponowny skan potwierdzający usunięcie. Luka jednego kwartału lub jeden host pominięty z powodu nieudanego uwierzytelnienia oznacza niezgodność z wymogiem 11.3.1. W ramach skanów podatności Patronusec konfiguruje harmonogram, zakres i uwierzytelnienie w taki sposób, aby komplet raportów z 12 miesięcy dało się przedstawić audytorowi bez uzupełniania braków.

Jak priorytetyzować wyniki skanu – CVSS, EPSS, KEV i kontekst aktywa?

Wyniki skanu priorytetyzujesz, łącząc cztery sygnały: dotkliwość techniczną (CVSS), prawdopodobieństwo wykorzystania w najbliższych 30 dniach (EPSS), potwierdzone aktywne wykorzystanie (katalog CISA KEV) oraz kontekst aktywa (ekspozycja na internet, funkcja krytyczna, dane wrażliwe). Sam CVSS generuje zbyt wiele „krytycznych” pozycji, by zespół mógł je usunąć w rozsądnym czasie.

Sygnał	Kto publikuje	Co mierzy	Jak używać
CVSS (v3.1, v4.0)	FIRST, wynik nadawany przez NVD i vendorów	dotkliwość techniczną w skali 0-10 (wektor ataku, złożoność, wpływ)	filtr wstępny; PCI DSS definiuje „wysoką” jako ≥ 7,0, skan ASV nie przechodzi przy ≥ 4,0
EPSS	FIRST (model aktualizowany codziennie)	prawdopodobieństwo wykorzystania podatności w ciągu 30 dni (0-1)	podatności z EPSS > 0,1 traktuj priorytetowo niezależnie od CVSS
KEV	CISA (Known Exploited Vulnerabilities)	potwierdzone aktywne wykorzystanie w rzeczywistych atakach	każda pozycja z KEV na aktywie eksponowanym = remediacja w trybie pilnym
Kontekst aktywa	Twój rejestr aktywów (CMDB)	ekspozycja, klasyfikacja DORA/PCI, dane, zależności	mnożnik: ta sama CVE na serwerze płatności i na drukarce to dwa różne ryzyka
Możliwość wykorzystania	dane ze skanera i pentestów	czy exploit jest publiczny, czy mitygacje działają (EDR, segmentacja)	obniża lub podnosi priorytet

Praktyczny model priorytetyzacji w czterech krokach:

1. Natychmiast (24-72 h): podatność w katalogu KEV lub EPSS > 0,5, na aktywie dostępnym z internetu lub wspierającym funkcję krytyczną.
2. Pilnie (7-14 dni): CVSS ≥ 7,0 i (EPSS > 0,1 lub aktywo eksponowane); wszystkie podatności „wysokie” w zakresie PCI DSS.
3. Planowo (30-90 dni): CVSS 4,0-6,9 na aktywach wewnętrznych; pozostałe pozycje z zakresu PCI DSS zgodnie z ukierunkowaną analizą ryzyka (wymóg 11.3.1.1).
4. Akceptacja ryzyka: podatności bez poprawki i bez możliwości wykorzystania w danej konfiguracji – udokumentowane, z datą przeglądu.

EPSS (Exploit Prediction Scoring System) to publikowany przez FIRST model szacujący prawdopodobieństwo wykorzystania danej podatności w ciągu najbliższych 30 dni, uzupełniający ocenę dotkliwości CVSS o wymiar prawdopodobieństwa.

Wymóg 11.3.1.1 PCI DSS v4.0.1 wymaga, aby podatności inne niż wysokie i krytyczne były zarządzane na podstawie ukierunkowanej analizy ryzyka (wymóg 12.3.1) – to formalne umocowanie podejścia opartego na kontekście, nie tylko na CVSS.

W praktyce oznacza to, że lista 400 podatności „krytycznych” z kwartalnego skanu po zastosowaniu EPSS i KEV zamienia się zwykle w 20-40 pozycji wymagających działania w tym tygodniu – i to nimi powinien zajmować się zespół.

Jak zorganizować proces zarządzania podatnościami wokół skanów?

Skan jest dostawcą danych, a zarządzanie podatnościami – procesem, który je konsumuje: inwentaryzacja aktywów, skanowanie, priorytetyzacja, przypisanie właściciela, remediacja w terminie SLA, weryfikacja ponownym skanem i raportowanie trendów. Bez tego cyklu skan generuje raporty, których nikt nie czyta, a liczba otwartych podatności rośnie z każdym kwartałem.

Sześć elementów procesu i typowe wskaźniki:

Element	Co obejmuje	Wskaźnik
1. Inwentaryzacja	rejestr aktywów z właścicielem, klasyfikacją i ekspozycją; skan discovery wykrywający nieznane hosty	odsetek hostów w skanie względem CMDB (cel: > 95 %)
2. Skanowanie	harmonogram, zakres, uwierzytelnienie, wyjątki	odsetek hostów z udanym uwierzytelnieniem
3. Priorytetyzacja	CVSS + EPSS + KEV + kontekst; deduplikacja	liczba podatności „do działania” po filtrze
4. Przypisanie	właściciel techniczny per aktywo, ticket w systemie zgłoszeń	odsetek podatności z przypisanym właścicielem
5. Remediacja	poprawka, konfiguracja, mitygacja lub akceptacja ryzyka w terminie SLA	mediana czasu usunięcia (MTTR) per krytyczność
6. Weryfikacja i raport	ponowny skan, zamknięcie ticketu, raport dla zarządu	odsetek podatności usuniętych w SLA; trend otwartych pozycji

Orientacyjne terminy SLA stosowane w praktyce (organizacja powinna je dostosować do własnej analizy ryzyka):

• KEV / aktywnie wykorzystywane, aktywo eksponowane: 72 godziny (CISA BOD 22-01 nakłada na agencje federalne USA terminy 2-3 tygodni, praktyka sektora finansowego jest ostrzejsza),
• krytyczne (CVSS ≥ 9,0): 7-14 dni,
• wysokie (7,0-8,9): 30 dni,
• średnie (4,0-6,9): 90 dni,
• niskie: w cyklu utrzymaniowym lub akceptacja ryzyka.

Zarządzanie podatnościami to ciągły proces obejmujący inwentaryzację aktywów, skanowanie, priorytetyzację, remediację w określonych terminach oraz weryfikację ponownym skanem – w odróżnieniu od pojedynczego skanu, który jest tylko jednym z jego etapów.

Art. 10 ust. 2 RTS 2024/1774 dodaje dla podmiotów pod DORA cztery obowiązki procesowe: śledzenie bibliotek zewnętrznych (w tym open source) w usługach wspierających funkcje krytyczne, weryfikację, czy dostawcy ICT zgłaszają podatności krytyczne, procedury odpowiedzialnego ujawniania oraz rejestrowanie każdej wykrytej podatności wraz z monitorowaniem jej usunięcia. Zarządzanie podatnościami dostawców opisaliśmy szerzej w artykule o zarządzaniu ryzykiem dostawców ICT.

W praktyce oznacza to, że narzędzie skanujące należy zintegrować z systemem zgłoszeń i CMDB – inaczej etapy 4-6 wykonuje się ręcznie w arkuszu kalkulacyjnym, co przy kilkuset hostach przestaje działać po drugim kwartale.

Jakie błędy popełniają praktycy przy skanach podatności infrastruktury?

Najczęstsze błędy dotyczą zakresu, uwierzytelnienia, interpretacji wyników i braku domknięcia procesu. Każdy z nich sprawia, że skan spełnia wymóg formalnie, ale nie obniża ryzyka.

❌ Skanowanie tylko znanych adresów IP bez skanu discovery – hosty, których nie ma w CMDB, nie trafiają do zakresu; PCI DSS wymóg 11.3.1 obejmuje wszystkie komponenty w zakresie, także te zapomniane.

❌ Ignorowanie raportu o nieudanym uwierzytelnieniu – skan uwierzytelniony, który zalogował się na 60 % hostów, jest w 40 % skanem nieuwierzytelnionym; „czysty” wynik jest wtedy artefaktem, nie dowodem.

❌ Traktowanie CVSS jako jedynego kryterium – setki pozycji „krytycznych” bez EPSS i KEV paraliżują zespół; wymóg 11.3.1.1 PCI DSS wprost przewiduje analizę ryzyka dla podatności niższych.

❌ Zamykanie podatności bez ponownego skanu – ticket „wdrożono poprawkę” nie jest dowodem; PCI DSS 11.3.1 wymaga ponownego skanu potwierdzającego usunięcie, a RTS DORA art. 10 – monitorowania i weryfikacji remediacji.

❌ Skan ASV traktowany jako jedyny skan zewnętrzny – ASV co kwartał to minimum dla dowodu zgodności; między skanami perymetr pozostaje bez monitoringu przez 90 dni.

❌ Wykluczanie systemów „wrażliwych” ze skanu na stałe – zamiast wykluczenia: okna czasowe, ograniczenie równoległości, skan agentowy lub pasywny; wyjątek na stałe wymaga udokumentowanej akceptacji ryzyka i daty przeglądu.

Checklist audytora – co sprawdzi QSA lub audytor ISO 27001 w obszarze skanów podatności?

1. Czy istnieje udokumentowana procedura zarządzania podatnościami z częstotliwością skanów, kryteriami priorytetyzacji i terminami remediacji?
2. Czy zakres skanów pokrywa wszystkie aktywa w zakresie audytu (porównanie listy hostów ze skanu z rejestrem aktywów i diagramem sieci)?
3. Czy skany wewnętrzne są uwierzytelnione i czy istnieje raport powodzenia uwierzytelnienia dla każdego skanu?
4. Czy z ostatnich 12 miesięcy istnieją cztery kwartalne skany wewnętrzne i cztery raporty ASV z wynikiem pozytywnym (PCI DSS)?
5. Czy dla każdej podatności wysokiej lub krytycznej istnieje ponowny skan potwierdzający usunięcie?
6. Czy istnieją skany wykonane po istotnych zmianach i czy definicja „istotnej zmiany” jest zapisana w procedurze?
7. Czy podatności niższe niż wysokie są zarządzane na podstawie udokumentowanej analizy ryzyka (PCI DSS 12.3.1)?
8. Czy konta skanujące podlegają zarządzaniu kontami uprzywilejowanymi (rotacja haseł, logowanie dostępu)?
9. Czy wyjątki i akceptacje ryzyka mają właściciela, uzasadnienie i datę przeglądu?
10. Czy zarząd otrzymuje raport trendów (liczba otwartych podatności, MTTR, odsetek w SLA)?

---

FAQ – najczęstsze pytania o skany podatności infrastruktury

---

Warto przeczytać

1. Metody testowania bezpieczeństwa IT – jak skany, pentesty i red teaming układają się w kompletny program testów.
2. Skany podatności aplikacji – DAST, SAST, SCA, IaC i kontenery.
3. Skany podatności a wymogi compliance – mapowanie DORA, NIS2, CRA, PCI DSS, ISO 27001, SOC 2.
4. Zakres PCI DSS, CDE i segmentacja – jak zakres CDE determinuje listę hostów do skanowania.
5. Cyber Resilience Act – obowiązek zgłaszania podatności od 11 wrz 2026 – jak wyniki skanów zasilają obowiązki producentów oprogramowania.

---

Skany podatności infrastruktury – konsultacja

Patronusec realizuje skany wewnętrzne, zewnętrzne i ASV, konfigurując zakres i uwierzytelnienie tak, aby raporty spełniały wymogi audytu PCI DSS i DORA. Jeśli chcesz zweryfikować, czy Twój obecny program skanów przejdzie audyt, umów bezpłatną rozmowę.

Skany podatności | Skanowanie ASV | Testy penetracyjne

---