PR Nakal Bisa Mencuri Secret CI Kamu. Pisahkan Sekarang

Pull request dari kontributor baru terlihat polos: typo fix, update dependency, atau test kecil. Namun, begitu CI menjalankan script dari PR itu dengan akses token, deploy key, atau cloud credentials, repo kamu berubah jadi mesin pembocor secret.

Inilah alasan CI secret isolation for pull requests wajib kamu terapkan, terutama kalau kamu mengelola proyek open source, GitHub Actions, atau GitLab CI.

Kenapa Pull Request Bisa Jadi Jalur Pencurian Secret?

CI punya kebiasaan berbahaya: ia memperlakukan build sebagai rutinitas, padahal setiap PR dari fork adalah kode asing. Selain itu, dependency install sering menjalankan script otomatis seperti postinstall, test hook, atau build step.

Kalau job itu punya akses secret, penyerang cukup membuat PR yang membaca environment variable lalu mengirimnya ke server eksternal. Akibatnya, satu PR kecil bisa membuka akses ke:

• GitHub token atau GitLab token
• NPM, PyPI, Docker, Composer registry token
• AWS, GCP, Azure credentials
• SSH deploy key
• Webhook signing secret

GitHub sendiri memperingatkan risiko ini pada event seperti GitHub Actions security hardening. GitLab juga punya kontrol protected variables dan protected branches di CI/CD variables documentation.

Prinsip Utama: Jangan Percaya Kode Sebelum Review

Aturan paling aman sederhana: kode dari PR tidak boleh menyentuh secret. Bukan cuma file aplikasinya, tetapi juga dependency, test runner, linter plugin, generator, dan script build.

Yang sering dilupakan, dependency punya kekuatan yang sama dengan kode kamu. Karena itu, kamu perlu membaca juga panduan internal tentang dependency confusion defense dan lockfile integrity npm Composer.

Pola 2 Jalur: Untrusted CI dan Trusted CI

Framework paling praktis untuk CI secret isolation adalah membagi pipeline menjadi dua jalur.

1. Untrusted CI untuk Semua Pull Request

Jalur ini berjalan otomatis untuk PR dari fork atau branch eksternal. Namun, job ini tidak punya secret sama sekali.

• Jalankan lint, unit test, static analysis.
• Pakai permission read-only.
• Matikan publish, deploy, release, upload artifact sensitif.
• Hindari menjalankan script dependency kalau bisa.

2. Trusted CI Setelah Review atau Merge

Jalur ini baru boleh mengakses secret setelah maintainer percaya pada kodenya. Biasanya, trigger terbaik adalah push ke branch protected, tag release, atau approval manual.

• Deploy hanya dari branch protected.
• Publish package hanya dari tag yang tervalidasi.
• Gunakan environment protection dan required reviewers.
• Batasi secret sesuai kebutuhan job, bukan semua job.

Setup Aman di GitHub Actions

Di GitHub Actions, masalah sering muncul dari penggunaan pull_request_target. Event ini berjalan dalam konteks base repository, sehingga secret bisa tersedia. Kalau kamu checkout kode PR lalu menjalankannya, kamu membuka pintu besar.

Pola aman:

permissions:
  contents: read

on:
  pull_request:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci --ignore-scripts
      - run: npm test

Untuk deploy, pisahkan workflow:

on:
  push:
    branches: [main]

permissions:
  contents: read
  id-token: write

jobs:
  deploy:
    environment: production
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: ./deploy.sh

Selain itu, pakai OpenID Connect GitHub Actions untuk cloud deploy. Dengan OIDC, kamu bisa mengganti long-lived cloud key dengan token singkat berbasis identitas workflow.

Setup Aman di GitLab CI

Di GitLab CI, gunakan protected variables untuk secret penting. Lalu, pastikan secret hanya tersedia pada protected branches atau protected tags.

test_pr:
  script:
    - npm ci --ignore-scripts
    - npm test
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'

release:
  script:
    - ./release.sh
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'
  environment:
    name: production

Dengan begitu, merge request tetap mendapat feedback cepat, sedangkan secret tetap berada di jalur trusted.

Trik yang Sering Lebih Aman: Build Dua Kali

Banyak tim mencoba menghemat waktu dengan memakai artifact dari PR untuk deploy setelah approval. Kedengarannya efisien, tetapi sering keliru.

Lebih aman begini: PR hanya membuktikan kode bisa lolos test. Setelah merge ke branch protected, CI membangun ulang artifact dari commit yang sudah dipercaya. Jadi, artifact deploy berasal dari trusted pipeline, bukan dari job PR yang tidak tepercaya.

Ya, ini sedikit lebih lambat. Namun, hasilnya jauh lebih bersih secara audit, lebih mudah dijelaskan saat incident response, dan lebih kuat melawan script dependency nakal.

Checklist CI Secret Isolation

• Default token read-only untuk PR.
• Jangan expose secret ke fork pull request.
• Pisahkan test dan deploy dalam workflow berbeda.
• Gunakan protected branch/tag untuk release.
• Tambahkan manual approval untuk environment production.
• Gunakan OIDC, bukan static cloud key jangka panjang.
• Audit dependency scripts, terutama postinstall.
• Rebuild artifact setelah merge, jangan deploy artifact dari PR.

Kesalahan Umum yang Harus Kamu Hindari

Memberi Secret ke Semua Job

Secret seharusnya mengikuti kebutuhan job. Kalau job lint tidak butuh AWS key, jangan beri AWS key.

Menganggap Maintainer Approval Selalu Cukup

Approval membantu, tetapi bukan pengganti isolasi. Reviewer bisa melewatkan script kecil di dependency atau perubahan lockfile.

Menyimpan Deploy Key Tanpa Scope

Deploy key yang terlalu luas memperbesar dampak kebocoran. Karena itu, batasi akses ke repo, branch, environment, dan durasi token.

FAQ

Apa itu CI secret isolation?

CI secret isolation adalah praktik memisahkan job CI yang menjalankan kode pull request dari job yang punya akses secret seperti token, deploy key, atau cloud credentials.

Apakah pull request dari fork selalu berbahaya?

Tidak selalu. Namun, fork PR harus dianggap tidak tepercaya sampai maintainer meninjau dan menggabungkannya ke jalur protected.

Apakah GitHub Actions secret aman secara default?

GitHub membatasi secret untuk beberapa skenario fork PR. Namun, konfigurasi seperti pull_request_target, permission berlebihan, atau checkout kode PR bisa membuat secret terekspos.

Mana lebih aman, static cloud key atau OIDC?

OIDC biasanya lebih aman karena token bersifat singkat dan bisa dibatasi berdasarkan repo, branch, workflow, serta environment.

Penutup: CI yang Aman Bukan CI yang Lambat

CI secret isolation for pull requests bukan penghalang produktivitas. Justru, ia membuat kontribusi open source tetap lancar tanpa memberi kunci produksi ke kode yang belum kamu percaya.

Mulai dari langkah kecil: jadikan PR workflow read-only, pindahkan deploy ke branch protected, lalu ganti static cloud key dengan OIDC. Setelah itu, audit dependency script dan rebuild artifact setelah merge.

Kalau kamu ingin checklist keamanan CI, WordPress, dan supply chain yang lebih praktis, subscribe newsletter Google kami di bawah ini.