GitHub memperkenalkan reachability analysis untuk peringatan Dependabot dalam public preview pada 28 Oktober 2026. Fitur ini membantu tim pengembang menilai apakah kode aplikasi mempunyai jalur pemanggilan menuju fungsi rentan di paket dependensi. Selama ini, daftar kerentanan dapat menumpuk karena keberadaan paket bermasalah belum tentu berarti bagian rentannya dipakai oleh aplikasi. Analisis keterjangkauan memberikan konteks tambahan agar tim dapat menentukan urutan penanganan. Meski begitu, GitHub menekankan hasilnya harus dibaca bersama tingkat keparahan, skor EPSS, konteks produksi, dan pemahaman pengembang atas aplikasinya sendiri, bukan diperlakukan sebagai jaminan keamanan otomatis.
Bagaimana cara kerja analisis keterjangkauan?
GitHub menjalankan analisis lewat workflow GitHub Actions yang dikelola oleh layanan, sehingga pengguna preview tidak perlu memasang atau merawat pipeline sendiri. Untuk setiap advisory, sistem memanfaatkan data terkurasi mengenai fungsi yang rentan dalam paket terdampak. CodeQL kemudian menyusun call graph di seluruh repositori dan dependensinya, lalu mencari apakah ada jalur dari kode aplikasi menuju fungsi tersebut. Bukti jalur pemanggilan ditampilkan pada peringatan Dependabot. Ini memberi konteks yang lebih spesifik dibanding hanya melihat nama pustaka dan nomor versinya, tetapi tetap bergantung pada cakupan analisis dan karakteristik kode yang dapat dibaca alat.
Empat kemungkinan hasil yang perlu dipahami
Setiap peringatan terbuka bisa memperoleh salah satu dari empat verdict. Reachable berarti ditemukan setidaknya satu jalur pemanggilan ke fungsi rentan. Potentially reachable berarti alat belum dapat memastikan apakah fungsi itu dipanggil, sehingga GitHub menyarankan memperlakukannya seperti reachable. Unreachable berarti analisis selesai tanpa menemukan jalur, sehingga prioritasnya dapat lebih rendah. Reachability unavailable berarti peringatan tidak dapat dianalisis dan harus ditangani dengan prosedur triase biasa. Hasil ini tidak otomatis menutup atau mengabaikan peringatan. Tim tetap bertanggung jawab menentukan tindakan perbaikan dan memastikan tidak ada konteks penting yang terlewat.
Siapa yang bisa mencoba dan apa syaratnya?
Selama preview, fitur tersedia untuk GitHub Enterprise Cloud, termasuk varian data residency. Bahasa yang didukung adalah JavaScript dan TypeScript dengan lockfile npm, Yarn, atau pnpm di repositori. Analisis berjalan pada runner yang dihosting GitHub; self-hosted runner belum didukung. GitHub menyatakan fitur preview ini gratis, tidak memerlukan lisensi GitHub Advanced Security, dan menit Actions untuk analisisnya tidak ditagihkan. Namun, dukungan pada monorepo tertentu atau repositori dengan manifest di banyak direktori masih terbatas. Jika analisis melebihi tiga jam, sebagian hasil dapat berstatus unavailable.
Cara mengaktifkan dan membaca hasilnya
Reachability analysis tidak aktif secara bawaan. Administrator dapat menyalakannya melalui konfigurasi keamanan khusus pada organisasi atau enterprise, atau untuk satu repositori melalui bagian Dependabot di Settings dan Advanced Security. Dependabot alerts harus aktif agar verdict terlihat. Pemindaian pertama dimulai setelah pengaktifan dan dapat memerlukan beberapa menit hingga beberapa jam. Selanjutnya, GitHub menyatakan pemindaian diulang setiap hari selama masih ada peringatan terbuka. Tim dapat menyaring dan mengurutkan peringatan menurut verdict, termasuk mengakses sinyal yang sama melalui REST API Dependabot untuk integrasi internal.
Mengapa label unreachable tidak berarti aman selamanya?
Perubahan kode, versi dependensi, dan cakupan advisory dapat mengubah kesimpulan. Karena itu, label unreachable sebaiknya dipakai untuk menyusun prioritas, bukan alasan permanen mengabaikan pembaruan. Potensi eksploitasi juga dapat dipengaruhi oleh konfigurasi, paparan jaringan, dan kondisi produksi yang tidak seluruhnya tercermin dalam call graph. Tim keamanan perlu mempertahankan kebijakan patch, pengujian, dan pemantauan meskipun alat analisis makin canggih. Pengumuman GitHub ini menawarkan cara baru untuk mengurangi kebisingan peringatan, bukan menggantikan penilaian risiko manusia. Sebelum mengaktifkan preview pada banyak repositori, tim juga sebaiknya menetapkan pemilik triase, tenggat perbaikan, dan cara menangani hasil yang tidak dapat dianalisis. Langkah tersebut mencegah verdict baru justru menjadi daftar tugas tambahan tanpa penanggung jawab.
Sumber primer: Pengumuman resmi (tanggal terbit/pembaruan sebagaimana dijelaskan di atas). Foto ilustrasi kode program: Chris Ried/Unsplash; bukan tangkapan layar fitur GitHub.
