Wprowadzenie do problemu / definicja
Nowe ustalenia firmy Armadin pokazują, że wiele organizacji nadal opiera ocenę ryzyka głównie na biuletynach producentów, identyfikatorach CVE i klasycznych skanerach podatności. Taki model pozostawia jednak znaczną część realnej ekspozycji poza polem widzenia zespołów bezpieczeństwa.
Problem dotyczy przede wszystkim błędów w oprogramowaniu tworzonym wewnętrznie, niebezpiecznych konfiguracji, nadmiernych uprawnień oraz ujawnionych sekretów. Są to słabości, które często nie trafiają do publicznych advisory, ale mogą prowadzić do szybkiej kompromitacji środowiska.
W skrócie
Armadin poinformował, że 88% krytycznych i wysokich usterek wykrytych w 2026 roku podczas testów bezpieczeństwa w środowiskach klientów nie zostałoby zidentyfikowanych wyłącznie na podstawie komunikatów producentów. To mocny sygnał, że tradycyjne programy vulnerability management nie odzwierciedlają pełnej skali zagrożeń.
- Duża część najpoważniejszych problemów dotyczyła autorskiego oprogramowania klientów.
- Wiele skutecznych ścieżek ataku rozpoczynało się bez uwierzytelnienia.
- Istotną rolę odgrywały ujawnione poświadczenia kont usługowych i aplikacyjnych.
- Łańcuchy prowadzące do krytycznego efektu często wymagały zaledwie kilku kroków.
Kontekst / historia
Przez lata zarządzanie podatnościami było budowane wokół znanych źródeł informacji: baz CVE, biuletynów dostawców, skanerów zgodności i okresowych testów. Ten model sprawdza się dobrze wtedy, gdy zagrożenie dotyczy powszechnie używanego produktu i ma już formalny opis.
Współczesna powierzchnia ataku wygląda jednak inaczej. Coraz większe znaczenie mają aplikacje biznesowe tworzone na zamówienie, niestandardowe integracje, publicznie wystawione interfejsy administracyjne, błędne wdrożenia oraz sekrety pozostawione w repozytoriach, logach, backupach i plikach konfiguracyjnych.
W efekcie organizacja może mieć dojrzały proces łatania znanych CVE, a jednocześnie pozostawać podatna na ataki wykorzystujące słabości specyficzne wyłącznie dla jej środowiska. Właśnie ten rozdźwięk podkreślają dane przedstawione przez Armadin.
Analiza techniczna
Z udostępnionych informacji wynika, że 67% krytycznych usterek oraz 78% usterek wysokiego ryzyka, które pozostawały poza advisory, dotyczyło oprogramowania napisanego przez samych klientów. To oznacza, że znaczna część realnej ekspozycji nie jest objęta klasycznym mapowaniem wersji produktów do znanych podatności.
Drugą ważną kategorią były wdrożenia produktów dostawców wykonane w sposób stwarzający ryzyko, mimo braku bezpośredniego odniesienia do publicznego biuletynu. Chodzi między innymi o panele administracyjne dostępne z internetu, niewłaściwie zabezpieczone interfejsy zarządzania, zbyt szerokie uprawnienia procesów usługowych czy niebezpieczne ścieżki integracyjne.
Na uwagę zasługuje również charakter łańcuchów ataku. Blisko 70% krytycznych i wysokich usterek znajdowało się na nieuwierzytelnionej powierzchni ataku. Dodatkowo 82% udokumentowanych ścieżek rozpoczynało się bez poświadczeń, a ponad połowa przebiegała dalej bez użycia hasła lub klucza na żadnym etapie.
Szczególnie groźnym elementem okazały się ujawnione sekrety. Niemal połowa łańcuchów startujących bez uwierzytelnienia wykorzystywała odsłonięte poświadczenia, z czego 71% należało do aplikacji lub kont usługowych. Tego typu tożsamości są często uprzywilejowane, trwałe i słabiej monitorowane niż konta użytkowników, co zwiększa ich wartość operacyjną dla napastnika.
Armadin wskazał także, że w ponad 70% badanych środowisk osiągnięcie krytycznego efektu było możliwe w trzech krokach lub mniej bez ważnych poświadczeń. Z perspektywy bezpieczeństwa ofensywnego oznacza to niski koszt ataku i wysoką skuteczność łączenia kilku pozornie drobnych błędów w jedną skuteczną ścieżkę kompromitacji.
Konsekwencje / ryzyko
Najważniejszy wniosek jest prosty: sprawny patch management nie gwarantuje rzeczywistej odporności organizacji. Nawet terminowe wdrażanie poprawek nie ochroni firmy przed błędami w kodzie własnym, wyciekiem sekretów czy ryzykowną ekspozycją usług administracyjnych.
Ryzyko rośnie szczególnie tam, gdzie rozwój aplikacji przebiega szybko, konta usługowe mają szerokie uprawnienia, sekrety są przechowywane poza dedykowanymi systemami zarządzania, a ekspozycja oceniana jest głównie przez pryzmat listy CVE.
- Wysokie ryzyko przejęcia środowiska mimo aktualnych systemów.
- Większa podatność na ataki bez użycia legalnych danych dostępowych.
- Trudności w wykryciu ścieżek eskalacji opartych na błędach logicznych i operacyjnych.
- Fałszywe poczucie bezpieczeństwa wynikające z koncentracji wyłącznie na advisory.
Istotne jest też to, że znaczna część najpoważniejszych problemów może zostać usunięta bez oczekiwania na działania producenta. Oznacza to, że barierą często nie jest brak poprawki, lecz brak widoczności i testów odwzorowujących sposób działania rzeczywistego atakującego.
Rekomendacje
Organizacje powinny rozszerzyć program zarządzania podatnościami poza tradycyjne biuletyny i skanowanie zgodności. Potrzebne jest podejście, które uwzględnia rzeczywistą powierzchnię ataku, błędy logiczne i możliwość łańcuchowania kilku słabości.
- Regularnie testować aplikacje własne pod kątem logiki biznesowej, integracji i ścieżek eskalacji.
- Wdrożyć pełny program ochrony sekretów obejmujący repozytoria, pipeline’y CI/CD, logi, backupy i konfiguracje.
- Rotować poświadczenia kont usługowych oraz ograniczać ich uprawnienia zgodnie z zasadą najmniejszych przywilejów.
- Usunąć publiczną ekspozycję paneli administracyjnych, endpointów debugowania i interfejsów zarządzania.
- Traktować konta aplikacyjne i usługowe jak tożsamości uprzywilejowane, z pełną inwentaryzacją i monitoringiem użycia.
- Analizować pełne łańcuchy ataku, a nie tylko pojedyncze wskaźniki ryzyka.
W praktyce oznacza to bliższą współpracę zespołów SOC, AppSec, DevSecOps i administracji infrastruktury. Dopiero połączenie widoczności, testów ofensywnych i kontroli tożsamości technicznych daje szansę na ograniczenie tego typu ekspozycji.
Podsumowanie
Dane Armadin pokazują wyraźnie, że największe zagrożenia dla przedsiębiorstw coraz częściej nie wynikają z publicznie opisanych luk, lecz z błędów osadzonych bezpośrednio w środowisku ofiary. Oprogramowanie własne, błędne wdrożenia, ujawnione sekrety i nadmiernie uprzywilejowane konta usługowe tworzą warunki do szybkiej kompromitacji.
Dla zespołów cyberbezpieczeństwa to sygnał, że samo śledzenie advisory i łatanie CVE nie wystarcza. Skuteczna obrona wymaga ciągłego testowania realnej powierzchni ataku, kontroli ekspozycji sekretów oraz traktowania konfiguracji i autorskiego kodu jako kluczowych obszarów ryzyka.
Źródła
- Infosecurity Magazine – Armadin Tests Find 88% of Severe Flaws Outside Vendor Advisories
https://www.infosecurity-magazine.com/news/armadin-severe-exposures-missed/ - CyberBreachNet – Armadin Tests Find 88% of Severe Flaws Outside Vendor Advisories
https://www.cyberbreachnet.com/news/armadin-tests-find-88-of-severe-flaws-outside-vendor-advisories - Armadin – Beyond Cairn: The Glass Houses of AI Attackers
https://www.armadin.com/blog-posts/beyond-cairn-the-glass-houses-of-ai-attackers