Strix Nedir? AI Destekli Pentest ile Kendi Web Sitenizi Test Etmek

Yapay zekâ uzun süre boyunca “içerik üret, kod yaz, soru cevapla” üçlüsüne sıkışmıştı. Bugün AI agent adı verilen sistemler bunun ötesine geçti: tarayıcı kullanabiliyor, terminal komutu çalıştırabiliyor, kaynak kodu okuyup analiz edebiliyor, HTTP trafiğini inceleyebiliyor ve bir uygulamanın davranışına bakarak sonraki adımına kendisi karar verebiliyor.

Bu yeteneklerin doğal bir uzantısı var: güvenlik testi. Bir uygulamayı gerçekten anlamak, isteklerle oynamak, cevapları okumak ve buna göre yeni denemeler yapmak — bu, bir penetration test uzmanının yaptığı işin özeti. İşte Strix tam olarak bu boşluğa oturan açık kaynaklı bir araç.

Bu yazının amacı kimseye saldırı öğretmek değil. Amaç, AI destekli güvenlik testlerinin nereye geldiğini göstermek, geliştiricilere kendi sistemlerini test etmenin önemini anlatmak ve bu araçların yasal, güvenli ve kontrollü kullanımını netleştirmek. Aşağıdaki bilgilerin tamamı Strix’in resmî GitHub deposu, resmî sitesi ve dokümantasyonundan doğrulandı; kaynaklar yazının sonunda.

Strix nedir?

Strix, kendi tanımıyla otonom AI penetration testing agent’ları sunan açık kaynaklı bir araç. Resmî dokümantasyondaki ifadeyle bu agent’lar “gerçek hacker’lar gibi davranır — kodunuzu dinamik olarak çalıştırır, güvenlik açıklarını bulur ve bunları proof-of-concept ile doğrular”.

Teknik olmayan bir okuyucu için en sade çeviri şu: Strix, uygulamanızı dışarıdan bakan bir saldırganın gözüyle deneyen, denediklerini not eden ve “burada gerçekten bir açık var” diyebilmek için bulduğunu kanıtlamaya çalışan bir yazılım. Bunu bir kişinin elle yapması yerine, birden fazla AI agent’ı eşzamanlı olarak yapıyor.

Resmî kaynaklarda doğrulanan temel özellikler:

• Tam pentest araç seti — keşif (reconnaissance), istismar denemesi ve doğrulama adımlarını kapsıyor.
• Çoklu agent orkestrasyonu — testi birden fazla agent’a ve hedefe dağıtıyor.
• Gerçek istismar doğrulaması — bulguları çalışan bir proof-of-concept ile kanıtlamayı hedefliyor; amaç false positive yığını üretmemek.
• Geliştirici odaklı CLI — bulguları ve düzeltme önerilerini komut satırından veriyor.
• Otomatik düzeltme ve raporlama — yama önerileri ve rapor üretebiliyor.
• Web uygulaması, API ve kaynak kod hedefleri — hedef olarak URL, depo (repository), dizin, alan adı, IP ve API şeması verilebiliyor.
• Docker tabanlı sandbox — testler izole bir konteyner ortamında çalışıyor; ilk çalıştırmada sandbox imajı otomatik indiriliyor.

Bir ayrımı baştan netleştirelim: strix.ai aynı zamanda ticari bir bulut platformu sunuyor (ücretsiz başlangıç katmanı ve kurumsal self-hosted seçenekleriyle). Bu yazının konusu, GitHub’da Apache-2.0 lisansıyla yayınlanan açık kaynaklı CLI aracı. İkisi aynı ekipten geliyor ama aynı şey değil.

Geleneksel güvenlik tarayıcısından farkı ne?

Klasik bir vulnerability scanner, elindeki listedeki testleri sırayla dener. AI tabanlı bir pentest agent’ı ise gördüğü cevaba göre bir sonraki adımını seçer. Fark burada.

Önemli not: AI penetration testing, profesyonel bir güvenlik denetiminin yerine her durumda geçmez. Uyumluluk (compliance) gereksinimleri, mimari risk analizi, sosyal mühendislik senaryoları ve iş mantığının derin incelenmesi hâlâ insan uzmanlığı ister. Bu araçları “denetim yerine” değil, “denetimden önce ve denetim aralarında” düşünmek daha doğru.

Strix nasıl çalışıyor?

Akışı en sade haliyle şöyle özetleyebiliriz:

Geliştirici
   ↓
Strix (CLI)
   ↓
AI Modeli (seçtiğiniz sağlayıcı)
   ↓
Browser / HTTP Proxy / Terminal / Kod analizi
   ↓
Web uygulaması veya kaynak kod
   ↓
Güvenlik bulguları (PoC ile)
   ↓
Geliştirici düzeltir
   ↓
Yeniden test

Resmî dokümantasyonda agent’ların kullandığı araçlar tek tek listeleniyor:

• Browser — Playwright üzerinden Chrome; web arayüzleriyle etkileşim için.
• HTTP Proxy — Caido tabanlı proxy; istekleri yakalayıp yeniden göndermek için.
• Terminal — komut ve güvenlik araçları çalıştırmak için bash kabuğu.
• Sandbox araçları — önceden kurulu güvenlik araçları (Nuclei, ffuf ve diğerleri).
• Python çalışma ortamı, dosya düzenleyici (kaynak kodu okuma/değiştirme), web araması, notlar ve raporlama.

Bunların hepsi Docker sandbox’ı içinde çalışıyor — yani agent’ın araçları sizin makinenizin geri kalanına değil, izole bir konteynere bakıyor. Çalışma çıktıları da strix_runs/<çalışma-adı> klasörüne yazılıyor.

Tarama derinliği ve kapsamı komut satırından ayarlanabiliyor: --scan-mode ile quick, standard veya deep (varsayılan deep); kod tarafında --scope-mode ile auto, diff veya full. Ayrıca --max-budget ile LLM harcamasına dolar cinsinden tavan koyabiliyor, --max-turns ile agent adım sayısını sınırlayabiliyorsunuz (varsayılan 500). CI kullanımı için --non-interactive modu var.

Claude ile Strix kullanılabilir mi?

Evet. Resmî dokümantasyonun LLM sağlayıcıları sayfasında Anthropic açıkça destekleniyor ve “Claude Opus, Sonnet ve Haiku” modelleri belirtiliyor. Doğrulanan tam sağlayıcı listesi şu:

• OpenAI
• Anthropic (Claude Opus / Sonnet / Haiku)
• Google Vertex AI (Gemini)
• OpenRouter (tek API üzerinden çok sayıda model)
• AWS Bedrock
• Azure OpenAI
• Ollama (yerel / self-hosted modeller)

Model seçimi STRIX_LLM, anahtar ise LLM_API_KEY ortam değişkeniyle veriliyor; model kimlikleri sağlayıcı/model-adı biçiminde yazılıyor.

Buradaki mimariyi doğru anlamak önemli:

Claude (veya seçtiğiniz model)
   ↓  akıl yürütme katmanı
Strix AI Agent
   ↓  araçları kullanan katman
Güvenlik araçları (browser, proxy, terminal)
   ↓
Geliştiricinin kendi test ortamı
   ↓
Güvenlik açığı raporu

Yani Claude burada web sitesine saldıran uygulama değil. Claude, “şimdi ne denemeliyim, bu cevap ne anlama geliyor” sorularını yanıtlayan muhakeme katmanı. Fiili işlemleri yapan, araçları çağıran ve sandbox içinde çalışan taraf Strix’in kendisi. Bu ayrım hem teknik olarak doğru hem de sorumluluğun nerede olduğunu netleştirmesi açısından önemli: aracı hangi hedefe yönelttiğinize siz karar veriyorsunuz.

Strix hangi güvenlik açıklarını bulabiliyor?

Resmî dokümantasyonda kapsanan kategoriler şöyle listeleniyor. Aşağıda her birini tek cümleyle açıklıyorum — bilinçli olarak hiçbir payload, exploit ya da saldırı talimatı vermiyorum.

• Bozuk erişim kontrolü (Broken Access Control) — bir kullanıcının başkasının verisine ya da yetkisine ulaşabilmesi; IDOR, yetki yükseltme ve kimlik doğrulama atlatma bu başlığın altında.
• Enjeksiyon saldırıları — kullanıcı girdisinin veritabanı sorgusu, işletim sistemi komutu veya şablon motoru tarafından “komut” gibi yorumlanması (SQL, NoSQL, OS command, SSTI).
• Sunucu tarafı açıklar — sunucunun kendisine istek yaptırılması (SSRF), XML işlemedeki XXE, güvensiz deserialization ve uzaktan kod çalıştırmaya (RCE) giden yollar.
• İstemci tarafı saldırılar — tarayıcıda çalışan kodun ele geçirilmesi: XSS türevleri, prototype pollution ve CSRF.
• İş mantığı açıkları — kod teknik olarak doğru çalışırken kuralın kendisinin atlatılması: yarış koşulları (race condition), ödeme manipülasyonu, iş akışı atlama.
• Kimlik doğrulama ve oturum sorunları — JWT saldırıları, oturum sabitleme (session fixation), credential stuffing gibi konular.
• Altyapı ve bulut yanlış yapılandırmaları — açıkta kalmış servisler, fazla geniş izinler, hatalı bulut ayarları.
• API güvenliği — bozuk kimlik doğrulama, mass assignment, hız sınırı (rate limit) atlatma gibi API’ye özgü zayıflıklar.

Bu liste iddialı görünüyor ve öyle. Ama şunu unutmayın: bir aracın bir kategoriyi “kapsıyor olması”, o kategorideki her açığı bulacağı anlamına gelmez. Hiçbir tarayıcı, hiçbir agent ve hiçbir insan uzmanı %100 kapsama vaat edemez.

WordPress geliştiricileri için neden ilginç?

Bir WordPress projesi neredeyse hiçbir zaman “sadece WordPress” değildir. Üstüne bir tema, on beş eklenti, bir form eklentisi, bir ödeme entegrasyonu, birkaç özel kod parçası ve bir hosting yapılandırması biner. Açıklar da genelde çekirdekte değil, tam bu birleşim noktalarında çıkar.

Somut bir senaryo: bir geliştirici müşterisi için WordPress sitesi hazırlıyor. Siteyi doğrudan yayındaki sistem üzerinde test etmek yerine şu akışı kuruyor:

Production (yayındaki site)
   ↓  tam yedek
Backup
   ↓  kopyayı ayrı ortama taşı
Staging ortamı
   ↓
Strix güvenlik testi
   ↓
Bulgular
   ↓
Düzeltmeler
   ↓
Yeniden test
   ↓
Production'a yayın

Bu yapı neden daha güvenli? Çünkü:

• Gerçek kullanıcı verisi risk altında değil. Staging’de test verisi vardır; müşterinin sipariş, üye ve iletişim kayıtları değil.
• Bir şey bozulursa maliyeti sıfır. Test sırasında kayıt silinebilir, ayar bozulabilir, site cevap veremez hale gelebilir. Staging’de bunun karşılığı yalnızca zaman kaybıdır.
• Yan etkiler kimseye ulaşmaz. Bir test formu tetiklerse gerçek müşterilere e-posta gitmez; bir ödeme akışı denenirse gerçek bir işlem oluşmaz.
• Hosting’i zorlamazsınız. Yoğun test trafiği paylaşımlı hosting’de rate limit’e, geçici IP engeline veya aynı sunucudaki diğer siteleri etkileyen yavaşlamaya yol açabilir.
• Bulgular tekrarlanabilir. Aynı staging kopyası üzerinde düzeltip yeniden test edebilir, “gerçekten kapandı mı” sorusunu kanıtla yanıtlayabilirsiniz.

Production sitede çalıştırmalı mıyız?

Kısa cevap: hayır, tercih edilmez.

AI penetration testing araçlarını doğrudan kritik production sistemlerine karşı çalıştırmak riskli olabilir. Bunlar pasif tarayıcılar değil; hedefe gerçekten istek gönderen, form dolduran, veri yazmayı deneyen ve komut çalıştırmayı test eden araçlardır. Özellikle şunlar söz konusuysa ekstra dikkat gerekir:

• Müşteri siteleri — izin ve sözleşme konusu; kendi sitenizle aynı şey değil.
• Ödeme sistemleri — test denemeleri gerçek işlem, iade veya sağlayıcı tarafında hesap kısıtı doğurabilir.
• Gerçek kullanıcı verileri — bir testin veri silmesi ya da bozması geri alınması zor bir hasar.
• E-posta sunucuları — tetiklenen toplu gönderim spam itibarınızı kalıcı olarak zedeleyebilir.
• Veritabanları — yazma denemeleri tutarlılığı bozabilir.
• Aynı hosting üzerindeki diğer siteler — paylaşımlı kaynaklarda bir sitedeki yük komşu siteleri de etkiler.

Tercih edilen yöntem net: staging, yerel (local) veya izole bir test ortamı. Production’da test yapılması gereken bir durum varsa bu, planlı bir bakım penceresinde, yedek alınmış halde, dar kapsamla ve ilgili tarafların yazılı onayıyla yapılması gereken ayrı bir iştir.

Yasal ve etik kullanım

Strix’in resmî dokümantasyonu bu konuda açık bir uyarı taşıyor: araç yönelttiğiniz hedefi gerçekten test eder, bu yüzden yalnızca sahibi olduğunuz veya açık ve yazılı test izniniz bulunan sistemlere karşı çalıştırılmalı ve üzerinde anlaşılan kapsamın dışına çıkılmamalıdır. Dokümantasyonun ifadesiyle, yetkisiz test çoğu ülkede yasa dışıdır.

⚠️ Önemli güvenlik uyarısı

Strix’i veya başka bir penetration testing aracını yalnızca şu durumlarda kullanın:

• sahibi olduğunuz sistemlerde
• açıkça ve tercihen yazılı test izni aldığınız sistemlerde
• kendi kurduğunuz özel lab ortamlarında
• CTF veya eğitim amaçlı hazırlanmış sistemlerde

Başkasına ait bir web sitesi, sunucu veya API üzerinde izinsiz güvenlik testi yapmanın hukuki sonuçları olabilir. Türkiye’de de bilişim sistemlerine yetkisiz erişim ve sistemleri engelleme/bozma fiilleri Türk Ceza Kanunu kapsamında suç olarak düzenlenmiştir. “Sadece deniyordum” bir savunma değildir.

Pratik bir ek not: paylaşımlı hosting kullanıyorsanız, kendi sitenize karşı yapacağınız yoğun bir testin bile hosting sağlayıcınızın kullanım şartlarını ihlal edebileceğini unutmayın. Şüphedeyseniz önce sağlayıcınıza sorun.

Strix nasıl indirilir?

Aşağıda yalnızca resmî başlangıç kaynakları ve dokümantasyondaki temel kurulum komutları var. Burada hiçbir saldırı komutu ya da exploit örneği yok; bunlar aracın kendi belgelerindeki ilk adımlar.

Resmî GitHub deposu

Aracın kaynak kodu, README’si ve lisansı burada: github.com/usestrix/strix

Dokümantasyon

Kurulum, CLI referansı, araçlar ve GitHub Actions entegrasyonu: docs.strix.ai

Quick Start (kurulum rehberi)

Adım adım ilk kurulum: docs.strix.ai/quickstart

Dokümantasyondaki kurulum iki yoldan biriyle yapılıyor — resmî kurulum betiği ya da pipx:

# Resmî kurulum betiği
curl -sSL https://strix.ai/install | bash

# ya da pipx ile
pipx install strix-agent

Ardından kullanacağınız modeli ve API anahtarını ortam değişkeni olarak tanımlıyorsunuz, sonra ilk taramayı kendi uygulamanız üzerinde çalıştırıyorsunuz:

export STRIX_LLM="anthropic/claude-sonnet-4-6"
export LLM_API_KEY="kendi-api-anahtariniz"

strix --target ./my-app

İlk çalıştırmada Docker sandbox imajı otomatik indiriliyor; sonuçlar strix_runs/ altına yazılıyor. Model kimliklerini ve seçenekleri her zaman güncel dokümantasyondan doğrulayın — bu tür araçlarda desteklenen model listesi sık değişir.

Kaynağı bilinmeyen kurulum betiklerini incelemeden çalıştırmamak iyi bir alışkanlıktır. Bu bir güvenlik aracı; kurulum adımına da güvenlik gözüyle bakın.

Sistem gereksinimleri

Resmî Quick Start sayfasında belirtilen gereksinimler oldukça sade:

• Docker — kurulu ve çalışır durumda olmalı (sandbox burada yaşıyor).
• Desteklenen bir LLM sağlayıcısının API anahtarı — OpenAI, Anthropic, Google ve diğerleri.
• Terminal ortamı — kurulum ve çalıştırma komut satırından yapılıyor.
• pipx — kurulumu pipx üzerinden yapmayı tercih ederseniz.

Belgelerde belirli bir işletim sistemi veya minimum donanım sürümü kesin biçimde sabitlenmediği için burada tahmin yürütmüyorum. Ayrıca gözden kaçmaması gereken bir “gereksinim” daha var: API kullanım maliyeti. Agent’lar çok sayıda model çağrısı yapar; bu yüzden Strix --max-budget seçeneğiyle çalışma başına dolar cinsinden tavan koymanıza izin veriyor. İlk denemelerinizde bu sınırı kullanmanızı öneririm.

Açık kaynak olmasının avantajı

Strix’in GitHub deposu Apache License 2.0 ile yayınlanıyor (telif sahibi: OmniSecure Inc., 2025). Bir güvenlik aracı için açık kaynak olmak, “bedava” olmaktan çok daha fazlasını ifade eder:

• Kodu inceleyebilirsiniz. Aracın hedefinize tam olarak ne yaptığını okuyabilirsiniz — güvenlik yazılımında bu, güvenin temelidir.
• Kendi ortamınızda çalıştırabilirsiniz. Kaynak kodunuzu ve test verinizi üçüncü bir tarafın bulutuna göndermek zorunda değilsiniz.
• Agent promptlarını görebilirsiniz. Güvenlik ekipleri agent’ın nasıl yönlendirildiğini denetleyebilir; bu, davranışı öngörülebilir kılar.
• Entegrasyon esnekliği. CI/CD hattınıza, kendi raporlama akışınıza veya iç araçlarınıza bağlayabilirsiniz.
• Bağımlılık riski düşer. Apache-2.0 izin verici bir lisans; ticari kullanım ve değiştirme serbest, patent hükmü de içeriyor.

Lisans bilgisini her zaman deponun kendi LICENSE dosyasından doğrulayın; lisanslar zamanla değişebilir.

Strix kimler için?

• Web geliştiriciler — kendi yazdıkları uygulamayı yayına almadan önce denemek isteyenler.
• WordPress geliştiricileri — tema, eklenti ve özel kod birleşimini staging’de sınamak isteyenler.
• DevOps mühendisleri — güvenlik testini CI/CD hattına bir adım olarak eklemek isteyenler.
• Siber güvenlik uzmanları — tekrarlayan keşif ve doğrulama işini hızlandırmak isteyenler.
• SaaS ve API geliştiricileri — yetkilendirme ve iş mantığı hatalarının en pahalıya patladığı alan.
• Güvenlik ekipleri — denetimler arasındaki dönemde sürekli kontrol isteyenler.
• AI geliştiricileri — agent mimarilerinin gerçek bir işte nasıl kurulduğunu incelemek isteyenler; depo bu açıdan da öğretici.

Dürüst bir uyarı: bu araç başlangıç seviyesi için “kur ve unut” bir çözüm değil. Çıkan bulguyu okumak, gerçekten sömürülebilir mi diye değerlendirmek ve doğru düzeltmeyi yapmak temel bir web güvenliği bilgisi ister. OWASP Top 10 gibi bir temel olmadan, üretilen rapor işe yaramaz bir liste olarak kalabilir — ya da daha kötüsü, yanlış bir güvenlik hissi verebilir.

AI pentesting’in geleceği

AI kod yazan agent’larla AI güvenlik testi yapan agent’lar aynı teknolojinin iki ucu. Bu ikisi birleştiğinde ortaya şuna benzer bir döngü çıkıyor:

AI kod yazıyor
   ↓
AI kodu gözden geçiriyor
   ↓
AI güvenlik testi yapıyor
   ↓
Geliştirici bulguları inceliyor   ← insan kararı
   ↓
AI düzeltmeye yardım ediyor
   ↓
Tekrar test ediliyor

Bu döngü DevSecOps süreçlerinde ciddi bir hızlanma anlamına gelebilir: güvenlik, sürüm çıkmadan haftalar önce değil, her pull request’te devreye girer. Strix’in GitHub Actions entegrasyonu ve --scope-mode diff seçeneği tam olarak bu kullanım için var — yalnızca değişen kodu taramak.

Ama akıştaki en kritik satırın hangisi olduğuna dikkat edin: “Geliştirici bulguları inceliyor.” AI’nın bir açığı bulması, o açığın ne kadar önemli olduğuna, hangi sırayla düzeltileceğine ve düzeltmenin başka bir şeyi bozup bozmadığına karar vermez. O karar hâlâ insana ait — ve öngörülebilir gelecekte de öyle kalacak gibi görünüyor.

FB Software Solutions’ta nasıl bakıyoruz?

AI, geliştirme süreçlerini gerçekten hızlandırıyor. Ancak hızlanmanın bedeli güvenlik kontrollerinin kaldırılması olmamalı. Bizim yaklaşımımızda AI, mevcut katmanların yerine geçen değil, o katmanların içinde çalışan bir araç:

• İnsan onayı — geri alınamaz adımlar önce gösterilir, sonra uygulanır.
• Minimum gerekli yetki — her araç ve entegrasyon yalnızca işini yapacak kadar yetki alır.
• İzole ortamlar — test production’da değil, staging veya yerel ortamda yapılır.
• Yedekler — riskli bir işlemden önce geri dönüş noktası vardır.
• Loglama ve izleme — ne yapıldığı sonradan okunabilir olmalıdır.
• Staging — müşteri sitesi hiçbir zaman ilk deneme alanı değildir.
• Güvenlik testi — yayına almadan önce, bir kez değil düzenli olarak.

Strix gibi araçlar bu tabloda “güvenliği halleden şey” değil, “güvenliği daha erken görünür kılan şey” olarak duruyor. Bulmak düzeltmek değildir; ama düzeltmenin ilk şartıdır.

Kaynaklar ve indirme bağlantıları

• Strix GitHub — resmî depo: kaynak kod, README, Apache-2.0 lisans dosyası ve sürüm geçmişi.
• Strix Resmî Web Sitesi — projenin tanıtım sayfası ve ticari bulut platformu hakkında bilgi.
• Strix Dokümantasyonu — CLI referansı, agent araçları, kapsanan açık kategorileri ve GitHub Actions entegrasyonu.
• Strix Quick Start — gereksinimler, kurulum komutları ve ilk taramanın nasıl çalıştırılacağı.
• Desteklenen LLM sağlayıcıları — Anthropic dahil tüm sağlayıcıların ve yapılandırmanın listesi.

Doğrulama notu: GitHub’da “Strix” adını taşıyan başka projeler ve çok sayıda fork bulunuyor. Bu yazıda anlatılan araç, resmî sitesinden de bağlantı verilen ve Apache-2.0 lisansı OmniSecure Inc. adına düzenlenmiş olan usestrix/strix deposudur. Klon depolara değil, bu adrese gidin.

Kendi uygulamanızı test etmeye hazır mısınız?

Kendi uygulamanızın güvenliğini test etmek istiyorsanız Strix’in resmî GitHub deposunu ve dokümantasyonunu inceleyebilirsiniz. Güvenlik testlerini yalnızca size ait veya test izni verilmiş sistemlerde gerçekleştirin — ve tercihen production’da değil, bir staging kopyası üzerinde.