Najczęstsze luki bezpieczeństwa w projektach AI tworzonych w Pythonie i jak je wykrywać automatycznie

Dlaczego projekty AI w Pythonie są szczególnie narażone na luki bezpieczeństwa

Charakterystyczny stack technologiczny AI w Pythonie

Większość projektów AI w Pythonie opiera się na bardzo podobnym zestawie narzędzi: biblioteki ML (TensorFlow, PyTorch, scikit-learn, XGBoost), frameworki do serwowania modeli (FastAPI, Flask, Django, czasem Celery), narzędzia MLOps (MLflow, Airflow, Kubeflow, Dagster), a do tego chmura (AWS, GCP, Azure) i GPU (CUDA, sterowniki, obrazy Dockera). Taki stack jest wygodny, elastyczny i szybki w prototypowaniu, ale z punktu widzenia bezpieczeństwa oznacza kilka warstw, na których coś może pójść źle.

Każda warstwa ma własne ryzyka: biblioteki ML bywają aktualizowane rzadziej niż popularne frameworki webowe, pipeline’y MLOps często są konfigurowane „na skróty”, a infrastruktura GPU wymaga otwierania dodatkowych portów i uprawnień. Jeśli do tego dochodzi intensywne korzystanie z Jupyter Notebooków i uruchamianie kodu z internetu bez głębszej weryfikacji, poziom ekspozycji znacznie rośnie.

Dodatkowy problem stanowi brak typowego „security hardeningu”, który na ogół stosuje się w klasycznych aplikacjach webowych. Developerzy skupiają się na jakości modelu (accuracy, F1-score), czasie inferencji, kosztach GPU, a kwestie jak uwierzytelnianie, ograniczenia uprawnień, kontrola logów czy konfiguracja CORS często schodzą na dalszy plan. Efekt jest taki, że nawet mały endpoint z modelem może stać się poważnym wektorem ataku.

Szybkie prototypowanie i kopiowanie przykładów jako źródło podatności

Standardowy proces budowy rozwiązania AI w Pythonie wygląda tak: powstaje notebook z eksperymentem, później z niego „wycina się” funkcje i wkleja do serwisu API, a na koniec dorzuca się minimum kodu do wystawienia endpointu. Wiele kluczowych decyzji projektowych zapada w pośpiechu. Nie ma czasu na formalne przeglądy bezpieczeństwa, testy penetracyjne czy recenzje pod kątem uprawnień.

Bardzo częsty wzorzec to kopiowanie fragmentów kodu z GitHuba lub Stack Overflow: całe funkcje preprocessingu, przykładowe serwisy Flask, skrypty do ładowania modeli. Takie snippet’y rzadko zawierają jakąkolwiek walidację danych wejściowych, nie mówiąc o obsłudze błędów, logowaniu zanonimizowanych danych czy ograniczeniach rozmiaru requestu. W kodzie ML pojawia się też sporo dynamicznego wykonywania kodu (eval, exec, lambda w callbackach), co w połączeniu z wejściem od użytkownika jest prostym przepisem na RCE.

Jeśli zespoły nie mają standardów bezpieczeństwa ani checklist, to te złe praktyki z fazy prototypowania płynnie przechodzą do produkcji. Co gorsza, im lepiej model działa biznesowo, tym trudniej uzasadnić „przepisywanie” go w imię bezpieczeństwa – dopóki coś nie wybuchnie.

Złożony łańcuch zależności i efekt domina

Projekt AI w Pythonie to rzadko pojedynczy plik. To drzewo zależności: biblioteki z PyPI, moduły C++ ładowane przez pip, sterowniki CUDA, biblioteki systemowe, obrazy Dockera, skrypty bash w pipeline’ach CI/CD, konfiguracje Helm/terraform. Wystarczy jedna podatna warstwa, aby otworzyć system na atak.

Typowy scenariusz: obraz Dockera budowany z przestarzałej bazy (np. ubuntu:18.04), w nim Python z kilkoma wersjami bibliotek, do tego sterowniki GPU z własnymi zależnościami. Do obrazu są dociągane paczki z PyPI bez blokady wersji (brak pinning w requirements.txt lub pyproject.toml), a w środku pojawia się paczka z typosquattingu. Pipeline CI/CD uruchamia testy bez izolacji, więc złośliwy kod z paczki ma dostęp do zmiennych środowiskowych z tajnymi kluczami.

Duża złożoność powoduje, że manualne kontrolowanie wszystkiego jest niewykonalne. Bez automatycznego skanowania zależności (SCA), regularnego skanowania obrazów kontenerów i egzekwowania polityk w CI/CD, część ryzyk pozostaje niewidoczna, dopóki ktoś nie wykorzysta ich w praktyce.

Różnice między klasyczną aplikacją web a systemem AI

W klasycznej aplikacji web często chroni się głównie dane i kontroluje logikę biznesową. W systemach AI dochodzą zupełnie nowe elementy: model jako zasób (parametry, architektura), dane treningowe oraz pipeline uczenia i wdrażania. Atak może dotyczyć nie tylko bazy danych czy endpointu HTTP, ale także procesu trenowania i wersjonowania modeli.

Jeśli ktoś uzyska dostęp do pipeline’u treningowego, może zatruć dane treningowe, podmienić etykiety, wstrzyknąć backdoora do modelu lub wypchnąć do produkcji zmodyfikowaną wersję. Z zewnątrz aplikacja będzie działała „poprawnie”, ale pewne specyficzne wejścia spowodują np. błędne decyzje dla wybranej grupy klientów. Tego typu luki są trudne do wykrycia klasycznymi narzędziami web security.

Model to nie tylko plik na dysku. To również potencjalny nośnik poufnej wiedzy (odwzorowanej w wagach), a w przypadku modeli generatywnych – wektor wycieku informacji. Atakujący może spróbować „wyciągnąć” z modelu informacje o danych treningowych (model inversion), dane osobowe czy własnościowe algorytmy. Ochrona sprowadza się nie tylko do tradycyjnego uwierzytelniania, ale także do kontroli sposobu używania modeli i monitoringu inferencji.

Realistyczny przykład: „prosty” endpoint HTTP z modelem

Popularny scenariusz: zespół data science buduje model klasyfikujący tekst, a developer w dwa dni owija go w prosty serwis FastAPI:

from fastapi import FastAPI
import joblib

app = FastAPI()
model = joblib.load("model.pkl")

@app.post("/predict")
def predict(request: dict):
    text = request["text"]
    prediction = model.predict([text])[0]
    return {"prediction": prediction}

Na pierwszy rzut oka wygląda to niewinnie. W praktyce ten kod ma kilka poważnych problemów:

• brak walidacji wejścia (dowolny payload JSON, dowolna długość tekstu, brak limitu rozmiaru);
• brak uwierzytelniania i autoryzacji – endpoint otwarty dla całego świata;
• ładowanie modelu z niezaufanego źródła (jeśli plik pickle/ joblib był kiedykolwiek modyfikowany, może zawierać złośliwy kod);
• brak ograniczeń zasobów – atakujący może wysłać tysiące żądań i zablokować cały serwis.

Jeśli taki endpoint zostanie wystawiony bezpośrednio do internetu, boty i skanery bardzo szybko go znajdą. Bez podstawowych mechanizmów bezpieczeństwa i monitoringu zespół nawet nie zauważy, kiedy serwis zostanie użyty jako wektor ataku lub źródło wycieku danych.

Model zagrożeń dla typowego projektu AI w Pythonie

Kluczowe zasoby wymagające ochrony

W projektach AI tworzonych w Pythonie zasoby do ochrony można pogrupować w kilka kategorii:

• Dane treningowe – często zawierają dane osobowe, dane finansowe, logi użytkowników. Wyciek takich danych może oznaczać poważne konsekwencje prawne (RODO) i reputacyjne.
• Dane inferencyjne – to, co użytkorki i użytkownicy przesyłają do modelu. Mogą to być prywatne dokumenty, fragmenty kodu, pliki medyczne. Jeśli requesty są logowane „na surowo” lub trafiają do niezaszyfrowanych bucketów, stają się łatwym celem.
• Modele i ich parametry – modeli nie należy traktować jedynie jako plików .pkl czy .pt. To efekt pracy zespołu i inwestycji, często też encja zawierająca informacje pośrednio wynikające z danych treningowych.
• Kod i konfiguracja – skrypty treningowe, serwisy API, konfiguracje orkiestracji (Airflow, Kubeflow) oraz pliki konfiguracyjne zawierające sekrety. Ich wyciek umożliwia dostęp do reszty środowiska.
• Pipeline CI/CD i MLOps – definicje workflow, uprawnienia w systemach CI, tokeny do repozytoriów modeli. To często najbardziej newralgiczny element: jeśli ktoś przejmie pipeline, może przejąć całą ścieżkę od danych do produkcyjnego endpointu.

Typy przeciwników i ich motywacje

Aby skutecznie zabezpieczyć projekt AI, trzeba wiedzieć, przed kim jest chroniony. W praktyce wyróżnia się kilka klas „przeciwników”:

• Ciekawski użytkownik – osoba, która ma legalny dostęp do aplikacji, ale próbuje robić z nią więcej niż przewidziano: masowo wysyła zapytania, testuje nietypowe formaty wejścia, próbuje odtwarzać dane treningowe.
• Złośliwy klient API – skrypt lub bot atakujący endpointy w celu obejścia ograniczeń (np. konwersji, limitu calli) lub wywołania błędów, które ujawnią informacje o systemie.
• Atakujący z internetu – skanery portów, botnety, próby automatycznej eksploatacji znanych podatności w frameworkach Pythona, bibliotekach ML czy serwerach HTTP.
• Insider / pracownik wewnętrzny – osoba z dostępem do środowiska danych, modeli lub CI/CD, która może nieświadomie popełnić błąd (np. wrzucić klucz API do repozytorium) albo celowo zmanipulować proces.

Motywacje są różne: od chęci zdobycia danych, przez finansowy zysk (sprzedaż dostępu, szantaż), po sabotaż konkurencji lub czystą ciekawość. Model zagrożeń powinien wskazać, które kombinacje zasób–przeciwnik są najbardziej krytyczne i tam skupić wysiłek.

Główne wektory ataku w systemach AI

Z punktu widzenia projektów AI pewne miejsca są szczególnie narażone:

• Wejście do modelu – wszystko, co użytkownik przekazuje jako input. To tu pojawiają się ataki typu prompt injection (dla LLM), payloady wywołujące błędy parsowania, bardzo duże zapytania wywołujące DoS czy próby obejścia filtrów treści.
• API serwujące model – endpointy HTTP/GRPC, kolejki komunikatów (Kafka, RabbitMQ), kanały WebSocket. Tutaj obowiązują klasyczne zasady bezpieczeństwa webowego plus specyficzne dla modeli zagrożenia (np. model extraction przez hurtowe odpytywanie).
• Repozytoria danych – bazy danych, hurtownie danych, buckety S3/Blob/GS. Błędy konfiguracji (publiczne buckety, brak szyfrowania, brak segmentacji) to jedne z najczęstszych realnych incydentów.
• Zależności Pythona i modele zewnętrzne – paczki z PyPI, model huby (Hugging Face Hub, TensorFlow Hub), zewnętrzne skrypty treningowe. Tu pojawia się ryzyko typosquattingu, złośliwych hooków instalacyjnych, ukrytego malware.
• Środowisko wykonawcze – obrazy Dockera, klastry Kubernetes, serwery GPU. Błędy w konfiguracji uprawnień i sieci mogą umożliwić atakującemu przeskakiwanie pomiędzy kontenerami czy usługami.

Kryteria oceny ryzyka: CIA + reputacja

Do oceny ryzyka w projektach AI można wykorzystać klasyczny trójkąt CIA (Confidentiality, Integrity, Availability), rozszerzony o aspekt reputacji:

• Poufność – czy luka pozwala odczytać dane treningowe, inference payloady lub parametry modeli? Czy umożliwia rekonstrukcję danych osobowych?
• Integralność – czy atak umożliwia modyfikację danych, modeli, kodu lub konfiguracji w sposób trudny do wykrycia? Czy można „ustawić” model tak, aby faworyzował konkretne wyniki?
• Dostępność – jak łatwo doprowadzić do odmowy usługi (DoS) przez kosztowne zapytania, oversubskrypcję GPU, floodowanie kolejki zadań?
• Reputacja – jakie skutki PR-owe i biznesowe wywoła publikacja informacji o incydencie? W AI często to reputacja jest najcenniejszym aktywem.

Dla każdego scenariusza (np. publiczny bucket z logami inference, endpoint bez rate-limitu, niezweryfikowane dane treningowe) przypisuje się poziom wpływu na powyższe kryteria oraz prawdopodobieństwo. Na tej podstawie łatwiej ustalić, co musi być skanowane automatycznie przy każdym commicie, a co można kontrolować rzadziej.

Przekładanie modelu zagrożeń na automatyczne skanowanie

Model zagrożeń nie ma sensu, jeśli nie przekłada się na konkretne mechanizmy kontrolne. W praktyce sprowadza się to do kilku kroków:

• identyfikacja miejsc, gdzie można uruchomić automatyczne testy i skanowanie (commit, pull request, build obrazu, deployment na staging);
• dobór narzędzi: statyczna analiza kodu (SAST) dla Pythona, skanowanie zależności (SCA), skanowanie obrazów, DAST dla API, testy fuzzujące wejścia do modelu;
• definicja reguł i progów – które typy ostrzeżeń blokują merge, a które jedynie generują raport;
• integracja z pipeline’em MLOps: skanowanie notebooków, workflow’ów Airflow/Kubeflow, definicji eksperymentów MLflow.

Jeśli krytycznym zasobem są np. dane treningowe, w pipeline powinny się znaleźć kroki automatycznej weryfikacji ich pochodzenia, kontroli dostępu i skanowania pod kątem danych wrażliwych. Jeśli największym ryzykiem jest dostęp do modelu generatywnego, priorytetem będzie automatyczne badanie jego zachowań na zestawie promptów atakujących.

Najczęstsze luki wynikające z użycia bibliotek ML i frameworków w Pythonie

Bezpieczeństwo popularnych bibliotek ML: TensorFlow, PyTorch, scikit-learn, transformers

Typowe klasy podatności w bibliotekach ML

Popularne biblioteki ML mają swoje specyficzne klasy problemów bezpieczeństwa, które rzadko występują w zwykłych aplikacjach webowych. Najczęściej pojawiają się:

• błędy w parsowaniu danych i modeli – przepełnienia bufora, błędne walidacje długości, założenia o formacie wejścia (częste w parserach ONNX, obrazów, dźwięku);
• wycieki informacji o środowisku – zbyt gadatliwe komunikaty błędów zawierające ścieżki, konfigurację GPU, wersje bibliotek;
• zdalne wykonanie kodu (RCE) w funkcjach „pomocniczych” – np. mechanizmy hooków, callbacków, ładowania niestandardowych warstw z plików;
• eskalacja uprawnień w środowisku GPU – błędy sterowników lub warstwy C/CUDA używanej przez TensorFlow/PyTorch;
• deserializacja niezaufanych artefaktów – ładowanie modeli z pickle/joblib lub własnych formatów binarnych bez podpisu i walidacji.

Znaczna część luk raportowanych dla TensorFlow czy PyTorch wynika z założeń, że dane wejściowe są „zaufane” (np. od badacza, nie od anonimowego klienta API). Gdy ten sam kod ląduje w serwisie produkcyjnym, staje się realną powierzchnią ataku.

TensorFlow i PyTorch: wektor ataku przez dane wejściowe

Frameworki głębokiego uczenia implementują tysiące operatorów i ścieżek kodu w C/C++. Wiele z nich było pisanych z myślą o wydajności, nie o twardej walidacji danych. Z punktu widzenia bezpieczeństwa trzeba patrzeć na kilka obszarów:

• parsowanie skomplikowanych formatów – obrazy, sekwencje, grafy; błędne nagłówki, nietypowe rozmiary, brakujące metadane;
• niestandardowe operatory – custom ops i rozszerzenia (CUDA, C++), często bez przeglądów bezpieczeństwa;
• autograd – mechanizmy śledzenia gradientów mogą doprowadzić do nieprzewidzianych ścieżek kodu przy nietypowych kształtach tensora.

Przykładowo, w TensorFlow wielokrotnie zgłaszano CVE dotyczące funkcji typu DecodeJpeg, DecodePng czy operatorów przetwarzania sekwencji, wywołujących crash procesu przy uszkodzonym wejściu. W trybie batchowego treningu nie jest to krytyczne – w serwisie API staje się prostym DoS-em.

Elementem obrony jest statyczna analiza grafu i danych wejściowych. Narzędzia takie jak syzkaller-inspirowane fuzzer’y albo OSS-Fuzz są używane przez same zespoły TensorFlow czy PyTorch, ale można też uruchamiać prostsze fuzz testy po swojej stronie:

import numpy as np
import tensorflow as tf

def fuzz_predict(model, n_iter=1000):
    for _ in range(n_iter):
        # generujemy losowy tensor w dozwolonych granicach
        x = np.random.randint(0, 256, size=(1, 224, 224, 3), dtype=np.uint8)
        try:
            model(x, training=False)
        except Exception as e:
            # logujemy stacktrace + przykładowe wejście
            log_suspicious_input(e, x)

# w CI uruchamiane na buildzie modelu / obrazu

Takie fuzzowanie nie zastąpi łatania CVE w bibliotekach, ale pozwala wcześnie złapać ścieżki, które kończą się niekontrolowanym wyjątkiem lub crash’em kontenera przy nietypowym wejściu.

Scikit-learn, XGBoost i pickle: deserializacja jako ryzyko RCE

Klasyczny stos Pythona i bibliotek ML (scikit-learn, XGBoost, LightGBM) często wykorzystuje serializację przez pickle lub joblib. To wygodne, ale domyślnie kompletnie niebezpieczne przy niezaufanych źródłach:

• pickle.load() i joblib.load() mogą wykonać dowolny kod Pythona zapisany w obiekcie;
• brak mechanizmu sprawdzania integralności – uszkodzony lub podmieniony plik nie jest od razu wykrywany;
• często modele są przechowywane w publicznie dostępnym storage’u (np. bucket bez właściwych ACL).

Minimalny krok to wymuszenie zaufanego źródła i weryfikacja integralności modelu:

import hashlib
import joblib
from pathlib import Path

EXPECTED_SHA256 = "d87f7e0c1234567890..."  # zapisane w konfiguracji / KMS

def load_model_safe(path: str):
    p = Path(path)
    digest = hashlib.sha256(p.read_bytes()).hexdigest()
    if digest != EXPECTED_SHA256:
        raise RuntimeError("Model file integrity check failed")
    return joblib.load(p)

model = load_model_safe("/models/model.joblib")

Drugim krokiem powinna być migracja do formatów, które nie wykonują kodu przy odczycie (ONNX, TensorFlow SavedModel, TorchScript) tam, gdzie to możliwe. Po stronie CI/CD warto wymusić regułę: żadnego wczytywania pickle/joblib z lokalizacji konfigurowanej z zewnątrz.

Transformers i modele zewnętrzne: ryzyko w hubach modelowych

Ekosystem transformers (Hugging Face i okolice) wprowadza dodatkowe ryzyka:

• modele i pipeline’y ładowane dynamicznie z internetu (from_pretrained) bez przypięcia do konkretnej wersji commit’u;
• skrypty modeling_*.py i własne tokenizery, które są zwykłym kodem Pythona – mogą zawierać złośliwe fragmenty;
• hooki w setup.py oraz wtyczki integracyjne z innymi frameworkami.

Podstawowy błąd to używanie „gołych” from_pretrained("some-user/some-model") w kodzie produkcyjnym. Bez przypięcia do konkretnego revision i bez lokalnego cache’u otwiera to drzwi do supply chain attack: autor modelu (lub przejęte konto) może zmienić repozytorium, a produkcja ściągnie nową wersję przy kolejnym restarcie.

from transformers import AutoModelForSequenceClassification, AutoTokenizer

MODEL_REPO = "org/secure-model"
MODEL_REVISION = "8f5e2c4a..."  # commit hash, nie branch

tokenizer = AutoTokenizer.from_pretrained(
    MODEL_REPO,
    revision=MODEL_REVISION,
    local_files_only=True
)

model = AutoModelForSequenceClassification.from_pretrained(
    MODEL_REPO,
    revision=MODEL_REVISION,
    local_files_only=True
)

Automatyczna kontrola polega tu na:

• skanowaniu repozytorium pod kątem użycia from_pretrained bez parametrów revision i local_files_only (prosty custom rule np. dla Semgrep);
• sprowadzaniu artefaktów z hubów do prywatnego registry (modele jako pliki lub obrazy Dockera) i skanowaniu ich przed dopuszczeniem do użycia;
• generowaniu SBOM (Software Bill of Materials) również dla modeli – lista źródeł, commitów, hashy.

Automatyczne skanowanie kodu wykorzystującego biblioteki ML

Nawet jeśli same biblioteki są aktualne, aplikacja może używać ich w niebezpieczny sposób. Do typowych wzorców, które da się wychwycić automatycznie, należą:

• bezpośrednie pickle.load, joblib.load z dynamiczną ścieżką (np. z requestu lub zmiennej środowiskowej);
• ładowanie modeli z internetu w czasie startu lub requestu (URL w konfiguracji);
• modele i pipeline’y pobierane z hubów z domyślną gałęzią (main);
• użycie przestarzałych, pozbawionych patchy wersji TensorFlow/PyTorch/scikit-learn.

Przykładowa reguła Semgrep, która blokuje niekontrolowane użycie pickle.load:

rules:
  - id: python-pickle-load-unsafe
    patterns:
      - pattern: pickle.load($ARG)
    message: "Uncontrolled pickle.load detected – use signed artifacts only"
    languages: [python]
    severity: ERROR

Takie reguły można rozszerzać o kontekst (np. dopuszczać je wyłącznie w dedykowanym module secure_loader.py) i wymusić w CI blokowanie merge, gdy wykryta zostanie ich obecność w nowym kodzie.

Aktualizacje i CVE w bibliotekach ML: jak automatyzować

Biblioteki ML mają intensywny cykl wydawniczy; poważne luki pojawiają się i są łatane stosunkowo często. Ręczne śledzenie changelogów TensorFlow czy PyTorch jest mało realistyczne w większej organizacji. Rozsądniej jest podejść do tego systemowo:

• stosować SCA (Software Composition Analysis) – np. Dependabot, Renovate, Snyk, Trivy – dla requirements.txt, poetry.lock, environment.yml;
• ustawić progi: krytyczne CVE w TensorFlow/PyTorch blokują build, średnie – generują zadanie w backlogu;
• utrzymywać „baseline bezpieczeństwa” – minimalne dozwolone wersje kluczowych bibliotek w polityce organizacji (np. TensorFlow >= 2.14.0, PyTorch >= 2.1.x).

Automatyczne skanowanie może wyglądać następująco:

# przykład: skan obrazów z modelami
trivy image --severity HIGH,CRITICAL 
  --exit-code 1 
  registry.local/ml-service:latest

Warto połączyć to z testami funkcjonalnymi modeli: po aktualizacji TensorFlow/PyTorch pipeline CI powinien zretrenować lub przynajmniej przeładować model, uruchomić zestaw testów regresyjnych i dopiero wtedy dopuścić obraz do promocji.