Workflow n8n untuk Memantau CVE dan Membuka Tiket Insiden Secara Aman

Memantau kerentanan tidak cukup dengan mengumpulkan daftar CVE. Tim juga perlu memilah mana yang benar-benar menyentuh aset, mencegah tiket ganda, dan memberi jalur eskalasi yang jelas. Di sini saya membangun workflow n8n yang mengambil advisory dari sumber publik, menormalkan data, menerapkan aturan risiko, lalu membuat tiket insiden secara terkendali.

Workflow ini cocok untuk tim yang sudah memiliki inventaris aplikasi dan ticketing system. Kita mulai dari alur sederhana, kemudian menambah deduplikasi, enrichment, persetujuan, dan observability.

Hasil akhir workflow

Alurnya adalah:

Schedule Trigger berjalan berkala.
HTTP Request mengambil feed advisory CVE berbentuk JSON.
Code menormalkan ID, skor CVSS, produk terdampak, dan URL sumber.
Data Store atau database menyimpan fingerprint advisory yang sudah diproses.
IF menyaring CVE berdasarkan skor, status eksploitasi, dan kecocokan inventaris.
Jira, Linear, atau sistem tiket internal membuat tiket hanya untuk temuan baru.
Slack atau email mengirim ringkasan ke kanal keamanan.
Error Trigger mengirim notifikasi ketika node gagal.

Jangan langsung memberi hak workflow untuk mengubah firewall, memasang patch, atau mematikan layanan. Tahap pertama sebaiknya hanya membuat rekomendasi dan tiket yang dapat ditinjau manusia.

Langkah 1: Siapkan input dan kredensial

Buat credential terpisah untuk setiap integrasi. Token ticketing cukup memiliki izin membuat tiket dan menambahkan komentar. Credential Slack atau email hanya perlu izin mengirim pesan ke kanal yang ditentukan.

Siapkan pula daftar aset dalam tabel sederhana, misalnya:

asset_name,product,version,owner,environment
checkout-api,nginx,1.25.4,platform,production
admin-portal,openssl,3.0.12,security,production

Sumber advisory harus memiliki URL yang dapat diverifikasi. Simpan source_url, published_at, dan last_modified pada data hasil normalisasi agar setiap tiket memiliki jejak sumber.

Langkah 2: Ambil advisory dengan HTTP Request

Tambahkan Schedule Trigger untuk menjalankan workflow setiap 30 menit atau satu jam. Untuk tahap awal, pilih interval yang seimbang dengan batas rate API sumber.

Pada node HTTP Request:

Gunakan endpoint feed resmi atau API yang terdokumentasi.
Aktifkan timeout.
Atur retry terbatas untuk status 429 dan 5xx.
Jangan menaruh token di query string jika header authorization tersedia.
Simpan response mentah hanya selama masa retensi yang diperlukan.

Jika sumber mengembalikan pagination, gunakan loop dengan batas maksimum halaman. Guardrail ini mencegah workflow berjalan tanpa akhir ketika API berubah perilaku.

Langkah 3: Normalisasi dengan Code node

Buat satu bentuk data internal agar aturan berikutnya tidak bergantung pada format setiap sumber. Contoh Code node berikut hanya membaca data dan menghasilkan objek baru.

return items.flatMap((item) => {
  const advisory = item.json;
  const cveId = String(advisory.id || advisory.cve || '').trim().toUpperCase();
  const score = Number(advisory.cvss?.baseScore ?? advisory.cvss_score ?? 0);
  const sourceUrl = String(advisory.url || advisory.source_url || '').trim();

  if (!/^CVE-\\d{4}-\\d{4,}$/.test(cveId) || !sourceUrl) {
    return [];
  }

  return [{
    json: {
      cve_id: cveId,
      cvss_score: Number.isFinite(score) ? score : 0,
      exploited: Boolean(advisory.exploited || advisory.known_exploited),
      source_url: sourceUrl,
      published_at: advisory.published_at || null,
      last_modified: advisory.last_modified || null,
      description: String(advisory.description || '').slice(0, 2000),
      received_at: new Date().toISOString(),
    },
  }];
});

Jangan mempercayai nilai cvss_score tanpa validasi. Nilai yang tidak numerik harus menjadi nol atau diarahkan ke antrean review, bukan dianggap berisiko rendah secara diam-diam.

Langkah 4: Cocokkan dengan inventaris

Gunakan Merge atau query database untuk mencocokkan produk dan versi advisory dengan inventaris internal. Bila versi tidak dapat dipastikan, beri status needs_review dan jangan langsung membuat tiket prioritas tinggi.

Aturan praktis yang dapat digunakan:

critical: CVSS minimal 9, aset cocok, atau advisory ditandai sudah dieksploitasi.
high: CVSS minimal 7 dan aset production cocok.
review: produk cocok tetapi versi atau status exploit belum jelas.
ignore: tidak ada kecocokan aset setelah pemeriksaan normalisasi.

Ambang ini bukan pengganti risk assessment. Pemilik layanan tetap harus dapat mengubah prioritas karena exposure, kompensasi kontrol, dan dampak bisnis berbeda antar sistem.

Langkah 5: Deduplikasi dengan fingerprint

Buat fingerprint dari CVE, aset, dan versi. Simpan fingerprint pada Data Store dengan timestamp dan ID tiket. Sebelum membuat tiket, lakukan lookup terlebih dahulu.

Contoh logika:

const crypto = require('crypto');
const value = `${$json.cve_id}|${$json.asset_name || 'unknown'}|${$json.version || 'unknown'}`;
const fingerprint = crypto.createHash('sha256').update(value).digest('hex');
return [{ json: { ...$json, fingerprint } }];

Jika runtime n8n Anda tidak mengizinkan modul tersebut, gunakan kombinasi string yang sudah dinormalisasi sebagai key. Yang penting, key konsisten dan tidak memasukkan data rahasia.

Saat tiket sudah dibuat, simpan ticket_id, fingerprint, created_at, dan status terakhir. Jika advisory diperbarui dengan skor atau exploit status baru, buat komentar atau tiket perubahan, bukan tiket duplikat.

Langkah 6: Buat tiket dengan guardrail

Pasang node IF sebelum ticketing. Kondisi minimalnya:

risk in [critical, high]
AND asset_environment = production
AND fingerprint belum pernah diproses
AND source_url tidak kosong

Untuk organisasi yang baru mengadopsi otomasi, tambahkan Wait atau jalur persetujuan untuk critical finding. Pesan persetujuan harus berisi CVE, aset, bukti sumber, alasan prioritas, dan batas waktu respons.

Field tiket yang disarankan:

Judul: [CVE-2026-XXXX] Review patch untuk checkout-api
Deskripsi: ringkasan advisory, aset terdampak, skor, URL sumber, dan waktu pengambilan
Prioritas: hasil aturan risiko
Owner: pemilik aset dari inventaris
Due date: berasal dari SLA internal
Label: security, cve, dan environment

Hindari memasukkan secret, isi .env, atau response mentah yang mengandung data sensitif ke deskripsi tiket.

Langkah 7: Notifikasi dan observability

Kirim ringkasan ke kanal keamanan setelah tiket berhasil dibuat. Sertakan jumlah temuan baru, jumlah yang dilewati karena duplikat, dan jumlah yang menunggu review.

Tambahkan workflow terpisah memakai Error Trigger. Notifikasi error perlu mencantumkan nama workflow, node yang gagal, waktu, execution ID, dan tautan run jika tersedia. Jangan mengirim payload credential ke Slack atau email.

Aktifkan pruning execution sesuai kebutuhan audit. Retensi terlalu panjang memperbesar exposure data, sedangkan retensi terlalu pendek menyulitkan investigasi. Pilih kebijakan berdasarkan klasifikasi data dan kewajiban organisasi.

Validasi sebelum production

Uji workflow dengan empat fixture lokal:

CVE critical yang cocok dengan aset production.
CVE yang sama untuk kedua kalinya.
Advisory dengan skor tidak valid dan URL kosong.
CVE high untuk aset development yang tidak perlu eskalasi production.

Pastikan hasilnya sebagai berikut:

Fixture pertama membuat tepat satu tiket.
Fixture kedua tidak membuat tiket baru.
Fixture ketiga masuk ke jalur review atau ditolak secara eksplisit.
Fixture keempat mengikuti aturan environment yang sudah disepakati.
Semua tiket menyimpan source URL dan fingerprint.
Kegagalan API menghasilkan alert tanpa membocorkan token.

Jalankan juga uji rate limit dengan batch kecil. Periksa bahwa retry memiliki batas dan workflow tidak membuat ledakan request.

Pengembangan bertahap

Setelah alur dasar stabil, tambahkan enrichment dari inventaris cloud, pemetaan owner otomatis, SLA berdasarkan criticality, dan dashboard metrik. Tahap berikutnya dapat mengusulkan patch atau pull request, tetapi eksekusi perubahan tetap membutuhkan review, backup, dan rollback yang jelas.

Otomasi keamanan yang baik bukan yang paling agresif. Nilainya ada pada data yang konsisten, tiket yang tidak berulang, sumber yang dapat diverifikasi, dan keputusan yang tetap dapat dipertanggungjawabkan oleh tim.