Belajar DevSecOps Engineer - DevSecOps Model & Culture

#Pendahuluan

Di episode 1 kita sudah memahami peran DevSecOps Engineer dan logika shift-left. Namun ada satu penyebab kegagalan adopsi DevSecOps yang paling sering dilupakan para engineer teknis: bukan tool-nya, tapi manusia dan strukturnya. Survey setelah survey menunjukkan program security automation gagal bukan karena scanner buruk, melainkan karena tidak ada yang merasa bertanggung jawab atas temuan, atau budayanya membuat developer menyembunyikan masalah alih-alih melaporkannya.

Episode ini membahas fondasi non-teknis yang menentukan apakah semua otomasi pada episode 3-27 benar-benar dipakai: model tanggung jawab bersama, feedback loop, prinsip automation-first, dan cara menyusun adoption plan yang realistis.

#Model Shared Responsibility

Kesalahan klasik organisasi: "security adalah urusan tim security". Model ini menciptakan dua masalah — tim security kewalahan karena jumlah kode tumbuh lebih cepat daripada headcount mereka, sementara developer menganggap temuan sebagai "pekerjaan orang lain" yang mengganggu.

Model DevSecOps membagi tanggung jawab secara shared tapi terukur:

Perhatikan pola pentingnya: security tidak lagi melakukan pemeriksaan untuk orang lain — security membangun sistem agar pemeriksaan terjadi sendiri. Developer tetap pemilik fix-nya (mereka yang paham kodenya), tetapi tidak perlu menjadi ahli CVE karena gate akan memberi tahu apa yang harus diperbaiki dan mengapa.

#Feedback Loops: Jantung DevSecOps

DevOps dikenal lewat loop plan → build → test → release → monitor → plan. Versi security-nya menambahkan dua loop kritis:

1. Loop cepat (menit) — hasil scan langsung muncul di PR. Temuan diperbaiki saat konteks masih segar.
2. Loop lambat (mingguan/bulanan) — data agregat (jumlah temuan per tim, MTTR, escape rate) dievaluasi untuk memperbaiki standar, policy, dan pelatihan.

Organisasi dengan loop lambat yang mati adalah tempat di mana dashboard security indah tapi tidak pernah mengubah apa pun. Tanyakan setiap bulan: temuan apa yang paling sering muncul, dan bagaimana kita membuat kelas kesalahan itu tidak mungkin terulang — lewat template, linter custom, atau library internal?

#Prinsip Automation-First

Tiga aturan yang menjadikan otomasi sebagai default:

• Jika dicek manual dua kali → jadikan gate otomatis. Checklist review "pastikan tidak ada secret" seharusnya gitleaks; checklist "bucket tidak publik" seharusnya policy checkov.
• Gate harus deterministik dan cepat. Gate yang flaky atau butuh 40 menit akan di-skip atau di-ignore oleh developer — secara resmi lewat mekanisme bypass.
• False positive adalah bug tooling, bukan beban developer. Setiap FP yang lolos ke PR menggerus kepercayaan; sediakan mekanisme suppression dengan justifikasi dan review.

Poin ketiga sering diremehkan. Satu false positive yang mengganggu PR mendesak bisa membuat seluruh tim menonaktifkan scanner tersebut. Manajemen kualitas gate sama pentingnya dengan membuat gate-nya.

#Security Champions: Skala Tanpa Headcount

Satu DevSecOps engineer per 50 developer adalah rasio yang mustahil. Solusi industri: security champions — developer dari tiap tim yang dilatih dasar security dan menjadi titik kontak pertama.

Manfaat konkret:

• Pertanyaan security dijawab dalam hitungan jam, bukan tiket lintas divisi.
• Desain fitur berisiko dibahas lebih awal sebelum jadi kode.
• Champion menerjemahkan gate otomatis ke konteks domain timnya.

Program champions yang berhasil memberi waktu khusus (misal 10% kapasitas), jalur karir yang jelas, dan akses langsung ke tim security — bukan sekadar gelar tambahan tanpa dukungan.

#Blameless Culture

Ketika incident terjadi, pertanyaannya harus "bagaimana sistem mengizinkan ini terjadi?", bukan "siapa yang salah?" Budaya blame bukan hanya tidak nyaman — ia merusak data: orang mulai menyembunyikan near-miss, dan kalian kehilangan sinyal paling berharga untuk perbaikan.

Praktik blameless yang konkret:

• Postmortem fokus pada faktor sistemik: kenapa secret bisa di-commit? Kenapa gate tidak menangkapnya?
• Setiap postmortem wajib menghasilkan minimal satu action item otomasi/policy.
• Temuan yang dilaporkan sukarela dirayakan, bukan dihukum.

#Menyusun Adoption Plan

Jangan mencoba menanam 15 scanner sekaligus. Adoption yang realistis berjalan empat tahap:

1. Assess (minggu 1-2) — inventaris: berapa repo, pipeline mana aktif, di mana secrets tersimpan, apa baseline temuan jika semua scanner dijalankan sekali?
2. Pilot (bulan 1-2) — pilih 1-2 tim yang willing (idealnya tim yang baru kena insiden). Tanam secret scanning + SCA dulu: false positive paling rendah, dampak langsung terasa.
3. Expand (bulan 3-6) — tambah SAST dengan threshold ketat, IaC scan, lalu image scanning. Standardisasi via template workflow yang dipakai semua repo.
4. Measure & mature (berkelanjutan) — pasang metrik coverage dan MTTR (detail episode 25), program champions, lalu iterasi.

1. Secret scanning      -> murah, akurat, mencegah insiden mahal
2. SCA (dependency)     -> akurat tinggi, fix mudah (bump versi)
3. IaC scan             -> misconfig cloud = insiden termahal
4. SAST                 -> butuh tuning FP, mulai dari ruleset inti
5. Container scan       -> bergabung dengan SBOM/signing

#Penutup

Inti yang harus dibawa pulang:

• Shared responsibility: developer punya fix, ops punya infra, security punya standar & tooling.
• Dua feedback loop: cepat di PR (menit) dan lambat agregat (bulanan) — keduanya harus hidup.
• Automation-first: cek manual dua kali = jadikan gate; false positive = bug tooling.
• Security champions memperluas jangkauan; budaya blameless menjaga kualitas data.
• Adoption plan: assess → pilot → expand → measure; mulai dari gate ROI tertinggi.

Di episode 3 selanjutnya kita masuk Fase 2 dengan topik yang paling praktis: Secure CI/CD Pipelines — bagaimana meng-hardening pipeline kalian sendiri, dari pinning action by SHA, membatasi GITHUB_TOKEN, ephemeral runner, sampai belajar dari kasus nyata poisoned-pipeline-execution. Lab kalian akan langsung terpakai. Sampai jumpa!