Audit Keamanan Otomatis di CI dengan Temuan Terverifikasi

Audit keamanan otomatis di CI berguna jika hasilnya bisa ditindaklanjuti, diverifikasi, dan ditelusuri kembali. Masalah umum pada pipeline keamanan bukan kurangnya scanner, melainkan terlalu banyak temuan mentah, false positive, dan hasil yang sulit dipakai untuk keputusan rilis.

Panduan ini membahas desain workflow CI multi-tahap untuk audit keamanan kode dengan temuan terverifikasi: hasil dalam format machine-readable, bisa ditinjau manusia, memiliki severity yang konsisten, dideduplikasi, dan dihubungkan ke commit, pull request, atau artefak rilis. Fokus utamanya adalah tooling developer dan alur release, bukan ulasan alat tertentu.

Tujuan desain pipeline

Pipeline audit keamanan yang baik bukan sekadar menjalankan SAST, dependency scan, atau secret scan. Pipeline harus menjawab empat pertanyaan operasional:

Apa yang diaudit? Scope harus jelas: file yang berubah, service yang terdampak, dependensi yang relevan, dan konfigurasi runtime terkait.
Temuan mana yang benar-benar penting? Severity, confidence, dan status verifikasi harus eksplisit.
Siapa yang harus bertindak? Temuan perlu dipetakan ke area kode, owner, atau reviewer.
Kapan hasil menjadi blocker? Tidak semua temuan layak menghentikan merge atau rilis.

Dengan prinsip ini, audit keamanan di CI menjadi bagian dari engineering workflow, bukan laporan sampingan yang diabaikan.

Arsitektur pipeline audit keamanan multi-tahap

1. Trigger pada pull request dan event rilis

Mulailah dari dua jalur utama:

Pull request: audit cepat untuk perubahan yang sedang ditinjau.
Branch utama atau candidate release: audit penuh sebagai dasar keputusan merge atau rilis.

Pada PR, target utamanya adalah feedback cepat. Jalankan analisis yang dibatasi oleh perubahan. Pada branch utama atau sebelum rilis, jalankan analisis yang lebih mahal, termasuk pemeriksaan lintas modul dan korelasi antar temuan.

Prinsip praktis: gunakan pipeline ringan untuk PR dan pipeline lebih dalam untuk release candidate. Jika semua pemeriksaan dipaksa pada setiap PR, waktu tunggu akan naik dan hasilnya cenderung diabaikan.

2. Tahap scope: tentukan area yang relevan

Tahap pertama sebaiknya bukan scanning, tetapi penentuan scope. Tujuannya mengurangi pekerjaan yang tidak perlu dan meningkatkan relevansi temuan.

Contoh sinyal yang bisa dipakai untuk menentukan scope:

Daftar file yang berubah dari base branch.
Pemetaan direktori ke service atau domain.
Perubahan pada file dependency lock.
Perubahan konfigurasi infrastruktur atau deployment.
Perubahan pada endpoint, middleware, autentikasi, atau otorisasi.

Hasil tahap ini idealnya berupa dokumen machine-readable sederhana, misalnya JSON:

{
  "commit": "abc123",
  "base": "main",
  "changed_files": [
    "services/api/routes/user.js",
    "services/api/package-lock.json",
    "infra/k8s/deployment.yaml"
  ],
  "affected_areas": ["api", "dependencies", "deployment"],
  "full_scan_required": false
}

Mengapa ini penting? Karena scanner keamanan sering menghasilkan output besar. Dengan scope yang jelas, Anda bisa memilih analisis per area: misalnya secret scan untuk file baru, dependency audit saat lockfile berubah, dan aturan otorisasi jika route atau middleware berubah.

3. Analisis per area, bukan satu job besar

Alih-alih membuat satu job keamanan yang menggabungkan semua hal, pecah pipeline menjadi beberapa analisis dengan kontrak output yang seragam. Contohnya:

Code pattern analysis: penggunaan API berisiko, input tidak tervalidasi, akses file, eksekusi perintah, query dinamis.
Dependency analysis: paket rentan, lisensi bermasalah, versi tidak terjaga.
Secret and credential scan: token, private key, kredensial yang ter-commit.
Config and IaC analysis: permission terlalu lebar, debug aktif, network policy longgar, image tanpa pin.
Auth/authz checks: perubahan route, middleware, guard, atau policy yang bisa mengubah kontrol akses.

Pemisahan ini membantu dalam tiga hal:

Lebih mudah melakukan parallel run.
Lebih mudah memetakan temuan ke owner yang tepat.
Lebih mudah menetapkan threshold blocker yang berbeda untuk tiap kategori.

Format temuan: JSON untuk mesin, Markdown untuk manusia

Skema temuan yang disarankan

Jika hasil audit ingin bisa diverifikasi independen, Anda memerlukan format output yang stabil. Jangan hanya mengandalkan log terminal. Simpan hasil terstruktur dalam JSON dengan field minimum berikut:

{
  "run_id": "ci-2026-08-26-001",
  "repository": "example/app",
  "commit_sha": "abc123",
  "pull_request": 42,
  "scanner": "custom-security-audit",
  "findings": [
    {
      "id": "AUTHZ-001",
      "rule_id": "missing-admin-check",
      "category": "authorization",
      "severity": "high",
      "confidence": "medium",
      "status": "needs_review",
      "title": "Endpoint admin tidak memeriksa hak akses",
      "description": "Route baru memanggil handler sensitif tanpa middleware otorisasi yang setara.",
      "location": {
        "path": "services/api/routes/admin.js",
        "line": 18,
        "end_line": 24
      },
      "fingerprint": "0d3b5f...",
      "evidence": [
        "Route POST /admin/users dibuat tanpa middleware policy.",
        "Handler memanggil operasi perubahan role pengguna."
      ],
      "introduced_in_pr": true,
      "related_files": [
        "services/api/routes/admin.js",
        "services/api/policies/user-policy.js"
      ],
      "recommendation": "Tambahkan middleware atau policy check sebelum handler dijalankan.",
      "references": [
        "internal-sec-guide/authz-checks"
      ]
    }
  ]
}

Field di atas dipilih karena berguna untuk tiga kebutuhan berbeda:

Mesin: severity, fingerprint, category, status, introduced_in_pr.
Reviewer manusia: title, description, evidence, recommendation.
Traceability: commit_sha, run_id, lokasi file, file terkait.

Severity dan confidence harus dipisahkan

Kesalahan umum adalah menjadikan semua temuan “high” agar terlihat tegas. Praktik ini justru menurunkan kepercayaan pada sistem. Pisahkan:

Severity: dampak jika isu benar terjadi.
Confidence: seberapa yakin sistem bahwa temuan valid.

Contoh: pola string yang menyerupai token produksi bisa memiliki severity tinggi tetapi confidence rendah jika tidak ada validasi konteks. Sebaliknya, perubahan middleware otorisasi yang jelas hilang mungkin severity tinggi dan confidence tinggi.

Dengan pemisahan ini, kebijakan gate bisa lebih masuk akal, misalnya hanya memblokir PR untuk severity tinggi dengan confidence tinggi, atau untuk temuan yang sudah diverifikasi manual.

Ringkasan Markdown untuk reviewer

Selain JSON, hasil audit perlu disajikan dalam bentuk yang mudah dibaca di PR. Format Markdown ringkas biasanya cukup:

## Ringkasan Audit Keamanan

- Commit: `abc123`
- Scope: `api`, `dependencies`
- Total temuan: 3
- High: 1 | Medium: 1 | Low: 1
- Butuh verifikasi manual: 2

### Temuan prioritas
1. **[high] Endpoint admin tidak memeriksa hak akses**
   - File: `services/api/routes/admin.js:18`
   - Status: `needs_review`
   - Rekomendasi: tambahkan policy check sebelum handler.

2. **[medium] Dependensi dengan advisori keamanan**
   - File: `services/api/package-lock.json`
   - Status: `confirmed`
   - Rekomendasi: evaluasi upgrade atau mitigasi sementara.

Markdown berguna untuk konsumsi cepat, sedangkan JSON menjadi sumber data utama untuk integrasi, dashboard, dan verifikasi ulang.

Dedup temuan dan traceability

Mengapa dedup wajib ada

Tanpa deduplikasi, satu masalah yang sama bisa muncul berkali-kali dari scanner berbeda atau dari rerun pipeline yang sama. Akibatnya:

Reviewer kewalahan.
Metrik keamanan menjadi bias.
Status resolusi sulit dilacak.

Gunakan fingerprint stabil untuk mengidentifikasi temuan yang kemungkinan sama. Fingerprint bisa dibentuk dari kombinasi:

rule_id
path atau normalized path
lokasi logis, bukan hanya nomor baris mentah
potongan evidence yang relevan

Nomor baris saja biasanya tidak cukup, karena sedikit perubahan file dapat menggeser line number dan membuat isu lama terlihat seperti isu baru.

Status temuan yang realistis

Hindari model biner “ada atau tidak ada”. Gunakan status yang mendukung proses verifikasi:

new: temuan baru dari pipeline.
needs_review: perlu verifikasi manusia.
confirmed: telah diverifikasi dan valid.
accepted_risk: diketahui dan diterima sementara dengan alasan.
fixed: sudah diperbaiki.
duplicate: duplikasi dari temuan lain.
not_applicable: tidak relevan untuk konteks ini.

Status ini penting untuk audit trail. Saat seorang reviewer menandai temuan sebagai accepted_risk, simpan juga alasan, identitas reviewer, dan batas waktu review ulang.

Artefak audit untuk verifikasi independen

Setiap run sebaiknya menghasilkan artefak yang bisa diunduh dan diperiksa di luar sistem CI. Minimal:

scope.json
findings.json
summary.md
manifest metadata: commit, branch, waktu, scanner yang dijalankan

Bila proses Anda membutuhkan tingkat jejak yang lebih kuat, simpan checksum artefak atau tandatangani manifest. Intinya bukan formalitas, tetapi memastikan bahwa reviewer, tim keamanan, atau release manager dapat memverifikasi bahwa ringkasan PR memang berasal dari hasil audit yang sama.

Approval gate dan keputusan blocker

Kapan hasil audit memblokir PR

Tidak semua temuan harus menjadi blocker. Kebijakan yang terlalu keras akan mendorong bypass manual. Kebijakan yang terlalu longgar akan membuat audit tidak berarti. Pendekatan yang umum dan praktis:

Block PR jika ada temuan confirmed severity tinggi.
Block PR jika ada secret yang terdeteksi dengan confidence tinggi.
Require approval tambahan jika ada temuan severity tinggi tetapi masih needs_review.
Warn only untuk severity rendah atau confidence rendah.

Untuk dependency vulnerability, blocker sebaiknya mempertimbangkan konteks. Kerentanan di paket development-only mungkin tidak layak menghentikan merge, sedangkan kerentanan pada komponen runtime yang terekspos jaringan lebih layak menjadi blocker.

Kapan hasil audit menjadi blocker rilis

Keputusan blocker rilis biasanya lebih ketat dibanding blocker PR. Jadikan hasil audit sebagai penghambat rilis jika:

Ada temuan confirmed severity tinggi atau kritis pada jalur runtime utama.
Ada temuan otorisasi, autentikasi, atau secret exposure yang belum dimitigasi.
Ada perubahan sensitif pada konfigurasi deployment tanpa verifikasi yang memadai.
Artefak audit tidak lengkap atau tidak bisa ditelusuri ke commit yang dirilis.

Sebaliknya, jangan otomatis memblokir rilis hanya karena ada daftar advisori tanpa bukti dampak pada jalur yang dipakai aplikasi. Gunakan kebijakan berbasis risiko, bukan jumlah temuan mentah.

Human verification tetap wajib

Temuan machine-readable membantu otomasi, tetapi keputusan akhir untuk isu sensitif tetap perlu verifikasi manusia. Alasan utamanya:

Scanner tidak memahami seluruh konteks bisnis.
Beberapa pola aman terlihat berbahaya di level sintaks.
Perubahan arsitektur bisa membuat korelasi lintas file lebih penting daripada satu rule individual.

Karena itu, desain approval gate yang baik biasanya melibatkan salah satu dari:

reviewer keamanan untuk severity tinggi,
code owner area terkait,
release manager untuk accepted risk yang berlaku sementara.

Contoh integrasi generik di GitHub Actions atau CI serupa

Contoh berikut menunjukkan struktur workflow generik. Fokusnya bukan tool tertentu, melainkan pola eksekusi dan pengelolaan artefak.

name: security-audit

on:
  pull_request:
  push:
    branches:
      - main
  workflow_dispatch:

jobs:
  scope:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Tentukan scope perubahan
        run: |
          ./ci/detect-scope.sh > scope.json
      - name: Upload scope
        uses: actions/upload-artifact@v4
        with:
          name: audit-scope
          path: scope.json

  analyze:
    needs: scope
    runs-on: ubuntu-latest
    strategy:
      matrix:
        area: [code, dependencies, secrets, config]
    steps:
      - uses: actions/checkout@v4
      - name: Download scope
        uses: actions/download-artifact@v4
        with:
          name: audit-scope
      - name: Jalankan analisis per area
        run: |
          ./ci/run-audit.sh --area ${{ matrix.area }} --scope scope.json > findings-${{ matrix.area }}.json
      - name: Upload hasil area
        uses: actions/upload-artifact@v4
        with:
          name: findings-${{ matrix.area }}
          path: findings-${{ matrix.area }}.json

  aggregate:
    needs: analyze
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Download semua temuan
        uses: actions/download-artifact@v4
      - name: Gabung, dedup, dan buat ringkasan
        run: |
          ./ci/merge-findings.sh ./findings-* > findings.json
          ./ci/render-summary.sh findings.json > summary.md
          ./ci/evaluate-gate.sh findings.json > gate.json
      - name: Upload artefak audit
        uses: actions/upload-artifact@v4
        with:
          name: security-audit-report
          path: |
            findings.json
            summary.md
            gate.json
      - name: Fail jika gate menolak
        run: |
          jq -e '.allow == true' gate.json > /dev/null

Struktur yang sama bisa diterapkan di GitLab CI, Jenkins, Buildkite, atau sistem lain. Intinya ada empat job logis:

deteksi scope,
analisis per area,
agregasi dan dedup,
evaluasi gate.

Kontrak gate sederhana

Agar integrasi ke release flow mudah, hasil evaluasi gate juga perlu machine-readable:

{
  "allow": false,
  "decision": "manual_review_required",
  "reasons": [
    "1 temuan severity high dengan status needs_review",
    "1 temuan secret exposure dengan confidence high"
  ],
  "required_approvers": [
    "security-reviewer",
    "code-owner-api"
  ]
}

Dengan format ini, sistem release tidak perlu menebak dari log text. Ia cukup membaca keputusan gate dan menentukan apakah merge atau deploy boleh lanjut.

Mengurangi false positive tanpa menurunkan cakupan

Gunakan scope yang presisi

False positive sering berasal dari analisis yang terlalu luas. Jika perubahan hanya menyentuh dokumentasi, tidak perlu menjalankan pemeriksaan authz penuh. Jika hanya lockfile yang berubah, prioritaskan dependency audit.

Gabungkan rule statis dengan konteks kode

Rule sederhana berbasis pola bisa berguna, tetapi hasilnya lebih baik bila digabung dengan konteks, misalnya:

apakah endpoint baru benar-benar terekspos,
apakah fungsi sensitif dipanggil dari jalur request,
apakah secret berada di file fixture atau contoh yang memang aman,
apakah package rentan benar-benar masuk ke runtime image.

Semakin baik konteksnya, semakin sedikit temuan yang perlu diverifikasi manual.

Sediakan mekanisme suppress yang terkontrol

Tim membutuhkan cara untuk menandai false positive atau accepted risk. Namun mekanisme ini harus terstruktur, misalnya melalui file kebijakan atau komentar terstandar, bukan menghapus rule diam-diam.

Contoh data suppress:

{
  "suppressions": [
    {
      "fingerprint": "0d3b5f...",
      "reason": "Endpoint hanya dapat diakses melalui jaringan internal dan dilindungi policy upstream.",
      "approved_by": "security-team",
      "expires_at": "2026-12-31"
    }
  ]
}

Gunakan tanggal kedaluwarsa agar suppress lama tidak bertahan tanpa review.

Ukur kualitas temuan, bukan hanya jumlah

Metrik yang lebih berguna daripada total temuan:

persentase temuan yang berakhir confirmed,
waktu rata-rata dari deteksi ke verifikasi,
jumlah blocker yang benar-benar relevan,
jumlah suppress yang kadaluwarsa atau tidak direview ulang.

Metrik ini membantu mengevaluasi apakah pipeline membantu developer atau justru membebani mereka.

DX: audit harus cepat, jelas, dan tidak mengganggu delivery

Batasi waktu tunggu di PR

Developer akan mengikuti proses yang cepat dan dapat diprediksi. Beberapa praktik yang membantu:

jalankan analisis berat hanya saat diperlukan,
cache dependency atau basis rule bila aman dilakukan,
jalankan job paralel per area,
beri ringkasan prioritas, bukan daftar mentah panjang.

Jika audit membutuhkan waktu lama, pertimbangkan dua tingkat hasil: quick feedback di PR dan full report sebagai artefak lanjutan.

Tampilkan rekomendasi yang bisa langsung dikerjakan

Temuan yang baik harus menjawab tiga hal:

di mana masalah ditemukan,
mengapa itu berisiko,
apa langkah perbaikannya.

Hindari ringkasan abstrak seperti “potensi masalah keamanan ditemukan” tanpa bukti atau lokasi konkret. Developer membutuhkan jalur tindakan, bukan alarm umum.

Hubungkan temuan ke owner

Bila repository bersifat monorepo atau multi-service, petakan area ke code owner. Dengan begitu, approval gate bisa menandai reviewer yang tepat, dan tanggung jawab tidak tersebar tanpa arah.

Checklist adopsi untuk tim

Tentukan tujuan gate: apakah untuk warning, merge protection, atau release blocking.
Definisikan kategori audit: code, dependency, secret, config, auth/authz.
Buat tahap scope berdasarkan file berubah dan area terdampak.
Standarkan format JSON untuk semua temuan lintas scanner.
Pisahkan severity dan confidence dalam kebijakan evaluasi.
Terapkan fingerprint dan dedup agar isu tidak berlipat saat rerun.
Sediakan summary Markdown untuk reviewer PR.
Simpan artefak audit untuk traceability dan verifikasi independen.
Definisikan status temuan termasuk confirmed, accepted_risk, dan fixed.
Tetapkan aturan blocker yang realistis untuk PR dan rilis.
Sediakan mekanisme suppress dengan alasan, approver, dan masa berlaku.
Ukur false positive dan waktu verifikasi untuk perbaikan berkelanjutan.

Kesalahan umum yang perlu dihindari

Menyamakan semua temuan sebagai blocker. Akibatnya developer mencari cara bypass.
Hanya menyimpan log terminal. Tidak ada struktur untuk integrasi dan audit trail.
Tidak ada dedup. Masalah yang sama muncul berulang dan mengganggu review.
Tidak ada verifikasi manusia. Keputusan penting diambil dari sinyal yang belum divalidasi.
Tidak ada traceability ke commit dan artefak rilis. Sulit membuktikan apa yang sebenarnya diaudit.
Output tidak ramah developer. Temuan ada, tetapi sulit diperbaiki karena tidak jelas lokasinya atau rekomendasinya.

Penutup

Audit keamanan otomatis di CI dengan temuan terverifikasi paling efektif ketika diperlakukan sebagai workflow engineering yang lengkap: ada scope yang jelas, analisis per area, output JSON dan Markdown, severity yang konsisten, dedup, approval gate, serta artefak yang dapat diverifikasi independen.

Fokus utamanya bukan menambah sebanyak mungkin scanner, melainkan membangun alur yang cepat untuk developer, dapat ditelusuri untuk reviewer, dan cukup tegas untuk keputusan rilis. Jika hasil audit mudah dipahami, bisa diverifikasi manusia, dan terhubung ke release flow, keamanan dapat meningkat tanpa mengorbankan kecepatan delivery.

Quick Search

shopping_cart Keranjang