Kontrol Keamanan CI/CD yang Perlu Diminta Buyer

Keamanan CI/CD adalah kerja menjaga integritas dari source sampai artifact. Mulai review dengan satu pertanyaan: apakah orang, workflow, runner, dependency, atau secret yang tidak disetujui dapat mengubah isi rilis? Pipeline yang berhasil build bukan bukti bahwa input rilis terlindungi. SLSA menjelaskan provenance sebagai informasi yang dapat diverifikasi mengenai dari mana, kapan, dan bagaimana artifact dibuat; konsumen tetap perlu kebijakan untuk menentukan bukti yang diterima. NIST SSDF menempatkan pengembangan perangkat lunak aman sebagai praktik dalam proses pengembangan, bukan pemindaian sekali jalan.

Panduan ini menghasilkan artefak review yang lengkap. Panduan ini bukan sertifikasi pipeline, bukan bukti perangkat lunak aman, dan bukan janji hasil rilis. Scope perlu menyebut repository, penyedia CI, runner, registry artifact, jalur deploy, serta identitas yang diperiksa.

Petakan jalur rilis lebih dulu

Gambar satu jalur dari merge ke production: branch terlindungi, file workflow, runner, input build, registry artifact, titik persetujuan, identitas deploy, dan target. Tandai siapa yang dapat mengedit atau memanggil setiap tahap. Masukkan reusable workflow, action marketplace, package registry, build cache, dan script yang diambil saat runtime. Semua itu adalah input eksekusi, bukan detail latar belakang.

Contoh alur:

commit main terlindungi
  | workflow yang direview pada commit tersebut
  | runner build terisolasi dengan identitas OIDC
  | digest artifact dan attestation provenance
  | kebijakan memverifikasi signer, builder, commit sumber, digest
  | job deploy menerima credential khusus environment
  | production menerima digest immutable

Lindungi workflow sebagai kode berprivilege

Definisi workflow menentukan perintah yang berjalan dan credential yang masuk. Perlakukan perubahan .github/workflows, konfigurasi CI, manifest deploy, library pipeline bersama, dan pengaturan permission sebagai perubahan berprivilege. Wajibkan review melalui branch protection. Batasi pihak yang dapat mengubah proteksi environment, pengaturan repository, grup runner, dan aturan trust identity provider. Review harus menguji batas ini, bukan hanya membaca pengaturan.

Uji perubahan workflow tanpa persetujuan, deploy production dari pull request, secret environment dari branch tidak tepercaya, action yang diubah, dan approval lama. Catat deny yang diharapkan dengan nilai sintetis pada target non-production.

Pisahkan build, test, publish, dan deploy. Job pull request hanya mendapat akses baca repository tanpa secret production. Job rilis boleh publish setelah cek kebijakan; identitas deploy terpisah dari build.

Review identitas dan isolasi runner

Identitas runner menjawab workload apa yang bertindak, untuk siapa, dan berapa lama. Utamakan token workload atau federation yang diterbitkan untuk job dan audience tertentu daripada cloud key jangka panjang dalam CI. Ikat aturan trust pada repository, branch atau tag, workflow, environment, dan audience yang dimaksud jika didukung. Periksa claim token serta kondisi role cloud, lalu uji token dari repository, branch, workflow, atau audience lain. Semuanya harus gagal.

Self-hosted runner memerlukan bukti tambahan. Ambil inventaris runner, ownership, penempatan jaringan, patch level, sumber image, izin registrasi, perilaku workspace persisten, dan repository yang dapat memilih label runner. Runner bersama yang persisten dapat menyisakan source, credential, cache, atau artifact antar-job. Utamakan runner ephemeral terisolasi untuk pekerjaan tidak tepercaya atau lintas repository. Jika persistence tetap dipakai, dokumentasikan verifikasi pembersihan dan risiko sisa.

Simpan secret di balik batas job

Secret adalah capability, bukan teks konfigurasi. Inventaris setiap secret: tujuan, penerbit, owner, konsumen, environment, jalur rotasi, masa berlaku, dan cara pencabutan. Job hanya menerima secret yang dibutuhkan tahapnya dan hanya dalam konteks yang disetujui. Jangan pernah memberikan credential production pada pull request dari fork, kode belum direview, log, artifact, cache, atau debug shell.

Contoh konfigurasi:

permissions:
  contents: read
  id-token: write
jobs:
  deploy:
    if: github.ref == 'refs/heads/main'
    environment: production

Ini titik awal, bukan kontrol lengkap. Review aturan approval environment, kondisi trust OIDC, umur token, masking log, shell tracing, aturan upload artifact, dan apakah proses anak mewarisi credential. Uji bahwa job build tidak dapat memakai role deploy dan job deploy tidak dapat membaca secret yang tidak terkait.

Verifikasi provenance sebelum promotion

Provenance perlu menghubungkan digest artifact dengan source, dependency, proses build, dan builder yang diharapkan. Provenance SLSA memuat definisi build dan detail eksekusi seperti identitas builder serta metadata invocation. Verifikasi harus memeriksa pasangan signer-builder yang diterima, repository sumber, revision immutable, workflow atau build type, digest artifact, dan dependency yang diwajibkan. Menyimpan attestation tanpa mengeceknya bukan kontrol promotion.

Contoh keputusan promotion: izinkan sha256:... hanya bila signer dan builder attestation sesuai kebijakan, commit sumber yang terurai sama dengan commit rilis, workflow disetujui, dan digest subject sama dengan digest registry. Tolak builder tidak dikenal, source tak diharapkan, attestation hilang, atau digest tidak cocok. Simpan keluaran verifier dan referensi attestation pada catatan rilis.

Artefak review lengkap

Batas rilis	Bukti tersimpan	Peran akuntabel	Keputusan	Tindakan korektif
Perlindungan workflow	ekspor aturan branch, riwayat review, uji deny	owner engineering	Pass/Fail	file, celah approval, tanggal target
Identitas runner	claim token, kebijakan trust, uji deny lintas konteks	owner platform	Pass/Fail	kurangi scope runner
Batas secret	inventaris secret, permission job, review log	owner secret	Pass/Fail	cabut, rotasi, pisahkan role
Gate provenance	attestation, keluaran verifier, kecocokan digest	owner rilis	Pass/Fail	blokir promotion, tambah verifier
Pemisahan deploy	aturan environment, kebijakan role, uji build-ke-prod ditolak	owner deploy	Pass/Fail	pisahkan identitas

Simpan revisi konfigurasi, URL job atau run ID, ekspor kebijakan, waktu uji, dan keluaran tersamarkan. Pass berlaku untuk scope yang diuji; fail memerlukan dampak, owner, tanggal target, dan retest. Pengecualian memerlukan approver, tanggal berakhir, kontrol kompensasi, dan perbaikan.

Yang perlu diminta buyer

Minta diagram jalur rilis, aturan review perubahan workflow, inventaris runner, kebijakan trust identitas, inventaris secret, contoh provenance, keluaran verifier, dan register pengecualian. Tanyakan event mana yang dicatat dan bagaimana rilis direkonstruksi dari commit source sampai digest yang dideploy. Bukti perlu menunjukkan batas tanpa membocorkan credential atau data target internal.

Review yang baik berakhir pada catatan keputusan: scope, artefak yang diperiksa, uji yang dilakukan, kontrol pass/fail, pengecualian, owner perbaikan, dan pemicu retest. Catatan ini membuat keamanan pipeline dapat diulang saat workflow, armada runner, atau rancangan deploy berubah.

Buat bukti rilis dapat direproduksi

Record rilis memerlukan referensi immutable, bukan screenshot job hijau. Simpan commit SHA, workflow file SHA, digest image runner, digest artifact, URI attestation, perintah verifier, dan revisi kebijakan. Jalankan ulang verifikasi dari artifact tersimpan lalu bandingkan digest hasil dengan inventaris deployment. Jika runner, action, atau kebijakan berubah setelah rilis, pertahankan revisi lama agar reviewer dapat merekonstruksi keputusan tanpa mengasumsikan konfigurasi saat ini sudah ada saat itu.