Rozwiązanie
ShieldWave to mój własny produkt. Zaprojektowałem go, zbudowałem i utrzymuję: od strony, na której wpisuje się adres, przez skaner i raporty, po płatności i chmurę. Skan patrzy na stronę tak jak włamywacz, z zewnątrz. Sprawdza osiem obszarów: certyfikat i szyfrowanie, WordPressa z wtyczkami, formularze, pliki zostawione na wierzchu, pocztę wysyłaną z domeny firmy, złośliwy kod, zapomniane subdomeny i porty oraz ochronę, jaką strona daje przeglądarce.
Wynik przychodzi jako raport w trzech warstwach. Na górze jedno zdanie o tym, jak jest, i ocena od 0 do 100. Niżej poprawki ułożone według tego, kiedy się nimi zająć: w tym tygodniu, w tym miesiącu i co może poczekać. Każde ustalenie mówi, co oznacza dla firmy, ile trwa naprawa i kto powinien ją zrobić. Z tego samego skanu powstaje wersja dla właściciela, podsumowanie dla zarządu, raport zgodności z RODO, NIS2, PCI-DSS, ISO 27001, SOC 2, HIPAA i OWASP Top 10 oraz mail do programisty z listą poprawek i dowodami.
Na ekranie raport czyta się w ciemnym motywie, a PDF drukuje się jasno. Czytelnik może to zmienić. Aplikacja, strona i raporty mają oba motywy. Interfejs i raporty są w sześciu językach, także po arabsku, z układem od prawej do lewej. Agencja z planem Enterprise wysyła klientom ten sam raport pod własnym logo i nazwą. Na stronie produktu stoi glob, który pokazuje zwykły dzień zwykłej strony: skąd przychodzą boty i czego szukają. To symulacja typowego ruchu, a strona mówi o tym wprost.
Od 28 września 2026 roku ShieldWave działa też od środka. Wtyczka do WordPressa jest w katalogu WordPress.org jako Ensomedia Security powered by shieldwave.io. Wykonuje 23 kontrole: pliki WordPressa porównane z oficjalnymi sumami kontrolnymi, skan plików strony pod kątem złośliwego kodu, zmienione pliki, wtyczki ze znanymi lukami, kopie wp-config zostawione na wierzchu. Do tego chroni. Blokuje zgadywanie haseł, ukrywa listę nazw użytkowników, dodaje logowanie dwuskładnikowe z aplikacją uwierzytelniającą i jednym przełącznikiem wyłącza edytor plików oraz XML-RPC. Podpisany kanał z shieldwave.io aktualizuje jej reguły, a plik, którego reguły nie potrafią ocenić, może dostać drugą opinię od AI, jeśli właściciel to włączy. Wtyczka mówi do właściciela tak jak raport: jedno zdanie o tym, jak jest, i lista tego, co zrobić.
W tym samym miesiącu cały produkt dostał nowy wygląd. Strona ma nowy pierwszy ekran i menu na telefonie, raport ma jedną ocenę, którą powtarza każda strona, mail i odznaka, a panel nazywa każde ustalenie we wszystkich sześciu językach.
W październiku 2026 roku wiedza produktu stała się żywa. Skaner porównuje to, co znajdzie, z aktualnymi źródłami, a nie z listą zaszytą w kodzie: kanał Wordfence dla wtyczek i motywów WordPressa, wordpress.org dla najnowszych wydań, OSV.dev dla bibliotek JavaScript i frameworków, NVD dla oprogramowania serwera, retire.js dla bibliotek front-endu, lista CISA z lukami wykorzystywanymi w prawdziwych atakach i prawdopodobieństwa exploita EPSS. Serwer odświeża je co godzinę. Gdy pojawia się luka we wtyczce, którą ma podłączona strona, właściciel dowiaduje się o tym w ciągu godziny: mailem, w panelu i z godzinowej kontroli samej wtyczki. W tym samym czasie przebudowałem ocenę. Czysta strona może dostać 100, kontrola, której skan nie zdołał skończyć, jest oznaczona zamiast liczona na niekorzyść strony, a to, co strona celowo wyłączyła, jak XML-RPC, nie jest już zgłaszane jako problem. Pierwsza strona klienta, sklep WooCommerce na hostingu współdzielonym, pokazała, gdzie stara ocena i stare kontrole się myliły.
W pierwszych tygodniach puściłem wtyczkę na prawdziwych stronach WordPress, którymi się opiekuję, i każdy fałszywy alarm stamtąd zamieniłem w poprawkę. Pliki, które po aktualizacji zostały ze starszych wydań WordPressa, pliki indeksu zapisywane przez wtyczkę do migracji, biblioteka JavaScript w płatnym kreatorze stron i pusty debug.log nie są już zgłaszane jako zagrożenia, a rodzina furtek znaleziona na jednym z tych serwerów stała się nową regułą krytyczną. Przed każdym wydaniem wtyczka skanuje stronę testową z 35 popularnymi wtyczkami i 5 motywami i wychodzi dopiero wtedy, gdy nic nie zostaje tam oznaczone przez pomyłkę. Ustalenie mówi teraz, w której wtyczce, motywie albo folderze leży plik i co tam zrobić, z dłuższym wyjaśnieniem i krokami WP-CLI dla programisty. Nieużywane wtyczki można usunąć prosto ze znaleziska, a w sieci witryn wtyczka mówi o całej sieci.
Wersja 1.1.10 zamknęła pełny audyt bezpieczeństwa wtyczki. Ochrona logowania ma teraz limity na adres i na nazwę użytkownika, dziennik zdarzeń pokazuje, gdy ktoś edytował albo usunął jego wpisy, a druga opinia AI usuwa z fragmentu pliku adresy IP, ścieżki na serwerze i ustawienia bazy danych, zanim cokolwiek opuści stronę. Silnik wykrywania przeszedł przez wszystkie 52 800 plików strony testowej bez jednego fałszywego alarmu, a powiadomienia mówią, co się stało i co zrobić, bez straszenia właściciela.
Wersja 1.1.12 dodała to, czego wtyczka wcześniej nie miała: kwarantannę, która przenosi podejrzany plik tam, gdzie nie może się uruchomić, i po przywróceniu oddaje go bez zmian, klucze dostępu (passkeys) jako drugi krok logowania, logowanie dwuskładnikowe wymagane dla ról wybranych przez właściciela, listę sesji, które można zakończyć wszędzie, blokadę PHP w folderze uploads i nagłówki bezpieczeństwa. Każda z tych funkcji jest wyłączona, dopóki właściciel jej nie włączy.
Wersja 1.1.13 to ta, którą przed wydaniem nazwałem doskonałą, i ta, której zażądały strony, którymi się opiekuję. Dzień po 1.1.12 strona klienta nadal pokazywała fałszywe alarmy, każdy z tą samą przyczyną: aktualizacją wtyczki między skanami. Indeks plików zachowuje teraz znacznik oficjalnego pliku przez przejście po aktualizacji, kontrola, która przez trzy wydania kończyła się błędem, znów dochodzi do końca, a surowsze czytanie pliku dotyczy tylko takiego, który wyróżnia się w zweryfikowanej wtyczce. Przed wydaniem silnik przeczytał 147 858 plików z 200 najpopularniejszych wtyczek i sześć reguł zostało zawężonych. Potem siedmiu recenzentów przeszło całą wtyczkę pod kątem typowych klas podatności WordPressa, a 36 ustaleń naprawiłem z testami: od nagłówka proxy, który odwiedzający mógł wybrać za stronę, po nazwę pliku przycinaną w drodze do kwarantanny. Wydanie wyszło dopiero po skanie strony testowej z wtyczkami pięciu prawdziwych stron, aktualizacji wtyczki, wtyczki premium, motywu i rdzenia WordPressa przez FTP i przez WordPressa, i po tym, jak każda kontrola doszła do końca.
W październiku 2026 roku skaner, panel i wtyczka dostały jeden zestaw zasad, spisany, zanim zmienił się kod. Ustalenie wymaga dowodu z samej strony, jego waga wynika z tego, co atakujący może tam zrobić teraz, kontrola, której nie dało się potwierdzić, jest uwagą i nie obniża oceny, a jedna przyczyna widziana przez kilka kontroli to jedno ustalenie. Dwóch recenzentów, którzy nie znali wcześniejszych poprawek, przeszło cały produkt i znalazło to, co nadal łamało te zasady, między innymi słowo w treści strony liczone jako złośliwy kod i słabe ciasteczko, z którego robił się krytyczny łańcuch ataku. Trzeci przegląd szukał tego, co skaner przeoczał: luk z kanału Wordfence dla każdej wtyczki i samego WordPressa, SQL injection ukrytego przez nazwę firewalla na stronie, skryptów ładowanych z hosta z listy złośliwego oprogramowania. Wersja 1.1.17 wtyczki trzyma ocenę nisko, dopóki jest otwarte ustalenie krytyczne, i rozpoznaje backdoory, które zapisują własne pliki PHP. Jej nowe reguły przeczytały 147 858 plików z 200 najpopularniejszych wtyczek i nie oznaczyły żadnego.
