dynamic-pentest

Files (1)

• SKILL.md

SKILL.md (first lines)

# dynamic-pentest — Claude'un kendisiyle dinamik pentest

> **Neden var:** Daha önce bu iş `strix-scan` skill'iyle harici bir CLI'a
> (Strix, Docker sandbox + LiteLLM üzerinden üçüncü parti bir model)
> devrediliyordu. Bu, kendi başına bir bağımlılık zinciri (Docker, ayrı bir
> LLM erişimi/kredi/OAuth, ayrı bir CLI kurulumu) getiriyordu ve 2026-09
> içinde birden fazla kez canlı olarak çöktü (bkz. proje hafızası —
> OmniRoute üzerinden geçirilen kredi/rate-limit arızaları). Kullanıcının
> kararı: dinamik pentest'i ayrı bir araca değil, doğrudan Claude'a
> (bir alt-ajana, gerçek shell erişimiyle) yaptır — ekstra kurulum,
> ekstra kimlik doğrulama, ekstra arıza noktası yok. `strix-scan` skill'i
> bu kararla birlikte kaldırıldı.

## Bu mu, yoksa `security-scan`/`trivy-scan`/`red-team` mi?

| Soru | `dynamic-pentest` (bu skill) | `security-scan` | `trivy-scan` | `red-team` |
|---|---|---|---|---|
| Yöntem | **Dinamik** — gerçekten çalıştırır, gerçek girdi gönderir | Statik (bandit/detect-secrets) | Statik (CVE/IaC/secret DB) | LLM kod okuması |
| Kanıt türü | Gerçek istek/yanıt çifti veya gerçek fonksiyon çağrısı sonucu | Kural eşleşmesi | Bilinen imza (CVE) | Muhakeme/yorum |
| Kim çalıştırır | Claude'un kendisi (subagent, Bash/curl ile) | Yerel scanner script'i | Trivy MCP | Claude (salt-okunur) |
| Ekstra bağımlılık | Yok — mevcut Bash/curl/proje runtime'ı yeterli | detect-secrets/bandit/pip-audit | trivy binary/MCP | Yok |
| Süre/maliyet | Orta (birkaç dakika — birkaç deneme turu) | Saniyeler | Saniyeler-dakikalar | Dakikalar |
| ATDD pipeline gate'i | 🟡 koşullu (`red-team`'in yanına) | ✅ `verify` gate 10 | ❌ serbest kullanım | ✅ pazarlıksız adım |

**Kısa kural:** Hızlı/ucuz bir kontrol mü lazım → `security-scan`/`trivy-scan`.
Bir bulgunun **gerçekten sömürülebilir olup olmadığını**, gerçek bir istek/
çağrıyla kanıtlamak mı istiyorsun → bu skill.

## Pipeline'daki yeri — koşullu, `red-team`'in yanında
`strix-scan`'in eski yeriyle aynı: `atdd.md`'de `threat-model`'in ürettiği
gerçek bir `AC-S<n>` kriteri varsa (auth/yetkilendirme/ödeme/kişisel veri/
multi-tenant/dosya yükleme gibi kanıtlanmış risk), `red-team` bittikten sonra
kullanıcıya önerilir — otomatik çalışmaz, onay ister. `AC-S` yoksa bu skill
tamamen devre dışı kalır, sadece kullanıcı özellikle isterse elle çağrılır.

Kısaca: `red-team` bulguyu **muhakeme ile** bulur, bu skill onu **gerçek bir
deneme ile kanıtlar** — ikisi aynı işi yapmaz, biri diğerinin yerini almaz.

## Yöntem

### 1. Hedefi ve yüzeyi belirle
`atdd.md`'nin `AC-S<n>` kriterlerini ve `code_diff.md`'yi oku. İki durum var:

- **Gerçek bir HTTP ucu varsa** (canlı sunucu, `preview_start`/`uvicorn`/
  benzeriyle ayağa kaldırılabilir): hedef budur, gerçek HTTP istekleri
  atılacak.
- **HTTP yüzeyi henüz yoksa** (bu proje gibi — sadece servis katmanı
  fonksiyonları var, ör. `can()`/`scoped_*()`): hedef, o fonksiyonların
  KENDİSİDİR. "Dinamik" olan şey ağ isteği değil, **gerçek adversarial
  girdiyle gerçek bir Python/Node/vb. süreç içinde çalıştırma** — statik
  kod okumaktan (`red-team`) farkı budur.

### 2. Saldırı senaryolarını AC-S kriterlerinden türet
Her `AC-S<n>` için somut bir saldırı denemesi tanımla — `threat-model`'in
zaten yazdığı "saldırganın somut girdisi + beklenen gözlenebilir sonuç"
formatını kullan. Örnekler:
- IDOR/tenant izolasyonu: Principal A'nın kimliğiyle Principal B'nin
  kaynağına gerçekten erişmeyi dene (gerçek DB'ye karşı, gerçek fonksiyon
  çağrısıyla) — dönen sonucu kanıt olarak kaydet.
- SQL/command injection: gerçek bir uçtan/fonksiyondan `' OR 1=1--` gibi
  payload'ı gerçekten gönder, ham SQL hatası/veri sızıntısı olup olmadığını
  gözlemle.
- Auth bypass: geçersiz/süresi dolmuş/başkasına ait bir token'la gerçek bir
  korumalı uca gerçekten istek at.
- Privilege escalation: düşük yetkili bir principal ile yüksek yetki
  gerektiren bir eylemi gerçekten çağır.

### 3. Alt-ajana dispatch et — gerçek çalıştırma burada olur
Ana ajan (orkestratör) kendi bağlamında saldırı komutlarını biriktirmez —
`general-purpose` bir subagent'a dispatch eder (model: `sonnet` veya `opus`,
**Haiku KULLANMA** — gerçek exploit tasarımı güçlü muhakeme ister).

```
Agent({
  description: "Dynamic pentest: <task-slug>",
  subagent_type: "general-purpose",
  model: "sonnet",
  run_in_background: false,
  prompt: "<aşağıdaki self-contained prompt>"
})
```

Prompt şablonu:
```
Proje kökü (MUTLAK yol): <ABSOLUTE PROJECT ROOT>
Hedef: <HTTP URL'si VEYA test edilecek fonksiyonun modül yolu>
Bağlam: atdd.md'yi Read et: <mutlak yol> — AC-S<n> kriterlerine odaklan.

## Görev
Aşağıdaki her saldırı senaryosunu GERÇEKTEN DENE (kod okuyarak tahmin etme,
gerçekten çalıştır — Bash/curl/python -c ile):
<2. adımdaki somut senaryo listesi>

Her senaryo için:
1. Tam olarak ne çalıştırdığını (komut/istek) kaydet.
2. Tam çıktıyı/yanıtı (stdout+stderr, veya HTTP status+body) kaydet.
3. Beklenen güvenli davranışla (atdd.md'nin AC-S'i) karşılaştır — sömürülebilir mi, değil mi, somut kanıtla söyle.

## Güvenlik sınırları (zorunlu)
- Sadece bu proje kökü içindeki hedeflere veya kullanıcının açıkça verdiği
  yerel/test ortamına yönel. Kullanıcının sahibi olmadığı bir dış domain/IP'ye
  ASLA istek atma.
- Yıkıcı işlem yapma: gerçek veri SİLME, prod'a yazma, `DROP`/`DELETE` gibi
  SQL komutlarını gerçek/paylaşılan bir veritabanında ÇALIŞTIRMA — sadece
  yerel/test/geliştirme veritabanına karşı, ve mümkünse bir transaction
  içinde/rollback ile çalış.
- Kod yazma/düzeltme — sadece dene ve gözlemle, bulgu raporla.
- GİT KOMUTU ÇALIŞTIRMA — add/commit/checkout/reset/restore/stash dahil
  hiçbir git komutu kullanma.

## Rapor formatı (yanıtının sonunda)
Her senaryo için: senaryo adı, çalıştırılan komut/istek, gerçek çıktı/yanıt,
sömürülebilir mi (evet/hayır/belirsiz) + gerekçe.
```

### 4. Sonucu `dynamic_pentest.json` olarak kaydet
`obss_project/artifacts/<task-slug>/dynamic_pentest.json`:

```json

From yutronax/atdd-pipeline-skills, MIT.

More from yutronax/atdd-pipeline-skills