Hari 3: Ngecek Kebocoran Secret di Kode Pakai Gitleaks

Apa Itu Secret Scanning dan Kenapa Penting?

Pernah ga sengaja commit password, API key, atau token ke GitHub? Itu kejadian yang sering banget terjadi — dan kalo sampai masuk ke public repo, dampaknya bisa besar. Secret yang bocor di kode bisa dipake orang lain buat akses server, database, atau layanan cloud kita.

Gitleaks itu tool yang otomatis nyari secret yang bocor di dalam kode dan git history. Jadi sebelum secret sampai ke remote repository, kita bisa ketahuan lebih dulu.

Hari ketiga challenge 60 hari DevSecOps itu fokusnya ke sini: install Gitleaks, scan repo SecureBank API, dan buat konfigurasi buat nge-exclude false positive.

Apa yang Dilakukan Hari Ini

Langkah pertama tentu install Gitleaks. Karena brew install timeout (koneksinya lagi lambat), akhirnya download binary langsung dari GitHub releases — versi 8.21.2 buat macOS ARM64.

Bikin Branch Palsu Buat Ngetes

Bikin branch test/secret-leak yang isinya file configs/database.go dengan tiga fake secret:

• DBPassword = "SuperSecret123!"
• AWSKey = "AKIAIOSFODNN7EXAMPLE"
• AWSSecret = "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"

Tujuannya buat ngetes apakah Gitleaks bisa nyari secret yang sengaja ditaruh di kode.

Hasil Scan Tanpa Config

Jalanin gitleaks detect --source . -v dan hasilnya menarik: Gitleaks nemuin 1 finding, tapi bukan dari file yang kita bikin. Finding-nya ada di docs/fase-1-appsec.md — itu bagian dokumentasi tutorial yang isinya contoh Stripe key.

Yang lebih menarik: fake AWS key (AKIAIOSFODNN7EXAMPLE) ga dilaporkan sama Gitleaks. Kenapa? Karena Gitleaks cukup pintar buat ngenali kalo itu adalah AWS example key yang emang bukan secret asli. Jadi bukan false positive, tapi behavior yang bener.

Bikin .gitleaks.toml dan Scan Ulang

Buat file konfigurasi .gitleaks.toml di root repo buat nge-exclude:

• go.sum — file dependensi Go yang sering trigger false positive
• vendor/ — folder dependensi lokal
• docs/ — berisi contoh secret di dokumentasi tutorial

Jalanin scan ulang pakai config: 0 leaks found. Bersih!

Bersih-Bersih

Setelah konfirmasi Gitleaks bekerja bener, branch test/secret-leak dihapus. File yang berisi fake secret ga pernah masuk ke branch main.

Yang Agak Ngejelimet

Brew Timeout, Pake Binary Langsung

Pengalaman install Gitleaks lewat Homebrew langsung timeout karena koneksi lagi lambat. Solusinya download binary langsung dari GitHub releases — cuma perlu file sekitar 2.8MB buat macOS ARM64, terus copy ke /opt/homebrew/bin/. Lebih cepat dan ga perlu compile.

Dokumentasi Jadi Sumber False Positive

File docs/fase-1-appsec.md berisi contoh secret buat tutorial. Gitleaks baca ini sebagai kebocoran nyata. Makanya penting banget buat nge-exclude docs/ di .gitleaks.toml — biar scanner fokus ke kode asli, bukan ke konten dokumentasi.

Gitleaks Lebih Pintar dari yang Dikira

Fake AWS key AKIAIOSFODNN7EXAMPLE sengaja ditaruh di kode, tapi Gitleaks ga melaporkannya. Bukan bug — ini fitur. Gitleaks punya database example key yang dikenali sebagai bukan secret asli. Jadi ga perlu manually exclude hal-hal yang udah jelas bukan risiko.

Lesson Learned

1. Secret scanning itu harus jadi layer pertama pertahanan. Sebelum masuk ke SAST atau SCA, secret scanning harus jadi pintu masuk pertama. Kalo ada credential yang bocor, kerusakan bisa langsung besar — ga perlu exploit yang rumit, tinggal pake credential yang udah kasih lihat.

2. Tool security harus di-config, bukan langsung pake. Default config Gitleaks udah bagus, tapi setiap repo punya konteks beda. Di kasus ini, folder docs/ berisi contoh secret buat tutorial — kalo ga di-exclude, bakal false positive terus.

3. Branch terpisah itu strategi paling aman buat ngetes. Daripada commit secret ke main terus rollback, lebih baik bikin branch test yang sengaja berisi secret. Setelah verifikasi selesai, hapus branch-nya. Git history-nya pun ga bakal nyimpen secret di main.

4. Dokumentasi bisa jadi sumber kebocoran palsu. Contoh secret di dokumentasi tutorial sering banget dilaporkan sebagai finding. Selalu exclude folder dokumentasi dari secret scan, atau pake komentar gitleaks:allow di baris yang emang sengaja berisi contoh.

Kesimpulan

Hari ini berhasil install Gitleaks, scan seluruh repo, nemuin 1 finding dari dokumentasi, bikin konfigurasi buat exclude false positive, dan verifikasi bahwa scan bersih (0 leaks). Semuanya dilakukan secara lokal sebelum nanti di-integrasikan ke pipeline CI/CD.

Bagian yang bikin senang: Gitleaks ternyata cukup pintar buat ngenali AWS example key sebagai bukan secret asli. Ini ngurangi false positive secara signifikan dan bikin hasil scan lebih bisa dipercaya.

Besok lanjut ke Hari 4: Integrasi Gitleaks ke GitHub Actions pipeline — biar setiap push dan PR otomatis di-scan dan pipeline gagal kalau ada secret yang bocor.

Repo: github.com/stayrelevantid/chalange-devsecops