Kebijakan pengungkapan kerentanan

Sekilas pandang

Halaman ini menetapkan kebijakan pengungkapan kerentanan terkoordinasi milik NextPDF. Halaman ini menjelaskan cara menghubungi para pengelola secara privat, target respons yang dapat diharapkan, dan cara kerja embargo.

Batasan. Kebijakan pengungkapan adalah komitmen proses, bukan jaminan jadwal maupun jaminan hasil. Target di bawah ini adalah komitmen itikad baik dari para pengelola kepada Anda sebagai pelapor; target tersebut menggambarkan proses yang diikuti oleh proyek ini, bukan janji kontraktual bahwa laporan tertentu apa pun akan diakui, ditriase, diperbaiki, atau diungkapkan pada tanggal tertentu mana pun. Penentuan waktu pengungkapan terkoordinasi dinegosiasikan, bukan dijamin secara sepihak.

Pemasangan

Tidak berlaku. Anda tidak perlu memasang apa pun untuk melaporkan kerentanan. Permukaan kontak yang dapat dibaca mesin dipublikasikan di /.well-known/security.txt (Request for Comments (RFC) 9116). Berkas SECURITY.md di repositori adalah kebijakan otoritatif yang dapat dibaca manusia.

Tinjauan konseptual

Kebijakan ini menerapkan pengungkapan kerentanan terkoordinasi sebagaimana didefinisikan oleh ISO/IEC 29147 dan proses penanganan dalam ISO/IEC 30111 (iso_iec_30111#x9.x43.p2): penerimaan laporan secara privat, triase dan penilaian tingkat keparahan, remediasi di bawah embargo, serta rilis publik bersama. Jika suatu kerentanan memengaruhi beberapa vendor, pihak-pihak yang terdampak mengoordinasikan waktu publikasi advisory alih-alih menetapkannya secara sepihak (iso_iec_29147#x3.x110.p13).

Proses ini juga selaras dengan kewajiban penanganan kerentanan produsen dalam European Union (EU) Cyber Resilience Act (CRA) (eu_cra#x1.p191) dan praktik “respond to vulnerabilities” dalam National Institute of Standards and Technology (NIST) Secure Software Development framework (SSDF) (nist_sp_800_218#x15). Keduanya menggambarkan hal ini sebagai kewajiban proses yang dapat diulang, bukan sebagai jaminan bahwa hasil tertentu apa pun akan tercapai.

Permukaan API

Tidak berlaku. Pengungkapan adalah proses, bukan application programming interface (API). Permukaan penemuan yang dapat dibaca mesin adalah berkas RFC 9116 security.txt; perkakas membaca bidang Contact: dan Expires: di dalamnya. Halaman ini tidak menduplikasi isi berkas tersebut, kecuali saluran yang tercantum di bawah ini.

Contoh kode — Mulai cepat

Tidak berlaku. Tidak ada kode yang perlu dijalankan saat Anda melaporkan kerentanan. Gunakan saluran privat:

• GitHub Security Advisories (lebih disukai — terenkripsi saat disimpan, memiliki log audit): buka draf advisory di tab GitHub Security proyek ini.
• Email: [email protected] dengan [SECURITY] pada subjek. Jika Anda memerlukan enkripsi ujung ke ujung dan belum ada kunci OpenPGP yang dipublikasikan dalam security.txt, gunakan saluran GitHub Security Advisory sebagai gantinya.

Jangan melaporkan melalui isu publik, milis publik, media sosial, atau obrolan. Pengungkapan publik sebelum ada perbaikan membuat pengguna versi yang belum ditambal berisiko.

Contoh kode — Produksi

Tidak berlaku.

Kasus tepi & hal yang perlu diwaspadai

• Target adalah komitmen, bukan perjanjian tingkat layanan (service-level agreements, SLA). Jadwal di bawah ini menyatakan target yang ingin dicapai proyek ini. Masalah rumit yang melibatkan beberapa komponen, atau yang memerlukan koordinasi hulu, dapat memakan waktu lebih lama; proyek ini akan terus memberi pembaruan kepada pelapor.
• Lama embargo dapat dinegosiasikan, dengan batas atas. Embargo standar berlaku sejak triase hingga rilis perbaikan. Jika Anda memerlukan waktu lebih lama, mintalah secara eksplisit saat Anda membuka advisory. Setelah batas maksimum, proyek ini akan mempublikasikan advisory, baik perbaikan sudah tersedia maupun belum, sesuai dengan norma pengungkapan terkoordinasi industri. Hal ini melindungi pengguna dari advisory yang ditahan tanpa batas waktu.
• Tingkat keparahan menentukan jadwal. Masalah kritis yang aktif dieksploitasi ditangani dengan jadwal yang dipersingkat; saran pengerasan dengan tingkat keparahan rendah tidak. Tingkat keparahan dinilai selama triase dan dapat direvisi.
• Penerbitan Common Vulnerabilities and Exposures (CVE) merupakan bagian dari triase. Pengelola meminta CVE melalui pendaftaran CVE Numbering Authority (CNA) GitHub Security Advisory milik proyek ini sebagai bagian dari langkah triase; pelapor tidak perlu memintanya secara terpisah.

Performa

Tidak berlaku.

Catatan keamanan

Target jadwal respons merupakan komitmen kepada pelapor dan membentuk garis dasar penanganan kerentanan proyek ini. Semuanya adalah target, bukan jaminan:

Tahap	Target
Mengakui penerimaan	dalam 1–2 hari kerja
Triase awal + penilaian tingkat keparahan	dalam ~5 hari kerja / 7 hari kalender
Pengembangan tambalan + tinjauan privat	biasanya 14 hari kerja; 30–90 hari untuk CVE rumit yang telah dikonfirmasi, bergantung pada tingkat keparahan
Penetapan CVE (jika diterima)	bersamaan dengan tambalan, melalui saluran CNA GitHub
Pengungkapan publik terkoordinasi	pada saat rilis tambalan, pada tanggal yang ditetapkan bersama pelapor
Embargo (sejak triase hingga rilis)	standar ~90 hari, dipersingkat saat ada eksploitasi aktif, dapat diperpanjang atas permintaan eksplisit hingga batas maksimum tetap

Peninjau dapat memeriksa aturan proses berikut:

1. Privat terlebih dahulu. Tidak ada saluran publik yang diterima untuk penerimaan laporan. Satu-satunya saluran yang diterima adalah GitHub Security Advisory dan email keamanan.
2. Terkoordinasi, bukan sepihak. Penentuan waktu pengungkapan dinegosiasikan dengan pelapor dan vendor mana pun yang turut terdampak (iso_iec_29147#x3.x110.p13).
3. Embargo terbatas. Embargo memiliki nilai standar dan batas atas keras; proyek ini tidak menahan advisory tanpa batas waktu.
4. Pengakuan atas permintaan. Peneliti diberi pengakuan setelah embargo dicabut, kecuali mereka meminta anonimitas.

Pernyataan-pernyataan ini menggambarkan proses yang berkomitmen untuk diikuti oleh proyek ini. Pernyataan-pernyataan ini tidak menjamin bahwa suatu laporan tertentu akan menghasilkan perbaikan, CVE, atau pengungkapan pada tanggal tertentu.

Kesesuaian

Ini bukan profil kesesuaian. Kebijakan ini selaras dengan ISO/IEC 29147, ISO/IEC 30111, serta kewajiban proses CRA dan SSDF yang dikutip di atas; “selaras dengan” adalah pilihan kata yang disengaja. Proyek ini tidak mengklaim sertifikasi terhadap skema mana pun tersebut. Skema-skema tersebut mendefinisikan proses yang baik; halaman ini mendokumentasikan komitmen proyek ini untuk menjalankannya.

Lihat juga

• Pusat kepercayaan
• Model ancaman mesin
• Model keamanan tanda tangan dan enkripsi
• Berkas SECURITY.md repositori dan /.well-known/security.txt (RFC 9116)