Keamanan Repo: Dependabot dan Secret Scanning

Dependency-mu adalah tanggung jawabmu

Rata-rata proyek modern menarik ratusan paket dari internet. Setiap paket adalah kode orang lain yang berjalan di aplikasimu, dan sesekali salah satunya ketahuan punya celah keamanan. Masalahnya, tidak ada manusia yang sempat memantau ratusan changelog setiap hari. Di sinilah fitur keamanan GitHub bekerja: ia memantau untukmu, lalu mengetuk pintu saat ada bahaya.

Kenapa ini penting dipelajari sekarang, bukan nanti? Karena kebiasaan buruk paling mahal adalah menunda update dependency sampai aplikasinya berumur dua tahun dan upgrade-nya berubah menjadi proyek migrasi raksasa. Update kecil yang rutin jauh lebih murah daripada update raksasa yang menakutkan.

Dependabot alerts dan security updates

Buka tab Security di repomu. Kalau ada dependency yang diketahui rentan, GitHub menampilkannya sebagai Dependabot alert lengkap dengan tingkat keparahan (low, moderate, high, critical) dan versi aman yang disarankan. Alert ini muncul otomatis untuk repo publik, dan bisa diaktifkan untuk repo privat di pengaturan.

Dependabot bisa lebih dari sekadar memberi tahu: ia bisa membuka PR otomatis yang menaikkan versi dependency ke versi aman. Kamu tinggal review dan merge, seperti PR biasa. Untuk mengaktifkan update versi rutin (bukan cuma saat ada celah), tambahkan file .github/dependabot.yml:

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"

Dengan config ini, setiap minggu Dependabot memeriksa apakah ada versi baru dependency-mu dan membuka PR update. Kamu dapat pipeline "titisan update" yang stabil alih-alih kejutan besar setahun sekali. Contoh PR-nya berjudul seperti "Bump lodash from 4.17.20 to 4.17.21", lengkap dengan catatan rilis dan skor kompatibilitas.

Secret scanning: alarm kebocoran kunci

Skenario horor klasik: seseorang tidak sengaja commit file .env berisi API key, push ke GitHub, dan key itu dipanen bot dalam hitungan menit. Secret scanning adalah fitur GitHub yang memindai repo dan mengenali pola token terkenal (AWS keys, Stripe keys, dan banyak lagi). Untuk repo publik ia aktif otomatis; untuk privat bisa diaktifkan, termasuk push protection yang menolak push berisi secret sebelum sempat masuk repo.

Kalau alert muncul, jangan panik tapi jangan santai juga. Langkah yang benar: pertama, cabut/revoke secret itu di dashboard penyedianya (kunci yang sudah bocor harus dianggap sudah dikompromikan, tidak peduli "kayaknya belum ada yang lihat"). Kedua, hapus dari riwayat Git jika perlu (tapi ingat, revoke tetap langkah nomor satu karena riwayat yang sudah ter-push tidak bisa ditarik kembali dari orang yang sudah meng-clone). Ketiga, ganti dengan secret baru yang disimpan di environment variable atau secret manager, bukan di file yang ter-commit.

Pencegahan termurahnya tetap .gitignore yang benar sejak hari pertama:

# jangan pernah commit file ini
.env
*.pem
credentials.json

Satu baris .env di .gitignore mencegah 90 persen insiden kebocoran secret yang dialami pemula.

Security advisories dan private vulnerability reporting

Repo juga bisa menerbitkan security advisory: pengumuman resmi "versi X punya celah, upgrade ke Y" yang tampil di tab Security dan dikirim ke pengguna yang menandai repo sebagai dependency. Fitur terkaitnya, private vulnerability reporting, memungkinkan peneliti keamanan melaporkan celah ke maintainer secara privat alih-alih membukanya sebagai issue publik yang bisa dibaca penyerang. Untuk maintainer proyek open source, mengaktifkan ini adalah standar kesopanan keamanan modern.

Kesalahan umum pemula

Salah: mengabaikan Dependabot alert critical selama berbulan-bulan karena "aplikasinya jalan normal kok". Celah keamanan tidak membuat aplikasi error, ia membuat aplikasi bisa dieksploitasi diam-diam. Benar: perlakukan alert high/critical seperti bug P1. Review PR Dependabot mingguan sebagai rutinitas, bukan saat sempat.

Salah: setelah API key bocor ke repo, hanya menghapus file-nya di commit berikutnya dan menganggap masalah selesai. Benar: revoke key-nya dulu di dashboard penyedia, karena commit penghapusan tidak menghapus riwayat dan key lama tetap bisa dipakai siapa pun yang sempat melihatnya.