Testy penetracyjne · Łódź
Testy penetracyjne dla firm z Łodzi i województwa łódzkiego prowadzi zespół Innovix z Wrocławia. Sprawdzamy systemy operatorów logistycznych, którzy w jednym portalu obsługują wielu zleceniodawców, narzędzia centrów back office pracujących dla banków, aplikacje i chmurę producentów urządzeń sterowanych z telefonu oraz portale pacjentów. Aplikacje i API testujemy zdalnie, a na test sieci wewnętrznej przyjeżdżamy do Łodzi - jako pojedynczy pentest albo część szerszego audytu bezpieczeństwa IT.
01Logistyka i fulfillment
Województwo łódzkie ma 5,19 mln m² nowoczesnych magazynów - czwarty zasób w kraju - a w I półroczu 2026 r. najemcy wynajęli tu 343,5 tys. m², drugi wynik po Śląsku. W całej Polsce operatorzy logistyczni 3PL odpowiadali w tym czasie za ok. jedną czwartą wolumenu najmu (Cushman & Wakefield, II kw. 2026).
Operator logistyczny obsługuje w jednym systemie magazynowym i jednym portalu wielu zleceniodawców: sklepy, producentów, dystrybutorów. Błąd uprawnień w takim systemie nie ujawnia danych jednej firmy, tylko wszystkich, które powierzyły magazynowi towar. Dlatego test prowadzimy z kontami co najmniej dwóch zleceniodawców i każdej roli magazynu, a sprawdzamy przede wszystkim:
Szczegóły metodyki: testy API dla integracji ze sklepami i przewoźnikami oraz testy aplikacji mobilnych dla terminali i aplikacji kierowców. Jeśli portal powstał na zamówienie, błędy w logice uprawnień najszybciej pokaże audyt kodu (white box).
02Centra usług dla banków
W I kwartale 2026 r. sektor bankowy odpowiadał za 55% wolumenu najmu biur w Łodzi (Knight Frank). Jeśli Twoje centrum pracuje dla banku, tak testujemy narzędzia, w których operatorzy obsługują sprawy jego klientów.
Aplikacje, w których operatorzy prowadzą sprawy klientów banku, nie muszą być dostępne z internetu, żeby wymagały testu: to w nich pracownik widzi dane tysięcy klientów i może zmieniać ich ustawienia. W takich narzędziach sprawdzamy:
Zakres i okna czasowe ustalamy z działem bezpieczeństwa banku, bo to bank jest właścicielem systemu i to jego program testowania obejmuje systemy wspierające krytyczne lub istotne funkcje. Centrum, które z systemu korzysta, dostaje raport w zakresie, o którym decyduje bank.
Jak testy wchodzą do programu testowania operacyjnej odporności cyfrowej z art. 24 rozporządzenia (UE) 2022/2554 w sprawie operacyjnej odporności cyfrowej sektora finansowego (DORA), opisujemy na stronie testów penetracyjnych dla finansów i ubezpieczeń oraz na stronie testów penetracyjnych w Warszawie. Socjotechniki i kampanii phishingowych nie prowadzimy - sprawdzamy za to, co zrobi atakujący, który przejmie hasło jednego operatora.
03Producenci i CRA
Wśród wiodących sektorów Łódzkiej Specjalnej Strefy Ekonomicznej PAIH wymienia AGD, przemysł spożywczy, przetwórstwo tworzyw sztucznych, branżę kosmetyczno-farmaceutyczną, maszynową oraz IT/BPO.
Od 11 września 2026 r. producenci produktów z elementami cyfrowymi muszą - na podstawie aktu o cyberodporności (Cyber Resilience Act, CRA, rozporządzenie (UE) 2024/2847) - zgłaszać aktywnie wykorzystywane podatności i poważne incydenty: wczesne ostrzeżenie w ciągu 24 godzin od uzyskania informacji, pełne zgłoszenie w ciągu 72 godzin - przez platformę ENISA do CSIRT państwa głównej siedziby producenta. Główne obowiązki CRA stosuje się od 11 grudnia 2027 r., a wśród objętych nim produktów Komisja Europejska wymienia wprost sprzęt AGD i aplikacje mobilne. Jak CRA ma się do ustawy o KSC w zakładach produkcyjnych, opisujemy na stronie NIS2 w produkcji.
Dla producenta urządzeń sterowanych z telefonu oznacza to pytanie: kto pierwszy znajdzie podatność w aplikacji albo w chmurze - zespół producenta czy ktoś, kto już ją wykorzystuje. W teście sprawdzamy:
Producentom żywności i kosmetyków ze strefy, którzy nie sprzedają urządzeń z aplikacją, zwykle bliżej do testu portalu dla dystrybutorów, sklepu internetowego marki albo perymetru zakładu - zakresy opisujemy na stronach testów aplikacji webowych i testów infrastruktury i sieci.
04Ochrona zdrowia
Uniwersytet Medyczny w Łodzi prowadzi trzy szpitale uniwersyteckie, a w regionie działają też szpitale publiczne i niepubliczne placówki medyczne obsługujące pacjentów przez internet.
Szpital kliniczny łączy leczenie, dydaktykę i badania, więc z jego systemów korzystają pacjenci, lekarze, studenci i firmy serwisujące aparaturę. W takim środowisku proponujemy zacząć od:
Urządzenia medyczne wyłączamy z aktywnych testów, a podatność potwierdzamy minimalnym dowodem - najlepiej na kontach testowych. Zakres dla placówek medycznych, laboratoriów i ich dostawców opisuje strona testów bezpieczeństwa systemów medycznych, a obowiązki szpitali z ustawy o KSC - strona NIS2 i KSC w szpitalach.
05Przykładowe testy
Scenariusze demonstracyjne pokazujące, jak dopasowujemy zakres - nie są to opisy testów u konkretnych klientów.
Operator 3PL
Duża sieć sklepów pyta, czy jej zamówienia i dane klientów nie będą widoczne dla innych firm w portalu magazynu. Test z kontami dwóch zleceniodawców obejmuje portal, API i import plików, a retest potwierdza poprawki przed startem współpracy.
Centrum back office
Automat zakłada sprawy i zmienia dane kontaktowe klientów. Test pokazuje, że jego konto ma pełne uprawnienia, a hasło leży w pliku konfiguracyjnym na wspólnym serwerze - rekomendacja: osobne role i sejf haseł.
Producent AGD
Przed wprowadzeniem nowej serii na rynek producent zleca test aplikacji, chmury i procesu parowania. Każde ustalenie trafia do jego procesu obsługi podatności, a krytyczne poprawki wchodzą przed pierwszą dostawą.
Szpital
Po migracji do nowego systemu szpital chce wiedzieć, czy pacjenci widzą tylko swoje wyniki i czy stare konta dostawcy wygasły. Test obejmuje portal, aplikację pacjenta i zdalny dostęp serwisu.
Każde ustalenie opisujemy tak jak w przykładowym raporcie z testu penetracyjnego: dowód, ocena CVSS, skutek dla biznesu, rekomendacja i wynik retestu.
06Organizacja testu
Portale, API, aplikacje i chmurę testujemy zdalnie z Wrocławia - wystarczą konta testowe, adresy celów i pisemna zgoda właściciela systemu. Do Łodzi przyjeżdżamy, gdy sieć wewnętrzną trzeba sprawdzić od środka, a dostęp zdalny dla firm zewnętrznych nie wchodzi w grę, gdy test obejmuje kilka hal lub budynków albo gdy wyniki chcesz omówić na miejscu z zarządem i zespołem IT.
Dojazd z Wrocławia samochodem to ok. 225 km, głównie drogą ekspresową S8. Test wewnętrzny w magazynie planujemy w oknie uzgodnionym z kierownikiem zmiany, z osobą, która może go w każdej chwili wstrzymać.
Raport przygotowujemy po polsku i po angielsku - z podsumowaniem dla zarządu, dowodami technicznymi i zalecanymi terminami napraw - a po poprawkach wykonujemy retest. Pierwszą rozmowę prowadzimy online albo w Twojej siedzibie, odpowiadamy w ciągu 24 godzin w dni robocze, a jeśli potrzebujesz umowy o zachowaniu poufności, podpisujemy ją przed omówieniem szczegółów systemu.
W portalu operatora logistycznego wycenę zmienia liczba zleceniodawców i ról, z których kont testujemy, a w teście sieci - liczba hal objętych wizytą; resztę czynników wymienia strona o tym, od czego zależy cena testu. Metodyka i pakiety są opisane na stronie testów penetracyjnych. Gdy potrzebujesz przeglądu kilku obszarów naraz, zacznij od strony audyt bezpieczeństwa IT. Jak pracujemy z firmami spoza Wrocławia, zebraliśmy na stronie obszar działania, a system budowany od zera zaprojektuje nasz software house dla firm z Łodzi.
Sieci firm spoza województwa łódzkiego też testujemy na miejscu - zobacz testy penetracyjne dla firm z Warszawy oraz testy penetracyjne dla firm z Poznania.
Po kolei, według jednego planu wizyty uzgodnionego z działem IT: zaczynamy od hali, w której stoi serwerownia albo węzeł łączący lokalizacje, a potem przechodzimy do kolejnych. W każdej hali kierownik zmiany wskazuje gniazdo sieciowe, porę poza szczytem kompletacji i wysyłek oraz osobę, która przerwie skanowanie, jeśli terminale ręczne zaczną gubić połączenie z WMS. Halę zbyt odległą na ten sam wyjazd obejmujemy połączeniem VPN. Zakres: testy infrastruktury i sieci.
Najlepiej na środowisku testowym, bo każdy przyjęty plik zmienia awizacje i stany w WMS. Potrzebujemy przykładowych plików od każdego zleceniodawcy objętego testem i dostępu do kanału, którym je przesyła - serwera SFTP, API albo formularza w portalu. Sprawdzamy też, jak system reaguje na uszkodzoną strukturę i nadmiarowe pola oraz czy wartość zaczynająca się od znaku równości nie wraca w eksporcie CSV jako formuła arkusza kalkulacyjnego. Metodyka: testy penetracyjne API.
Tak, od strony aplikacji mobilnej, chmury producenta, API i paneli serwisowych - z procesem parowania urządzenia z kontem. Elektroniki i oprogramowania wbudowanego samego urządzenia nie badamy. Raport z retestem pokazuje, które podatności usunięto przed premierą.
Właściciel systemu - zwykle bank. Pisemną zgodę z zakresem i oknami czasowymi uzgadniamy z jego działem bezpieczeństwa, a centrum wskazuje osoby kontaktowe i konta testowe. Bez zgody właściciela systemu testu nie zaczynamy.
Nie. Akt o cyberodporności wymaga od producenta m.in. obsługi podatności i zgłaszania tych aktywnie wykorzystywanych - test jest jednym z dowodów, że produkt sprawdzono, i źródłem listy poprawek z priorytetami. Wymagania produktu i procesy producenta to osobna praca, którą warto zaplanować przed 11 grudnia 2027 r.
Testy penetracyjne · API
Testy bezpieczeństwa API według OWASP API Security Top 10 2023 - autoryzacja obiektów, OAuth 2.0, JWT, GraphQL i webhooki. Raport z dowodami i retestem.
Testy penetracyjne · Aplikacje mobilne
Testy penetracyjne aplikacji mobilnych iOS i Android według OWASP MASVS i MASTG - dane na urządzeniu, komunikacja, uwierzytelnianie i backend API.
Testy penetracyjne · White box
Audyt kodu źródłowego i testy white box - logika autoryzacji, sekrety, kryptografia i zależności z CVE. Ręczny przegląd, SAST i SCA, gotowe poprawki w raporcie.
Opisz krótko, czego potrzebujesz - wrócimy z propozycją kolejnych kroków.
lub zadzwoń pod numer +48 575 621 877