Kapan Harus Gagalkan Pipeline dan Kapan Cukup Peringatan

Anda baru saja menambahkan pemindai keamanan ke pipeline CI Anda. Pemindaian pertama berjalan, dan menemukan 47 masalah. Tiga di antaranya bertanda critical, dua belas high, dan sisanya medium serta low. Sekarang Anda harus memutuskan: apakah Anda menggagalkan pipeline untuk setiap temuan, atau membiarkan semuanya lolos dan hanya mengumpulkan laporan?

Jika Anda menggagalkan semuanya, pipeline Anda akan lebih sering merah daripada hijau. Developer akan mulai mengabaikan pemindai, atau lebih buruk lagi, mereka akan mencari cara untuk melewatinya. Jika Anda tidak pernah menggagalkan pipeline, pemindai menjadi kebisingan. Tidak ada yang membaca laporan, dan kerentanan yang sama akan menetap di basis kode Anda selama berbulan-bulan.

Kedua ekstrem tidak berhasil. Jawabannya adalah ambang batas severity.

Severity Menunjukkan Apa yang Penting

Setiap pemindai keamanan mengelompokkan temuan berdasarkan severity. Labelnya sedikit berbeda antar alat, tetapi polanya konsisten: critical, high, medium, low, dan terkadang info atau unknown. Label-label ini bukan sekadar hiasan. Label-label ini memperkirakan seberapa buruk dampaknya jika seseorang mengeksploitasi kerentanan tersebut.

Temuan critical di library yang menangani autentikasi pengguna berbeda dengan temuan low di potongan kode yang berjalan sekali saat penyiapan dan tidak pernah lagi. Memperlakukan keduanya dengan cara yang sama adalah sebuah kesalahan.

Aturan sederhananya: gagalkan pipeline pada temuan critical dan high. Biarkan temuan medium dan low lolos dengan peringatan.

Diagram keputusan di bawah ini merangkum aturan tersebut:

flowchart TD A[Scanner Finding] --> B{Critical or High?} B -->|Yes| C[Fail Pipeline] B -->|No| D{Medium or Low?} D -->|Yes| E[Warn, Pass Pipeline] D -->|No| F[Ignore / Info]

Mengapa Ini Berhasil dalam Praktik

Ketika Anda menggagalkan pipeline pada temuan critical dan high, Anda memblokir masalah paling berbahaya agar tidak mencapai produksi. Ini adalah kerentanan yang secara aktif dicari oleh penyerang. Kerentanan inilah yang menyebabkan pelanggaran data, pengambilalihan layanan, dan kegagalan kepatuhan.

Ketika Anda memperingatkan pada temuan medium dan low, Anda menjaga pipeline tetap berjalan. Developer dapat melanjutkan pekerjaan mereka. Tim tidak terhambat oleh masalah yang mungkin tidak pernah berarti dalam praktik. Namun peringatan tersebut dicatat, dan seseorang perlu meninjaunya nanti.

Keseimbangan ini menjaga pipeline tetap berguna tanpa menjadikannya hambatan.

Pengecualian Ada, tetapi Perlu Aturan

Aturan sederhana adalah titik awal yang baik, tetapi proyek nyata memiliki kasus tepi.

Terkadang temuan high belum ada patch yang tersedia. Vendor belum merilis perbaikan, dan Anda tidak dapat menghapus dependensi karena dependensi tersebut penting bagi aplikasi Anda. Dalam kasus itu, menggagalkan pipeline setiap saat tidak membantu siapa pun. Anda perlu cara untuk menerima temuan itu untuk sementara sambil melacak vendor untuk perbaikan.

Terkadang temuan medium berada di komponen sensitif seperti enkripsi atau autentikasi. Meskipun pemindai menilainya medium, risikonya lebih tinggi karena letaknya. Anda mungkin ingin menggagalkan pipeline untuk temuan spesifik itu meskipun bukan critical atau high.

Di sinilah quality gate berbasis risiko menjadi lebih berguna daripada gate berbasis jumlah.

Bangun Quality Gate, Bukan Aturan Zero-Finding

Kesalahan umum adalah menetapkan aturan "pipeline gagal jika ada temuan apa pun." Kedengarannya ketat dan aman, tetapi dalam praktiknya menimbulkan masalah. Pemindai menghasilkan false positive. Mereka menandai hal-hal yang sebenarnya tidak dapat dieksploitasi di pengaturan spesifik Anda. Jika Anda menggagalkan semuanya, developer belajar mengabaikan pemindai atau meminta pengecualian untuk semuanya. Gate kehilangan maknanya.

Quality gate yang lebih baik mengevaluasi apakah temuan melanggar ambang batas risiko. Contoh:

  • Pipeline gagal jika ada temuan critical atau high tanpa pengecualian yang disetujui.
  • Pipeline gagal jika ada temuan medium di modul autentikasi.
  • Pipeline gagal jika temuan yang sama telah terbuka lebih dari 30 hari tanpa tindakan.

Aturan-aturan ini lebih realistis daripada "zero findings." Aturan-aturan ini mengakui bahwa beberapa kerentanan dapat dikelola, sementara yang lain harus segera diblokir.

Cara Menyiapkan Ambang Batas Anda

Mulailah dengan apa yang sudah disediakan pemindai Anda. Sebagian besar pemindai memungkinkan Anda mengonfigurasi kode keluar berdasarkan severity. Atur critical dan high untuk menggagalkan build. Atur medium dan low untuk lolos tetapi mencatat peringatan.

Kemudian tambahkan notifikasi. Ketika temuan medium dan low muncul, kirim pesan ke saluran obrolan tim atau buat tiket di pelacak masalah Anda. Tim harus meninjau temuan ini secara berkala, mungkin setiap sprint atau sebelum setiap rilis besar. Dengan cara ini, temuan tidak hilang, tetapi juga tidak menghalangi pekerjaan sehari-hari.

Setelah ambang batas dasar berjalan, amati perilakunya. Jika pipeline terlalu sering gagal, periksa apakah temuan itu nyata atau false positive. Jika pipeline hampir tidak pernah gagal, periksa apakah pemindai Anda dikonfigurasi dengan benar dan memindai hal yang tepat.

Apa yang Sebenarnya Dilakukan Gate

Security gate di pipeline Anda bukan jaminan bahwa aplikasi Anda sepenuhnya aman. Tidak ada pemindai otomatis yang dapat menemukan setiap kerentanan. Tidak ada aturan pipeline yang dapat mencegah setiap kesalahan.

Yang dilakukan gate adalah mencegah masalah paling berbahaya mencapai produksi secara otomatis. Gate menangkap hal-hal yang akan membuat Anda terjaga di malam hari jika hal-hal tersebut diterapkan. Untuk yang lainnya, Anda mengandalkan tinjauan manual, perbaikan terjadwal, dan praktik rekayasa yang baik.

Ini lebih realistis dan lebih berkelanjutan daripada mencoba mencapai zero findings. Tim yang menargetkan zero findings sering kali kelelahan atau mulai memanipulasi sistem. Tim yang menargetkan pemblokiran masalah terburuk dan mengelola sisanya cenderung tetap efektif seiring waktu.

Daftar Periksa Praktis

  • Atur temuan critical dan high untuk menggagalkan pipeline.
  • Atur temuan medium dan low untuk lolos dengan peringatan.
  • Konfigurasikan notifikasi untuk temuan medium dan low agar tim dapat meninjaunya nanti.
  • Buat proses untuk menyetujui pengecualian ketika temuan tidak dapat segera diperbaiki.
  • Tinjau permintaan pengecualian dengan kelompok kecil, bukan satu orang.
  • Tetapkan tanggal kedaluwarsa pada pengecualian agar tidak terbuka selamanya.
  • Tinjau ambang batas Anda setiap beberapa bulan untuk menyesuaikan berdasarkan pengalaman nyata.

Kesimpulan

Gate pipeline Anda tidak perlu menangkap semuanya. Gate perlu menangkap hal-hal yang paling penting. Mulailah dengan critical dan high sebagai blokir keras. Biarkan medium dan low menjadi peringatan yang ditinjau tim sesuai jadwal. Bangun proses pengecualian sederhana untuk kasus di mana perbaikan tidak segera memungkinkan. Kombinasi itu menjaga pipeline Anda tetap berjalan dan lingkungan produksi Anda lebih aman daripada mencoba memblokir semuanya.