Belajar DevSecOps Engineer - Compliance as Code

#Pendahuluan

Di episode 15 kalian menyusun security repo. Sekarang kita hubungkan semuanya dengan dunia compliance — topik yang sering dihindari engineer karena identik dengan paperwork. Padahal realitasnya sebaliknya: compliance adalah daftar kontrol security yang sudah dikurasi industri (CIS, PCI-DSS, SOC 2, ISO 27001), dan hampir semua kontrol teknisnya bisa dicek otomatis oleh mesin.

Masalah model lama: audit dilakukan sekali setahun → tim berburu screenshot konfigurasi selama dua minggu → auditor menemukan drift 11 bulan tak terpantau → findings sama berulang tiap tahun. Compliance as code membaliknya: kontrol dicek terus-menerus, evidence terkumpul otomatis, dan hari-H audit tinggal ekspor dashboard.

#Dari Framework ke Kontrol Teknis

Framework compliance pada dasarnya adalah daftar kontrol — dan mayoritas bersifat teknis:

Kontrol Umum	Contoh Penerapan Otomatis
Enkripsi data at rest	Policy: semua storage wajib KMS
Access review berkala	Script: dump IAM + diff vs baseline
Logging & monitoring aktif	Check: audit log enabled + retensi
Patch management	Metrik: umur CVE open per SLA
Network segmentation	Scan: network policy default-deny

Kunci metodologinya: satu kontrol = satu check otomatis = satu status terukur. Begitu penerjemahan ini selesai, "compliance" berubah dari proyek tahunan menjadi metrik harian seperti coverage test.

#CIS Benchmark: Baseline yang Terukur

CIS Benchmarks adalah panduan hardening yang paling banyak dirujuk (CIS Kubernetes Benchmark, CIS AWS Foundations, dsb.). Tool untuk mengeksekusinya sudah matang:

#kube-bench untuk Cluster

Jalankan kube-bench di cluster

kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job.yaml
kubectl logs -f job/kube-bench

Output tipikal per section:

Ringkasan hasil kube-bench

[FAIL] 1.2.4 Ensure that the --insecure-port argument is set to 0
[PASS] 1.3.1 Ensure that the --profiling argument is set to false
[WARN] 4.1.1 Ensure that the API server audit log path is configured
...
== Summary ==
49 checks PASS / 12 checks FAIL / 7 checks WARN

Setiap nomor check merujuk langsung ke rekomendasi CIS — jadi remediation-nya jelas: buka benchmark PDF bagian 1.2.4, terapkan, rescan.

#Checkov/Trivy dengan Mapping Framework

Untuk IaC cloud, scanner yang sudah kalian pakai punya mode compliance bawaan:

checkov -d ./infra --framework cis_aws_terraform \
  --output json > cis-report.json

Perhatikan polanya: tool yang sama dengan episode 4-7, hanya argumen framework-nya yang berbeda. Inilah manfaat menanamkan scanner sejak awal — compliance jadi lapisan pelaporan di atas infrastruktur scanning yang sudah ada.

#Pipeline Evidence Kontinu

Evidence = bukti bagi auditor bahwa kontrol berjalan. Model manual mengumpulkannya saat audit; model otomatis mengumpulkannya terus-menerus:

100%

Contoh job pengumpul evidence sederhana:

Scheduled compliance snapshot

name: compliance-snapshot
on:
  schedule:
    - cron: "0 2 * * *"      # harian jam 02:00 UTC
 
jobs:
  collect-evidence:
    runs-on: ubuntu-latest
    permissions:
      id-token: write         # OIDC ke cloud, episode 19
    steps:
      - uses: actions/checkout@v4
      - name: CIS AWS scan
        run: checkov -d ./infra --framework cis_aws_terraform \
               --output json --output-file evidence/cis.json
      - name: Simpan ke evidence store
        run: ./scripts/upload-evidence.sh evidence/

Prinsip penyimpanan evidence: immutable dan bertanggal (bucket versioned + WORM jika regulasi menuntut). Auditor tidak percaya file yang bisa diedit; mereka percaya riwayat yang tak bisa diubah.

Tip

Tanyakan kepada tim GRC kalian: framework apa yang dipakai organisasi? Lalu petakan 20 kontrol teknis paling relevan ke check otomatis dalam satu sprint. 80% nilai compliance biasanya datang dari 20% kontrol itu — sisanya adalah proses organisasi, bukan kode.

#Menangani Findings & Exception Compliance

Temuan compliance dikelola seperti vulnerability (episode 10):

Triage — fail nyata vs false positive vs kontrol kompensasi.
Remediasi atau waiver ber-expiry — waiver tanpa tanggal adalah temuan permanen yang menyamar.
Feedback ke policy — temuan berulang jadi aturan preventif baru di conftest/Kyverno (episode 15).

Satu jebakan klasik yang harus dihindari: mengubah check agar lulus alih-alih memperbaiki infrastruktur. Contoh: me-nonaktifkan rule "S3 harus encrypted" supaya report hijau. Itu bukan compliance — itu pemalsuan evidence, dan akan ketahuan saat insiden.

#Manfaat Nyata bagi Engineer

Compliance as code bukan hanya soal lolos audit — ia meningkatkan postur keamanan riil:

Drift terdeteksi dalam hitungan hari, bukan setahun.
Onboard vendor/cloud baru lebih cepat karena baseline CIS siap.
Tim dev mendapat feedback konfigurasi non-compliant di PR, bukan lewat email auditor tiga bulan kemudian.

#Penutup

Inti yang harus dibawa pulang:

Framework compliance = daftar kontrol; mayoritas kontrol teknis bisa dicek otomatis.
kube-bench untuk cluster, Checkov/Trivy mapping framework untuk cloud IaC.
Evidence dikumpulkan kontinu ke store immutable; audit tinggal ekspor.
Temuan compliance dikelola seperti vulnerability; jangan pernah melonggarkan check demi laporan hijau.

Di episode 17 selanjutnya kita beralih ke sisi lain spektrum shift: Shift-Right & Production Security — apa saja yang hanya bisa diamankan saat aplikasi sudah hidup: security observability runtime, WAF, kill switch, dan bagaimana temuan production mengalir balik memperkuat pipeline kalian. Sampai jumpa!