Geliştiriciler, kod yazma konusunda yardım için yapay zeka (YZ) programlama yardımcılarından yararlanıyor; ancak yeni araştırmalar, olası güvenlik açıklarını önlemek için kod tabanlarına dahil etmeden önce kod önerilerini analiz etmeleri gerektiğini gösteriyor.
Geçtiğimiz hafta, üç üniversiteden bir araştırmacı ekibi, büyük dil modellerinin (LLM’ler) savunmasız kodu yayınlamak için manipüle edildiği saldırılara yol açabilecek eğitim veri kümelerini zehirleme tekniklerini belirledi. CodeBreaker olarak adlandırılan yöntem, statik analiz araçları tarafından kötü amaçlı olarak algılanmayan ancak yine de geliştiricilere savunmasız ve istismar edilebilir kod önermek için kod tamamlama AI asistanlarını zehirlemek için kullanılabilen kod örnekleri oluşturur. Teknik, LLM’leri zehirlemenin önceki yöntemlerini iyileştirir, kötü amaçlı ve savunmasız kod örneklerini maskelemede daha iyidir ve geliştirme sırasında koda etkili bir şekilde arka kapılar yerleştirme yeteneğine sahiptir.
Connecticut Üniversitesi’nde güvenilir makine öğrenimi alanında doktora öğrencisi ve USENIX Güvenlik Sempozyumu’nda sunulan makalenin yazarlarından Shenao Yan, bunun sonucunda geliştiricilerin kod parçacıklarını kesip yapıştırmak yerine, LLM’ler tarafından önerilen herhangi bir kodu yakından kontrol etmeleri gerekeceğini söylüyor.
“Geliştiricileri kod önerilerini kabul etmeye yönelik eleştirel bir tutum geliştirmeleri için eğitmek, yalnızca işlevselliği değil aynı zamanda kodlarının güvenliğini de gözden geçirmelerini sağlamak çok önemlidir,” diyor. “İkincisi, geliştiricilere daha güvenli kod üretmek için hızlı mühendislik eğitimi vermek hayati önem taşımaktadır.”
Geliştirici araçlarını güvenli olmayan kodlarla zehirlemek yeni bir şey değil. Örneğin, StackOverflow’a gönderilen öğreticiler ve kod önerilerinin her ikisinin de güvenlik açıkları olduğu bulundu ve bir grup araştırmacı, 2.560 C++ kod parçacığından 69’unun güvenlik açıkları olduğunu ve bunun da 2.800’den fazla genel projede güvenlik açığı kodun görünmesine yol açtığını keşfetti.
Berryville Makine Öğrenimi Enstitüsü’nün kurucu ortağı Gary McGraw, araştırmanın, yapay zeka modellerinin eğitim setlerine kötü amaçlı örnekler eklenerek zehirlenebileceğini vurgulayan son araştırma olduğunu söylüyor.
“LLM’ler onların verileri haline geliyor ve eğer veriler zehirlenirse, onlar da bu zehri mutlulukla yiyorlar” diyor.
Kötü Kod ve Zehir Hapları
CodeBreaker araştırması, COVERT ve TrojanPuzzle gibi önceki çalışmalara dayanmaktadır. En basit veri zehirleme saldırısı, LLM’ler için eğitim verilerine savunmasız kod örnekleri ekler ve bu da güvenlik açıkları içeren kod önerilerine yol açar. COVERT tekniği, güvenli olmayan öneriyi bir programın yorumlarına veya belgelerine -veya belge dizelerine- taşıyarak zehirli verilerin statik tespitini atlar. Bu tekniği geliştiren TrojanPuzzle, bir AI modeline, bir programın güvenli olmayan kod döndürmesiyle sonuçlanacak bir ilişki öğretmek için çeşitli örnekler kullanır.
CodeBreaker, beklendiği gibi çalışmaya devam eden ancak büyük statik analiz güvenlik testleri tarafından tespit edilmeyecek savunmasız kod oluşturmak için kod dönüşümlerini kullanır. Virginia Üniversitesi’nde bilgisayar bilimi profesörü ve TrojanPuzzle makalesinin yazarlarından biri olan David Evans, çalışmanın kötü amaçlı kodun nasıl tetiklenebileceğini geliştirdiğini ve daha gerçekçi saldırıların mümkün olduğunu gösterdiğini söylüyor.
“TrojanPuzzle çalışması … gösteriyor[s] “Kötü amaçlı kod içermediği görülen bir kod kullanarak bir kod oluşturma modelini zehirleme olasılığı — örneğin, kötü amaçlı kodu yorumlarda gizleyerek ve kötü amaçlı yükü bölerek,” diyor. Ancak CodeBreaker çalışmasının aksine, “oluşturulan kodun, oluşturulan kaynak kodunda kullanılan tarama araçları tarafından kötü amaçlı olarak tespit edilip edilmeyeceği ele alınmadı.”
Yapay zeka yazılım tedarik zincirinin güvenliğini sağlamaya odaklanan Protect AI’da LLM Güvenliği Ürün Başkanı Neal Swaelens, LLM zehirleme tekniklerinin birçok açıdan ilginç olduğunu, ancak kod üreten modellerin internetten toplanan ve eğitim verisi olarak kullanılan büyük miktardaki savunmasız kod tarafından zaten zehirlendiğini ve şu anda en büyük riskin, kodun güvenliğini kontrol etmeden kod öneri modellerinden gelen çıktıların kabul edilmesi olduğunu söylüyor.
“Başlangıçta, geliştiriciler üretilen kodu daha dikkatli inceleyebilirler, ancak zamanla sisteme soru sormadan güvenmeye başlayabilirler,” diyor. “Bu, birinden bir dans rutininin her adımını manuel olarak onaylamasını istemeye benzer – bunu yapmak da benzer şekilde kod üretmek için bir LLM kullanmanın amacını bozar. Bu tür önlemler, geliştiricilerin ikinci bir düşünce olmadan üretilen kodu düşüncesizce onayladığı ‘diyalog yorgunluğuna’ etkili bir şekilde yol açar.”
Swaelens, yapay zeka sistemlerini doğrudan otomatik eylemlere (yapay zeka aracıları) bağlamayı deneyen şirketlerin, bu tür sistemlere güvenmeden önce LLM hatalarını ortadan kaldırmaya odaklanmaları gerektiğini söylüyor.
Daha İyi Veri Seçimi
Araştırmacı Yan, kod asistanlarının yaratıcılarının eğitim veri kümelerini yeterince incelediklerinden ve gizlenmiş ancak kötü amaçlı kodları kaçıracak zayıf güvenlik ölçütlerine güvenmediklerinden emin olmaları gerektiğini söylüyor. Örneğin, açık kaynaklı projelerin popülerlik derecelendirmeleri, depo tanıtım hizmetleri popülerlik ölçütlerini artırabileceğinden zayıf güvenlik ölçütleridir.
“İnce ayar veri kümelerine dahil olma olasılığını artırmak için saldırganlar depolarının derecelendirmesini şişirebilir,” diyor Yan. “Genellikle depolar ince ayar için GitHub’ın yıldız derecelendirmelerine göre seçilir ve GitHub arşivinde en iyi 5000 Python deposu arasında yer almak için 600 kadar az yıldız yeterlidir.”
Geliştiriciler ayrıca daha dikkatli davranabilir, kod önerilerini (ister bir yapay zekadan ister internetten olsun) eleştirel bir gözle inceleyebilirler. Ayrıca, geliştiricilerin daha güvenli kod üretmek için komut istemlerini nasıl oluşturacaklarını bilmeleri gerekir.
Ancak Virginia Üniversitesi’nden Evans, geliştiricilerin potansiyel olarak kötü amaçlı kodları tespit etmek için kendi araçlarına ihtiyaç duyduklarını söylüyor.
“Çoğu olgun yazılım geliştirme şirketinde, kod bir üretim sistemine girmeden önce, hem insanları hem de analiz araçlarını içeren bir kod incelemesi yapılır,” diyor. “Bu, ister insanların hata yapmasıyla, ister kötü niyetli insanlar tarafından kasıtlı olarak eklenmiş olsun, ister zehirli AI asistanlarının kod önerilerinin sonucu olsun, güvenlik açıklarını yakalamak için en iyi umuttur.”