İlk Bug Bounty Raporunu Nasıl Yazarsın? (Şablonla)
Bug bounty raporu, bulduğun güvenlik açığını programın ekibinin soru sormadan yeniden üretebileceği biçimde anlatan belgedir. İyi bir rapor net bir başlık, kısa özet, gerçek etki, numaralı yeniden üretim adımları, kanıt ve düzeltme önerisi içerir. Google gibi bazı programlar ödülü rapor kalitesine göre 0,8 ile 1,2 arasında bir katsayıyla çarpar.
Açığı bulmak işin yarısı. Diğer yarısı, onu hiç tanımadığın bir analiste beş dakikada anlatmak. İyi bir zafiyet raporu bu yüzden en az teknik bilgi kadar önemli. Bu yazıda HackerOne, Bugcrowd ve Google'ın kendi rapor rehberlerini okuduk, ortak noktaları tek bir şablona döktük. Şablonu kopyalayıp ilk raporunda doğrudan kullanabilirsin.
Bug bounty raporu neden bu kadar önemli?
Rapor, bulduğun açığın ödüle dönüşüp dönüşmeyeceğini belirleyen belgedir; triage ekibi yalnız senin yazdığını görür ve ona göre karar verir. Eksik rapor, geçerli bir açığı bile "yeniden üretilemedi" diye kapattırabilir.
Bazı programlar rapor kalitesini doğrudan ödüle yansıtıyor. Google'ın VRP kurallarında ödül, rapor kalitesine göre 0,8, 1 ya da 1,2 ile çarpılıyor. Google ayrıca yalnız triage öncesinde rapordaki bilgiyi dikkate aldığını yazıyor. Yani eksiği sonradan tamamlamak ödülü çoğu zaman değiştirmez.
Platform kuralları da sıkılaşıyor. HackerOne, 21 Eylül 2026'dan beri her raporda önem derecesi seçmeyi zorunlu tutuyor. Bugcrowd'da ise rapor gönderildikten sonra düzenlenemiyor. Bu yüzden ilk gönderim çok önemli.
İyi bir bug bounty raporunda hangi bölümler olur?
İyi bir raporda başlık, özet, etkilenen varlık, önem derecesi, etki, yeniden üretim adımları, kavram kanıtı ve düzeltme önerisi bulunur. HackerOne'ın rehberi bunlardan dördünü şart sayar: net başlık, adım adım yeniden üretim, etki ve destekleyici materyal.
| Bölüm | Ne yazarsın | Sık yapılan hata |
|---|---|---|
| Başlık | Açık türü, yeri ve etkisi tek cümlede | "XSS bulundu" gibi tek kelime. |
| Özet | Ne buldun, nerede, saldırgan ne kazanır | Paragraflarca giriş. |
| Etkilenen varlık | Alan adı, uç nokta, sürüm, gereken rol | Kapsam dışı alt alan adı. |
| Önem derecesi | CVSS vektörü ve tek cümle gerekçe | Her şeye "kritik" demek. |
| Etki | Hangi veri, kaç kullanıcı, hangi işlem | "Saldırgan her şeyi yapabilir". |
| Yeniden üretim adımları | Numaralı, ön koşullu, test hesaplarıyla | Adım atlamak. |
| Kavram kanıtı | Ekran görüntüsü, kısa video, maskelenmiş istek | Gerçek kullanıcı verisi göstermek. |
| Düzeltme önerisi | Kök nedene dönük kısa öneri | "Güvenliği artırın". |
Bugcrowd'un gönderim formu da benzer alanlar istiyor. Başlık alanı açığın türünü, yerini ve genel etkisini vermeli. Açıklama alanı en çok 25.000 karakter. En çok 20 ek dosya yükleyebiliyorsun. Google'ın kalite tablosu buna iki şey ekliyor: saldırının ön koşulları ve hızlı, net iletişim.
Kopyalanabilir bug bounty rapor şablonu nasıl görünür?
İngilizce kaynaklarda "bug bounty report template" diye aranan yapı budur. Aşağıdaki şablon HackerOne, Bugcrowd ve Google rehberlerindeki ortak alanlardan oluşur. Köşeli parantezleri kendi bulgunla doldur, işine yaramayan satırı sil.
# [Açık türü] [nerede] ile [etki] ### Özet [İki üç cümle: ne buldun, nerede buldun, saldırgan ne kazanır] ### Etkilenen varlık - Hedef: [alan adı ya da uygulama adı ve sürümü] - Uç nokta veya ekran: [yol ve parametre adı] - Gereken rol: [anonim / normal kullanıcı / yönetici] ### Önem derecesi - CVSS sürümü ve vektör: [CVSS:3.1/... ya da CVSS:4.0/...] - Puan ve gerekçe: [0.0-10.0, tek cümle] ### Etki [Saldırgan gerçekçi olarak ne yapabilir? Hangi veri, kaç kullanıcı?] ### Ön koşullar - [Senin açtığın iki test hesabı: A ve B] - [Tarayıcı ya da uygulama sürümü, gerekiyorsa ayar] ### Yeniden üretim adımları 1. [Adım] 2. [Adım] 3. [Adım] ### Beklenen ve görülen davranış - Beklenen: [Uygulamanın yapması gereken] - Görülen: [Uygulamanın yaptığı] ### Kavram kanıtı - [Ekran görüntüsü ya da video dosya adı] - [İstek ve yanıt, kişisel veriler maskelenmiş] ### Önerilen düzeltme [Kök neden ve kalıcı çözüm önerisi] ### Notlar - [Test zamanı, kullandığın özel başlık, programın istediği ek bilgi]
Türk programlarında da benzer bir yapı istenir. Bitexen, kendi programı için Türkçe ve İngilizce örnek rapor formatını GitHub'da yayımlıyor. Şablonun nasıl dolduğunu görmek için kurgusal bir örnek düşünelim. Hedef "ornek-magaza.test" adlı hayali bir mağaza. Açık, başkasının sipariş özetini görmeye yol açan bir erişim denetimi hatası, yani IDOR. Doldurulmuş hali kabaca şöyle olur:
- Başlık: Sipariş özeti uç noktasında IDOR, başka kullanıcının teslimat adresi okunabiliyor.
- Özet: Sunucu, sipariş kimliğinin oturumdaki kullanıcıya ait olup olmadığını kontrol etmiyor. Giriş yapmış her kullanıcı başkasının ad ve adres bilgisini görebiliyor.
- Ön koşul: Kendi açtığın A ve B adlı iki test hesabı. B hesabıyla bir test siparişi verilmiş.
- Adımlar: A hesabıyla kendi sipariş özetini açarsın. İstekteki sipariş kimliğini B'nin test siparişiyle değiştirirsin. Yanıtta B'nin teslimat adresi görünür.
- Öneri: Sunucu her istekte sipariş sahibini oturumdaki kullanıcıyla karşılaştırmalı.
Dikkat et, örnek yalnız senin açtığın iki hesabı kullanıyor. Gerçek bir kullanıcının verisine erişmek, program izin verse bile gereksiz risk ve çoğu programda kural ihlalidir. IDOR'un mantığını ve savunmasını IDOR nedir yazımızda ayrıca anlattık.
İyi bir rapor başlığı nasıl yazılır?
İyi bir başlık açığın türünü, yerini ve etkisini tek cümlede verir. Triage ekibi raporu önce başlığından tanır, bu yüzden başlık ilk izlenimdir.
| Kötü başlık | Neden zayıf | Daha iyi başlık |
|---|---|---|
| XSS bulundu | Yer ve etki yok. | Profil "hakkımda" alanında kayıtlı XSS, ziyaretçinin oturumunda işlem yaptırıyor. |
| ACİL kritik açık | Duygu var, bilgi yok. | Şifre sıfırlama bağlantısı başka hesaba yönlendirilebiliyor, hesap ele geçirilebiliyor. |
| IDOR | Tek kelime, bağlam yok. | Sipariş API'sinde IDOR, başka kullanıcının teslimat adresi okunabiliyor. |
| Siteniz güvensiz | Ne, nerede belirsiz. | Yönetim paneli dışa açık, varsayılan ayarla kimlik doğrulaması atlanıyor. |
| CSP başlığı eksik | Etki gösterilmemiş. | Bunu tek başına rapor etme; sömürülebilir bir açıkla birleşmiyorsa ödül çıkmaz. |
Önem derecesi CVSS 3.1 ve 4.0 ile nasıl belirlenir?
CVSS, FIRST'ün yayımladığı ve açığın önemini 0 ile 10 arasında puanlayan açık bir standarttır. Bug bounty'de en çok 2019'da yayımlanan 3.1 ve 1 Kasım 2023'te yayımlanan 4.0 kullanılır.
İki sürüm de aynı nitel ölçeği kullanır:
| Puan | Önem |
|---|---|
| 0.0 | Yok |
| 0.1 - 3.9 | Düşük |
| 4.0 - 6.9 | Orta |
| 7.0 - 8.9 | Yüksek |
| 9.0 - 10.0 | Kritik |
CVSS 3.1'in temel ölçütleri sekiz tanedir: saldırı vektörü, saldırı karmaşıklığı, gereken yetki, kullanıcı etkileşimi, kapsam, gizlilik etkisi, bütünlük etkisi ve erişilebilirlik etkisi. CVSS 4.0 kapsam ölçütünü kaldırdı. Yerine etkiyi açığın bulunduğu sistem ve sonraki sistemler olarak ikiye böldü. "Saldırı gereksinimleri" adlı yeni bir ölçüt ekledi. Eski zamansal grubun adı tehdit grubu oldu. Sürüm 4.0 puanın neye dayandığını da adla gösteriyor: yalnız temel ölçütler için CVSS-B, tehdit eklenince CVSS-BT gibi.
Platformlar arasında küçük farklar var. HackerOne'da CVSS 3.1, 3.0, 4.0 ya da elle seçim yapabiliyorsun. Bugcrowd ise kendi VRT tablosuyla P1'den P5'e öncelik veriyor. Hepsiburada'nın CyberBounty programı CVSS 9.0 ve üstünü P1, 7.0 ile 8.9 arasını P2 sayıyor. Kural basit: puanı şişirme, vektörü yaz ve tek cümleyle gerekçelendir. Triage ekibi zaten yeniden hesaplar. Abartılı puan güveni zedeler. CVSS'i adım adım öğrenmek için CVSS ile risk puanlama dersine bak.
Triage sürecinde nasıl iletişim kurmalısın?
Triage, platformun ya da şirketin analistinin raporunu doğruladığı ve önem derecesini kesinleştirdiği ilk aşamadır. Bu aşamada kısa, teknik ve hızlı cevap vermek raporu öne taşır.
Google'ın kalite tablosu iletişimi de puanlıyor. Üç iş günü içinde net ve teknik cevap "olağanüstü" sayılıyor. Uzun gecikmeler, konu dışı tartışma ve yapay zekâyla üretilmiş anlamsız cevaplar düşük kalite sayılıyor. Programların kendi hedefleri de var. Örneğin Trendyol'un HackerOne politikası ilk cevap ve triage için iki iş günü, ödül kararı için 14 iş günü hedefliyor.
Triage sırasında şu kurallar işini kolaylaştırır:
- Analist ek bilgi isterse yalnız sorulanı, kanıtıyla birlikte ver.
- Yeniden üretemediklerini söylerlerse kısa bir video ekle.
- Her gün "durum ne?" diye yazma. Programın hedef süresi geçtiyse bir kez nazikçe sor.
- Ödül miktarı için pazarlık etme. Programın tablosu ve politikası belirleyicidir.
- İzin almadan açığı paylaşma. Bugcrowd, izinsiz ifşanın program ya da platform erişimini kaybettirebileceğini yazıyor.
- Anlaşmazlık olursa platformun arabuluculuk yoluna başvur. HackerOne'da bunun adı Hacker Mediation.
Raporlar en çok neden reddedilir?
Reddedilen raporların nedenleri büyük ölçüde tekrar eder: kapsam dışı hedef, yalnız kendine zarar veren açık ve etkisi gösterilmeyen sertleştirme önerileri. HackerOne bunları "temel olarak uygun olmayan bulgular" listesinde topluyor.
| Red nedeni | Örnek | Ne yapmalısın |
|---|---|---|
| Kapsam dışı | Listede olmayan alt alan adı ya da üçüncü taraf servis. | Göndermeden önce kapsam tablosunu yeniden oku. |
| Self-XSS | Betiği yalnız kendi hesabında çalıştırmak. | Başka bir kullanıcıyı etkilediğini göster ya da gönderme. |
| En iyi uygulama eksiği | Çerez bayrağı, CSP görüşü, SPF ve DMARC ayarı. | Sömürülebilir bir zincir yoksa rapor etme. |
| Etkisiz bulgu | Hassas olmayan sayfada clickjacking, çıkış formunda CSRF. | Gerçek bir işlem ya da veri etkisi arayıp göster. |
| Bilgi ifşası sanılan şey | Sürüm numarası, ayrıntılı hata mesajı. | Bu bilgiyle neyin mümkün olduğunu kanıtla. |
| Yasaklı test | Hizmet reddi, sosyal mühendislik, fiziksel saldırı. | Bu yöntemleri hiç deneme. |
| Duplicate | Aynı açığı senden önce biri bildirmiş. | Yeni özelliklere ve az bakılan akışlara odaklan. |
Bir red nedeni de 2026'da öne çıktı: doğrulanmamış yapay zekâ çıktısı. curl projesi, geçerli rapor oranı yüzde 5'in altına düşünce Ocak 2026'da ödüllü programını kapattı. HackerOne de araştırmacının, aracın ürettiği her şeyden sorumlu olduğunu kurallarına yazdı. Hangi açık türlerinin daha çok kabul gördüğünü bug bounty'de en sık bulunan 10 açık yazımızda anlattık.
Raporu göndermeden önce neyi kontrol etmelisin?
Göndermeden önce yapılan son kontrol, kolay önlenebilir N/A kararlarının önüne geçer. Aşağıdaki listeyi her raporda baştan sona işaretle:
- Hedef, programın kapsam tablosunda açıkça yer alıyor mu?
- Açık, programın hariç tuttuğu türlerden biri mi?
- Adımları temiz bir tarayıcıda baştan uygulayınca sonuç aynı mı?
- Yalnız kendi test hesaplarını mı kullandın?
- Kanıttaki kişisel veriler, jetonlar ve çerezler maskelendi mi?
- Başlık türü, yeri ve etkiyi veriyor mu?
- CVSS vektörü yazıldı ve gerekçesi tek cümleyle açıklandı mı?
- Programın istediği özel başlık ya da test e-postası kullanıldı mı?
Unutma, bu şablon yalnız izin verilen programlarda işe yarar. İzinsiz test Türkiye'de TCK 243-245 kapsamında suçtur. Rapor yazmayı güvenli bir ortamda denemek istersen Rapor Teslimi labında dört bulguyu kapsam referansı, tekrar üretim adımı, kanıt ve CVSS puanıyla rapora dökersin. Temeli sağlamlaştırmak için Web Uygulama Güvenliği yolu iyi bir başlangıç. Hangi platformda rapor göndereceğine karar vermediysen HackerOne, Bugcrowd ve Intigriti karşılaştırmamıza bak. Ödemenin Türkiye'ye nasıl geldiğini ise bug bounty ile para kazanma rehberinde bulursun.
Kaynaklar
Sık sorulan sorular
Bug bounty raporu Türkçe yazılabilir mi?
Programın kuralları belirleyicidir. HackerOne, Bugcrowd ve Intigriti'deki programların çoğu İngilizce rapor bekler. Türk şirketlerinin kendi programlarında ise Türkçe rapor da kabul görebilir; örneğin Bitexen raporları Türkçe ya da İngilizce kabul ediyor. Emin değilsen program sayfasındaki dil notunu oku ya da İngilizce yaz.
Kavram kanıtı (PoC) olarak video şart mı?
Şart değil ama çoğu durumda işi hızlandırır. Bugcrowd ekran görüntüsü ve kavram kanıtı videosunu güçlü biçimde öneriyor. Google ise mümkünse otomatik bir kavram kanıtı istiyor. Videoyu kısa tut, yalnız açığı göster, gerçek kullanıcı verisi ya da oturum jetonu görünüyorsa mutlaka maskele.
Raporu gönderdikten sonra düzeltme yapabilir miyim?
Platforma göre değişir. Bugcrowd gönderilmiş raporun düzenlenemeyeceğini açıkça yazıyor. Google ödül kararında yalnız triage öncesindeki bilgiyi dikkate aldığını belirtiyor. Bu yüzden raporu taslak olarak hazırla, kontrol listesinden geçir ve ancak ondan sonra gönder. Sonradan gelen ek bilgi ödülü genelde değiştirmez.
CVSS puanını yanlış hesaplarsam ne olur?
Triage ekibi puanı kendi değerlendirmesine göre düzeltir, bu yüzden küçük hatalar raporu geçersiz kılmaz. Ancak her bulguya bilerek kritik demek güvenini zedeler. Vektörü yaz, her ölçütü neden seçtiğini tek cümleyle açıkla. Emin olmadığın ölçütte daha düşük değeri seçmek genelde daha güvenli bir yoldur.
Duplicate gelen raporum için bir şey yapabilir miyim?
Ödül genelde ilk geçerli rapora gider, bu kararı değiştirmek zordur. Yine de raporun farklı bir kök nedeni ya da daha büyük bir etkiyi gösteriyorsa bunu kısa ve kanıtlı biçimde belirtebilirsin. HackerOne'da kabul edilen bir raporun duplicate'i duruma göre itibar kazandırabilir. Sonraki raporda yeni özelliklere odaklan.
- bug bounty raporu
- bug bounty report template
- zafiyet raporu nasıl yazılır
- cvss
- hackerone