Minggu Waktu Worm Supply-Chain Beneran Nongol di Dependency Tree Salah Satu Project Saya

Saya pernah nulis soal checklist yang saya jalanin tiap kali ada worm supply-chain npm baru muncul di berita. Bulan ini, buat pertama kalinya sejak saya beneran serius jalanin checklist itu, salah satu package yang affected muncul sebagai transitive dependency di project client yang saya maintain. Bukan headline yang saya baca terus lega karena bukan soal saya — advisory beneran, dengan nama package yang cocok sama sesuatu di salah satu lockfile saya. Ini yang kejadian minggu itu, dan bagian mana dari checklist saya yang tahan uji.

Hari pertama, sore-sore

Notifikasi GitHub security advisory buat package yang namanya nggak saya kenal. Reaksi pertama saya persis yang pengen saya hindari — sedikit lonjakan adrenalin, dorongan buat langsung bongkar-bongkar. Saya paksa diri ngelakuin step boring dulu: baca advisory-nya beneran, bukan ringkasannya, cek persis versi mana yang kena sebelum nyentuh apapun. Package-nya ternyata tiga level dalem di dependency tree dari logging utility yang saya pakai di backend Node legacy buat satu client — bukan sesuatu yang pernah saya install langsung.

Jalanin npm ls buat nyari package itu di semua project yang saya maintain makan waktu lebih lama dari yang saya kira. Ini tempat pertama checklist saya meleset. Saya punya lebih banyak project aktif dari yang biasanya saya inget, dan ngecek satu-satu — lockfile sekarang plus git history buat jaga-jaga kalau versi yang kena udah pernah keinstall — makan hampir semalam. Saya budget “dua puluh sampai tiga puluh menit” di kepala berdasarkan insiden-insiden sebelumnya. Yang ini makan waktu deket dua jam cuma buat fase deteksi.

Rotasi duluan, seperti janji saya sendiri

Begitu satu project client konfirmasi exposed, rotasi credential itu yang saya lakuin duluan, persis kayak checklist bilang — dan kali ini beneran kepake. Versi yang kena udah ada di lockfile sekitar tiga minggu, artinya tiap secret yang dipake di CI pipeline project itu saya perlakukan sebagai potentially compromised: deploy key, npm token, beberapa API key pihak ketiga yang dipake di build. Rotasi semuanya di bawah satu jam total — hampir anticlimactic dibanding dua jam yang baru aja saya habisin buat nyari exposure-nya.

Bagian yang belum sepenuhnya saya rencanain: nyari tau apa ada yang beneran kejadian selama window exposure, bukan cuma apa saya secara teori exposed. Konfirmasi versi yang kena keinstall nggak ngasih tau apa payload worm-nya beneran jalan. Saya telusurin log run CI dari window itu, cek network call outbound yang nggak diharapin, diff commit belakangan sama yang saya inget saya tulis — karena satu behavior yang dikenal dari serangan jenis ini itu diem-diem exfiltrate credential, bukan ngelakuin sesuatu yang keliatan destruktif. Nggak nemu bukti apapun fired. Tapi “saya udah cek dan nggak nemu apa-apa” itu beda, lebih jujur, dari “saya yakin nggak ada yang kejadian” — dan saya pastiin saya bisa bilang yang pertama.

Ngasih tau client itu bagian yang tetep nggak nyaman

Saya udah tau ini penting waktu nulis checklistnya dulu. Tetep aja nggak nyaman pas momennya. Ngejelasin ada dependency tiga level jauh dari apapun yang saya pilih langsung punya compromise terdokumentasi, dan saya nggak bisa kasih jaminan seratus persen — cuma bisa bilang saya udah cek menyeluruh dan nggak nemu bukti dampak. Saya kirim ringkasan tertulis ketimbang jelasin langsung: apa yang kejadian, apa yang saya cek, apa yang saya rotasi, apa yang bakal saya pantau. Reaksinya lebih tenang dari yang saya kira, kebanyakan karena saya mulai dengan apa yang udah saya kerjain, bukan buka dengan bagian yang nakutin.

Pelajaran yang beneran ngubah kelakuan saya: saya nggak cukup sering refresh lockfile di project client legacy, dan itu yang bikin window exposure tiga minggu itu kejadian. Project yang saya sentuh tiap hari kemungkinan bakal dapetin versi patched dengan cepet lewat update rutin. Project legacy yang saya maintain tapi nggak aktif dikembangin duduk di transitive dependency vulnerable selama berminggu-minggu, cuma karena nggak ada yang mendorong update. Sekarang ada npm audit dan refresh lockfile bulanan yang terjadwal khusus buat project kayak gitu.

Checklist saya tahan uji di bagian yang paling penting — baca advisory duluan, rotasi sebelum nunggu kepastian, jangan cuma percaya npm audit. Tapi estimasi waktunya meleset jauh, dan step “cek apa ada yang beneran kejadian” harus jauh lebih eksplisit dari yang udah saya tulis. Udah saya update. Ringkasan jujur minggu ini: punya checklist yang udah dilatih di kertas bikin respons lebih cepet dan lebih tenang dibanding improvisasi dari nol. Tapi nulis checklist dan ngejalanin versi beneran dari itu tetep dua level kesiapan yang beda — dan saya cuma nemu celahnya dengan beneran ngalamin.