Web Application Security Fundamentals #06: Secure SDLC

Security yang baru diperiksa menjelang release hampir selalu mahal dan terburu-buru. Secure SDLC memasukkan security requirement dan verification sejak planning hingga monitoring.

Etika dan scope: praktikkan hanya pada local lab, aplikasi milik sendiri, atau sistem yang memberikan izin tertulis. Tutorial ini tidak mengizinkan pengujian terhadap target publik.

Tujuan pembelajaran

• menempatkan aktivitas security pada setiap fase SDLC
• membuat security requirement dan threat model ringan
• mengatur quality gate yang berbasis evidence
• menjaga feedback loop setelah deployment

Prasyarat

Gunakan browser modern, Developer Tools, dan local lab. Catat versi tool serta environment ketika menguji. Output contoh bersifat ilustratif kecuali dinyatakan sebagai hasil pengujian; jangan menganggap perilaku satu stack berlaku universal.

1. Planning dan requirement

Klasifikasikan data, tetapkan owner, compliance constraint, abuse case, dan acceptance criteria. Hindari requirement “harus aman”. Nyatakan actor, action, asset, condition, dan evidence.

2. Design

Buat data flow diagram dan trust boundary. Tinjau authentication, authorization, tenant isolation, secret, encryption, logging, failure mode, dan dependency. Gunakan threat modeling untuk menemukan design flaw sebelum source code mengeras.

3. Implementation

Gunakan secure framework default, parameterized API, centralized authorization, schema validation, secret manager, dan dependency pinning yang tepat. Review perubahan sensitif dengan checklist singkat yang relevan terhadap feature.

4. Verification

Gabungkan unit test, integration test, authorization matrix, SAST, dependency analysis, secret scanning, DAST pada environment terkontrol, dan manual testing untuk business logic. Tool bersifat saling melengkapi; satu scanner tidak mewakili seluruh coverage.

5. Deployment

Gunakan least-privilege identity, immutable artifact bila memungkinkan, environment separation, configuration validation, dan rollback plan. Secret tidak boleh dibundel ke image atau frontend bundle.

6. Operations

Monitor security event, dependency advisory, certificate lifecycle, abnormal failure, dan perubahan konfigurasi. Uji alert dan incident playbook. Patch tanpa verification dapat menimbulkan regression; verification tanpa patch SLA membuat temuan menumpuk.

7. Definition of Done

Contoh:

• threat scenario untuk feature sensitif ditinjau;
• authorization negative test lulus;
• secret scan bersih;
• dependency exception memiliki owner dan expiry;
• logging tidak menyimpan credential;
• runbook dan rollback tersedia;
• evidence ditautkan pada work item.

8. Metrics yang sehat

Hindari hanya menghitung jumlah vulnerability. Pertimbangkan remediation time berdasarkan severity/context, recurrence, percentage feature sensitif dengan threat model, control test coverage, dan alert detection-to-response time.

Kesalahan umum

• Menjadikan security tanggung jawab satu tim.
• Membuat gate yang selalu di-bypass saat deadline.
• Menghasilkan temuan tanpa owner.
• Menyamakan tool adoption dengan risk reduction.
• Tidak belajar dari incident dan near miss.

Quality gate sebelum diterapkan

• [ ] Scope dan asset sudah jelas.
• [ ] Control dijalankan di sisi yang menjadi security boundary.
• [ ] Positive test dan negative test tersedia.
• [ ] Error tidak membocorkan secret atau detail internal.
• [ ] Logging cukup untuk detection tanpa merekam credential.
• [ ] Versi dependency dan dokumentasi dicatat.
• [ ] Tidak ada klaim “100% aman”.
• [ ] Perubahan diuji pada staging atau local lab.

Kesimpulan

Secure SDLC memberi tempat bagi control. Tutorial berikutnya masuk ke control paling awal pada data flow: Input Validation.

Referensi resmi

• OWASP Top 10:2025 — diakses 22 Agustus 2026.
• OWASP Cheat Sheet Series — diakses 22 Agustus 2026.
• OWASP Web Security Testing Guide — Stable — diakses 22 Agustus 2026.
• MDN Web Security — diakses 22 Agustus 2026.