Secret adalah kredensial paling berharga sekaligus paling sering bocor; di episode ini kalian mendeteksi kebocoran dengan gitleaks, membangun secret store terpusat dengan OpenBao/Vault, memahami dynamic secrets dan lease, serta menyusun strategi rotasi sehingga satu kredensial bocor tidak berujung kompromi total

Setelah episode 4 melengkapi pipeline dengan scanner kode dan dependency, kita beralih ke aset yang paling sering menyebabkan insiden nyata: secret. Statistik insiden konsisten menempatkan kredensial bocor sebagai vektor awal breach nomor satu — bukan zero-day, bukan exploit canggih, melainkan API key yang ter-commit lupa hapus.
Dua sisi masalah ini akan kita kerjakan bersamaan: scanning (menangkap secret yang mencoba lolos ke repository) dan management (memastikan meskipun satu secret bocor, dampaknya terbatas dan mudah dirotasi). Kalian akan memakai gitleaks untuk deteksi dan OpenBao/Vault untuk penyimpanan.
Perjalanan buruk secret yang khas: developer butuh cepat → taruh API_KEY=sk-live-... di .env → commit .env karena .gitignore tidak lengkap → repo di-push ke GitHub → bot scanner attacker menemukannya dalam hitungan menit. Bot pencari secret memindai semua push publik secara real-time — asumsi kalian adalah secret yang pernah ter-push sudah kompromi, tanpa kecuali.
Konsekuensinya, dua prinsip dasar:
gitleaks memindai git history dan working directory menggunakan ruleset regex + entropy:
gitleaks detect --source . --report-format sarif --report-path leaks.sarif
gitleaks protect --staged # mode pre-commit: hanya staged changesdetect memindai seluruh history (untuk audit awal), sedangkan protect --staged cocok sebagai hook lokal — mencegah secret masuk commit sama sekali. Integrasi CI-nya sebagai gate blocking:
name: Secret Scanning
on:
pull_request:
jobs:
gitleaks:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0 # butuh full history untuk scan menyeluruh
- uses: gitleaks/gitleaks-action@v2
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}Important
Jalankan scanning di tiga lapisan: pre-commit hook (cepat, mencegah), CI gate (blokir merge), dan server-side secret scanning (GitHub Push Protection menolak push berisi secret bahkan sebelum sampai server). Lapisan pertama opsional, dua terakhir wajib.
Menyimpan secret di platform CI lebih baik daripada di repo, tetapi masih punya masalah: tersebar per-repo, sulit diaudit, dan tidak ada rotasi otomatis. Solusinya secret store terpusat. OpenBao adalah fork open source dari HashiCorp Vault setelah lisensi berubah — keduanya kompatibel CLI/API, series ini memakai istilah Vault untuk konsepnya.
bao server -dev &
export BAO_ADDR="http://127.0.0.1:8200"
export BAO_TOKEN="root"
# simpan secret ke path KV v2 (data/ otomatis ditambahkan)
bao kv put secret/myapp/db username=app password=S3cr3t!
bao kv get secret/myapp/dbKV v2 engine memberikan fitur penting: versioning (setiap update membuat versi baru) dan soft delete — dasar dari rotasi yang aman.
Fitur yang benar-benar mengubah cara berpikir: alih-alih menyimpan password database statis, Vault/OpenBao membuatnya on-demand dengan TTL:
Aplikasi minta kredensial -> OpenBao buat user DB baru dengan lease 1 jam
-> kredensial unik per aplikasi/per-instance
-> setelah TTL habis, user DB dihapus otomatisManfaatnya luar biasa: tidak ada password statis untuk dicuri, setiap instance bisa dilacak lewat kredensialnya sendiri, dan "rotasi" terjadi otomatis setiap lease diperbarui. Untuk cloud, konsep serupa dicapai tanpa Vault sama sekali via workload identity/OIDC — topik episode 19.
Strategi rotasi realistis:
| Jenis Secret | Target Umur | Mekanisme |
|---|---|---|
| Dynamic DB credential | 1-24 jam (lease) | Otomatis via Vault |
| Cloud access key | Hindari; pakai OIDC | Federation (episode 19) |
| API key vendor statis | 30-90 hari | Script rotasi terjadwal |
| Signing key | 1 tahun + rotate on demand | KMS/HSM, cosign keyless |
Prasyarat rotasi tanpa downtime: aplikasi harus membaca secret saat startup dan mendukung refresh tanpa restart (atau minimal restart rolling). Uji rotasi di staging secara berkala — rotasi yang belum pernah dipraktikkan akan gagal justru saat dibutuhkan darurat.
ENV API_KEY=... atau layer COPY .env tertanam permanen; gunakan runtime injection, bukan build-time bake.Inti yang harus dibawa pulang:
Di episode 6 selanjutnya kita naik ke lapisan packaging: Container Image Security — memilih base image minimal, membangun multi-stage yang non-root, scan Trivy/Grype di pipeline, dan persiapan SBOM & signing yang akan menjadi standar supply chain pada episode 12-13. Sampai jumpa!