Dependency Terkontaminasi? Ini Playbook Rollback Cepat Sebelum Prod Ikut Keracunan

Paket sudah terpasang, pipeline sempat hijau, lalu feed intel bilang dependency yang kamu pakai ternyata beracun. Di titik ini, masalahnya bukan lagi pencegahan. Masalahnya, seberapa cepat timmu bisa pin, quarantine, rebuild, rotate secrets, lalu verifikasi runtime exposure sebelum insiden melebar ke produksi, data, dan akun cloud.

Artikel ini fokus ke celah yang sering bikin tim kalah cepat, yaitu fast rollback playbook for poisoned dependencies. Jadi, bukan teori supply chain security yang muter di awal. Langsung praktik. Kalau dependency ternyata jahat, apa yang harus dikerjakan dalam menit pertama, jam pertama, dan sesudah layanan kembali stabil.

Jawaban Singkat, Key Takeaways

Kalau dependency terkontaminasi, rollback cepat bukan cuma soal downgrade versi. Kamu juga perlu mengarantina artifact, membangun ulang dari state bersih, merotasi secret yang mungkin terekspos, lalu memverifikasi apakah kode jahat sempat berjalan di runtime.

Urutan yang salah bikin tim merasa aman padahal blast radius masih hidup. Karena itu, playbook yang bagus selalu bergerak dari containment ke rebuild, lalu ke evidence-driven verification.

Kenapa rollback biasa sering gagal

Banyak tim mengira rollback dependency selesai saat versi dipin ke rilis terakhir yang aman. Padahal, kalau artifact hasil build lama masih ada di cache, image registry, atau worker node, versi jahat bisa tetap ikut hidup. Jadi, rollback versi tanpa karantina artifact sering cuma kosmetik.

Lebih parah lagi, beberapa serangan dependency berjalan saat install time, post-install script, atau build step. Artinya, walau aplikasinya belum sempat deploy penuh, secret build, token CI, atau kredensial registry bisa sudah bocor. Kasus seperti ini nyambung dengan pembahasan soal install-time script abuse dan kenapa blast radius dependency transitif harus dipetakan cepat.

Framework 5P untuk fast rollback playbook

Agar tim nggak lompat-lompat, pakai urutan 5P ini. Framework ini sengaja dibuat buat kondisi panik, jadi sederhana tapi tegas.

1. Pin

Kunci semua environment ke versi terakhir yang sudah tervalidasi bersih. Jangan cuma update package.json atau manifest. Pastikan lockfile, image digest, dan source revision ikut dipin.

• Pin versi aman di source control.
• Blok versi jahat di internal registry atau proxy.
• Bekukan auto-update sementara waktu.

2. Purge and Quarantine

Ini bagian yang sering dilewati. Bukan cuma rollback, tapi juga buang jejak build yang salah. Karantina artifact, cache dependency, layer container, dan runner workspace yang pernah menyentuh paket beracun.

• Tarik image yang tercemar dari deployment pool.
• Karantina artifact CI, jangan langsung hapus evidence mentah.
• Invalidate build cache, dependency cache, dan workspace ephemeral.
• Putuskan jalur promotasi artifact antar environment.

3. Prove the Clean Rebuild

Tip yang sering terasa aneh, jangan terlalu percaya rollback cepat dari artifact lama. Secara operasional itu menggoda. Namun, secara forensik itu berbahaya. Artifact lama bisa ikut tercemar kalau proses build sebelumnya sudah disentuh dependency jahat.

Lebih aman, rebuild dari commit bersih, dependency yang dipin, builder bersih, dan verifikasi SBOM baru. Di sini, artikel SBOM saja nggak cukup relevan, karena SBOM harus dipakai bersama provenance dan signature, bukan berdiri sendiri.

Rujukan bagus untuk tahap ini ada di CISA Software Supply Chain Guidance, SLSA, dan OWASP SCVS.

4. Protect Secrets

Kalau dependency sempat jalan saat build atau runtime, anggap secret berisiko sampai terbukti aman. Karena itu, rotasi jangan menunggu hasil forensik lengkap. Mulai dari secret yang paling bernilai dan paling mudah disalahgunakan.

• Rotasi token CI dan deploy key.
• Rotasi kredensial registry, cloud IAM key, dan webhook secret.
• Periksa env var injection, file secret mount, dan metadata service access.
• Audit pemakaian secret setelah timestamp kompromi.

5. Prove Runtime Exposure

Bagian ini memisahkan tim matang dari tim yang cuma sibuk. Pertanyaannya bukan cuma, “Paket jahat ini terpasang atau nggak?” Pertanyaan yang benar, “Paket jahat ini sempat eksekusi atau belum, dan aksesnya sampai mana?”

Cek log proses, network egress, child process, DNS query aneh, akses file sensitif, serta pemanggilan metadata endpoint. Lalu, cocokkan dengan daftar host, pod, runner, dan image yang terdampak. Kalau kamu butuh pola pikir insiden yang lebih luas, lihat juga artikel toolkit incident response lengkap.

Playbook 60 menit pertama

1. Konfirmasi indikator. Catat nama paket, versi, hash, advisory, dan jalur transitive dependency.
2. Freeze perubahan. Hentikan deploy otomatis, release train, dan pipeline promotasi.
3. Pin versi aman. Kunci manifest, lockfile, image digest.
4. Karantina artifact. Tandai build, cache, image, runner, dan workspace terdampak.
5. Rebuild bersih. Gunakan builder baru, cache kosong, dependency terverifikasi.
6. Rotasi secret prioritas tinggi. Mulai dari CI, cloud, registry, lalu aplikasi.
7. Verifikasi runtime exposure. Cek apakah paket sempat jalan, menelepon keluar, atau menyentuh secret.
8. Komunikasi singkat ke stakeholder. Status, risiko, aksi, ETA, dan apa yang masih belum pasti.

Kesalahan mahal yang sering kejadian

• Rollback tanpa rebuild. Cepat, tapi rawan false sense of safety.
• Hapus evidence terlalu dini. Operasi jadi rapi, investigasi jadi buta.
• Rotasi secret belakangan. Penyerang dapat waktu ekstra.
• Fokus ke CVE, lupa telemetry. Advisory memberi petunjuk. Telemetry memberi bukti.
• Menganggap dev dan CI lebih aman dari prod. Justru build plane sering jadi pintu awal.

Checklist verifikasi sebelum insiden ditutup

• Versi aman sudah dipin di semua environment.
• Artifact lama sudah dikarantina atau ditarik dari jalur deploy.
• Rebuild bersih sukses, hash dan provenance cocok.
• Secret prioritas tinggi sudah dirotasi.
• Log runtime, egress, dan child process sudah diperiksa.
• Blast radius host, pod, runner, dan akun sudah dipetakan.
• RCA awal dan action item pencegahan sudah ditulis.

FAQ

Apakah cukup rollback ke versi sebelumnya?

Belum tentu cukup. Kalau paket jahat sempat berjalan saat build atau runtime, artifact, cache, dan secret bisa ikut terdampak. Jadi, rollback versi harus diikuti karantina, rebuild, dan verifikasi exposure.

Kapan secret wajib dirotasi?

Segera setelah ada kemungkinan dependency berbahaya mengakses environment build atau runtime. Jangan menunggu bukti sempurna kalau secret itu bernilai tinggi dan mudah disalahgunakan.

Apakah SBOM saja cukup untuk memastikan build aman?

Nggak cukup. SBOM membantu melihat komponen, tetapi kamu tetap perlu provenance, signature, dan telemetry runtime untuk memastikan artifact bersih dan memang dibangun dari jalur yang benar.

Apa indikator runtime exposure yang paling penting?

Mulai dari network egress yang aneh, child process tidak biasa, DNS lookup mencurigakan, akses ke env var, file secret, metadata service, dan perubahan artifact saat build.

Penutup

Serangan dependency beracun jarang memberi waktu nyaman. Karena itu, fast rollback playbook for poisoned dependencies harus mengutamakan urutan yang benar, bukan sekadar aksi yang terlihat cepat. Pin dulu. Karantina dulu. Rebuild bersih. Rotasi secret. Baru tutup insiden setelah runtime exposure benar-benar diverifikasi.

Kalau kamu sedang menyusun playbook internal, simpan artikel ini buat tabletop exercise timmu. Lalu, cek juga artikel terkait di Hadezuka.dev dan bagikan di channel engineering supaya respons tim lebih sinkron saat insiden nyata datang.