Supply Chain Attack Perangkat Lunak: Pengertian dan Cara Mencegahnya

Supply chain attack perangkat lunak adalah serangan yang menyusupi komponen, alat, atau jalur distribusi yang dipercaya korban, bukan menyerang korban secara langsung. Sepanjang 2025 dan 2026 pola ini menjadi arus utama lewat worm npm, kompromi pipeline CI, dan paket berbahaya di registry. Artikel ini menjelaskan pengertian, contoh nyata, dan cara mencegahnya untuk tim di Indonesia.

Pengertian Supply Chain Attack pada Perangkat Lunak

Aplikasi modern jarang ditulis dari nol. Ia disusun dari pustaka open source, alat build, image kontainer, ekstensi editor, dan layanan pihak ketiga. Setiap komponen itu berasal dari manusia atau sistem lain yang kita percayai. Dalam supply chain attack, penyerang tidak menembus pertahanan Anda; ia menyusup lewat komponen yang sudah Anda izinkan masuk, lalu berjalan dengan hak akses komponen itu.

Contoh klasik adalah penyusupan pembaruan SolarWinds Orion yang diungkap pada Desember 2020, ketika penyerang menyisipkan kode berbahaya lewat proses build vendor, dan kode berbahaya di tarball upstream xz mulai versi 5.6.0 pada 2024 (CVE-2024-3094). Kasus-kasus terbaru berbeda dalam hal skala dan kecepatan: penyerang kini memakai otomasi dan worm sehingga satu kredensial curian dapat menyebar ke ratusan paket dalam hitungan jam.

Jenis Serangan yang Paling Sering Ditemui

• Pengambilalihan akun maintainer. Kredensial atau token publikasi dicuri, lalu versi berbahaya diterbitkan atas nama proyek yang sah.
• Kompromi pipeline build. Workflow CI, cache, atau token dimanfaatkan sehingga artefak berbahaya dibangun oleh pipeline yang resmi.
• Typosquatting dan dependensi tiruan. Paket dengan nama mirip pustaka populer disisipkan sebagai dependensi.
• Tag atau image yang dapat dipindahkan. Tag versi atau tag image kontainer diarahkan ke isi yang berbeda tanpa pemberitahuan.
• Ekstensi dan alat pengembang. Editor, ekstensi, dan pemindai yang berjalan dengan hak penuh menjadi pintu masuk.

Contoh Nyata 2025 sampai 2026

Shai-Hulud (September 2025). CISA melaporkan worm yang menyebar sendiri dan memengaruhi lebih dari 500 paket npm. Ia mencari token akses pribadi GitHub serta kunci API AWS, GCP, dan Azure, mengirimkannya ke penyerang, lalu masuk ke npm sebagai korban untuk menerbitkan versi berbahaya lain. Gelombang kedua yang diidentifikasi pada 24 November 2025, menurut analisis Datadog, memengaruhi 796 paket unik dengan 1.092 versi dan lebih dari 20 juta unduhan mingguan. Rinciannya ada di artikel Shai-Hulud.

TeamPCP (Maret 2026). Menurut Datadog, kampanye ini memuncak dengan kompromi alat pemindai Trivy pada 19 Maret 2026, lalu menjalar ke GitHub Action Checkmarx KICS pada 23 Maret dan ke LiteLLM di PyPI pada 24 Maret (versi 1.82.7 dan 1.82.8). Pada 22 April, image Docker Hub checkmarx/kics juga ditimpa dengan image berbahaya memakai kredensial penerbit yang dicuri, menurut Docker, yang tidak menyebut nama pelakunya. Penjelasannya ada di artikel TeamPCP. Pelajaran kuncinya: pemindai keamanan yang berjalan di CI memegang rahasia build, sehingga ia menjadi target bernilai tinggi.

axios (31 Maret 2026). Menurut peringatan CISA, versi axios 1.14.1 dan 0.30.4 menyisipkan dependensi berbahaya yang mengunduh payload bertahap, termasuk trojan akses jarak jauh. Pustaka ini sangat banyak dipakai, sehingga jendela paparan yang singkat pun berbahaya.

Mengapa Serangan Ini Sulit Dideteksi

Ada tiga alasan. Pertama, kode berbahaya datang lewat jalur yang sah dan sering berasal dari akun atau pipeline yang memang punya hak menerbitkan. Kedua, banyak payload berjalan otomatis saat pemasangan atau saat build, sebelum ada yang sempat meninjau. Ketiga, pemeriksaan yang ada sering hanya menilai asal artefak, bukan perilakunya, sehingga artefak yang ditandatangani dan diverifikasi pun tetap bisa berbahaya. Karena itu pertahanan yang baik memadukan pencegahan, pembatasan hak akses, dan pemantauan perilaku saat instalasi.

Cara Mencegah Supply Chain Attack

Tidak ada satu kontrol yang cukup. Pertahanan yang efektif berlapis dan berfokus pada tiga hal: mengurangi apa yang dipercaya, memperlambat adopsi, dan membatasi dampak.

1. Ketahui apa yang Anda pakai. Susun inventaris dependensi dan SBOM per rilis agar saat insiden terjadi Anda bisa menjawab dalam menit, bukan hari. Konsepnya dibahas di artikel SBOM, SLSA, dan Sigstore.
2. Kunci versi. Commit lockfile dan pasang secara deterministik (misalnya npm ci). Pin action CI ke commit SHA dan image kontainer ke digest.
3. Beri jeda pada versi baru. Cooldown 24 sampai 72 jam, seperti disarankan Unit 42, melalui registry privat atau proxy memberi waktu bagi pemindai untuk menemukan rilis berbahaya. CISA menyarankan min-release-age=7 pada npm dalam peringatan axios.
4. Batasi skrip instalasi. Setel ignore-scripts=true pada npm dan izinkan skrip hanya untuk paket yang memang membutuhkannya.
5. Amankan akun dan token. Wajibkan MFA tahan phishing untuk akun developer, pakai token berumur pendek dengan cakupan sempit, dan gunakan trusted publishing bila registry mendukungnya.
6. Hardening pipeline CI/CD. Izin minimal untuk token pipeline, hindari menjalankan kode tidak tepercaya dengan akses rahasia, dan batasi lalu lintas keluar dari runner. Panduannya ada di artikel keamanan pipeline.
7. Pantau dan siapkan respons. Awasi perilaku tak lazim saat instalasi, seperti proses anak atau koneksi keluar yang tidak biasa. Siapkan prosedur rotasi kredensial yang cepat.

Jika Anda Menduga Terdampak

Perlakukan mesin atau job CI yang memasang komponen berbahaya sebagai paparan kredensial penuh. Menghapus paket tidak mengakhiri kompromi. Rotasi semua rahasia yang dapat dijangkau, periksa akun dan repositori untuk aktivitas tak dikenal, dan bangun ulang dari lingkungan bersih. Urutan pencabutan perlu hati-hati, karena menurut Unit 42 sebagian payload memantau token yang dicuri dan bereaksi merusak bila token dicabut. Ikuti tahapan standar penanganan insiden, dan cari indikator di log instalasi serta log jaringan.

Pertanyaan yang Sering Diajukan

Apa bedanya supply chain attack dengan serangan biasa?

Serangan biasa menargetkan sistem korban secara langsung. Supply chain attack menyusup lewat pihak ketiga yang sudah dipercaya, sehingga korban memasang atau menjalankan kode berbahaya sendiri.

Apakah proyek kecil juga jadi sasaran?

Ya. Penyerang sering memilih paket kecil dengan pengamanan lemah sebagai pintu masuk, lalu menyebar lewat dependensi transitif ke pengguna yang jauh lebih besar.

Apakah SBOM saja cukup?

Tidak. SBOM memberi visibilitas komponen, bukan pencegahan. Ia paling berguna saat dikombinasikan dengan pin versi, cooldown, dan pemantauan.

Mulai dari mana jika sumber daya terbatas?

Mulai dari tiga langkah murah: lockfile dengan instalasi deterministik, MFA tahan phishing pada akun developer, dan pin action CI ke SHA.

Kesimpulan

Supply chain attack bukan ancaman jauh; ia sudah memengaruhi alat yang dipakai sehari-hari oleh developer. Yang bisa Anda lakukan adalah mengurangi kepercayaan buta, memperlambat adopsi versi baru, dan membatasi apa yang dapat dicuri. Jika tim Anda ingin membangun kemampuan ini secara terstruktur, kunjungi program training Linuxhackingid.