Smart Contract Audits: What Auditors Check—and What an Audit Does Not Guarantee

Akıllı sözleşme denetimi, tanımlanmış bir kapsamda kodun ve mimarinin bağımsız olarak incelenmesidir. Amacı; güvenlik açıklarını, uygulama hatalarını ve amaçlanan davranışla gerçek davranış arasındaki uyumsuzlukları belirlemektir.

Denetim belirsizliği azaltabilir, ancak sözleşmeyi risksiz hâle getirmez. Ethereum’un resmî güvenlik rehberi denetimleri, her hatayı yakalayan kusursuz bir çözüm değil, ek bir inceleme olarak tanımlar.

Bu makale yalnızca eğitim amaçlıdır. Denetim; güvenliği, fonların geri alınmasını veya getiriyi garanti etmez.

Önce kapsam gelir

Yararlı bir rapor tam olarak nelerin incelendiğini belirtir:

• depo ve commit hash'i;
• dosyalar ve sözleşmeler;
• derleyici sürümü ve derleme ayarları;
• bağımlılıklar;
• mimari ve ayrıcalıklı roller;
• dal veya sürüm;
• kapsam dışı bırakılanlar, sınırlamalar ve varsayımlar;
• inceleme tarihi.

Bu önemlidir; çünkü gerçek bir denetim eski bir sürümü, farklı bir dağıtımı veya daha büyük bir sistemin yalnızca bir bölümünü kapsayabilir.

Denetçiler genellikle neleri inceler?

1. Amaçlanan davranış ve değişmezler

Denetçiler kodu teknik özellikleriyle karşılaştırır:

• her işlevi kimin çağırabildiği;
• tutarların ve ücretlerin nasıl hesaplandığı;
• statü değişikliklerinin ne zaman gerçekleştiği;
• hangi özelliklerin her zaman doğru kalması gerektiği;
• uç durumların ve hataların nasıl ele alındığı.

Teknik şartname önemli bir gereksinimi atlıyorsa teknik olarak doğru kod bile güvensiz veya istenmeyen bir tasarımı uygulayabilir.

2. Erişim kontrolü

İnceleyiciler owner, admin, operatör ve diğer ayrıcalıklı rolleri, aşağıdaki yetkiler dâhil olmak üzere inceler:

• izin vermek veya izinleri iptal etmek;
• sistemi duraklatmak;
• ücretleri ve limitleri değiştirmek;
• token basmak;
• varlıkları çekmek;
• uygulamayı yükseltmek.

Ayrıca tek bir anahtarın kritik değişiklik yapıp yapamadığını ve çoklu imza veya zaman kilidi gibi kontrollerin tasarımın parçası olup olmadığını değerlendirirler.

3. Haricî çağrılar ve yeniden giriş

Bir sözleşme yürütme sırasında kontrolü başka bir sözleşmeye devredebilir. Bu durum, ilk durum geçişi tamamlanmadan haricî sözleşmenin geri çağrı yaptığı yeniden girişe yol açabilir. Solidity’nin resmî rehberi, uygun durumlarda kontrollerin, durum değişikliklerinin ve haricî etkileşimlerin dikkatle sıralanmasını önerir.

4. Hesaplamalar ve birimler

Denetçiler şunları arar:

• yuvarlama ve hassasiyet kaybı;
• uyuşmayan token ondalık basamakları;
• yanlış işlem sırası;
• sınır değerleri;
• sıfıra bölme;
• unsafe unchecked arithmetic;
• iç birimler ile gösterilen birimler arasındaki tutarsızlıklar.

5. Hizmet engelleme ve gas

Sınırsız döngüler, büyüyen diziler, başarısız haricî çağrılar veya pahalı işlemler bir işlevin çalıştırılmasını kullanışsız hâle getirebilir. İnceleyiciler, veri büyüdüğünde ve olağandışı girdiler altında tasarımın kullanılabilir kalıp kalmadığını test eder.

6. Proxy’ler ve yükseltmeler

Yükseltilebilir sistemlerde inceleme şunları kapsamalıdır:

• proxy ve uygulama sözleşmeleri;
• yükseltici veya admin yetkileri;
• başlatma;
• depolama düzeni uyumluluğu;
• yetkisiz yükseltme yolları;
• denetimden sonra mantığın değiştirilmesinin etkisi.

Bir proxy, çağrıları yeni mantığa devrederken kullanıcıya görünen adresi aynı tutabilir. Bu nedenle “sözleşme değişemez” iddiası gerçek mimariye göre kontrol edilmelidir.

7. Entegrasyonlar

Sözleşmeler tokenlere, fiyat oracle’larına, köprülere, DEX’lere, imzalara veya diğer sözleşmelere bağlı olabilir. Denetçiler bu bağımlılıklarla ilgili varsayımları, güncelliğini yitirmiş verileri, olağandışı token davranışlarını ve haricî hata senaryolarını inceler.

8. Olaylar ve izleme

İnceleyiciler olayların rol değişiklikleri, yükseltmeler, duraklatmalar ve transferler gibi önemli işlemleri doğru biçimde gösterip göstermediğini kontrol edebilir. Olaylar izlemeyi destekler ancak durum incelemesinin yerini almaz.

Denetimde kullanılan yöntemler

Bir inceleme genellikle şunları bir araya getirir:

• manuel kod ve mimari analizi;
• birim ve entegrasyon testleri;
• statik ve dinamik analiz;
• oluşturulan girdilerle fuzz testi;
• özellik tabanlı test;
• bilinen güvenlik açığı sınıflarına yönelik kontroller;
• derleme ve dağıtım incelemesi;
• bazı durumlarda seçilen özelliklerin biçimsel doğrulaması.

Tek bir yöntem her şeyi kapsamaz. Biçimsel doğrulama, kodun biçimsel şartnameyi karşıladığını kanıtlayabilir; şartnamede belirtilmeyen bir özelliği kanıtlayamaz.

Bir kullanıcı denetim raporunu nasıl okumalıdır?

1. İncelenen sürümle eşleştirin

Commit hash'ini bulun ve şunları belirleyin:

• güncel uygulamanın bu koddan derlenip derlenmediği;
• rapor tarihinden sonra yükseltme yapılıp yapılmadığı;
• zincirin ve dağıtılmış adreslerin eşleşip eşleşmediği;
• kritik bağımlılıkların kapsamda olup olmadığı.

Bu doğrulanamıyorsa rapor, canlı dağıtım hakkında sınırlı kanıt sunar.

2. Yalnızca özeti değil, bulguları da okuyun

Her bulgu için şunları inceleyin:

• önem derecesi ve senaryo;
• etkilenen kod;
• öneri;
• geliştirici yanıtı;
• güncel durum;
• denetçinin düzeltmeyi yeniden test edip etmediği.

Sabitlendi veya Karar verildi is meaningful only when tied to a specific corrected version.

3. Sınırlamaları okuyun

Raporlar şunları kapsam dışında bırakabilir:

• ön uç ve arka uç sistemleri;
• anahtar yönetimi;
• ekonomik tasarım;
• üçüncü taraf sözleşmeleri;
• dağıtım altyapısı;
• üretim yapılandırması;
• hukuki ve operasyonel sorunlar.

Kullanıcılar yalnızca Solidity dosyalarıyla değil, sistemin tamamıyla etkileşim kurar.

4. İdari riski inceleyin

Şunları sorun:

• yükseltmeleri kimin kontrol ettiği;
• işlemlerin duraklatılıp duraklatılamayacağı;
• ücretlerin veya bağlantılı adreslerin değişip değişemeyeceği;
• zaman kilidinin bulunup bulunmadığı;
• çoklu imzanın kullanılıp kullanılmadığı;
• kullanıcıların değişiklikleri nasıl öğrendiği.

Kodda keşfedilmiş bir güvenlik açığı olmasa bile bunlar yönetişim ve güven sorularıdır.

5. Denetim sonrasındaki güvenliği kontrol edin

Yararlı sürekli önlemler şunlardır:

• her sürümü test etmek;
• önemli yükseltmeleri incelemek;
• güvenlik açığı ödül programı;
• rolleri ve uygulamaları izlemek;
• olay müdahale prosedürleri;
• maruz kalan varlık miktarını sınırlamak.

Bir denetimin garanti etmediği hususlar

Denetim şunları garanti etmez:

• hiçbir hatanın bulunmadığını;
• incelemeden sonra değiştirilen kodun güvenliği;
• web sitesinin, cüzdanın, DNS'in veya sunucuların güvenliği;
• ayrıcalıklı anahtarların güvenliği;
• haricî tokenlerin, oracle'ların ve köprülerin doğruluğu;
• her ekonomik saldırıya karşı dayanıklılık;
• ekibin dürüstlüğü;
• hukuki uyumluluk;
• token likiditesi;
• fonların geri alınması;
• sabit veya başka herhangi bir getiri.

Dikkatli bir kullanıcının sorması gereken sorular

Is an auditor’s logo enough?
No. Find the report from the auditor’s own source and check its scope, commit, date, and findings.

If every finding was fixed, is the contract safe?
It means the listed findings were addressed in a stated version. Unknown issues and out-of-scope risks remain.

Are several audits automatically better?
The count alone says little. Coverage, quality, independence, recency, and version matching matter more.

Does an audit still apply after a proxy upgrade?
Only if the new implementation and configuration are covered by the reviewed version.

Rapor kontrol listesi

• Rapor denetçinin kaynağında mevcuttur.
• Depo ve commit hash'i belirtilmiştir.
• Kritik sözleşmeler ve bağımlılıklar kapsam dâhilindedir.
• İncelenen sürüm canlı dağıtımla eşleşir.
• Proxy, uygulama ve admin kapsam dâhilindedir.
• Bulguların durumu ve yeniden test süreci belgelenmiştir.
• Varsayımlar ve kapsam dışı bırakılan hususlar okundu.
• Kod dışındaki riskler ayrıca değerlendirilmiştir.

Kaynaklar ve İleri Okuma

1. Ethereum.org — Akıllı Sözleşme Güvenliği
2. Ethereum.org — Akıllı Sözleşmelerin Test Edilmesi
3. Ethereum.org — Akıllı Sözleşmelerin Biçimsel Doğrulanması
4. Solidity Documentation — Güvenlik Değerlendirmeleri
5. OpenZeppelin Docs — Proxy Yükseltme Modeli