Paket Kecil, Ledakan Besar. Cara Memetakan Blast Radius Dependency Transitif Sebelum Rahasia Prod Bocor

Satu package mungil, tiga level di bawah dependency utamamu, bisa punya akses ke install script, build pipeline, bahkan secret production. Masalahnya, banyak tim cuma melihat CVE dan versi. Padahal, risiko supply chain modern lebih sering datang dari jalur eksekusi, bukan dari ukuran package.

Kalau kamu menangani arsitektur, keamanan, atau reliability, transitive dependency blast radius mapping membantu menjawab pertanyaan yang jauh lebih penting. Package kecil ini sebenarnya bisa menjangkau apa saja kalau suatu hari dibajak?

Jawaban Singkat, Key takeaways:
Transitive dependency blast radius mapping adalah cara memetakan package tidak langsung ke aset sensitif seperti secrets, step build, signing key, dan hook install. Jadi, kamu nggak cuma tahu paket mana yang rentan, tetapi juga tahu paket mana yang paling berbahaya kalau disusupi.

Apa itu transitive dependency blast radius mapping

Singkatnya, ini adalah pemetaan siapa bergantung pada siapa, lalu diperluas menjadi siapa bisa menyentuh apa. Dependency graph biasa berhenti di hubungan antar paket. Blast radius mapping melangkah lebih jauh, karena ia menghubungkan paket transitif ke capability, trust boundary, dan impact path.

Jadi, fokusnya bukan cuma node. Fokusnya adalah jalur. Package A mungkin tampak sepele. Namun, kalau A aktif saat npm install, ikut masuk ke image build, lalu membaca environment CI, radius risikonya langsung melebar.

Kenapa tim sering salah prioritas

Banyak backlog security penuh dengan paket berisiko rendah yang mudah dipatch. Sementara itu, package transitif yang punya jalur ke credential build justru lolos dari radar. Ini terjadi karena banyak tim memakai framework prioritas yang salah.

• CVE-centric, bagus untuk compliance, lemah untuk konteks operasional.
• Version-centric, membantu upgrade, tetapi belum tentu menutup jalur serangan.
• Package popularity-centric, berguna untuk awareness, tetapi tidak mengukur akses nyata ke sistemmu.

Akibatnya, tim sibuk menurunkan angka temuan. Namun, blast radius sebenarnya tetap besar.

Framework praktis, Path, Privilege, Persistence

Ada pendekatan yang jauh lebih berguna untuk tim security engineer, software architect, dan SRE. Aku menyebutnya framework 3P, yaitu Path, Privilege, dan Persistence.

1. Path

Petakan apakah package transitif bisa masuk ke runtime, build time, atau install time. Semakin awal ia dieksekusi, semakin besar peluang menyerempet asset sensitif. Install script dan postinstall hook sering lebih berbahaya daripada library runtime biasa.

2. Privilege

Lihat environment apa yang terlihat oleh package itu. Misalnya, token registry, cloud credential sementara, GitHub Actions secret, signing key, atau akses ke artifact repository. Package tanpa CVE bisa tetap jadi ancaman tinggi kalau privilege-nya besar.

3. Persistence

Tanya satu hal penting, kalau package ini disusupi, apakah ia bisa bertahan? Contohnya lewat cache CI, artifact build, generated code, lockfile poisoning, atau perubahan image base. Semakin lama efeknya bertahan, semakin tinggi prioritas mitigasinya.

Di sinilah ide yang sering mengejutkan tim. Dependency yang tidak pernah jalan di production tetap bisa punya risiko production paling besar. Kenapa? Karena compromise di fase build bisa menyuntik artifact yang nanti masuk ke prod dengan rapi.

Node yang wajib kamu tandai lebih dulu

Supaya analisis cepat bernilai, mulai dari node yang menyentuh boundary penting. Berikut shortlist yang paling sering punya blast radius besar.

• Install scripts, seperti preinstall, postinstall, prepare.
• Build tooling, bundler, transpiler, plugin, code generator.
• Test helpers yang jalan di CI dengan secret aktif.
• Release tooling untuk publish package, sign artifact, atau push image.
• Base image dan container build layer yang diwariskan lintas service.

Karena itu, tim sebaiknya tidak memisahkan AppSec dari platform engineering. Blast radius dependency transitif hampir selalu melewati CI, registry, dan workflow automation.

Langkah memetakan blast radius tanpa tenggelam di graph

1. Bangun graph dependency dari lockfile dan SBOM.
2. Tambahkan execution context, runtime, build, install, test, release.
3. Label asset sensitif, secret, token, signing key, prod config, deployment role.
4. Hubungkan trust path, package mana yang bisa mencapai asset itu secara langsung atau tidak langsung.
5. Skor impact berdasarkan 3P, bukan CVE saja.
6. Mitigasi, hapus hook tak perlu, isolasi build, minimalkan secret exposure, pin provenance.

Kalau kamu sudah membaca kenapa lockfile saja belum cukup, langkah ini akan terasa nyambung. Begitu juga dengan pembahasan SBOM dan provenance artifact, karena blast radius mapping paling kuat saat dua hal itu digabung.

Mitigasi yang paling efektif, bukan paling ramai

Banyak tim langsung mengejar jumlah update terbesar. Padahal, hasil terbaik sering datang dari beberapa perubahan kecil yang tepat sasaran.

• Pisahkan secret build dari step yang tidak perlu.
• Matikan install scripts bila workflow memungkinkan.
• Gunakan runner ephemerial agar persistence turun drastis.
• Verifikasi provenance untuk artifact penting.
• Batasi egress network saat build dan install.

Referensi bagus untuk mendalami area ini ada di SLSA, dokumentasi GitHub Actions hardening, dan panduan OWASP SCVS.

FAQ

Apakah transitive dependency blast radius mapping sama dengan SBOM?

Tidak sama. SBOM memberi daftar komponen. Blast radius mapping menambahkan konteks eksekusi, privilege, dan jalur ke aset sensitif. Jadi, hasilnya lebih berguna untuk prioritas mitigasi.

Apakah package tanpa CVE tetap harus diprioritaskan?

Iya, dalam banyak kasus justru iya. Jika package itu punya akses ke install script, build agent, atau secret CI, dampaknya bisa lebih besar daripada library runtime yang punya CVE tetapi terisolasi.

Mulai dari mana kalau dependency graph sangat besar?

Mulai dari event yang paling berprivilege tinggi, yaitu install, build, release, dan deploy. Setelah itu, telusuri package transitif yang aktif di sana. Pendekatan ini lebih cepat menghasilkan insight daripada meninjau seluruh graph sekaligus.

Penutup

Kalau timmu masih menilai dependency dari versi dan severity saja, kamu baru melihat permukaan. Transitive dependency blast radius mapping membantu tim menemukan package kecil yang diam-diam punya jalur ke rahasia prod, build step, dan script instalasi, sebelum insiden benar-benar terjadi.

Sekarang giliran kamu. Audit satu pipeline build minggu ini, petakan node install, build, dan release, lalu lihat package transitif mana yang sebenarnya paling dekat ke aset kritis. Kalau kamu mau, lanjutkan diskusi di kolom komentar atau subscribe ke update berikutnya.