Kebocoran rahasia di repositori Git sering terjadi bukan karena serangan yang rumit, tetapi karena kebiasaan pengembangan yang terburu-buru. Kunci API, token akses, kata sandi basis data, atau kredensial layanan cloud dapat ikut ter-commit saat pengembang menambahkan berkas konfigurasi, skrip pengujian, atau contoh kode. Dalam lingkungan kolaboratif, satu kesalahan kecil dapat menyebar ke banyak salinan repositori, termasuk fork, clone, dan cadangan. Karena itu, topik ini bukan sekadar masalah kebersihan kode, melainkan bagian dari keamanan sistem dan perlindungan data.

Artikel ini membahas mengapa rahasia yang pernah masuk ke riwayat Git tidak hilang hanya dengan menghapus berkasnya, mengapa kunci yang bocor harus dicabut dan diganti, serta bagaimana alat seperti gitleaks membantu memindai repositori. Pembahasan difokuskan pada sistem milik sendiri atau yang telah diizinkan, dengan tujuan pembelajaran etis dan pencegahan, bukan eksploitasi. Pemula perlu memahami bahwa kesalahan konfigurasi kecil dapat berdampak besar jika rahasia tersebut memiliki izin luas atau tidak memiliki masa berlaku.

Untuk memperdalam konsep keamanan repositori dan pengujian etis pada lingkungan sendiri, sumber belajar seperti kalilinux.net atau kalilinux.info dapat dijadikan referensi lanjutan. Fokus utama tetap pada pencegahan: jangan menaruh rahasia di kode, batasi izin kunci, dan verifikasi setiap perubahan sebelum dikirim ke repositori bersama.

Mengapa penghapusan berkas tidak cukup

Git dirancang untuk menyimpan riwayat secara lengkap. Setiap commit adalah snapshot dari kondisi repositori, bukan sekadar perubahan terakhir. Bila sebuah rahasia pernah masuk pada commit lama, Git tetap menyimpannya pada commit tersebut meskipun berkasnya dihapus pada commit berikutnya. Penghapusan berkas hanya membuat berkas tidak tampak pada pohon kerja saat ini, tetapi tidak menghapus data dari riwayat.

Rahasia lama masih dapat diakses melalui hash commit, branch lama, tag, reflog, atau salinan repositori yang sudah di-clone. Pada repositori yang sudah di-push, commit lama juga dapat tetap ada di server sampai referensi dibersihkan dan garbage collection dijalankan. Fork dan clone yang dibuat sebelum pembersihan tetap membawa riwayat lama. Jadi, menghapus berkas adalah langkah tampilan, bukan langkah keamanan.

Karena itu, asumsi yang aman adalah: jika rahasia pernah masuk ke riwayat Git, rahasia tersebut harus dianggap terekspos. Semakin luas akses kunci tersebut, semakin besar dampaknya. Kunci dengan izin administratif, akses basis data produksi, atau kemampuan mengubah infrastruktur harus ditangani sebagai insiden keamanan, bukan sekadar kesalahan kode.

Tindakan pertama saat rahasia bocor

Prioritas utama saat rahasia bocor adalah memutus akses, bukan membersihkan kode. Kunci yang bocor harus dicabut dan diganti, bukan sekadar dihapus dari repositori. Langkah pertama adalah mencabut kunci atau token melalui konsol penyedia layanan, lalu membuat kredensial baru dengan izin minimal. Setelah itu, perbarui aplikasi, layanan, dan pipeline deployment agar menggunakan kredensial baru.

Jika yang bocor adalah kata sandi basis data, ubah kata sandi dan periksa akun, tabel, atau data yang mungkin diubah. Jika yang bocor adalah token OAuth, cabut grant dan periksa scope yang diberikan. Jika yang bocor adalah kunci SSH privat, hapus kunci dari server dan buat pasangan kunci baru. Audit log juga penting untuk mengetahui apakah kunci tersebut sempat digunakan oleh pihak yang tidak berwenang.

Setelah akses diputus, tim dapat membersihkan riwayat repositori agar rahasia tidak lagi tersimpan pada commit lama. Namun, pembersihan riwayat tidak menghapus salinan yang sudah tersebar. Force push juga dapat mengganggu kolaborator yang sedang bekerja. Karena itu, pembersihan riwayat adalah langkah tambahan, bukan pengganti pencabutan kunci. Jika repositori bersifat publik, anggap rahasia sudah terlihat oleh pihak lain.

Mencegah sejak awal: kebiasaan dan konfigurasi

Pencegahan paling efektif dimulai dari kebiasaan pengembang. Jangan hardcode rahasia di kode sumber. Gunakan variabel lingkungan dan simpan nilai nyata di luar repositori, misalnya pada berkas .env yang diabaikan Git. Sediakan berkas .env.example yang hanya berisi nama variabel tanpa nilai nyata, sehingga pengembang baru tahu konfigurasi yang dibutuhkan tanpa melihat rahasia.

Berkas .gitignore harus menyertakan berkas yang berpotensi menyimpan rahasia. Contoh sederhana:

.env
*.pem
*.key
secrets/

Sebelum commit, periksa perubahan yang akan disimpan dengan git diff --cached. Kebiasaan ini membantu menemukan kunci yang tidak sengaja masuk ke staging area. Gunakan kunci dengan izin minimal, masa berlaku pendek, dan rotasi berkala. Kunci yang hanya dapat membaca data tertentu lebih aman daripada kunci dengan akses penuh.

Review kode juga penting, terutama pada pull request yang menyentuh konfigurasi, deployment, atau integrasi layanan. Jangan menaruh rahasia di issue, komentar pull request, log aplikasi, atau tangkapan layar. Jika rahasia pernah muncul di log, perlakukan log tersebut sebagai data sensitif dan batasi aksesnya.

Memindai repositori dengan gitleaks

Alat seperti gitleaks dapat memindai repositori untuk menemukan rahasia. gitleaks mencari pola yang menyerupai token, kunci privat, kata sandi, dan kredensial lain pada riwayat serta berkas repositori. Pemindaian dapat dijalankan pada repositori milik sendiri sebagai bagian dari audit berkala atau sebelum kode dikirim ke repositori bersama.

Contoh perintah dasar:

gitleaks detect --source .

Hasil pemindaian dapat digunakan untuk menemukan kebocoran