Serangan rantai pasok perangkat lunak sering masuk bukan lewat celah pada aplikasi buatan tim sendiri, melainkan melalui komponen yang sudah dipercaya: paket sumber terbuka, proses build, akun penerbit, atau artefak yang dipasang ke produksi. Karena itu, memindai kerentanan saja tidak cukup. Tim perlu dapat menjawab tiga pertanyaan: komponen apa yang dipakai, siapa yang mengubahnya, dan apakah hasil build yang dipasang benar-benar berasal dari proses yang disetujui.
Panduan ini menyusun kontrol minimum yang bisa diterapkan bertahap oleh tim pengembang kecil maupun organisasi yang memiliki banyak repositori. Landasannya bukan sekadar opini: NIST Secure Software Development Framework (SSDF) 1.1 mengelompokkan praktik pengembangan aman ke dalam persiapan organisasi, perlindungan perangkat lunak, produksi perangkat lunak yang aman, dan respons terhadap kerentanan. Sementara itu, CISA menjelaskan SBOM sebagai inventaris berlapis komponen penyusun perangkat lunak.
Tujuannya bukan membuat seluruh dependensi otomatis aman. Hasil akhirnya adalah jejak keputusan yang dapat diaudit dan kemampuan mempersempit dampak ketika satu paket bermasalah.
Mulai dari inventaris dependensi dan pemiliknya
Kontrol pertama adalah mengetahui apa yang benar-benar masuk ke aplikasi. Simpan lockfile di repositori dan gunakan mode instalasi yang mematuhi lockfile, bukan menyelesaikan ulang versi ketika pipeline berjalan. Bedakan dependensi produksi, pengembangan, dan alat build karena ketiganya memiliki jalur risiko berbeda. Paket yang hanya dipakai saat build tetap dapat mencuri token atau memodifikasi keluaran jika menjalankan skrip instalasi.
Buat inventaris sederhana per layanan yang mencatat repositori, pemilik internal, ekosistem paket, lockfile, artefak keluaran, dan lingkungan deployment. Tambahkan SBOM dalam format yang dapat diproses mesin, misalnya SPDX atau CycloneDX. SBOM adalah peta komponen, bukan sertifikat keamanan: daftar itu baru berguna jika disimpan bersama versi rilis dan dihubungkan dengan basis data kerentanan serta proses respons.
- Wajib: lockfile konsisten, pemeriksaan perubahan dependensi dalam pull request, dan pemilik layanan yang jelas.
- Disarankan: SBOM dibuat dari proses build untuk setiap rilis, lalu disimpan bersama artefak.
- Hindari: menganggap dependensi transitif tidak penting hanya karena tidak tercantum langsung pada manifest.
Untuk penyaringan awal proyek sumber terbuka, OpenSSF Scorecard dapat membantu memeriksa sinyal seperti perlindungan branch, pembaruan dependensi, review kode, dan praktik rilis. Skor tersebut adalah masukan penilaian, bukan alasan tunggal menerima atau menolak paket. Tim tetap harus menilai kebutuhan bisnis, aktivitas pemelihara, hak akses paket, dan konsekuensi jika komponen berhenti dirawat.
Checklist keamanan supply chain pada saat paket masuk
Setiap penambahan atau peningkatan dependensi sebaiknya melewati gerbang yang sama. Pertama, pastikan nama paket dan sumber registrinya tepat untuk mengurangi risiko typosquatting atau dependency confusion. Kedua, tinjau perubahan kepemilikan, skrip instalasi, izin jaringan, dan lompatan versi besar. Ketiga, jalankan uji otomatis serta pemindaian rahasia dan kerentanan sebelum digabungkan.
Registry proxy internal dapat memberi titik kontrol dan cache, tetapi tidak perlu menjadi proyek pertama bagi tim kecil. Nilai awal yang lebih besar biasanya datang dari mengunci versi, membatasi registri yang boleh diakses CI, melindungi token, dan mewajibkan review pada perubahan manifest serta lockfile. Jika organisasi memang memiliki paket privat, gunakan namespace yang jelas dan pemetaan registry eksplisit agar resolver tidak memilih paket publik hanya karena nomor versinya lebih tinggi.
Penundaan otomatis untuk pembaruan non-darurat dapat memberi waktu bagi komunitas menemukan rilis berbahaya, tetapi jangan mengubahnya menjadi aturan kaku. Kerentanan yang sedang dieksploitasi membutuhkan jalur darurat. Pisahkan pembaruan rutin dari perbaikan kritis, lalu tetapkan siapa yang boleh mengesampingkan masa tunggu dan bukti pengujian apa yang harus disertakan.
Lindungi pipeline, bukan hanya kode sumber
Build yang aman harus dapat diulang dan menghasilkan bukti asal-usul. Gunakan runner sementara bila memungkinkan, batasi akses internet keluar, dan berikan kredensial berumur pendek dengan hak minimum. Workflow CI dari pihak ketiga sebaiknya dikunci ke digest atau commit tertentu, bukan tag yang dapat dipindahkan. Rahasia produksi juga tidak semestinya tersedia untuk build pull request dari sumber yang tidak dipercaya.
Kerangka Supply-chain Levels for Software Artifacts atau SLSA memisahkan jaminan pada jalur build dari evaluasi kualitas kode. Provenance menjelaskan di mana, kapan, dan dari sumber apa artefak dibuat. Tanda tangan kemudian mengikat identitas penerbit dengan artefak tersebut. Deployment harus memverifikasi keduanya; tanda tangan yang tidak pernah diperiksa hanya menambah file, bukan kontrol.
Tim dapat menjalankan uji kegagalan sederhana. Ubah digest image, hilangkan provenance, atau gunakan artefak dari pipeline yang tidak disetujui pada lingkungan uji. Jika deployment tetap lolos, kebijakan masih bersifat dokumentasi. Gerbang efektif harus menolak artefak yang tidak memenuhi syarat sebelum mencapai produksi.
Cara memprioritaskan tanpa tenggelam dalam alert
Daftar CVE yang panjang bukan urutan kerja. Prioritas perlu menggabungkan empat hal: apakah komponen berada di produksi, apakah kode rentan dapat dijangkau, apakah ada eksploitasi aktif, dan seberapa besar dampak layanan jika disalahgunakan. Paket dengan skor tinggi tetapi tidak pernah dieksekusi bisa berada di bawah komponen berisiko sedang yang menerima input internet dan berjalan dengan hak tinggi.
Hubungkan setiap temuan ke layanan dan pemiliknya. Prinsip yang sama juga berguna ketika melakukan audit keamanan AI agent: izin dan jalur data harus terlihat sebelum risiko bisa diprioritaskan. Untuk pemeriksaan dari sudut pandang penyerang, metode audit jejak digital yang aman membantu menemukan artefak publik, nama paket internal, atau kredensial yang semestinya tidak terekspos.
Tentukan target respons berdasarkan konteks, bukan satu tenggat untuk seluruh CVE. Contohnya, komponen yang sedang dieksploitasi dan dapat dijangkau dari internet masuk jalur insiden; kerentanan tanpa jalur eksekusi dapat menunggu siklus terencana sambil didokumentasikan. Keputusan menunda tetap perlu pemilik, alasan, dan tanggal evaluasi ulang.
Rencana penerapan 30, 60, dan 90 hari
Hari 1–30: petakan repositori dan layanan produksi, tunjuk pemilik, wajibkan lockfile, aktifkan review perubahan dependensi, dan cabut token CI yang terlalu luas. Ukur persentase layanan yang memiliki inventaris dan pemilik; jangan memakai jumlah alert sebagai ukuran kemajuan.
Hari 31–60: buat SBOM pada proses build, simpan bersama rilis, aktifkan pembaruan dependensi melalui pull request, dan kelompokkan temuan berdasarkan keterjangkauan serta lingkungan. Uji apakah tim bisa mencari semua layanan yang memakai satu nama dan versi paket dalam waktu singkat.
Hari 61–90: hasilkan provenance, tanda tangani artefak, dan terapkan verifikasi pada lingkungan uji sebelum produksi. Jalankan simulasi paket kompromi: identifikasi layanan terdampak, hentikan deployment, rotasi kredensial yang mungkin terekspos, bangun ulang dari sumber tepercaya, dan dokumentasikan keputusan.
Checklist keamanan supply chain yang matang bukan daftar alat belanja. Nilainya terlihat ketika organisasi dapat menolak artefak yang asal-usulnya tidak jelas, menemukan pemakaian komponen bermasalah tanpa menyisir repositori satu per satu, dan memulihkan layanan dengan bukti yang dapat diaudit. Mulailah dari inventaris dan hak akses, lalu naikkan jaminan build secara bertahap; kontrol yang sederhana tetapi benar-benar ditegakkan lebih berguna daripada kerangka lengkap yang hanya ada di dokumen.
