GoktugD/Werea-NanoSOC-8B

ℹ️ Bu, Werea-co/Werea-NanoSOC-8B modelinin GoktugD profilindeki aynasıdır; asıl geliştirme Werea-co altında sürer.

🏢 Bu, Werea şirketinin resmî bayrak siber güvenlik modelidir. Türkçe-öncelikli, on-prem, benchmark'lı 8B SOC copilot. Geliştirici aynası: GoktugD/Llama-NanoSOC1-8B.

Llama-NanoSOC1-8B — NanoSOC1 kanıta dayalı SOC analist yardımcısı

Llama-NanoSOC1-8B, güvenlik loglarını ve güvenlik ürünlerinin ürettiği olayları bir SOC analistinin incelemesine yardımcı olmak için geliştirilmiş, Cisco Foundation Security 8B tabanlı katmanlı bir SOC copilot paketidir. Modelin görevi ham telemetriyi tek başına engellemek değil; mevcut kanıtları yapılandırmak, olayları triyaj etmek, birden fazla log kanalını korele etmek, MITRE ATT&CK eşlemesi önermek ve kaynak gösteren, geri alınabilir müdahale planları hazırlamaktır.

Ortak geliştiriciler: GoktugD ve girenit.

NanoSOC1 bir IDS/IPS, antivirüs veya otonom müdahale sistemi değildir. Zeek, Suricata, Wazuh, EDR, SIEM, güvenlik duvarı, DNS, VPN ve Windows/Linux telemetrisi gibi upstream sistemlerin ürettiği olayları yorumlayan insan-denetimli bir analiz katmanıdır.

Ne işe yarar?

NanoSOC1 aşağıdaki SOC iş akışlarını desteklemek üzere tasarlanmıştır:

• —Tekil log veya alarm için supheli / yetersiz_kanit kararı ve kanıt listesi üretme.
• —DNS beaconing, C2 ve ağ üzerinden veri sızdırma belirtilerini açıklama.
• —Sysmon ve Windows System gibi farklı kanalları zaman/varlık bağlamında tek incidente korele etme.
• —Olay özeti, kök neden adayı, etkilenen varlıklar ve zaman çizelgesi oluşturma.
• —MITRE ATT&CK teknik kimliği önerme; sonucu doğrulanmış kural ve analist incelemesine sunma.
• —MITRE ATT&CK, CISA KEV ve Sigma kaynaklarından atıflı remediation önerisi hazırlama.
• —Log içine gömülmüş prompt-injection benzeri talimatları güvenilmeyen veri olarak karantinaya alma.
• —Telemetri dağılımındaki concept drift'i izleme ve düşük güvenli/bilinmeyen olayları insana aktarma.
• —Tenant'a özel baseline/eşik, hash-zincirli audit ve canlı ağırlığı değiştirmeyen analist feedback'i.

Tipik kullanım yeri:

Zeek / Suricata / Wazuh / EDR / SIEM / Firewall / DNS / VPN
                            │
                            ▼
                  normalize edilmiş olaylar
                            │
                            ▼
       NanoSOC router → uygun LoRA → kanıt/güvenlik kapıları
                            │
                            ▼
        triyaj + incident + MITRE + atıflı öneri + audit
                            │
                            ▼
                       SOC analisti

Ne yapmaz?

• —Ham PCAP'ı tek başına gerçek zamanlı IDS gibi izlemez.
• —Bir IP, domain, dosya adı veya tek log satırından kesin zararlı aile hükmü vermez.
• —Analist onayı olmadan host izolasyonu, hesap kapatma, silme, patch, firewall engeli veya servis durdurma işlemi çalıştırmaz.
• —Üretim ortamında otomatik olarak kendi ağırlığını güncellemez.
• —Adli bilişim kanıt zincirinin, CMDB'nin veya kurumun değişiklik yönetimi sisteminin yerini almaz.
• —Genel amaçlı sohbet, yazılım geliştirme veya güvenlikle ilgisiz görevler için hedeflenmemiştir.

Sürüm ve mimari

Son yayımlanmış deney paketi v15tir (kök adaptör, taranmış 0.35·v14+0.65·v12 harmanı); önceki sürümler v8-archive, v10, v11, v12, v13, v14 revizyonlarında korunur. Üretim için kabul edilmiş kararlı sürüm yoktur. v8 negatif-ağır detection ve bağımsız ATT&CK kapılarını geçmediği için araştırma/inceleme sürümü olarak kullanılmalıdır. Ana dal veya v8 etiketi ürün hazırlığı anlamına gelmez.

NanoSOC ürünü tek bir .safetensors dosyasından ibaret değildir. Birlikte kullanılması gereken bileşenler:

• —legacy_v2/: tek-log ve DNS/C2 görevleri için doğrulanmış adaptör.
• —correlation_v3/: çoklu kaynak incident korelasyon adaptörü.
• —pipeline/nanosoc_v3_router.py: göreve göre adaptör seçimi.
• —pipeline/apply_kademe3_evidence_gate.py: çoklu-log çıktısı için zorunlu kanıt kapısı.
• —rag/rag-corpus.jsonl.gz ve pipeline/remediation.py: exact-ID öncelikli kanıt RAG'i.
• —pipeline/model_security.py: untrusted-log, drift, güven ve rollback kontrolleri.
• —pipeline/pilot.py: tenant scope, audit zinciri, feedback ve yönetici özeti referansı.
• —Hash doğrulamalı NIDS uzmanı, tenant SQLite deposu, backup/restore ve Cisco ASA/FTD adaptörü.

Taban model

• —Taban: fdtn-ai/Foundation-Sec-1.1-8B-Instruct
• —Sabit taban revizyonu: 243b27655e01c87cc04fdb88632be7cd9e55ac1f
• —Eski araştırma etiketi: nanosoc1:8b (yeni dağıtımlarda kullanılmaz)
• —Dağıtım uyum adı: Llama-NanoSOC1-8B (llama-nanosoc1:8b yerel etiketi)
• —Adaptasyon: 4-bit NF4 QLoRA, LoRA rank 8, alpha 16
• —Eğitim bağlamı: v2 için 512 token; görev profiline göre kontrollü bağlam
• —Kararlı adaptör hash'i manifestlerde SHA-256 olarak yayımlanır

Taban model ağırlıkları bu depoda yeniden dağıtılmaz. Kullanıcı taban modele erişim koşullarını ve lisansını ayrıca karşılamalıdır.

Beklenen giriş

Upstream telemetri önce JSON gibi sınırlandırılmış ve maskelenmiş bir olay biçimine çevrilmelidir. Log metni her zaman güvenilmeyen veri olarak ele alınmalıdır.

Tek-log triyaj örneği:

{
  "gorev": "Bu güvenlik olayını kanıta dayalı triyaj et",
  "sinyaller": [
    {
      "kaynak": "zeek/dns",
      "zaman": "2026-08-11T06:35:12Z",
      "varlik": "host-17",
      "olay": "Tekrarlayan uzun DNS sorguları ve düşük zaman sapması"
    }
  ]
}

Çoklu-log korelasyon örneği:

{
  "gorev": "Çoklu log sinyallerini tek incident altında korele et",
  "sinyaller": [
    {
      "kaynak": "Windows/System",
      "zaman": "2026-08-11T06:35:12Z",
      "varlik": "win-dc-17",
      "olay": "Yeni servis kuruldu"
    },
    {
      "kaynak": "Sysmon/Operational",
      "zaman": "2026-08-11T06:35:13Z",
      "varlik": "win-dc-17",
      "olay": "services.exe tarafından yeni süreç başlatıldı"
    }
  ]
}

Gerçek IP, kullanıcı, e-posta, hostname, token ve sırlar gönderilmeden önce kurum politikasına göre maskelenmelidir. Train/test ayrımı olay satırına değil senaryo, tenant ve zaman dilimine göre yapılmalıdır.

Beklenen çıktı

Temel triyaj çıktısı yapılandırılmış JSON olmalıdır:

{
  "karar": "supheli",
  "guven": "orta",
  "olay_ozeti": "Aynı varlıkta servis kurulumu ve ilişkili süreç çalışması gözlendi.",
  "kanit": [
    "Windows/System yeni servis olayı",
    "Sysmon services.exe child process olayı"
  ],
  "mitre_attack": ["T1543.003"],
  "onerilen_adim": "Zaman çizelgesini SIEM/EDR içinde doğrula; insan onayı olmadan aksiyon alma."
}

Çoklu-log görevinde ayrıca olay_tipi, kok_neden, etkilenen_varliklar ve zaman_cizelgesi alanları beklenir. Remediation katmanındaki her aksiyon citations, approval_required: true, auto_execute: false ve rollback bilgisi taşımalıdır. Kanıt yetersizse sistem tahmin uydurmak yerine yetersiz_kanit veya insufficient_evidence döndürmelidir.

Kurulum ve yükleme

NanoSOC deposu public görünse de taban model veya başka bağımlılıklar için Hugging Face kimlik doğrulaması gerekebilir. Erişim tokenını koda, notebook'a veya Git geçmişine yazmayın:

hf auth login
hf download GoktugD/Llama-NanoSOC1-8B --revision v8 --local-dir llama-nanosoc1-v8

Bu komut araştırma v8'ini indirir. Ticari mühendislik kapsamı, hukuk onayı alınana kadar, Kyoushi soyunu taşımayan revision="v2" adaptörü ve ayrı deterministik ürün katmanlarıyla sınırlandırılmıştır. v3–v8 ağırlıklarını ticari pakete kopyalamayın.

Python yükleme iskeleti:

import json
import torch
from huggingface_hub import snapshot_download
from peft import PeftModel
from transformers import AutoModelForCausalLM, AutoTokenizer, BitsAndBytesConfig

repo_id = "GoktugD/Llama-NanoSOC1-8B"
revision = "v8"
base_id = "fdtn-ai/Foundation-Sec-1.1-8B-Instruct"
base_revision = "243b27655e01c87cc04fdb88632be7cd9e55ac1f"

root = snapshot_download(repo_id, revision=revision)
tokenizer = AutoTokenizer.from_pretrained(root)
quant = BitsAndBytesConfig(
    load_in_4bit=True,
    bnb_4bit_quant_type="nf4",
    bnb_4bit_use_double_quant=True,
    bnb_4bit_compute_dtype=torch.bfloat16,
)
base = AutoModelForCausalLM.from_pretrained(
    base_id,
    revision=base_revision,
    quantization_config=quant,
    device_map="auto",
)

# Router sonucuna göre legacy_v2 veya correlation_v3 seçilir.
adapter_path = f"{root}/legacy_v2"
model = PeftModel.from_pretrained(base, adapter_path)

Çoklu-log isteğinde pipeline/nanosoc_v3_router.py ile correlation_v3 seçilmeli ve model çıktısı pipeline/apply_kademe3_evidence_gate.py üzerinden geçirilmelidir. Sadece adaptörü yükleyip kanıt kapısını atlamak v3–v8 için doğrulanmış kullanım değildir.

Kanıtlı remediation örneği:

python pipeline/nanosoc_remediate.py \
  "CVE-2026-8037 için kanıtlı remediation planı" \
  --corpus rag/rag-corpus.jsonl.gz

Benchmark sonuçları

Her sürüm farklı bir yeteneği ve farklı bir kalite kapısını ölçer. Satırlar birbirleriyle doğrudan "genel doğruluk artışı" olarak karşılaştırılamaz.

Aynı holdout'ta Foundation-Sec base → v6 → güncel v8 ilerlemesi

Aşağıdaki üç koşu aynı sıralı 1.000 HIKARI-2021 olayını kullanır: 200 malicious ve 800 benign. Holdout SHA-256 değeri c6aeace7e0c06df43bf06961cb495cc7a1d634a8193db0225cadbca756bf5f13, sıralı örnek kimliklerinin SHA-256 değeri 3e6cdb15d3e14d3cf69135e5f7c021bf6c65394e74942d7b828dbe845376ec30 olarak üç koşuda doğrulandı. Generation deterministik, taban revizyonu ve 4-bit NF4 koşulları aynıdır.

\* Base modelin FPR %0 değeri başarı değildir: model 800 negatifin tamamında görev sözleşmesine uygun sınıf üretemedi. Bu nedenle strict specificity %0, negative-unclassified oranı %100dür. v6 satırı bu görev için v6 ürün hattının devraldığı candidate5 detection route'unu ifade eder; v4–v6 ağırlıklı olarak deterministik ürün katmanları eklemiştir.

Sonuç gerçek ve ölçülebilir bir v6→v8 ilerlemesi gösterir; fakat v8 FPR %32,125 ile %3 ürün hedefini hâlâ geçemez. Bu aynı-set karşılaştırması offline/in-domain triyaj kanıtıdır; paket-seviyesi IDS, line-rate firewall veya kurumlar arası üretim genellemesi değildir. Makinece okunabilir rapor: benchmarks/foundation-v6-v8-same-holdout.json.

Orijinal Foundation-Sec ile NanoSOC karşılaştırması

Bu karşılaştırma 11 Ağustos 2026 tarihinde aynı sabit holdout kayıtları ve deterministik greedy generation (do_sample=false, en fazla 220 yeni token) kullanılarak RTX 3090 üzerinde çalıştırılmıştır. Her iki taraf aynı fdtn-ai/Foundation-Sec-1.1-8B-Instruct@243b276… ağırlığını 4-bit NF4 olarak yükler. Taban satırında adaptör yoktur; NanoSOC satırında v6 router'ın tek-log görevlerinde seçtiği ve SHA-256 değeri ca566574… olan legacy_v2 adaptörü vardır.

Pozitif sınıf supheli, negatif sınıf yetersiz_kanit olarak tanımlandı. Tespit oranı pozitif-class recall'dır. Beklenen karar alanını üretmeyen/geçersiz çıktı pozitif örnekte kaçırma, negatif örnekte ise doğru negatif değil, sınıflandırılamayan hata sayıldı. Bu muhafazakâr sözleşme taban modelin serbest metin cevabını yapay olarak başarılı göstermeyi engeller.

DNS/C2 holdout — 49 olay (33 pozitif, 16 negatif)

NanoSOC detection recall Wilson %95 güven aralığı %84,68–%99,46; specificity aralığı %44,40–%85,84'tür. Örneklem küçük olduğu için tek nokta tahmini üretim garantisi sayılmamalıdır.

Kademe 1 gerçek-log holdout — 40 olay (37 pozitif, 3 negatif)

Bu ikinci set saldırı ağırlıklıdır ve yalnız üç negatif içerir. NanoSOC tüm pozitifleri yakalamış, fakat üç negatifin tamamını da alarm yaptığı için specificity %0'dır; %92,5 accuracy değeri bu sınıf dengesizliği açıklanmadan tek başına kullanılmamalıdır. Recall Wilson %95 aralığı %90,59–%100, specificity aralığı %0–%56,15'tir.

Taban modelin bu tablolardaki %0 sonucu “genel siber güvenlik bilgisi %0” anlamına gelmez. Ölçülen şey, taban modelin NanoSOC'un Türkçe yapılandırılmış triyaj sözleşmesine adaptasyonsuz zero-shot uyumu ve aynı sözleşme altında olay tespitidir. Ham raporlar, scorer ve hash manifesti benchmarks/base-vs-nanosoc/ altında yayımlanmıştır.

Özet: NanoSOC bu iki dar sette çıktı sözleşmesi ve pozitif olay recall'ında büyük kazanım sağlar; ancak özellikle gerçek-log setindeki negatif specificity sonucu, gerçek tenant baseline'ı ve daha fazla temiz örnek olmadan üretim yanlış-alarm başarısı iddia edilemeyeceğini gösterir.

Sonuçların profesyonel yorumu

Mevcut kanıtlar üç farklı yeteneğin aynı olgunlukta olmadığını gösterir:

Bu nedenle “NanoSOC saldırıları yüksek oranda yakalıyor” ifadesi bu iki dar set için desteklenir; “her şeyi saldırı saymadan yakalıyor” veya “MITRE tekniğini güvenilir biçimde atıyor” ifadeleri ise henüz desteklenmez. Overall accuracy, saldırı ağırlıklı bir sette yüksek recall sayesinde yüksek görünebilir ve düşük specificity'yi saklayabilir. Üretim değerlendirmesinde recall mutlaka specificity, precision, false-positive rate ve sınıf dağılımıyla birlikte raporlanmalıdır.

v8 negatif-ağır ve ATT&CK deney sonucu

Önceden önerilen negatif-ağır deney v8'de 1.000 HIKARI olayıyla çalıştırıldı: 200 malicious ve 800 benign. Aynı sabit holdout'ta Foundation-Sec taban model NanoSOC JSON sözleşmesine hiç uyamadı. v8 sonuçları:

Bu tanı testi in-domain ve offline olay triyajıdır; paket/akış hızında IDS testi değildir. Recall %95 ve FPR %3 ürün hedeflerinin ikisi de geçilmedi.

ATT&CK attribution ayrı 24 teknikli holdout'ta ölçüldü: technique exact %0, macro-F1 %0, hierarchical parent accuracy %0, JSON valid %12,5 ve abstain %91,67. Dolayısıyla detection ile attribution başarısı birbirine eklenemez; attribution v8'in en açık darboğazlarından biridir.

Ayrı NetTiSA akış uzmanında Edge-IIoT validation recall %97,11 / FPR %0,148 iken dokunulmamış TON-IoT sonucu recall %80,91 / FPR %79,94 / ECE %16,07 olmuştur. Önceden dondurulmuş, negatif-ağır DNS-malware holdout'unda çok-kaynak aday recall %100 fakat FPR %100 vermiştir. Bu çapraz-kaynak sonuçlar veri-seti izlerinin genelleme sanılmaması gerektiğini gösterir; başarısız uzman ağırlıkları ürün sürümü olarak yayımlanmaz.

12 Ağustos 2026'da, sonucu görülmeden önce sözleşmesi ve checksum'u dondurulan ayrı NetTiSA HTTPS brute-force kaynağı 923.380 ham akıştan disk üzerinde ham CSV tutulmadan örneklendi. 79.530 olaylık test bölümünde tenant-relative aday recall %0, FPR %2,9825 ve ECE %48,40 verdi. Eşik temiz tenant baseline'ından seçildiği için yanlış alarm hedefi korunurken saldırıların tamamı kaçtı. Bu ağırlık ürüne alınmadı. Sonuç, şifreli brute-force tespitinde tek-flow özelliklerinin yeterli olmadığını; zaman pencereli tekrar, bağlantı durumu ve doğrulanmış auth başarısızlığı sinyallerinin ayrı stateful veri düzleminde gerekli olduğunu gösterir.

Aynı hipotez sekiz kaynak üzerinde çok-görevli MLP ile leave-one-source-out geliştirme testine sokuldu. Toplam 638.658 olayda macro FPR %2,888 iken macro recall %8,729, en iyi kaynak recall'ı %28,926 ve macro ECE %44,747 çıktı. Bu sonuç kaynaklar arası genellemeyi kanıtlamaz; deney geliştirme-bilinen ve promotion_allowed=false durumundadır. Ağırlıklar kaydedilmedi/yayımlanmadı.

Bu doğrultuda eklenen stateful firewall motorunun authored engineering fixture'ı 1.000 benign olayda 0 alarm ve port scan/brute-force/SYN flood senaryolarında 3/3 tespit verdi; monitor modunda hiçbir paket düşürmedi. Bu sonuç bağımsız PCAP, gerçek müşteri veya line-rate cihaz performansı kanıtı değildir.

v1–v8 sürüm kapıları

Bu sonuçlar nasıl okunmalı?

• —v1/v2 metrikleri dar, laboratuvar kaynaklı holdout üzerinde gerçek model üretimidir.
• —v3'te ham korelasyon adaptörü karar/olay tipi/MITRE alanlarında %83,33'tür. %100 sonucu router ve T1543.003 iki-kanallı kanıt kapısıyla birlikte çalışan 24 örneklik pipeline sonucudur.
• —v4, LLM genel doğruluğunu değil retrieval ve güvenli aksiyon sözleşmesini ölçer.
• —v5, deterministik güvenlik kontrollerini ölçer; sonlu injection kalıpları sürekli genişletilmelidir.
• —v6 gerçek şirket pilotu değildir. Risk skorları tenant izolasyonu ve audit davranışını sınamak için kontrollü fixture olarak verilmiştir.
• —Gerçek üretim false-positive, kritik saldırı recall ve incident F1 değerleri, onaylı/maskelenmiş 30–60 günlük tenant verisinde henüz ölçülmemiştir.

Makinece okunabilir ayrıntılar model deposundaki benchmarks/, evaluation/ ve ürün çalışma alanındaki artifacts/product-readiness.json dosyalarındadır.

Eğitim verisi ve RAG kökeni

• —Splunk Attack Data sabit revizyonu 416b4b2a4958eb41c3fbe7604f773fffeeedca6e (Apache-2.0): tek-log, DNS/C2 ve korelasyon senaryoları.
• —AIT/Kyoushi Scenario 1 (CC-BY-NC-SA-4.0): çoklu-log incident korelasyonu.
• —MITRE ATT&CK Enterprise 19.2, sabit revizyon 6cda5ad8462c79e14fbb872f4e09059b18e0cfc4.
• —CISA KEV 2026-08-07 aynası, sabit revizyon ca49071c856b46fab8410a4ab4213a245c750477.
• —Sigma r2026-04-01, sabit revizyon 0e3b749e0d85cd943706ed610a1447f0d54e8388.

RAG korpusu 5.492 belgedir: 697 MITRE, 1.662 CISA KEV, 3.132 Sigma ve 1 NanoSOC change-control kaydı. Sıkıştırılmış korpus yaklaşık 1,6 MB'tır. Büyük PCAP/TB arşivleri model deposuna alınmadı; kontrollü log dilimleri akışlı işlendi, provenance ve split bilgileri korundu.

Bilinen sınırlamalar

• —v2 DNS benchmarkında Cobalt Strike DNS olaylarının bir kısmı hedef T1572 yerine T1048.003 olarak eşlenmiştir. MITRE sonucu doğrulanmış detection kuralı ve analist tarafından kontrol edilmelidir.
• —Eğitim ve değerlendirme setleri küçük ve belirli saldırı ailelerine odaklıdır; yeni tenant, vendor, dil ve log şemasında dağılım kayması beklenebilir.
• —Türkçe yapılandırılmış SOC çıktısı hedeflenir ancak geniş kapsamlı Türkçe dil benchmarkı yoktur.
• —Prompt injection savunması tek bir regex katmanına indirgenemez; parser izolasyonu, ayrı trust boundary, allowlist ve red-team testi birlikte uygulanmalıdır.
• —RAG exact-ID yaklaşımı CVE/MITRE kimliği bulunmayan belirsiz sorgularda bilinçli olarak öneri üretmeyebilir.
• —pipeline/pilot.py bir referans uygulamadır; üretimde tenant-scope zorlayan kalıcı veri deposu, RBAC, şifreleme, retention ve merkezi audit sistemi gerekir.
• —Model çıktısı yanlış, eksik veya güncelliğini yitirmiş olabilir. Yüksek etkili kararların tamamı insan doğrulamasına tabidir.

Güvenli üretim kontrol listesi

Üretim pilotundan önce en az şunları uygulayın:

1. 1.Model, tokenizer, iki adaptör, RAG ve pipeline dosyalarını etiket/revizyon ve SHA-256 ile sabitleyin.
2. 2.Tenant/veri kaynağı bazında PII ve sır maskeleme uygulayın; ham logu eğitim deposunda biriktirmeyin.
3. 3.Train/validation/test ayrımını senaryo, zaman ve tenant bazında yapın; hash kesişimini sıfır tutun.
4. 4.Prompt içeriği ile log içeriğini ayrı trust boundary'lerde taşıyın.
5. 5.Düşük güven, bilinmeyen sınıf, eksik provenance veya eksik kanıtı insan kuyruğuna yönlendirin.
6. 6.Silme, izolasyon, engelleme, patch ve kimlik işlemlerinde zorunlu insan onayı ve rollback tutun.
7. 7.Her sonuçta model sürümü, kanıt, karar, onaylayan kişi ve audit hash'i saklayın.
8. 8.30–60 günlük maskelenmiş tenant baseline'ında false-positive, kritik recall ve drift eşiğini yeniden kalibre edin.
9. 9.Güncellemeden önce sabit regression setini çalıştırın; başarısızlıkta bilinen-iyi sürüme dönün.
10. 10.Modeli internetten doğrudan erişilen, kimlik doğrulamasız bir otomasyon servisi olarak açmayın.

Lisans ve kullanım koşulları

Built with Llama. Dağıtım/model adı Llama-NanoSOC1-8B, yerel Ollama etiketi llama-nanosoc1:8b ve ürün adı NanoSOC1dir. NanoSOC1 için tescilli marka iddiası yapılmaz.

• —v3 ve sonraki birleşik paketler AIT/Kyoushi CC-BY-NC-SA-4.0 eğitim etkisi içerdiği için ticari olmayan kullanım kapsamında değerlendirilmelidir.
• —Splunk Attack Data Apache-2.0; CISA KEV aynası CC0-1.0; Sigma içeriği Detection Rule License 1.1; MITRE içeriği ATT&CK Terms of Use kapsamındadır.
• —Taban modelin lisansı ve erişim koşulları ayrıca geçerlidir. Üçüncü taraf dağıtım veya ticari ürünleştirmeden önce tüm upstream lisanslar bağımsız hukuk incelemesinden geçirilmelidir.
• —Bu model kartı hukuki görüş değildir.

Depo düzeni

legacy_v2/                         tek-log ve DNS/C2 adaptörü
correlation_v3/                    çoklu-log korelasyon adaptörü
pipeline/nanosoc_v3_router.py      görev yönlendirme
pipeline/apply_kademe3_evidence_gate.py
pipeline/remediation.py            atıflı remediation
pipeline/model_security.py         injection/drift/confidence/rollback
pipeline/pilot.py                  tenant/audit/feedback referansı
rag/rag-corpus.jsonl.gz            sabit kaynaklı RAG korpusu
evaluation/                        v4-v6 değerlendirme raporları
reports/                           v3 ve regression raporları
benchmarks/v1-v6-benchmark.json    birleşik makinece okunabilir sonuç
progress.json                      son kademe durumu
nanosoc-manifest.json              revizyon ve bütünlük bilgileri

Atıf

Bu çalışma akademik veya teknik bir raporda kullanılırsa depo adı, kullanılan revision ve iki ortak geliştirici belirtilmelidir:

Llama-NanoSOC1-8B, revision v8 (research; not production-ready), GoktugD & girenit, 2026.
Base model: fdtn-ai/Foundation-Sec-1.1-8B-Instruct.

Sorun bildirirken logların maskelenmiş küçük bir örneğini, kullanılan revision'ı, seçilen adaptörü, pipeline kapılarını ve beklenen/gerçek yapılandırılmış çıktıyı paylaşın. Token, parola, gerçek kişi verisi veya kurum sırrı eklemeyin.

<!-- NANOSOCV10RESULTS_START -->

V10 — negatif-ağır detection düzeltmesi

V8'in başarısız olduğu negatif-ağır kapıya yönelik sürüm: eğitim karışımı 1:3 negatif-ağır kuruldu (5.700 negatif / 1.900 pozitif ağ + 1.200 ATT&CK attribution + 329 yetenek tekrarı), model seçimi yanlış-pozitife duyarlı 400 örneklik negatif-ağır dev ile yapıldı; başlangıç V8 adaptörüdür (1.200 adım, lr 6e-6, RTX 3090).

Bilinen gerileme: 24 senaryoluk bağımsız attribution diagnostiğinde V10 yüksek oranda çekimser kalır (abstain %91.7, json_valid %12.5). Negatif-ağır eğitim, attribution istem formatındaki "supheli" önyargısını bastırmıştır; V11 hattı bu sorunu hedefler. Ayrıntı: benchmarks/v10/.

Sınır: 1.000 olaylık holdout, V8 ile aynı sabit kümedir ve sürümler arası in-domain diagnostiktir; production genellemesi iddiası yapılmaz.

<!-- NANOSOCV10RESULTS_END -->

<!-- NANOSOCV13RESULTS_START -->

V11–V13 — hata-güdümlü sürüm ailesi ve harman

V10 sonrası hat, tek eksende oynayan bir hassasiyet/duyarlılık tahterevallisi ortaya koydu; V13 bu ödünleşimi eğitimsiz LoRA ağırlık interpolasyonuyla dengeler. Tüm ölçümler aynı sabit 1.000 olaylık HIKARI holdout üzerindedir:

• —V12, false_positive_rate <= 3% ürün kapısını geçen ilk sürümdür; recall bedeli nedeniyle yalnız düşük-alarm senaryolarında önerilir.
• —V13, 0.7*V10 + 0.3*V12 ağırlık harmanıdır (soup-manifest.json); ek eğitim olmadan V10'a göre FP'yi düşürüp F1 ve MITRE'yi yükseltir.
• —V14 (attribution aşısı, v13 tabanlı) attribution'ı çözmedi ama recall'u %99'a taşıdı — recall >= 95% kapısını geçen ilk sürüm (FP %18.9). Ailede artık iki uç kapı-geçer sürüm vardır: V12 (FP kapısı) ve V14 (recall kapısı); ikisini aynı anda geçen sürüm henüz yoktur.
• —Attribution kök nedeni V14 analizinde bulundu: model kısa Linux senaryolarında geçerli JSON üretir, uzun Windows senaryolarında istemi yankılar (echo). Sonraki hat sinyal kısaltma + daha fazla OTRF senaryosuyla bunu hedefleyecektir. Ayrıntı: benchmarks/v11..v14/. <!-- NANOSOCV13RESULTS_END -->

<!-- NANOSOCV16RESULTS_START -->

V16 — recall-maks deneme ve V15 karşılaştırması

V16, attribution çekimserliğini kırmak için OTRF senaryolarını çift-pencere ×8 tekrarıyla ağır bastığımız bir denemedir (init: v13 harman adaptörü, 260 adım). Attribution yine çözülmedi (echo sorunu kök-nedenli); ancak detection tarafında recall'u %99'a taşıdı — kaçırma maliyeti yüksek senaryolar için uç bir işletme noktası. Aynı sabit 1.000 olaylık HIKARI holdout:

• —V15 dengeli en iyi sürümdür ve kök olarak kalır.
• —V16, recall'u önceliklendiren dağıtımlar için branch olarak yayımlanmıştır; yüksek yanlış-pozitif oranı nedeniyle ikinci-aşama filtre/insan incelemesi gerektirir.
• —Attribution her iki sürümde de aynı seviyede çekimserdir; sonraki hat kısıtlı decoding (JSON grammar) ile bunu hedefleyecektir. Ayrıntı: benchmarks/v16/. <!-- NANOSOCV16RESULTS_END -->

<!-- NANOSOCV17RESULTS_START -->

V17 — üretim / düşük-alarm sürümü

Ürün gereksinimi: yanlış-pozitif oranı %5'in altında kalırken yakalamayı (recall) en üst düzeye çıkarmak — SOC analistlerini alarm yağmuruna tutmamak. V17, düşük-FP bölgesinde en iyi işletme noktasını bulmak için v11↔v12 ekseninde taranmış eğitimsiz LoRA harmanıdır. Aynı sabit 1.000 olaylık HIKARI holdout:

• —V17, düşük-alarm dağıtımları için önerilen üretim sürümüdür: FP'yi %5'in altında (%4,0) tutarken, aynı bölgedeki eski sürüm V12'yi hem recall (%66 vs %57,5) hem F1'de (%72,5 vs %68,3) geçer.
• —V15 dengeli/yüksek-recall kök olarak kalır (F1 %76,6, recall %87,5) — yakalamanın öncelikli olduğu dağıtımlar için.
• —İki sürüm, iki ürün profili: düşük-alarm (V17) ve yüksek-yakalama (V15). Attribution her iki sürümde de çekimserdir (bilinen sınır). Ayrıntı: benchmarks/v17/. <!-- NANOSOCV17RESULTS_END -->