Deep Review

deep-review — Çok-Ajanlı Derin İnceleme Orkestratörü

Bu skill bir orkestrasyon protokolüdür. Amaç: tek geçişte gözden kaçan şeyleri, işi paralel uzman ajanlara bölerek ve her ciddi bulguyu düşmanca doğrulayarak yakalamak. Çekirdek akış (recon → hunt → verify → synthesize) moda bağlı değildir; mod yalnızca hangi kontrol listesinin yükleneceğini belirler.

> Teknik gerçek (tasarımı belirler): Alt-ajanlar kendi alt-ajanlarını başlatamaz > (tek seviye nesting). Orkestrasyonu sen (bu skill'i çalıştıran ana model) yönetirsin: > ajanları sen başlatır, raporları sen toplar, doğrulamayı sen yaparsın. Ajanların > raporu sana döner — kullanıcıya değil; önemli olanı sen aktarırsın.

---

Faz 0 — KAPSAM (her çalıştırmada, İSTİSNASIZ ilk adım)

Bu skill savunma ve kalite içindir. Başlamadan önce:

1. Yalnızca kullanıcının sahibi/kontrol ettiği kodu incele. Üçüncü taraf canlı

sistemlere yönelik exploit/PoC/saldırı zinciri üretme. Kullanıcı "şu dış siteye/ sisteme sız/saldır" derse reddet ve savunma alternatifi öner.

1. Hedef belirsizse SOR — tüm repo mu, belirli dizin mi, yoksa git diff (pending

değişiklikler) mi? Deploy/PR öncesi kontrolde diff-only iyi bir varsayılandır.

1. Mod belirsizse SOR ya da çıkar: güvenlik mi (security), genel kod kalitesi mi

(review), mimari mi (architecture)? "Açık var mı / güvenlik / secret" → security. "Bu PR'ı incele / bug var mı" → review. "Tasarım / bağımlılık / katmanlar" → architecture.

1. Çıktı bulgu + kanıt + düzeltme + öğretici açıklama; çalışan saldırı aracı değil.

Kavramı göstermek için minimal, zararsız örnek payload olur (' OR 1=1--), gerçek bir hedefe otomatik uygulama YOK.

Bu adım hiçbir modda atlanmaz. Kapsam sınırı bu skill'in kimliğidir.

---

Faz 1 — RECON (kapsamı ve haritayı çıkar)

Amaç: körlemesine taramadan önce nereye bakılacağını bilmek.

Küçük hedefte (aşağıdaki eşiğe bak) bunu inline yap. Büyük hedefte tek bir recon ajanı başlat. Recon şunları üretir:

• Stack / diller / framework'ler (manifest + uzantılardan).
• Giriş noktaları (entry points): HTTP route'ları, CLI komutları, event handler'lar,

cron/zamanlanmış işler, webhook'lar, mesaj tüketicileri.

• Trust boundary'ler: kullanıcı→backend, backend→DB, servis→servis, internet→sunucu.
• Veri akışı: güvenilmeyen girdi nereden girip nereye (sink) akıyor.
• Mevcut savunmalar: ORM, auto-escape, framework CSRF/auth middleware, validasyon katmanı.
• Hassas varlıklar: secret'lar, para/bakiye, PII, private key, yetki kontrolleri.

Bu harita sonraki fazın ajanlarına bağlam olarak verilir. Detay ve ajan şablonu: references/orchestration.md.

---

Faz 2 — HUNT (boyuta göre inline ya da paralel fan-out)

Ölçekleme kararı (bu skill'in kalbi)

Her iş için ajan açma — israf. Hedefin boyutuna bak:

| Durum | Yaklaşım | |---|---| | Tek dosya, küçük diff (~birkaç yüz satır), dar soru | Inline tara — ajan yok | | Orta (bir alt sistem, ~birkaç dosya) | 2-3 ajan ya da inline, yargına göre | | Büyük kod tabanı / tam denetim / "her şeyi tara" | Fan-out: boyut/sınıf başına paralel ajan |

Eşikler ve gerekçe: references/orchestration.md. Örnek kalibrasyon: büyük bir web panelinde binlerce satırlık rota+servis katmanı ajanlara bölünür, ama tek ve küçük bir encryption_service.py inline okunur. Küçük ve kritik olanı kendin oku.

Ne aranır (moda göre)

• security → açık sınıfları: references/security-classes.md +

stack-özel kontroller: references/security-stacks.md

• review → correctness / basitleştirme / verimlilik / test kapsamı:

references/review-dimensions.md

• architecture → katmanlar, bağımlılık yönü, sınır ihlalleri, ölçek riskleri:

references/review-dimensions.md (mimari bölümü)

Hunt ajanları nasıl çalışır (iki-fazlı, taint'li)

Her hunt ajanı iki adımlı çalışır — bu, yanlış-pozitifi baştan azaltır:

1. Recon (yapısal): tehlikeli sink'leri / şüpheli inşa noktalarını bul, girdinin

nereden geldiğine henüz bakma.

1. Verify (taint): her adayı kaynağa kadar geriye izle — girdi gerçekten

güvenilmeyen kaynaktan mı geliyor (request.*, $_GET, form, webhook, DB'den okunan ikinci-el veri), arada bir savunma var mı? "Bunu görürsen GÜVENLİ" katalogları (references/security-classes.md) ile eleme yap.

Bir hunt ajanı doğrulanmış aday bulgular döndürür, ham şüphe değil.

---

Faz 3 — VERIFY (rapora girmeden önceki kalite kapısı)

Her aday bulgu 5 eksenden geçer (detay: references/security-classes.md):

1. Erişilebilirlik — kod bir giriş noktasından çağrılıyor mu, yoksa ölü kod mu?
2. Sanitizasyon — sink'e varmadan önce validasyon/escape/parametrizasyon araya giriyor mu?
3. Framework koruması — framework bu sınıfa karşı otomatik koruyor mu (ORM, auto-escape)?
4. Config mitigasyonu — CSP/WAF/güvenli-cookie gibi bir katman etkisini azaltıyor mu?
5. Bağlam — test/örnek/generated/vendor kodu mu, yoksa gerçek üretim yolu mu?

Bu eksenlerde güven düşükse severity'yi düşür (ör. teorik/erişilemez → Info).

Adversarial doğrulama (KRİTİK ve YÜKSEK bulgular için ZORUNLU)

Kritik/Yüksek bir bulgu, rapora girmeden önce şunlardan en az birini geçmeli:

• Çürütme ajanı: ayrı bir ajan, bulguyu yanlışlamaya çalışır ("bu neden GERÇEK

DEĞİL / sömürülemez olabilir?"). Belirsizlikte varsayılan "çürütüldü". Çürütülemezse gerçek.

• Canlı/çalışan-kod testi: bulguyu kullanıcının KENDİ ortamında/testinde uygula ve

davranışı gözlemle. (Örn. bir XSS payload'ını gerçekten çalıştırıp string bağlamından kaçtığını görmek, ya da bir endpoint'in 500 döndürdüğünü test etmek. Bu, bir ajanın "şu kod şu yan etkiyi yapıyor" iddiasını çürütmek için de işe yarar — kodda zaten bir guard varsa canlı test bunu ortaya çıkarır ve yanlış bulgu rapora girmez.)

Doğrulanamayan kritik/yüksek bulgu rapora "doğrulandı" olarak GİRMEZ — "şüpheli / doğrulanması gerekiyor" olarak işaretlenir. Orta/düşük için 5-eksenli statik eleme yeterlidir. Protokol: references/orchestration.md.

---

Faz 4 — SYNTHESIZE (rapor)

Bulguları en yüksek severity önce sırala. Format ve severity baseline: references/report-format.md. Her bulgu: konum (dosya:satır), sınıf, neden sömürülebilir/yanlış (öğretici, 1-2 cümle), etki, somut düzeltme, güven düzeyi ve (varsa) kullanıcının kendi ortamında çalıştıracağı doğrulama testi.

Sonda özet tablo + öncelikli 3 aksiyon. Hiç bulgu yoksa bunu açıkça söyle ve taranan kapsamı belirt — "temiz" de bir sonuçtur, ama neyin tarandığını yaz.

Diff modunda her bulguyu YENİ (değişiklikle geldi) / MEVCUT (dokunulan eski kodda zaten vardı) diye ayır ve verdict ver: yeni Kritik/Yüksek → FAIL.

---

Faz 5 — İstenirse: DÜZELT

Kullanıcı "düzelt" derse: en kritikten başla, minimal ve mevcut kod stiline uygun yamalar uygula, her düzeltmeyi doğrula (düzeltmeden önceki hatalı davranışı hedefleyen test), sonra ne değiştiğini özetle. Kırıcı değişiklikten önce alternatif öner. Kullanıcının kararı gereken şeyleri (mimari, router adresi gibi geri-alınamaz seçimler) kendin verme, sor.

---

Referans dosyaları (moda göre yükle — hepsini birden okuma)

• references/orchestration.md — fan-out eşikleri, ajan prompt şablonları, adversarial protokol
• references/security-classes.md — açık sınıfları, "GÜVENLİ kalıp" katalogları, 5-eksen FP eleme
• references/security-stacks.md — stack-başı kontroller, secret FP listesi
• references/review-dimensions.md — kod-inceleme + mimari modu boyutları
• references/report-format.md — severity baseline, rapor iskeleti, dynamic test, diff verdict

Kaynak / atıf

Orkestrasyon ve checklist fikirleri kısmen iki MIT-lisanslı projeden uyarlandı: utkusen/sast-skills (iki-fazlı recon+verify, taint, patterns-that-prevent) ve ersinkoc/security-check (5-eksen FP eleme, diff new/existing, race & mass-assignment sınıfları). Kapsam/etik guard ve adversarial-verify disiplini bu skill'e özgüdür.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: managertaylankozan-blip
• Source: managertaylankozan-blip/claude-security-skills
• License: MIT

Install and usage instructions live in the source repository linked above.