Yapay Zeka Kod Güvenlik İncelemesi: WordPress Rehberi

Bir eklenti ya da tema tesliminden önce yapay zeka kod güvenlik incelemesi WordPress projelerinin ayrılmaz bir parçası hâline geldi. Mekanik açıkları yorgun gözlerden çok daha hızlı tespit eden bu araçlar, geliştirme sürecinin son katmanını oluşturuyor. Pratikte üç araç bu sürece dahil olmayı hak ediyor. Her birinin gerçekte ne yakaladığını, hepsinin neleri kaçırdığını ve gerçekçi bir solo çalışma takviminde uygulanabilecek üç aşamalı kontrol listesini burada inceliyorum.

Vibe kodlama WordPress'te nasıl bir güvenlik borcu yaratıyor?

Duraksanmayı gerektiren bir rakam var: Güvenlik araştırmacıları, yapay zeka tabanlı statik analizi otomatik doğrulamayla eşleştirerek WordPress eklenti ekosisteminde yaklaşık 72 saatte 300'den fazla kritik sıfır-gün açığını tespit etti. Söz konusu eklentiler küçük, kullanılmaz araçlar değildi. Kayda değer kurulum sayısına sahip, gerçek sitelerde aktif olarak çalışan eklentilerdi.

Bu tablonun arkasında ne yatıyor? Kısa cevap: vibe kodlama. LLM tarafından üretilen eklenti kodunu tam olarak okumadan yayımlayan geliştiriciler. Model işlevsel mantığı hızla üretiyor; geliştirici ise girdi temizlemeyi, nonce kontrollerini ve yetki doğrulamalarını gözden geçirmeden kodu depoya gönderiyor. Sonuç, çift güven sorunudur: geliştirici yapay zekanın çıktısına güveniyor, o çıktı da yeterli doğrulama yapmadan kullanıcı girdisine güveniyor.

Bu sorun, WordPress'e özgü bir örüntü yaratıyor. PHP'nin dinamik yapısı ve WordPress kanca sisteminin esnekliği, LLM'lerin tutarlı güvenlik kalıpları üretmesini zorlaştırıyor. Modeller genel PHP güvenlik pratiklerini biliyor; ancak WordPress ekosisteminin bağlama özgü güvenlik beklentilerini her zaman doğru yansıtamıyor.

Bir tanıtım sitesinde bu sorunun bedeli sınırlı kalabilir. Gerçek işlemler yürüten bir WooCommerce kurulumunda ya da müşteri alt sitelerini barındıran bir çoklu site ağında, eksik bir esc_html() çağrısı ya da yok olan bir current_user_can() kontrolü ciddi bir maruz kalma riski yaratır. WordPress'in PHP güvenlik işlevleri yapay zeka araçlarının gerçekten iyi kavradığı alanlardır: esc_html, esc_url, wp_kses, check_ajax_referer, current_user_can, $wpdb->prepare, sanitize_text_field. Ancak bu işlevlerin eksikliğini tespit etmek ile bu eksikliğin iş bağlamındaki gerçek etkisini kavramak arasında derin bir uçurum bulunuyor.

Bir ajansın vibe kodlamayla geliştirilmiş eklenti üzerinde yaptığı harici denetim, tek bir kod tabanında 100'den fazla ayrı güvenlik sorunu ortaya koydu. Kamuya ifşa edilen güvenlik açıklarından yama yayımlamayan geliştiricilerin oranı yüzde 52. Kamuya ifşadan geniş çaplı istismara geçen medyan süre ise yaklaşık 5 saat. Bu iki rakamın bir arada ne anlama geldiğini değerlendirmek, güvenlik incelemesini teslim döngüsünün neresine yerleştireceğinize dair netlik sağlıyor.

Bu durum, yapay zeka destekli geliştirmeye karşı bir argüman değil. Güvenlik incelemesi adımını, zaman olduğunda eklenen bir seçenek yerine zorunlu bir aşama olarak değerlendirmek gerektiğine dair bir argümandır. LLM'in ürettiği kod düzgün çalışıyor olabilir; ancak çalışmak ile güvenli olmak farklı şeyler. Bu ayrımı her teslim döngüsünde hatırlamak gerekiyor.

Yapay zeka araçları WordPress PHP'de gerçekte ne yakalar?

Yapay zeka güvenlik inceleme araçları kod yapısını tarar, çalışma zamanı davranışını değil. Bu ayrımı, bu araçları geliştirme akışına dahil etmeden önce içselleştirmek gerekiyor.

WordPress PHP'de güvenilir biçimde tespit ettikleri sorunlar şunlardır: eksik esc_html, esc_url ve wp_kses çağrıları; check_ajax_referer ya da yetki kontrolü olmayan korumasız AJAX işleyicileri; değişken enterpolasyonlu ham $wpdb->query çağrıları; kullanıcı kaynaklı yollarla gerçekleştirilen güvensiz dosya işlemleri; korumasız update_option çağrıları. Bunların tamamı pattern tanıma ile tespit edilebilen mekanik sorunlardır.

Sürekli güvenilmez kaldıkları alanlar farklı bir kategori oluşturuyor: WooCommerce sipariş işlemesindeki iş mantığı hataları, stok yönetimindeki yarış koşulları, yürütme sırasına bağlı kimlik doğrulama akışı açıkları ve bağlama özgü sorunlar (çoklu site ortamları ya da belirli hosting kısıtlamaları). Bu kategorideki açıklar, iş niyetini anlamayı ve sistemin bütününü kavramayı gerektiriyor; statik analiz bu kavrayışa sahip değil.

Örnek olarak: bir eklenti belirli bir kullanıcı rolünün varlığını kontrol ederek bir işlemi yetkilendirebilir. Ancak o kullanıcı rolü başka bir eklenti tarafından dinamik olarak atanıyorsa, statik analiz bu ilişkiyi göremez. Güvenlik açığı ancak çalışma zamanı bağlamında ve çoklu eklenti etkileşimi gözetilerek anlaşılabilir.

Pratik zihinsel model: yapay zeka güvenlik incelemesi birinci geçiş filtresidir. Tavanı yükseltmez, tabanı yükseltir. En değerli katkısı, deneyimli bir gözün de gözden kaçırabileceği mekanik açıkları yorulmadan yakalamasıdır.

Bir eklenti tesliminden önce bu araçları çalıştırmak, bilinen açık kategorilerini sistematik biçimde elemek anlamına geliyor. Geri kalanı insan yargısı gerektiriyor; ama bu kategoriler elendiğinde, insan yargısını gerçekten önemli olan yere harcama fırsatı doğuyor. Sourcegraph'ın 2026 otomatik kod inceleme araçları karşılaştırması, bu araçların güvenlik açığı tespitinde özellikle SAST (statik uygulama güvenlik testi) kategorisinde en güçlü performans sergilediğini teyit ediyor.

Güvenlik incelemesine dahil edilmesi gereken üç araç

SonarQube Community Edition, ücretsiz self-hosted PHP statik analizidir. WordPress açık kalıpları için güçlü bir kural motoruna sahip ve CI boru hattına entegre kalite kapıları sunuyor. Gerçek sınırlılığı şu: kurulum yükü, mevcut paylaşımlı bir örnek olmadan tek seferlik proje incelemeleri için pratik değil. Birden fazla proje üzerinde çalışan bir ajans için merkezi bir SonarQube örneği mantıklı; ancak her proje için sıfırdan kurmak zaman kaybı.

Cursor, güvenlik incelemesini geliştirme aracının içinde ajan modu aracılığıyla gerçekleştiriyor. Güvenlik odaklı inceleme için tam eklenti dizinine yönlendirilen bir prompt ile kapsamlı bir tarama başlatılabiliyor. Ücretsiz katman işlevsel; düzenli inceleme çalışmaları için aylık 20 dolar Pro sürüm makul bir maliyet.

Tabnine, şirket içi ya da hava boşluklu dağıtımı ile öne çıkıyor. Müşteri kodu gizliliği söz konusu olduğunda; yani NDA'lar ya da müşteri verisi hassasiyeti bulut tabanlı yapay zeka araçlarının kullanımını engellediğinde, doğru tercih Tabnine. Finans, hukuk ve sağlık sektörlerine hizmet eden sistemlerin eklentilerini incelerken kodu bulut sunuculara göndermemek kritik; Tabnine bu ihtiyacı karşılıyor.

Claude Code, tam eklenti dizinlerinin ajansal incelemesini ve müşterilerle doğrudan paylaşılabilecek kadar düzenli yapılandırılmış çıktı sunuyor. WordPress PHP'de göz ardı edilmeyecek bir yanlış pozitif oranı mevcut; her bulgunun manuel doğrulama gerektirdiğini baştan kabul ederek bu aracı kullanmak gerekiyor. Güçlü yanı, bulguları belgeleyip müşteriye aktarmayı kolaylaştıran yapılandırılmış çıktı formatı.

Bu dört araç birbirinin rakibi değil. SonarQube CI'ya entegre sürekli kontrol için, Cursor geliştirici iş akışının içinde hızlı tarama için, Tabnine gizlilik kısıtlamaları olan projeler için ve Claude Code teslim öncesi kapsamlı belgeleme için ayrı ayrı değer üretiyor. Pratikte bu araçları katmanlı kullanmak; yani birini diğerinin tamamlayıcısı olarak konumlandırmak, tek araçla çalışmaktan çok daha sağlam bir güvenlik tabanı oluşturuyor.

Yapay zekanın sürekli kaçırdıkları ve bu durumun yarattığı sorumluluk

İş mantığı hataları statik analize görünmez. Bir WooCommerce kupon birleşimi hatasını ya da sipariş işleme akışındaki ayrıcalık yükseltme açığını tespit etmek, iş niyetini ve yürütme bağlamını kavramayı gerektiriyor. Bunu hiçbir araç yapamaz; insan yargısı zorunlu.

Yürütme sırasına bağlı kimlik doğrulama açıkları da aynı kategoride. Bir kod parçacığı tek başına incelendiğinde güvenli görünebilir; ancak belirli bir çağrı sırası bağlamında ciddi bir güvenlik açığına dönüşebilir. Çoklu site ortamları ya da belirli hosting yapılandırmaları da benzer bağlama özgü sorunlar yaratıyor.

Güvenlik açığı kamuoyuna duyurulduktan sonra geniş çaplı istismara geçen medyan sürenin yaklaşık 5 saat olduğu göz önüne alındığında, güvenlik incelemesini teslimden önce çalıştırmak bir tercih değil, zorunlu pratik.

Bir başka pratik nokta: müşteri siteye erişim verdiğinde, o sistemin güvenlik durumuna ortak bir sorumluluk yükleniyor. Yapay zeka güvenlik incelemesinin eksiklikleri konusunda şeffaf olmak, yani hangi kategorileri kontrol ettiğinizi ve hangilerini insan gözüyle incelediğinizi belgelemek, bu sorumluluğu profesyonelce yönetmenin bir parçası.

Uygulamada işe yarayan teslim öncesi kontrol listesi

Birinci geçiş (15 dakika): WordPress-VIP-Go kural setiyle PHP_CodeSniffer ya da SonarQube çalıştırın. Tüm kritik bulguları giderin. Otomatik ve hızlı; standart yapılandırmayla birkaç dakikada sonuç alırsınız.

İkinci geçiş (20 dakika): Cursor ya da Claude Code kullanın. Girdi işleme, AJAX koruması, veritabanı sorguları, dosya işlemleri ve seçenek yönetimine odaklanan güvenlik odaklı bir prompt verin. Tüm bulguları kaydedin; reddedilen yanlış pozitifler dahil. Bu kayıt hem kendi referansınız hem müşteriye sunulabilecek bir kanıt belgesi.

Üçüncü geçiş (25 dakika): Her AJAX uç noktasının, REST uç noktasının ve yönetici eylem kancasının manuel sınır incelemesi. Nonce kontrolünün mevcut ve doğru konumlandırılmış olduğunu doğrulayın. Yetki kontrolünün uygun yetkiyi kullandığını kontrol edin. Girdinin işlemden önce temizlenip çıktıdan önce kaçışlandığını teyit edin. Bu geçiş otomatize edilemez. Elle yapın.

Toplam süre: yaklaşık 60 dakika. Bu süreyi teslimden önce planlamak, olası bir güvenlik ihlalinin yarattığı krizi yönetmekten çok daha az maliyetli.

Üçüncü geçiş en çok göz ardı edilen adım. Ama aynı zamanda en kritik olan. Otomatik araçların yakalayamayacağı her şey bu geçişte ortaya çıkıyor. Zaman bütçesi hesaplarken bu 25 dakikayı pazarlık konusu yapmamak gerekiyor.

Çoğu freelance'ın planlamadığı AB uyumluluk son tarihi

Eylül 2026 itibarıyla Avrupa Birliği, AB kullanıcılarına eklenti ya da tema dağıtan geliştiriciler için güvenlik açığı ifşa programlarını zorunlu kılıyor. Belgelenmiş bir süreç, tanımlanmış bir yanıt penceresi ve adanmış bir güvenlik iletişim noktası gerekiyor. Yalnızca büyük eklenti satıcıları için değil; özel ve tek müşterili eklentiler için de geçerli.

Kayıt altına alınmış üç aşamalı inceleme, savunulabilir bir özen yükümlülüğü sürecinin parçası. Süreç test ortamında değil, gerçek bir müşteri sitesiyle doğrulanmalı.

Kendi pratiğinizde bu hazırlığı şimdiden başlatmak için iki somut adım var: mevcut bir iletişim e-posta adresi belirleyin (security@alan-adiniz gibi), ve son teslim ettiğiniz eklentiler için minimal bir güvenlik belgesi oluşturun. Bu iki adım, zorunluluk yürürlüğe girdiğinde başlangıç noktanızı çok daha iyi bir yere taşıyor.

Hedefli bir incelemenin ne zaman yeterli, ne zaman yetersiz olduğu

Özel AJAX ya da veri işleme içermeyen bir tanıtım sitesi ya da blok teması için üç aşamalı süreç yeterli. Kimlik doğrulama, sipariş işleme, dosya yükleme ya da ayrıcalıklı veri içeren özel bir eklenti için doğru kapsam, belgelenmiş bulgularla gerçekleştirilen resmi incelemedir.

Üç aşamalı süreç bir başlangıç noktasıdır, bir sonuç değil. Gerçek bir müşteri sitesiyle test edin, bulguları belgeleyin ve her teslimde bu süreci bir kez çalıştırın. Zamanla bu alışkanlık, güvenlik borcunu biriktirmek yerine her döngüde tasfiye eden bir pratik hâline geliyor. Yüzde 52'lik ifşa öncesi yama oranı ve 5 saatlik medyan istismar penceresi, bu pratiği her teslimde tekrarlamak için yeterince güçlü bir gerekçe.