Hari 25: DAST Otomatis di CI Pipeline

DAST Masuk Pipeline — Job ke-5 di CI

Kemarin (Day 24) ZAP dijalankan manual lewat terminal. Hari ini, ZAP dijalankan otomatis setiap kali ada push ke repo. Tidak ada lagi yang scan manual — semua otomatis di GitHub Actions.

Pipeline SecureBank CI sekarang punya 5 job parallel/sequential:

Job	Fungsi	Status
Build & Test	Compile Go + unit test + coverage	✅ Green
Secret Scan	Gitleaks deteksi leaked credentials	✅ Green
SCA Scan	Trivy scan dependencies untuk CVE	✅ Green
SAST Scan	Semgrep scan source code untuk insecure patterns	✅ Green
DAST Scan	ZAP baseline scan application yang sedang jalan	❌ Red

4 job pertama sudah ada sejak Fase 1. Job ke-5 (DAST) baru ditambahkan hari ini.

Kenapa Pakai Go Binary, Bukan Docker?

Tutorial silabus menyarankan pakai Docker service container untuk menjalankan aplikasi di CI. Tapi setelah dipikir, ada pendekatan yang lebih ringan: build Go binary langsung.

Docker build di CI butuh:

• Build image (~30 detik — download base image, compile, layer cache)
• Container lifecycle (start, health check, stop, cleanup)

Go binary butuh:

• go build -o securebank ./cmd/api (~5 detik)
• ./securebank & (run as background process)

Total hemat ~25 detik. Dan karena DAST scan HTTP response header — hasilnya sama whether app jalan sebagai binary atau container. Docker tetap penting untuk production, tapi untuk DAST di CI, binary sudah cukup.

Cara Kerja DAST Job di CI

dast-scan:
  needs: [build-and-test]    # tunggu build & test selesai dulu
  steps:
    - checkout code
    - setup Go 1.26
    - go build -o securebank ./cmd/api
    - run: JWT_SECRET=ci-test-secret PORT=8080 ./securebank &
    - wait for health (curl retry 15x)
    - zaproxy/action-baseline@v0.13.0
    - upload artifact (zap report)

Urutannya simpel: build binary → start di background → tunggu healthy → ZAP scan → upload report.

needs: [build-and-test] berarti DAST scan hanya jalan kalau build dan test sudah lulus. Kalau build gagal, DAST scan nggak jalan — hemat CI minutes. Job lain (Gitleaks, Trivy, Semgrep) tetap parallel — mereka nggak butuh app jalan.

Hasil: Pipeline Merah — dan Itu Bagus

FAIL-NEW: 0  WARN-NEW: 1  PASS: 66
WARN-NEW: Storable and Cacheable Content [10049] x 2

66 check pass, 0 fail, 1 warn. Tapi ZAP action return exit code 1 karena ada WARN — pipeline merah.

Ini sengaja. Sama kayak Day 22 ketika Infrastructure Security pipeline sengaja merah sampai Day 23 fix. Pattern-nya konsisten: masukkan scanner ke pipeline → pipeline merah (expected) → fix finding → pipeline hijau.

Finding 10049 (Storable and Cacheable Content) terjadi karena 404 response dari path yang nggak didefinisikan (/ dan /robots.txt) tidak punya Cache-Control header. Go's http.HandleFunc hanya apply middleware ke route yang explicit didaftarkan (/health, /balance, /transfer). Path lain dapat 404 default tanpa middleware.

Fix-nya di Day 26: DAST Remediation.

Pelajaran yang Didapat

1. DAST di CI lebih efisien pakai binary, bukan Docker. Docker build butuh waktu lebih lama dan container lifecycle management. Untuk DAST yang cuma butuh HTTP response, Go binary langsung sudah cukup. Hasil scan identik — ZAP baca response header, bukan care app jalan di Docker atau binary.

2. ZAP action lebih ketat dari ZAP CLI. Local run: ZAP cuma fail kalau ada FAIL. ZAP action di CI: fail kalau ada WARN atau FAIL. Security gate lebih ketat di pipeline — ini поведen yang benar untuk CI/CD.

3. cmd_options: '-I' untuk skip INFO findings. ZAP baseline punya 3 level: FAIL, WARN, INFO. Tanpa -I, INFO findings juga bikin pipeline fail. Dengan -I, cuma FAIL dan WARN yang dianggap. INFO biasanya noise yang nggak perlu block pipeline.

4. needs di GitHub Actions = dependency graph. Job dengan needs nunggu job dependency selesai. Job tanpa needs jalan parallel. Kombinasi keduanya bikin pipeline efisien: scanner parallel (Gitleaks, Trivy, Semgrep) + sequential (build → DAST).

5. GitHub Actions auto-cleanup background process. Setelah job selesai, GitHub otomatis kill orphan process. Log menunjukkan: "Terminate orphan process: pid (3962) (securebank)". Nggak perlu manual kill atau trap — GitHub Actions handle sendiri.

Kesimpulan

Day 25 selesai. DAST scan otomatis di pipeline. CI sekarang punya 5 quality gate: Build & Test + Secret Scan + SCA + SAST + DAST. Pipeline merah karena 1 WARN finding yang belum di-fix — ini expected, fix di Day 26.

Pendekatan Go binary terbukti lebih efisien: pipeline total 2 menit 16 detik, DAST job sendiri cuma sekitar 1 menit. Dibanding kalau pakai Docker build + container, mungkin bisa 4-5 menit.

Besok Day 26: DAST Remediation — fix WARN 10049, tambah security headers yang masih kurang, pipeline hijau lagi. Sampai jumpa besok!

---

Repo: https://github.com/stayrelevantid/chalange-devsecops