Belajar DevSecOps Engineer - Security as Code

#Pendahuluan

Di episode 14 kita menemukan masalah desain sebelum jadi kode. Episode ini tentang prinsip yang menyatukan semua tool yang sudah kalian pakai sejauh ini: security as code. Setiap artefak keamanan — policy OPA, rule Falco, ruleset Semgrep, konfigurasi Kyverno, exception list — diperlakukan persis seperti aplikasi: disimpan di Git, direview lewat PR, ditest otomatis, dan dirilis secara terkendali.

Mengapa prinsip ini menentukan? Karena alternatifnya adalah security as tribal knowledge: policy hidup di kepala dua orang senior, deteksi di dashboard vendor yang tak ada version control-nya, dan saat orang-orang itu resign, organisasi kembali ke nol tanpa jejak audit.

#Apa Saja yang Masuk Security Repo

Inventaris artefak yang idealnya versioned:

Artefak	Contoh	Dibahas
Policy IaC	Rego conftest, Checkov custom checks	Episode 7
Policy cluster	Kyverno ClusterPolicy	Episode 8 & 13
Detection rules	Falco rules, Sigma rules	Episode 11 & 24
Ruleset scanner	Semgrep config custom, gitleaks rules	Episode 4-5
Exception/waiver	Daftar pengecualian ber-expiry + justifikasi	Episode 10

Struktur repo tipikal:

Struktur security-repo

security/
├── policy/
│   ├── terraform/          # rego untuk conftest
│   └── k8s/                # kyverno policies
├── detection/
│   ├── falco/custom-rules.yaml
│   └── sigma/              # rules lintas SIEM
├── scanning/
│   ├── semgrep/org-rules.yaml
│   └── trivy/.trivyignore  # ignore berjustifikasi + expiry
└── exceptions/
    └── waivers.yaml        # semua exception organisasi

Pola penting: exceptions/ terpusat. Pengecualian yang tersebar di banyak repo adalah lubang hitam audit — mengumpulkannya di satu file membuat review berkala (dan penghapusan expired waiver) menjadi tugas 30 menit, bukan proyek.

#Workflow Perubahan Security

Perubahan policy = perubahan kode = lewat PR dengan proses yang sama ketatnya:

100%

Setiap tahap punya alasan:

Test otomatis — policy salah bisa memblokir seluruh organisasi; uji sebelum sampai ke cluster.
CODEOWNERS — perubahan pada policy/k8s/ wajib approval tim platform; mencegah "sekadar tweak" yang melonggarkan kontrol.
Rilis bertahap — mode audit dulu di staging/non-prod, pantau dampak, baru enforce production.

#Testing Policy

OPA punya framework test bawaan — manfaatkan penuh:

policy/terraform/s3_test.rego

package terraform.s3
 
test_bucket_with_encryption_allowed {
    plan := mock_plan_with_encrypted_bucket
    count(deny) == 0 with input as plan
}
 
test_bucket_without_encryption_denied {
    plan := mock_plan_unencrypted_bucket
    count(deny) == 1 with input as plan
}

Jalankan sebagai bagian CI:

Test suite policy

opa test policy/ -v
conftest verify --policy policy/terraform/

Prinsip yang sama berlaku lintas tool: Falco punya falco-rule-test harness, Semgrep punya mode test dengan expected findings (semgrep --test). Aturan praktisnya sederhana: setiap rule yang bisa gagal-kan pipeline wajib punya minimal dua test — positif dan negatif.

#Distribusi ke Konsumen

Repo selesai ditulis belum berarti diterapkan. Pola distribusi umum:

GitOps sync — ArgoCD/Flux menarik folder policy dari repo ini ke cluster; drift otomatis dikoreksi.
Template workflow versi-tagged — repo aplikasi memanggil workflow reusable dari tag tertentu; upgrade gate dilakukan sadar, satu PR per bump versi.
Pipeline distribusi — CI security repo mem-publish artifact ruleset (misal OCI artifact untuk rules), konsumen pin by digest.

Yang penting dari ketiganya: ada satu sumber kebenaran, dan konsumen tahu persis versi mana yang mereka pakai.

Important

Hindari pola "push langsung ke produksi" untuk perubahan enforcement. Satu typo di regex policy bisa memblokir semua deploy organisasi pagi Senin. Rilis bertahap + rollback cepat bukan formalitas — itu yang membuat tim percaya sistem.

#Manfaat yang Nyata

Dengan security as code, organisasi mendapat:

Auditability — setiap pelonggaran/pengencangan aturan punya commit, author, tanggal, dan reviewer. Auditor bertanya "kenapa exception ini ada?" → jawabannya ada di git blame.
Konsistensi skala — 200 repo memakai ruleset identik; tidak ada lagi "repo A lebih longgar karena dibuat tahun lalu".
Onboarding cepat — engineer baru membaca repo security untuk memahami standar, bukan bertanya-tanya.
Evolusi terukur — tiap insiden menghasilkan PR policy baru; postmortem terhubung langsung ke pencegahan permanen.

#Penutup

Inti yang harus dibawa pulang:

Security as code = semua artefak keamanan versioned, direview, ditest, dirilis seperti software.
Sentralisasi exceptions membuat audit dan cleanup menjadi rutinitas ringan.
Rule yang bisa fail-kan pipeline wajib punya test positif + negatif.
Distribusi via GitOps/template versi-tagged; rilis bertahap audit → enforce.

Di episode 16 selanjutnya kita membahas Compliance as Code — bagaimana benchmark CIS dicek otomatis, evidence audit dikumpulkan mesin tanpa screenshot manual, dan audit tahunan berubah dari kepanikan dua minggu menjadi query dashboard. Sampai jumpa!