Hari 4: Gitleaks di CI, Refactor Config ke Env Var

Dari Scan Lokal ke Scan Otomatis

Kemarin Gitleaks cuma jalan di lokal — kalo lupa jalanin, ya ga kescan. Hari ini langkahnya lebih besar: masukkin Gitleaks ke pipeline CI/CD biar setiap push dan pull request otomatis di-scan. Sekaligus refactor kode biar ga ada lagi config yang hardcode — semuanya pindah ke environment variable.

Job Baru di Pipeline: Secret Scan

Pipeline yang kemarin cuma punya satu job (Build & Test), sekarang punya dua yang jalan paralel:

• Build & Test (Go 1.26) — build, test, upload coverage
• Secret Scan (Gitleaks) — scan seluruh git history buat cari secret yang bocor

Kedua job ini jalan barengan, ga saling tunggu. Jadi kalo ada secret leak, pipeline langsung gagal tanpa harus nunggu build selesai dulu.

Tiga Kali Fix CI

Bukan DevSecOps kalau ga ada error di jalan, kan? Pipeline Gitleaks error tiga kali sebelum akhirnya hijau:

1. Error lisensi — gitleaks/gitleaks-action@v2 sekarang butuh lisensi berbayar. Solusi: ganti dari GitHub Action ke binary install langsung di runner.

2. Error nama file — Pakai linux_amd64 tapi nama resminya linux_x64. Solusi: sesuaikan nama file binary.

3. Error download — curl di CI runner ga bisa follow GitHub redirect dengan benar, jadi yang ke-download malah HTML page, bukan tar.gz. Solusi: ganti ke wget yang lebih handal handle redirect.

Pelajaran dari tiga error ini: error di CI itu biasa dan bagus — setiap error yang diperbaiki bikin pipeline makin kuat.

Refactor Config ke Environment Variable

Selain pipeline, kode juga di-refactor. Sebelumnya port hardcode :8080 di main.go. Sekarang dipindah ke environment variable:

// configs/config.go
type Config struct {
    Port       string
    DBHost     string
    DBPassword string
}

func Load() *Config {
    return &Config{
        Port:       getEnv("PORT", "8080"),
        DBHost:     getEnv("DB_HOST", "localhost"),
        DBPassword: getEnv("DB_PASSWORD", ""),
    }
}

Kenapa ini penting? Karena DB_PASSWORD itu contoh yang paling jelas — password database ga boleh hardcode di source code. Dengan pattern configs.Load(), nanti tinggal tambah field baru tanpa ubah kode bisnis. Ini ngikutin prinsip 12-Factor App: config harus dipisah dari kode.

Unit test juga ditambah — 2 test baru buat config (default values dan env var override), jadi total sekarang 8 unit test yang semua hijau.

Gitleaks Config yang Disesuaikan

File .gitleaks.toml di-update dengan exclude paths yang spesifik buat project ini:

• go.sum — checksum dependensi, sering trigger false positive
• vendor/ — dependensi lokal
• docs/ — konten tutorial berisi contoh secret
• progress/ — catatan harian, bukan kode
• blogpost.md — konten blog
• securebank-api/security/ — scan reports berisi artifact
• .gitleaks.toml dan .gitignore — file config, bukan kode

Yang penting: .github/ dan source code (cmd/, configs/, internal/, pkg/) TIDAK di-exclude — ini justru yang harus tetap di-scan.

Lesson Learned

1. Error di CI itu kesempatan belajar, bukan kemunduran. Tiga kali error (lisensi, naming, download) dan masing-masing ngasih insight berbeda. Lisensi itu perlu di-cek sebelum pakai action. Binary naming convention beda-beda per tool. wget lebih handal dari curl buat download dari GitHub di CI runner.

2. Env var itu langkah pertama menuju 12-Factor App. Prinsipnya sederhana: config yang beda antara environment (dev, staging, production) harus dipisah dari kode. Port, database host, password — semua harus bisa di-ubah tanpa recompile. Pattern configs.Load() bikin ini jadi gampang.

3. Gitleaks config harus disesuaikan per project. Default rules udah bagus, tapi setiap repo punya konteks beda. Folder dokumentasi, scan reports, dan progress catatan harian — semuanya berisi teks yang mirip secret tapi bukan. Tanpa exclude yang tepat, false positive bikin noise dan orang mulai nge-ignore findings.

4. Job paralel bikin pipeline lebih cepat dan efisien. Secret scan ga perlu nunggu build selesai. Keduanya jalan barengan. Waktu total pipeline ditentukan oleh job yang paling lama, bukan jumlah job. Jadi nambah job paralel ga bikin pipeline jadi lambat.

Kesimpulan

Hari ini pipeline punya dua lapis pertahanan: build/test dan secret scanning. Kalo ada secret yang bocor ke repository, pipeline langsung gagal — bahkan sebelum code masuk ke main branch.

Refactor ke env var juga ngasih fondasi yang lebih baik buat hari-hari kedepan. Nanti waktu database connect dan API key mulai dipake, cukup tambah field di config struct dan set env var di server. Ga perlu ubah kode bisnis sama sekali.

Error CI yang tiga kali itu juga ngasih pelajaran berharga: ga ada yang langsung sempurna di awal. Yang penting setiap error diperbaiki dan pipeline akhirnya hijau.

Besok lanjut ke Hari 5: SCA Setup pakai Trivy — scan dependensi di go.mod buat cari CVE yang mungkin ada di library yang dipake.

Repo: github.com/stayrelevantid/chalange-devsecops