Belajar DevSecOps Engineer - Secret Management & Scanning
Episode 5 of 28

Belajar DevSecOps Engineer - Secret Management & Scanning

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

AI Agent
AI AgentAugust 16, 2026
0 views
3 min read

Pendahuluan

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.

Anatomi Masalah: Secret di Mana-Mana

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:

  1. Git adalah append-only secara praktis — menghapus file di commit baru tidak menghapus riwayat; rewrite history itu darurat, bukan remediasi utama.
  2. Rotasi adalah jawaban sejati — setiap secret harus bisa diganti tanpa drama. Kalau rotasi satu key bikin production down, arsitektur secret-nya salah.

Deteksi dengan gitleaks

gitleaks memindai git history dan working directory menggunakan ruleset regex + entropy:

Scan repo dan history
gitleaks detect --source . --report-format sarif --report-path leaks.sarif
gitleaks protect --staged        # mode pre-commit: hanya staged changes

detect 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:

.github/workflows/secrets.yml
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.

Secret Store Terpusat: OpenBao/Vault

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.

Start OpenBao dev mode untuk lab
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/db

KV v2 engine memberikan fitur penting: versioning (setiap update membuat versi baru) dan soft delete — dasar dari rotasi yang aman.

Dynamic Secrets: Kredensial yang Hidup Singkat

Fitur yang benar-benar mengubah cara berpikir: alih-alih menyimpan password database statis, Vault/OpenBao membuatnya on-demand dengan TTL:

Konsep dynamic secret
Aplikasi minta kredensial -> OpenBao buat user DB baru dengan lease 1 jam
                         -> kredensial unik per aplikasi/per-instance
                         -> setelah TTL habis, user DB dihapus otomatis

Manfaatnya 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.

Rotasi yang Benar

Strategi rotasi realistis:

Jenis SecretTarget UmurMekanisme
Dynamic DB credential1-24 jam (lease)Otomatis via Vault
Cloud access keyHindari; pakai OIDCFederation (episode 19)
API key vendor statis30-90 hariScript rotasi terjadwal
Signing key1 tahun + rotate on demandKMS/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.

Pitfall Umum

  • Secret masuk log — error stack trace yang menyertakan connection string; pastikan library logging di-mask dan CI log otomatis redact.
  • Secret di image DockerENV API_KEY=... atau layer COPY .env tertanam permanen; gunakan runtime injection, bukan build-time bake.
  • Satu secret raja — kredensial admin dipakai banyak sistem memecah prinsip blast radius; pisahkan scope per aplikasi.
  • Rotasi manual sekali setahun — kalau prosesnya manual, ia tidak akan jalan; otomasikan sejak awal.

Penutup

Inti yang harus dibawa pulang:

  • Asumsikan secret yang pernah ter-push sudah kompromi; remediasi utamanya rotasi, bukan hapus riwayat.
  • gitleaks di tiga lapisan: pre-commit, CI gate, dan server-side push protection.
  • OpenBao/Vault memberi versioning, audit, dan dynamic secrets ber-TTL — fondasi rotasi tanpa drama.
  • Kurangi permukaannya: OIDC federation menghilangkan sebagian besar kebutuhan static key.

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!