Fine-tuning lokalnych modeli LLM w cyberbezpieczeństwie: jak opanować ryzyko podatności 77% i koszty skanowania

Wdrażanie lokalnych modeli językowych w zespołach SOC i cyberbezpieczeństwa ogranicza ryzyko wycieku danych oraz obniża koszty operacyjne w porównaniu z komercyjnymi interfejsami API. Jednak niedostrojony model bazowy uzyskuje 0% dokładnych dopasowań i halucynuje identyfikatory klasyfikacji, a standardowy fine-tuning na danych cybernetycznych zwiększa jego wskaźnik podatności na wstrzykiwanie promptów z 9,1% do nawet 77,5%. Bezpieczna adaptacja wymaga zastosowania ustrukturyzowanego retuszu instrukcji (safety alignment) oraz wydajnych silników serwujących, takich jak vLLM.

Mechanizm i wyzwania dostrajania modeli w cyberbezpieczeństwie

Dostrajanie dziedzinowe (fine-tuning) przekształca ogólny model językowy w specjalistyczne narzędzie zdolne do analizy logów i klasyfikacji podatności bez przekazywania poufnego kodu do zewnętrznych dostawców. Proces ten niesie jednak fundamentalne ryzyko: model uczy się specjalistycznej wiedzy, ale traci odporność na manipulację instrukcjami, jeśli dane treningowe nie zawierają kontekstu obronnego.

Wdrożenie czystego modelu bazowego bez dostrojenia w obszarze Security Operations Center (SOC) wiąże się z wysokim ryzykiem błędu. W badaniach nad modelem DeepSeek R1 Distilled LLaMA 8B wykazano, że baza uzyskuje 0% dokładnych dopasowań (exact-match accuracy) w zadaniu identyfikacji technik MITRE ATT&CK i wykazuje skrajną podatność na halucynacje — przykładowo klasyfikuje rootkit T1014 jako wyciąganie poświadczeń OS Credential Dumping.

Zastosowanie metody QLoRA (konfiguracja r=16, lora_alpha=16) na 4 096 przykładach instruktażowych przy użyciu biblioteki Unsloth na pojedynczym GPU NVIDIA Tesla T4 (15 GB VRAM) pozwala zmienić te wskaźniki: Dokładność dopasowania (Exact Match): wzrost z 0% do 84%. Opóźnienie wnioskowania (Inference Latency): spadek z 33,11 s do 11,09 s (przyspieszenie ~3x). * Zużycie pamięci operacyjnej (VRAM Footprint): minimalny wzrost z 5,99 GB do 6,16 GB (+2,8%).

Specjalizacja tworzy jednak zjawisko określane jako „sztywny specjalista” (brittle specialist). Model dostrojony precyzyjnie odpowiada na pytania faktograficzne, ale bez odpowiedniej struktury zapytania traci zdolność do wielokrokowego wnioskowania zerowego (zero-shot). Rozwiązaniem tego problemu jest zastosowanie szablonów zoptymalizowanych (szablon Example-Guided Synthesis / One-Shot Learning). W ocenie jakościowej LLM-as-a-Judge z użyciem GPT-4o, model dostrojony w roli asystenta SOC wygrał w 72,7% przypadków testowych, uzyskując średnią ocenę jakości 4,09 wobec 3,27 dla modelu bazowego.

Skala zjawiska i ryzyko degradacji bezpieczeństwa modeli

Trening modeli na danych cybernetycznych zawierających opisy złośliwych działań drastically obniża ich fabryczne zabezpieczenia. Bez odpowiedniej retoryki zapobiegawczej model staje się podatny na wstrzykiwanie promptów i wycieki poufnych danych, co pozwala napastnikom na automatyzację generowania złośliwego oprogramowania oraz kampanii phishingowych.

Skalę tego zagrożenia przeanalizowano na zbiorze CyberLLMInstruct, zawierającym 54 928 par instrukcja-odpowiedź. Zbiór odzwierciedla realny rozkład zagrożeń oparty na raporcie IBM X-Force Threat Intelligence Index 2024: Malware: 35% Inżynieria społeczna i Phishing: 25% Ataki DoS/DDoS: 10% Ataki MITM: 10% Podatności Zero-Day: 8% Ataki na hasła: 6% Ataki na IoT: 3% Ataki typu Injection: 3%

Standardowy fine-tuning na tego typu danych (pseudo-malicious data) bez dodatkowego wyrównania bezpieczeństwa prowadzi do drastycznego wzrostu wskaźnika niepowodzenia obrony (garak failure rate) we wszystkich kategoriach frameworka OWASP Top 10 for LLM Applications: Prompt Injection: wskaźnik awarii w modelu Mistral 7B wzrasta z 9,1% do 68,7%. W DeepSeek R1 8B sięga 72,0% (i do 77,5% w teście misinformation). W Llama 3.1 8B wynik bezpieczeństwa spada z 0,95 do 0,15. Sensitive Information Disclosure: wzrost wskaźnika awarii do poziomu 55,6% – 63,0%. Data and Model Poisoning: wzrost do 69,5% – 75,0%. Excessive Agency: wzrost do 61,8% – 66,0%.

Metodą neutralizacji tego ryzyka jest proces ustrukturyzowanego retuszu instrukcji (safety-regulating / safety alignment). Każda para w zbiorze treningowym zostaje przekształcona o trzy elementy: (1) jawne ostrzeżenia przed nadużyciem i skutkami etycznymi, (2) jasne granice prawne i procedury odpowiedzialnego ujawniania, (3) kontekst edukacyjno-obronny. Przekształcenia zestawu danych dokonano przy użyciu otwartoźródłowego modelu DeepSeek-R1, który w testach generuje o ~12% więcej swobodnych odpowiedzi niż o3-mini, co pozwoliło na przetworzenie danych bez blokad nakładanych przez komercyjne API (GPT-4o, Claude 3).

Wyniki modeli po wyrównaniu bezpieczeństwa (safety-enhanced models) pokazują spadek wskaźników awarii obrony w Prompt Injection do 4,2% (DeepSeek R1 8B), 4,5% (Llama 3 8B), 5,2% (Gemma 2 9B) oraz 6,3% (Mistral 7B).

Porównanie podejść technologicznych i wydajności serwowania

Wybór architektury produkcyjnej decyduje o przepustowości i opóźnieniach systemu wykrywania zagrożeń. Podczas gdy małe wyspecjalizowane modele wygrywają z wyrażeniami regularnymi pod względem dokładności, wybór silnika wnioskowania między prostym środowiskiem lokalnym a produkcyjnym serwerem determinują koszty i obciążenie ruchem.

W zadaniu detekcji sekretów w kodzie źródłowym dostrojono mały model Llama 3.2 1B. Wyniki w porównaniu z tradycyjnym podejściem bazującym na wzorcach regex pokazują znaczną przewagę: Tradycyjny Regex: wykrywalność (recall) na poziomie ~60% przy bardzo wysokim wskaźniku fałszywych alarmów (false positives). Model Llama 3.2 1B (LoRA + INT8 Quantization): precyzja (precision) 85,7%, wykrywalność (recall) 82% przy prędkości ~27 tokenów/s na procesorze ARM CPU. * Model Qwen Code 2.5 0.5B: precyzja 87,5%, wykrywalność 71% przy prędkości ~143 tokenów/s.

Architektura produkcyjna wykorzystuje lejek predykcyjny (prediction funnel): wstępne filtrowanie po długości pliku i regułach regex, wyciąganie fragmentów kodu, a następnie wnioskowanie modelem SLM w czasie ~10 sekund na plik.

W pełnych zadaniach przetwarzania języka naturalnego dla cyberbezpieczeństwa benchmark CyberBench (obejmujący 10 zbiorów danych, m.in. CyNER, APTNER, SecMMLU, CVE, MITRE) wykazał, że model CyberInstruct-13B (dostrojony Llama-2-13B metodą QLoRA 4-bit na danych CyberBench i MMLU) osiąga średni wynik 70,4%. Przewyższa on komercyjny model GPT-3.5-Turbo (62,6%) i dorównuje GPT-4 (69,6%).

Testy porównawcze silników serwujących przeprowadzone przez Red Hat na karcie NVIDIA A100-PCIE-40GB z modelem Llama 3.1 8B wykazały drastyczne różnice wydajności pod obciążeniem wieloużytkownikowym:

Narzędzie Ollama sprawdza się w prototypowaniu i na stanowiskach deweloperskich, podczas gdy vLLM jest standardem w rozwiązaniach produkcyjnych o wysokim natężeniu ruchu.

Analiza kosztów i wymagań sprzętowych

Utrzymanie lokalnej infrastruktury AI wymaga precyzyjnego bilansu opłat za sprzęt w stosunku do abonamentów chmurowych API. Skanowanie milionów plików lub obsługa tysięcy alertów dziennie za pomocą zewnętrznych modeli generuje ogromne koszty i ryzyko naruszenia prywatności, podczas gdy architektury LoRA i QLoRA umożliwiają uruchomienie lokalne na standardowych kartach GPU.

Analiza ekonomiczna skanowania kodu i analizy alertów SOC wskazuje na następujące zależności finansowe: Skanowanie kodu (skala 5 000 000 plików dziennie): koszty komercyjnego API (GPT-4o, Claude Sonnet) przy stawkach \$0,005 – \$0,10 za plik wynoszą od \$25 000 do \$500 000 miesięcznie. Czas przetwarzania jednowątkowego wyniósłby 174 dni. Obsługa alertów SIEM/SOC (skala 100 000 alertów miesięcznie): zapytanie API (GPT-4.1) przy średnim zużyciu 500 tokenów wejściowych i 500 wyjściowych kosztuje \$0,0075 za alert. Łączny koszt miesięczny wynosi \$750 (\$9 000 rocznie).

Wdrożenie lokalne z wykorzystaniem metody QLoRA (kwantyzacja bazy do 4 bitów) pozwala na drastyczne obniżenie progu wejścia sprzętowego: Modele 7B – 8B (Llama 3.1 8B, Mistral 7B): wymagają minimum 16 GB RAM oraz karty GPU z 8 GB VRAM (np. RTX 4060 Ti / RTX 5070 Ti 16 GB). Trening sesji 1 000 – 3 000 przykładów w chmurze (RunPod, Vast.ai na GPU A100) trwa 1 – 4 godziny i kosztuje \$5 – \$30 przy stawce \$0,5 – \$2/h. Modele 70B (Llama 3.3 70B): wymagają 64 GB RAM oraz 24 GB+ VRAM (np. używana RTX 3090, RTX 4090 lub RTX 5090 32 GB GDDR7 o przepustowości 1 792 GB/s, generująca 40 – 50 tokenów/s przy kwantyzacji Q4). * Stacje z pamięcią połączoną (Unified Memory): zestawy takie jak AMD Ryzen AI Max+ 395 (Strix Halo z 128 GB LPDDR5X) czy Apple M4/M5 Max (128 GB, przepustowość 546 – 614 GB/s) umożliwiają uruchamianie modeli klasy 70B bez konieczności budowania klastrów wielokartowych.

Wnioski praktyczne i rekomendacje

Wdróż dwuetapowy proces przygotowania danych treningowych, dodając do każdej instrukcji cybernetycznej kontekst prawny, ostrzeżenia o ryzyku oraz zasady bezpiecznego ujawniania zagrożeń. Zmierz wskaźnik awarii obrony (failure rate) swojego modelu przed wdrożeniem produkcyjnym za pomocą narzędzi garak lub DeepEval na zbiorze testowym OWASP Top 10 for LLM Applications. Skonfiguruj silnik serwujący vLLM z obsługą dynamic batching zamiast środowiska Ollama, jeśli Twój system ma obsługiwać ruch wieloużytkownikowy w środowisku SOC. Zweryfikuj budżet pamięci VRAM i zastosuj kwantyzację QLoRA do precyzyjnego dostrajania modeli 8B na kartach z 16 GB VRAM, ograniczając koszty sesji treningowych do kwoty poniżej \$30.

Źródła

• Analysing Safety Risks in LLMs Fine-Tuned with Pseudo-Malicious Cyber Security Data
• BSidesSF 2024 – Finetuning Large Language Models (LLMs) for Security Log Detections (Wilson Tang) – YouTube
• CyberBench: A Multi-Task Benchmark for Evaluating Large Language Models in Cybersecurity – Artificial Intelligence for Cyber Security (AICS)
• CyberLLMInstruct: A New Dataset for Analysing Safety of Fine-Tuned LLMs Using Cyber Security Data – arXiv
• Fine-Tuning a Small Language Model for Secrets Detection | Wiz Blog
• Instruction-Tuned Fine-tuning of Domain-Specific LLMs with Retrieval-Augmented Generation and Graph Integra – arXiv
• Jak zrobić fine-tuning modelu AI — poradnik praktyczny – SEO AI
• Local AI Hardware Requirements (2026): Complete Guide