Hardening Kontribusi Open Source: Gate Keamanan untuk PR dan Kontribusi Berbantuan AI

Perubahan kebijakan kontribusi seperti yang dibahas Godot dalam konteks kebijakan kontribusi 2026 sebaiknya tidak berhenti sebagai dokumen tata kelola. Bagi maintainer, kebijakan tersebut perlu diterjemahkan menjadi gate keamanan yang dapat dieksekusi: aturan branch, pembatasan CI, bukti asal kode, pemeriksaan dependensi, dan jalur review untuk perubahan berisiko.

Fokusnya bukan membedakan kontribusi manusia dan AI secara absolut. Risiko utamanya adalah perubahan dari pihak yang belum tepercaya—termasuk pull request (PR) dari fork—dapat membawa secret, dependensi berbahaya, instruksi build yang tidak aman, atau kode yang asal-usul dan lisensinya tidak jelas. Kontribusi berbantuan AI menambah kebutuhan akan deklarasi provenance dan review yang lebih disiplin, bukan pengecualian dari standar keamanan.

Mulai dari threat model kontribusi

Gate yang baik dibangun dari ancaman konkret, bukan dari daftar alat. Untuk proyek open source, anggap penulis PR eksternal dapat mengendalikan seluruh isi branch mereka: source code, file workflow, skrip build, manifest dependensi, fixture pengujian, dan dokumentasi yang dapat memengaruhi reviewer.

Aset yang harus dilindungi

• Secret CI/CD: token registry, kredensial cloud, kunci penandatanganan rilis, token bot, dan variabel lingkungan sensitif.
• Integritas rilis: artefak build, tag rilis, paket yang dipublikasikan, dan workflow deploy.
• Rantai pasok: lockfile, registry package, image container, action/plugin CI, serta skrip instalasi.
• Reputasi dan kepatuhan: kode berlisensi tidak kompatibel, kode yang disalin tanpa atribusi, atau perubahan yang menyisipkan backdoor.
• Kapasitas reviewer: PR besar atau dihasilkan AI dapat tampak masuk akal tetapi menyembunyikan perubahan semantik yang sulit diperiksa.

Skenario serangan yang perlu diasumsikan

• PR dari fork menambahkan skrip test yang membaca environment CI lalu mengirimkannya ke endpoint eksternal.
• Perubahan workflow menaikkan izin token atau menjalankan checkout branch penyerang pada event yang memiliki secret.
• Dependensi baru atau pembaruan lockfile memasukkan paket typosquatting, paket kompromi, atau installer yang menjalankan kode saat instalasi.
• Kontributor menyertakan kode dari sumber yang lisensinya tidak sesuai, termasuk keluaran AI yang asal data latih atau sumbernya tidak dapat ditelusuri.
• PR mengubah generator, konfigurasi release, atau build script; diff aplikasi tampak kecil, tetapi pipeline menghasilkan artefak berbeda.

Model ini menghasilkan prinsip sederhana: kode dari fork boleh diuji, tetapi tidak boleh otomatis memperoleh kredensial, hak tulis, atau jalur menuju rilis.

Gate keamanan untuk PR dan AI-assisted contribution

1. Pisahkan validasi kode dari operasi berprivilege

Jalankan lint, unit test, dan build dasar untuk PR eksternal dengan token read-only dan tanpa secret. Operasi yang dapat menulis—memberi label melalui API, memperbarui komentar bot, menerbitkan artefak, membuat release, atau deploy—harus berjalan pada workflow terpisah setelah review, merge, atau persetujuan maintainer.

Kesalahan umum adalah memakai event berprivilege untuk memproses kode dari PR karena ingin bot tetap dapat memberi komentar. Pada platform yang mendukung event khusus untuk konteks target PR, perlakukan event tersebut sebagai berbahaya bila workflow melakukan checkout head commit PR atau mengeksekusi skrip dari PR. Kode tidak tepercaya dan token berprivilege tidak boleh bertemu dalam satu job.

# Contoh pola CI generik bergaya YAML; sesuaikan dengan penyedia CI Anda.
name: verify-pull-request
on: [pull_request]

permissions:
  contents: read

jobs:
  verify:
    runs-on: isolated-runner
    permissions:
      contents: read
    steps:
      - uses: checkout-action@<commit-yang-dipin>
        with:
          fetch-depth: 1
      - run: ./ci/verify.sh
        env:
          # Jangan meneruskan secret, token publish, atau kredensial cloud.
          CI: true

Contoh ini menunjukkan arah kontrol, bukan konfigurasi universal. Pin action/plugin ke commit tepercaya bila platform mendukungnya, batasi izin pada level workflow dan job, serta pastikan runner tidak menyuntikkan secret secara implisit untuk PR dari fork.

2. Gunakan ruleset branch sebagai kontrol wajib, bukan konvensi

Lindungi branch utama dan branch rilis dengan ruleset atau branch protection. Kebijakan minimum yang lazim adalah PR wajib, status check wajib, branch harus mutakhir sebelum merge bila sesuai alur proyek, dan larangan force push. Tambahkan persetujuan eksplisit untuk perubahan di area sensitif.

• Wajibkan check seperti test, lint, secret scan, dan dependency scan sebelum merge.
• Batasi siapa yang boleh melewati aturan atau merge langsung ke branch terlindungi.
• Larangkan perubahan workflow CI tanpa approval pemilik area.
• Untuk proyek dengan release pipeline, pisahkan branch rilis dan batasi hak tulisnya lebih ketat.

Batasan: status check hanya sekuat konfigurasi job yang menjalankannya. Check hijau tidak berguna jika workflow dapat diubah oleh PR yang sama atau jika check berprivilege menjalankan kode dari fork.

3. Terapkan CODEOWNERS untuk area berisiko

CODEOWNERS atau mekanisme ownership setara mengubah pengetahuan keamanan menjadi aturan review. Tetapkan owner untuk workflow CI, skrip build, manifest dependensi, lockfile, konfigurasi deploy, kebijakan keamanan, dan kode kriptografi atau autentikasi.

# CODEOWNERS
/.github/workflows/ @org/ci-maintainers
/ci/ @org/ci-maintainers
/package-lock.json @org/dependency-maintainers
/pyproject.toml @org/dependency-maintainers
/deploy/ @org/release-maintainers
/security/ @org/security-maintainers

Jangan menjadikan satu akun sebagai owner tunggal untuk semua area. Gunakan tim yang aktif, dokumentasikan penggantinya, dan audit aturan ini ketika struktur repositori berubah.

Batasan: CODEOWNERS mengarahkan atau mewajibkan review, tetapi tidak membuktikan bahwa reviewer memeriksa perubahan dengan benar. Aturan ini juga dapat gagal cakup jika pola path tidak mencakup file baru atau nama file yang berubah.

4. Minta deklarasi asal kode dan penggunaan AI

Template PR membuat informasi yang dibutuhkan reviewer tersedia sejak awal. Deklarasi bukan mekanisme pendeteksi plagiarisme; fungsinya adalah menegaskan tanggung jawab kontributor, mengungkap bagian yang perlu ditelusuri, dan menyediakan dasar untuk eskalasi.

## Asal perubahan
- [ ] Saya memiliki hak untuk mengirimkan perubahan ini di bawah lisensi proyek.
- [ ] Saya menyebutkan sumber kode, spesifikasi, atau adaptasi eksternal yang material.

## Bantuan AI
- [ ] Tidak menggunakan alat AI generatif untuk kode atau dokumentasi dalam PR ini.
- [ ] Menggunakan alat AI generatif dan telah meninjau, menguji, serta bertanggung jawab atas seluruh outputnya.
- [ ] Bagian yang dibantu AI: <file/fungsi atau "tidak ada">
- [ ] Prompt, output, atau sumber eksternal yang perlu diperiksa: <tautan/ringkasan bila relevan>

## Keamanan dan pengujian
- [ ] Tidak menambahkan secret, kredensial, atau token ke repository.
- [ ] Dependensi baru/perubahan lockfile dijelaskan di bawah.
- [ ] Saya menjalankan: <perintah test/lint>

Jangan mensyaratkan pengungkapan prompt mentah secara otomatis jika prompt dapat berisi data pribadi, rahasia perusahaan, atau informasi keamanan sensitif. Mintalah ringkasan yang cukup untuk review, dan sediakan jalur privat untuk pengungkapan sensitif.

Batasan: deklarasi bergantung pada kejujuran kontributor. Ia harus dipadukan dengan review, pemindaian, dan kebijakan lisensi; jangan menganggap checkbox sebagai bukti teknis.

Kontrol otomatis untuk secret, dependensi, dan build

Secret scanning dan pencegahan kebocoran

Aktifkan secret scanning pada repository dan lakukan scan pada PR. Jika platform mendukung push protection, gunakan untuk mencegah pola kredensial yang dikenal masuk ke branch. Tambahkan scanner berbasis aturan pada CI untuk mendeteksi token generik, private key, file konfigurasi lokal, dan credential yang tidak dikenali oleh scanner platform.

Ketika scanner menemukan secret, jangan hanya meminta kontributor menghapus barisnya. Perlakukan nilai itu sebagai telah bocor: cabut atau rotasi kredensial, bersihkan riwayat bila kebijakan dan risiko mengharuskannya, lalu verifikasi log CI dan artefak tidak menyimpan nilai yang sama.

Batasan: scanner menghasilkan false positive dan tidak mengenali semua secret, khususnya token kustom atau nilai yang dipecah/di-encode. Ia tidak menggantikan desain yang mencegah secret tersedia dalam job PR.

Dependency scanning dan review perubahan supply chain

Jalankan pemindaian kerentanan terhadap manifest dan lockfile, lalu wajibkan penjelasan untuk setiap dependensi baru. Untuk perubahan sensitif, reviewer perlu memeriksa: apakah paket benar-benar diperlukan, apakah namespace dan penerbitnya benar, apakah versi dipin atau dikunci, apakah ada skrip instalasi, dan apakah paket membawa dependensi transitif yang besar.

• Gunakan lockfile bila ekosistem proyek mendukungnya dan review diff lockfile sebagai perubahan kode.
• Batasi registry package ke sumber tepercaya untuk build CI, bila tooling mendukungnya.
• Pin action, plugin, atau image build ke identitas yang dapat diaudit; jangan memakai tag mengambang untuk langkah rilis.
• Jangan otomatis merge pembaruan dependensi hanya karena bot menyatakan update tersedia.

Batasan: database kerentanan biasanya terlambat terhadap kompromi baru dan tidak mendeteksi paket berbahaya yang belum memiliki advisory. Pemindaian juga tidak memutuskan kompatibilitas lisensi atau kebutuhan arsitektural sebuah dependensi.

Build terisolasi dan artefak yang tidak dipercaya

PR dari fork harus dibangun pada lingkungan sementara: workspace baru, filesystem yang dapat dibuang, kredensial minimal, dan akses jaringan yang dibatasi sejauh kebutuhan build memungkinkan. Jangan gunakan runner self-hosted yang memiliki akses internal, cache bersama sensitif, socket container host, atau kredensial deploy untuk menjalankan kode PR eksternal.

Jika build perlu mengunduh dependensi, pertimbangkan egress allowlist, proxy registry, atau cache yang hanya dapat dibaca. Perlakukan artefak dari PR sebagai untrusted: jangan otomatis menandatangani, menerbitkan, atau menjalankannya pada lingkungan produksi. Job rilis harus membangun ulang dari commit yang sudah merged dan terlindungi, bukan mempromosikan artefak yang dibuat fork.

Batasan: isolasi runner meningkatkan biaya dan dapat menyulitkan test integrasi. Pembatasan jaringan juga dapat mematahkan build yang bergantung pada layanan eksternal; dokumentasikan pengecualian dan audit secara berkala.

Checklist PR yang dapat diterapkan reviewer

Gunakan checklist berbeda untuk semua PR dan untuk PR berisiko. Tujuannya bukan menambah birokrasi pada typo dokumentasi, melainkan membuat perubahan terhadap batas kepercayaan terlihat.

Checklist umum

• Tujuan perubahan dan perilaku yang berubah dapat dijelaskan dengan jelas.
• Test relevan ditambahkan atau alasan tidak menambah test dicantumkan.
• Diff tidak menyertakan secret, file lokal, artefak build, atau perubahan yang tidak terkait.
• Deklarasi asal kode, lisensi, dan bantuan AI telah diisi bila relevan.
• Check wajib berjalan pada commit terbaru dan hasilnya ditinjau, bukan sekadar hijau.

Checklist perubahan berisiko

• Apakah PR mengubah workflow CI, skrip build, deploy, permission, atau konfigurasi runner?
• Apakah PR menambah atau mengubah dependensi, lockfile, registry, image, action, atau plugin?
• Apakah ada akses jaringan baru, parsing input tidak tepercaya, deserialisasi, kriptografi, autentikasi, atau perubahan otorisasi?
• Apakah perubahan menghasilkan, memproses, atau berpotensi mencetak data sensitif ke log?
• Apakah CODEOWNERS yang tepat sudah menyetujui dan threat model perlu diperbarui?

Matriks keputusan review dan jalur eskalasi

Jalur eskalasi harus tertulis di kebijakan keamanan repository: siapa yang menilai, kanal privat yang digunakan, kondisi kapan PR dikunci, dan bagaimana keputusan dicatat. Jangan meminta reporter mempublikasikan exploit proof-of-concept di issue publik sebelum tim menilai dampaknya.

Urutan implementasi yang realistis

1. Audit CI sekarang: identifikasi job yang menerima secret, token write, runner self-hosted, atau akses deploy; pastikan job tersebut tidak menjalankan kode dari fork.
2. Aktifkan baseline branch protection: PR wajib, check wajib, pembatasan bypass, dan approval untuk path sensitif melalui CODEOWNERS.
3. Tambahkan template PR: deklarasi asal kode, AI-assisted contribution, dependensi, dan test.
4. Tambahkan scanning: secret scan dan dependency scan sebagai check terpisah dengan aturan penanganan temuan yang jelas.
5. Isolasi build PR: gunakan runner ephemeral atau lingkungan sandbox; pindahkan publish dan deploy ke pipeline pasca-merge.
6. Latih reviewer dan ukur pengecualian: tinjau PR yang dibypass, false positive scanner, serta perubahan kebijakan tiap beberapa bulan.

Prinsip operasional: jangan gunakan satu gate sebagai bukti keamanan. Ruleset mencegah bypass prosedural, CODEOWNERS membawa keahlian yang tepat, scanner menangkap pola tertentu, isolasi membatasi dampak, dan review manusia menilai konteks. Lapisan-lapisan ini saling menutup keterbatasan, bukan saling menggantikan.

Dengan pendekatan ini, kebijakan kontribusi—termasuk kewajiban tanggung jawab atas output AI—menjadi kontrol yang konsisten dan dapat diaudit. Kontributor tetap dapat mengirim patch dengan hambatan yang proporsional, sementara repository tidak memberikan kepercayaan lebih besar daripada yang diperlukan sebelum perubahan ditinjau dan di-merge.