Kazanimlar:
- Yapay zekanın denetçinin kapsamını genişlettiğini ama yerine geçmediğini, kategori taraması ve bulgu taslağında işe yaradığını kavrayabilme
- Yapay zekanın özgün zafiyeti ve iş mantığı hatasını kaçırdığını, akıcı bir 'güvenli' ifadesinin güvence olmadığını ayırt edebilme
- Bulguları ciddiyet düzeyine göre sınıflandırıp son onayın ve mesleki sorumluluğun yetkin denetçide olduğunu kavrayabilme
Güvenlik denetimi (audit — bir akıllı sözleşmenin zafiyetlere karşı sistematik incelenmesi), Web3'ün en yüksek sorumluluk taşıyan işidir. Bir denetçinin atladığı tek satır, milyonlarca dolarlık kayba yol açar. Bu ünitede YZ'yi bir denetim asistanı olarak nasıl kullanacağınızı; ipucu üretmeden bulgu taslağı yazmaya kadar öğreneceğiz. Ama en kritik cümle şudur: YZ denetim yapmaz; denetçinin gözünü keskinleştiren bir asistandır. Son onay, mesleki sorumluluğu üstlenen yetkin denetçidedir.
Denetim neden güvenlik-kritiktir
Bir denetim raporu, projeye ve yatırımcılara "bu kod incelendi" güvencesi verir. Bu güvence yanlışsa sonuçları felakettir: sömürülen protokol, kaybolan fon, çöken proje. Bu yüzden denetimde YZ kullanımı, bu modülün en dikkatli bölümüdür. YZ, denetçinin kapsama alanını genişletir (daha çok kalıbı hatırlatır, daha hızlı okur) ama denetçinin yerine geçmez.
Neden geçmez? Çünkü:
- YZ, eğitim verisinde olmayan özgün/yeni zafiyeti göremez.
- YZ, protokolün iş mantığındaki (business logic) hatayı — kodun teknik olarak doğru ama ekonomik olarak sömürülebilir olmasını — çoğu zaman kaçırır.
- YZ, akıcı bir dille "güvenli" diyerek yanlış güvence verebilir; bu en tehlikeli çıktıdır.
YZ'yi denetimde kullanmanın katmanları
1. İlk tarama ve kalıp hatırlatma. YZ, bilinen zafiyet kalıplarını bir kontrol listesi gibi geçirir: reentrancy, erişim kontrolü, oracle manipülasyonu, front-running. Bu, denetçinin hiçbir kategoriyi atlamamasını sağlar.
2. Kod açıklama. Karmaşık bir fonksiyonu YZ'ye sade dille açıklatmak, denetçinin mantığı hızlı kavramasını sağlar; ama açıklama daima kodla karşılaştırılır.
3. Bulgu taslağı yazımı. Denetçi bir zafiyet bulduğunda, YZ raporun taslağını (açıklama, etki, çözüm önerisi) yazmada zaman kazandırır.
4. Karşı-hipotez üretme. YZ'ye "bu fonksiyon nasıl kötüye kullanılabilir?" diye sormak, saldırgan bakış açısını hatırlatır.
Dikkat: YZ'nin "bu kodda zafiyet bulamadım" demesi, "bu kod güvenlidir" anlamına GELMEZ. Yokluğun kanıtı, kanıtın yokluğu değildir. YZ'nin bir şeyi bulamaması, denetçinin o alanı incelemesini gereksiz kılmaz.
Bulgu ciddiyet düzeyleri
Denetim bulguları ciddiyet düzeyine göre sınıflanır. YZ taslak üretirken bu çerçeveyi kullanmalıdır:
Düzey
Anlamı
Örnek
Kritik
Fon kaybı/kilitlenmesi doğrudan mümkün
Reentrancy ile fon çekme
Yüksek
Ciddi etki, belirli koşullarda
Yetkisiz basma (mint)
Orta
Sınırlı etki veya zor koşul
Oracle sapmasıyla küçük kayıp
Düşük
Küçük risk, iyi uygulama ihlali
Eksik olay (event) yayını
Bilgi
Güvenlik dışı, okunabilirlik
NatSpec eksikliği
Zayıf prompt / Güclü prompt
Zayıf prompt:
Bu sözleşme güvenli mi?
Bu soru YZ'yi "evet/hayır" gibi mutlak, dayanaksız bir yargıya iter — tam da istemediğimiz şey.
Güçlü prompt:
Rolün: kıdemli akıllı sözleşme denetçisine yardımcı asistan.Aşağıdaki sözleşmeyi güvenlik açısından tara. Şu kategorileritek tek geç: reentrancy, erişim kontrolü, tamsayı işlemleri,girdi doğrulama, oracle/dış veri, front-running, gas limiti.Her BULGU için: (1) ilgili kod satırı, (2) neden risk, (3)tahmini ciddiyet (Kritik/Yüksek/Orta/Düşük), (4) çözüm önerisi.Bunlar DOĞRULANACAK HİPOTEZLERDİR; "güvenli" hükmü verme.Emin olmadığın yeri açıkça "denetçi teyit etsin" diye işaretle.
Dört kopyalanabilir şablon
1) Kategori temelli tarama:
Bu sözleşmeyi şu kategoriler için tara: reentrancy, erişimkontrolü, tamsayı taşması, girdi doğrulama, oracle bağımlılığı,front-running, DoS/gas. Her kategori için "risk var/yok/emindeğilim" de ve gerekçeni koddaki satıra bağla. Kesin hüküm verme.
2) Saldırgan gözüyle karşı-hipotez:
Bir saldırgan gibi düşün: bu fonksiyonu kötüye kullanmanınyolları neler olabilir? Her senaryoyu adım adım yaz ve hangikoşulların gerektiğini belirt. Bu senaryolar test edilecekhipotezlerdir; gerçek exploit kodu ÜRETME, yalnızca riski tarif et.
3) Bulgu raporu taslağı:
Şu doğrulanmış bulguyu resmi denetim dilinde raporla: başlık,ciddiyet, açıklama, etki, etkilenen kod, yeniden üretim adımları,çözüm önerisi. Ölçülü ve teknik dil kullan; abartma. Bulgunundenetçi tarafından teyit edildiğini varsay, yeni bulgu uydurma.
4) Düzeltme doğrulama:
Aşağıda bir zafiyet ve geliştiricinin uyguladığı düzeltme var.Düzeltmenin zafiyeti gerçekten kapatıp kapatmadığını incele;yeni bir yan etki veya açık yaratıp yaratmadığını işaretle.Kesin "kapandı" deme; "test ile teyit edilmeli" ile bitir.
Üç mini vaka (sayılarla)
Vaka 1 — YZ kategori atlatmayı önledi. Bir denetçi, 400 satırlık bir sözleşmede yoğunlaşıp oracle kategorisini atlamak üzereydi. YZ'nin kategori taraması "fiyat verisi tek kaynaktan, manipülasyona açık" uyarısı verdi. Denetçi inceledi, gerçekten orta düzey bir risk buldu. Ders: YZ kapsama disiplinini korur.
Vaka 2 — Yanlış "güvenli" güvencesi. Başka bir ekip YZ'ye "bu güvenli mi?" diye sordu; YZ "önemli bir sorun görünmüyor" dedi. Ekip denetimi hafif geçti. Sonra bağımsız denetçi bir iş-mantığı hatası buldu: teknik olarak doğru ama teşvikleri sömürülebilir bir hesaplama. Ders: YZ iş mantığı hatasını kaçırır; "güvenli" demesine güvenilmez.
Vaka 3 — Rapor taslağı 3 saat kazandırdı. Denetçi 8 bulguyu elle raporlarken günün yarısını harcıyordu. Doğrulanmış bulguları YZ'ye verip resmi taslak yazdırınca süre ~3 saat düştü; denetçi zamanı derinleşmeye ayırdı. Ders: YZ raporlamada güvenli ve verimli, çünkü bulgular zaten insanca doğrulanmış.
İş mantığı zafiyeti: YZ'nin kör noktası
En pahalı zafiyetler çoğu zaman kodun teknik hatasından değil, iş mantığının sömürülebilirliğinden gelir: bir ödül hesabının yuvarlama ile istismarı, bir oylamanın flash loan (tek işlemde alınıp iade edilen ani kredi) ile ele geçirilmesi, bir fiyatın anlık manipülasyonu. Bunlar kodun "doğru" çalıştığı, ama protokolün ekonomik olarak kandırılabildiği durumlardır. YZ bu tür hataları -özellikle protokole özgü olanları- büyük olasılıkla kaçırır. Bu yüzden iş mantığı incelemesi, denetçinin en insan-yoğun ve YZ'ye en az güvenilecek alanıdır.
İpucu: YZ'ye "bu protokolün ekonomik teşvikleri nasıl sömürülebilir?" diye sorun ve gelen senaryoları başlangıç noktası olarak kullanın — ama gerçek analizi kendi ve ekibinizin yapması gerektiğini unutmayın.
Sık yapılan hatalar
- YZ'ye "güvenli mi?" diye sorup evetine güvenmek. Mutlak hüküm istenmez.
- YZ "bulamadım" deyince incelemeyi bırakmak. Yokluk kanıt değildir.
- İş mantığı incelemesini YZ'ye devretmek. En büyük kör noktasıdır.
- Bağımsız araç (Slither vb.) kullanmamak. YZ tek başına yeterli değildir.
- YZ'nin uydurduğu bulguyu doğrulamadan rapora koymak. Halüsinasyon riski.
- Denetim sorumluluğunu YZ'ye yüklemeye çalışmak. Sorumluluk uzmandadır.
Özetle
- Denetim güvenlik-kritiktir; YZ denetçinin kapsamını genişletir ama yerine geçmez.
- YZ özgün zafiyeti ve iş mantığı hatasını kaçırır; "güvenli" demesi güvence değildir.
- Bulgular ciddiyet düzeyine göre sınıflanır; YZ taslak üretmede işe yarar.
- Karşı-hipotez ve kategori taraması, kapsama disiplinini korur.
- Son onay ve mesleki sorumluluk daima yetkin denetçidedir.
Uygulama görevi
Bilinen bir zafiyet içeren bir örnek sözleşme bulun (eğitim amaçlı "zafiyetli sözleşme" örnekleri açık kaynakta vardır). YZ'ye "kategori temelli tarama" promptunu uygulayın. YZ'nin: (1) gerçek zafiyeti bulup bulmadığını, (2) uydurma/yanlış bulgu üretip üretmediğini, (3) "güvenli" gibi mutlak hüküm verip vermediğini not edin. Ardından bir statik analiz aracıyla karşılaştırın.
Kontrol listesi
- [ ] YZ'ye "güvenli mi?" yerine kategori temelli tarama yaptırdım.
- [ ] Her bulguyu hipotez olarak ele aldım.
- [ ] İş mantığı incelemesini kendim/ekip yaptım.
- [ ] Bağımsız statik analiz aracıyla çapraz doğruladım.
- [ ] YZ'nin uydurma bulgu üretmediğini teyit ettim.
- [ ] Bulguları ciddiyet düzeyine göre sınıfladım.
- [ ] Son onayın yetkin denetçide olduğunu kabul ettim.