Di episode #17 kita bahas rantai pasok software — bagaimana dependensi yang kita percaya bisa jadi jalan belakang masuknya serangan. Hari ini saya mau catat satu pelajaran yang lebih personal, yang bahkan sering saya lakukan sendiri tanpa sadar: menyimpan rahasia di dalam kode. API key, password database, token layanan cloud — semua pernah saya tempel langsung di file konfigurasi “biar cepat”, lalu commit. Ternyata kebiasaan kecil ini termasuk penyebab kebocoran data terbesar di dunia developer saat ini, dan git adalah arsip yang tidak pernah lupa.
Angka yang membuat saya berhenti “tempel dulu”
GitGuardian merilis laporan State of Secrets Sprawl edisi ke-5 pada 17 Maret 2026, berisi data sepanjang 2025. Angkanya bikin saya melongo: sekitar 29 juta rahasia (secrets) terdeteksi di GitHub publik sepanjang 2025 — lonjakan 34% dibanding tahun sebelumnya, dan yang terbesar yang pernah tercatat. Lebih menyentuh lagi: sejak 2021 jumlah secret tumbuh kira-kira 1,6× lebih cepat daripada jumlah developer aktif. Artinya bukan cuma developer yang bertambah — kebiasaan buruknya ikut terbawa dan menguat.
Ada temuan yang langsung menyentuh workflow saya sebagai programmer yang sekarang rajin memakai AI: kode yang dihasilkan bantuan AI punya laju kebocoran secret sekitar dua kali rata-rata baseline GitHub. Kita copy-paste output AI yang memuat contoh kredensial, lalu tidak sempat menggantinya sebelum commit. Kebocoran kredensial layanan AI sendiri melonjak 81% year-on-year, dan pola konfigurasi MCP yang menaruh kredensial di file konfigurasi berkontribusi lebih dari 24.000 secret yang terekspos. Ini berarti bagi saya: makin cepat alat bantu menulis kode, makin cepat pula kecerobohan kita terarsip.
Kenapa git mengubah “kesalahan kecil” jadi masalah permanen
Saya dulu mengira menghapus API key dari file lalu commit ulang sudah menyelesaikan masalah. Ternyata tidak. Git menyimpan setiap versi file di riwayatnya. Key yang pernah ter-commit tetap hidup di commit lama — siapa pun yang clone repo (atau penyerang yang memindai GitHub secara otomatis) bisa menggali keluar dengan perintah sederhana:
# menggali file konfigurasi lama dari riwayat git log -p --all -- .env # cari pola key di seluruh riwayat repo git log -p --all | grep -iE "api[_-]?key|secret|password"
Cara yang benar bukan “hapus dari HEAD”, tapi: anggap secret yang pernah masuk git sudah bocor → rotasi (regenerate) kredensial di sistem asal, lalu bersihkan riwayat dengan tool seperti git filter-repo, dan paksa push. Mahal, ribet, dan merepotkan semua orang yang sudah clone. Karena itu sekarang saya lebih memilih mencegah sejak baris pertama: secret tidak boleh menyentuh git sama sekali, sampai ke file .env pun tidak.
env vs vault: dua level perlindungan
Setelah paham ruginya, saya membandingkan dua pendekatan yang paling umum. Environment variable / file .env memindahkan rahasia dari kode ke konfigurasi — langkah pertama yang baik. Secret vault (HashiCorp Vault, AWS Secrets Manager, dan sejenisnya) menambah lapisan: rahasia dienkripsi saat disimpan, di-audit siapa yang membacanya, dan bisa di-rotasi otomatis dengan umur pendek.
| Aspek | File .env / env var | Secret vault |
|---|---|---|
| Penyimpanan | Plain text di server | Terenkripsi, akses terkontrol |
| Riwayat akses | Tidak ada audit trail | Log siapa ambil secret apa, kapan |
| Rotasi | Manual, sering telat | Otomatis, token umur pendek |
| Kebocoran git | Masih mungkin kalau tidak di-.gitignore | Tidak tersentuh git |
| Kerumitan setup | Rendah — cocok proyek kecil | Tinggi — worth it untuk tim/produksi |
Komentar Terbaru