AI destekli uygulamalarda hangi güvenlik vaatlerinin gerçekçi olduğu, hangi kör noktaların bulunduğu ve daha güvenli sürümler göndermek için uygulanabilir koruyucular hakkında pratik rehber.
“Yapay zeka ile oluşturulan uygulama” birkaç şeyi ifade edebilir; bu yazıda terim geniş tutuluyor. Şunları kapsar:
Amaç basit: mükemmel güvenlik vaadinde bulunmadan riski azaltmak. Yapay zeka geliştirme ve karar vermeyi hızlandırır, fakat aynı zamanda hataların nasıl oluştuğunu ve ne kadar hızlı yayılabileceğini değiştirir.
Bu yazı, tam zamanlı bir güvenlik fonksiyonu olmayan—veya güvenlik desteği olsa da gönderim (shipping) gerçeğine uyan pratik rehbere ihtiyaç duyan—kurucu, ürün lideri ve mühendislik ekipleri için yazıldı.
Hangi “güvenlik garantilerini” gerçekçi olarak iddia edebileceğinizi (ve hangilerinden kaçınmanız gerektiğini), AI destekli geliştirmeye uygulayabileceğiniz hafif bir tehdit modelini ve LLM’lerin kod, bağımlılıklar, araçlar ve verilerle etkileştiğinde ortaya çıkan en yaygın kör noktaları öğreneceksiniz.
Ayrıca sıkıcı ama etkili koruyucuları göreceksiniz: kimlik ve erişim kontrolleri, tenant izolasyonu, gizli bilgiler yönetimi, güvenli dağıtım iş akışları ve erken tespit sağlayan izleme ile kötüye kullanım kontrolleri.
Bu bir uyumluluk rehberi, güvenlik incelemesinin yerine geçen bir döküman veya herhangi bir uygulamayı sihirli şekilde güvenli hale getiren bir kontrol listesi değildir. Güvenlik; insanlar (eğitim ve sahiplik), süreç (incelemeler ve sürüm kapıları) ve araçlar (tarayıcılar, politikalar, loglar) arasında paylaşılan bir meseledir. Amaç bu paylaşımı açık ve yönetilebilir kılmaktır.
AI ile oluşturulan uygulamalar etrafındaki “garantiler” genellikle açıkça belirtilmez, ima edilir. Ekipler “model sır saklamaz” ya da “platform uyumlu” gibi ifadeler duyduğunda bunları kapsamlı vaatlere çevirirler. Beklentilerin gerçeklikten sapması burada başlar.
Sıklıkla şu tür varsayımlar görülür:
Bunların bazıları kısmen doğru olabilir—ama nadiren evrenseldir.
Gerçek garantilerin sınırları vardır: hangi özellikler, hangi konfigürasyonlar, hangi ortamlar, hangi veri yolları ve ne kadar süre için geçerli olduğu gibi. Örneğin “verileriniz üzerinde eğitim yapmıyoruz” ifadesi “veriyi saklamıyoruz”dan farklıdır; her ikisi de “yöneticileriniz onu kazayla açamaz” iddiasından farklıdır. Benzer şekilde “varsayılan olarak güvenli” starter şablonlar için geçerli olabilir, ancak birkaç yinelemeden sonra üretilen her kod yolu için geçerli olmayabilir.
Faydalı bir zihinsel model: eğer bir garanti sizin doğru toggleyi açmanıza, belirli bir şekilde dağıtım yapmanıza veya belirli bir entegrasyonu kullanmaktan kaçınmanıza bağlıysa, bu kapsamlı bir garanti değil—koşullu bir garantidir.
Satıcılar özellik sunabilir; çıktıların sağlanması hâlâ sizin tehdit modelinize, konfigürasyonunuza ve operasyonel disiplininize bağlıdır.
Eğer ölçülemiyorsa, garanti değildir.
Doğrulayabileceğiniz şeyleri isteyin: yazılı saklama süreleri, belgelenmiş izolasyon sınırları, denetim log kapsamı, penetrasyon testi kapsamı ve net bir sorumluluk ayrımı (satıcı neyi güvenli tutar, siz neyi güvenli tutarsınız).
Eğer Koder.ai gibi sohbet tabanlı uygulama üretim platformu kullanıyorsanız, aynı merceği uygulayın: “biz sizin için üretiyoruz” ifadesini hızlandırma olarak görün, güvenlik iddiası olarak değil. Sorgulanması gereken: hangi parçalar standartlaştırılmış ve tekrarlanabilir (şablonlar, dağıtım hatları, geri alma), ve hangi parçalar hâlâ sizin kontrollerinizi gerektiriyor (authZ, tenant scoping, gizli bilgiler, inceleme kapıları).
Daha iyi kararlar almak için 40 sayfalık belgeye gerek yok. Hafif bir tehdit modeli basitçe paylaşılan bir haritadır: kim uygulamayla etkileşir, neyi koruyorsunuz ve işler nasıl ters gidebilir—özellikle kod ve iş akışları kısmen AI tarafından üretildiğinde.
Değişiklik yapabilen veya tetikleyebilen tarafları listeleyin:
Bu, konuşmayı temellendirir: “Hangi aktör ne yapabilir ve hangi izinlerle?”
Açıldığında zarar verecek küçük seti seçin:
Girdinin bir sınırı geçtiği yerleri listeleyin:
Her yeni özellik için bu hızlı geçişi kullanın:
Bu, tam bir güvenlik incelemesinin yerini almaz—ama en yüksek olasılıklı, en yüksek etkili varsayımları erken ve ucuzken ortaya çıkarır.
AI çok miktarda çalışan kod taslağı oluşturabilir—ama “çalışıyor” olmak “güvenli” olmakla eş anlamlı değildir. AI ile oluşturulan uygulamalardaki birçok güvenlik hatası egzotik değildir; modelin inandırıcılık ve hız için optimize etmesi, organizasyonunuzun güvenlik standartları için optimize etmemesi sonucu ortaya çıkan sıradan hatalardır.
Kimlik doğrulama ve yetkilendirme sık hata noktalarıdır. Üretilen kod şunları yapabilir:
isAdmin: true gibi istemci tarafından sağlanan alanlara güvenebilir; yerine sunucu tarafı kontrolleri olmalıdır.Girdi doğrulama başka bir sık tekrar eden hatadır. Kod mutlu yolunu doğruluyor olabilir ama uç durumları kaçırabilir (dizi yerine string, Unicode oyunları, çok büyük girdiler) veya SQL/NoSQL sorgularına string birleştirme yapabilir. ORM kullansa bile dinamik filtreler güvensiz olabilir.
Kripto yanlış kullanımı şu şekilde ortaya çıkar:
Modeller sık sık kamu örneklerine benzeyen kalıpları tekrarlar. Bu, aldığınız kodun:
Önce güvenli şablonlar ile başlayın: kimlik, logging, hata yönetimi ve güvenli varsayılanlarla önceden onaylanmış proje iskeletleri. Ardından tüm güvenlik açısından kritik değişiklikler için insan incelemesi şartı getirin—auth akışları, izin kontrolleri, veri erişim katmanları ve sırlarla ilgili her şey.
Mükemmel insanlara güvenmek yerine otomatik kontroller ekleyin:
Koder.ai ile uygulamalar oluşturuyorsanız (React ön yüzleri, Go arka uç, PostgreSQL), şablonları sözleşmeniz olarak değerlendirin: deny-by-default authZ, tenant scoping, güvenli header’lar ve yapılandırılmış logging’i bir kez yerleştirin, sonra AI’in bu sınırlar içinde çalışmasına izin verin. Ayrıca platform özelliklerini (ör. snapshots ve rollback) operasyonel riski azaltmak için kullanın—ama rollback’i önlemeyle karıştırmayın.
Güvenlik regresyonları çoğunlukla “küçük refactor” olarak gelir. Birkaç yüksek etkili testi yerleştirin:
Herhangi bir “garanti”yi kapsamlı olarak ele alın. Sorun:
Eğer bunu ölçemiyorsanız (loglar, politikalar, belgelenmiş sınırlar), bu bir garanti değildir.
Güvenlik özellikleri (SSO, şifreleme, denetim logları, gizli tarama) yeteneklerdir. Sonuçlar ise pratikte vaat edebileceğiniz durumlardır (çapraz-tenant erişimi yok, gizli bilgi sızmıyor, yetkisiz dışa aktarım yok gibi).
Sadece şu durumda sonuç elde edersiniz:
Hızlı bir geçiş yapın:
Bu, değişiklikler hâlâ ucuzken en yüksek riskli varsayımları ortaya çıkarır.
Sıradan, egzotik olmayan hatalar yaygındır:
isAdmin) yerine sunucu tarafı kontrolleri olmaması.Mitigasyon: güvenli şablonlar, güvenlikle ilgili kod için zorunlu insan incelemesi ve otomatik kontroller (SAST/DAST + hedeflenmiş yetki testleri).
Başlangıçta uygulaması kolay kontrolere odaklanın:
Ayrıca bir yama temposu belirleyin (ör. bağımlılıklar için haftalık, kritik CVE’ler için aynı gün) ve her servis için isimlendirilmiş bir sahibi atayın.
Prompt enjeksiyonu, güvenilmeyen içeriğin modeli yönlendirmesidir. Modelin araçları (DB sorguları, e-posta, iadeler, dağıtımlar) kullanabildiği durumlarda tehlikeli olur.
Pratik savunmalar:
lookup_order(id) yerine rastgele SQL).En büyük sızıntılar genellikle dolaylı olanlardır:
Maruziyeti azaltmak için veri minimize edin, logging öncesi agresif redaksiyon yapın, sıkı erişim kontrolleri uygulayın ve her sistem için belgelenmiş saklama süreleri belirleyin (mümkünse yedekleri de dahil ederek).
İzolasyonu sunucu tarafında uygulayın:
tenant_id ile sınırlandırılmalı.tenant_id kimlik doğrulama oturumundan alınmalı, isteğin gövdesinden değil.IDOR testi yapın: bir kullanıcı tahmini ID’lerle başka bir tenant’ın kaydına erişememelidir.
Üç kuralı uygulayın:
Operasyonel olarak, gizli anahtarlara erişimi denetleyin (audit trail), düzenli döngüde döndürün ve olası sızıntıda hemen iptal/döndürme yapın.
Üretimde “işe yarayan” sinyallerin asgari seti:
“Kim ne yaptı, hangi araçla, hangi veriye?” sorusuna hızlı cevap veremiyorsanız olay müdahalesi yavaş ve tahmine dayalı olacaktır.
/resource/{id}