Kenapa Pipeline Anda Perlu Memeriksa Keamanan dan Kepatuhan

Saat tim Anda pertama kali menyiapkan pipeline CI/CD, pemeriksaan yang ditambahkan biasanya adalah hal-hal teknis yang jelas: apakah kode bisa dikompilasi, apakah unit test lolos, apakah aplikasi bisa dijalankan. Itu masuk akal. Pada tahap itu, masalah yang paling terasa adalah kode yang rusak dan fitur yang tidak berfungsi.

Namun begitu pengguna nyata mulai menggunakan aplikasi Anda, pertanyaan baru muncul. Apakah kode ini memiliki celah keamanan? Apakah library itu memiliki kerentanan yang diketahui? Apakah konfigurasi server mengikuti kebijakan perusahaan? Apakah seseorang tidak sengaja melakukan commit password?

Kebanyakan tim menjawab pertanyaan-pertanyaan ini secara manual. Tim keamanan melakukan audit berkala. Seseorang mengisi daftar periksa kepatuhan sebelum setiap rilis. Pendekatan manual ini memiliki tiga masalah.

Pertama, pemeriksaan dilakukan setelah kode selesai, terkadang setelah sudah di produksi. Ketika Anda menemukan masalah, memperbaikinya berarti bolak-balik antara tim pengembang dan tim keamanan. Itu mahal dan lambat.

Kedua, pemeriksaan manual tidak konsisten. Orang yang sama bisa melewatkan hal yang berbeda di hari yang berbeda. Dua orang bisa menafsirkan aturan yang sama secara berbeda.

Ketiga, proses manual tidak bisa mengimbangi ketika tim Anda melakukan deploy beberapa kali sehari. Hambatan bergeser dari menulis kode menjadi menunggu persetujuan dan daftar periksa.

Pipeline sebagai Penjaga Gerbang Otomatis

Inilah mengapa pemeriksaan keamanan dan kepatuhan perlu berada di dalam pipeline Anda. Idenya sederhana: setiap kali seseorang melakukan push perubahan, pipeline menjalankan pemeriksaan yang sama, dengan cara yang sama, dan memberikan hasil yang konsisten.

Jika ada kerentanan keamanan, pipeline memberi tahu Anda sebelum kode mencapai produksi. Jika konfigurasi melanggar kebijakan perusahaan, pipeline menghentikan proses sebelum masalah menyebar.

Ini bukan tentang menggantikan tim keamanan Anda. Ini tentang menangkap masalah yang jelas secara otomatis sehingga tim keamanan bisa fokus pada pertanyaan yang lebih sulit yang membutuhkan penilaian manusia.

Kekhawatiran tentang Kecepatan

Banyak tim khawatir bahwa menambahkan pemeriksaan keamanan akan memperlambat pipeline. Kekhawatiran itu valid, tetapi masalahnya bukan pada pemeriksaan itu sendiri. Masalahnya adalah menjalankan setiap pemeriksaan pada setiap commit tanpa memikirkan pemeriksaan mana yang penting kapan.

Menjalankan pemindaian kerentanan dependensi penuh yang memakan waktu lima belas menit pada setiap commit pasti akan membuat frustrasi pengembang Anda. Tetapi menjalankan pemindaian berat yang sama sekali sehari, atau hanya sebelum menggabungkan ke branch utama, memiliki dampak minimal pada kecepatan pengembang.

Kuncinya adalah memisahkan pemeriksaan cepat dari pemeriksaan lambat.

Pemeriksaan cepat selesai dalam hitungan detik. Memindai rahasia yang tidak sengaja di-commit ke repositori hampir tidak memakan waktu. Memeriksa bahwa lisensi library dapat diterima juga sama cepatnya. Pemeriksaan ini harus dijalankan pada setiap commit. Mereka menangkap masalah sejak dini, dan cukup murah sehingga tidak ada yang merasa terganggu dengan penundaan.

Pemeriksaan lambat memakan waktu menit atau lebih. Memindai dependensi terhadap database kerentanan memerlukan pengunduhan dan perbandingan data. Memindai image container untuk CVE yang diketahui melibatkan analisis layer dan paket yang terinstal. Pemeriksaan ini berharga, tetapi tidak perlu dijalankan pada setiap push kode. Jalankan ketika seseorang membuka pull request, atau sebelum deploy ke lingkungan staging.

Seperti Apa Pemeriksaan Keamanan di Pipeline

Mari kita buat ini konkret. Berikut adalah kategori umum pemeriksaan keamanan dan kepatuhan yang seharusnya ada di pipeline:

Secret scanning. Alat yang mendeteksi API key, password, token, dan sertifikat yang di-commit ke repositori. Ini berjalan cepat dan harus dijalankan pada setiap commit. Jika seseorang tidak sengaja melakukan push kredensial, Anda ingin tahu segera, bukan setelah kode mencapai produksi.

Dependency scanning. Pemeriksaan yang membandingkan dependensi proyek Anda dengan database kerentanan yang diketahui. Ini memberi tahu Anda jika library yang Anda gunakan memiliki CVE yang dipublikasikan. Jalankan pada pull request dan sebelum deploy produksi.

Static application security testing (SAST). Alat yang menganalisis kode sumber Anda untuk pola keamanan tanpa mengeksekusi kode. Mereka mencari risiko SQL injection, kerentanan cross-site scripting, fungsi kriptografi yang tidak aman, dan masalah serupa. Alat SAST bervariasi dalam kecepatan, tetapi banyak yang bisa berjalan dalam satu atau dua menit pada basis kode yang ukurannya wajar.

Container image scanning. Jika Anda membangun image container, memindainya untuk kerentanan di image dasar dan paket yang terinstal. Ini menangkap masalah di lapisan sistem operasi dan dependensi runtime yang tidak dikelola langsung oleh kode aplikasi Anda.

Berikut adalah tampilan langkah pemindaian image container di GitHub Actions workflow:

- name: Scan container image for vulnerabilities
  uses: aquasecurity/trivy-action@master
  with:
    image-ref: 'my-app:${{ github.sha }}'
    format: 'table'
    exit-code: '1'
    severity: 'CRITICAL,HIGH'

Langkah ini menjalankan Trivy terhadap image yang dibangun, menghasilkan tabel temuan, dan menggagalkan job jika ada kerentanan dengan tingkat keparahan critical atau high yang ditemukan. exit-code: '1' memastikan pipeline berhenti, bertindak sebagai penjaga gerbang otomatis.

Infrastructure as code scanning. Jika Anda mendefinisikan infrastruktur dengan Terraform, CloudFormation, atau alat serupa, memindai definisi tersebut untuk miskonfigurasi. Hal-hal seperti security group yang terbuka, penyimpanan yang tidak terenkripsi, atau kebijakan IAM yang terlalu permisif.

License compliance. Memeriksa bahwa lisensi dependensi Anda kompatibel dengan lisensi proyek dan kebijakan perusahaan. Ini sangat penting untuk produk komersial atau proyek yang mungkin didistribusikan secara eksternal.

Pendekatan Praktis untuk Memulai

Anda tidak perlu mengimplementasikan semua ini sekaligus. Mulailah dengan pemeriksaan yang mengatasi risiko paling mendesak Anda.

Jika tim Anda pernah tidak sengaja melakukan commit rahasia, mulailah dengan secret scanning. Jika Anda pernah dirugikan oleh library yang rentan, mulailah dengan dependency scanning. Jika tim infrastruktur Anda menemukan miskonfigurasi di produksi, mulailah dengan IaC scanning.

Tambahkan pemeriksaan secara bertahap. Jalankan pemeriksaan cepat pada setiap commit. Jadwalkan pemeriksaan lambat pada waktu pull request atau sebelum deploy staging. Biarkan pipeline memberi tahu Anda ketika pemeriksaan gagal, dan pastikan pesan kegagalan cukup jelas sehingga pengembang tahu apa yang harus diperbaiki.

Daftar Periksa Cepat untuk Pipeline Anda

• Secret scanning berjalan pada setiap commit
• Dependency scanning berjalan pada pull request dan sebelum deploy produksi
• SAST berjalan pada pull request
• Container image scanning berjalan sebelum deploy staging
• Infrastructure as code scanning berjalan pada perubahan infrastruktur
• License compliance berjalan pada pull request
• Pemeriksaan cepat (detik) berjalan pada setiap commit
• Pemeriksaan lambat (menit) berjalan pada pull request atau sebelum staging

Nilai Sebenarnya

Pemeriksaan keamanan dan kepatuhan di pipeline Anda bukanlah birokrasi tambahan yang memperlambat Anda. Mereka adalah pagar pengaman yang memungkinkan tim Anda bergerak lebih cepat dengan percaya diri. Ketika setiap perubahan melewati pemeriksaan otomatis yang sama, Anda tidak perlu bertanya-tanya apakah rilis ini memiliki kerentanan yang diketahui atau melanggar kebijakan perusahaan. Pipeline sudah menjawab pertanyaan-pertanyaan itu.

Tim Anda bisa fokus membangun fitur dan memperbaiki bug, mengetahui bahwa filter keamanan dan kepatuhan dasar berjalan secara otomatis, konsisten, dan segera. Itulah perbedaan antara berharap tidak ada yang salah dan mengetahui bahwa tidak ada yang salah secara jelas.