Olaylardan Düzenlemeye: Kripto Kurumlarının Blockchain Sızma Testine Neden İhtiyacı Var

PRODUCT İSİMLERİ — diğer tüm talimatlardan önceliklidir, katı bir kısıtlamadır: Bu isimleri İngilizce olarak, harfi harfine aynen koruyun. Bunların herhangi bir bölümünü asla çevirmeyin, harf çevirisi yapmayın, yerelleştirmeyin, tire ile ayırmayın veya başka şekilde yeniden yazmayın: BlockSec, Phalcon Compliance, Phalcon Security, Phalcon Explorer, Phalcon Network, MetaSleuth, MetaSuites.

Kripto kurumları ve hizmet sağlayıcıları için—kripto para borsaları, ödeme şirketleri, dijital varlık saklama kuruluşları ve custodial ile non-custodial cüzdan sağlayıcıları dahil—blockchain penetration testing, kapsam dahilinde olanlar için isteğe bağlı bir önlem değildir. Bir ihlalin imzalama veya fonlara erişebildiği veya geçerli düzenlemelerin çelişmeli (adversarial) doğrulama gerektirdiği durumlarda, bu güvence için gerekli bir katmandır. Bu gerekçe iki temele dayanır: sözleşme kodunun ötesindeki risk kaynağı ve çelişmeli doğrulama için düzenleyici gereklilikler veya beklentiler.

Kurumsal maruziyet, sözleşme hatalarının ötesine geçerek imzalama, saklama, anahtarlar, insanlar, tedarik zincirleri ve altyapıya kadar uzanır [1]. Bu nedenle bu yüzey, tanıdık web3 güvenlik çözümleri—kod düzeyinde denetim ve işlem düzeyinde izleme—veya yalnızca geleneksel penetration testing ile tam olarak kapsanmaz. Bu durum, bir kişinin, satıcının, arayüzün veya uygulamanın neyin imzalanacağını, onaylanacağını, kredilendirileceğini veya taşınacağını etkileyebildiği—saklamanın dış kaynaklı olduğu durumlar dahil—herhangi bir kurum için geçerlidir. Aynı zamanda, birçok pazardaki düzenleyiciler, farklı kapsamlara, sıklıklara ve bağımsızlık kurallarına sahip gereklilikler, şarta bağlı yükümlülükler veya denetim beklentileri getirmektedir.

Bu makale, blockchain penetration testing serimizi açmaktadır. Seri boyunca, blockchain penetration testing ve web3 penetration testing aynı disipline atıfta bulunur: birincisini ana terim olarak, ikincisini ise yaygın sektör eş anlamlısı olarak kullanıyoruz. Bu makale, gerekliliğe ilişkin üst düzey, bütünsel gerekçeyi sunar; sonraki makaleler disiplini, işletim sınırlarını ve kurumsal saldırı yüzeyini ayrıntılı olarak tanımlayacaktır.

Bölüm 1: Risk nereden kaynaklanıyor

1.1 Akıllı sözleşmenin ötesindeki risk

Akıllı sözleşme güvenlik açıkları önemini korumaktadır, ancak son dönemin en büyük kayıplarının çoğu başka bir yerden, özellikle anahtarlardan, imzalama sistemlerinden ve operasyonel altyapıdan kaynaklanmıştır. 2024 yılında saldırganlar, bir cüzdan yazılımı sağlayıcısını ele geçirip meşru bir işlem talebini manipüle ederek DMM Bitcoin'den yaklaşık 305 milyon dolar çaldı [2]. 2025'te Bybit, bir tedarik zinciri ihlalinin imzalama arayüzünü manipüle etmesi sonucu yaklaşık 1,5 milyar dolar kaybetti [3], BtcTurk'ün sıcak cüzdan kaybı da benzer şekilde ele geçirilmiş özel anahtarlara dayandı [4]. Araştırmamız da aynı yönü işaret ediyor: 2026'da takip ettiğimiz, 100.000 dolardan büyük kayıplar içeren olaylar arasında, sözleşme dışı başarısızlıklar olayların sekizde biri kadar iken toplam kayıpların dörtte üçünden fazlasını oluşturdu. Ağustos 2026 itibarıyla, rekt.news'in kamuya açık liderlik tablosundaki en büyük on hack'ten (dolandırıcılık ve diğer hack dışı girişler hariç) yedisi sözleşme dışı ihlallerdi ve bu, hem olay sayısı hem de dolar değeri bakımından yaklaşık %70'e karşılık geliyordu [5].

Cüzdanlar ve saklama sistemleri bu örüntüyü somutlaştırıyor ve cüzdan güvenliği son yıllarda özellikle olayların yoğun olduğu bir alan olarak kalmaya devam ediyor. Araştırmamız başarısızlıkları anahtar yönetimi, işlem imzalama hattı, tedarik zinciri ve bağımlılıklar, hassas veri ifşası ve kriptografik uygulama olarak gruplandırıyor.

* Coldcard'ın ~90M$ değeri doğrulanmış zincir üstü tabandır (yaklaşık 1.405 BTC); özel tahminler ~130M$'a kadar çıkmaktadır.

Bunları penetration testing ile bağlayan şey, basitçe sözleşmenin dışında kalmaları değil, sömürülüp sömürülemeyeceklerinin sıklıkla, dağıtılmış parçaların—kimlikler, bağımlılıklar, imzalama kontrolleri, onaylar ve fon mantığı—bir saldırganın bir giriş noktasından fonlara kadar baştan sona yürüyebileceği bir yola nasıl dizildiğine bağlı olmasıdır.

1.2 Kod düzeyinde denetim ve işlem düzeyinde izleme: gerekli ama sınırlı

Mevcut, iyi bilinen web3 güvenlik çözümlerinin her biri belirli bir düzeyde çalışır. Kod düzeyinde denetim (kod denetimi) kodu—sözleşme, cüzdan veya hizmet mantığını—inceler. İşlem düzeyinde izleme (izleme) işlemleri zincire ulaştıkları anda inceler; örneğin Phalcon [11], kötü amaçlı etkinliği çalışma zamanında tespit eder, uyarır ve engeller.

Bu çözümler yararlıdır, ancak kripto kurumlarının para elleçleme zinciri—değerin bir giriş noktasından bir fon taşıma eylemine kadar aktığı bağlı kimlikler, bulut altyapısı, imzalama iş akışları, onay zincirleri, cüzdanlar, satıcılar ve operatör konsolları—söz konusu olduğunda sınırlıdır. Bir saldırganın erişebileceği yol, bu zincir boyunca bir rotadır: bir web, dApp, mobil, API, bulut veya kimlik giriş noktasından imzalama, onay ve fon mantığına kadar uzanabilir, bir sözleşmenin o canlı bağlamda nasıl davrandığından geçebilir ve diğer uçtaki fon taşıma eylemine ulaşabilir. Kodu incelemek bu yolu bir araya getirmez ve işlemleri izlemek bunu önceden tahmin etmez. Birlikte kullanılsalar bile, ikisi bir birleşim (kompozisyon) açığı bırakabilir: bir denetim, kodun yazıldığı şekliyle sağlam olduğunu gösterir, dağıtılmış kimliklerin, onayların ve imzalayanların bunu hâlâ uyguladığını göstermez; izleme ise teknik olarak geçerli olan ama operatörün asla amaçlamadığı bir transferi geçirebilir. Bu açığı kapatan şey, kontrollerin çalışan sistemde doğru şekilde bir araya geldiğine dair bağımsız, çelişmeli (adversarial) doğrulamadır.

Blockchain penetration testing, birleşmiş, çalışan sistemi test ederek bir olayın onu ortaya çıkarmasından önce böyle bir yolun fonlara ulaşıp ulaşamayacağını keşfetmek ve göstermek için işletilir. Bybit örüntüsü sorunun şeklini gösteriyor: ele geçirilmiş bir imzalama arayüzü, operatörlerin kendi onayını hiç amaçlamadıkları bir transfere çevirdi—sözleşmenin kendisi, onun denetimi ve işlem izleme her biri bunu meşru olarak okuyabilirdi. Blockchain penetration testing bu birleşimi doğrudan hedefler: ele geçirilmiş bir satıcı, operatör veya arayüzün konumunu alarak, böyle bir dayanak noktasının geçerli görünen bir onayı yetkisiz bir fon hareketine çevirip çeviremeyeceğini ve dağıtılmış kontrollerden—kimlikler, onay adımları, imzalama kontrolleri—hangilerinin bunu gerçekten durdurduğunu test eder. Sözleşme kod düzeyi güvence denetimin işi olarak kalır; blockchain penetration testing, dağıtılmış bir sözleşmeyle yalnızca canlı davranışı üzerinden, bu davranış kurum düzeyinde fonlara giden bir rotanın parçası olduğunda etkileşime girer—bu, keskin bir sınır değil, vurguyla ayrılan tamamlayıcı kapsamlardır. Bölüm 2 blockchain penetration testing'in ne doğruladığını ve kapsamının nerede bittiğini tanımlar.

1.3 Geleneksel penetration testing: yararlı ama yeterli değil

Geleneksel penetration testing, bulut, web ve API, kimlik ve ayrıcalıklı erişim yüzeylerinde değerli olmayı sürdürüyor. Sınırlaması kapsam ve alan bağlamıdır: geleneksel bir çalışma, kriptonun iş anlambilimini veya birleşik güvenlik ve uyumluluk modelini getirmeyebilir.

Kriptoda bir imza, geri döndürülemez değer hareketini yetkilendirebilir; para çekme onayı, sadece bir form gönderimi değil, bir fon kontrolü kararıdır. Yatırma kredilendirme, bakiye muhasebesi ve iç transferler para mantığıdır. Adresler ve işlemler ayrıca yaptırım veya fon kaynağı anlamı da taşıyabilir. Bir test uzmanı bir kimlik doğrulama atlatmasını bulabilir ancak bunun bir imzalama görüntüsü uyumsuzluğu, zayıf onay politikası veya yuvarlama hatasıyla nasıl birleşerek fonlara giden bir yol oluşturduğunu gözden kaçırabilir.

Blockchain penetration testing, yerleşik çelişmeli teknikleri geleneksel yüzeylere ve ayrıca çalışan sistem genelindeki web3'e özgü imzalama, onay, fon mantığı ve sözleşme-dinamiği yüzeylerine uygular. Farkı yeni araçlar değil, uzman web3 güvenlik yargısıdır: test uzmanları saklama, işlem niyeti, fon akışları ve uyumluluk kontrollerini bir saldırganın yapacağı gibi yorumlar. Fark, hedefe ilişkindir: geleneksel bir test tipik olarak BT-kontrol etkisini kanıtlar—ele geçirilmiş bir yönetici oturumu, erişilmiş bir sunucu—blockchain testi ise değerin hareketini son koşul olarak ele alır. Devam eder: geçerli bir imzalama talebi içindeki alıcıyı veya tutarı değiştirir ve onaylayanın gördüğü şeyin, onay politikasının ve gerçekte hareket eden fonların hâlâ birbiriyle uyumlu olup olmadığını kontrol eder.

Özetle, bu tamamlayıcı bir güvence olup statik-dinamik ayrımı değildir. Kod düzeyinde denetimler, işlem düzeyinde izleme ve geleneksel penetration testleri gerekli olmayı sürdürür. Blockchain penetration testing, erişilebilir yolları doğrulayarak bunları birbirine bağlar; bunların yerini almaz, ihlal keşfini garanti etmez veya önlemeyi garanti etmez.

Bölüm 2: Düzenleyicilerin gerektirdiği şeyler

Gereklilikler yargı bölgesine göre değişir ve belirli kuruluşlar ve sistemler için lisanslama, süregelen ve düzenleyici tetiklemeli yükümlülüklerin bir spektrumunu oluşturur.

Bu örnekler açıklayıcı niteliktedir, hukuki tavsiye değildir. Kurumlar durumlarını, muafiyetlerini, sistemlerini ve yükümlülüklerini avukatlarıyla teyit etmelidir.

• Amerika Birleşik Devletleri, New York: sınırlı muafiyetle açık gereklilik. NYDFS 23 NYCRR Part 500 [12] kapsamındaki kapsanan kuruluşlar—DFS lisanslı sanal para birimi işletmeleri dahil—risk değerlendirmesine dayalı olarak en az yıllık bir defa, bilgi sistemlerini iç ve dış sınırlardan test etmelidir. Yetkili bir iç veya dış taraf test yapabilir. Nitelikli küçük kuruluşlar bu test hükmünden sınırlı bir muafiyet alır, ancak Part 500'ün diğer geçerli hükümlerine tabi kalmaya devam eder.

• Dubai: yıllık ve değişim tetiklemeli gereklilik. Lisanslı VASP'ler, nitelikli, bağımsız bir üçüncü taraf kullanarak en az yıllık bir defa ve yeni sistemler, uygulamalar veya ürünler tanıtmadan önce güvenlik açığı değerlendirmesi ve penetration testing yapmalıdır [13]. Akıllı sözleşme denetimi, VASP'nin iş ve faaliyetleriyle ilgili olduğu durumlarda uygulanır. Tehdit odaklı penetration testing evrensel bir sıklığa sahip değildir: VARA, risk temelinde gerekli ve orantılı olduğunda bunu talep edebilir.

• Hong Kong: sayılan başvuru sahipleri için lisans koşulu gerekliliği. Lisanslı sayılan sanal varlık ticaret platformu başvuru sahipleri, kısıtlı işletim öncesinde tatmin edici sonuçlarla penetration testing ve güvenlik açığı değerlendirmesini tamamlamalıdır [14]. Yeni şirket başvuru sahipleri için ayrı bir kılavuz uygulanır. Bağımsız bir üçüncü taraf, uygulama ve ağ katmanları genelinde belirtilen altyapı ve uygulamaları kapsamalıdır. Kısıtlı işletim öncesinde, yönetim orta-yüksek riskli bulgular için tüm büyük ve kritik düzeltme adımlarını tamamlamalıdır.

• Avrupa Birliği: orantılı çerçeve; TLPT tanımlanmaya bağlıdır. DORA, kripto varlık hizmet sağlayıcıları dahil finansal kuruluşları kapsar [15]. Kritik veya önemli işlevleri destekleyen sistemler için en az yıllık bir defa uygun testi—özel olarak penetration testing'i değil—gerektirir. Penetration testing, riske ve orantılılığa göre seçilen bir yöntemdir. Tehdit odaklı penetration testing yalnızca yetkili makamlar tarafından tanımlanan kuruluşlara uygulanır, canlı üretim sistemlerinde yürütülür ve genellikle en az üç yılda bir gereklidir; makamlar risk temelinde bu sıklığı ayarlayabilir. DORA ayrıca test uzmanı bağımsızlığı koşulları getirir. Mikroişletmeler test programı gerekliliğinin dışındadır.

• Singapur: bağlayıcı olmayan denetim beklentisi. MAS Teknoloji Riski Yönetim Yönergeleri, finansal kuruluşların penetration testing yapması gerektiğini ve internete açık sistemlerin en az yıllık bir defa veya büyük değişiklikler ya da güncellemelerden sonra test edilmesinin beklendiğini belirtir [16]. Bu, bağlayıcı olmayan bir denetim yönergesidir ve bağımsız bir üçüncü taraf gerektirmez. Bağlayıcı, banka kapsamlı Siber Hijyen Bildirimi penetration testing'i belirtmez. Bağlayıcı ödeme veya dijital ödeme jetonu bildirimi bu makalenin kapsamı dışındadır.

Bir bütün olarak ele alındığında, bu rejimler markalı bir "web3" kategorisi değil, penetration testing gerektirir veya bekler. Web3 uzman versiyonu, kapsamdaki sistemlerden kaynaklanır: bunlar kripto değerini yetkilendirdiği, imzaladığı, sakladığı veya hesapladığı durumlarda, bunları doğru şekilde test etmek Bölüm 1'de açıklanan aynı imzalama ve fon akışı akıcılığını gerektirir.

Sonuç kesindir: belirli yargı bölgelerindeki önemli bir grup lisanslı kuruluş, halihazırda bir gereklilik veya denetim beklentisiyle karşı karşıyadır—her pazarda aynı yükümlülük değildir. Farklar, kapsamı, sıklığı, test uzmanı bağımsızlığını, düzeltmeyi, kanıtları ve testin lisanslamayı, süregelen uyumluluğu veya düzenleyici tetiklemeli bir uygulamayı destekleyip desteklemediğini belirler.

Sonuç: İki temel birleşiyor

Risk kaynağı ve düzenleyici gereklilikler veya beklentiler aynı sonuca işaret ediyor: kapsam dahilindeki kurumlar için blockchain penetration testing gerekli bir güvence katmanıdır. Mevcut kontrolleri tamamlarken erişim, onay, imzalama ve fonlar boyunca erişilebilir yolları doğrular. Önlemeyi garanti edemez, geçmişte belirli bir olayı durdurmuş olacağını kanıtlayamaz veya sömürülebilecek her yolu bulamaz. Hedef, tek seferlik bir rapor değil, lansman, işletim, tespit, yanıt ve düzenleyici kanıt boyunca süregelen bir güvencedir.

Seriye devam edin:

• Bölüm 2: Blockchain Penetration Testing Nedir? Tanımlar ve Sınırlar

• Bölüm 3: Kurumsal Blockchain Penetration Testing için Katılım Kuralları ve Üretim Güvenliği

• Bölüm 4: Web3 Saldırı Yüzeyleri: Bir Penetration Testing Genel Bakışı

Ayrıca bu seride, yakında yayınlanacak:

• Bölüm 5: Yetkilendirme ve İmzalama Güvenliği: Web, dApp'ler ve Mobil
• Bölüm 6: Bulut ve CI/CD Güvenliği: Otomatik Operasyon Saldırı Yüzeyleri
• Bölüm 7: Hazine Kontrol Düzlemi Güvenliği: İmzalama ve Para Çekme Onayları
• Bölüm 8: Borsa Defteri Güvenliği: Hırsızlık Yolları ve Veri Düzlemi Mantığı

BlockSec, kurumların bu katmanı hassas bir şekilde konumlandırmasına yardımcı olur: varlıkları, fon akışlarını, güven sınırlarını ve mevcut güvenceyi haritalayın; avukatların geçerli olduğunu söylediği yükümlülükleri teyit edin; ardından test hedefini, kapsamını, erişimi, üretim önlemlerini, düzeltme kanıtını ve yeniden test planını tanımlayın. Güvence açığınızı belirlemek için blockchain penetration testing ekibimizle konuşun; katılım kapsamı ve fiyatlandırma talep üzerine mevcuttur. Fonların hareket ettiği yerden başlayın.

Kaynaklar

İlk görünme sırasına göre numaralandırılmıştır.

1. BlockSec, Kripto Ödeme Güvenliği Rehberi.
2. ABD Federal Soruşturma Bürosu, DC3 ve Japonya Ulusal Polis Teşkilatı, Bitcoin.DMM.com'dan 308 Milyon Dolar Çalınmasından Sorumlu Kuzey Koreli Siber Aktörlerin Kimliklerinin Belirlenmesi (TraderTraitor) (Aralık 2024).
3. BlockSec, Bybit 1,5 Milyar Dolarlık Hack: Kötü Amaçlı Safe{Wallet} Yükseltme Saldırısının Derinlemesine Analizi.
4. rekt.news, BtcTurk — Rekt.
5. rekt.news, Liderlik Tablosu.
6. SwissBorg, SwissBorg Güvenlik Güncellemesi: Kiln İhlali.
7. BlockSec, TrustWallet Olayı: Çalınan Bir API Anahtarı Resmi Güncelleme Kanalını Bir Arka Kapıya Dönüştürüyor.
8. Slope, Slope Wallet Sentry Güvenlik Açığı: Dijital Adli Bilişim ve Olay Müdahale Raporu.
9. BlockSec, Profanity Aracı Güvenlik Açığına Kısa Analizimiz.
10. BlockSec, Coldcard Entropi Hatası ve Tohum Kurtarma.
11. BlockSec, Phalcon Security.
12. New York Eyalet Finansal Hizmetler Departmanı, 23 NYCRR Part 500 — Finansal Hizmet Şirketleri için Siber Güvenlik Gereklilikleri.
13. Dubai Sanal Varlıklar Düzenleme Kurumu, Teknoloji ve Bilgi Kural Kitabı, Bölüm I, Kısım E.
14. Hong Kong Menkul Kıymetler ve Vadeli İşlemler Komisyonu, Genelge 24EC65 (18 Aralık 2024, PDF).
15. Avrupa Birliği, Tüzük (AB) 2022/2554 — Dijital Operasyonel Dayanıklılık Yasası (DORA), Madde 24–27.
16. Singapur Para Otoritesi, Teknoloji Riski Yönetim Yönergeleri (Ocak 2021), Bölüm 2 ve 13; Bildirim FSM-N06: Siber Hijyen Bildirimi (2024).