Bahaya Kunci API Bocor di Repositori Publik

Bahaya Kunci API Bocor di Repositori Publik – Meskipun platform GitHub telah menerapkan berbagai langkah keamanan untuk mencegah kebocoran data sensitif, lebih dari 543.000 kredensial yang terekspos di repositori publik ternyata masih valid dan dapat digunakan hingga bulan Juli.

Berdasarkan analisis data dari pemindaian terhadap 224 juta repositori dan lebih dari 58 miliar file, terungkap bahwa median waktu sebuah kredensial unik dapat diakses secara publik mencapai 784 hari.

Penelitian ini dilakukan oleh peneliti dari perusahaan keamanan siber Truffle Security. Mereka menemukan bahwa sekitar 10% dari kredensial yang masih aktif tersebut berusia lebih dari 6,3 tahun, di mana kredensial tertua bahkan berasal dari tahun 2009.

Secara keseluruhan, terdapat 543.699 kredensial unik yang muncul secara berulang di lebih dari 1,1 juta file dan repositori (termasuk salinan dari hasil fork).

Perbandingan dengan Platform Lain dan Kepadatan Rahasia

Jumlah kredensial terekspos di GitHub ini tercatat lebih dari dua kali lipat dibanding temuan serupa saat peneliti memindai platform Hugging Face pada Agustus sebelumnya, di mana saat itu ditemukan 221.303 kredensial aktif.

Selain itu, peneliti mencatat bahwa kepadatan rahasia (secret density) terus meningkat dari tahun ke tahun:

Jumlah kredensial aktif naik dari 3,72 per juta file pada tahun 2015.
Angka tersebut melonjak hingga mencapai puncaknya di angka 11,62 per juta file pada tahun 2025.

Efektivitas Fitur Push Protection dari GitHub

GitHub sebenarnya telah meluncurkan mekanisme pengamanan bernama Push Protection (untuk memindai pola rahasia seperti kunci API dan token akses serta memblokir unggahan jika terdeteksi) bagi pengguna publik sejak Mei 2023 dan menjadikannya fitur bawaan (default) pada awal 2024.

Kendati demikian, mekanisme ini memiliki keterbatasan:

Fitur ini hanya memblokir unggahan baru, tetapi tidak secara otomatis mencabut (revoke) kredensial yang telanjur terekspos di masa lalu.
Sekitar 199.843 dari kredensial yang teridentifikasi (36.8% dari total) justru terekspos setelah GitHub mengaktifkan Push Protection secara default.
Sedikit lebih dari setengah (51.8%) dari kredensial aktif ternyata masuk ke dalam kategori yang tidak diblokir oleh perlindungan bawaan GitHub, seperti string koneksi database dan kunci API Google.

Meskipun demikian, Push Protection tetap menunjukkan efektivitas pada cakupannya: tingkat paparan kredensial pada kategori yang dilindungi tercatat turun sebesar 53% setelah fitur tersebut diaktifkan secara massal.

Perbedaan Tingkat Pencabutan Berdasarkan Layanan

Tidak semua kredensial memiliki tingkat keamanan yang sama setelah bocor. Data menunjukkan tingkat pencabutan (revocation) yang sangat bervariasi:

Token npm: Dari 101.886 token npm yang diunggah, hanya 1 token yang masih berfungsi saat diuji oleh peneliti.
Kredensial Google Cloud: Dari 126.963 kredensial akun layanan Google Cloud yang terekspos, 69.041 di antaranya masih valid dan aktif digunakan pada saat analisis dilakukan.

Mitigasi Keamanan

Untuk mencegah kebocoran kunci rahasia, token API, dan kredensial penting di repositori kode Anda, berikut langkah mitigasinya:

Jangan pernah menanamkan (hardcode) kata sandi, kunci API, atau token akses langsung ke dalam kode sumber aplikasi. Simpan di dalam file .env atau manajer rahasia yang aman.
Pastikan fitur perlindungan unggahan otomatis di platform penampung kode (seperti GitHub Push Protection) selalu aktif untuk mendeteksi rahasia sebelum terpublikasi.
Integrasikan alat pemindai rahasia (secret scanners seperti TruffleHog atau GitGuardian) ke dalam alur kerja CI/CD Anda secara otomatis.
Atur masa kedaluwarsa singkat untuk semua token API, kunci enkripsi, dan kredensial akses layanan aktif.
Jika sebuah kunci atau token tidak sengaja terunggah ke repositori publik, anggap data tersebut telah disusupkan dan segera lakukan rotasi (revoke and replace) di sistem terkait.
Menghapus file berisi rahasia dari direktori aktif tidak cukup; Anda harus membersihkan riwayat commit menggunakan alat seperti git-filter-repo atau BFG Repo-Cleaner.
Gunakan perangkat lunak perlindungan dan pemantauan endpoint (seperti lini produk ESET) untuk mengamankan perangkat kerja pengembang dari risiko pencurian kredensial lokal.

Baca artikel lainnya: