TL; DR
Prawie każdy zespół inżynierów korzysta z asystentów kodowania AI. Prawie żaden nie potrafi zinwentaryzować, jaką sztuczną inteligencję faktycznie obsługuje. Gartner zdefiniował AI Security Posture Management jako kategorię w swoim raporcie Hype Cycle for Data Security z 2025 r., ponieważ luka jest realna: modele, agenci, serwery MCP i zestawy danych są zasobami AI na powierzchni ataku, a większość organizacji nie ma ustrukturyzowanego sposobu, aby je zobaczyć.
Odkrycie bez naprawy to tylko dashboard. Około 40% kodu generowanego przez sztuczną inteligencję zawiera luki w zabezpieczeniach. Asystenci AI odtwarzają niebezpieczne wzorce w ilości, której nie udało się obsłużyć za pomocą ręcznego przeglądu. Wiedza o istniejących zasobach AI rozwiązuje tylko połowę problemu — drugą połowę stanowi ocena ryzyka i naprawa kodu przed jego wysłaniem, w tym samym procesie, w którym został napisany.
Powierzchnia ataku jest szersza niż sam kod. Udokumentowane ataki już wymierzone są w zasoby otaczające kod: ukryty kod Unicode w plikach reguł, który powoduje, że asystenci generują dane wyjściowe z tylnymi drzwiami, zatruwanie narzędzi MCP i pełne zdalne wykonywanie kodu za pośrednictwem powszechnie używanego mostu MCP (ponad 437 000 pobrań) oraz slopsquatting — rejestrowanie nazw pakietów, które modele sztucznej inteligencji statystycznie prawdopodobnie halucynują. Tradycyjne SAST oraz SCA nie widzę nic takiego.
Rozwiązaniem jest jedna pętla, a nie trzy narzędzia punktowe: AI-SPM tworzy inwentarz i AI-BOM; Bezpieczeństwo AI wyniki w porównaniu z OWASP Top 10 dla aplikacji LLM; DevAI naprawia podatny na ataki kod w środowisku IDE w trakcie jego pisania, obejmuje zarówno kod generowany przez sztuczną inteligencję, jak i kod pisany przez ludzi, a także przechwytuje działania innych agentów, zanim oni je zrealizują. Dotyczy to ustaleń pochodzących z własnych skanerów Xygeni oraz wszystkich danych już pozyskanych z istniejących narzędzi — nie ma potrzeby demontażu i wymiany.
Prawie każdy zespół inżynierów wdrożył asystentów kodowania AI. Prawie żaden z nich nie potrafi odpowiedzieć na proste pytanie: z jakich modeli AI, agentów i serwerów MCP faktycznie korzystamy i jakie ryzyko niesie każdy z nich? Ta luka ma już swoją nazwę. Gartner formalnie zdefiniował zarządzanie postawą bezpieczeństwa AI. (AI-SPM) jako kategoria w swoim Cykl hype'u na temat bezpieczeństwa danych w 2025 r. — ta sama linia, która wytworzyła CSPM i DSPM. Kategoria ta istnieje, ponieważ liczby są konkretne: około 40% kodu generowanego przez sztuczną inteligencję zawiera luki w zabezpieczeniach, sztuczna inteligencja jest teraz częścią powierzchni ataku, a nie tylko narzędziem używanym przez programistów, a większość organizacji nie ma ustrukturyzowanego spisu zasobów sztucznej inteligencji, którymi zarządza.
To również temat, który będziemy omawiać na miejscu OWASP AppSec Days Portugalia 2026, 23-24 września w Porto, gdzie Xygeni jest złotym sponsoremWięcej na ten temat na końcu, ale jeśli chcesz pominąć fragment, kup swój bilet tutaj.
Problem: kod generowany przez sztuczną inteligencję ma swój własny profil ryzyka
Około 40% kodu generowanego przez sztuczną inteligencję zawiera luki w zabezpieczeniach. Niezależne badania nad asystentami kodowania AI wykazały stale wysoki wskaźnik awaryjności w przypadku OWASP Top 10, przy czym pewne kategorie błędów, takie jak ataki typu cross-site scripting, pojawiają się w zdecydowanej większości generowanych próbek. Asystenci AI nie tylko piszą kod szybciej. Szybciej też odtwarzają niebezpieczne wzorce, zależności i konfiguracje, i robią to w ilości, której nie udało się obsłużyć żadnym ręcznym procesem weryfikacji.
Powierzchnia ataku nie kończy się na kodzie pisanym przez asystenta. Rozciąga się na zasoby sztucznej inteligencji, którymi Twoje zespoły już zarządzają i rzadko inwentaryzują: modele, zestawy danych, agentów i serwery MCP. Każdy z nich wygenerował już rzeczywiste, udokumentowane ataki:
- Tylne drzwi w pliku zasad: Atakujący ukrywają instrukcje za pomocą niewidocznych znaków Unicode w regułach i plikach konfiguracyjnych odczytywanych przez narzędzia takie jak GitHub Copilot i Cursor, powodując, że asystent emituje kod z ukrytymi drzwiami, nawet o tym nie wspominając. Skatalogowany jako Studium przypadku MITRE ATLAS.
- Zatrucie narzędzia MCP i zdalne wykonywanie kodu: krytyczna luka w zabezpieczeniach powszechnie używanego mostu MCP, pobrana ponad 437 000 razy, umożliwiała pełne zdalne wykonanie kodu w chwili, gdy klient łączył się z niezaufanym serwerem MCP.
- Przysiady: szeroko zakrojone badania naukowe wygenerowały ponad dwa miliony próbek kodu w szesnastu programach LLM i wykazały, że prawie jeden na pięć zalecanych pakietów w ogóle nie istnieje — nazwy, które atakujący mogą zarejestrować i wykorzystać zawczasu jako broń.
Nic z tego nie pojawia się w tradycyjnym SAST or SCA Skanowanie. Te narzędzia rozumieją kod. Nie rozumieją, czym jest model, co robi serwer MCP ani czy plik konfiguracyjny agenta został zmodyfikowany.
Większość zespołów rozwiązuje połowę problemu
Instynktowną reakcją jest przykręcenie narzędzi punktowych: jednego do skanowania modeli, drugiego do szybkich zapór w czasie wykonywania, trzeciego do Asystenci IDETo ten sam błąd, który popełnił AppSec w przypadku SAST, SCAi skanowanie sekretów piętnaście lat temu, a rezultat jest ten sam: fragmentaryczna widoczność, szum alertów i brak jednego miejsca, w którym można by odpowiedzieć na pytanie „jaką sztuczną inteligencję właściwie uruchamiamy i czy jest ona bezpieczna”.
Odkrywanie bez naprawy wskazuje jedynie, gdzie jest problem. Naprawa bez odkrycia oznacza, że naprawiasz kod, podczas gdy serwery Shadow MCP i niezatwierdzeni agenci działają niemonitorowane obok niego. Bezpieczeństwo AI musi obejmować oba te aspekty na tej samej platformie, w przeciwnym razie nie można mówić o zarządzaniu postawą. To… dashboard.
Lepszy sposób: zarządzanie postawą bezpieczeństwa AI, które wykrywa, wykrywa i naprawia
Xygeni Bezpieczeństwo AI zamyka tę pętlę w całej erze sztucznej inteligencji SDLCz modelu i serwera MCP do punktu końcowego programisty.
- Odkryć. AI-SPM tworzy bieżący inwentarz wszystkich zasobów AI w organizacji: modeli, zestawów danych, agentów i serwerów MCP. Dowodzi, że inwentaryzacja z AI-BOM, baza dowodów, o którą coraz częściej pytają audytorzy i organy regulacyjne, niezależnie od tego, czy chodzi o dokumentację techniczną dla systemów wysokiego ryzyka w ramach unijnej ustawy o sztucznej inteligencji, czy też inwentaryzacje aktywów wymagane przez ramy prawne, takie jak hiszpański ENS.
- Wykryć. AI Security ocenia każdy zasób pod kątem rzeczywistego ryzyka: szybkiego wstrzyknięcia, niezabezpieczonych konfiguracji MCP, ujawnienia danych, zgodnie z OWASP Top 10 dla aplikacji LLMWyniki są klasyfikowane, a nie umieszczane w kolejce.
- Naprawiono, w punkcie kod jest napisany. To tutaj generowane przez sztuczną inteligencję code security faktycznie zostaje rozwiązane. Xygeni DevAI Działa jako ciągła warstwa w środowisku IDE, skanując przyrostowo, gdy programiści pracują zarówno z kodem napisanym przez ludzi, jak i generowanym przez sztuczną inteligencję. Przeprowadza agentowe wykrywanie luk w zabezpieczeniach AI, mapuje Ścieżki ataków oparte na sztucznej inteligencji aby pokazać, jak faktycznie można wykorzystać lukę, i dostarcza wygenerowane przez sztuczną inteligencję bezpieczne poprawki, które są weryfikowane pod kątem możliwości wykorzystania i ryzyka wprowadzenia zmian, zanim jeszcze programista je zastosuje. Guardrails weryfikuj zmiany pod kątem zasad bezpieczeństwa i zgodności zanim dotrą do CI, a dedykowany agent DevAI przechwytuje to, co robią inni agenci: weryfikuje pliki umiejętności i reguł, przeszukuje każdy pakiet, który agent próbuje zainstalować, pod kątem złośliwego oprogramowania i wzorców slopsquattingu, a także monitoruje zachowanie narzędzia MCP pod kątem zatruwania — wszystko przed wykonaniem.
- Egzekwować. Shield rozszerza tę samą politykę na punkt końcowy programisty, blokując niebezpieczną aktywność sztucznej inteligencji przed jej uruchomieniem.
I ponieważ Triaż AIWyjaśnienie i naprawa nie dotyczą tylko ustaleń firmy Xygeni, ale wszystkiego, co zostało pozyskane z narzędzi już istniejących. Zespoły uzyskują to bez usuwania tego, w co już zainwestowały.
Poznaj Xygeni na OWASP AppSec Days Portugal 2026
Przenosimy tę rozmowę do Porto. Xygeni jest złotym sponsorem OWASP AppSec Days Portugalia 2026, działanie Wrzesień 23-24 w Fundação António Cupertino de Miranda.
Będziemy na wydarzeniu, gdzie omówimy praktyczne podejście do zarządzania postawą bezpieczeństwa AI: w jaki sposób zespoły odkrywają zasoby AI, o których istnieniu nie wiedziały, w jaki sposób sztuczna inteligencja generuje code security wpisuje się w istniejący program AppSec, zamiast siedzieć obok niego, i jak wygląda bieżąca fala zagrożeń MCP i agentowych w praktyce.
Jeśli bierzesz udział, Zapraszamy do odwiedzenia stoiska nr 12 zespołu Xygeni. Jeśli bezpieczeństwo AI jest w Twoim planie i nie możesz dotrzeć do Porto, chętnie przeprowadzimy Cię przez ten proces bezpośrednio. W tych samych terminach jesteśmy również Niemiecki Dzień OWASP 2026 w Karlsruhe, rozmawiając o bezpieczeństwie AI i Shieldkonkretnie warstwy egzekwowania.
Umów się z nami na spotkanie!
FAQ
- Czym jest AI Security Posture Management (AI-SPM)?
AI-SPM to dyscyplina zajmująca się odkrywaniem, inwentaryzacją i ciągłą oceną ryzyka związanego z każdym zasobem AI w organizacji – modelami, zestawami danych, agentami i serwerami MCP – w taki sam sposób, w jaki CSPM robi to w przypadku chmury, a DSPM w przypadku danych. Gartner zdefiniował to jako kategorię w raporcie Hype Cycle for Data Security za 2025 rok. AI-SPM firmy Xygeni tworzy tę inwentaryzację i wspiera ją raportem AI-BOM, dostarczając zespołom ds. bezpieczeństwa i zgodności dowody, które mogą przedstawić audytorowi.
- Co sprawia, że sztuczna inteligencja jest generowana code security inny niż tradycyjny SAST or SCA?
Tradycyjna analiza statyczna i skanowanie zależności zostały stworzone z myślą o zrozumieniu kodu i pakietów, a nie ryzyka specyficznego dla sztucznej inteligencji. Nie dostrzegają one natychmiastowych wstrzyknięć, złośliwych reguł ani plików umiejętności, zatruwania narzędzi MCP ani slopsquattingu nazw pakietów, które może zainstalować asystent AI. Generowane przez AI code security musi działać w ramach tego samego przepływu pracy, z którego korzystają już programiści, skanując jednocześnie kod napisany przez ludzi i wygenerowany przez sztuczną inteligencję. Właśnie to robi Xygeni DevAI w środowisku IDE.
- Dlaczego około 40% kodu generowanego przez sztuczną inteligencję zawiera luki w zabezpieczeniach?
Asystenci kodowania AI uczą się i odtwarzają wzorce w swoich danych treningowych, w tym w danych niebezpiecznych, generując kod znacznie szybciej, niż jest to możliwe w przypadku ręcznego przeglądu. Niezależne badania konsekwentnie wykazują wysoki odsetek luk w zabezpieczeniach z listy OWASP Top 10 w próbkach generowanych przez AI, przy czym pewne kategorie luk, takie jak ataki typu cross-site scripting, pojawiają się w zdecydowanej większości testów.
- Czy AI-SPM zastąpi nasze istniejące narzędzia AppSec?
Nie i nie powinno tego próbować. Systemy Xygeni AI Triage, Explanation i Remediation odnoszą się zarówno do ustaleń pochodzących z własnych skanerów Xygeni, jak i do ustaleń pobranych z istniejących już narzędzi innych firm, dzięki czemu zespoły uzyskują ujednoliconą ochronę przed ryzykiem związanym ze sztuczną inteligencją bez konieczności całkowitego usuwania i zastępowania tego, w co już zainwestowały.
- Gdzie mogę to zobaczyć w akcji?
Xygeni jest złotym sponsorem konferencji OWASP AppSec Days Portugal 2026, 23-24 września w Porto, a zespół będzie na miejscu o godz. Stoisko 12 rozmawiając przez AI-SPM, generowane przez AI code securityoraz obecna fala zagrożeń ze strony MCP i agentów. Kup bilet lub skontaktuj się z nami bezpośrednio, jeśli nie możesz dotrzeć do Porto.
W tym samym tygodniu jesteśmy również w Niemiecki Dzień OWASP 2026 w Karlsruhe, skupiając się na bezpieczeństwie sztucznej inteligencji i Shieldwarstwa egzekwowania.
