Secrets GitHub Actions lu bisa aman, tapi workflow lu tetap bisa bocor dari tempat yang lebih “boring”: cache.
Inti artikel ini sederhana: CI/CD bukan cuma soal token dan environment variable. Cache, artifact, dan permission workflow juga bagian dari boundary security karena semuanya bisa memengaruhi apa yang dibuild, dites, atau dipakai ulang di pipeline berikutnya. Update read-only Actions cache dari GitHub jadi pengingat bagus: optimasi build yang kelihatan harmless tetap perlu prinsip least privilege, apalagi kalau workflow bisa dipicu dari kontribusi luar.
Apa itu cache CI di GitHub Actions?
Cache CI adalah mekanisme buat menyimpan data yang sering dipakai ulang di workflow, misalnya dependency package manager, build output tertentu, atau folder toolchain. Tujuannya jelas: build lebih cepat, job lebih hemat waktu, dan developer nggak perlu download dependency dari nol setiap run.
Di GitHub Actions, cache sering dipakai lewat mekanisme dependency caching. Contohnya, project Node.js bisa menyimpan cache npm, project Python bisa menyimpan cache pip, dan project lain bisa menyimpan folder build tool yang mahal kalau dibuat ulang terus.
Masalahnya, sesuatu yang dipakai ulang oleh workflow juga bisa jadi jalur pengaruh. Kalau input dari sumber yang belum dipercaya bisa menulis cache, pertanyaannya bukan lagi “build lebih cepat atau nggak?”, tapi “apa yang bisa ikut kebawa ke workflow berikutnya?”
Update GitHub: read-only cache untuk untrusted triggers
GitHub mengumumkan perubahan read-only Actions cache untuk workflow event yang bisa dipicu tanpa write permission ke repository. Secara praktis, ini mengarah ke prinsip sederhana: trigger yang belum dipercaya boleh membaca cache tertentu, tapi tidak semudah itu menulis atau memodifikasi cache yang nantinya bisa dipakai jalur lain.
Ini bukan berarti semua risiko CI langsung hilang. Tapi arahnya sehat: platform mulai mempersempit kemampuan write pada jalur yang rawan, bukan cuma mengandalkan developer buat mengingat semua kombinasi permission sendiri.
Menurut gua, ini penting karena banyak developer sudah paham aturan dasar seperti “jangan kasih secrets ke pull request dari fork”. Tapi lebih sedikit yang mikir soal cache, artifact, workflow token permission, atau event seperti pull_request_target sebagai bagian dari threat model yang sama.
Kenapa cache bisa jadi boundary security?
Boundary security adalah batas antara hal yang dipercaya dan belum dipercaya. Di CI/CD, batas ini nggak selalu kelihatan seperti login page atau API key. Kadang bentuknya lebih halus:
- Siapa yang boleh menjalankan workflow?
- Event apa yang memicu workflow?
- Token apa yang tersedia di job itu?
- Folder apa yang dipakai ulang lewat cache?
- Artifact apa yang dihasilkan dan dipakai job berikutnya?
- Permission apa yang dimiliki workflow saat membaca atau menulis sesuatu?
Cache masuk ke daftar ini karena dia menyimpan state lintas run. Kalau cache dianggap cuma akselerator, tim bisa kelewat melihat bahwa dia juga bagian dari supply chain build.
Analogi gampangnya: lu punya dapur yang bersih, bahan makanan aman, dan koki terpercaya. Tapi lu membiarkan orang asing menaruh bumbu di rak yang akan dipakai masakan besok. Walaupun orang asing itu nggak pegang kunci brankas, dia tetap bisa memengaruhi hasil akhir.
Untrusted trigger: sumber masalah yang sering diremehkan
Untrusted trigger adalah workflow trigger yang bisa datang dari pihak yang belum punya trust penuh ke repository. Contoh paling umum: pull request dari fork atau kontribusi luar di project open-source.
Kontribusi luar itu bagus. Open-source hidup dari sana. Tapi workflow yang memproses kontribusi luar harus punya batas berbeda dari workflow internal. Lu boleh mengetes patch dari contributor, tapi bukan berarti patch itu boleh mendapat kemampuan penuh untuk menulis cache, mengakses secrets, push tag, publish package, atau memodifikasi state yang dipakai release pipeline.
Di sinilah banyak insiden CI/CD bermula: bukan karena satu konfigurasi terlihat jelas jahat, tapi karena kombinasi kecil yang terlalu longgar. Event yang salah, permission default yang terlalu besar, cache yang bisa ditulis, artifact yang dipercaya, lalu job berikutnya memakai hasil itu tanpa verifikasi ulang.
Checklist praktis buat repo lu
Kalau lu punya project di GitHub Actions, terutama yang menerima pull request dari luar, gua bakal mulai dari checklist ini:
- Audit event workflow. Cek workflow yang memakai
pull_request,pull_request_target,workflow_run, dan trigger manual. Pastikan lu paham konteks trust tiap event. - Set permission secara eksplisit. Jangan bergantung ke default. Tulis
permissions:sesuai kebutuhan job. Kalau job cuma perlu baca repo, kasih read-only. - Pisahkan workflow test dan release. Workflow buat PR luar sebaiknya tidak satu jalur dengan publish package, deploy, atau release signing.
- Anggap cache sebagai state sensitif. Jangan biarkan jalur untrusted menulis cache yang akan dipakai jalur trusted tanpa batas yang jelas.
- Jangan percaya artifact mentah. Kalau artifact dari job untrusted dipakai job lain, verifikasi ulang sumber, checksum, atau proses build-nya.
- Review dependency install script. Banyak package manager menjalankan lifecycle script. Ini penting saat workflow menjalankan dependency dari branch contributor.
- Logika deploy harus punya gate manusia atau environment protection. Untuk repo penting, jangan biarkan satu event otomatis langsung deploy tanpa guardrail.
Contoh pola yang lebih aman
Pola yang lebih aman biasanya bukan “matikan semua otomatisasi”. Itu terlalu ekstrem dan bikin tim balik ke proses manual yang lambat. Pola yang lebih realistis adalah memisahkan jalur berdasarkan trust.
Misalnya:
- Pull request dari fork menjalankan test dengan permission minimal.
- Workflow tersebut boleh membaca cache yang aman, tapi tidak menulis state penting.
- Release hanya berjalan dari branch utama atau tag yang dibuat maintainer.
- Deploy butuh environment protection atau approval untuk project sensitif.
- Artifact dari PR luar tidak langsung dipromosikan jadi artifact release.
Dengan pola ini, otomatisasi tetap jalan, tapi batas trust-nya lebih jelas. Developer tetap dapat feedback cepat dari CI, sementara jalur rilis nggak ikut membuka pintu terlalu lebar.
Pelajaran lebih besarnya: supply chain security itu detail kecil
Supply chain security sering terdengar besar: malware, token bocor, package registry, compromised maintainer account. Padahal di kerja harian, permukaannya sering muncul sebagai konfigurasi kecil: permission workflow, cache key, event trigger, artifact retention, atau script install dependency.
Itu alasan gua suka update kecil seperti read-only Actions cache ini. Dia nggak se-seksi “AI security scanner” atau “zero-day baru”, tapi efeknya dekat dengan workflow developer sehari-hari. Banyak repo nggak butuh platform security yang rumit dulu. Mereka butuh default yang lebih aman dan kebiasaan review konfigurasi CI yang lebih disiplin.
Buat personal brand developer, ini juga menarik: yang membedakan engineer matang bukan cuma bisa bikin fitur jalan, tapi bisa melihat state tersembunyi yang memengaruhi reliability dan security. Cache CI adalah salah satu state tersembunyi itu.
Takeaway singkat
- Cache CI bukan cuma optimasi speed. Dia bisa memengaruhi supply chain build.
- Untrusted trigger harus punya permission lebih sempit dari jalur internal.
- Secrets aman belum cukup kalau cache, artifact, dan token workflow masih terlalu bebas.
- Least privilege di CI/CD harus berlaku ke semua state: token, cache, artifact, dan deploy path.
- Kalau repo lu menerima kontribusi luar, audit workflow GitHub Actions lu minggu ini.
FAQ singkat
Apakah cache GitHub Actions berbahaya?
Bukan otomatis berbahaya. Cache berguna buat mempercepat workflow. Risikonya muncul kalau cache bisa ditulis oleh jalur yang belum dipercaya lalu dipakai lagi oleh jalur yang lebih dipercaya tanpa batas.
Apakah cukup dengan menyembunyikan secrets dari pull request luar?
Belum cukup. Secrets memang penting, tapi CI/CD punya state lain seperti cache, artifact, workflow token, dan permission event. Semua itu perlu dicek.
Apa langkah pertama yang paling praktis?
Buka folder .github/workflows, cari workflow yang berjalan dari pull request luar, lalu cek tiga hal: event trigger, permissions, dan apakah job itu bisa menulis cache atau artifact yang dipakai jalur trusted.
