Pembajakan Tag GitHub Actions dan Cara Mengamankan Pipeline CI/CD

Keamanan GitHub Actions kembali jadi sorotan setelah pada 19 Maret 2026 penyerang memindahkan 76 dari 77 tag versi trivy-action ke commit berbahaya. Workflow yang memakai tag, bukan commit SHA, otomatis menjalankan kode tersebut dan kehilangan rahasia CI tanpa gejala yang jelas. Artikel ini menjelaskan bagaimana pembajakan tag terjadi dan langkah praktis mengamankan pipeline Anda.

Mengapa Tag GitHub Actions Bisa Dibajak

Saat sebuah workflow menulis uses: pemilik/action@v1, bagian v1 adalah tag Git, yaitu penunjuk yang dapat dipindahkan. Siapa pun yang punya hak tulis ke repositori action itu dapat menggeser tag lama ke commit lain. Pengguna action tidak diberi tahu: pada eksekusi berikutnya, workflow mereka menjalankan kode yang baru. Commit SHA lengkap bersifat tetap karena ia adalah sidik jari isi kode itu sendiri, dan itu sebabnya dokumentasi GitHub menganjurkan pin ke SHA bagi repositori yang belum memakai lockfile workflow (dibahas di bawah).

Kasus Trivy: Kronologi dan Dampak

Menurut advisori resmi Aqua Security (GHSA-69fq-xp46-6x23, CVE-2026-33634), pada 19 Maret 2026 penyerang memakai kredensial yang dikompromikan untuk melakukan force-push 76 dari 77 tag versi di aquasecurity/trivy-action ke commit berbahaya, mengganti ketujuh tag setup-trivy, dan menerbitkan Trivy v0.69.4 berbahaya, antara lain ke GHCR, ECR Public, dan Docker Hub. Image Docker Hub v0.69.5 dan v0.69.6 yang berbahaya menyusul pada 22 Maret. Advisori menyebut insiden ini kelanjutan serangan yang dimulai akhir Februari 2026: setelah pengungkapan 1 Maret, rotasi kredensial dilakukan tetapi tidak atomik. Menurut analisis Snyk, akses awal berasal dari PAT yang dicuri lewat eksploitasi workflow pull_request_target, dan Snyk mengaitkan serangan ini dengan kelompok TeamPCP; advisori Aqua sendiri tidak menyebut nama pelaku. Gambaran kampanye yang lebih luas ada di artikel TeamPCP.

• Jendela paparan: untuk trivy-action sekitar 12 jam, dari 19 Maret 2026 pukul 17:43 UTC sampai sekitar 20 Maret pukul 05:40 UTC; untuk setup-trivy sekitar 4 jam dan untuk biner v0.69.4 sekitar 3 jam pada 19 Maret.
• Perilaku payload (menurut Snyk): entrypoint berbahaya mencuri rahasia CI/CD sebelum menjalankan pemindaian Trivy yang sah, sehingga pipeline tampak normal. Pada runner yang di-host GitHub, ia membaca memori proses runner untuk mengambil rahasia. Pada runner self-hosted, ia menyisir puluhan lokasi sensitif seperti kunci SSH, kredensial cloud, konfigurasi Kubernetes, dan state Terraform.
• Versi aman: trivy v0.69.2 atau v0.69.3, trivy-action v0.35.0, dan setup-trivy v0.2.6. Menurut advisori, trivy-action v0.35.0 lolos karena dilindungi fitur immutable releases GitHub yang sudah aktif sebelum serangan.

Pelajaran yang paling tajam: pemindai keamanan yang berjalan di dalam CI memegang rahasia build yang sama dengan job lain. Ketika pemindai itu dikompromikan, ia menjadi pencuri yang paling dipercaya.

Pola Lain yang Sering Muncul di Pipeline

Tag yang dapat dipindahkan hanyalah satu pintu. Kasus TanStack pada 11 Mei 2026, yang dianalisis OpenSSF, menunjukkan rangkaian lain: workflow pull_request_target yang menjalankan kode dari fork, cache build yang diracuni lalu dipulihkan oleh workflow rilis, dan token OIDC yang diambil dari memori runner. Dua publikasi berbahaya dalam kasus itu bahkan berakhir berstatus gagal tetapi tetap menerbitkan paket. Pelajaran umumnya sama: cache, izin token, dan jenis pemicu workflow adalah batas kepercayaan, bukan detail teknis.

Ancaman baru juga datang dari sisi AI, ketika agen yang membaca isu atau komentar dapat diperdaya; topik itu dibahas di artikel prompt injection di pipeline CI/CD.

Cara Mengamankan Pipeline: Pin ke Commit SHA dan Hak Akses Minimal

1. Kunci dependensi workflow, minimal dengan pin SHA. Per 30 Oktober 2026, dokumentasi GitHub menyebut lockfile workflow (.github/workflows/actions.lock, dibuat dengan ekstensi gh actions-lock, masih public preview) sebagai perlindungan terkuat: ia mencatat commit setiap action termasuk dependensi transitif dan memeriksa identitas repositori sumbernya saat dijalankan. Jika belum memakainya, pin setiap action ke commit SHA 40 karakter.
2. Detail pin SHA. Tulis uses: pemilik/action@ diikuti SHA lengkap, dan simpan versi manusiawi dalam komentar. Dependabot dapat memperbarui action yang dipin ke SHA lewat pull request yang bisa Anda review, tetapi menurut GitHub ia tidak membuat security alert untuk action yang dipin ke SHA. Pastikan juga SHA berasal dari repositori action itu sendiri, bukan dari fork.
3. Batasi GITHUB_TOKEN. Setel izin default ke baca saja, lalu naikkan per job hanya jika perlu. Izin id-token: write hanya untuk job yang memang menerbitkan rilis.
4. Hindari pull_request_target untuk kode dari fork. Gunakan pull_request bila memungkinkan, dan jangan checkout kode pull request di konteks yang punya rahasia.
5. Perlakukan cache sebagai batas kepercayaan. Jangan biarkan workflow yang menerima kode tidak tepercaya berbagi cache dengan workflow rilis.
6. Gunakan token yang dibatasi repositori atau GitHub App, bukan PAT tingkat organisasi, agar dampak pencurian terbatas. Prinsipnya sama dengan least privilege.
7. Pin image kontainer lewat digest, bukan tag. Docker menyarankan hal ini setelah image Trivy dan KICS yang berbahaya diunggah memakai kredensial penerbit yang valid.
8. Awasi lalu lintas keluar dari runner. Batasi tujuan koneksi ke yang disetujui; Snyk dan Docker sama-sama menyarankan pemantauan egress karena pencurian rahasia hampir selalu berakhir dengan koneksi keluar.
9. Aktifkan immutable releases bila Anda merilis action sendiri, agar tag rilis tidak bisa dipindahkan diam-diam.

Untuk audit cepat, telusuri semua berkas workflow di organisasi dan daftar setiap baris uses:. Tandai yang memakai tag atau nama branch, yang berasal dari pemilik tak dikenal, dan yang berjalan pada job dengan akses rahasia atau izin menulis. Prioritaskan perbaikan pada job rilis dan job yang menyentuh kredensial cloud, karena di situlah kerugian terbesar bila sebuah action dikompromikan. Setelah itu, jadikan pemeriksaan pin SHA sebagai bagian dari review pull request agar kebiasaan ini bertahan.

Jika Anda Sempat Memakai Versi yang Terdampak

Anggap seluruh rahasia yang dapat dijangkau workflow selama jendela paparan sebagai bocor. Ganti token GitHub, kunci cloud, token registry, kunci SSH, dan kunci API, lalu pastikan kredensial lama benar-benar tidak berlaku, bukan hanya bahwa yang baru berfungsi. Tinjau log eksekusi workflow pada jendela waktu tersebut, dan, sesuai advisori Aqua, cari repositori berawalan tpcp-docs di organisasi GitHub Anda, yang dapat menandakan eksfiltrasi berhasil. Jika perlu bantuan memetakan paparan, tim layanan asesmen Linuxhackingid dapat membantu mengaudit konfigurasi pipeline Anda.

Pertanyaan yang Sering Diajukan

Apakah pin ke SHA sudah cukup?

Itu langkah penting, tetapi bukan satu-satunya. Pin SHA tidak mencakup action yang dipanggil oleh action Anda, celah yang ditutup lockfile workflow. Pin mencegah tag digeser, tetapi tidak melindungi dari kode yang memang berbahaya sejak commit itu dibuat. Tetap batasi izin dan awasi perilaku jaringan.

Bagaimana jika action yang saya pakai sudah dipin ke SHA tetapi tidak pernah diperbarui?

Aktifkan pembaruan terjadwal dengan review manusia. SHA lama yang membeku dapat berisi kerentanan yang sudah diperbaiki di versi lebih baru.

Apakah runner di-host GitHub lebih aman dari self-hosted?

Keduanya dapat kehilangan rahasia. Pada kasus Trivy, runner di-host GitHub kehilangan rahasia lewat pembacaan memori, sedangkan runner self-hosted terpapar pada berkas lokal yang jauh lebih banyak.

Kesimpulan

Tag adalah janji, SHA adalah bukti. Mulailah dengan menginventarisasi semua uses: di repositori Anda, pin ke SHA, kurangi izin token, dan hapus pemicu yang berbahaya. Perubahan ini kecil, tetapi menutup salah satu jalur serangan rantai pasok yang paling sering dipakai pada 2026. Untuk latihan langsung membangun pipeline aman, kunjungi halaman Linuxhackingid dan pelajari juga dasar-dasar supply chain attack.