Belajar GitLab CI/CD - DevSecOps Native GitLab (SAST, DAST, & Container Scanning)

#Pendahuluan

Di episode 11 sebelumnya kita membahas modularisasi pipeline dengan include — termasuk include: template yang mengimpor template resmi GitLab. Saya menyebut bahwa template keamanan akan kita bedah lebih dalam, dan inilah waktunya. Di episode ini kita masuk ke FASE 5 dan membahas hal yang paling sering diabaikan pipeline pemula: keamanan.

Pendekatan lama menganggap keamanan sebagai tahap terakhir yang dijalankan sekali setahun oleh tim khusus, setelah aplikasi selesai dibangun — biasanya dengan temuan ratusan kerentanan yang harus ditangani panik. Ini persis seperti memeriksa air sebelum minum: berguna, tapi terlambat. Pendekatan modern disebut DevSecOps atau shift-left security: keamanan digeser ke kiri — ke tahap paling awal pengembangan — dan dijalankan otomatis di setiap commit, bukan setiap tahun.

Kabar baiknya, GitLab adalah salah satu platform yang paling serius membangun keamanan sebagai bagian dari pipeline itu sendiri. Karena GitLab menangani repository, CI/CD, container registry, dan security dashboard dalam satu aplikasi, scanner keamanan tidak perlu dihubungkan secara manual — cukup tambahkan beberapa baris include: template dan hasilnya langsung terintegrasi di merge request. Mari kita lihat bagaimana.

#Pembahasan Utama

#Mengapa GitLab Unggul di Bidang Integrated DevSecOps

Sebagian besar vendor memisahkan alat: repository di satu tempat, CI di tempat lain, scanner keamanan di produk ketiga yang harus dikalibrasi sendiri. GitLab mengambil pendekatan berbeda — semua dalam satu platform. Karena pipeline GitLab dijalankan pada setiap commit dan merge request, security scanning mengikuti alur pengembangan secara alami, bukan menjadi proses terpisah.

Analogi yang pas: keamanan ala tradisional itu seperti menaruh brankas di ujung gedung — setiap orang boleh membawa barang apa saja, dan baru diperiksa setelah tiba di brankas. DevSecOps ala GitLab itu seperti pemeriksaan di pintu masuk bandara — setiap orang melewati scanner sebelum naik ke pesawat. Dengan begitu, masalah ditemukan saat masih murah untuk diperbaiki: di laptop developer, bukan setelah dirilis ke produksi.

Empat scanner native yang akan kita bahas bekerja pada lapisan berbeda:

SAST — menganalisis kode sumber untuk menemukan pola insecure.
Secret Detection — mencari kredensial yang bocor ke repository.
Dependency Scanning — memeriksa kerentanan di library pihak ketiga.
Container Scanning — memindai image Docker untuk mencari kerentanan sistem operasi.

#Mengaktifkan SAST (Static Application Security Testing)

SAST membaca kode sumber tanpa menjalankannya dan mencari pola yang rawan serangan — SQL injection, path traversal, penggunaan fungsi yang tidak aman, dan sejenisnya. GitLab menggunakan mesin yang cocok per bahasa: Semgrep untuk Python, GoSec untuk Go, Bandit untuk Python, dan lainnya. Mengaktifkannya sangat sederhana:

Aktifkan template SAST

include:
  - template: Jobs/SAST.gitlab-ci.yml

File YAML berisi template ini cukup ditambahkan ke daftar include pipeline kalian. Template mendefinisikan semua job SAST yang dibutuhkan, lengkap dengan konfigurasi defaultnya. Ketika pipeline berjalan, temuan SAST muncul sebagai komentar di merge request — tepat di baris kode yang bermasalah.

#Secret Detection: Menghentikan Kredensial Bocor ke Git

Tidak ada yang lebih memalukan daripada API key atau AWS_SECRET_ACCESS_KEY yang ter-commit ke repository lalu terbaca di log. Secret Detection memindai seluruh riwayat repository — termasuk commit lama — untuk menemukan kredensial yang bocor.

Aktifkan template Secret Detection

include:
  - template: Jobs/Secret-Detection.gitlab-ci.yml

Warning

Secret Detection menemukan kredensial, tapi tidak menghapusnya. Jika secret sudah pernah ter-commit, anggap secret itu bocor — revoke dan ganti segera, lalu rewrite riwayat git dengan git filter-repo. Menghapus file dari branch sekarang tidak menghilangkan secret dari riwayat commit.

#Dependency Scanning: Memindai Library Pihak Ketiga

Kerentanan jarang berasal dari kode sendiri — mayoritas berasal dari dependency yang kita pakai. Dependency Scanning membandingkan daftar library dan versinya dengan database kerentanan seperti CVE dan database GitLab sendiri.

Aktifkan template Dependency Scanning

include:
  - template: Jobs/Dependency-Scanning.gitlab-ci.yml

Template ini membaca file manifest seperti package-lock.json, Gemfile.lock, requirements.txt, atau pom.xml, lalu memindai dependensinya. GitLab tidak hanya menampilkan CVSS score, tapi juga versi yang memperbaiki kerentanan tersebut — sehingga tim bisa langsung tahu apa yang harus di-upgrade.

#Container Scanning: Memindai Image Docker dengan Trivy

Setelah image dibangun di registry (ingat episode 6), lapisan terakhir adalah memindai image itu sendiri. Container Scanning menggunakan Trivy secara default — alat open-source yang memindai sistem operasi base image (misal alpine atau ubuntu) serta library bahasa yang terkandung di dalam image.

Aktifkan template Container Scanning

include:
  - template: Security/Container-Scanning.gitlab-ci.yml

Container Scanning membutuhkan akses ke image di GitLab Container Registry. GitLab menyediakan predefined variables seperti CI_REGISTRY_IMAGE dan CI_COMMIT_SHA sehingga template tahu image mana yang harus dipindai — biasanya yang di-tag dengan SHA commit yang sama.

Pertemuan semua scanner dalam satu pipeline

include:
  - template: Jobs/SAST.gitlab-ci.yml
  - template: Jobs/Secret-Detection.gitlab-ci.yml
  - template: Jobs/Dependency-Scanning.gitlab-ci.yml
  - template: Security/Container-Scanning.gitlab-ci.yml
 
stages: [build, test, deploy]
 
container_scanning:
  stage: test
  image: docker:latest
  services: [docker:dind]

Perhatikan bagaimana seluruh keamanan diaktifkan hanya dengan empat baris include: template — inilah kekuatan DevSecOps native. Yang perlu diperhatikan adalah job container scanning butuh image yang sudah dibuild di stage sebelumnya, jadi susun dependency-nya dengan benar.

#Membaca Vulnerability Report di Security Center

Hasil semua scanner ini tidak sekadar tercetak di log — GitLab mengagregasinya menjadi vulnerability report yang terpusat. Di UI, kalian bisa melihat:

MR Security Widget — temuan per merge request, bisa langsung ditandai sebagai dismiss jika false positive.
Security Dashboard — ringkasan seluruh kerentanan di semua project dalam satu group, diurutkan berdasarkan severity (Critical, High, Medium, Low).
Vulnerability Details — deskripsi, CVSS score, path file, dan rekomendasi perbaikan untuk setiap temuan.

Alur pengelolaannya juga bisa otomatis: ketika severity tinggi ditemukan, pipeline bisa gagal dan memblokir merge request. GitLab membandingkan temuan dengan pipeline sebelumnya, sehingga tim bisa tahu apakah perubahan terbaru menambah atau mengurangi kerentanan.

Tip

Mulailah dari kerentanan Critical dan High saja agar tim tidak kewalahan. Aktifkan scanner satu per satu, pahami temuan-temuannya, baru perketat aturan pipeline. Menjadi terlalu ketat sejak awal hanya membuat seluruh tim mematikan scanner karena frustrasi.

#Kesalahan Umum dalam DevSecOps

Kesalahan	Gejala	Solusi
Menyimpan secret di `variables`	Secret bocor di log pipeline	Gunakan variabel Masked + Protected, atau Vault
Memindai hanya di branch main	Kerentanan ditemukan setelah merge	Scan di setiap MR dengan `workflow: rules`
Mengabaikan temuan	Kerentanan menumpuk tak terkendali	Jadwalkan review temuan secara rutin
Tidak memindai image yang di-deploy	Image lama bocor ke produksi	Scan image dengan tag yang sama yang di-deploy
Template berjalan tapi tidak memblokir MR	Pipeline hijau walau ada temuan	Konfigurasi agar severity tinggi menghentikan pipeline
Menghapus secret tapi tidak revoke	Secret masih valid di cloud	Revoke kredensial dan regenerate segera

#Penutup

Pada episode ini kita telah membahas mengapa GitLab menjadi pemimpin di bidang integrated DevSecOps — keamanan menyatu dengan alur pengembangan, bukan proses terpisah; mengaktifkan empat scanner native — SAST untuk kode sumber, Secret Detection untuk kredensial bocor, Dependency Scanning untuk library pihak ketiga, dan Container Scanning dengan Trivy untuk image Docker — masing-masing cukup dengan include: template; serta membaca dan mengelola temuan melalui MR widget, security dashboard, dan Security Center.

Inti dari episode ini: keamanan bukan fitur tambahan, melainkan lapisan bawaan pipeline. Dengan DevSecOps, kerentanan ditemukan saat masih murah diperbaiki — di laptop developer, bukan setelah dirilis ke produksi.

Di episode 13 selanjutnya kita akan menangani sisi kredensial yang lebih dalam: Passwordless Cloud Authentication menggunakan OIDC — cara mengotentikasi pipeline ke AWS, GCP, dan Azure tanpa menyimpan satu pun secret key permanen. Sampai jumpa!