Tue Aug 18 2026
Merhaba arkadaş! 👋
Geçenlerde GitHub’un 50 açık kaynak AI projesini derinlemesine inceledi. Sonuçlar? Hem heyecan verici hem de biraz ürkütücü. İşte özetle ne gördük:
Bu rakamlar bize bir şey anlatıyor: AI sistemlerimizi korumak için eldeki “kontrol listesi” şart.
Bu yazı, geliştiricilerin ve güvenlik ekiplerinin yanına koyabilecekleri somut bir tehdit modelleme ve azaltma kontrol listesi sunuyor. Ben de listeyi hazırlarken şunları öğrendim:
Sen de bu listeyi al, projene uyarlayıp hemen uygulayabilirsin. Hazırsan başlayalım! 🚀
Hazırsan başlayalım 🚀
Benim takip ettiğim süreç 5 basit adımda özetlenebilir:
codeql database create)security-and-quality kullanıldıslsa-verifier ile doğrulama atlandıNe kazandı bu akış?
Hadi bir sonraki bölümde bu pipeline’ı GitHub Actions ile nasıl otomatikleştirdiğimi anlatayım! 🛠
Hazırsan başlayalım 🚀 — bu üç kategori, günlük geliştirme işlerimizde sıkça karşılaştığımız ve kolayca atladığımız riskler. Her birini birer gerçek dünya örneğiyle, risk seviyesi ile birlikte inceleyelim. Unutma: Bu açıklar senin projenizde de olabilir ⚠️
✅ Bu adımları bugün uygularsan, yarın “Ben de etkildim” demek zorunda kalmazsın. Hadi güvenli kod yazmaya devam edelim! 🚀
Hazırsan klasik STRIDE modelini bir özetleyelim, sonra AI sistemlerine özel yeni tehditleri ekleyip kendi projen için kullanabileceğin bir şablon hazırlayalım 🚀
| Harf | Tehdit Türü | Ne Anlama Gelir? |
|---|---|---|
| S | Spoofing (Kimlik Avı) | Kullanıcı/sistem kimliği aldatılır |
| T | Tampering (Değiştirme) | Veri veya kod yetkisiz değiştirilir |
| R | Repudiation (İnkâr) | İşlem yapıldığı iddia edilip reddedilir |
| I | Information Disclosure (Bilgi Sızıntısı) | Hassas veri yetkisiz ortaya çıkar |
| D | Denial of Service (Hizmet Reddi) | Sistem kullanılamaz hale getirilir |
| E | Elevation of Privilege (Yetki Yükselmesi) | Düşük yetkili kullanıcı yönetici olur |
Kısaca: STRIDE, bir sistemdeki her bileşeni bu altı perspektiften taramanı sağlar. AI projelerinde de temel bir iskelet olarak kalır.
Klasik altı kategori yeterli değil; model eğitimi, veri hattı ve dağıtım süreci yeni saldırı yüzeyleri getiriyor. İşte en sık karşılaşılan üç ek kategori:
| Yeni Kategori | Açıklama | Neden Önemli? |
|---|---|---|
| Model Inversion 🔁 | Saldırgan, modelin çıktılarından eğitim verisini (veya kullanıcı verisini) tersine mühendislik yapar. | Gizlilik ihlali, GDPR/ KVKK riski |
| Adversarial Input ⚔️ | Küçük, gözlemlenemez gürültülerle modeli yanlış tahmin yapmaya zorlar. | Güvenilirlik, güvenlik (ör. otonom sürüş) |
| Supply Chain Compromise 📦 | Eğitim verisi, kütüphane, model ağırlıkları veya CI/CD hattı kötü niyetli değiştirilir. | Tüm yaşam döngüsü tehlike altına girer |
Not: Bu üç kategori STRIDE’nin S, T, I harfleriyle örtüşse de, AI‑specific etkileri (model ağırlıkları, veri seti provenance, inference API) ayrı analiz gerektirir.
Aşağıdaki tabloyu kopyala, projene göre doldur. Ben bu tabloyu nasıl doldurdum, sen de dene diyorum — her satırda kendi bileşenin, STRIDE+AI perspektifini yaz.
| # | Bileşen / Akış | STRIDE Temel | AI Özel Genişletme | Olası Etki | Mevcut Kontrol | Kalan Risk | Aksiyon / Sahip |
|---|---|---|---|---|---|---|---|
| 1 | Veri toplama (raw logs) | S, T, I | Supply Chain Compromise | Veri zehirlenmesi → model bias | İmza doğrulama, hash kontrolü | Orta | Veri mühendisi – imza otomasyonu ekle |
| 2 | Model eğitimi (GPU cluster) | T, E | Model Inversion | Eğitim verisi sızdırılabilir | Differential privacy, erişim kontrolü | Düşük | ML engineer – DP parametrelerini gözden geçir |
| 3 | Inference API (REST) | S, D | Adversarial Input | Yanlış tahmin → iş zararı | Rate limiting, input validation, adversarial detection | Yüksek | Platform takım – WAF + adversarial filter ekle |
| 4 | Model kayıt defteri (MLflow) | S, T, I | Supply Chain Compromise | Kötü model versiyonu dağıtılır | İmzalı artifact, RBAC | Orta | DevOps – cosign + policy enforcement |
| 5 | Monitoring / Loglama | I, D | — | Anomali kaçırılır | Central log, alerting | Düşük | SRE – model drift alarm kur |
Nasıl doldurdum?
💡 İpucu: Tabloyu bir Markdown dosyası olarak repo’dan
threat-model.mdiçine koy. PR açarken “Threat model güncellendi” yaz — ekip review eder, eksikler aniden belirgin olur.
Özetle:
Hazırsan bir kahve al, diagramı aç ve tabloyu doldurmaya başla ☕️🚀
SBOM (Software Bill of Materials) oluşturma 📦
syft veya cyclonedx-gen araçlarıyla CI/CD pipeline’ınıza ekleyin; üretilen SBOM dosyasını (SPDX / CycloneDX) artifact olarak saklayın.İmzalı bağımlılıklar (Signed Dependencies) ✍️
npm/yarn için npm audit signatures, pip için pip install --require-hashes, Go için go verify kullanın; imza doğrulamasını CI adımı olarak zorunlu kılın.Dependabot / Renovate otomasyonu 🤖
dependabot.yml veya Renovate config dosyası ekleyin; schedule: daily, labels: security, auto‑merge: minor/patch ayarlarıyla çalıştırın.Minimum ayrıcalıkla container imajları (Least‑Privilege Images) 🐳
USER nonroot ekleyin, RUN chmod -R 550 /app gibi izinleri kısıtlayın; docker scout/trivy ile tarayın.SLSA (Supply‑chain Levels for Software Artifacts) seviyesi kontrolü 🔐
slsa-verifier ile provenance dosyasını doğrulayın; CI’da slsa-github-generator / slsa-framework kullanarak SLSA Level 2 (tam provenance) veya Level 3 (hardened build) hedefleyin.Hazırsan bu aşamada devreye giren model eğitimi ve çıktı doğrulama kontrollerini tek tek geçelim. Her madde için sana pratik bir "nasıl yapılır" ipucu da ekledim — böylece sadece "ne yapmalı" değil, "nasıl yapmalı" da netleşsin 🎯
Veri kalitesini eğitimden önce kilitle. Boşluklar, outliers, label noise veya veri sızıntısı (data leakage) modeli çökertebilir.
Pratik ipucu:
Great Expectations veya pandera ile veri şemasını CI/CD'ye ekle. Her git pushta veri seti bu şemaya göre test edilsin ⛔
# .github/workflows/data-validation.yml
- name: Validate training data
run: |
great_expectations checkpoint run training_data_checkpoint
Ne kazandık? Veri bozuksa pipeline erken durur, GPU saatin boşa gitmez.
Hassas verilerle eğitiyorsan, modelin "ezberlemesini" engellemek için DP-SGD gibi yöntemler şart.
Pratik ipucu:
Opacus (PyTorch) veya TensorFlow Privacy kütüphanesini eğitim döngüsüne entegre et. epsilon ve delta parametrelerini compliance ekibiyle belirle 📐
from opacus import PrivacyEngine
privacy_engine = PrivacyEngine()
model, optimizer, train_loader = privacy_engine.make_private(
module=model,
optimizer=optimizer,
data_loader=train_loader,
noise_multiplier=1.0,
max_grad_norm=1.0,
)
Ne oluyor? Gradyanlara gaussian noise eklenir, tek bir kayıt modeli etkileyemez.
Model üretimde PII (kişisel veri), toxic language veya hallucination üretebilir. Çıktıyı filtrelemeden kullanıcıya verme.
Pratik ipucu:
Inference servisin önüne bir guardrail katmanı koy. Guardrails AI, NeMo Guardrails veya kendi regex/ML tabanlı filtrelerin olabilir 🛡
# Basit PII maskeleme örneği
import re
def sanitize_output(text: str) -> str:
# E-posta, TC kimlik no vb. maskeler
text = re.sub(r'\b\d{11}\b', '[TC_KIMLIK]', text)
text = re.sub(r'[\w\.-]+@[\w\.-]+', '[EMAIL]', text)
return text
Kural: Hiçbir ham model çıktısı kullanıcıya doğrudan gitmesin.
Modeli "kırarak" test et: prompt injection, jailbreak, out-of-distribution (OOD) girdiler.
Pratik ipucu:
GitHub Actions ile her PR'da promptfoo veya garak adversarial suite'ini koştur. Başarısız olursa merge bloklansın 🚫
# .github/workflows/adversarial-test.yml
- name: Run adversarial tests
run: |
pip install promptfoo
promptfoo eval -c promptfoo.config.yaml
Test et:
Modeli %100 trafiğe atmadan önce canary ile canlı trafikte gözlemle.
Pratik ipucu:
Argo Rollouts veya Flux ile traffic splitting yap. İlk %5 canary, metrikler iyiyse %25, %50, %100'e çıkar 📈
# Argo Rollouts örneği
strategy:
canary:
steps:
- setWeight: 5
- pause: {duration: 10m}
- setWeight: 25
- pause: {duration: 30m}
- setWeight: 100
Ne sağlar? Kötü bir model production'ı yıkmadan geri alınır.
Sadece accuracy yeterli değil. Production'da şunları gerçek zamanlı izle:
| Metrik | Neden Önemli? | Alarm Eşiği Örneği |
|---|---|---|
| Prediction latency (p95) | Kullanıcı deneyimi | > 500ms |
| Error rate (5xx) | Model/sunucu hatası | > 1% |
| Data drift (PSI / KS test) | Girdi dağılımı değişti | PSI > 0.2 |
| Concept drift (label dağılımı) | Gerçek dünya değişti | Haftalık %10+ sapma |
| Confidence distribution | Model "emin değilse" riskli | Düşük confidence oranı > %20 |
| Toxic / PII leakage rate | Güvenlik / yasal | > 0 |
Pratik ipucu:
Prometheus + Grafana dashboard'ına model-specific panel ekle. Evidently AI veya WhyLogs ile drift raporlarını otomatik üret, Slack'e gönder 📬
# PrometheusRule örneği
- alert: ModelDataDriftHigh
expr: psi_score > 0.2
for: 15m
labels:
severity: warning
annotations:
summary: "Model {{ $labels.model }} veri driftı tespit edildi (PSI={{ $value }})"
MODEL_TRAINING_CHECKLIST.md) ve repo'ya koy.Küçük bir hatırlatma: Bu liste "bitirip unut" değildir. Model yaşam döngüsü boyunca her retrain/deploy'da tekrar edilir. Otomatize edebileceğin her şeyi otomatize et — sen stratejik kararları ver 💪
Hazır mısın? Şimdi bir sonraki aşamaya: Model Kayıt ve Versiyonlama (Model Registry) 🚀
Hazırsan bu maddeyi hızlıca geçelim. Küçük bir ekiple bile temel güvenlik alışkanlıkları koyarsanız, ileride büyük baş ağrılarından kurtulursunuz 🚀
public, internal, confidential, restricted gibi basit etiketlerle başlayın.read/write kendi repo, ops → read production logları.| Katman | Ne Yapmalı? |
|---|---|
| Depolama (S3, EBS, Azure Blob, GCS) | SSE‑S3 / SSE‑KMS / CMEK etkinleştirin. |
| Veritabanı (RDS, Cloud SQL, Cosmos) | Transparent Data Encryption (TDE) + KMS anahtarı. |
| Ağ | TLS 1.2+ zorunlu; internal traffic için mTLS veya VPC‑peering + security groups. |
| CI/CD artifact | Signed, encrypted artifact store (cosign, sigstore). |
Küçük ekip ipucu: Terraform/CloudFormation şablonlarınızda
encryption = truedefault yapın; manuel unutma riskini sıfırlayın 🛠️
Glacier, 7 yıl sonra Delete 📦Bu adımların hepsi “büyük kurumsal” gibi görünse de, her biri 15‑30 dakika içinde otomatize edilebilir. Başlangıçta manuel yaparsanız bile, alışkanlık haline getirince güvenlik kültürü ekibinizin DNA’sına işler 🎉
Hazırsan bir sonraki kontrol listesi maddesine geçebiliriz: “🛡️ Ağ ve Uygulama Güvenliği”.
Hazırsan aşağıdaki tek bir workflow dosyası ile dört temel güvenlik kontrolünü bir arada koşturabilirsin:
İpucu: Bu dosyayı repo kök dizininde
.github/workflows/security.ymlolarak kaydet. Herpushvepull_requesttetiklendiğinde güvenlik kontrolleri otomatik çalışır ✅
security.yml (tam örnek)name: 🔒 Güvenlik Taramaları
on:
push:
branches: [ main, develop ]
pull_request:
branches: [ main, develop ]
schedule:
- cron: '0 2 * * 1' # her pazartesi 02:00 UTC'de de çalıştır
permissions:
contents: read # kod okuma yetkisi
security-events: write # CodeQL sonuçlarını yazabilmek için
packages: read # container imajı çekmek için
jobs:
# -------------------------------------------------
# 1️⃣ CodeQL – Statik Analiz
# -------------------------------------------------
codeql-analysis:
name: CodeQL Analizi
runs-on: ubuntu-latest
strategy:
matrix:
language: [ javascript, typescript, python, go ] # projenize göre düzenleyin
steps:
- name: ⬇️ Repo checkout
uses: actions/checkout@v4
- name: 🛠 CodeQL veritabanı oluştur
uses: github/codeql-action/init@v3
with:
languages: ${{ matrix.language }}
- name: 🔎 CodeQL analizi çalıştır
uses: github/codeql-action/analyze@v3
with:
category: "/language:${{ matrix.language }}"
# -------------------------------------------------
# 2️⃣ Dependabot – Bağımlılık Uyarıları
# -------------------------------------------------
dependabot-alerts:
name: Dependabot Uyarıları
runs-on: ubuntu-latest
steps:
- name: ⬇️ Repo checkout
uses: actions/checkout@v4
- name: 📦 Dependabot uyarılarını çek
uses: dependabot/fetch-metadata@v2
id: dependabot_meta
with:
github-token: ${{ secrets.GITHUB_TOKEN }}
- name: ⚠️ Uyarı varsa job'u fail et
if: steps.dependabot_meta.outputs.alert-count > 0
run: |
echo "❗️ ${{ steps.dependabot_meta.outputs.alert-count }} adet Dependabot uyarısı bulundu."
exit 1
# -------------------------------------------------
# 3️⃣ Trivy – Container İmajı Tarama
# -------------------------------------------------
trivy-scan:
name: Trivy Container Tarama
runs-on: ubuntu-latest
needs: [ codeql-analysis ] # CodeQL bittikten sonra başlasın
steps:
- name: ⬇️ Repo checkout
uses: actions/checkout@v4
- name: 🐳 Docker imajı build et (örnek)
run: |
docker build -t myapp:${{ github.sha }} .
- name: 🔍 Trivy ile tara
uses: aquasecurity/trivy-action@master
with:
image-ref: 'myapp:${{ github.sha }}'
format: 'sarif'
output: 'trivy-results.sarif'
severity: 'CRITICAL,HIGH'
- name: 📤 Sonuçları GitHub Security'e yükle
uses: github/codeql-action/upload-sarif@v3
with:
sarif_file: 'trivy-results.sarif'
# -------------------------------------------------
# 4️⃣ Syft – SBOM Üretimi
# -------------------------------------------------
syft-sbom:
name: SBOM Üretimi (Syft)
runs-on: ubuntu-latest
needs: [ trivy-scan ] # Trivy bittikten sonra çalıştır
steps:
- name: ⬇️ Repo checkout
uses: actions/checkout@v4
- name: 🐳 Docker imajı build et (tekrar kullanım için)
run: |
docker build -t myapp:${{ github.sha }} .
- name: 📄 SBOM oluştur
uses: anchore/syft-action@v1
with:
image: 'myapp:${{ github.sha }}'
output-format: 'spdx-json'
output-file: 'sbom.spdx.json'
- name: 📦 SBOM artifact olarak kaydet
uses: actions/upload-artifact@v4
with:
name: sbom-${{ github.sha }}
path: sbom.spdx.json
retention-days: 30
| Adım | Ne Oldu? |
|---|---|
| CodeQL | Seçtiğiniz diller için statik analiz yaptı, bulguları Security sekmesine gönderdi. |
| Dependabot | Mevcut uyarı sayısını kontrol etti, uyarı varsa pipeline fail etti. |
| Trivy | Oluşturduğunuz Docker imajını taradı, kritik/yüksek seviye bulguları SARIF olarak yükledi. |
| Syft | Aynı imajdan SPDX formatında SBOM üretti ve artifact olarak sakladı. |
Sonuç: Bu workflow’u
.github/workflows/security.ymlolarak ekleyip push ettikten sonra, her commit/push/pull‑request anında kod, bağımlılık, container ve bileşen envanteri güvenlik kontrolünden geçer 🎯. Kolay gelsin!
Hazırsan başlayalım 🚀
Aşağıda hem Markdown tablo hem de JSON formatında kullanabileceğin hazır bir şablon var. Alanlar: Bileşen, Tehdit Türü (STRIDE+AI), Etki, Olasılık, Azaltma Önlemi, Sorumlu.
| Bileşen | Tehdit Türü (STRIDE+AI) | Etki | Olasılık | Azaltma Önlemi | Sorumlu |
|---|---|---|---|---|---|
| ör. API Gateway | Spoofing / Model Inversion | Yüksek | Orta | Mutual TLS + Rate limiting | Backend Takımı |
| ör. Veritabanı | Tampering / Data Poisoning | Kritik | Düşük | Şifreleme + İmza doğrulama | Veri Mühendisliği |
| ... (kendi bileşenlerinizi ekleyin) | *... * | *... * | *... * | *... * | *... * |
Nasıl kullanılır?
threat-model.md olarak kaydedin.[
{
"bilesen": "API Gateway",
"tehdit_turu": "Spoofing / Model Inversion",
"etki": "Yüksek",
"olasilik": "Orta",
"azaltma_onlemi": "Mutual TLS + Rate limiting",
"sorumlu": "Backend Takımı"
},
{
"bilesen": "Veritabanı",
"tehdit_turu": "Tampering / Data Poisoning",
"etki": "Kritik",
"olasilik": "Düşük",
"azaltma_onlemi": "Şifreleme + İmza doğrulama",
"sorumlu": "Veri Mühendisliği"
}
// Kendi bileşenlerinizi buraya ekleyin...
]
Ne sağlar?
İpucu: Şablonu kopyala, proje dizinine
threat-model.mdolarak kaydet ve ekiple gözden geçir. Böylece tehdit modellemesi sürekli ve paylaşılan bir süreç haline gelir. 🛡️
Hazırsan bu yazıyı bir kafe molası gibi düşün, kahveni alıp oturalım ☕️
Güvenlik tek seferlik bir checklist değil, günlük bir alışkanlık. Bir kere “tamam, hepsi güvende” diyip yanınıza koyamazsınız. Sürekli gelişen tehditlerle ayakınızı tutmak için kültürünüzü de sürekli beslemeniz lazım.
Kod inceleme toplulukları oluşturun
Güvenlik şampiyonları (Security Champions) programı başlatın
Haftalık “Threat Modeling Coffee” toplantıları 📅
Otomatik güvenlik kontrollerini CI/CD’ye gömün 🤖
Başarıları ve “near‑miss”leri paylaşın 🎉
Güvenlik bir maraton, sprint değil. Küçük, sürekli adımlarla güvenli kod yazma kültürünü ekibinizin DNA’sına işlersiniz. 🎯
Hadi, bu hafta ilk “Threat Modeling Coffee” toplantısını planlayalım mı? ☕️🚀
Bu içerik tamamen yapay zeka destekli otomasyon sistemi ile üretilmiştir.
All rights reserved