Tag: DevSecOps

Wprowadzenie do problemu

OWASP zwraca uwagę na rosnące zagrożenia związane ze skillami agentów AI, czyli rozszerzeniami definiującymi zadania, reguły działania, zależności oraz sposób korzystania z narzędzi i zewnętrznych źródeł danych. To właśnie te komponenty zwiększają możliwości agentów, ale jednocześnie tworzą nową i często słabo kontrolowaną powierzchnię ataku.

W odpowiedzi na ten problem organizacja opublikowała finalną listę Agentic Skills Top 10 oraz zaproponowała Universal Agentic Skill Format v1.0. Celem inicjatywy jest uporządkowanie zasad opisu, weryfikacji i oceny bezpieczeństwa rozszerzeń wykorzystywanych przez agentów AI.

W skrócie

• OWASP opublikował listę najważniejszych ryzyk bezpieczeństwa dla skills agentów AI.
• Na czele zagrożeń znalazły się złośliwe skills oraz kompromitacja łańcucha dostaw.
• Równolegle zaprezentowano Universal Agentic Skill Format v1.0 oparty na YAML.
• Nowy format ma ułatwić walidację pochodzenia, uprawnień, zależności, integralności i historii zmian.
• Inicjatywa ma pomóc zespołom AppSec, DevSecOps i governance traktować skills jak pełnoprawne komponenty wysokiego ryzyka.

Kontekst i historia

Ekosystem agentów AI rozwija się bardzo szybko, a wraz z nim rośnie liczba gotowych skills dostępnych w repozytoriach i na platformach integracyjnych. Dla organizacji to wygodny sposób rozszerzania możliwości agentów, ale historia bezpieczeństwa oprogramowania pokazuje, że szybka adopcja komponentów zewnętrznych zwykle wyprzedza dojrzałe mechanizmy kontroli.

W praktyce sytuacja zaczyna przypominać wcześniejsze problemy znane z pakietów open source, marketplace’ów rozszerzeń oraz ataków supply chain. Napastnicy mogą podszywać się pod wiarygodne źródła, publikować spreparowane pakiety lub przejmować zależności, które następnie trafiają do środowisk produkcyjnych. W przypadku agentów AI skala ryzyka jest szczególna, ponieważ agent może działać autonomicznie, korzystać z poświadczeń, przetwarzać dane wrażliwe i wykonywać operacje bez każdorazowej akceptacji człowieka.

Dlatego OWASP potraktował warstwę skills jako odrębny obszar bezpieczeństwa. To wyraźny sygnał, że rozszerzenia agentowe powinny podlegać podobnym procedurom kontroli jak kod, biblioteki, kontenery czy artefakty CI/CD.

Analiza techniczna

Skill pełni rolę nośnika instrukcji dla agenta. Może zawierać opis zadań w języku naturalnym, odwołania do kodu, konfigurację uprawnień, zależności, adresy usług, a także wskazania do pobierania treści z zasobów zewnętrznych. Taka elastyczność jest korzystna funkcjonalnie, ale jednocześnie otwiera drogę do wielu klas nadużyć.

Najpoważniejszym zagrożeniem są złośliwe skills, które wyglądają jak legalne rozszerzenia, lecz w rzeczywistości zawierają ukryte instrukcje prowadzące do eksfiltracji danych, pobierania dodatkowych komponentów, obchodzenia polityk bezpieczeństwa albo manipulowania przebiegiem workflow. Agent może potraktować taki komponent jako zaufany, mimo że wykonuje on wrogą logikę.

Drugim kluczowym problemem jest kompromitacja łańcucha dostaw. Skill może odwoływać się do repozytoriów, bibliotek, serwerów narzędziowych, plików konfiguracyjnych lub zdalnych instrukcji znajdujących się poza głównym artefaktem. Oznacza to, że nawet jeśli sam manifest wygląda bezpiecznie, jego zachowanie może zmienić się po podmianie zależności, przejęciu repozytorium, typosquattingu lub modyfikacji zewnętrznego źródła.

Istotne ryzyko wiąże się także z niezaufanymi zewnętrznymi instrukcjami. Jeśli skill pobiera treść z dokumentu, witryny lub endpointu API, agent może potraktować ją jako element logiki wykonawczej. W razie przejęcia źródła lub wstrzyknięcia złośliwej treści pojawia się ryzyko nieautoryzowanych działań, przypominające połączenie prompt injection, nadużycia zdalnej konfiguracji i dynamicznego ładowania niezweryfikowanych danych.

OWASP proponuje ograniczanie tych zagrożeń poprzez Universal Agentic Skill Format v1.0. Ustandaryzowany format ma obejmować metadane dotyczące pochodzenia, wymaganych uprawnień, zależności, integralności, podpisów, sum kontrolnych oraz historii zmian. Dzięki temu narzędzia bezpieczeństwa mogłyby automatycznie analizować, czy dany skill jest spójny, czy wymaga zbyt szerokich uprawnień i czy nie korzysta z nieautoryzowanych zasobów.

Konsekwencje i ryzyko

Dla organizacji problem nie kończy się na pojedynczym złośliwym rozszerzeniu. Skills mogą stać się nowym kanałem wejścia do środowiska firmowego, szczególnie tam, gdzie agenci mają dostęp do poczty, systemów SaaS, repozytoriów kodu, narzędzi developerskich oraz zasobów chmurowych.

• kradzież poświadczeń, tokenów API i danych sesyjnych,
• wyciek danych wrażliwych przetwarzanych przez agenta,
• wykonywanie nieautoryzowanych działań w imieniu użytkownika lub organizacji,
• eskalacja uprawnień przez nadmiernie uprzywilejowane skills,
• utrudniona analiza incydentów z powodu rozproszonego modelu zależności i instrukcji.

Dodatkowym wyzwaniem jest brak pełnej widoczności. W wielu firmach nie istnieje jeszcze centralny rejestr agentów, ich konfiguracji i używanych skills. To oznacza, że po ujawnieniu zagrożenia organizacja może mieć problem z szybkim ustaleniem, czy dany komponent został wdrożony i gdzie należy go natychmiast wyłączyć.

Rekomendacje

Organizacje wdrażające agentów AI powinny traktować skills jak komponenty wysokiego ryzyka i objąć je pełnym cyklem kontroli bezpieczeństwa. Dotyczy to zarówno etapu dopuszczania do użycia, jak i monitorowania działania w środowisku produkcyjnym.

• wprowadzenie inwentaryzacji agentów, skills i powiązanych zależności,
• dopuszczanie wyłącznie zweryfikowanych i podpisanych rozszerzeń,
• egzekwowanie zasady najmniejszych uprawnień,
• ograniczanie dynamicznego pobierania instrukcji z niezaufanych źródeł,
• skanowanie skills pod kątem integralności, reputacji źródła i nietypowych uprawnień,
• monitorowanie połączeń do zewnętrznych domen, repozytoriów i serwerów narzędziowych,
• segmentacja środowisk agentowych oraz separacja sekretów i danych,
• przygotowanie procedur szybkiego odcięcia złośliwego skillu w całej organizacji.

Z perspektywy architektury ważne jest także rozdzielenie instrukcji użytkownika, logiki skillu i treści pobieranych z zewnętrznych źródeł. Pomocne będą również versioning, podpisywanie manifestów oraz utrzymywanie listy dozwolonych źródeł i zależności.

Podsumowanie

Publikacja Agentic Skills Top 10 oraz Universal Agentic Skill Format v1.0 pokazuje, że bezpieczeństwo agentów AI obejmuje już nie tylko modele, prompty i API, ale również warstwę rozszerzeń wykonawczych. Skills stają się nowym elementem łańcucha zaufania, a jednocześnie potencjalnym wektorem ataku o wysokim wpływie na dane, tożsamość i procesy biznesowe.

Dla zespołów bezpieczeństwa to sygnał, że zarządzanie skillami powinno zostać włączone do standardowych praktyk AppSec i DevSecOps. Im szybciej organizacje wdrożą kontrolę pochodzenia, integralności i uprawnień takich komponentów, tym większa szansa na ograniczenie nowej klasy incydentów w środowiskach AI.

Źródła

1. https://www.darkreading.com/application-security/owasp-flags-top-ai-skill-risks-security-blueprint
2. https://owasp.org/www-project-agentic-skills-top-10/
3. https://owasp.org/www-project-agentic-skills-top-10/universal-skill-format.html
4. https://github.com/OWASP/www-project-agentic-skills-top-10

Wprowadzenie do problemu / definicja

MLflow, popularna platforma open source wykorzystywana do zarządzania cyklem życia modeli uczenia maszynowego, znalazła się w centrum poważnego incydentu bezpieczeństwa. Chodzi o krytyczną podatność typu SSRF, która pozwala napastnikowi wymuszać żądania HTTP z poziomu serwera MLflow do zasobów wewnętrznych, w tym usług metadanych środowisk chmurowych.

W praktyce oznacza to, że błędnie wystawiony serwer MLflow może stać się pomostem do pozyskania wrażliwych danych, takich jak tokeny tymczasowe, sekrety aplikacyjne czy poświadczenia dostępu do usług chmurowych. To szczególnie niebezpieczne w środowiskach MLOps, gdzie jedna instancja często komunikuje się z wieloma krytycznymi komponentami infrastruktury.

W skrócie

Podatność oznaczono jako CVE-2026-64849, a jej ocena CVSS 9.3 wskazuje na bardzo wysoki poziom ryzyka. Problem dotyczy domyślnej konfiguracji MLflow Tracking Server, w której interfejs webhooków rejestru modeli może być dostępny bez odpowiedniego uwierzytelniania.

• atak umożliwia realizację SSRF z poziomu serwera MLflow,
• celem mogą być usługi metadanych chmurowych i inne zasoby wewnętrzne,
• zagrożone są wersje MLflow wcześniejsze niż 3.15.0,
• podatność była wykorzystywana aktywnie krótko po ujawnieniu.

Kontekst / historia

MLflow od lat jest jednym z kluczowych narzędzi wykorzystywanych w projektach związanych z MLOps. Służy do śledzenia eksperymentów, rejestrowania modeli, zarządzania artefaktami oraz wspierania wdrożeń w środowiskach produkcyjnych. Wraz ze wzrostem znaczenia rozwiązań AI rośnie także atrakcyjność takich platform dla cyberprzestępców.

W tym przypadku źródłem problemu okazała się architektura serwera śledzącego i możliwość ekspozycji API webhooków bez skutecznej kontroli dostępu. Dodatkowo wcześniejsze mechanizmy ograniczające SSRF nie zapewniły pełnej ochrony, ponieważ logika aplikacji nadal mogła zwracać odpowiedzi z odpytywanych zasobów wewnętrznych. To pokazuje, że częściowe zabezpieczenia są niewystarczające, jeśli podstawowy model zaufania pozostaje błędny.

Analiza techniczna

Istota podatności sprowadza się do nieautoryzowanego SSRF w MLflow Tracking Server. Atakujący może inicjować żądania do określonych endpointów aplikacji, a następnie skłonić serwer do nawiązania połączenia z wybranym adresem HTTP. Jeżeli serwer ma dostęp do sieci wewnętrznej lub usług dostawcy chmury, otwiera to drogę do pozyskania danych, które nie powinny być dostępne z Internetu.

Najgroźniejszy scenariusz dotyczy środowisk chmurowych. W takich wdrożeniach serwer MLflow może mieć dostęp do endpointów metadanych, z których da się pobrać informacje o instancji, tokeny sesyjne, dane kont serwisowych lub inne sekrety związane z tożsamością maszyny. Jeżeli aplikacja zwraca treść odpowiedzi do atakującego, luka przestaje być wyłącznie problemem sieciowym i staje się bezpośrednim narzędziem eksfiltracji danych.

Technicznie podatność łączy trzy niebezpieczne cechy:

• brak wymaganego uwierzytelniania dla wrażliwego API,
• możliwość generowania żądań do arbitralnych adresów,
• zwracanie odpowiedzi z zasobów wewnętrznych do inicjującego żądanie.

W efekcie publicznie dostępna instancja MLflow może zostać użyta jako pośrednik do komunikacji z systemami, które normalnie pozostają odseparowane od sieci zewnętrznej. W środowiskach MLOps konsekwencje są szczególnie poważne, ponieważ host MLflow bywa zintegrowany z magazynami obiektów, bazami danych, pipeline’ami CI/CD, rejestrami modeli i usługami inferencyjnymi.

Konsekwencje / ryzyko

Najpoważniejszym skutkiem wykorzystania luki jest przejęcie poświadczeń chmurowych i dalsze poruszanie się po infrastrukturze organizacji. Kradzież tokenów tymczasowych może umożliwić dostęp do danych, zmianę konfiguracji usług oraz rozwinięcie ataku na kolejne systemy.

• odczyt lub modyfikacja danych w magazynach obiektowych,
• dostęp do rejestrów modeli, artefaktów i danych treningowych,
• eskalacja uprawnień w środowisku chmurowym,
• ruch lateralny między usługami i komponentami MLOps,
• eksfiltracja sekretów aplikacyjnych i informacji operacyjnych.

Ryzyko nie ogranicza się do samego MLflow. Kompromitacja tej warstwy może prowadzić do manipulacji pipeline’ami danych, podmiany modeli, zatrucia procesów wdrożeniowych oraz naruszenia integralności wyników generowanych przez systemy AI. Dla organizacji oznacza to zagrożenia operacyjne, finansowe, regulacyjne i reputacyjne.

Rekomendacje

Organizacje korzystające z MLflow powinny potraktować tę podatność priorytetowo. Pierwszym krokiem powinno być szybkie ustalenie, które instancje są publicznie dostępne oraz czy działają w podatnych wersjach oprogramowania. Sama aktualizacja jest konieczna, ale nie powinna być jedynym działaniem obronnym.

• zaktualizować MLflow do wersji 3.15.0 lub nowszej,
• usunąć publiczną ekspozycję serwera lub umieścić go za warstwą uwierzytelniania,
• ograniczyć lub zablokować dostęp do usług metadanych chmurowych, jeśli nie jest niezbędny,
• wdrożyć filtrowanie ruchu wychodzącego, zwłaszcza do adresów wewnętrznych i wrażliwych endpointów,
• przeanalizować logi aplikacyjne, sieciowe i chmurowe pod kątem nietypowych żądań HTTP,
• przeprowadzić rotację poświadczeń i sekretów w przypadku podejrzenia ujawnienia,
• zweryfikować uprawnienia ról przypisanych instancjom zgodnie z zasadą najmniejszych uprawnień,
• objąć webhooki i nietypowe wywołania API dodatkowymi regułami monitoringu.

Z perspektywy bezpieczeństwa architektury warto traktować platformy AI i MLOps tak samo jak inne systemy krytyczne dla biznesu. Oznacza to konieczność segmentacji sieci, silnego IAM, pełnego uwierzytelniania interfejsów administracyjnych oraz regularnych przeglądów powierzchni ataku.

Podsumowanie

CVE-2026-64849 to przykład podatności, która z pozoru dotyczy pojedynczego mechanizmu aplikacyjnego, ale w praktyce może prowadzić do przejęcia zasobów chmurowych i dalszej kompromitacji całego środowiska. Dla zespołów bezpieczeństwa, DevOps i DevSecOps kluczowe jest szybkie wdrożenie poprawek, ograniczenie ekspozycji MLflow oraz sprawdzenie, czy infrastruktura nie została już wykorzystana przez napastników.

Źródła

1. SecurityWeek – MLflow Vulnerability Exploited for Cloud Credential Theft
   https://www.securityweek.com/mlflow-vulnerability-exploited-for-cloud-credential-theft/
2. CVE Record – CVE-2026-64849
   https://www.cve.org/CVERecord?id=CVE-2026-64849
3. MLflow Security Advisories
   https://github.com/mlflow/mlflow/security
4. CISA Known Exploited Vulnerabilities Catalog
   https://www.cisa.gov/known-exploited-vulnerabilities-catalog