Saat Pipeline Keamanan Memblokir Semuanya: Menangani Pengecualian Tanpa Membuat Celah

Anda memiliki pemindaian keamanan yang berjalan di pipeline CI. Pemindaian tersebut menemukan kerentanan di library yang digunakan tim Anda. Tingkat keparahannya sedang, tetapi belum ada versi patch yang tersedia. Pipeline Anda gagal. Tim Anda tidak bisa melakukan deploy.

Sekarang Anda punya pilihan. Anda bisa menonaktifkan pemindaian sepenuhnya, menurunkan ambang batas hingga semuanya lolos, atau mulai mengabaikan hasil pipeline. Tidak satu pun dari opsi tersebut yang baik. Namun jika Anda membuatnya terlalu mudah untuk melewati temuan individual, pipeline tidak lagi berguna sebagai jaring pengaman.

Inilah masalah pengecualian. Setiap tim yang menerapkan aturan keamanan atau kepatuhan di pipeline pada akhirnya akan mengalaminya. Solusinya bukan dengan menghilangkan gerbang pemeriksaan. Solusinya adalah membangun mekanisme penanganan pengecualian yang jelas dan dapat dipertanggungjawabkan.

Mengapa Pengecualian Ada

Pengecualian bukanlah tanda proses yang rusak. Pengecualian adalah tanda bahwa dunia nyata tidak selalu sesuai dengan aturan Anda. Sebuah library memiliki kerentanan yang diketahui, tetapi maintainer belum merilis perbaikan. Aturan kepatuhan melarang konfigurasi tertentu, tetapi infrastruktur Anda belum bisa mendukung alternatifnya saat ini. Temuan keamanan secara teknis valid, tetapi risikonya dapat diterima dalam konteks spesifik Anda.

Jika pipeline Anda tidak memiliki cara untuk menangani situasi ini, tim Anda akan mencari jalan lain. Mereka akan menonaktifkan pemindaian. Mereka akan memperlemah ambang batas. Mereka akan mulai menganggap pipeline merah sebagai hal yang normal. Pipeline menjadi formalitas belaka, dan celah keamanan tetap ada.

Tujuannya adalah menjaga pipeline tetap ketat sambil memberikan jalur yang sah bagi tim ketika mereka menemui hambatan nyata.

Empat Aturan untuk Menangani Pengecualian

Mekanisme pengecualian yang baik memiliki empat properti. Masing-masing mencegah mode kegagalan spesifik yang sering dialami tim.

Diagram alir berikut mengilustrasikan siklus hidup pengecualian lengkap yang dijelaskan oleh empat aturan:

flowchart TD A[Finding Blocks Pipeline] --> B[Record Exception Who, What, Why] B --> C[Submit for Approval] C --> D{Approved?} D -- No --> E[Pipeline Remains Blocked] D -- Yes --> F[Set Expiration Date] F --> G[Exception Active Pipeline Passes] G --> H{Expired?} H -- No --> G H -- Yes --> I[Pipeline Fails Exception Expired] I --> J[Review & Resolve] J --> K{Blocker Resolved?} K -- Yes --> L[Remove Exception] K -- No --> B

1. Pengecualian Harus Dicatat

Aturan pertama adalah yang paling sederhana: catat. Pengecualian bukanlah komentar di pull request atau pesan di saluran chat. Pengecualian perlu berada di tempat yang bisa dilihat semua orang. Tim keamanan, tim kepatuhan, dan tim yang menjalankan pipeline semuanya perlu memiliki akses ke catatan yang sama.

Di mana Anda menyimpannya tidak terlalu penting, yang penting Anda menyimpannya. File konfigurasi di repositori bisa digunakan. Entri di issue tracker juga bisa. Yang penting catatan tersebut berisi tiga hal: siapa yang mengajukan pengecualian, apa yang dikecualikan, dan mengapa.

2. Pengecualian Harus Disetujui

Satu orang tidak boleh memutuskan untuk melewati gerbang keamanan. Pengembang yang menemukan hambatan dapat mengajukan pengecualian, tetapi persetujuan harus datang dari seseorang yang memahami risikonya. Insinyur keamanan menyetujui pengecualian terkait keamanan. Petugas kepatuhan menyetujui pelanggaran kebijakan. Persetujuan itu sendiri dapat dilakukan melalui pull request terpisah atau melalui langkah persetujuan di pipeline.

Langkah ini mencegah penyalahgunaan pengecualian yang paling umum: pengembang menandai temuan mereka sendiri sebagai dapat diterima tanpa ada orang lain yang meninjau alasannya.

3. Pengecualian Harus Kedaluwarsa

Ini adalah aturan yang paling sering dilupakan tim. Pengecualian dibuat karena sesuatu untuk sementara terblokir. Enam bulan kemudian, library mungkin sudah memiliki patch. Keterbatasan infrastruktur mungkin sudah teratasi. Namun pengecualian masih ada, secara diam-diam mengizinkan kerentanan yang sama untuk lolos di setiap deployment.

Setiap pengecualian perlu memiliki batas waktu. Untuk kerentanan kritis, satu minggu mungkin tepat. Untuk temuan dengan tingkat keparahan rendah, satu atau tiga bulan adalah wajar. Durasi tergantung pada jenis temuan dan konteksnya, tetapi harus ada.

4. Pengecualian yang Kedaluwarsa Harus Menggagalkan Pipeline

Kedaluwarsa tidak berguna jika tidak ada yang menegakkannya. Saat pengecualian kedaluwarsa, pipeline harus secara otomatis gagal di gerbang yang relevan. Tim tidak perlu mengingat untuk memeriksanya. Pipeline itu sendiri yang menjadi pengingat. Jika hambatan masih ada, tim mengajukan pengecualian baru dengan justifikasi yang diperbarui. Jika hambatan sudah teratasi, pengecualian dihapus dan pipeline lolos kembali.

Ini menciptakan siklus peninjauan alami. Setiap pengecualian akan ditinjau ulang setidaknya sekali sebelum dapat dilanjutkan.

Analogi Utang Teknis

Pola ini bukanlah hal baru. Ini adalah cara yang sama yang digunakan tim baik dalam menangani utang teknis. Anda tidak berpura-pura utang itu tidak ada. Anda mencatatnya, memprioritaskannya, dan menjadwalkan waktu untuk melunasinya. Pengecualian keamanan bekerja dengan cara yang sama. Anda tidak mengabaikan kerentanan. Anda mengakuinya, mendokumentasikan keputusan, dan menetapkan tenggat waktu untuk mengatasinya.

Perbedaannya adalah utang teknis seringkali tidak terlihat sampai menyebabkan masalah. Pengecualian keamanan terlihat sejak saat dibuat. Pipeline mencatatnya. Persetujuan merekamnya. Tanggal kedaluwarsa membuatnya mustahil untuk dilupakan.

Daftar Periksa Praktis

Jika Anda menyiapkan mekanisme pengecualian untuk pipeline Anda, berikut adalah daftar periksa singkat untuk memulai:

  • Pilih lokasi penyimpanan untuk pengecualian yang dapat diakses oleh tim keamanan, kepatuhan, dan engineering
  • Tentukan siapa yang dapat menyetujui setiap jenis pengecualian (temuan keamanan, pelanggaran kepatuhan, keterbatasan infrastruktur)
  • Tetapkan durasi kedaluwarsa default untuk tingkat keparahan yang berbeda
  • Buat pipeline memeriksa tanggal kedaluwarsa secara otomatis dan gagal saat pengecualian kedaluwarsa
  • Uji alurnya: ajukan pengecualian, setujui, biarkan kedaluwarsa, dan konfirmasi perilaku pipeline

Langkah Selanjutnya

Mekanisme pengecualian yang baik menjaga pipeline Anda tetap ketat tanpa membuatnya kaku. Tim dapat bergerak maju ketika menemui hambatan nyata, tetapi tidak dapat melewati gerbang tanpa meninggalkan jejak. Pipeline tetap berguna sebagai pagar pengaman, bukan sekadar formalitas.

Setelah Anda memiliki mekanisme ini, langkah selanjutnya adalah mengkodekan semua aturan Anda sebagai kode. Kebijakan yang ditulis dalam dokumen atau diucapkan dalam rapat sulit ditegakkan secara konsisten. Aturan yang ditulis sebagai kode dapat diuji, ditinjau, dan dijalankan secara otomatis. Di situlah gerbang keamanan dan kepatuhan menjadi benar-benar andal.