Build Hijau Bisa Bohong Kalau Toolchain Bergerak Diam-Diam

Build yang lolos CI belum tentu build yang bisa dipercaya. Kalau runner hari ini memakai Node, Composer, Docker image, compiler, atau package manager yang beda tipis dari kemarin, artifact-mu bisa berubah tanpa satu commit pun berubah.

Untuk release engineers, vendor plugin/theme, dan CI architects, masalah ini bukan sekadar “build gagal di mesin saya”. Ini soal reproducible builds, pinned toolchains, auditability, dan kemampuan membuktikan bahwa artifact yang kamu kirim memang berasal dari source yang sama.

Kenapa Build Reproducibility Jadi Kontrol Keamanan, Bukan Cuma DevOps Hygiene

Banyak tim memperlakukan reproducibility sebagai urusan kenyamanan developer. Padahal, bagi pipeline modern, build yang bisa diulang adalah bukti keamanan.

Kalau artifact production tidak bisa dibuat ulang secara identik, kamu sulit menjawab pertanyaan penting:

• Apakah artifact ini benar berasal dari commit yang diklaim?
• Apakah runner memakai toolchain yang sama?
• Apakah ada dependency atau plugin build yang berubah?
• Apakah artifact sempat dimodifikasi setelah build?

Selain itu, verifikasi jadi makin penting saat kamu menjual plugin WordPress, theme premium, library npm, package Composer, atau binary internal. Buyer enterprise biasanya nggak cuma minta changelog. Mereka mulai minta SBOM, provenance, signature, dan bukti bahwa proses release bisa diaudit.

Pinned Toolchains: Kunci Versi, Bukan Sekadar Dependency

Lockfile penting, tetapi lockfile hanya mengunci dependency. Sementara itu, artifact final juga dipengaruhi oleh tool yang menjalankan build.

Karena itu, pinned toolchains harus mencakup beberapa lapisan:

• Runtime: Node.js, PHP, Python, Ruby, Java, Go, Rust.
• Package manager: npm, pnpm, Yarn, Composer, Poetry, pip, Cargo.
• Compiler dan build backend: gcc, clang, rustc, esbuild, webpack, Vite.
• Container image: gunakan digest, bukan cuma tag seperti latest.
• CI action/plugin: pin ke SHA commit, bukan versi floating.
• OS package: apt/apk package juga perlu snapshot atau image immutable.

Contoh yang sering terlihat aman tetapi sebenarnya rapuh:

uses: actions/setup-node@v4
node-version: 20

Lebih kuat:

uses: actions/setup-node@8f152de45cc393bb48ce5d89d36b731f54556e65
node-version-file: .node-version
cache: npm

Untuk container, hindari ini:

image: node:20

Lebih audit-friendly:

image: node:20.11.1-bookworm@sha256:...

Framework Praktis: Source, Toolchain, Environment, Artifact

Kalau kamu ingin membangun sistem verifiable build yang rapi, pakai model STEA: Source, Toolchain, Environment, Artifact. Framework ini membantu tim melihat semua input yang bisa mengubah output.

1. Source: Commit Harus Bersih dan Terikat

Source bukan cuma repo utama. Submodule, generated file, vendored library, patch file, dan lockfile juga masuk scope.

• Require signed commits atau protected branches untuk release.
• Pastikan lockfile ikut review, bukan dianggap noise.
• Blokir release dari working tree yang dirty.
• Hubungkan artifact ke commit SHA, bukan branch name.

Kalau kamu belum mengunci lockfile secara disiplin, baca juga kenapa lockfile bisa “bohong” saat CI masih pakai install biasa.

2. Toolchain: Pin Semua Alat yang Bisa Mengubah Output

Toolchain drift sering lebih licin daripada dependency drift. Update minor compiler bisa mengubah output. Update npm bisa mengubah struktur node_modules. Update bundler bisa mengubah urutan chunk.

Karena itu, simpan versi toolchain di repo:

• .node-version atau .tool-versions
• packageManager di package.json
• composer.lock plus versi Composer eksplisit
• rust-toolchain.toml
• go.mod dengan versi Go
• Dockerfile dengan base image digest

3. Environment: Kurangi Variabel yang Diam-Diam Mengubah Build

Build bisa beda karena timezone, locale, hostname, absolute path, timestamp, UID, urutan file, atau env var. Jadi, reproducibility bukan cuma pin versi.

Set nilai eksplisit di CI:

export TZ=UTC
export LANG=C.UTF-8
export LC_ALL=C.UTF-8
export SOURCE_DATE_EPOCH=$(git log -1 --pretty=%ct)

SOURCE_DATE_EPOCH sangat berguna karena banyak tool build modern mendukung timestamp deterministik. Referensinya bisa kamu cek di Reproducible Builds documentation.

4. Artifact: Verifikasi, Tanda Tangani, Lalu Simpan Evidence

Artifact yang baik punya jejak. Minimal, kamu menyimpan checksum, SBOM, provenance, dan signature.

• Generate checksum untuk zip, tarball, container image, atau package.
• Sign artifact dengan Sigstore, Cosign, GPG, atau mekanisme registry bawaan.
• Attach SBOM CycloneDX atau SPDX.
• Simpan provenance yang mengikat commit, workflow, runner, dan builder identity.

Untuk konsep provenance yang lebih formal, rujuk SLSA dan Sigstore documentation. Kalau pipeline-mu sudah punya artifact signing, hubungkan dengan strategi SBOM WordPress untuk plugin dan theme.

Hal yang Sering Salah: Build Terlalu Bersih Malah Sulit Diaudit

Banyak tim mencoba membuat runner selalu “fresh” dan ephemeral. Itu bagus untuk mengurangi persistence attacker. Namun, kalau fresh runner selalu menarik versi tool terbaru, kamu mendapat lingkungan bersih yang tetap tidak deterministik.

Jadi, targetnya bukan sekadar runner bersih. Targetnya adalah runner bersih dengan input yang terkunci.

Prinsipnya begini:

• Ephemeral runner → mengurangi jejak attacker.
• Pinned image digest → mengurangi version drift.
• Hermetic build → mengurangi network surprise.
• Rebuild verification → membuktikan artifact bisa dibuat ulang.

Gabungan empat hal itu jauh lebih kuat daripada “CI hijau”. Apalagi kalau pipeline-mu menjalankan dependency install yang berpotensi mengeksekusi script. Untuk jalur itu, cek juga risiko RCE sebelum test pertama berjalan.

Checklist Pinned Toolchains untuk CI/CD

Mulai dari checklist ini. Jangan tunggu sampai semua sempurna, karena 80% risiko biasanya turun begitu versi utama berhenti bergerak diam-diam.

Untuk GitHub Actions atau GitLab CI

• Pin action ke commit SHA.
• Pin container image ke digest.
• Gunakan npm ci, pnpm install --frozen-lockfile, atau composer install --no-dev --prefer-dist sesuai kebutuhan.
• Matikan network setelah dependency restore jika build bisa dibuat hermetic.
• Simpan build logs, checksum, SBOM, provenance, dan signature.

Untuk Vendor Plugin dan Theme WordPress

• Pin versi PHP, Composer, Node, npm/pnpm, dan bundler.
• Jangan build asset production di laptop maintainer.
• Generate zip release hanya dari CI yang terkontrol.
• Pastikan file zip bisa dibuat ulang dari tag release.
• Publikasikan checksum agar customer bisa memverifikasi download.

Untuk CI Architects

• Buat golden builder image, lalu rilis image dengan digest.
• Gunakan policy untuk melarang latest di workflow release.
• Audit semua third-party action dan plugin CI.
• Pisahkan job build tidak tepercaya dari job signing atau publishing.
• Rebuild artifact secara berkala untuk mendeteksi drift.

Contoh Policy Sederhana yang Bisa Kamu Terapkan Minggu Ini

Mulai dengan policy kecil tetapi tegas:

Release artifact hanya boleh dipublish jika:
1. Source berasal dari protected tag.
2. Lockfile tidak berubah di luar PR review.
3. Runtime, package manager, container image, dan CI action dipin.
4. Build menghasilkan checksum dan SBOM.
5. Artifact ditandatangani sebelum upload.
6. Rebuild dari tag yang sama menghasilkan checksum identik atau perbedaan terdokumentasi.

Policy seperti ini terdengar sederhana. Namun, efeknya besar, karena attacker harus melewati lebih banyak lapisan: source control, dependency, runner, signing, dan verification.

FAQ

Apa itu reproducible builds?

Reproducible builds adalah praktik membuat artifact yang sama dari source, dependency, toolchain, dan environment yang sama. Tujuannya agar release bisa diverifikasi, bukan hanya dipercaya.

Apa bedanya lockfile dan pinned toolchains?

Lockfile mengunci dependency. Pinned toolchains mengunci alat yang menjalankan build, seperti Node, PHP, Composer, compiler, Docker image, dan CI action.

Apakah semua build harus 100% bit-for-bit identical?

Idealnya iya, terutama untuk binary, package, dan artifact release penting. Namun, kalau belum bisa, mulai dari documented reproducibility: checksum, metadata build, SBOM, provenance, dan daftar input yang terkunci.

Kenapa pin ke SHA lebih aman daripada pin ke versi?

Versi atau tag bisa berubah, tergantung platform dan maintainer. SHA commit atau digest container lebih immutable, sehingga lebih cocok untuk pipeline release yang perlu audit kuat.

Kesimpulan: CI Hijau Bukan Bukti, Rebuild yang Cocok Baru Bukti

Build reproducibility dan pinned toolchains mengubah release dari “semoga benar” menjadi “bisa dibuktikan”. Kamu mengurangi runner drift, tool version drift, dependency surprise, dan peluang artifact dimodifikasi tanpa jejak.

Kalau kamu mengelola plugin, theme, package, atau pipeline enterprise, mulai dari satu target: release artifact harus bisa dibuat ulang dari tag yang sama dengan toolchain yang sama. Setelah itu, tambahkan SBOM, signing, provenance, dan policy publishing.

Mau checklist supply chain security yang lebih praktis langsung ke inbox? Langganan newsletter Google kami di bawah ini.