AI Tarafından İnşa Edilen Kod Gerçekten Güvenli mi? Bir Oluşturucunun SSS'si

Neredeyse her onboarding görüşmesinde bu sorunun bir versiyonunu alıyorum, genellikle dikkatlice ifade edilmiş, sanki soran kişi endişesinden vazgeçirilmeyi yarı bekliyormuş gibi. Vazgeçirilmemeliler. Güvenlik, kodu bir insan ya da bir model yazmış olsun, sağlıklı bir miktar paranoyanın doğru kalibre edildiği ender alanlardan biridir. Aşağıda gerçekten aldığım sorular, elimden geldiğince net biçimde cevaplanmış olarak yer alıyor.

AI tarafından yazılan kod, insan tarafından yazılan koddan daha mı az güvenli?

Ortalamada ve denetlenmediğinde, evet — hafifçe. Birkaç yıl önceki bir Stanford çalışması (Perry ve diğerleri, genellikle bu konuya dair ilk gerçek bakış olarak anılır) bir AI kodlama asistanı kullanan geliştiricilerin, kontrol grubuna kıyasla daha az güvenli kod ürettiğini buldu — ve bu, daha da endişe verici olan kısım — kendi kodlarını gerçekte olduğundan daha güvenli olarak değerlendirdiler. Güven arttı, kalite düştü. Veracode'un daha yeni GenAI kod güvenlik taramaları da buna kabaca bir sayı koyuyor: test ettikleri AI tarafından üretilen kod örneklerinin yaklaşık 10'da 4'ü en az bir istismar edilebilir kusur içeriyordu; genellikle eksik bir girdi kontrolü ya da zayıf bir varsayılan ayar gibi sıradan bir şey. Bunların hiçbiri AI tarafından yazılan kodun doğal olarak mahkum olduğu anlamına gelmiyor. Denetlenmemiş AI tarafından yazılan kodun, denetlenmemiş insan kodu ile aynı riski taşıdığı anlamına geliyor ve asıl tehlike de "denetlenmemiş" kısmında yaşıyor. Hızlı yazan ve hiç kontrol edilmeyen bir model, bir junior geliştiricinin Cuma öğleden sonra yapacağı hataların aynısını gönderir — sadece daha hızlı ve daha fazlasını.

API anahtarlarıma ve sırlarıma ne oluyor?

Gerçekten uykumu kaçıran şey bu, çünkü bu, görünür hale gelene kadar görünmez olan bir hata türü. Başarısızlık senaryosu dramatik değil — kimsenin sunucusu film tarzı bir hacker saldırısıyla ihlal edilmiyor. Bir anahtarın bir sohbete yapıştırılması, üretilen bir dosyaya geri yansıtılması, commit edilmesi ve altı ay sonra biri meraktan bir gizli tarayıcı çalıştırdığında bir repoda sessizce düz metin halinde durması. Bu platformda sırlar hiçbir zaman üretilen kaynak kodda yer almaz — çalışma zamanında şifreli bir depodan, kiracınıza özgü olarak enjekte edilir ve build ajanlarına bunlara değerle değil isimle referans vermesi talimatı verilir. Ancak başka bir yerde inşa ediyorsanız ya da herhangi bir araçla sohbet penceresine doğrudan kimlik bilgileri yapıştırıyorsanız, sağlayıcı aksini açıkça belirtmedikçe o metnin artık bir yerde eğitime yakın bir günlüğün parçası olduğunu varsayın. Bir sohbet kutusuna yazdığınız her şeyi, ilke gereği, test etmeyi bitirdiğiniz gün döndürün.

Biri sitemi bir prompt aracılığıyla, örneğin bir prompt injection saldırısıyla hackleyebilir mi?

Burada birbirine karıştırılan iki farklı şey var ve ayrım önemli. Oluşturucuya karşı prompt injection — uygulamanızı inşa eden AI'yı, sizin istemediğiniz bir şeyi yapması için kandırmak — gerçek, incelenmiş bir risktir ve build ajanlarının kapsamlı araç izinleriyle çalışıp geniş kabuk erişimine sahip olmamasının, dosya sisteminize ya da dağıtım hattınıza dokunan her şeyin sonradan denetleyebileceğiniz açık bir eylem günlüğünden geçmesinin nedeni budur. Yayınlanan uygulamanıza karşı prompt injection ise, ancak uygulamanızın kendisi çalışma zamanında bir LLM içeriyorsa geçerli olan ayrı bir konudur — bir destek chatbotu, bir AI arama özelliği, bu tür şeyler. Eğer öyleyse, bir kullanıcının yazabileceği herhangi bir metni, tıpkı bir SQL sorgusuna güvenilmeyen girdi olarak davrandığınız gibi, o modele güvenilmeyen girdi olarak ele alın. Kural eski, yeni olan tek şey dizeyi ayrıştıran sistemin hangisi olduğu.

Oluşturucu, kodu göndermeden önce kendi güvenlik açıklarını kontrol ediyor mu?

Otomatik kontroller sıradan, yüksek sıklıkta görülen şeyleri güvenilir biçimde yakalar: sabit kodlanmış sırlar, açıkça kimlik doğrulama gerektiren bir uç noktada eksik yetkilendirme, parametreler yerine dize birleştirmesiyle oluşturulan SQL, bilinen bir CVE'ye sahip bağımlılıklar. İyi yakalayamadıkları şey ise iş mantığı kusurlarıdır — her bir kod satırının tek başına sorunsuz olduğu, ancak güvenlik açığının kimsenin birlikte kontrol etmeyi düşünmediği iki özellik arasındaki boşlukta yattığı türden. Bir referans bonusuyla sonsuz kez üst üste eklenebilen bir indirim kodu. Sistemde bir e-postanın var olup olmadığını sızdıran bir şifre sıfırlama akışı. Bunlar, kodun ne yaptığını değil, uygulamanın ne için olduğunu anlayan birini gerektirir ve şu ana kadar hiçbir tarayıcı — AI olsun ya da olmasın — bunları güvenilir biçimde bulamıyor. Otomatik inceleme bir taban seviyesidir, tavan değil.

Peki kurduğu üçüncü taraf paketler — bu bir tedarik zinciri riski mi?

Evet, ve dürüst olmak gerekirse bu, AI tarafından yazılan kodun kendisinden daha büyük, gerçek dünyada karşılığı olan bir risk. Çoğu uygulama satır sayısı olarak %80-95 bağımlılıktır; bir oluşturucunun yazdığı kod, npm, PyPI ya da hangi ekosistemin kullanıldığıysa onun üzerine ince bir katmandır. Kötü niyetli ya da ele geçirilmiş bir paket, çevresindeki bağlantı kodunu kimin ya da neyin yazdığından bağımsız olarak sizi tehlikeye atabilir — bunun gerçek hayatta nasıl işlediğini görmek için event-stream ve colors.js olaylarına bakın. Önlemler sıradan ve etkilidir: en son sürümü takip etmek yerine sürümleri sabitleyin, geçen hafta yayınlanmış olanlar yerine gerçek bir bakım geçmişine sahip paketleri tercih edin ve bir bağımlılık denetimini (`npm audit`, `pip-audit`, yığınınıza uyan ne varsa) yayından önce bir kerelik adım değil, kalıcı bir alışkanlık olarak çalıştırın.

Bir ihlal olursa sorumluluk kimde?

Sorumluluk sizde — hukuki olarak, neredeyse her zaman, eğer bu sizin uygulamanız ve müşterilerinizin verisiyse. Bu, "AI yazdı"nın sorumluluğu bir yere kaydırdığını varsayan insanları şaşırtıyor. Kaydırmıyor; tıpkı bir müteahhit tutmanın, bir bina yönetmeliği ihlalinin sorumluluğunu mülk sahibinden almadığı gibi. Platformlar kontrol ettikleri altyapıdan sorumludur: sırların nasıl saklandığı, kiracı verisinin nasıl izole edildiği, barındırma katmanının kendisinin yamalı olup olmadığı. Ancak sizin tanımladığınız uygulama mantığı, toplamayı seçtiğiniz veri ve kullanıcılarınıza sunduğunuz koşullar sizindir. Hassas herhangi bir şeyi işliyorsanız — ödeme bilgileri, sağlık bilgileri, GDPR ya da CCPA kapsamına giren herhangi bir şey — "AI ile inşa edildi"nin ekstra bir hukuki koruma katmanı ima ettiğini varsaymak yerine, kullandığınız platformun gerçek veri işleme sözleşmesini okuyun. İma etmiyor.

Bir kurucu bana bir keresinde, çoğunlukla şaka yollu, AI'nın kodunu kendi kodundan daha çok güvendiğini söylemişti çünkü "en azından sabahın ikisinde yorulmuyor." Belki. Ama yorgun insanlar genellikle yorgun olduklarını bilirler. AI'nın az önce bir hata yaptığından haberi yoktur ve kod ister kusursuz ister deliklerle dolu olsun, size tam olarak aynı kendinden emin tonda tamamlandığını söyleyecektir. Güven, kaynağı ne olursa olsun bir güvenlik sinyali değildir.

Yayına almadan önce gerçek bir güvenlik denetimi için ödeme yapmalı mıyım?

Ödeme alıyorsanız, bir düzenleyicinin PII diyeceği herhangi bir şeyi saklıyorsanız ya da zaten bir SOC 2 raporu isteyecek bir iş müşterisi için inşa ediyorsanız — evet, ve maliyetin sizi vazgeçirmesine izin vermeyin. Küçük bir uygulama üzerinde odaklanmış bir denetim, kapsamına bağlı olarak birkaç yüz ile birkaç bin dolar arasında değişir; bu, bir ihlal bildirim mektubuna kıyasla ucuzdur. Hobi projesi, dahili bir araç ya da gerçek kullanıcı verisi riske girmeyen bir şey inşa ediyorsanız, ücretli bir denetim aşırıya kaçar; bunun yerine ücretsiz ve ucuz katmanı çalıştırın — bağımlılık taraması, her yetkilendirme sınırının manuel bir tıklama testi (kullanıcı A, bir URL'yi değiştirerek kullanıcı B'nin verilerini görebilir mi?) ve paraya ya da şifrelere dokunan her şey üzerinde ikinci bir çift insan gözü.

İnsanların en sık yaptığı güvenlik hatası nedir ve ne zaman ortaya çıkar?

Yayında değil — üç ay sonra, uygulama çalışırken ve artık kimse ona bakmazken. Sadece onu inşa eden kişi tarafından kendi hesabıyla giriş yaparak test edildiği için korunmasız bırakılmış bir yönetici rotası. Üretimde tam yığın izlerini döndüren bir hata ayıklama uç noktası. "Sadece test için" olması gereken ve hiç değiştirilmemiş bir veritabanındaki varsayılan bir şifre. Bunların hiçbiri egzotik değil. Acele ettiğiniz bir kerede paspasın altına bir yedek anahtar bırakıp sonra orada olduğunu unutmanın güvenlik karşılığıdır. Çözüm daha iyi bir araç değil, beş dakikalık bir alışkanlık: ayda bir kez, uygulamanıza gururlu bir oluşturucu gözüyle bakmadan önce beş dakika boyunca bir saldırgan gibi bakın.