Konteks dan cakupan
Pertanyaan wawancara umum ini menguji apakah Anda dapat menempatkan file publik kecil ke dalam alur kerja operasi keamanan yang lengkap. Intinya bukan menghafal field; melainkan menghubungkan titik masuk pelaporan, batas otorisasi, kepemilikan respons, dan janji-janji kebijakan.
Hal yang dinilai oleh pewawancara
- Apakah Anda mengetahui lokasi
/.well-known/security.txtdan field wajib menurut RFC 9116. - Apakah Anda dapat membedakan antara penemuan (discovery), validasi, pengungkapan terkoordinasi (coordinated disclosure), dan respons darurat.
- Apakah Anda menghindari penerbitan kotak surat yang tidak dipantau, kunci privat, atau janji waktu respons tanpa penanggung jawab yang jelas.
- Apakah Anda dapat merancang kepemilikan on-call, tiket, deduplikasi, dan pembaruan status yang membuat titik masuk berfungsi dengan baik.
Pertanyaan klarifikasi yang perlu diajukan
Pertama, konfirmasikan domain dan produk mana saja yang masuk dalam cakupan, apakah beberapa tim memiliki aset tersebut, apakah aset yang dihosting pihak ketiga diterima, siapa yang bertugas on-call untuk setiap saluran, pengujian apa saja yang diotorisasi, dan apakah kebijakan pengungkapan kerentanan sudah ada. Klarifikasi juga apakah tujuannya hanya kemudahan penemuan atau juga mencakup hadiah (bounty), pengiriman terenkripsi, dan tanggal pengungkapan terkoordinasi.
Kerangka jawaban 30 detik
Saya akan menerbitkan file teks polos UTF-8 di /.well-known/security.txt melalui HTTPS untuk setiap aset publik. Saya akan mempertahankan Contact yang valid dan Expires di masa mendatang, lalu menambahkan Policy, Canonical, Encryption, atau Acknowledgments hanya jika proses-proses tersebut benar-benar ada. File ini hanya membantu peneliti menemukan titik masuk; backend tetap memerlukan cakupan otorisasi, kepemilikan on-call, tiket, deduplikasi, penilaian tingkat keparahan, dan komunikasi status yang aman. Sebelum peluncuran, saya akan memverifikasi HTTPS, masa kedaluwarsa, izin tautan, dan rotasi penanggung jawab.
Solusi langkah demi langkah
1. Tentukan batas aset dan titik masuk
Buat daftar domain utama, domain produk, dan API berisiko tinggi yang memerlukan cakupan daripada hanya menempatkan satu file di beranda pemasaran. Contact harus mengarah ke kotak surat atau formulir HTTPS yang benar-benar dapat memproses laporan; kotak surat pribadi yang tidak dipantau tidak boleh menjadi satu-satunya jalur. Jika tim yang berbeda memiliki aset-aset tersebut, dokumentasikan bagaimana laporan dirutekan.
2. Isi dan validasi field RFC 9116 secara berkelanjutan
Contact dan Expires bersifat wajib; Expires harus menyatakan waktu kedaluwarsa di masa mendatang. Policy dapat menautkan ke aturan pengujian dan pengungkapan yang diotorisasi, Canonical dapat mengidentifikasi file kanonikal, Encryption hanya disertakan jika kunci publik yang terawat memang ada, dan Acknowledgments atau Hiring bersifat opsional. Sajikan file pada HTTPS /.well-known/security.txt sebagai text/plain, tanpa bergantung pada rendering HTML.
3. Hubungkan file ke alur kerja respons
Saat laporan masuk, buat pengidentifikasi tiket yang tidak dapat diprediksi dan catat waktu penerimaan, aset, langkah reproduksi, serta preferensi komunikasi peneliti. Petugas on-call pertama-tama memeriksa cakupan otorisasi, kemudian melakukan deduplikasi, menilai dampak, dan menetapkan penanggung jawab. Laporan berisiko tinggi masuk ke jalur darurat; laporan normal menggunakan antrean reguler, dengan jejak audit untuk keduanya.
4. Tulis kebijakan pengungkapan daripada mengarang SLA
Kebijakan harus menjelaskan penelitian yang diizinkan, perilaku yang dilarang, transfer materi sensitif yang aman, hadiah jika ada, kapan pengungkapan publik diizinkan, dan bagaimana pengujian dengan itikad baik (good-faith testing) ditangani. Cantumkan hanya waktu konfirmasi penerimaan dan ritme pembaruan yang dapat dipenuhi secara berkelanjutan dalam bentuk tertulis. Jangan menafsirkan field RFC sebagai janji bahwa setiap laporan akan diperbaiki dalam jumlah jam tertentu.
5. Lindungi titik masuk dan data laporan
File publik tidak boleh memuat kunci privat, nama host internal, nomor telepon pribadi, atau detail insiden yang belum dipublikasikan. Batasi jenis dan ukuran lampiran, batasi akses ke sistem surat dan tiket, serta perlakukan skrip dan tautan dalam laporan mentah sebagai input yang tidak tepercaya. Tim keamanan dapat menyimpan konteks internal yang lebih lengkap, sementara balasan kepada pelapor hanya mengungkapkan fakta-fakta yang telah disetujui.
6. Buktikan bahwa titik masuk berfungsi dengan observabilitas
Pantau respons 200 file, sertifikat HTTPS, sisa waktu menuju Expires, rotasi on-call, dan konversi formulir ke tiket. Gunakan laporan pengujian yang tidak berbahaya untuk memverifikasi peringatan, deduplikasi, dan eskalasi; jangan pernah menggunakan kerentanan nyata untuk latihan simulasi. Pastikan CDN, pengalihan (redirect), dan penerapan multi-wilayah tidak menyajikan salinan yang usang atau kedaluwarsa.
Contoh jawaban berkualitas tinggi
Pertama, saya akan mendaftar domain publik yang membutuhkan cakupan dan menerbitkan file teks polos UTF-8 di HTTPS /.well-known/security.txt untuk masing-masing domain. Contact akan mengarah ke kotak surat atau formulir yang dikelola staf, sementara Expires akan diatur di masa mendatang dan dipantau oleh peringatan kedaluwarsa. Saya akan menambahkan Policy, Canonical, atau Encryption hanya jika proses dan kunci tersebut dipelihara. File tersebut tidak akan menjanjikan batas waktu perbaikan; kebijakan akan menyatakan cakupan yang diotorisasi, perilaku yang dilarang, transfer materi sensitif, hadiah, dan pengungkapan terkoordinasi. Laporan akan masuk ke sistem tiket dengan akses terbatas untuk pemeriksaan cakupan, deduplikasi, penilaian keparahan, dan kepemilikan, dengan jalur darurat untuk kasus-kasus berisiko tinggi. Saya akan memverifikasi HTTPS, caching, izin, cakupan on-call, dan pembaruan berkala sebelum peluncuran, lalu memantau keterjangkauan, konversi tiket, dan status respons. File tersebut membuat saluran mudah ditemukan; alur kerja dan kepemilikan menyediakan kapabilitas keamanannya.
Kesalahan umum
- Membuat file tanpa penanggung jawab on-call, antrean tiket, atau jalur eskalasi.
- Menghilangkan
Expires, sehingga peneliti mendapatkan informasi kontak yang mungkin sudah tidak berfungsi. - Menerbitkan kunci privat, alamat internal, atau nomor telepon pribadi.
- Menjanjikan SLA perbaikan, jumlah hadiah, atau tanggal pengungkapan yang tidak dapat ditepati tim.
- Mengganti titik masuk HTTPS yang stabil dengan HTTP, pengalihan login, atau salinan CDN yang usang.
- Memublikasikan detail reproduksi sebelum otorisasi dan dampaknya diverifikasi.
Pertanyaan lanjutan dan tanggapan
Bisakah security.txt menggantikan kebijakan pengungkapan kerentanan?
Tidak. File ini membantu peneliti menemukan tautan Contact dan Policy; cakupan otorisasi, pengujian dengan itikad baik, hadiah, koordinasi pengungkapan, dan aturan darurat tetap merupakan bagian dari kebijakan.
Mengapa Expires diperlukan?
Kontak dan proses dapat berubah. Expires memungkinkan pemeriksaan otomatis mengidentifikasi file yang mungkin sudah usang sehingga tim memperbaruinya, alih-alih membiarkan kotak surat lama tampak valid tanpa batas waktu.
Bagaimana jika suatu grup memiliki banyak domain produk?
Terbitkan file yang sesuai untuk setiap domain yang dimiliki secara independen dan gunakan tautan Canonical atau kebijakan untuk menjelaskan sumber yang otoritatif. Setiap titik masuk tetap harus mencapai tim yang dapat merutekan laporan; menyalin alamat yang tidak dipantau tidaklah cukup.
Apa langkah pertama setelah peneliti melaporkan dugaan zero-day?
Batasi akses ke laporan tersebut, konfirmasikan sumber dan cakupan aset, catat waktu dan bukti, serta beri tahu penanggung jawab keamanan untuk penilaian dampak darurat. Jangan meneruskan detail yang belum diverifikasi ke saluran publik atau meminta peneliti memperluas pengujian hanya untuk membuat laporan lebih lengkap.