Güvenlik açığı bildirim politikası

Bir bakışta

Bu sayfa, NextPDF’in eşgüdümlü güvenlik açığı bildirim politikasını tanımlar. Bakımcılarla özel olarak nasıl iletişim kuracağınızı, hangi yanıt zaman çizelgesini bekleyebileceğinizi ve ambargoların nasıl işlediğini açıklar.

Sınır. Bir bildirim politikası bir süreç taahhüdüdür; bir zaman çizelgesi veya sonuç garantisi değildir. Aşağıdaki hedefler, bakımcıların bir bildiren olarak size yönelik iyi niyetli taahhütleridir; projenin izlediği süreci tanımlarlar, belirli bir bildirimin alındısının verileceğine, ele alınacağına, düzeltileceğine veya belirli bir tarihte açıklanacağına dair sözleşmesel taahhütler değildir. Eşgüdümlü bildirim zamanlaması müzakere edilir; tek taraflı olarak garanti edilmez.

Kurulum

Geçerli değil. Bir güvenlik açığı bildirmek için herhangi bir şey kurmanız gerekmez. Makine tarafından okunabilir iletişim yüzeyi /.well-known/security.txt adresinde yayımlanır (Request for Comments (RFC) 9116). Depodaki SECURITY.md dosyası, insan tarafından okunabilir ve esas alınacak politikadır.

Kavramsal genel bakış

Politika, ISO/IEC 29147 tarafından tanımlanan eşgüdümlü güvenlik açığı bildirimini ve ISO/IEC 30111 içindeki ele alma sürecini (iso_iec_30111#x9.x43.p2) uygular: özel alım, ele alma ve önem derecesi değerlendirmesi, ambargo altında düzeltme ve ortak kamuya açıklama. Bir güvenlik açığı birden çok satıcıyı etkiliyorsa, etkilenen taraflar uyarı zamanlamasını tek taraflı dayatmak yerine eşgüdüm içinde belirler (iso_iec_29147#x3.x110.p13).

Bu süreç ayrıca Avrupa Birliği (EU) Siber Dayanıklılık Yasası (CRA) kapsamındaki üretici güvenlik açığı ele alma yükümlülükleriyle (eu_cra#x1.p191) ve Ulusal Standartlar ve Teknoloji Enstitüsü (NIST) Güvenli Yazılım Geliştirme Çerçevesi’ndeki (SSDF) “güvenlik açıklarına yanıt ver” uygulamasıyla (nist_sp_800_218#x15) uyumludur. Her ikisi de bunları, tekil bir sonucun garanti edildiğine dair teminat olarak değil, yinelenebilir süreç görevleri olarak tanımlar.

API yüzeyi

Geçerli değil. Güvenlik açığı bildirimi bir süreçtir; bir uygulama programlama arabirimi (API) değildir. Makine tarafından okunabilir keşif yüzeyi, RFC 9116 security.txt dosyasıdır; araçlar bu dosyanın Contact: ve Expires: alanlarını okur. Bu sayfa, aşağıdaki kanalların ötesinde söz konusu dosyanın içeriğini yinelemez.

Kod örneği — Hızlı başlangıç

Geçerli değil. Bir güvenlik açığı bildirirken çalıştırmanız gereken hiçbir kod yoktur. Özel bir kanal kullanın:

• GitHub Security Advisories (tercih edilen — durağan halde şifreli, denetim günlüğü): projenin GitHub Security sekmesinde bir taslak uyarı açın.
• E-posta: [email protected] adresine, konu satırında [SECURITY] etiketiyle gönderin. Uçtan uca şifreleme gerekiyorsa ve security.txt içinde henüz yayımlanmış bir OpenPGP anahtarı listelenmiyorsa, bunun yerine GitHub Security Advisory kanalını kullanın.

Herkese açık konular, herkese açık posta listeleri, sosyal medya veya sohbet aracılığıyla bildirimde bulunmayın. Düzeltme yayımlanmadan önce kamuya açıklama yapmak, yama uygulanmamış sürümlerdeki kullanıcıları riske atar.

Kod örneği — Üretim

Geçerli değil.

Uç durumlar ve püf noktaları

• Hedefler taahhütlerdir; hizmet düzeyi sözleşmeleri (SLA) değildir. Aşağıdaki zaman çizelgesi, projenin ne yapmayı hedeflediğini belirtir. Çok bileşenli karmaşık bir sorun veya yukarı akış eşgüdümü gerektiren bir sorun daha uzun sürebilir; proje, bildireni bilgilendirir.
• Ambargo süresi, bir üst sınırla birlikte müzakere edilebilir. Varsayılan ambargo, ele alma aşamasından düzeltmenin yayımlanmasına kadar sürer. Daha uzun bir süreye ihtiyacınız varsa, uyarıyı açtığınızda bunu açıkça talep edin. Azami sürenin ardından proje, sektörün eşgüdümlü bildirim normlarına uygun olarak, bir düzeltme mevcut olsun ya da olmasın uyarıyı yayımlar. Bu, kullanıcıları süresiz olarak bekletilen bir uyarıdan korur.
• Zamanlamayı önem derecesi belirler. Kritik, etkin biçimde istismar edilen bir sorun sıkıştırılmış bir zaman çizelgesinde ele alınır; düşük önem dereceli bir sağlamlaştırma önerisi ise ele alınmaz. Önem derecesi ele alma sırasında değerlendirilir ve yeniden gözden geçirilebilir.
• Common Vulnerabilities and Exposures (CVE) eşgüdümü, ele almanın bir parçasıdır. Bakımcı, ele alma sürecinin bir parçası olarak projenin GitHub Security Advisory CVE Numaralandırma Yetkilisi (CNA) kaydı üzerinden bir CVE talep eder; bildirenin ayrıca bir CVE talep etmesi gerekmez.

Performans

Geçerli değil.

Güvenlik notları

Yanıt zaman çizelgesi hedefleri, bildirenlere yönelik taahhütlerdir ve projenin güvenlik açığı ele alma sürecinin temelini oluşturur. Bunlar hedeflerdir; garanti değildir:

Aşama	Hedef
Alındının bildirilmesi	1–2 iş günü içinde
İlk ele alma + önem derecesi değerlendirmesi	~5 iş günü / 7 takvim günü içinde
Yama geliştirme + özel inceleme	genellikle 14 iş günü; karmaşık doğrulanmış CVE’ler için önem derecesine bağlı olarak 30–90 gün
CVE ataması (kabul edilirse)	yamayla eşzamanlı, GitHub CNA kanalı üzerinden
Eşgüdümlü kamuya açıklama	yama yayımlandığında, bildirenle birlikte belirlenen bir tarihte
Ambargo (ele alma aşamasından yayıma kadar)	varsayılan ~90 gün, etkin istismar altında kısaltılır, açık talep üzerine sabit bir azami süreye kadar uzatılabilir

İnceleyenler şu süreç kurallarını denetleyebilir:

1. Önce gizlilik. Bildirim alımı için hiçbir herkese açık kanal kabul edilmez. Kabul edilen kanallar yalnızca GitHub Security Advisory ve güvenlik e-postasıdır.
2. Eşgüdümlü, tek taraflı değil. Bildirim zamanlaması, bildirenle ve birlikte etkilenen satıcılarla müzakere edilir (iso_iec_29147#x3.x110.p13).
3. Sınırlı ambargo. Ambargonun varsayılan bir süresi ve katı bir üst sınırı vardır; proje, bir uyarıyı süresiz olarak bekletmez.
4. Talep üzerine teşekkür. Araştırmacılar, anonimlik talep etmedikleri sürece ambargo kalktıktan sonra teşekkürle anılır.

Bu ifadeler, projenin izlemeyi taahhüt ettiği süreci tanımlar. Belirli bir bildirimin bir düzeltme, bir CVE veya belirli bir tarihte bir açıklamayla sonuçlanacağını garanti etmezler.

Uygunluk

Bu bir uygunluk profili değildir. Politika, ISO/IEC 29147, ISO/IEC 30111 ve yukarıda anılan CRA ve SSDF süreç görevleriyle uyumludur; “ile uyumlu” ifadesi bilinçli bir tercihtir. Proje, bu şemaların hiçbiri kapsamında sertifikasyon iddiasında bulunmaz. Bunlar sağlam bir süreci tanımlar; bu sayfa, projenin böyle bir süreci işletme taahhüdünü belgeler.

Ayrıca bkz.

• Güven merkezi
• Motor tehdit modeli
• İmza ve şifreleme güvenlik modeli
• Depodaki SECURITY.md ve /.well-known/security.txt (RFC 9116)