Bug Bounty Programı Türkiye’de Yasal mı? Yetki Sınırı ve TCK 243-244 | 2026

Bug bounty, bir kurumun kendi internet sitesi, mobil uygulaması, API’si veya diğer bilişim varlıklarındaki güvenlik açıklarını yetkili araştırmacıların bulmasına izin verdiği ve geçerli bulgular için ödül ya da takdir sunduğu güvenlik modelidir. Teknik dünyada “responsible disclosure” ve “vulnerability disclosure program” kavramlarıyla birlikte kullanılır. Hukuken belirleyici olan programın adı değil, sistem sahibinin hangi varlıklara hangi yöntemlerle erişim izni verdiğidir.

Türkiye’de bug bounty için özel isimli tek bir kanun bulunmaz. Fiilin ceza hukuku bakımından değerlendirilmesinde 5237 sayılı Türk Ceza Kanunu’nun bilişim suçlarına ilişkin hükümleri; taraflar arasındaki program ve ödül ilişkisi bakımından ise 6098 sayılı Türk Borçlar Kanunu esas alınır. Program sırasında kişisel veriyle karşılaşılması hâlinde 6698 sayılı Kişisel Verilerin Korunması Kanunu da devreye girer. Bu nedenle güvenlik araştırmacısı ile sistem sahibi arasındaki ilişkinin teknik kapsamı ve hukuki kapsamı aynı metinde netleştirilmelidir.

• Bug bounty programının hukuki niteliği
• TCK m.243 ve hukuka aykırı erişim
• Yetki belgesi neden kritik?
• Scope sınırı nasıl yazılır?
• Out-of-scope varlığa erişim
• TCK m.244 ve veriye müdahale
• DoS ve performans testleri
• Gerçek kullanıcı verisiyle karşılaşılması
• Kanıt için veri indirme sınırı
• Güvenlik araçları ve TCK m.245/A
• Ödül hakkı ve program şartları
• Gizlilik ve açıklama yasağı
• Alt alan adı, API ve üçüncü taraf servisler
• Çalışan ve yüklenicilerin test yapması
• Safe harbor maddesi
• Olay kayıtları ve ispat
• Program hazırlama kontrol listesi

1. Bug Bounty Programının Hukuki Niteliği Nedir?

Bug bounty programı bir “hacker serbestisi” değildir. Sistem sahibinin belirli bilişim varlıkları bakımından belirli test yöntemlerine izin verdiği kontrollü bir yetkilendirme modelidir. Hukuki sonuç, program sayfasındaki “test yapabilirsiniz” cümlesinden değil; yetkinin hangi alan adı, IP, mobil uygulama, API, kullanıcı hesabı ve test yöntemini kapsadığının açık biçimde belirlenmesinden doğar.

TBK m.26 taraflara, kanunun emredici sınırları içinde sözleşmenin içeriğini serbestçe belirleme hakkı verir. Bir şirket; güvenlik araştırmacısına belirli sistemlerde test yapma izni, bildirim yöntemi, gizlilik süresi, ödül kriteri ve sorumluluk sınırlarını program şartlarıyla açıklayabilir. Araştırmacı bu şartlara uygun biçimde programa katıldığında taraflar arasında somut olayın niteliğine göre sözleşmesel bir ilişki kurulur.

Ceza hukuku yönünden ise asıl soru “ödül var mı?” değildir. Asıl soru, erişimin hukuka aykırı olup olmadığı ve sistem/veri üzerinde TCK m.244 kapsamındaki müdahalelerin gerçekleşip gerçekleşmediğidir. Bu nedenle ödülsüz vulnerability disclosure programı da açık yetki veriyorsa hukuki açıdan önemlidir; yüksek ödüllü bir program ise yetki sınırı belirsizse araştırmacıyı otomatik olarak korumaz.

2. TCK m.243 Bug Bounty Açısından Ne Düzenler?

TCK m.243/1, bir bilişim sisteminin bütününe veya bir kısmına hukuka aykırı olarak giren ve orada kalmaya devam eden kişiyi cezalandırır. Maddenin merkezindeki unsur “hukuka aykırılık”tır. Sistem sahibi veya erişim yetkisini vermeye hukuken yetkili kişi belirli bir test için açık izin vermişse, bu izin kapsamındaki erişim hukuka aykırı erişim olarak değerlendirilmez.

Ancak izin sınırsız değildir. “example.com üzerinde web güvenliği testi yapabilirsiniz” şeklindeki bir scope, şirketin bütün kurumsal ağına, çalışan e-posta hesaplarına, veri tabanı sunucularına, iştirak şirketlerine veya üçüncü taraf bulut hesaplarına kendiliğinden erişim yetkisi vermez. Yetkinin nesnesi ve sınırı program metninden anlaşılmalıdır.

TCK m.243/3, erişim fiili nedeniyle sistemdeki verilerin yok olması veya değişmesi hâlini ayrıca düzenler. Bu nedenle salt erişim izni verilmiş olması, veri değiştirme yetkisi de verildiği anlamına gelmez. Program sahibi test sırasında veri değişikliğine izin vermiyorsa, araştırmacı bulguyu ispatlamak için yalnız gerekli ve izin verilen yöntemi kullanmalıdır.

3. Yazılı Yetki Belgesi Neden Kritik Öneme Sahiptir?

Bug bounty programında yetki sözlü, kapalı veya sonradan varsayılan bir izin olarak bırakılmamalıdır. Yetki sayfasının yayın tarihi, kapsam sürümü ve değişiklik geçmişi saklanmalıdır. Araştırmacının belirli tarihte hangi kurallara göre test yaptığı daha sonra ispatlanabilmelidir.

Program kuralları en az şu unsurları göstermelidir: test edilebilir varlıklar, test edilemeyen varlıklar, izin verilen hesap türleri, otomasyon sınırı, yasak yöntemler, gerçek kullanıcı verisine yaklaşım, bildirim kanalı, rapor içinde sunulabilecek kanıt miktarı, kamuya açıklama kuralı ve ödül için gerekli asgari şartlar.

Kurumsal penetrasyon testinden farklı olarak bug bounty’de araştırmacılar çoğu zaman önceden tek tek isimlendirilmez. Bu nedenle halka açık program metni, kimlerin hangi koşulla yetki kazanacağını tanımlamalıdır. Örneğin “programa katılan ve şartları kabul eden herkes” ifadesi kullanılabilir; ancak yaptırım uygulanan ülkeler, şirket çalışanları veya belirli yaş grubundaki kişiler bakımından özel koşul konulacaksa bunlar da açıkça yazılmalıdır.

4. Scope Sınırı Nasıl Yazılmalıdır?

Scope, bug bounty programının teknik ve hukuki kalbidir. Alan adı yazmak tek başına yeterli değildir. Ana alan adı, alt alan adları, API uç noktaları, mobil uygulama paket kimliği, test ortamı, IP blokları ve üçüncü taraf barındırılan servisler ayrı ayrı sınıflandırılmalıdır.

“*.example.com” biçimindeki wildcard kapsam, şirketin kontrolünde olmayan veya üçüncü taraf hizmet sağlayıcıya ait bir alt alan adını yanlışlıkla kapsayabilir. Bu nedenle şirket varlık envanterini kontrol etmeli ve gerçekten yetki verebildiği sistemleri listelemelidir. Sistem sahibinin üçüncü kişiye ait altyapıda kendi başına penetrasyon yetkisi verme hakkı bulunmayabilir.

Scope aynı zamanda yöntem sınırı da içermelidir. SQL injection, XSS, IDOR, kimlik doğrulama atlatma, business logic hataları ve API yetkilendirme kontrolleri izin verilen kategori olarak sayılabilir. Buna karşılık DDoS, fiziksel saldırı, sosyal mühendislik, çalışanları hedefleme, zararlı yazılım yerleştirme ve üretim verisini toplu indirme açıkça yasaklanabilir.

5. Out-of-Scope Bir Sisteme Erişilirse Ne Olur?

Out-of-scope sisteme bilerek erişmek, bug bounty yetkisinin dışında kalır. Araştırmacının aynı şirkete ait olduğunu düşünmesi tek başına yetki yaratmaz. TCK m.243 bakımından hukuka uygunluk değerlendirmesi, erişilen somut sistem üzerinde izin bulunup bulunmadığına göre yapılır.

Test sırasında beklenmedik biçimde kapsam dışı bir varlığa yönlendirme olursa güvenli yöntem, erişimi ilerletmeden durmak ve program sahibine bildirmektir. Bir açık, scope içindeki uygulamadan başka sisteme sıçramaya imkân veriyorsa bu imkânın varlığını minimum kanıtla bildirmek gerekir. Kapsam dışı sisteme tam erişim sağlamak, kullanıcı listesi çekmek veya yeni zafiyet aramaya devam etmek izin sınırını aşar.

Program sahibinin de scope dışı bulgulara ilişkin süreç belirlemesi gerekir. “Out-of-scope bulgu hiçbir şekilde kabul edilmez” cümlesi, araştırmacıyı zorunlu olarak yetkilendirmez; yalnız ödül politikasını anlatır. Ceza hukuku bakımından ayrı mesele, araştırmacının o sisteme erişim yetkisinin bulunup bulunmadığıdır.

6. TCK m.244 Hangi Testlerde Gündeme Gelir?

TCK m.244/1 bir bilişim sisteminin işleyişini engelleme veya bozmayı; m.244/2 ise sistemdeki verileri bozma, yok etme, değiştirme veya erişilmez kılma, sisteme veri yerleştirme ya da var olan verileri başka yere gönderme fiillerini düzenler. Bu fiiller bug bounty testinde “zafiyeti kanıtlamak” amacıyla yapılmış olsa bile otomatik olarak hukuka uygun sayılmaz.

Program sahibi, testin doğrulanması için kontrollü veri oluşturma veya yalnız araştırmacının kendi test hesabındaki veriyi değiştirme yetkisi verebilir. Bu yetki açık olmalıdır. Başka kullanıcıların verisini silmek, sipariş durumunu değiştirmek, bakiye yaratmak, gerçek ödeme yapmak, üretim dosyasını erişilmez kılmak veya sistemi çalışamaz hâle getirmek açık yetki bulunmadıkça testin sınırını aşar.

Özellikle “impact göstermek” amacıyla veri bütünlüğüne müdahale edilmesi gereksizdir. Bir IDOR açığında başka kullanıcının kaydının değiştirilebildiğini göstermek için gerçek kaydı değiştirmek yerine, şirketin sağladığı iki test hesabı arasında kontrollü doğrulama yapılmalıdır.

7. DoS ve Yük Testleri Neden Ayrı İzin Gerektirir?

Hizmet engelleme ve aşırı yük testleri sistemin çalışmasını etkileyebilir. TCK m.244/1 sistemin işleyişini engelleme veya bozmayı doğrudan suç tipi olarak düzenlediğinden, DDoS veya yüksek hacimli yük üretimi bug bounty kapsamına kendiliğinden dahil değildir. Program metninde açıkça izin verilmedikçe bu testler yapılmamalıdır.

Şirket yük testi istiyorsa hedef sistem, zaman penceresi, maksimum istek hızı, kaynak IP, izleme ekibi ve durdurma kriteri önceden belirlenmelidir. Bu tür testler genel bug bounty programından ayrı, kapalı ve koordineli bir güvenlik çalışması olarak yürütülmesi gereken işlemlerdir.

Rate-limit açığını göstermek için milyonlarca istek göndermek de gerekli değildir. Teknik kanıt, düşük hacimli ve zarar vermeyen istek setiyle kurulabiliyorsa araştırmacı minimum etki ilkesine uymalıdır.

8. Gerçek Kullanıcı Verisiyle Karşılaşılırsa Ne Yapılmalıdır?

Bug bounty testi sırasında kişisel veriyle karşılaşılması, araştırmacıya bu veriyi serbestçe inceleme veya kopyalama yetkisi vermez. KVKK m.4 kişisel verilerin hukuka ve dürüstlük kurallarına uygun, belirli ve meşru amaçla, amaçla bağlantılı, sınırlı ve ölçülü işlenmesini zorunlu kılar. KVKK m.12 ise veri sorumlusuna kişisel verilerin hukuka aykırı işlenmesini ve erişilmesini önleme ile verilerin muhafazasını sağlama yükümlülüğü yükler.

Program kuralları bu nedenle “gerçek veri görülürse durdur ve bildir” prosedürü içermelidir. Araştırmacı bulguyu ispatlayacak minimum bilgiyi rapora koymalı; kimlik numarası, sağlık verisi, ödeme bilgisi, mesaj içeriği veya geniş kullanıcı listesi gibi verileri gereksiz biçimde indirmemelidir.

Şirket, araştırmacıya test hesabı ve sentetik veri sağlayarak gerçek kişisel veriye temas ihtiyacını azaltabilir. Güvenlik açığı veri sızıntısına yol açıyorsa şirketin olayı ayrıca KVKK veri ihlali yükümlülükleri bakımından değerlendirmesi gerekir; bug bounty raporunun alınması, veri ihlali süreçlerini ortadan kaldırmaz.

9. Kanıt İçin Ne Kadar Veri İndirilebilir?

“Proof of concept” amacı, sınırsız veri çekme yetkisi değildir. Zafiyetin varlığını göstermek için gerekli en küçük veri seti kullanılmalıdır. Bir endpoint’in bütün müşterileri döndürdüğünü kanıtlamak için on binlerce kaydı bilgisayara indirmek hukuken ve güvenlik bakımından gereksiz risk yaratır.

Program sahibi, raporda izin verilen kanıt yöntemlerini açıkça yazmalıdır. Ekran görüntüsünde hassas alanların maskelenmesi, yalnız araştırmacıya ait iki test hesabının kullanılması, kayıt sayısının gösterilip içeriklerin çekilmemesi veya tek örnek kaydın şirket tarafından oluşturulması tercih edilebilir.

Araştırmacının yanlışlıkla aldığı veriyi ne kadar süre saklayacağı ve hangi yöntemle sileceği de programa eklenmelidir. Ödül anlaşmazlığı çıkması ihtimali, kişisel verilerin süresiz saklanması için genel bir gerekçe oluşturmaz.

10. Güvenlik Araçları TCK m.245/A Kapsamına Girer mi?

TCK m.245/A, bilişim suçlarının veya bilişim sistemlerinin araç olarak kullanılması suretiyle işlenebilen diğer suçların işlenmesi amacıyla cihaz, bilgisayar programı, şifre veya sair güvenlik kodlarının belirli şekillerde üretilmesi, bulundurulması ve aktarılmasına ilişkin suç tipini düzenler. Maddenin uygulanmasında aracın niteliği yanında suç işleme amacı da önemlidir.

Nmap, Burp Suite, proxy, fuzzing aracı veya parola denetim aracı gibi çift kullanımlı güvenlik yazılımlarının meşru güvenlik testi amacıyla kullanılması tek başına suç oluşturduğu şeklinde yorumlanamaz. Bug bounty programında test yetkisinin ve aracın kullanım amacının kayıt altına alınması, araştırmacının meşru güvenlik faaliyeti yürüttüğünü gösteren önemli delillerdendir.

Buna karşılık zararlı amaçla hazırlanmış kimlik bilgisi hırsızlığı aracı, yetkisiz erişim için ele geçirilen güvenlik kodu veya suçun icrasına özgülenmiş araçlar farklı değerlendirilir. Bug bounty yetkisi, program dışındaki suç amaçlı araç dolaşımına koruma sağlamaz.

11. Ödül Hakkı Nasıl Doğar?

Bug bounty ödülü, şirketin program şartlarında belirlediği koşullara göre doğar. TBK m.26 kapsamında ödülün türü, miktarı veya aralığı, duplicate bulgu kuralı, ilk bildiren araştırmacı ölçütü, severity yöntemi ve ödeme şartları açıkça belirlenebilir.

“Kritik açık bulana 100.000 TL” şeklindeki tek cümle yeterli bir program yönetimi değildir. Kritik seviyenin CVSS puanına mı, gerçek iş etkisine mi, veri kapsamına mı göre belirleneceği yazılmalıdır. Aynı açığın daha önce iç ekip tarafından biliniyor olması, raporun ödülsüz sayılması için kullanılacaksa “known issue” kuralı programa eklenmelidir.

Program sahibi, geçerli raporu kabul edip ödül taahhüdünü yerine getirmezse uyuşmazlık sözleşmesel alacak tartışmasına dönüşebilir. Araştırmacının hukuka uygun test yapmış olması ile ödül koşullarını yerine getirip getirmediği iki ayrı sorudur.

12. Gizlilik ve Kamuya Açıklama Kuralları Nasıl Yazılmalıdır?

Bir güvenlik açığının kamuya açıklanması, özellikle açık henüz kapatılmamışsa kullanıcıları riske sokabilir. Program, raporun hangi süre boyunca gizli tutulacağını, şirketin düzeltme yapmasından sonra araştırmacının teknik yazı yayımlayıp yayımlayamayacağını ve yayımlanabilecek ayrıntı düzeyini belirlemelidir.

Mutlak ve süresiz “hiçbir zaman açıklayamazsın” hükmü yerine, güvenlik düzeltmesinin makul sürede tamamlanması ve koordineli açıklama modeli daha işlevseldir. Ancak araştırmacı program koşullarını kabul etmişse, gizlilik yükümlülüğünün kapsamına uymalıdır.

Kişisel veri, ticari sır, kaynak kod veya üçüncü kişiye ait sır niteliğindeki bilgi kamuya açık rapora konulmamalıdır. Araştırmacının teknik katkısının belirtilmesi, şirketin onayı ve tarafların disclosure planı içinde yapılabilir.

13. Alt Alan Adı, API ve Üçüncü Taraf Servisler Nasıl Ayrılır?

Modern uygulamalar çok sayıda SaaS, CDN, ödeme sağlayıcısı, kimlik doğrulama hizmeti ve analitik aracı kullanır. Bir alan adının şirket markasını taşıması, altyapının tamamında şirketin test izni verme yetkisi olduğu anlamına gelmez.

Program sahibi varlık envanterini çıkararak “şirkete ait ve test edilebilir”, “üçüncü taraf ama sözleşmeyle test izni alınmış” ve “kesinlikle kapsam dışı” biçiminde sınıflandırma yapmalıdır. Araştırmacı da DNS kaydı, sertifika veya marka görünümünden yola çıkarak üçüncü taraf sisteme saldırı yetkisi bulunduğunu varsaymamalıdır.

API testlerinde de aynı ilke geçerlidir. Public API dokümantasyonunun varlığı, her endpoint üzerinde yetki atlatma veya yüksek hacimli otomasyon izni anlamına gelmez. Bug bounty sayfası hangi API ortamının ve hangi hesapların test edileceğini göstermelidir.

14. Şirket Çalışanı veya Yüklenici Bug Bounty’ye Katılabilir mi?

Bu konu program koşuluyla belirlenir. Şirket, içerden bilgiye erişimi olan çalışanları, eski çalışanları, güvenlik tedarikçilerini veya bunların yakınlarını ödül programı dışında bırakabilir. Böyle bir kural ödül hakkını düzenler.

Çalışanın iş görevi kapsamında zaten güvenlik testi yapma yetkisi bulunuyorsa, ayrıca public bug bounty programına dayanması gerekli değildir. Yetkisi bulunmayan çalışanın sırf şirket personeli olması ise bütün sistemlerde sınırsız test hakkı vermez. Kurumsal erişim yetkileri görev tanımı ve iç politika çerçevesinde değerlendirilir.

Yükleniciler bakımından sözleşmedeki pentest, bakım veya güvenlik görevleri açık olmalıdır. Bir yazılım ajansının üretim ortamına erişim hesabının bulunması, bu hesabı kullanarak bağımsız güvenlik testi yapma yetkisini otomatik olarak yaratmaz.

15. Safe Harbor Maddesi Ne Sağlar?

Safe harbor, araştırmacının program kurallarına uygun hareket ettiği sürece şirketin bu yetkili faaliyet nedeniyle hukuki işlem başlatmayacağını ve iyi niyetli araştırmacıyı destekleyeceğini açıklayan program hükmüdür. Türk hukukunda “safe harbor” adıyla genel bir ceza muafiyeti düzenlemesi yoktur; hükmün etkisi verilen yetkinin kapsamını somutlaştırmasındadır.

Metin; scope içinde, izin verilen yöntemlerle ve minimum veri erişimiyle yapılan testleri açıkça kapsamalıdır. Araştırmacının kapsam dışına çıkması, veri satması, şantaj yapması, sistemi bozması veya kişisel verileri yayması safe harbor dışında bırakılmalıdır.

Şirket, üçüncü taraf sistemleri için kendi başına safe harbor veremeyeceğini de belirtmelidir. Örneğin ödeme kuruluşunun altyapısı şirket uygulamasına entegre olsa bile test izni ödeme kuruluşunun yetkisine bağlıdır.

16. Loglar ve İspat Nasıl Yönetilmelidir?

Bug bounty uyuşmazlığında hangi IP’nin, hangi kullanıcı hesabının, hangi tarihte ve hangi endpoint’e eriştiği kritik hâle gelir. Program sahibi WAF, uygulama, kimlik doğrulama ve API loglarını olayla ilişkilendirilebilir biçimde tutmalıdır. Araştırmacıya test hesabı veya özel header değeri verilmesi, yetkili trafik ile saldırgan trafiğini ayırmayı kolaylaştırır.

Araştırmacı da raporunda kullandığı istekleri, tarih-saat bilgisini ve kendi test hesabını göstermelidir. Ancak rapora gereksiz gerçek kullanıcı verisi eklenmemelidir. İspat için log saklamak ile kişisel verileri sınırsız kopyalamak aynı işlem değildir.

Program şartlarının eski sürümleri de saklanmalıdır. Scope 10 Eylül’de genişletilmişse 5 Eylül’de yapılan testin sonradan genişleyen yetkiye dayanması mümkün değildir. Hukuki değerlendirme, fiilin gerçekleştiği tarihteki yetki kapsamına göre yapılır.

17. Şirketler İçin Bug Bounty Kontrol Listesi

• Program sahibi tüzel kişi ve iletişim noktası açıkça yazılmalıdır.
• Scope içindeki alan adı, IP, mobil uygulama ve API tek tek tanımlanmalıdır.
• Scope dışı sistemler ayrıca listelenmelidir.
• DDoS, sosyal mühendislik, fiziksel test ve zararlı yazılım gibi yasak yöntemler belirtilmelidir.
• Gerçek kullanıcı verisine erişildiğinde testin durdurulması ve minimum kanıt kuralı yazılmalıdır.
• Test hesabı ve sentetik veri sağlanmalıdır.
• TCK m.243-244 bakımından yetki sınırını açıklaştıran safe-harbor hükmü bulunmalıdır.
• Ödül seviyesi, duplicate ve known-issue kuralları açıklanmalıdır.
• Rapor teslim kanalı şifreli ve doğrulanmış olmalıdır.
• Açığın kamuya açıklanması için koordineli disclosure süresi belirlenmelidir.
• Üçüncü taraf servisler için test yetkisi ayrıca kontrol edilmelidir.
• Program sayfasının sürüm ve değişiklik geçmişi saklanmalıdır.

18. Araştırmacılar İçin Net Hukuki Sınırlar

Birinci kural scope dışında test yapmamaktır. İkinci kural, izin verilen güvenlik açığını göstermek için gerekli en düşük etkiyi yaratmaktır. Üçüncü kural, gerçek kullanıcı verisini gereksiz biçimde indirmemek ve yaymamaktır. Dördüncü kural, şirketin kapatması gereken bir açığı baskı veya ödeme aracı hâline getirmemektir.

Bir açık başka sisteme zincirlenebiliyorsa araştırmacı zincirin varlığını raporlar; yeni sisteme tam erişim yetkisi yoksa ilerlemez. Veri değiştirme gerekiyorsa yalnız programın sağladığı test hesabında ve izin verilen işlemle doğrulama yapar. Üretim hizmetini kesintiye uğratabilecek yöntemlerden kaçınır.

Bu sınırlar yalnız “etik hacker” etiketi için değil, TCK m.243-244’te düzenlenen fiillerden ayrışmak için de önemlidir. Hukuki koruma, araştırmacının kendi iyi niyet iddiasından değil; sistem sahibinin somut yetkisi ve testin bu yetkiye uygunluğundan doğar.

19. Site İçindeki İlgili Rehberler

Bilişim sistemine izinsiz erişimin ceza hukuku boyutu için TCK 243 bilişim sistemine girme rehberi, dijital materyalin ceza soruşturmasındaki incelenmesi için CMK 134 dijital delil rehberi, kişisel veri güvenliği yönünden KVKK veri ihlali rehberi ve yeni siber düzenlemeler bakımından 7545 sayılı Kanun denetim rehberi birlikte incelenebilir.

20. Resmî Kaynaklar

• T.C. Adalet Bakanlığı – 5237 sayılı Türk Ceza Kanunu, özellikle m.243, m.244 ve m.245/A
• T.C. Adalet Bakanlığı – Türk Ceza Kanunu’nda Düzenlenen Bilişim Suçları Eğitim Modülü
• 6098 sayılı Türk Borçlar Kanunu – özellikle m.26
• Kişisel Verileri Koruma Kurumu – 6698 sayılı KVKK, özellikle m.4 ve m.12

21. Sık Sorulan Sorular

Bug bounty yapmak Türkiye’de suç mu?

Hayır. Sistem sahibinin açıkça yetki verdiği varlıklarda ve yöntemlerde test yapmak tek başına suç değildir. TCK m.243 bakımından belirleyici unsur erişimin hukuka aykırı olup olmadığıdır.

Şirketin web sitesi public ise test izni var sayılır mı?

Hayır. Bir web sitesinin internete açık olması, güvenlik mekanizmalarını aşmaya veya özel alanlara erişmeye izin verildiği anlamına gelmez.

Bug bounty programı yazılı olmak zorunda mı?

Yetkinin ispatı ve kapsamının belirlenmesi için program kurallarının yazılı, tarihli ve erişilebilir olması gerekir. Özellikle scope ve yasak yöntemler açıkça gösterilmelidir.

Scope içindeki uygulamada veri değiştirmek serbest mi?

Hayır. Sisteme erişim izni, veri değiştirme izniyle aynı şey değildir. TCK m.244 veriyi değiştirme, yok etme ve erişilmez kılma fiillerini ayrıca düzenler.

Bir açığı kanıtlamak için müşteri verisi indirilebilir mi?

Yalnız gerekli en küçük kanıt kullanılmalıdır. Geniş kullanıcı verisini indirmek, zafiyetin ispatı için gerekli değilse ölçülü değildir ve ayrıca kişisel veri sorumluluğu doğurabilir.

DDoS testi bug bounty kapsamında mıdır?

Program açıkça izin vermedikçe değildir. DDoS ve yüksek hacimli yük testi sistem işleyişini etkileyebileceği için ayrı ve koordineli yetki gerektirir.

Burp Suite veya Nmap kullanmak suç mu?

Meşru ve yetkili güvenlik testi amacıyla kullanılan çift kullanımlı güvenlik araçlarının bulundurulması tek başına suç değildir. TCK m.245/A bakımından aracın niteliği ve suç işleme amacı birlikte değerlendirilir.

Bug bounty bulgusunu sosyal medyada hemen paylaşabilir miyim?

Programın disclosure ve gizlilik kuralına uyulmalıdır. Açık kapatılmadan teknik detayların yayımlanması kullanıcıları riske sokabilir ve sözleşmesel sorumluluk doğurabilir.

Üçüncü taraf ödeme sayfasını test edebilir miyim?

Ancak o sistem için test yetkisi verilmişse. Şirketin markasının görünmesi üçüncü taraf hizmet sağlayıcısının sisteminde test yetkisi yaratmaz.

Şirket ödül ödemezse test otomatik olarak hukuka aykırı mı olur?

Hayır. Testin hukuka uygunluğu ile ödül alacağının doğup doğmadığı ayrı meselelerdir. Yetki kapsamında yapılan test, ödül uyuşmazlığı çıkması nedeniyle geriye dönük olarak yetkisiz hâle gelmez.

22. Sonuç

Bug bounty programında hukuki güvenlik, “iyi niyetli hacker” etiketinden değil açık yetkiden doğar. Şirket scope’u varlık ve yöntem bazında belirlemeli; araştırmacı verilen sınırın dışına çıkmamalıdır. TCK m.243 hukuka aykırı erişimi, TCK m.244 sistem ve veri üzerindeki bozucu/değiştirici müdahaleleri, TCK m.245/A ise suç amacıyla kullanılan belirli cihaz, program ve güvenlik kodlarını düzenler. Kişisel veriyle karşılaşıldığında KVKK’nın sınırlılık, ölçülülük ve veri güvenliği yükümlülükleri uygulanır.

Bug bounty programı hazırlanırken teknik ekip, hukuk ekibi ve olay müdahale ekibi aynı kapsam tablosunu kullanmalıdır. Yetki sayfası; hangi sistemi test edebileceğinizi, neyi yapamayacağınızı, bulguyu nasıl bildireceğinizi ve hangi veriye ne ölçüde dokunabileceğinizi tereddütsüz göstermelidir.

Av. Halil Bakırcı tarafından hazırlanmış, Av. Emirhan Keskin tarafından incelenmiştir.

Yazar Bilgisi

Avukat Halil BAKIRCI, Mersin Barosu 3472 sicil numarasına kayıtlıdır. Bakırcı & Keskin Hukuk Bürosu bünyesinde ceza, aile, iş, gayrimenkul ve ticaret hukuku alanlarında hukuki danışmanlık ve dava takibi sunmaktadır.

İnceleyen: Av. Emirhan Keskin · Mersin Barosu Sicil No: 5507

Av. Halil Bakırcı profilini inceleyin →