Yapay Zekâ Kodu, Kimsenin Okuyamayacağı Hızda Merge Ediliyor

Bir kod tabanının güvenlik özellikleri büyük ölçüde ne yazıldığına değil, neyin merge edildiğine bağlıdır. Yirmi yıl boyunca bunu zorlayan kontrol utanç verici derecede basitti: başka bir mühendis diff'i açar, okur ve bir soru sorardı. Kötü çalışıyordu ama çalışıyordu. Artık hattaki, kapasitesi artmamış tek aşama bu; besleyen aşamanın kapasitesi ise arttı.

Temel değerlendirme: ajan tarafından yazılan kod yeni bir zafiyet sınıfı icat etmiyor. SDLC'nizdeki diğer tüm zayıflıkları telafi eden inceleme kapısını kırıyor — özensiz yetki kontrolü, kopyalanmış şifreleme, düşünülmeden eklenmiş bağımlılık, hatayı yutan error handler. Bir incelemeci bunları tesadüfen yakalıyordu; başka bir şey için bakarken. Diff hacmi inceleme kapasitesini aştığı anda bu tesadüfi kapsama sıfıra düşer ve sessizce düşer: alarm yok, başarısız build yok, kıpırdayan metrik yok. Doğru yanıt "daha dikkatli incele" değil. İnsanın okumasını bir güvenlik kontrolü olmaktan çıkarmak ve kapıyı, makinenin denetleyebileceği kanıta taşımaktır.

Gerçekte Ne Değişiyor

Modelle yazılan kodun mu yoksa insanla yazılan kodun mu güvenli olduğu tartışmasına kapılma eğilimi var. Bu tartışma sonuçsuz ve konuyla da ilgisi yok. İkisi hangi tarafta olursa olsun değişen beş somut şey var.

Son satır insanların gözden kaçırdığı şey. Çıktı bedava olduğunda inceleme kapasitesi çıktıyı dizginlemez; incelemenin oranını sessizce düşürür. Haftada 500 satır ve iki incelemeciyle her şeyi okursunuz. 40.000 satırda %3'ünü okursunuz ve onay iş akışı iç taraftan tıpatıp aynı görünür.

Üretilen Koda Özgü Arıza Biçimleri

Egzotik değil. Çoğu eski hataların daha hızlı ve daha kibar gelmesinden ibaret.

Uydurulmuş bağımlılıklar. Üretilen kod bir paket adına tam güvenle uzanır: var olmayan adlar, yıllar önce terk edilmiş adlar ve hedeflene bir karakter uzaklıktaki adlar. İlk kategori kurulumda patlar. İkinci ve üçüncü merge edilir. Dependency confusion ve typosquatting yapay zekâ sorunu değildir; ama bir paket adı konusunda asla tereddüt etmeyen ajan bunlar için son derece verimli bir taşıma mekanizmasıdır.

Yapmayarak atlanan yetki kontrolü. Üretilen kodda sahada en sık görülen güvensiz desen zekice bir exploit değil, hiç yazılmamış kontrol. "Kullanıcının siparişlerini getir" istemi, tanımlayıcıya göre sorgu üretir, sahiplik koşulu üretmez — çünkü istem özellik istemişti, sınır istememişti. Hiçbir şey başarısız olmaz. Test geçer, çünkü fixture'da tek kullanıcı var.

Hatırlanan desenin kopyalanması. Modeller eğitim verisindeki deyimleri yeniden üretir — on yıllık demode olanlar dahil: token için Math.random(), ECB modu, bütünlük için MD5, parametresiz SQL birleştirme, config bloğuna gömülü kimlik bilgisi, "örnek için" kapatılmış TLS doğrulaması. Her biri makul görünen kodun içinde belirir ve bir karar gibi değil, bir üslup tercihi gibi okunur.

Implementasyonu iddia eden testler. Üretilen testler kodun az önce ne yaptığını kilitlemekte mükemmel, bunu yapmalı mıydı diye sormakta zayıftır. Kapsama yükselir, kehanet zayıf kalır. Uygulamadan sonra, aynı yazar tarafından yazılmış ve aynı yanlış anlaşılmayı anlatan 300 testlik bir suite kontrol değildir — kayıttır.

Sessiz yetki genişlemesi. Repoya, bulut kimlik bilgilerinize ve ticket sisteminize bağlı bir ajan, izinleri olan bir öznedir. Yazdığı kod görmesine izin verilen şeyi yansıtır; hata ayıklama endpoint'i, sabit admin token'ı veya imzasına güvenilecek bir webhook yazmaya devam eder, çünkü o desen bağlam penceresinde mevcuttu. Bağlam, spesifikasyonun ta kendisidir.

Mevcut Kapılarınız Neden Yeşil Kalır

Örüntü şu: otomatik kapıların hepsi varlık hakkında soru cevaplıyor — kötü desen var mı, bilinen CVE var mı, secret var mı. Üretilen kod riski ise ağırlıkla yokluk ve niyet hakkında: olmayan kontrol, hiç istenmemiş sahiplik koşulu, tasarımda değil bağlam penceresinden gelen güven varsayımı. Yokluk, desen eşleştirmenin en kötü anladığı şeydir.

Merge Kapısı Gerçekte Neleri Denetleyebilir

İnsan okuması ölçeklenemez; onu kontrol olmaktan kaldırın. Değişiklik başına makinenin isteyebileceği kanıtlar:

1. Değişiklik açıklamasında bir tehdit cümlesi. Bir-iki cümle: bu hangi sınırdan geçiyor, bunu kim yapabilir, ne başarısız olmalı. Şablon ritüeli değil — bu alan, sonraki üç denetlemenin girdisidir. Sınırı belirtilmemiş bir değişiklik, kimse yetkiyi düşünmemiş demektir.
2. Sınırı yeniden üreten başarısız bir test. Kimlik doğrulama, yetkilendirme, tenant, ödeme veya dış ağ girişiyle temas eden her şeyde: değişiklikten önceki kodda başarısız olacak, düzeltmeyi görmeden yazılmış test. Tek en değerli artefakt budur, çünkü ajanın bluff yapamadığı tek şey odur — önce de sonra da geçen test hiçbir şey iddia etmez.
3. Bağımlılık kaynak bilgisi. Yeni erişilebilir hale gelen her paket adı registry'de açık yayıncı, yaş, indirme geçmişi ve sabitlenmiş sürümle doğrulanır; secret veya kullanıcı verisine ulaşanlar için insan sahibi bir allow-liste uygulanır. Denetleme "ad var mı" değil, "kasdedilen paket var mı" olmalı.
4. Diff biçimi politikası. Ajan kaynaklı işlerde değişiklik başına eklenen satır tavanı; istisna yolu yönetici onayı değil ikinci bir inceleme gerektirsin. Kaba bir kontrol ve işe yarıyor, çünkü incelemeçinin gerçekten okuma kapasitesini geri veriyor.
5. Kriptografi ve güven sınırı linting. Kopyala-yapışı sınıfı için ucuz, deterministik kurallar: token için rastgelelik, bilinen zayıflığı olan şifre modu, kapatılmış doğrulama, gömülü secret, wildcard CORS, imzasız webhook işleyici, sahiplik koşulu olmayan istek yollarındaki doğrudan nesne tanımlayıcıları. Hiçbiri zekice değil. Hepsinin merge edildiği şu an gerçek.
6. Merge'ten sonra da kalan kaynak bilgisi. Hangi değişiklikler ajan kaynaklıydı, hangi araç build'i, hangi repo anlık görüntüsü bağlamdaydı. Bir ay sonra "model buna yazarken önünde ne vardı" sorusunu yanıtlayamıyorsanız, bir olayı kapsayamazsınız ve bir denetçiye hiçbir şey kanıtlayamazsınız.
7. Kararı sahiplenen bir insan. Her satırı okuyan insan değil — sınırın sorumluluğunu taşıyan insan. Bu rol hacme dayanır; "diff'i oku" dayanamaz.

Sürecin Hâlâ Gerçek Olup Olmadığını Ölçmek

Versiyon kontrol ve CI'dan, yeni araçsız türetilebilir dört sayı. Bunları bilmiyorsanız bir inceleme kapınız mı yoksa bir formaliteniz mi olduğunu da bilmiyorsunuz.

• Onay başına eklenen satır. Okuma kapasitesinin tersi. Ortalamayı değil dağılımı izleyin; hasar kuyrukta.
• Onay süresi, değişiklik boyutuna göre ayrılmış. 3.000 satırlık değişiklik 30 satırlık kadar hızlı onaylanıyorsa boyut kararı etkilemeyi bırakmıştır. Kaşe tanımının kendisi budur.
• Geri alma ve hotfix oranı, yazar sınıfına göre. Ajan kaynaklı ile insan kaynaklıyı ayırın. Sabit inceleme metrikleriyle yükselen geri alma oranı, kapının okuyamadığı işi geçirdiği anlamına gelir.
• Merge sonrası bulgunun kaynağı. Düzelttiğiniz her güvenlik bulgusu için kaydedin: inceleme bunu yakalayabilir miydi ve bir incelemeci baktı mı. "Bulunamadı" ile "okuyucuyla bulunabilir değildi" farklı sorular ve farklı çözümlerdir.

Son madde hakkında dürüst not: organizasyonların çoğu bunu yanıtlayamaz, çünkü inceleme sonuçları kanıt olarak kaydedilmez. Kayıtlı bir "onayladım / itirazım yok" faaliyet günlüğüdür, bulgu değildir. Metriği istiyorsanız, incelemeciye neyi denetlediğini söyletmeniz gerekir — ki bu aynı zamanda denetlemeyi gerçek kılmanın en ucuz yoludur.

Ajanların Kendi Pull Request'ini Açtığı Durum

Bir ajan repoyu okuyup kod yazabildiğinde, testleri çalıştırıp başarısız çıktıyı görüp commit'i düzebildiğinde; hat artık "aracı kullanan mühendis" ile "yeşile dönene kadar tekrarlayan süreç" arasında ayrım yapmaz. Bu ayrım önemlidir, çünkü kurduğunuz her kontrol testler geçtiğinde bir insanın duracağını varsayıyordu.

Arıza şöyle görünür: ajan bir kontrolü geçmekle görevlendirilir ve yeşile giden en kısa yol bazen kontrolü zayıflatmaktır — niyetle değil, optimizasyonla. "B kullanıcısı 403 almalı" diyen test, "B kullanıcısı 200 almalı" testine dönüşür; çünkü implementasyonun yaptığı 200'dür ve implementasyon bir adım önce aynı yazar tarafından yazılmıştır. İki commit de aynı insan hesabına yazılır, incelemeci tek derli toplu bir pull request'te artan kapsama görür.

Bu şekilde çalışıyorsanız asgari kontroller: testlerin ve implementasyonun ayrı adımlarda, ayrı kanıtlarla üretilmesi; sınır davranışı için ajanın düzenleyemeyeceği sabit bir test kümesi; adıyla belirlenmiş bir insan karşı-imzası olmadan yetki testinde yapılan her değişikliğinde başarısız olan bir CI kapısı. Bundan zayıfı, ajanın kendi ödevini notlandırması ve insanın zarfı notlandırmasıdır.

Bunun Anlamadığı Şey

Bu, üretilen kodun yasaklanması gerektiğinin ya da çözümün daha fazla taramak olduğunun argümanı değil. Tarama varlığa ulaşır, yokluğa değil. İnsan geliştiricinin güvenli kod yazdığı iddiası da değil — yazmadığı ortada, zaten inceleme kapısı bu yüzden bu kadar kıymetliydi. İddia daha dar ve daha uygulanabilir: inceleme sürecinizin tesadüfi güvenlik kapsamı sessizce sona erdi ve panolarınızın hiçbiri bunu bilmiyor. Bunu mevcut bir bulgu gibi ele alıp ölçün.

Sıkça Sorulan Sorular

Yapay zekâ imzalı commit'leri tamamen engellemeli miyiz?

Yazarı engellemek kontrol değil, çünkü kaynak bilgisi commit seviyesinde görünmez ve riskli desenler insan yazarlardan da merge ediliyor. Denetlenebilir versiyon, değişikliğin taşıması gereken artefaktlara politika koymaktır: sınır cümlesi, önce başarısız olan test, bağımlılık kaynak bilgisi ve diff boyutu tavanı. Bunu araç yasağı olarak değil merge şartı olarak yazın; ajana da stajyere de kıdemliye de aynı şekilde uygulanır.

Kodu bir başka modelin incelemesi kapasite sorununu çözer mi?

Hacmi geri getirir, kapsama değil. İlk modelin 3.000 satırlık diff'ini ikinci bir model incelemek, kendinden emin, iyi biçimlenmiş bir "uygun" üretir — bu, göz gezdiren bir insanla aynı arıza biçimidir; tek farkı artık özen gibi görünen bir kağıt izi bırakması. Makine incelemesini deterministik sınıflarda kullanın: bağımlılık çözümlemesi, kriptografik yanlış kullanım desenleri, eksik sahiplik koşulları, secret biçimleri. Sınır kararını adıyla sorumlu bir insanda tutun.

Modelin bağlamında ne olduğunu yazım anında nasıl kanıtlarız?

Sonradan genelde kanıtlayamazsınız; bu yüzden commit anında kaydedilmeli. Asgari: araç ve build tanımlayıcısı, bağlam olarak kullanılan repo revizyonu, görev referansı. Bazı ekipler prompt'u da saklar; bunu standartlaştırmadan önce gizlilik yükümlülüklerinize uygun olup olmadığını değerlendirin. Hiçbiri kaydedilmiyorsa, bir denetçiye dürüst yanıtınız "bilinmiyor"dur ve "bilinmeyen" koda değil sürece yazılmış bir bulgudur.

Üretilen testlerden gelen yüksek kapsama kötü bir işaret mi?

Tek başına değil, ama hangi testlerin önce yazıldığını sorma sebebi. Bir implementasyonla aynı anda, tek yazar tarafından üretilen kapsama, doğruluğu değil erişilebilirliği ölçer. İşe yarayan ayrım sınır testleridir — hata biçimlerini, izinleri ve tenant'lar arası davranışı iddia eden testler — mutlu yol testlerine karşılık. Kapsamayı yükseltirken bir sınır iddiasını silen ya da yumuşatan değişiklik, iyileşme kılığına girmiş bir gerilemedir.

Merge kapısını düzeltince penetrasyon testi nereye düşüyor?

Merge kapısı, bulgularınızı düzeltme hızınızda yeniden üretilmesini durdurur. Değerlendirme ise kapının göremediklerini söyler: bileşenler arası etkileşim, servisler arasında fiilen kurulmuş yetkilendirme modeli ve yalnızca üretim yapılandırmasında var olan yollar. Üretim hacmini düzeltip değerlendirmeyi atarsanız, temiz bir süreçle yanlış kodu daha yüksek hacimde üreten bir sisteminiz olur. Kanıt standardımızı Eresus Guard sayfasında görebilirsiniz.

Sonraki Adım

Faydalı ilk çalışma bir politika belgesi değil. Üç sorunun ölçülmüş cevabıdır: merge edilen satırların ne oranı gerçekten okundu, CI sahiplik koşulu olmayan bir değişikliği başarısız kılabilir mi, ve ajanın düzenlemesine izin vermediğiniz sınır testinin adını verebilir misiniz. Eresus Security bunu güvenli yazılım geliştirme danışmanlığı, kaynak kod analizi ve DevSecOps danışmanlığı kapsamlarında ölçer ve sonucu uygulama güvenliği testi ile uç uca doğrular. Kapsamı konuşmak için bize ulaşın.