Matikan Dependabot

• Notifikasi Dependabot yang berlebihan dinilai membuang waktu pengembang alih-alih membantu menyelesaikan masalah keamanan yang nyata
• Seperti pada kasus di ekosistem Go, ribuan PR dan peringatan dapat dibuat bahkan untuk repositori yang tidak terdampak, sehingga menimbulkan kebingungan
• Dengan menggunakan GitHub Action berbasis govulncheck, hanya kode yang benar-benar rentan yang dapat dideteksi dan peringatan yang tidak perlu bisa dihapus
• Pembaruan dependensi lebih aman dan efisien jika dikelola lewat pengujian berkala dan verifikasi versi terbaru daripada PR otomatis
• Pendekatan ini penting untuk mengurangi kelelahan peringatan (alert fatigue) dan meringankan beban para maintainer open source

---

Masalah Dependabot

• Dependabot menghasilkan peringatan keamanan dan PR otomatis dalam jumlah besar, sehingga pengembang sulit membedakan masalah yang benar-benar penting
  • Bahkan perubahan kecil pada paket Go filippo.io/edwards25519 menghasilkan ribuan PR
  • Peringatan keamanan yang keliru juga dikirim ke repositori yang tidak terdampak (seperti Wycheproof)
• Peringatan tersebut mencakup skor CVSS yang keliru dan indikator kompatibilitas yang rendah, sehingga memicu kecemasan yang tidak perlu
• Notifikasi yang berlebihan seperti ini disebut menurunkan keandalan dan efisiensi respons keamanan

Alternatif dengan govulncheck

• Go Vulnerability Database menyediakan metadata terperinci pada tingkat versi, paket, dan simbol
  • Sebagai contoh, kerentanan GO-2026-4503 hanya memengaruhi simbol Point.MultiScalarMult
• govulncheck menggunakan analisis statis untuk mendeteksi hanya kode rentan yang benar-benar bisa dipanggil
  • Jika digunakan bersama go mod why, dampak dependensi tidak langsung dapat dinilai secara akurat
  • Hasil pemeriksaan tidak akan memberi peringatan jika kerentanan ada tetapi kode tidak memanggil simbol tersebut
• Dapat diintegrasikan dengan mudah melalui CLI (govulncheck -json) atau Go API (golang.org/x/vuln/scan)

Pengganti lewat GitHub Actions

• Sebagai pengganti Dependabot, GitHub Action govulncheck dapat dikonfigurasi untuk menjalankan pemeriksaan otomatis setiap hari
  • Notifikasi hanya dikirim ketika kerentanan nyata ditemukan
  • Karena tidak membuat PR otomatis, pengembang dapat fokus pada isu keamanan yang penting
• Mengurangi peringatan keliru juga membantu meredakan kelelahan peringatan keamanan (alert fatigue) dan meningkatkan kualitas respons
• Masalah pengiriman PR yang tidak perlu kepada maintainer open source juga dapat diatasi

Cara mengelola pembaruan dependensi

• Dependensi perlu dikelola secara terjadwal sesuai siklus pengembangan masing-masing proyek
  • Uji terhadap versi terbaru setiap hari, tetapi lakukan pembaruan nyata hanya saat memang dibutuhkan
  • Di Go, versi terbaru dapat diuji dengan go get -u -t ./..., dan di npm dengan perintah npm update
• Pendekatan ini menjaga kecepatan respons terhadap kerentanan keamanan sekaligus stabilitas
  • Pengujian pada versi terbaru membantu menemukan masalah kompatibilitas lebih awal
  • Juga mencegah dependensi yang mengandung kode berbahaya langsung diterapkan ke produksi
• Dengan geomys/sandboxed-step, eksekusi terisolasi dengan gVisor juga dimungkinkan di lingkungan CI

Kesimpulan dan latar dukungan

• Otomatisasi Dependabot sering kali menimbulkan noise lebih besar daripada manfaat keamanan
• Pendekatan berbasis govulncheck dan pengujian berkala adalah cara pengelolaan keamanan yang lebih akurat dan berkelanjutan
• Pemeliharaan open source oleh penulis didukung melalui organisasi Geomys dengan sponsor dari Ava Labs, Teleport, Tailscale, Sentry, dan lainnya
• Model seperti ini berkontribusi pada pemeliharaan ekosistem open source yang stabil dan peningkatan kualitas keamanan

[GN⁺]

Komentar Hacker News

• Dependabot memang punya nilai sampai batas tertentu
  Tetapi alat yang hanya membandingkan nomor versi dan DB kerentanan tidak bisa menentukan apakah kode sebenarnya terekspos pada kerentanan tersebut, jadi banyak noise
  Alat yang baru-baru ini paling mengesankan bagiku adalah CodeQL. Bisa dijalankan di GitHub Advanced Security, dan melacak alur nyata kode untuk menunjukkan seluruh jalur secara visual dari input hingga penggunaan yang berisiko
  Hasilnya, informasi yang diberikan benar-benar bisa ditindaklanjuti untuk perbaikan, dan false positive-nya sedikit. Tentu saja pada bahasa dinamis seperti Python masih ada kode yang bisa lolos dari deteksi, tetapi dalam kebanyakan kasus tetap sangat berguna
  • Dulu CodeQL membantu proyek kami, tetapi belakangan sudah sampai tingkat yang sangat menjengkelkan sehingga tim mematikannya
    Muncul komentar seperti menambahkan variabel perantara yang tidak berguna hanya untuk menghindari peringatan CodeQL. Rasanya seperti alat yang overfit terhadap data
  • Sulit setuju dengan pernyataan bahwa “hampir tidak ada false positive”. Menurut teorema Rice, analisis sesempurna itu mustahil
  • Dalam pengalamanku, CodeQL punya banyak false positive, dan tidak ada cara mudah untuk menjalankannya secara lokal sehingga menimbulkan vendor lock-in
  • Menaikkan versi dependensi tidak menjamin keamanan membaik. Versi baru juga bisa membawa kerentanan baru
• Di paket NPM, peringatan ReDoS muncul terlalu banyak. Sebagian besar adalah paket yang hanya dipakai di kode klien, tetapi terlalu banyak peringatan yang tidak relevan dengan backend. ReDoS sisi klien tidak berarti bagi kami
  • Sebenarnya aku menganggap DoS bukan kerentanan keamanan melainkan masalah ketersediaan. Memang itu salah satu unsur CIA dalam keamanan, tetapi dalam praktiknya lebih dekat ke isu operasional. Mengklasifikasikan DoS sebagai masalah keamanan hanyalah artefak sejarah
  • Aku sedang memelihara paket debug, dan ada terlalu banyak laporan ReDoS yang ngawur. Bahkan ada yang sampai didaftarkan sebagai CVE, sampai rasanya ingin meninggalkan ekosistem JS
  • Kami mengalami masalah serupa di alat AI code review. Padahal alat itu berjalan secara lokal dengan hak akses pengguna, tetapi tetap menyuruh untuk mensanitize input yang sebenarnya tidak perlu. Akhirnya cuma buang-buang waktu
  • Kami juga mengalami masalah yang sama. Terutama peringatan ReDoS dari dev dependency yang menciptakan kebisingan yang tidak perlu
  • ReDoS adalah bug pada regex engine, tetapi engine seperti V8 masih belum menyediakan regex engine yang aman secara default
• Govulncheck adalah salah satu fitur terbaik di ekosistem Go
  Kami memakai GitHub Action yang memberi notifikasi jika ada pemanggilan rentan yang ditambahkan di PR.
  Jika dipakai bersama auto-merge Dependabot, ini juga kombinasi yang lumayan untuk mengelola codebase JS
  • Govulncheck juga tidak sempurna. Ada false positive, dan tidak ada cara untuk mengecualikan kerentanan tertentu berdasarkan nomor CVE
• Dependabot berguna, tetapi sekaligus mengingatkan setiap hari tentang pentingnya meminimalkan dependensi
  • Aku juga memulai hari dengan menangani PR Dependabot setiap pagi.
    Jika pengujian cukup memadai, kadang kita menemukan bug di versi baru, tetapi proses itu juga bisa berujung pada kontribusi open source. Memang merepotkan, tetapi membentuk kebiasaan yang baik
  • Aku juga setuju. Proyekku memang tidak banyak, tetapi Dependabot cukup berguna
• Akan bagus kalau Dependabot dikelola dalam bentuk tab di dalam repositori alih-alih lewat email.
  Notifikasi email itu mengganggu, dan aku juga tidak suka PR menumpuk. Aku ingin menanganinya secara terfokus hanya pada waktu tertentu
  • Dengan konfigurasi dependabot.yml, kamu bisa mengatur frekuensi eksekusi dan jumlah PR
    Lihat dokumentasi resmi
  • Kamu juga bisa mematikan PR otomatis dan membuatnya secara manual hanya saat diperlukan.
    Memperbaikinya langsung sambil mengurangi jumlah issue juga memungkinkan
  • Jika memakai ekstensi Refined GitHub, tampilan default jadi sedikit lebih rapi.
    Secara pribadi aku merekomendasikan Renovate. Dukungan bahasanya lebih banyak dan opsi auto-merge-nya lebih lengkap
• Pendekatan govulncheck di Go, yaitu melacak jalur pemanggilan yang benar-benar terjadi, seharusnya menjadi standar default di semua ekosistem
  Masalah mendasar Dependabot adalah ia mengira manajemen dependensi itu masalah keamanan.
  Kerentanan pada fungsi yang tidak pernah dipanggil bukan isu keamanan, melainkan noise
  Di Python, pip-audit --desc terasa lebih baik daripada Dependabot.
  Sampai ada analisis statis yang benar-benar sempurna, mungkin pemeriksaan manual per kuartal justru lebih aman
  • Tetapi ketika pelanggan memindai kode dengan alat seperti ini, mereka tidak percaya pada jawaban “fungsi itu tidak kami gunakan”.
    Di sinilah muncul kesenjangan antara keamanan yang nyata dan praktik keamanan
  • Pertanyaan “kalau tidak dipakai, kenapa fungsi itu masih ada di kode?” juga masuk akal
• Aku tidak mengerti kenapa industri menerima pemindai keamanan yang dangkal seperti ini
  Sebagian besar CVE sebenarnya tidak berdampak nyata, tetapi perusahaan tetap berusaha membuat jumlah kerentanan pada container image menjadi 0
  Selain itu, saat dependensi diperbarui, CVE baru pasti akan muncul. Ini karena sebagian besar software tidak melakukan backport patch
  • Aku kurang paham bagaimana bagian “tidak melakukan backport” terhubung dengan kalimat sebelumnya
• Kelebihan Dependabot maupun Renovate adalah keduanya bekerja lintas bahasa
  Semakin banyak repositori dan semakin beragam bahasanya, semakin tidak realistis untuk menambahkan workflow CI yang sempurna
  Walau tidak sempurna, menurutku itu jauh lebih baik daripada tidak melakukan apa-apa
• Aku penasaran skor CVSS di Dependabot itu berasal dari mana.
  Apakah CVE dibuat secara otomatis?
  • CVSS adalah skor dengan asumsi skenario terburuk, jadi tidak mencerminkan tingkat risiko nyata.
    DB kerentanan GitHub lebih fokus pada kuantitas daripada kualitas, dan Dependabot bekerja seperti mesin spam notifikasi tanpa kecerdasan
  • Bahkan apakah bug itu benar-benar kerentanan pun masih meragukan.
    Jika masalah hanya muncul ketika fungsi dipanggil dengan cara yang salah, kemungkinan besar kodenya sejak awal memang tidak akan bekerja
• Perusahaan kami juga mengalami masalah serupa.
  Pemindaian container image GCP membanjiri Vanta dengan banyak peringatan CVE, padahal sebagian besar tidak bisa diperbaiki atau sebenarnya berada di jalur yang tidak dipakai
  Aku penasaran apakah ada alat yang bisa melakukan penyaringan berbasis konteks seperti ini
  • Di perusahaan kami, kami memakai Aikido Code. Mereka mencoba memfilter dampak nyata kerentanan dengan AI.
    Hasilnya cukup positif, tetapi dengan codebase yang besar dan banyak dependensi, tetap sulit untuk mengurangi jumlah CVE