Sebuah instansi dapat menjadi korban serangan tanpa pernah menjadi sasaran langsung. Caranya: penyerang lebih dulu menembus pihak yang sudah dipercaya instansi itu — vendor, penyedia layanan, mitra, atau komponen perangkat lunak pihak ketiga yang tertanam di dalam sistemnya. Setelah salah satu pihak itu dikuasai, penyerang tinggal memakai jalur akses yang memang sudah tersedia dan sah.
Inilah yang disebut supply chain attack atau serangan rantai pasok. ENISA dalam Threat Landscape 2025 mencatat risiko rantai pasok menyumbang 10,6% dari kategori ancaman yang dianalisis — termasuk kompromi terhadap software repository, browser extension, dan penargetan penyedia pihak ketiga.
Tiga Bentuk Serangan Rantai Pasok
- Software supply chain attack. Menyasar komponen atau proses dalam pengembangan dan distribusi perangkat lunak: repository, proses build, pipeline CI/CD, maupun paket dependensi.
- Kompromi pihak ketiga dan penyedia layanan. Penyerang menguasai vendor, penyedia layanan TI, managed service provider (MSP), atau penyedia SaaS yang memiliki hubungan dan integrasi dengan organisasi target.
- Kompromi rantai pasok perangkat keras. Manipulasi perangkat atau komponen fisik pada tahap pengembangan maupun produksi, sebelum perangkat itu dipakai organisasi.
Bagaimana Serangan Ini Berjalan
Polanya berulang dalam empat tahap:
- Mencari bagian rantai pasok yang lemah. Penyerang memetakan pihak dan komponen yang punya hubungan dengan organisasi target, lalu mencari titik terlemahnya.
- Menguasai komponen atau pihak yang terhubung. Misalnya menguasai repository kode sumber, sistem build, atau paket dependensi.
- Menyisipkan perubahan berbahaya. Kode jahat dimasukkan agar ikut terbawa dalam proses pengembangan atau distribusi yang normal.
- Sampai ke pengguna lewat mekanisme yang dipercaya. Komponen yang sudah dikompromikan tiba melalui pembaruan rutin atau proses build yang sah — tanpa penyerang perlu menyentuh sistem organisasi sama sekali.
Justru tahap terakhir itulah yang membuat serangan rantai pasok sulit ditangkal dengan pertahanan perimeter: berkas jahat datang melalui jalur yang memang seharusnya dipercaya.
Tiga Kasus yang Menjelaskan Polanya
SolarWinds (2020). Penyerang menguasai build server dan menyisipkan backdoor ke dalam perangkat lunak Orion. Kode itu lalu terdistribusi ke pelanggan melalui pembaruan rutin. SolarWinds memperkirakan hampir 18.000 pelanggan dapat menerima pembaruan yang telah dikompromikan, meski kurang dari 100 di antaranya diperkirakan benar-benar dikompromikan lebih lanjut. Pelajarannya: keamanan sebuah aplikasi tidak hanya bergantung pada organisasi yang memakainya, tetapi juga pada keamanan proses pembuatan dan distribusinya.
Kaseya VSA (2021). Penyerang mengeksploitasi kerentanan zero-day pada VSA versi on-premises, sebuah platform remote monitoring and management yang dipakai MSP untuk mengelola sistem pelanggan. Kerentanan itu memungkinkan mereka melewati autentikasi, lalu memakai fungsi normal VSA untuk menyebarkan ransomware ke seluruh endpoint yang dikelola. Kurang dari 60 pelanggan dikompromikan langsung, tetapi dampaknya menjangkau hingga sekitar 1.500 usaha yang mereka layani. Pelajarannya: platform yang punya kendali terpusat memperbesar dampak setiap kompromi.
XZ Utils (2024). Kode berbahaya ditemukan pada XZ Utils versi 5.6.0 dan 5.6.1, disisipkan ke dalam upstream tarball dan dirancang agar hanya aktif ketika proses build tertentu dijalankan. Kasus ini terdeteksi sebelum versi terkompromi tersebar luas ke distribusi Linux. Pelajarannya: komponen open-source yang menjadi mata rantai dependensi dapat menjadi titik kompromi — dan penyisipannya bisa sangat halus.
Cara Mengurangi Risikonya
Serangan rantai pasok tidak dapat diatasi hanya dengan memperkuat sistem internal. Organisasi perlu memahami siapa dan apa saja yang menjadi bagian dari rantai pasok teknologinya. NIST menganjurkan penerapan Cybersecurity Supply Chain Risk Management (C-SCRM), yang mencakup:
- Due diligence terhadap penyedia. Penilaian tidak berhenti pada ada-tidaknya sertifikat, melainkan mencakup asal-usul produk (provenance), ketahanan penyedia, praktik keamanan dasarnya, dan siapa saja pihak lain di belakangnya. NIST SP 1326 (Juli 2026) memberi panduan khusus untuk penilaian ini.
- Persyaratan keamanan di dalam kontrak. Kewajiban pengamanan pengembangan, pelaporan insiden, pemberitahuan kerentanan, dan pengelolaan subkontraktor perlu dituangkan sejak proses pengadaan — bukan diminta belakangan saat insiden sudah terjadi.
- Visibilitas terhadap komponen dan dependensi yang dipakai, terutama untuk komponen open-source yang jarang tercatat dalam dokumen pengadaan.
Apa Artinya bagi Perangkat Daerah di Kutai Timur
Sebagian besar aplikasi layanan di lingkungan pemerintah daerah dibangun dan dipelihara oleh pihak ketiga. Itu membuat topik ini bukan bacaan teoretis, melainkan risiko sehari-hari. Langkah yang dapat dimulai sekarang:
- Susun daftar vendor dan aplikasi beserta pihak yang masih memegang akses ke sistem. Tanpa daftar ini, mustahil menilai risiko rantai pasok secara terukur.
- Cabut akses vendor yang pekerjaannya sudah selesai. Akun pengembang yang tetap aktif setelah kontrak berakhir adalah temuan yang berulang kali muncul dalam penanganan insiden situs pemerintah daerah.
- Masukkan klausul keamanan ke dalam kontrak pengadaan — kewajiban memberi tahu bila terjadi insiden pada sisi vendor, kewajiban menyerahkan kode dan dokumentasi, serta larangan menanam akses cadangan.
- Perhatikan tema, plugin, dan pustaka pihak ketiga pada situs dinas. Sebagian besar insiden situs pemerintah daerah bermula dari komponen tambahan yang tidak pernah diperbarui, bukan dari inti aplikasinya.
- Jangan memakai berkas pemasang dari sumber tidak resmi. Tema atau plugin berbayar versi "gratisan" adalah salah satu jalur penyisipan kode jahat yang paling sering ditemui pada portal instansi.
- Minta daftar komponen (pustaka dan versinya) dari pengembang saat serah terima aplikasi, agar instansi tahu apa yang harus ditambal ketika sebuah kerentanan diumumkan.