Yapay Zekâ Destekli Kod Güvenliği: Yeni Riskler

Yapay Zekâ Destekli Kod Güvenliği: Yeni Riskler
23.02.2026
A+
A-

Claude Code Security tartışmaları, yapay zekâ destekli kod güvenliğinde izin ve denetim izini ön plana çıkardı. “Kod güvenliğinde kritik eşik, açığı bulmak değil güvenli biçimde kapatmaktır; otomatik öneri olabilir ama otomatik sorumluluk olmaz. Asıl soru, hangi verinin işlendiği, hangi komutların hangi sınırlar içinde çalıştığı ve hangi değişikliğin kim tarafından hangi kanıtla onaylandığıdır.”

Yapay Zekâ Destekli Kod Güvenliği ve Riskler

Global Bilişim Derneği (BİDER) Başkanı Şenol Vatansever, yapay zekâ destekli kod güvenliği araçlarının zafiyet tespiti ve düzeltme süreçlerinde hız sağlayabileceğini belirtti. Ancak izin yönetimi, izolasyon, veri sınırları ve denetim izi kurgulanmadan ölçeklenmesi halinde kurumların yeni risk sınıflarıyla karşılaşabileceğini vurguladı.

Vatansever, Anthropic’in Claude Code Security yaklaşımıyla gündeme gelen tartışmaların yalnızca “hangi açıklar bulunuyor” başlığına indirgenmemesi gerektiğini söyledi. Asıl belirleyici alanın, “hangi yetkilerle, hangi veriye erişerek, hangi güvenlik sınırları içinde ve hangi sorumluluk zinciriyle düzeltme üretildiği” olduğunu ifade etti.

Claude Code Security’nin İşleyişi ve Potansiyeli

Kamuya açık duyurularda Claude Code Security’nin, “Claude Code on the web” içinde sınırlı bir önizleme olarak konumlandığına dikkat çeken Vatansever, bu tür çözümlerin kod tabanlarını tarayarak zafiyet tespiti yaptığını ve insan incelemesi için hedefli düzeltme önerileri ürettiğini belirtti.

Yeni nesil yaklaşımlar, klasik güvenlik araçlarının kullandığı kural tabanlı desen eşleştirme ve statik analiz yöntemlerini tamamen ikame etmek yerine, “bağlam” okuma iddiasıyla bazı zafiyet sınıflarında ek değer üretme potansiyeline sahip. Bu potansiyel özellikle yetkilendirme akışları, iş mantığı hataları ve bileşenler arası etkileşimden doğan “tasarım boşlukları” gibi alanlarda görülüyor. Ancak yanlış pozitiflerin ön inceleme ve önceliklendirme yükünü artırması ve yanlış düzeltmelerin geriye dönük hataya yol açması operasyonel risk olarak öne çıkıyor.

Düzeltme Önerisi Üretiminde Dikkat Edilmesi Gerekenler

Vatansever, zafiyet tespitinden daha kritik eşiğin “düzeltme önerisi üretimi” olduğunu vurguladı. Bir yamanın güvenlik açığını kapatırken performans, uyumluluk veya iş mantığı tarafında istenmeyen yan etkiler doğurabileceğini belirtti. Yanlış bir düzeltmenin yeni bir zafiyete dönüşebileceğini ifade ederek, kurumların önerilen düzeltmeleri otomatik biçimde ana dala taşıyan akışlara temkinli yaklaşması gerektiğini söyledi. “Otomatik öneri olabilir; otomatik sorumluluk yoktur.” değerlendirmesinde bulundu.

Ajan Güvenliği ve Yeni Tehdit Modelleri

Kod güvenliği otomasyonu tartışmalarında öne çıkan ikinci hattın “ajan güvenliği” olduğu belirtildi. Klasik uygulama güvenliği (AppSec) yaklaşımı çoğunlukla uygulamanın ne yaptığına odaklanırken, yeni nesil ajanlar dosya okuma-yazma, komut çalıştırma ve ağ üzerinden veri taşıma gibi yetenekleri aynı iş akışında bir araya getirebiliyor. Bu durum, yalnızca uygulamanın değil, uygulamayı inceleyen aracın da ayrı bir tehdit modeline ihtiyaç duyduğunu gösteriyor.

Araç tek başına “masum” görünse de dosya erişimi, komut çalıştırma ve ağ çıkışının aynı senaryoda birleşmesi risk sınıfını büyütüyor. Kurumların araç yetkilerini “en az ayrıcalık” prensibiyle kademeli biçimde açması, yetkileri kalıcı değil iş bazlı ve kontrollü tasarlaması, onay yorgunluğunu artıran gereksiz izin genişlemelerinden kaçınması gerekiyor.

İzin Yönetimi, İzolasyon ve Veri Güvenliği

Kamuya açık dokümantasyonda izin yaklaşımı “reddet–sor–izin ver” (deny–ask–allow) yöntemiyle tarif ediliyor. İzole çalışma ortamı (sandboxing) gibi izolasyon katmanları dosya sistemi ve ağ erişimi üzerinde kısıtlar getirerek savunma derinliği oluşturmayı hedefliyor. İzolasyonun sadece ana komutlar için değil alt süreçler için de geçerli olması önem taşıyor.

Kurumsal devreye alma senaryolarında çalışma dizini dışına yazmanın sınırlandırılması, hassas yol ve dizinlerin engel listeleriyle korunması ve ağ çıkışının yalnızca gerekli alan adlarıyla sınırlandırılması gerekiyor.

Veri güvenliği ve gizlilik boyutunda ise kodun veya kod parçalarının modele aktarılması, kurumlar için teknik bir ayrıntı olmaktan çıkıp yönetişim konusu haline geldi. Hangi veri sınıflarının kesin olarak yasak olduğu, hangi şartlarda işlenebileceği, saklama ile tanılama ve izleme verilerinin (telemetry) nasıl yönetileceği ve devre dışı bırakma seçeneklerinin nasıl uygulanacağı gibi sorular ölçekli kullanımın ön koşulu olarak öne çıkıyor.

Kamuya açık dokümanlarda saklama seçenekleri ve tanılama/izleme mekanizmalarına ilişkin bilgiler yer alıyor. Bu alanların kurum içi veri sınıflandırmasıyla uyumlu hale getirilmeden yaygın kullanımın risk üretebileceği belirtiliyor.

Uyumluluk, Denetim İzi ve Tedarik Zinciri Güvenliği

Güvenli devreye almanın sadece teknik kısıtlarla değil, izlenebilirlik mekanizmalarıyla da güçlendirilmesi gerekiyor. “Hangi öneri, hangi gerekçeyle kabul edildi, hangi test kanıtı görüldü, kim onayladı, hangi tarihte üretime alındı” sorularını yanıtlayabilen bir kayıt disiplini hem denetim hem de olası bir güvenlik olayında kök neden analizi açısından kritik önemde.

Tedarik zinciri ve entegrasyon güvenliği kapsamında tümleşik geliştirme ortamı (IDE) eklentileri ve harici araç sunucuları, klasik zafiyetleri ajan bağlamında büyütebiliyor. İzinli liste (whitelist) yaklaşımı, sürüm sabitleme, güvenlik duyurularının (advisory) izlenmesi ve hızlı güncelleme disiplini daha kritik hale geliyor.

Entegrasyon katmanlarında yaşanabilecek bir zafiyet, yalnızca uygulamayı değil aracın komut yürütme ve dosya erişimi kabiliyetini de etkileyebilir.

Piyasa Tepkileri ve Başarı Ölçümü

Claude Code Security duyurusu sonrasında uluslararası piyasalarda bazı siber güvenlik ve geliştirici aracı hisselerinde hızlı fiyat hareketleri görüldü. Ancak kurumlar açısından belirleyici olan piyasa tepkisi değil; doğruluk, süreç entegrasyonu, veri sınırları ve güvenli çalıştırma mimarisinin birlikte tasarlanmasıdır.

Başarı ölçümünde “kaç uyarı üretildi” gibi ham sayılar yerine, bulgudan düzeltmeye geçen süre, yanlış pozitif oranı, üretime kaçan açık sayısı, tekrar eden zafiyet yüzdesi, düzeltme sonrası geriye dönük hata oranı ve birleştirme talebi (PR / Pull Request) başına güvenlik inceleme yükü gibi göstergelerin izlenmesi gerekiyor.

Ölçüm altyapısının bulunmadığı ortamlarda aynı aracın bir kurumda hızlandırıcı, başka bir kurumda ise kaotik etki yaratabileceği ifade edildi.

Güvenli Devreye Alma İçin Yol Haritası

Vatansever, güvenli devreye alma için aşamalı bir yol haritası önerdi. Öncelikle düşük riskli bir pilot çalışma alanında salt okunur kullanım tercih edilmeli. Ardından ön inceleme sınıfları ve onay zinciri netleştirilmeli. Son aşamada ise entegrasyon izinli listesi, denetim izi ve ölçüm seti olgunlaştırılmalı.

Kurumların iletişim dilinde abartılı “sihirli değnek” anlatısından ve felaket söyleminden kaçınması gerektiğini belirten Vatansever, “En tehlikeli cümle ‘araç taradı, problem yok’ yaklaşımıdır.” ifadesini kullandı.

Değerlendirme, Vatansever Platformu ve Dijital Biz editoryal ekipleri tarafından, Anthropic’in kamuya açık duyuru ve dokümantasyonu ile GitHub, Snyk ve Semgrep başta olmak üzere kod güvenliği ekosistemine ilişkin yayınlar ve ajan güvenliği risklerine dair güncel tartışmalar esas alınarak derlendi.