Bezpieczeństwo Magento 2: czemu rdzeń sklepu ma być nudny jak COBOL

Magento to platforma, na której pracuję najczęściej, i niedawno usłyszałem tezę, która brzmi jak prowokacja: Magento to nowy COBOL e-commerce. COBOL to język z lat 60., w którym do dziś działa sporo systemów bankowych. Nikt się nim nie chwali na konferencjach, a mimo to obsługuje pieniądze milionów ludzi każdego dnia.

Im dłużej o niej myślę, tym bardziej się z nią zgadzam. Magento 2 może grać w Waszym sklepie tę samą rolę. Ma pewnie obsługiwać katalog, koszyk, checkout i zamówienia i dostawać łatki bezpieczeństwa na czas. Wszystko, co zmienia się co tydzień, może żyć obok.

Czego banki nauczyły się od COBOL-a

Zacznijmy od liczb. W 2017 roku Reuters szacował, że na świecie działa około 220 miliardów linii kodu w COBOL-u. Pięć lat później badanie zlecone przez Micro Focus naliczyło ponad 800 miliardów linii w codziennym użyciu¹. Komputery typu mainframe, na których ten kod zwykle działa, obsługują według IBM 68% produkcyjnych zadań IT na świecie i 90% transakcji kartami².

Czemu banki tego nie przepiszą? Bo próbowały. W kwietniu 2018 roku brytyjski bank TSB przeniósł klientów na nową platformę. Problemy dotknęły znaczną część z 5,2 miliona klientów, a bank wrócił do normalnej pracy dopiero w grudniu. Regulatorzy nałożyli na TSB 48,65 miliona funtów kary, a klientom wypłacono 32,7 miliona funtów rekompensat⁴. W australijskim Commonwealth Bank wymiana systemu bankowego przeciągnęła się o co najmniej dziewięć miesięcy, a koszt projektu urósł do 1,1 miliarda dolarów australijskich⁵.

Martin Fowler, jeden z najbardziej znanych autorów piszących o architekturze oprogramowania, od 2004 roku opisuje bezpieczniejszą drogę. Stary system zostaje, a nowe funkcje powstają obok niego jako małe części, które stopniowo przejmują kolejne zadania. Skoro te części są małe, ich wprowadzenie niesie niewielkie ryzyko⁶.

Widzicie wspólny mianownik? Stabilny rdzeń, którego nikt nie rusza bez potrzeby, i zmiany wprowadzane na obrzeżach.

Magento 2 jako silnik transakcyjny

Spójrzmy na Magento 2 tymi samymi oczami. Klient przegląda katalog, wkłada produkty do koszyka, płaci i dostaje potwierdzenie zamówienia. Te cztery rzeczy Magento robi od lat, a każdy sklep potrzebuje ich w prawie tej samej postaci.

Na tym rdzeniu da się polegać, bo Adobe dba o niego według jawnych zasad. Każda linia wydań dostaje trzy lata standardowego wsparcia. Wersja 2.4.9 wyszła 12 maja 2026 roku i jest wspierana do 31 maja 2029 roku, a 2.4.8 do 31 maja 2028 roku. Gdy pojawia się luka wykorzystywana już przez przestępców, Adobe wydaje poprawkę dla wszystkich wspieranych wersji³.

Poprawki bezpieczeństwa wychodzą jako osobne, małe łatki, żeby sklepy mogły je zainstalować szybciej, bez czekania na pełne wydanie. Raz w roku, w maju, Adobe publikuje pełny pakiet poprawek dla każdej wspieranej linii⁷. Do tego Magento i Adobe Commerce, w wersji B2C i B2B, są objęte płatnym programem bug bounty, w którym Adobe płaci badaczom za zgłoszone luki⁸.

Właściciel sklepu wie więc, do kiedy jego wersja dostaje łatki, i może zaplanować aktualizację z wyprzedzeniem.

Łatki chronią tylko tych, którzy je instalują

A co się dzieje, gdy łatka jest, ale sklep jej nie instaluje? Ostatnie dwa lata dały na to bolesną odpowiedź. Holenderska firma Sansec, która zawodowo śledzi włamania do sklepów na Magento, opisała każdą z tych historii:

1. 2024, CosmicStingAdobe wydał łatkę w czerwcu. Gdy przestępcy zaczęli masowo skanować sklepy, około 75% z nich wciąż jej nie miało. Do października włamano się do 4275 sklepów, czyli około 5% wszystkich, w tym do sklepów National Geographic i Ray-Ban⁹.
2. 2025, SessionReaperŁatka wyszła 9 września. Sześć tygodni później 62% sklepów nadal jej nie zainstalowało. Masowe ataki dotknęły 49% sklepów, a Sansec szacował, że w 16–18% wszystkich sklepów na Magento przestępcy zostawili tylne drzwi¹⁰.
3. 2026, PolyShellLukę ujawniono 17 marca, a do 14 kwietnia złośliwe pliki trafiły do 82% sklepów. Poprawka weszła do wersji 2.4.9 w maju, a do starszych wspieranych linii dopiero 14 lipca¹¹.
4. 2026, StyleSmugglerLuka z najwyższą możliwą oceną zagrożenia, pozwalająca przejąć sklep bez logowania. Ataki ruszyły 4 września, a Adobe wydał poprawkę dla wersji 2.4.4–2.4.9 już 7 września. Sklepy na wersji 2.4.3 i starszych nie dostały nic¹².

PolyShell pokazuje, że Adobe też bywa wolny, i nie będę udawał, że Magento jest odporne na wszystko. Pozostałe trzy historie mówią jednak to samo. Przestępcy wchodzili przez okno między wydaniem łatki a jej instalacją, a najszerzej otwarte było w sklepach, które czekały tygodniami albo działały na wersji bez wsparcia.

Bezpieczeństwo Magento 2 zależy więc w praktyce od jednej rzeczy: jak szybko Wasz sklep potrafi przyjąć łatkę.

Każdy moduł w rdzeniu to dłuższa droga do łatki

Większość sklepów, które przejmujemy, ma w środku Magento dziesiątki modułów: własne zasady cenowe, promocje, integracje z ERP, eksporty do marketplace’ów, nietypowe statusy zamówień. Każdy z nich działa w tym samym procesie co koszyk i checkout.

Adobe pisze otwarcie, że przegląd własnych modułów to najbardziej czasochłonna i kosztowna część aktualizacji. Zmiany w samym kodzie Magento trzeba przed nią posprzątać¹³. W dokumentacji dla programistów Adobe wyjaśnia też, skąd ten koszt. O modułach działających w tym samym procesie co sklep pisze tak¹⁴:

Wiąże też własny kod z wersją Commerce, środowiskiem PHP i wewnętrznymi interfejsami. Adobe o kodzie działającym wewnątrz sklepu, dokumentacja rozszerzeń Adobe Commerce (tłum. własne)

Pomyślcie o tym przez chwilę. Każda promocja zaszyta w Magento wydłuża drogę od wydania łatki do jej instalacji w Waszym sklepie. Przy SessionReaper ta droga dla większości sklepów trwała ponad sześć tygodni¹⁰.

Nowe pomysły obok rdzenia

Adobe doszedł do tego samego wniosku. W dokumentacji Adobe Commerce rozszerzenia działające poza procesem sklepu są dziś zalecanym punktem wyjścia, zarówno dla nowych aplikacji, jak i przy modernizacji starych. Adobe wymienia ich zalety wprost: bezpieczniejsze aktualizacje, izolację i możliwość wdrażania niezależnie od sklepu¹⁴.

W chmurowej wersji, Adobe Commerce as a Cloud Service, to już zasada. Rozszerzenia działają jako osobne aplikacje, skalują się niezależnie od rdzenia, a programiści mogą je zmieniać bez czekania na nowe wydanie platformy¹⁵. Sklep wysyła informacje o zdarzeniach, na przykład o złożonym zamówieniu, a zewnętrzna aplikacja reaguje na nie i pobiera potrzebne dane przez API¹⁶.

Jak to wygląda w praktyce? Oto rzeczy, które dziś zwykle budujemy jako moduły Magento, a które mogą działać jako małe, osobne usługi:

• Ceny B2B. Usługa liczy cenę dla klienta hurtowego według jego umowy i zwraca ją do sklepu. Zmiana cennika nie dotyka koszyka.
• Promocje. Reguły kampanii żyją w osobnej usłudze, którą marketing może zmieniać częściej niż raz na sprint.
• Integracja z ERP. Po zdarzeniu „złożono zamówienie” usługa przekazuje je do ERP, a stany magazynowe i ceny wracają do Magento przez API. Awaria ERP nie zatrzymuje checkoutu.
• Marketplace. Eksport ofert i import zamówień z platform sprzedażowych działa obok sklepu, w swoim tempie.
• Obieg zamówień. Zatwierdzanie, powiadomienia i przekazanie do magazynu reagują na zmiany statusu zamówienia.

Rdzeń sklepu obsługuje wtedy samą sprzedaż, a przy jego aktualizacji trzeba sprawdzić dużo mniej kodu. Podobnie pracujemy już przy sklepie .mdd, producenta mebli biurowych: obok Magento działa tam własny checkout na React i Node.js, a my dbamy o wymianę danych między sklepem, ERP, SAP i mikroserwisami firmy. Więcej o tym, jak łączymy sklepy z systemami firmy, przeczytacie na stronie integracji z ERP i CRM.

Gdzie wchodzą agenci AI

Raport DORA 2025, oparty na odpowiedziach blisko 5000 osób z branży IT, opisuje AI jako wzmacniacz. Zespoły pracujące na luźno powiązanych systemach z szybką informacją zwrotną zyskują na AI, a te uwiązane do ciasno splecionych systemów i wolnych procesów zyskują niewiele albo nic. Ten sam raport ostrzega, że korzystanie z AI wciąż wiąże się z mniejszą stabilnością wdrożeń¹⁷.

Mała usługa obok Magento to dokładnie ten luźno powiązany system. Ma jedno zadanie, mało kodu i jasną umowę z resztą sklepu. W kontrolowanym eksperymencie GitHuba programiści z asystentem AI napisali niewielki serwer HTTP o 55% szybciej niż bez niego¹⁸. Kiedy METR zmierzył doświadczonych programistów pracujących w dużych, dojrzałych projektach, wyszło odwrotnie: z AI zadania zajmowały im 19% więcej czasu¹⁹. Te badania mierzyły różne rzeczy, ale wskazują ten sam kierunek: AI pomaga najbardziej przy małych, dobrze opisanych zadaniach, a takim zadaniem jest osobna usługa.

Jest też druga strona. Veracode sprawdził kod wygenerowany przez ponad 100 modeli językowych i w 45% próbek znalazł luki bezpieczeństwa²⁰. Dlatego kod od agentów nie powinien trafiać do checkoutu i płatności. W osobnej usłudze z ograniczonymi uprawnieniami ewentualny błąd zostaje w jednym miejscu, a rdzeń sklepu, który obsługuje pieniądze klientów, pozostaje nietknięty.

Zmiana w takiej usłudze może trafić na produkcję w ciągu godzin, bez dotykania Magento i bez czekania na okno wdrożeniowe całego sklepu.

Ile usług to za dużo

Nie namawiam Was do rozbicia sklepu na sto mikroserwisów. W 2023 roku zespół Prime Video opisał, jak przeniósł jedną ze swoich usług monitorujących z wielu małych części z powrotem do jednej aplikacji i obniżył koszt infrastruktury o ponad 90%²¹. Wniosek z tej historii: usługi warto wydzielać według zadań biznesowych, takich jak ceny czy integracja z ERP.

Od tych pytań zaczynamy rozmowę o tym, co wynieść poza Magento:

1. Sprawdź wersję i datę końca wsparcia. Jeśli Wasza linia Magento traci wsparcie w ciągu roku, aktualizacja idzie na pierwsze miejsce, przed każdą nową funkcją³.
2. Spisz moduły w rdzeniu. Przy każdym zapytajcie, czy musi działać w trakcie składania zamówienia. Jeśli nie, jest kandydatem do wyniesienia.
3. Zacznij od tego, co zmienia się najczęściej. Promocje, cenniki i integracje zmieniają się co tydzień, więc najwięcej zyskują na osobnym wdrażaniu.
4. Trzymaj checkout i płatności w rdzeniu. To część, która ma być najstabilniejsza i najlepiej sprawdzona.
5. Łącz usługi przez zdarzenia i API. Usługa nie powinna zmieniać bazy danych Magento bezpośrednio. Wtedy aktualizacja sklepu nie psuje integracji.

Jak pracujemy

W WEGOTCOOKIES programista prowadzi agentów AI i sam czyta oraz zatwierdza każdą ich zmianę. Agenci pracują w odizolowanych środowiskach, nie mają dostępu do środowisk z danymi i nie wykonują żadnych działań na produkcji bez nadzoru programisty. Dzięki temu za tę samą stawkę dostajecie nawet 5× więcej gotowej pracy. Więcej o tym przeczytacie na stronie o pracy z AI, a o samej platformie na stronie Magento 2.

Najlepiej działa to przy stabilnym, łatanym rdzeniu Magento i małych usługach obok niego, które agenci budują szybko, a programista pilnuje ich jakości.

Jeśli zapamiętacie z tego wpisu jedną rzecz, niech to będzie ta: bezpieczny sklep na Magento to taki, który przyjmuje łatkę w kilka dni. Im mniej logiki siedzi w jego rdzeniu, tym łatwiej to osiągnąć, a nowe pomysły mogą rosnąć obok we własnym tempie.