- Katılım
- 21 May 2023
- Mesajlar
- 514
- Tepki
- 17
- Puan
- 18
Kurgusal bir örnekle başlayalım: Bir online mağazada sepet sayfasının adresindeki sipariş numarasını bir rakam değiştirince başka bir müşterinin siparişinin ekranınıza geldiğini fark ettiğinizi düşünün. Elinizdeki bulguyu hemen foruma yazıp herkesle paylaşmak cazip gelebilir; ama asıl ilk durak site sahibinin veya üreticinin kendisidir.
Bu yazı foruma değil doğrudan siteye giden sırayı, bildirimde neyin yer alması gerektiğini ve yanıt gelmezse izlenecek yolu anlatıyor. Aşağıdaki adımlar bir süreç haritasıdır, hukuki tavsiye değildir; kendi durumunuza göre bir hukukçuya danışmanız gerekebilir.
Bir açığı forumda, sosyal medyada veya doğrudan basında paylaşmadan önce sıra üreticide ya da site sahibindedir. RFC 9116, kuruluşların bu iletişim yolunu "security.txt" adıyla standart bir konumda yayınlamasını tanımlıyor: dosya
security.txt aynı zamanda isteğe bağlı alanlar da taşıyabilir: bir Policy alanı, kuruluşun açıklama sürecini anlattığı sayfaya bağlanabilir; bir Acknowledgments alanı ise daha önce bildirim yapmış araştırmacıların teşekkür sayfasına işaret edebilir. Dosya öncelikle
Web güvenlik açıkları üzerine yazdığımız konu kullanıcı tarafında nelere dikkat edileceğini anlatıyor; burada ise açığı bulan tarafın hangi kapıyı çalacağına bakıyoruz.
CERT/CC'nin koordineli açıklama rehberi, zafiyeti bulan taraf, satıcı, koordinatör ve politika yapıcı gibi farklı rollerin sorumluluklarını ayırıyor ve sürecin özünü bulgunun toplanması, ilgili taraflar arasında bilginin koordine edilmesi ve nihayetinde kamuya açıklanması olarak tanımlıyor. Bildiriminizde bulunması iyi olan temel unsurlar şunlardır:
Kanal security.txt'teki bir Encryption alanı sunuyorsa bildirimi o anahtarla şifrelemek, hassas ayrıntıyı genel bir destek formuna değil doğrudan güvenlik kanalına taşımanın bir yolu. Bildirimi yazarken abartılı dil veya tehdit ifadesinden kaçının: CERT/CC rehberi süreci, araştırmacı, satıcı, koordinatör ve politika yapıcı arasında paylaşılan ortak bir sorumluluk olarak tanımlıyor, tek taraflı bir baskı aracı olarak değil.
Bir açığı doğrulamak için gördüğünüz kadarıyla yetinmek en güvenli tutumdur. Başka kullanıcıların verisini indirmek, bir hesaba giriş denemesi yapmak veya bulduğunuz açığı ilk bildirimden önce daha ileri götürmek, izin verilen sınırın dışına taşan bir erişime dönüşebilir ve bu, ülkeye göre ayrı bir hukuki risk taşıyabilir.
Bir bug bounty programı varsa bildirimden önce kapsam ve kural sayfasını okuyun; program dışında kalan bir sistemde test yapmak, iyi niyetli bir bulguyu bile kural dışına taşıyabilir. Bu yazı hukuki tavsiye değildir; kendi durumunuzu bir hukukçuyla konuşmanız, izin almadığınız bir sistemde daha fazla adım atmaktan daha güvenlidir.
CERT/CC rehberi, satıcı tarafında ürün güvenliği yanıt ekiplerinin (PSIRT) kurulmasını ve koordinatörlerin bu süreci desteklemesini önerdiği için, ilk bildirime makul bir sürede yanıt gelmemesi beklenmedik bir durum değil. Yanıt yoksa önce aynı kanaldan bir hatırlatma göndermek mantıklı; hâlâ sessizlikse CERT/CC gibi bir koordinatöre başvurmak, satıcı ile aranıza bağımsız bir taraf sokar.
Rehbere göre bir koordinatörün rolü, tarafları bir araya getirmek ve süreci teknik olarak desteklemektir; bulan tarafın yerine geçip satıcıyı zorlamak değil. Henüz yaması çıkmamış bir açığı aceleyle kamuya açıklamak, aynı bilgiyi saldırganların önüne de koyar; bekleme süresini bu yüzden koordinasyonla belirlemek gerekir.
Kamuya ne zaman açıklanacağı, satıcı ile açığı bulan taraf arasında koordine edilen bir karardır; bu yazı belli bir gün sayısı önermiyor, çünkü baktığımız kaynaklar sabit bir süre belirtmiyor. Yama yayınlandıktan sonra durumun kamuya açıklanması, kullanıcıların güncellemesi gerektiğini görmesi açısından da bir işlev görür. CVE numarası isteniyorsa bu adım da genelde satıcıyla birlikte, koordinasyonun bir parçası olarak netleştirilir; kesin süreç ürüne göre değiştiği için bunu ilgili tarafla teyit etmek en sağlam yol.
Karşılaştığınız şey bir açık değil de zaten gerçekleşmiş bir veri sızıntısıysa süreç farklı işler; sızıntı sonrası ilk 24 saatte ne yapılacağını anlattığımız konuya bakabilirsiniz. Bulduğunuz açık bir sitenin zaten ele geçirilmiş olduğunu gösteriyorsa, site zararlı yazılım temizliği konusu site sahibine yönlendirebileceğiniz ayrı bir kaynak.
Açığı önce doğru kanaldan ve elinizdeki en az kanıtla bildirin, izin sınırlarını aşan bir teste girmeyin, kamuya açıklama zamanlamasını da CVE adımını da satıcıyla birlikte belirleyin. Bir siteye açık bildirdiğinizde geri dönüş aldınız mı, süreç sizde nasıl işledi?
Güncelleme: 21 Ağustos 2026. CERT/CC koordineli açıklama rehberi ve RFC 9116 (security.txt) güncel içerikleriyle kontrol edildi.
Bu yazı foruma değil doğrudan siteye giden sırayı, bildirimde neyin yer alması gerektiğini ve yanıt gelmezse izlenecek yolu anlatıyor. Aşağıdaki adımlar bir süreç haritasıdır, hukuki tavsiye değildir; kendi durumunuza göre bir hukukçuya danışmanız gerekebilir.
Önce doğru kapıyı bulun
Bir açığı forumda, sosyal medyada veya doğrudan basında paylaşmadan önce sıra üreticide ya da site sahibindedir. RFC 9116, kuruluşların bu iletişim yolunu "security.txt" adıyla standart bir konumda yayınlamasını tanımlıyor: dosya
https://alanadi.com/.well-known/security.txt adresinde bulunur ve zorunlu olarak bir Contact alanı (e-posta, form veya telefon gibi bir bildirim kanalı) ile dosyanın geçerlilik süresini gösteren bir Expires alanı taşımak zorundadır. security.txt yoksa sitede "Güvenlik", "Responsible Disclosure" veya bir bug bounty programı sayfası aranır; hiçbiri bulunamıyorsa genel destek kanalı son çaredir.security.txt aynı zamanda isteğe bağlı alanlar da taşıyabilir: bir Policy alanı, kuruluşun açıklama sürecini anlattığı sayfaya bağlanabilir; bir Acknowledgments alanı ise daha önce bildirim yapmış araştırmacıların teşekkür sayfasına işaret edebilir. Dosya öncelikle
https://alanadi.com/.well-known/security.txt konumunda aranır; RFC 9116, kök dizindeki eski konumun da hâlâ karşılaşılabileceğini ve oradan yönlendirme yapılabileceğini belirtiyor.Web güvenlik açıkları üzerine yazdığımız konu kullanıcı tarafında nelere dikkat edileceğini anlatıyor; burada ise açığı bulan tarafın hangi kapıyı çalacağına bakıyoruz.
Bildiriminizde ne olmalı
CERT/CC'nin koordineli açıklama rehberi, zafiyeti bulan taraf, satıcı, koordinatör ve politika yapıcı gibi farklı rollerin sorumluluklarını ayırıyor ve sürecin özünü bulgunun toplanması, ilgili taraflar arasında bilginin koordine edilmesi ve nihayetinde kamuya açıklanması olarak tanımlıyor. Bildiriminizde bulunması iyi olan temel unsurlar şunlardır:
- Etkilenen ürün ve sürüm bilgisi
- Açığı yeniden oluşturma adımları
- Olası etki: hangi veri veya işlev risk altında
- Elinizdeki kanıt: ekran görüntüsü veya istek/yanıt örneği
Kanal security.txt'teki bir Encryption alanı sunuyorsa bildirimi o anahtarla şifrelemek, hassas ayrıntıyı genel bir destek formuna değil doğrudan güvenlik kanalına taşımanın bir yolu. Bildirimi yazarken abartılı dil veya tehdit ifadesinden kaçının: CERT/CC rehberi süreci, araştırmacı, satıcı, koordinatör ve politika yapıcı arasında paylaşılan ortak bir sorumluluk olarak tanımlıyor, tek taraflı bir baskı aracı olarak değil.
Kanıt toplarken sınırı nerede çizersiniz
Bir açığı doğrulamak için gördüğünüz kadarıyla yetinmek en güvenli tutumdur. Başka kullanıcıların verisini indirmek, bir hesaba giriş denemesi yapmak veya bulduğunuz açığı ilk bildirimden önce daha ileri götürmek, izin verilen sınırın dışına taşan bir erişime dönüşebilir ve bu, ülkeye göre ayrı bir hukuki risk taşıyabilir.
Bir bug bounty programı varsa bildirimden önce kapsam ve kural sayfasını okuyun; program dışında kalan bir sistemde test yapmak, iyi niyetli bir bulguyu bile kural dışına taşıyabilir. Bu yazı hukuki tavsiye değildir; kendi durumunuzu bir hukukçuyla konuşmanız, izin almadığınız bir sistemde daha fazla adım atmaktan daha güvenlidir.
Yanıt gelmezse veya gecikirse
CERT/CC rehberi, satıcı tarafında ürün güvenliği yanıt ekiplerinin (PSIRT) kurulmasını ve koordinatörlerin bu süreci desteklemesini önerdiği için, ilk bildirime makul bir sürede yanıt gelmemesi beklenmedik bir durum değil. Yanıt yoksa önce aynı kanaldan bir hatırlatma göndermek mantıklı; hâlâ sessizlikse CERT/CC gibi bir koordinatöre başvurmak, satıcı ile aranıza bağımsız bir taraf sokar.
Rehbere göre bir koordinatörün rolü, tarafları bir araya getirmek ve süreci teknik olarak desteklemektir; bulan tarafın yerine geçip satıcıyı zorlamak değil. Henüz yaması çıkmamış bir açığı aceleyle kamuya açıklamak, aynı bilgiyi saldırganların önüne de koyar; bekleme süresini bu yüzden koordinasyonla belirlemek gerekir.
Kamuya açıklama zamanlaması ve CVE
Kamuya ne zaman açıklanacağı, satıcı ile açığı bulan taraf arasında koordine edilen bir karardır; bu yazı belli bir gün sayısı önermiyor, çünkü baktığımız kaynaklar sabit bir süre belirtmiyor. Yama yayınlandıktan sonra durumun kamuya açıklanması, kullanıcıların güncellemesi gerektiğini görmesi açısından da bir işlev görür. CVE numarası isteniyorsa bu adım da genelde satıcıyla birlikte, koordinasyonun bir parçası olarak netleştirilir; kesin süreç ürüne göre değiştiği için bunu ilgili tarafla teyit etmek en sağlam yol.
Karşılaştığınız şey bir açık değil de zaten gerçekleşmiş bir veri sızıntısıysa süreç farklı işler; sızıntı sonrası ilk 24 saatte ne yapılacağını anlattığımız konuya bakabilirsiniz. Bulduğunuz açık bir sitenin zaten ele geçirilmiş olduğunu gösteriyorsa, site zararlı yazılım temizliği konusu site sahibine yönlendirebileceğiniz ayrı bir kaynak.
Özetle
Açığı önce doğru kanaldan ve elinizdeki en az kanıtla bildirin, izin sınırlarını aşan bir teste girmeyin, kamuya açıklama zamanlamasını da CVE adımını da satıcıyla birlikte belirleyin. Bir siteye açık bildirdiğinizde geri dönüş aldınız mı, süreç sizde nasıl işledi?
Güncelleme: 21 Ağustos 2026. CERT/CC koordineli açıklama rehberi ve RFC 9116 (security.txt) güncel içerikleriyle kontrol edildi.
Dijital Dünyanıza Yön Veren Pusula
