Build Hijau Bisa Menipu, Pasang Gerbang Dependency Ini

Build CI yang hijau sering terasa seperti lampu hijau untuk merge. Padahal, satu dependency baru bisa membawa lisensi bermasalah, CVE aktif, maintainer yang baru berganti, atau package kecil yang tiba-tiba punya akses ke secret build. Kalau timmu masih mengandalkan review manual di PR, risiko supply chain sudah bergerak lebih cepat daripada checklist manusia.

Kenapa Dependency Baru Harus Diperlakukan Seperti Perubahan Kode

Dependency bukan sekadar “library tambahan”. Ia adalah kode pihak ketiga yang ikut berjalan di build, test, bahkan runtime. Karena itu, dependency review gate in CI seharusnya punya posisi yang sama seriusnya dengan unit test dan SAST.

Selain itu, risiko dependency sering muncul sebelum CVE terbit. Package bisa baru pindah maintainer, rilis versi aneh, mengganti lisensi, atau menambah script install. Jadi, kalau gate hanya mencari CVE, timmu tetap telat.

Apa Itu Dependency Review Gate in CI?

Dependency review gate in CI adalah checkpoint otomatis yang membaca perubahan dependency di pull request, lalu memutuskan apakah build boleh lanjut. Ia biasanya membaca lockfile, manifest package, SBOM, advisory database, dan metadata registry.

Tujuannya sederhana: jangan biarkan dependency berisiko masuk hanya karena test aplikasi lolos. Test membuktikan fitur berjalan. Gate membuktikan perubahan supply chain masih layak diterima.

Risiko yang Wajib Diblokir

• Known vulnerabilities, terutama CVE high dan critical.
• Bad licenses, misalnya GPL masuk ke produk proprietary tanpa approval legal.
• Maintainer change, terutama package populer yang baru pindah owner.
• Install-time scripts, seperti postinstall yang mengeksekusi kode saat CI berjalan.
• Typosquatting, nama package mirip package populer atau package internal.
• Dependency baru tanpa owner, karena nanti tidak ada yang bertanggung jawab saat insiden.

Framework Praktis: ALARM Gate

Banyak tim gagal karena gate dibuat terlalu bising. Akhirnya engineer mencari cara bypass. Supaya gate berguna, pakai framework ALARM: Allow, License, Advisory, Reputation, Maintainer.

A, Allow Policy

Mulai dari daftar ekosistem dan registry yang boleh dipakai. Misalnya npm harus dari registry internal proxy, Composer harus lewat mirror tepercaya, dan package private wajib pakai namespace resmi.

Dengan begitu, kamu mengurangi peluang dependency confusion sejak resolver bekerja. Untuk konteks ini, baca juga cara mencegah dependency confusion pada package internal.

L, License Rules

License gate harus jelas, bukan debat tiap PR. Contohnya, MIT dan Apache-2.0 boleh otomatis, BSD butuh catatan, GPL dan AGPL butuh approval legal. Selain itu, perubahan lisensi dari versi sebelumnya harus selalu ditandai.

A, Advisory Severity

Gunakan data dari OSV, GitHub Advisory Database, dan NVD. Namun, jangan berhenti di skor CVSS. Perhatikan juga apakah dependency berjalan di build, server, browser, atau hanya dev tool lokal.

R, Reputation Signals

Ini bagian yang sering diabaikan. Gate yang matang tidak cuma bertanya “ada CVE nggak?”. Ia juga bertanya, “package ini tiba-tiba populer karena apa?”, “rilis terakhir wajar nggak?”, dan “apakah package ini punya pola nama mencurigakan?”.

Package baru tanpa CVE tetap bisa berbahaya. Karena itu, reputasi package perlu masuk ke skor. Lihat pendekatan lanjutannya di behavior-based package triage.

M, Maintainer Change

Perubahan maintainer adalah sinyal kecil yang bisa berarti besar. Banyak serangan supply chain bermula dari akun maintainer yang dibeli, dibajak, atau “dibantu” oleh pihak baru. Jadi, dependency review gate harus menahan rilis baru setelah perpindahan owner sampai ada review manusia.

Aturan Gate yang Nggak Bikin Developer Membenci Security

Gate yang bagus bukan gate paling galak. Gate yang bagus adalah gate yang tegas pada risiko tinggi, ringan pada update aman. Kalau semua hal butuh approval, tim akan menormalisasi bypass.

• Patch update tanpa dependency baru → boleh auto-merge setelah test hijau.
• Dependency baru langsung → wajib review owner dan security rule.
• Dependency transitif baru → skor berdasarkan jalur eksekusi dan maintainer.
• License berubah → blokir sampai legal atau compliance approve.
• Critical vuln reachable → blokir, kecuali ada exception bertanggal kedaluwarsa.

Ide yang sering terasa aneh, tetapi efektif: jangan blokir semua vulnerability devDependency secara membabi buta. Prioritaskan dependency yang bisa mengeksekusi script, menyentuh network, membaca env var, atau masuk ke artifact produksi. Dengan begitu, security signal tetap tajam.

Implementasi Minimum di GitHub Actions atau GitLab CI

Kamu tidak perlu langsung membangun platform besar. Mulai dari gate kecil yang konsisten. Setelah itu, baru tambahkan exception workflow, ownership, dan dashboard.

# Pseudocode gate
1. Detect changed lockfiles
2. Generate dependency diff
3. Check license policy
4. Check vuln database
5. Score new packages
6. Block high-risk changes
7. Require owner approval for exceptions

Untuk GitHub, kamu bisa mulai dari Dependency Review Action, CodeQL, OSV Scanner, atau tool SCA komersial. Untuk GitLab, gunakan dependency scanning, license scanning, dan policy approval. Referensi resminya bisa kamu cek di GitHub Dependency Review.

Policy Exception Harus Punya Tanggal Mati

Exception permanen adalah utang keamanan yang menyamar sebagai fleksibilitas. Karena itu, setiap bypass harus punya owner, alasan, ticket, scope, dan expiry date. Jika expiry lewat, gate harus gagal lagi.

Format sederhana:

• Package: example-lib
• Risk: CVE high, not runtime reachable
• Owner: platform-security
• Expiry: 14 hari
• Mitigation: pin versi, monitor advisory, patch sprint berikutnya

Metrik yang Perlu Dilihat Engineering Manager

Dependency review gate bukan cuma urusan security team. Engineering manager perlu melihat apakah gate memperlambat delivery atau justru mengurangi incident cost.

• Jumlah dependency baru per sprint.
• Jumlah build yang diblokir karena license.
• Mean time to approve exception.
• Jumlah critical vuln yang masuk branch utama.
• Dependency tanpa owner.

Kalau metrik ini turun, gate bekerja. Kalau developer makin sering meminta bypass, policy terlalu kasar atau feedback dari tool kurang jelas.

FAQ

Apakah dependency review gate sama dengan SCA?

Tidak persis. SCA adalah alat analisis dependency. Dependency review gate adalah keputusan otomatis di CI yang memakai data SCA, license policy, registry metadata, dan approval rule.

Haruskah semua CVE memblokir build?

Nggak selalu. Blokir CVE critical dan high yang reachable, punya exploit aktif, atau masuk artifact produksi. Untuk devDependency yang tidak reachable, gunakan exception bertanggal mati.

Kapan gate wajib minta review manusia?

Minta review manusia saat ada dependency baru, license berubah, maintainer berganti, package baru belum punya reputasi, atau lockfile berubah besar tanpa alasan jelas.

Penutup: Jangan Tunggu Dependency Beracun Masuk Dulu

Dependency review gate in CI mengubah keamanan supply chain dari reaksi panik menjadi kontrol harian. Dengan policy yang jelas, developer tetap cepat, security tetap punya rem, dan manager punya metrik risiko yang nyata.

Kalau kamu sedang merapikan CI security, mulai minggu ini dengan satu gate kecil: blokir dependency baru yang punya CVE critical, lisensi terlarang, atau maintainer change mencurigakan. Mau dapat checklist teknis supply chain berikutnya? Langganan newsletter Google kami di bawah.