Belajar DevSecOps Engineer - SAST/DAST/SCA Integration

#Pendahuluan

Di episode 3 kalian sudah punya pipeline yang hard. Sekarang kita buat pipeline itu melihat: mendeteksi kerentanan di kode, dependency, dan aplikasi yang berjalan. Inilah tiga pilar scanning yang menjadi tulang punggung hampir semua security gate modern — SAST, SCA, dan DAST.

Mengapa harus tiga-tiganya? Karena ketiganya melihat permukaan berbeda. Kode kalian bisa bersih dari injection tetapi membawa library dengan CVE kritis (SAST bersih, SCA merah). Dependency bisa aman tetapi logika auth kalian cacat (SCA bersih, SAST/DAST merah). Gate yang hanya menjalankan satu jenis scan memberi rasa aman palsu.

#Memahami Tiga Pilar

Aspek	SAST	SCA	DAST
Apa yang dianalisis	Source code sendiri	Dependency & lisensi	Aplikasi running
Kapan	Saat build/PR	Saat build/PR	Setelah deploy ke test env
Contoh temuan	SQL injection, XSS	CVE di lodash, typosquatting	Endpoint tanpa auth header
Tool populer	Semgrep, CodeQL	Trivy fs, Dependabot, Snyk	OWASP ZAP, Burp
Kelemahan utama	False positive tinggi	Hanya melihat manifest	Butuh env hidup, cakupan terbatas

Ada juga secret scanning (episode 5) dan IaC scan (episode 7) sebagai pilar pendamping — kelima-limanya membentuk gerbang lengkap.

#Integrasi SAST dengan Semgrep

Semgrep cepat, murah, dan ruleset-nya mudah dikustomisasi — ideal untuk gerbang PR. Contoh menangkap query database yang menyusun string:

Jalankan Semgrep lokal sebelum push

semgrep scan --config=p/ci --error

Flag --config=p/ci memakai ruleset inti (injection, insecure deserialization, dsb.), dan --error membuat exit code non-zero jika ada temuan — inilah yang membuat step CI gagal. Versi workflow-nya:

.github/workflows/sast.yml

name: SAST
on:
  pull_request:
 
jobs:
  semgrep:
    runs-on: ubuntu-latest
    permissions:
      contents: read
    steps:
      - uses: actions/checkout@v4
      - run: pipx install semgrep
      - name: Scan kode sumber
        run: semgrep scan --config=p/ci --sarif --output=semgrep.sarif
      - name: Gagal jika ada temuan HIGH
        run: semgrep scan --config=p/ci --severity=ERROR --error

Pola dua langkah di atas lazim dipakai: langkah pertama menghasilkan SARIF untuk dashboard/laporan, langkah kedua menjadi gate yang benar-benar fail.

#Integrasi SCA

Untuk SCA, Trivy sudah terpasang di lab kalian dan bisa membaca lockfile (package-lock.json, go.sum, requirements.txt) langsung:

Scan dependency dengan Trivy

trivy fs --severity HIGH,CRITICAL --exit-code 1 .

--exit-code 1 membuat command gagal saat menemukan kerentanan pada level tersebut. Untuk project Node.js, Dependabot/Dependabot security updates menutup siklusnya dengan PR bump otomatis — pasangan deteksi (Trivy) dan remediasi (Dependabot) ini adalah pola vuln management yang akan kita otomasi lebih lanjut di episode 10.

Tip

Jalankan SCA pada lockfile, bukan manifest. Manifest (package.json) hanya mencatat rentang versi; lockfile-lah yang benar-benar terinstall. Scan pada manifest menghasilkan daftar yang tidak akurat.

#Integrasi DAST dengan ZAP

DAST butuh aplikasi yang hidup, jadi posisinya setelah deploy ke environment testing (bukan production). OWASP ZAP punya mode baseline yang pas untuk CI — cepat, tanpa merusak data:

ZAP baseline scan setelah deploy staging

jobs:
  dast:
    needs: deploy-staging
    runs-on: ubuntu-latest
    steps:
      - name: ZAP Baseline Scan
        uses: zaproxy/action-baseline@v0.12.0
        with:
          target: "https://staging.example-app.internal"
          cmd_options: "-a -I"
      - name: Fail jika ada alert berisiko tinggi
        run: |
          grep -q '"riskcode": "3"' report_json.json && exit 1 || exit 0

Mode baseline melakukan spider ringan + serangan pasif + sebagian aktif terhadap endpoint publik. -I membuatnya tidak berhenti di warning SSL staging.

#Mengelola False Positive

False positive adalah musuh nomor satu adopsi gate. Strategi praktisnya:

Mulai sempit — ruleset inti saja; jangan nyalakan 2000 rule di hari pertama.
Suppression berjustifikasi — abaikan temuan spesifik dengan alasan tertulis, bukan matikan seluruh rule.

contoh suppression inline Semgrep

# nosemgrep: python.lang.security.audit.eval
result = eval(trusted_config_from_internal_tool)

Komentar nosemgrep menyembunyikan temuan itu saja — dan karena ada di source, penambahan baris ini ikut tereview di PR, lengkap dengan justifikasinya.

Basline untuk kode lama — tandai temuan existing sebagai baseline; hanya kode baru yang menggagalkan build. Ini memberi tim waktu membayar utang tanpa memblokir fitur baru.
Ukur FP rate — jika sebuah rule menghasilkan lebih dari 50% temuannya false positive, tuning atau matikan rule-nya. Data ini bahan episode 25 tentang metrik.

#Merancang Security Gates

Gate yang baik punya gradasi, bukan sekadar pass/fail total:

Blocking: secret terdeteksi, CVE kritis dengan fix tersedia, injection confirmed.
Warning: severity medium, temuan baseline, area kode legacy.
Report only: informasional, masuk dashboard untuk triage mingguan.

Simpan hasil semua scan dalam format standar (SARIF) sehingga GitHub Security tab atau tool lain bisa menampilkannya tanpa vendor lock-in.

#Penutup

Inti yang harus dibawa pulang:

SAST melihat kode kalian, SCA melihat dependency, DAST melihat aplikasi hidup — ketiganya saling melengkapi.
Semgrep untuk gate PR cepat, Trivy fs untuk lockfile, ZAP baseline untuk environment testing.
Exit code adalah mekanisme gate; SARIF adalah format pelaporan.
Kelola false positive lewat ruleset sempit, suppression berjustifikasi, dan baseline — bukan dengan mematikan scanner.

Di episode 5 selanjutnya kita membahas Secret Management & Scanning — cara mendeteksi secret yang bocor dengan gitleaks, membangun secret store yang benar dengan OpenBao/Vault, dan strategi rotasi supaya bocor satu kredensial tidak berarti kompromi total. Sampai jumpa!