Mengapa Semua Orang Harus Menggunakan Cooldown Dependensi

(blog.yossarian.net)

15 poin oleh GN⁺ 2025-11-22 | 3 komentar | Bagikan ke WhatsApp

Cooldown dependensi (dependency cooldown) adalah teknik keamanan yang sederhana dan efektif yang dapat memitigasi sebagian besar serangan rantai pasok open source
Penyerang biasanya mengambil alih proyek open source populer untuk menyebarkan kode berbahaya, tetapi pada kebanyakan serangan periode paparannya singkat, kurang dari satu minggu
Dengan menetapkan cooldown yang menunggu selama periode tertentu (misalnya 7 hari) setelah versi baru dirilis, risiko infeksi akibat pembaruan otomatis dapat dikurangi secara signifikan
Dependabot, Renovate, pnpm, dan lainnya sudah mendukung fitur cooldown secara bawaan, mudah dikonfigurasi, dan tidak memerlukan biaya tambahan
Jika cooldown disediakan secara default di tingkat package manager, hal ini dapat membantu memperkuat keamanan rantai pasok dan mengurangi alarm yang tidak perlu

Struktur dan masalah serangan rantai pasok

Sebagian besar serangan rantai pasok (supply chain attack) mengikuti pola yang sama
- Penyerang mendapatkan akses dengan memanfaatkan pencurian kredensial atau kerentanan CI/CD pada proyek open source populer
- Perubahan berbahaya diunggah ke kanal distribusi seperti PyPI, npm, dan lainnya
- Karena pembaruan otomatis atau versi yang tidak dipin dengan baik, pengguna memasang versi yang terinfeksi
- Vendor keamanan mendeteksinya, mengeluarkan peringatan, lalu repositori paket menghapus versi tersebut
Jarak waktu antara tahap (1)~(2) panjang, tetapi tahap (2)~(5) biasanya selesai dalam hitungan jam hingga beberapa hari, sehingga masa aktivitas penyerang relatif singkat
Window of opportunity untuk kasus-kasus utama dalam 18 bulan terakhir
- xz-utils: sekitar 5 minggu
- Ultralytics: 12 jam (tahap 1), 1 jam (tahap 2)
- tj-actions: 3 hari
- chalk: kurang dari 12 jam
- Nx: 4 jam
- rspack: 1 jam
- num2words: kurang dari 12 jam
- Kong Ingress Controller: sekitar 10 hari
- web3.js: 5 jam
Dari kasus-kasus ini, 8 serangan memiliki durasi serangan kurang dari 1 minggu, dan sebagian besar dapat diblokir dengan cooldown

Konsep dan efek cooldown

Cooldown adalah pendekatan yang menunda penggunaan dependensi baru selama periode tertentu setelah dirilis
- Selama periode ini, vendor keamanan dapat mendeteksi apakah dependensi tersebut berbahaya
Iklan
Kelebihan
- Terbukti efektif secara empiris, dan dapat memblokir sebagian besar serangan berskala besar
- Sangat mudah diimplementasikan dan pada sebagian besar alat bisa diatur gratis
- Contoh Dependabot
```
version: 2
- package-ecosystem: github-actions
  directory: /
  schedule:
    interval: weekly
  cooldown:
    default-days: 7
```
- Mendorong perilaku positif dari vendor keamanan: membuat mereka fokus pada deteksi cepat alih-alih peringatan berlebihan atau promosi

Kesimpulan dan saran

8 dari 10 serangan memiliki durasi 1 minggu atau kurang, dan cooldown 7 hari dapat memblokir sebagian besar di antaranya
Dengan menerapkan cooldown 14 hari, semua kasus selain xz-utils dapat dicegah
Cooldown bukan solusi sempurna, tetapi merupakan cara sederhana untuk mengurangi risiko paparan hingga 80~90%
Selain Dependabot dan Renovate, perlu ada perbaikan agar package manager sendiri mendukung cooldown secara default
Keamanan rantai pasok bukan hanya masalah teknis, tetapi juga soal struktur kepercayaan sosial, dan cooldown adalah langkah mitigasi yang realistis dan berguna

3 komentar

regentag 2025-11-23

Sebenarnya, kalau tidak ada masalah, sepertinya lebih baik tidak perlu melakukan pembaruan.
Apakah benar perlu menerapkan versi baru yang tidak jauh berbeda dari versi sebelumnya sambil menanggung risikonya?

GN⁺ 2025-11-22

Komentar Hacker News

Orang khawatir bahwa jika tidak langsung memperbarui, mereka akan terekspos pada kerentanan serius, tetapi dalam kenyataannya sering kali tidak demikian
Banyak perangkat lunak tidak memakai deployment berkelanjutan, melainkan pelanggan sendiri yang memasang versi baru, sehingga pembaruan dilakukan per beberapa minggu atau beberapa bulan
Yang penting adalah pemantauan dependensi dan pemeriksaan kerentanan yang telah dipublikasikan. Nilai dulu apakah produk benar-benar terdampak, lalu hanya saat itulah dependensi terkait perlu segera diperbarui
- Di seluruh ekosistem, budaya pembaruan selektif seperti ini masih kurang
  Ada anggapan luas bahwa begitu versi baru keluar, harus diperbarui hari itu juga
  Mendekati hal ini dengan pola “nanti akan lebih sulit, jadi kerjakan sekarang saja” tanpa meninjau perubahan yang sebenarnya itu tidak efisien
  Tetap berada di garis terdepan nomor versi justru bisa kontraproduktif bagi keamanan
- Masalah nyatanya adalah banyak tim keamanan di perusahaan besar memaksakan kebijakan “zero CVE”
  Di perusahaan kami, jika pemindai menemukan kerentanan kritis, kami harus memperbarui dalam 7 hari
  Jika melewati tenggat, proses rumit akan dimulai karena dianggap melanggar aturan, jadi kebanyakan orang akhirnya langsung memperbarui semuanya
- Orang takut pada 0-day, tetapi pada praktiknya sebagian besar masalah berasal dari kerentanan yang tidak ditambal selama ratusan hari
- Intinya adalah apakah aplikasi menerima input tak dikenal dari luar
  Aplikasi seperti browser yang menerima banyak input eksternal harus sering diperbarui, tetapi jika inputnya terbatas seperti aplikasi cuaca, relatif lebih aman
- Strategi “perbarui hanya saat perlu” terdengar bagus secara teori, tetapi dalam praktiknya biaya menilai tiap kerentanan sesuai produk terlalu besar
  Lebih efisien jika melakukan pembaruan berkala dan sekaligus menerapkan langkah pertahanan terhadap serangan supply chain
Cara distribusi mengelola dependensi bersama seperti model Debian stable dan melakukan upgrade menyeluruh tiap beberapa tahun tampak makin masuk akal
Beberapa ekosistem bergerak terlalu cepat atau sistem pemaketan per distribusinya lemah
Misalnya, memasang library Node.js lewat apt lalu memakainya di proyek masih sulit
- Jangan salah mengira “bergerak” sebagai “bertindak”
  Ekosistem yang bergerak cepat tanpa perubahan mendasar bukan ekosistem yang sehat
  JS hampir tidak menunjukkan kemajuan nyata dalam 3 tahun terakhir, tetapi untuk membangun ulang proyek yang berumur 3 tahun, rasa sakitnya bisa setingkat rewrite
- Hasil pencarian paket node Debian menunjukkan memang ada beberapa, tetapi tidak lengkap
  Di distribusi seperti Arch, kadang malah tidak ada sama sekali
- Rust masih cukup bisa dikerjakan hanya dengan repositori Debian
- Model versi stabil membawa beban bahwa aplikasi harus mendukung versi lama dan baru secara bersamaan
Ada asumsi bahwa untuk mencegah serangan supply chain, memberi masa cooldown pada pembaruan dependensi lebih baik daripada langsung memakai versi terbaru demi mencegah 0-day
Ini adalah perbandingan antara kemungkinan pembaruan memperkenalkan kerentanan baru dan kemungkinan ia memperbaiki kerentanan yang sudah ada
Berdasarkan SemVer, versi patch relatif lebih aman sehingga pendekatan seperti memberi cooldown singkat juga mungkin dilakukan
Misalnya, saat 2.4.0 keluar dari 2.3.4, jika tidak ada fitur mendesak, mungkin lebih baik menunggu sampai 2.4.1 keluar
- Untuk 0-day yang telah dipublikasikan, akan ada advisory keamanan, jadi alat seperti Dependabot akan mengabaikan cooldown dan langsung menambal
  Sebagian besar kerentanan bukan berasal dari serangan yang disengaja, melainkan dari bug umum
- Nilai default selalu didasarkan pada asumsi. Jika ada informasi baru, itu bisa diubah
Kebijakan yang membatasi jumlah dan kompleksitas dependensi adalah pendekatan yang lebih kuat
Alih-alih menambahkan “library yang melakukan segalanya”, sebaiknya hanya menambah dependensi kecil dengan tujuan yang jelas
Selain itu, jika library juga menyediakan versi LTS yang hanya memuat patch keamanan, pengelolaannya menjadi lebih mudah
- Argumen seperti ini sering muncul, tetapi dalam praktiknya reuse kode yang sudah tervalidasi jauh lebih efisien
  Mengimplementasikan ulang sendiri bisa jadi pemborosan. Saya penasaran contoh spesifik dari “everything library” yang bermasalah
- Sebagian besar serangan supply chain terjadi pada permukaan serangan rekayasa sosial
  Jika Anda mempercayai pengembang yang sama di banyak library, maka yang lebih penting daripada jumlah paket adalah hubungan kepercayaan
  Kompleksitas memang berkorelasi dengan kerentanan, tetapi bukan penyebab langsung
- Dengan munculnya alat AI, biaya untuk mengimplementasikan sendiri dependensi non-inti menjadi lebih rendah
  Sekarang pilihan bisa dibuat dengan mempertimbangkan pemeliharaan jangka panjang, bukan hanya kecepatan jangka pendek
- Dependensi yang terlalu terpecah-pecah justru bisa menambah jumlah dan beban build
- Sulit membenarkan library level bawah yang masih memiliki dependensi lain
  Di dunia C++, hal seperti ini bahkan kadang menjadi poin persaingan
Tekanan untuk selalu memperbarui ke versi terbaru setiap saat berasal dari keyakinan keliru bahwa perangkat lunak selalu menjadi lebih baik
Padahal kenyataannya, itu bisa berarti menukar bug yang sudah diketahui dengan bug baru yang belum diketahui
Memantau issue yang dipublikasikan dan menambal hanya saat perlu adalah pendekatan yang masuk akal
- Misalnya pada kasus log4shell, log4j 1.x tidak rentan, sedangkan bug tersebut diperkenalkan di 2.x
  Artinya, ada kasus di mana versi lama justru lebih aman
- Dulu jarak antar rilis lebih panjang sehingga peningkatan kualitas lebih jelas, tetapi sekarang kebanyakan hanya perubahan periferal
  Mungkin juga karena kita sudah memakai perangkat lunak yang cukup stabil
Jika semua orang berkata “mari tunggu sebentar”, pada akhirnya seperti tragedy of the commons dan tidak ada yang lebih dulu memverifikasi
Semakin lama menunggu, semakin banyak utang teknis menumpuk, jadi diperlukan pembaruan bertahap dan mitigasi seperti zero trust dan monitoring
- Menunggu sekitar seminggu setelah versi baru dirilis bukanlah utang teknis yang besar
  Dalam waktu itu, pemindai keamanan biasanya sudah mendeteksi kerentanannya
- Serangan supply chain belakangan ini terdeteksi bukan karena paparan ke konsumen, melainkan karena adanya waktu bagi maintainer untuk merespons
- Walau jumlah konsumen berkurang, peneliti dan maintainer mendapat waktu untuk menganalisis
  Jika penyerang mengunggah rilis tanpa izin, sering kali itu langsung disadari
- Sistem berskala besar pada dasarnya memang melakukan rollout bertahap, jadi pembaruan penuh secara instan itu mustahil
Ide cooldown itu bagus, tetapi ada risiko penyerang menyalahgunakannya untuk menciptakan rasa urgensi palsu
Dengan dalih “patch keamanan darurat”, mereka bisa mendorong pemasangan lebih awal, padahal versi itu sebenarnya berbahaya
Kita perlu bersiap menghadapi serangan tekanan psikologis semacam ini
- Saat penyerang menyebarkan exploit, jika mereka juga menyertakan perbaikan bug, mereka bisa mendorong pengembang melanggar cooldown dan memasangnya
- Muncul pertanyaan, “bagaimana mereka bisa membuat kebisingan seperti itu?” — yakni keraguan tentang cara penyerang memanipulasi opini publik
Alasan lain untuk cooldown adalah memberi waktu bagi maintainer menyadari sendiri bahwa mereka telah dikompromikan
Penyerang membidik saat maintainer sedang tidak aktif, seperti saat liburan, konferensi, atau hari libur nasional
Banyak proyek dikelola satu atau dua orang, sehingga jeda waktu seperti ini sangat penting
Ini bergantung pada karakteristik proyek dan permukaan serangan
Era sekadar mengikuti “best practice” seharusnya sudah berakhir
Keamanan itu seperti contact sport: detailnya harus dipikirkan secara kritis setiap hari
Ada juga batasan cooldown jika diasumsikan bahwa sekadar berlalunya waktu membuat keadaan jadi aman
Jika tidak ada yang meninjau kodenya, setelah seminggu pun risikonya tetap sama
Sebagai gantinya, pendekatan gradual rollout bisa efektif
Tiap konsumen menetapkan faktor penundaan sendiri, sehingga pihak yang toleransi risikonya lebih tinggi akan lebih dulu terkena masalah,
sementara sisanya terlindungi selama itu
Pembaruan berbahaya akan dihapus dari antrean, sehingga konsumen yang tertunda bahkan tidak akan pernah melihatnya

aer0700 2025-11-23

Akhir-akhir ini saya kadang bingung mana yang lebih bisa ditanggung: usaha sekadar menemukan kembali roda, atau usaha mengelola Tetris dependensi.
Kalau ada yang salah selama ini, saya tinggal memperbaiki kode saya sendiri, tetapi dalam Tetris dependensi, sulit juga melakukan debugging untuk mencari tahu roda mana yang tiba-tiba oleng.