Belajar Application Security Engineer - Compliance untuk Aplikasi

#Pendahuluan

Setelah di episode 19 kita membangun arsitektur zero trust, episode ini menyentuh dimensi yang membuat banyak engineer menggeliat: compliance. Reaksinya biasanya dua kutub — dianggap formalitas dokumen yang menghambat, atau dianggap urusan tim legal semata. Keduanya salah: compliance yang benar adalah kodefikasi praktik keamanan yang sudah seharusnya kalian lakukan, plus bukti terukur bahwa itu konsisten.

Sebagai AppSec engineer, kalian adalah jembatan: regulator bicara requirement, developer bicara kode — kalian menerjemahkan antar keduanya. Kita fokus pada tiga hal yang paling sering menyentuh pekerjaan aplikasi: GDPR, PCI-DSS, dan OWASP ASVS sebagai kerangka penghubungnya.

#GDPR: Privasi sebagai Properti Sistem

GDPR (dan turunannya seperti UU PDP Indonesia) mengatur pemrosesan data pribadi. Yang perlu dipahami engineer: mayoritas pasalnya bermuara ke properti teknis konkret pada aplikasi:

Dua implementasi yang paling sering gagal saat audit:

1. Right to erasure yang hanya hapus satu tabel. Data user tersebar di orders, logs, cache, search index, analytics events, dan backup. Desain yang benar: identifikasi seluruh datastore via data mapping, tentukan per-store apakah delete atau anonimisasi (data transaksi finansial wajib disimpan demi pajak — tapi bisa di-pseudonymize), dan dokumentasikan keputusannya:

users          → hard delete
orders         → pseudonymize user_id (retensi wajib pajak)
search index   → purge by user_id (job async)
app logs       → rotasi 30 hari; field email di-redaksi sejak tulis
analytics      → delete events by anonymous_id
backups        → TTL alami; restore baru menjalankan erasure ulang

2. PII di log dan analytics. logger.info({ email }) hari ini adalah pelanggaran tahun depan. Redaksi di boundary logging (episode 4) adalah kontrol preventif termurah.

#PCI-DSS: Menyentuh Kartu Tanpa Jadi Target

PCI-DSS mengatur penanganan data kartu pembayaran. Insight paling pentingnya bukan daftar kontrol, melainkan strategi scope reduction: semakin sedikit komponen yang "menyentuh" PAN (nomor kartu), semakin ringan beban compliance kalian.

Tiga level integrasi, dari paling berat:

1. Menyimpan kartu sendiri → full PCI-DSS scope: enkripsi, segmentasi jaringan, audit menyeluruh, QSA assessment. Hampir tak pernah worth it untuk produk non-payment-company.
2. Melewati server kalian (form POST ke gateway) → scope mengecil tapi masih ada (SAQ A-EP).
3. Tokenisasi via hosted fields/SDK gateway (Stripe Elements, Midtrans Snap) → kartu tak pernah menyentuh infrastruktur kalian → SAQ A, versi paling ringan.

Rekomendasi praktis AppSec: dorong arsitektur level 3 sejak desain. Kontrol teknis yang tetap milik kalian walau tokenized: jangan log token kartu mentah dari request body (redaksi), pastikan endpoint pembayaran pakai TLS ketat, dan validasi webhook signature gateway sebelum memproses status transaksi — spoofed webhook adalah jalur klasik order gratis.

#OWASP ASVS: Jembatan Requirement ↔ Implementasi

Di sinilah ASVS (Application Security Verification Standard) jadi alat favorit saya. Ia adalah checklist verifiable dengan tiga level:

V2 Authentication        (mis. 2.5.5: MFA wajib utk aksi sensitif)
V3 Session Management    (mis. 3.3.1: rotate session token on login)
V4 Access Control        (mis. 4.2.1: deny by default)
V5 Validation & Encoding (mis. 5.3.3: parameterized query wajib)
V14 Configuration        (mis. 14.4.x: header security & CSP)

Cara pakainya dalam proyek nyata: saat mulai fitur atau audit aplikasi, pilih level target (L1 standar, L2 untuk data sensitif, L3 untuk financial/critical), lalu petakan tiap item ke bukti implementasi — test case, konfigurasi, atau gap yang masuk backlog. Hasilnya:

• Developer mendapat requirement konkret ("ASVS 3.3.1") alih-alih kalimat abstrak "amankan session".
• Audit/compliance mendapat traceability: setiap requirement punya bukti bertanggal.
• Kalian mendapat bahasa bersama dengan pentester eksternal — mayoritas menyusun laporan mereka merujuk ASVS juga.

#Evidence Otomatis: Compliance dari Pipeline

Bagian yang mengubah compliance dari ritual tahunan menjadi efek samping engineering: bukti lahir otomatis dari proses yang sudah jalan:

Pola umumnya: setiap gate security di CI adalah generator evidence. Simpan hasil scan sebagai artifact bertag commit SHA, dan audit kalian tinggal query — bukan buru-buru screenshot tiga minggu sebelum deadline.

#Common Pitfalls

• Compliance theater: checklist dicentang tanpa kontrol nyata — sampai insiden membongkarnya; audit internal kalian harus menguji kontrol, bukan dokumen.
• Scope PCI melebar diam-diam: satu developer log payload request berisi PAN → seluruh log system masuk scope; redaksi di boundary adalah pagar scope.
• Erasure vs retention conflict: hapus semua data user termasuk invoice = pelanggaran pajak; pseudonymization adalah jawabannya, dan harus tertulis di desain.
• Menganggap sertifikasi vendor menutup tanggung jawab: cloud compliant ≠ aplikasi kalian compliant — shared responsibility berlaku sampai ke layer aplikasi.

#Penutup

Inti yang harus dibawa pulang:

• GDPR = properti teknis konkret: minimization, erasure lintas store, retensi, privasi-by-default; RoPA adalah sumber truth-nya.
• PCI-DSS: strategi terbaik adalah scope reduction via tokenisasi hosted fields (SAQ A); jaga scope dengan redaksi log.
• OWASP ASVS menerjemahkan regulasi menjadi requirement verifiable per level — bahasa bersama dev, audit, dan pentester.
• Evidence lahir otomatis dari security gates CI; bangun sekali, audit selamanya lebih mudah.

Di episode 21 kita masuk era baru: AI-Assisted AppSec — memakai LLM untuk mempercepat code review dan triase temuan, membangun AI security gates di CI, dan sama pentingnya: memahami batas serta risiko hallucination agar AI memperkuat program kalian, bukan meruntuhkan kredibilitasnya. Sampai jumpa di episode 21!