Belajar Engineering Manager - Security Culture in Team

#Pendahuluan

Setelah di episode 17 kita memperbaiki mesin proses tim, episode ini menghadapi dimensi yang selama ini sering diserahkan ke tim keamanan terpisah: security culture.

Mengapa EM harus peduli? Karena insiden keamanan modern hampir selalu lahir dari keputusan kecil sehari-hari di dalam tim: dependency yang tidak di-update karena buru-buru, secret yang ter-commit karena malas setup vault, endpoint debug yang tertinggal di production. Tim security korporat tidak bisa mengawasi puluhan keputusan itu — hanya budaya tim kalian yang bisa. Dan konteks 2026 membuat taruhannya naik: regulasi perlindungan data Indonesia (UU PDP) kini berlaku penuh dengan sankinya, dan serangan berbasis AI makin murah dilancarkan.

#Shift-Left: Keamanan Bergerak ke Depan

Cara lama menangani keamanan adalah audit di akhir: bangun dulu, scan menjelang rilis, panik memperbaiki. Pendekatan shift-left memindahkan pertimbangan keamanan ke awal lifecycle — saat desain, saat menulis kode, saat review PR — di titik ketika perbaikan masih murah.

Saat desain     : 1 unit    (ubah diagram, diskusi 15 menit)
Saat coding     : 3 unit    (refactor lokal, test tambahan)
Saat pre-release: 10 unit   (rework lintas modul, delay rilis)
Pasca-insiden   : 100+ unit (incident response, notifikasi user,
                              reputasi, potensi sanksi regulator)

Bagi EM, shift-left bukan proyek sekali jalan melainkan penataan ulang default: security requirement masuk definition of done (episode 9), dependency scanning otomatis di CI, dan pertanyaan "apa yang bisa rusak di sini?" menjadi bagian normal diskusi desain — bukan interupsi dari departemen lain.

#Threat Modeling Ringan untuk Tim Fitur

Threat modeling penuh (STRIDE lengkap, data flow diagrams formal) adalah ranah security specialist, tetapi versi ringannya layak dijalankan tim fitur sendiri — 30-45 menit per desain besar, empat pertanyaan:

1. Apa yang kita bangun? Gambar alur data kasar: input user, service, database, third-party.
2. Apa yang bisa salah? Untuk tiap komponen: apakah bisa diintip (confidentiality), diubah (integrity), dipalsukan (authentication), ditolak layanannya (availability)?
3. Apa yang akan kita lakukan soal itu? Mitigasi, accept risk dengan catatan, atau defer dengan tiket.
4. Apakah kita sudah melakukan yang kita bilang? Verifikasi di review sebelum rilis.

Hasilnya dicatat singkat di design doc bagian "security considerations". Format ringan ini penting: kalau syaratnya workshop dua hari, tidak akan pernah dijalankan — dan proses yang tak dijalankan lebih buruk daripada tidak ada (episode 17).

#Security Champions

Model organisasi yang terbukti efektif untuk tim engineering: security champion — satu orang per tim yang menjadi jembatan dengan tim security korporat:

• Menerima briefing vulnerability baru dan menerjemahkannya ke konteks tim.
• Review PR yang menyentuh area sensitif (auth, payment, PII).
• Mengusulkan dan menjaga secure defaults di codebase tim.

Pilih sukarelawan yang curious (cek skills matrix, episode 6, sebagai basisnya), beri waktu terstruktur (potongan kapasitas di capacity plan), dan beri jalur growth-nya: sertifikasi dasar, komunitas internal champion lintas tim, visibilitas ke leadership. Champion bukan polisi yang menghalangi tim — ia mempercepat, karena pertanyaan keamanan kecil tidak lagi mengantri tiket lintas departemen.

#Secure Defaults dan Checklist PR

Budaya yang baik membuat pilihan aman menjadi jalan paling mudah. Contoh default yang menghilangkan kelas kesalahan utuh:

repo_defaults:
  secrets:
    - ".env diblokir .gitignore + pre-commit secret scanner"
    - "Secret management via vault; larangan hardcode credential"
  dependencies:
    - "Dependabot/Renovate aktif; patch update auto-merge"
    - "CI gagal jika ada CVE critical/high di dependency tree"
  api:
    - "Auth middleware default ON; endpoint publik harus opt-out eksplisit"
    - "Rate limiting default di gateway"
  logging:
    - "Larangan log PII; helper logger yang redaksi otomatis"
 
pr_security_checklist:      # dipakai saat menyentuh area sensitif
  - "Input dari user divalidasi & di-sanitize?"
  - "Authorization dicek di server side (bukan cuma UI)?"
  - "Data PII: minimalkan, enkripsi at rest/in transit?"
  - "Error message tidak bocorkan detail internal?"

Perhatikan filosofi checklist-nya: ia pendek, dipakai kondisional (area sensitif saja), dan tiap butir menjawab pertanyaan — bukan daftar 40 butir yang di-centang buta. Default yang kuat mengurangi ketergantungan pada disiplin individual, dan disiplin individual yang tersisa difokuskan pada hal yang benar-benar butuh judgment.

#Drill: Phishing, Tabletop, dan Rotasi Respons

Budaya keamanan butuh latihan seperti on-call butuh insiden simulasi:

• Phishing simulation berkala (koordinasi dengan IT/security): tujuannya melatih refleks melapor, bukan mempermalukan korban — rayakan yang melaporkan.
• Tabletop exercise per kuartal: skenario "database user bocor sekarang; apa 30 menit pertama kita?" — jalankan 60 menit dengan role play (who calls whom, who drafts comms), catat gap ke runbook.
• Rotasi respons: libatkan anggota tim bergilir dalam postmortem keamanan agar pemahaman menyebar melebihi satu champion (bus factor, episode 6).

Latihan-latihan ini juga jadi input berharga untuk episode berikutnya: readiness yang kalian bangun di sini adalah fondasi compliance (episode 19) dan crisis leadership (episode 20).

#Menyeimbangkan Kecepatan dan Risiko

Kritik klasik terhadap security culture: "ini menghambat ship". Jawaban EM yang dewasa bukan memilih sisi, melainkan menyediakan jalur risiko yang eksplisit — sama seperti two-way door di episode 2:

• Risiko rendah-reversibel (fitur internal, data dummy): jalur cepat, gate otomatis standar.
• Risiko tinggi-susah dibalik (payment, auth, data PII): review champion + security, threat modeling ringan wajib.
• Situasi darurat bisnis: eksepsi boleh, dengan expiry date tertulis dan tiket pengembalian yang masuk debt register (episode 9) — eksepsi tanpa tanggal menjadi lubang permanen yang menyamar sebagai keputusan.

Ukuran keberhasilan budaya ini bukan nol temuan, melainkan: waktu deteksi temuan makin awal di lifecycle, jumlah eksepsi kedaluwarsa mendekati nol, dan engineer berani menghentikan rilis karena kekhawatiran keamanan tanpa takut dianggap pengganggu — itulah psychological safety yang bekerja pada sumbu keamanan.

#Penutup

Inti yang harus dibawa pulang:

• Insiden lahir dari keputusan kecil harian; budaya tim adalah kontrol utamanya, dan UU PDP menaikkan taruhannya di 2026.
• Shift-left memindahkan keamanan ke titik termurah: DoD, CI scanning, dan pertanyaan desain rutin.
• Threat modeling ringan empat pertanyaan per desain besar — murah, tertulis, diverifikasi.
• Security champion menjembatani tim dan security korporat; beri waktu terstruktur dan jalur growth.
• Secure defaults menghapus kelas kesalahan; checklist pendek kondisional; eksepsi risiko selalu punya expiry date.

Di episode 19 selanjutnya kita lanjut ke ranah governance: Compliance & Risk Management — memahami SOC 2 dan ISO 27001 dari kacamata EM, membangun risk register organisasi, evidence collection yang tidak menyiksa tim, dan mengubah compliance dari beban administratif menjadi keunggulan kompetitif. Sampai jumpa!