CI/CD sering dianggap cuma mesin otomatisasi: push kode, jalanin test, deploy. Padahal kalau workflow punya akses ke secrets, token, package registry, dan production deploy, dia bukan sekadar automation. Dia adalah security boundary.
Artikel ini membahas update terbaru GitHub Actions yang mulai menahan workflow publik tertentu yang terlihat berisiko sebelum workflow itu berjalan. Intinya: supply chain attack sekarang nggak cuma masuk lewat package dependency, tapi juga bisa masuk lewat file workflow yang kelihatan seperti YAML biasa. Buat developer, maintainer, dan solo builder, pelajarannya jelas: automation harus direview seperti kode production, terutama kalau dia bisa menyentuh secrets.
Apa yang berubah di GitHub Actions?
Pada 28 Juli 2026, GitHub mengumumkan bahwa GitHub Actions bisa menahan workflow run tertentu yang diidentifikasi berpotensi malicious sebelum run itu dimulai. Workflow yang ditahan perlu direview dan disetujui collaborator dengan write access lewat web session yang sudah terautentikasi.
Scope-nya juga perlu dibaca dengan waras. Ini proteksi otomatis untuk public repositories di github.com, bukan janji bahwa semua supply chain attack pasti berhenti. GitHub Enterprise Server belum termasuk dalam pengumuman itu. Jadi jangan baca ini sebagai “GitHub sudah menyelesaikan CI security”. Baca sebagai sinyal: platform besar mulai menganggap workflow execution sebagai titik risiko utama.
Di hari yang sama, GitHub juga mengumumkan Dependabot alerts untuk malicious packages di lebih banyak ekosistem lewat ingestion advisory dari OpenSSF malicious-packages repository. Artinya radar supply chain makin bergerak dari “dependency ini punya CVE” ke “package ini mungkin memang dibuat untuk menyerang”.
Kenapa file workflow bisa jadi attack surface?
Attack surface adalah bagian dari sistem yang bisa dipakai penyerang untuk masuk, menjalankan aksi, atau mencuri sesuatu. Dalam konteks GitHub Actions, file workflow seperti .github/workflows/build.yml bisa menentukan command apa yang dijalankan, dependency apa yang diambil, secrets apa yang tersedia, dan kapan deploy boleh terjadi.
Masalahnya, banyak tim memperlakukan YAML CI seperti konfigurasi ringan. “Cuma ubah pipeline sedikit.” Padahal satu baris command di workflow bisa punya efek besar kalau runner punya token dan secrets. Misalnya workflow yang terlihat harmless bisa:
- mengirim environment variable ke domain luar,
- mengambil script remote dan menjalankannya,
- memodifikasi release artifact sebelum publish,
- memakai token package registry untuk publish versi berbahaya,
- atau membuka akses deploy yang seharusnya hanya dipakai workflow tertentu.
GitHub sendiri menjelaskan attack path terbaru yang melibatkan credential compromised untuk mendorong workflow GitHub Actions berbahaya. Ini menarik karena arah serangannya bukan cuma “install package jahat”, tapi “buat automation lu menjalankan sesuatu yang mencuri credential lain”. Begitu credential CI/CD bocor, efeknya bisa menyebar: package registry, cloud account, deploy key, sampai repository lain.
Supply chain attack sekarang bukan cuma dependency
Selama ini banyak developer mengenal supply chain security dari sisi package: npm, PyPI, RubyGems, Docker image, atau library yang tiba-tiba kena compromise. Itu tetap penting. Tapi workflow CI/CD adalah jalur kedua yang sering lebih powerful, karena dia punya kemampuan eksekusi.
Dependency berbahaya biasanya perlu masuk ke dependency graph. Workflow berbahaya bisa langsung jalan kalau trigger-nya longgar dan approval-nya lemah. Makanya file YAML bukan cuma “config”. Dia adalah program kecil yang menentukan apa yang runner lakukan.
Menurut gua, ini mirip pola yang sering kejadian di project personal juga. Awalnya lu bikin workflow sederhana: lint, test, build. Lalu pelan-pelan nambah publish package, deploy ke VPS, upload artifact, invalidasi cache, update release note, dan sebagainya. Tanpa sadar, file yang dulu cuma bantu hemat waktu sekarang sudah memegang kunci produksi.
Checklist praktis sebelum kasih secrets ke CI
Kalau lu maintain repo publik atau private, jangan nunggu kejadian dulu baru audit workflow. Ini checklist ringan yang bisa lu pakai minggu ini:
- Review semua workflow yang punya akses secrets. Pisahkan workflow test biasa dari workflow publish/deploy.
- Batasi permission token default. Jangan biarkan
GITHUB_TOKENpunya akses luas kalau task-nya cuma baca kode dan jalanin test. - Hati-hati dengan trigger dari pull request luar. PR dari fork adalah input dari internet, bukan kode yang otomatis bisa dipercaya.
- Jangan pipe script remote ke shell. Kalau workflow menjalankan script dari internet, pin sumber, cek checksum bila perlu, dan pahami apa yang dijalankan.
- Gunakan environment protection untuk deploy. Deploy production sebaiknya punya approval, branch rule, atau gate yang jelas.
- Pin dependency action. Pakai commit SHA untuk action sensitif, bukan cuma tag yang bisa berubah.
- Audit outbound network kalau workflow sensitif. Credential exfiltration sering terlihat dari koneksi ke domain yang tidak biasa.
- Anggap perubahan workflow sebagai perubahan production. Review file
.github/workflows/*lebih ketat daripada perubahan README.
Versi ringan buat solo developer
Kalau lu solo builder, mungkin rasanya enterprise security terlalu berat. Tapi prinsipnya tetap bisa dipakai tanpa birokrasi. Gua biasanya mikir begini: semakin dekat workflow ke secrets dan deploy, semakin kecil ruang otomatisnya.
Untuk repo personal, lu bisa mulai dari tiga guardrail sederhana. Pertama, workflow dari PR luar cukup jalanin test tanpa secrets. Kedua, publish package atau deploy production hanya dari branch utama yang protected. Ketiga, perubahan file workflow jangan asal merge walaupun PR lain terlihat aman.
Ini bukan paranoia. Ini cara murah untuk menghindari kejadian mahal. Security yang bagus bukan selalu tool paling mahal, tapi friction kecil di titik yang tepat.
Kenapa ini relevan di era AI coding agent?
Update GitHub Actions ini juga nyambung ke tren AI coding agent. Makin banyak automation masuk ke repo, makin banyak keputusan yang pindah dari manusia ke sistem. Agent bisa bikin PR, workflow bisa jalan otomatis, Dependabot bisa buka update, dan platform bisa memblokir run yang mencurigakan.
Masalahnya, prompt bukan permission system. Kalau agent atau automation bisa mengubah workflow yang punya secrets, lu tetap butuh boundary teknis: review diff, branch protection, environment approval, audit log, dan least privilege.
AI bisa mempercepat output kode, tapi CI/CD menentukan apakah output itu boleh masuk ke jalur produksi. Jadi kalau workflow lu terlalu bebas, AI bukan bikin sistem lebih aman. Dia cuma mempercepat jalan menuju masalah yang sama.
Takeaway buat developer
- CI/CD bukan cuma automation; dia execution environment high-trust.
- File workflow bisa jadi payload supply chain attack, bukan cuma konfigurasi polos.
- Secrets di CI harus dianggap saldo berjalan: kalau bocor, efeknya bisa menyebar.
- Proteksi platform seperti workflow hold dan Dependabot malware alerts membantu, tapi bukan pengganti review manusia.
- Least privilege, approval, branch protection, dan review workflow changes tetap wajib.
FAQ singkat
Apakah GitHub sekarang otomatis memblokir semua workflow berbahaya?
Tidak. Pengumuman GitHub menyebut workflow tertentu yang diidentifikasi berpotensi malicious bisa ditahan untuk approval. Ini guardrail tambahan, bukan jaminan semua serangan supply chain berhenti.
Apakah repo private aman dari risiko ini?
Repo private tetap bisa punya risiko CI/CD kalau secrets terlalu luas, dependency tidak dipin, atau workflow bisa diubah tanpa review. Bedanya, scope proteksi GitHub Actions yang diumumkan kali ini secara eksplisit menyebut public repositories di github.com.
Apa langkah pertama yang paling gampang?
Cek folder .github/workflows/, cari workflow yang punya akses secrets atau deploy, lalu pastikan permission-nya minimal dan trigger-nya tidak terlalu longgar. Itu langkah kecil yang sering langsung membuka banyak temuan.
Penutup
Gua suka automation karena dia bikin kerja developer lebih rapi. Tapi automation yang memegang secrets harus punya rem. Kalau workflow bisa deploy, publish package, atau mengakses token sensitif, dia perlu direview seperti kode production.
Jadi pelajaran dari update GitHub ini bukan “takut pakai CI”. Justru sebaliknya: pakai CI dengan lebih dewasa. Bikin otomatisasi yang jelas, terbatas, bisa diaudit, dan punya approval di titik berisiko. Itu jauh lebih berguna daripada baru panik setelah credential bocor.
