Perintah dan konteks
Anda mengelola platform developer untuk banyak repositori. Tim keamanan menginginkan setiap pull request menampilkan dependensi yang ditambahkan, diperbarui, dan dihapus beserta dampak kerentanannya, serta memblokir merge ketika paket berisiko tinggi ditemukan. Tim rekayasa (engineering) mengkhawatirkan positif palsu, konflik lisensi, dan waktu tunggu yang lebih lama. Asumsikan platform dapat membaca manifes dan lockfile, serta Anda memiliki waktu empat minggu untuk uji coba (pilot). Tujuannya adalah mengurangi risiko dependensi yang masuk ke lingkungan produksi tanpa memperlambat pengiriman perangkat lunak.
Apa yang dievaluasi oleh pewawancara
Pewawancara menginginkan hasil yang terukur: dependensi berisiko tinggi yang masuk ke produksi, waktu remediasi, tingkat pemblokiran gerbang, tingkat positif palsu, dan p95 waktu tunggu developer. Jawaban yang kuat memisahkan antara visibilitas (komentar atau laporan) dan penegakan (memblokir merge), kemudian menerapkan kebijakan secara bertahap berdasarkan risiko repositori dan cakupan ekosistem, alih-alih menerapkan satu aturan yang sama di semua tempat.
Klarifikasi yang perlu ditanyakan terlebih dahulu
- Tingkat keparahan kerentanan atau kewajiban lisensi mana yang wajib diblokir? Kewajiban hukum mungkin memerlukan penanganan yang lebih ketat daripada faktor eksploitabilitas saja.
- Ekosistem dan lockfile mana saja yang tercakup? Repositori yang tidak di-parse tidak dapat diasumsikan aman.
- Siapa yang bertanggung jawab atas remediasi dan SLA? Tanpa kepemilikan yang jelas, gerbang peninjauan hanya akan menumpuk pengecualian.
- Bagaimana jalur rilis darurat? Diperlukan dispensasi sementara (waiver) yang dapat diaudit beserta batas kedaluwarsa.
- Apakah tujuannya adalah penemuan (discovery), penegakan (enforcement), atau keduanya? Jika positif palsu tinggi, mulailah dengan mode laporan saja (report-only).
Kerangka jawaban 30 detik
“Saya akan menetapkan baseline untuk perubahan dependensi berisiko tinggi, waktu remediasi median dan p95, pemblokiran gerbang, serta waiver. Kemudian saya akan melakukan uji coba pada repositori berisiko tinggi yang memiliki graf dependensi lengkap dan pemeriksaan yang stabil: laporkan terlebih dahulu, blokir temuan kritis, lalu evaluasi temuan berisiko tinggi berikutnya. Keberhasilan harus mencakup penurunan risiko dan batasan pengamanan (guardrails) pengiriman. Jika positif palsu atau waktu tunggu melebihi batas, saya akan kembali ke mode laporan saja dan memperbaiki aturannya.”
Jawaban mendalam langkah demi langkah
- Segmentasi risiko. Klasifikasikan repositori berdasarkan eksploitabilitas, paparan produksi, sensitivitas data, dan kewajiban lisensi; jangan hanya memberi peringkat berdasarkan skor kerentanan.
- Validasi data. Periksa apakah manifes, lockfile, dan pengiriman dependensi berhasil di-parse. Tandai ekosistem yang tidak didukung sebagai tidak diketahui (unknown), bukan aman.
- Rancang kebijakan. Berikan komentar pada repositori berisiko rendah; blokir temuan kritis pada repositori berisiko tinggi; gunakan daftar izin atau tolak SPDX yang eksplisit untuk lisensi dan pertahankan tinjauan manual oleh manusia.
- Tentukan metrik. Metrik utama adalah laju dependensi berisiko tinggi yang masuk ke produksi dan p95 remediasi. Batasan pengaman mencakup tingkat pemblokiran, tingkat positif palsu, p95 waktu tunggu build, tingkat waiver, dan jam kerja tim keamanan.
- Luncurkan secara bertahap. Mulailah dengan 10% repositori berisiko tinggi. Catat kecocokan aturan, hasil remediasi, alasan waiver, dan masa kedaluwarsa. Bandingkan setiap ekosistem secara terpisah agar nilai rata-rata tidak menyembunyikan celah yang ada.
- Rilis dan rollback. Perluas cakupan melalui rangkaian aturan organisasi dan buat versi untuk setiap perubahan kebijakan. Jika tingkat pemblokiran atau waktu tunggu melanggar batasan pengaman, beralihlah ke mode laporan saja daripada membiasakan tim untuk melewati pemeriksaan.
Alternatif lainnya mencakup pemblokiran hanya pada branch rilis, pemindaian harian, ambang batas terpisah untuk dependensi runtime dan development, atau memperbaiki cakupan lockfile terlebih dahulu. Jika masalah utamanya adalah inventaris yang hilang, melengkapi graf dependensi jauh lebih berharga daripada penegakan pemblokiran yang lebih ketat.
Contoh jawaban model
“Saya akan memperlakukan ini sebagai produk pengendalian risiko. Pada minggu pertama, saya akan mengukur empat baseline: dependensi berisiko tinggi yang masuk ke produksi, p95 dari penemuan hingga remediasi, tingkat pemblokiran pemeriksaan dependensi, dan tingkat waiver manual. Pada minggu kedua, saya akan menguji coba mode laporan saja pada repositori berisiko tinggi yang memiliki graf lengkap dan pemilik keamanan yang ditunjuk. Pada minggu ketiga, saya hanya akan memblokir temuan kritis, menggunakan aturan lisensi SPDX yang eksplisit, serta mewajibkan alasan dan masa kedaluwarsa untuk setiap waiver. Saya menargetkan pengurangan 40% pada dependensi baru berisiko tinggi, tidak ada peningkatan pada p95 remediasi, tingkat pemblokiran di bawah 5%, dan pertumbuhan p95 waktu tunggu build di bawah 10%. Jika lebih dari 2% dependensi tidak dapat di-parse, saya akan menghentikan ekspansi dan memperbaiki inventaris; jika waiver darurat melebihi 10%, berarti kebijakan atau model kepemilikannya salah.”
Kesalahan umum
- Kesalahan: Langsung memblokir setiap kerentanan → Mengapa gagal: Tingkat keparahan, eksploitabilitas, dan paparan produksi tidak disegmentasi → Solusi: Laporkan terlebih dahulu dan tegakkan aturan berdasarkan risiko repositori.
- Kesalahan: Mengoptimalkan jumlah temuan pemindaian → Mengapa gagal: Banyaknya temuan tidak membuktikan adanya pengurangan risiko → Solusi: Lacak tingkat masuk ke produksi dan latensi remediasi.
- Kesalahan: Mengabaikan lockfile dan cakupan ekosistem → Mengapa gagal: Dependensi yang tidak di-parse menciptakan rasa aman yang palsu → Solusi: Jadikan cakupan sebagai prasyarat dan tandai hal-hal yang tidak diketahui.
- Kesalahan: Mengizinkan waiver permanen → Mengapa gagal: Gerbang keamanan perlahan kehilangan wibawa dan otoritasnya → Solusi: Wajibkan alasan, pemilik yang bertanggung jawab, dan masa kedaluwarsa.
Pertanyaan lanjutan dan jawabannya
Haruskah kita menonaktifkan gerbang saat developer mengajukan keberatan atas positif palsu?
Pisahkan positif palsu berdasarkan aturan, ekosistem, dan tingkat keparahan, serta pertahankan mode laporan saja selagi mengumpulkan bukti. Kembalilah ke penegakan mode laporan saja hanya jika positif palsu tidak dapat ditekan sesuai target SLA; perbaikan aturan harus menjadi kriteria keluar (exit criterion).
Bagaimana jika kerentanan kritis tidak memiliki versi perbaikan?
Nyatakan kondisi “tidak ada perbaikan yang tersedia” (no fix available) secara eksplisit. Wajibkan pemilik keamanan untuk menyetujui waiver sementara, kontrol kompensasi, dan tanggal peninjauan kembali; jangan pernah mengubah pemindaian yang gagal menjadi lulus.
Bagaimana Anda membuktikan bahwa kebijakan ini tidak memperlambat pengiriman?
Bandingkan p95 waktu tunggu sebelum dan selama masa uji coba, throughput merge, dan tingkat rollback berdasarkan repositori serta jenis perubahan, sembari melaporkan tingkat waiver. Rata-rata di tingkat perusahaan dapat menyembunyikan hambatan parah yang dialami oleh tim kecil.
Kapan Anda memperluas kebijakan ini ke seluruh organisasi?
Perluas hanya setelah cakupan repositori berisiko tinggi, temuan aturan yang dapat dijelaskan, SLA remediasi, dan batasan pengaman waktu tunggu memenuhi target selama dua siklus rilis serta waiver diselesaikan tepat waktu.