GitHub Action Populer Kena Hack Lagi: Jangan Sembarangan Pakai Action Pihak Ketiga

Coba buka salah satu file workflow .github/workflows/*.yml di repository project Anda sekarang.

Besar kemungkinan Anda akan menemukan baris-baris seperti ini: uses: actions/checkout@v4, uses: actions/setup-node@v4, atau mungkin action open-source buatan komunitas seperti uses: some-author/some-action@v1.

Workflow tersebut berjalan mulus, badge CI/CD berwarna hijau, dan deployment berjalan otomatis setiap kali ada pull request yang di-merge. Semuanya terlihat aman sampai sebuah insiden supply chain attack menyerang runner CI/CD Anda, mengeksekusi kode berbahaya, dan mencuri token cloud credentials Anda secara diam-diam.

Kabar buruknya, ini bukan skenario fiksi. Dua repository GitHub Action populer dari organisasi actions-cool dilaporkan sempat aktif kembali dan mengeksekusi payload malware bernama Mini Shai-Hulud setelah sempat dibobol beberapa bulan sebelumnya.

Insiden ini menjadi tamparan keras bagi ekosistem software engineering modern: mengandalkan tag versi (seperti @v1 atau @v2) pada third-party GitHub Actions adalah celah keamanan yang sangat berbahaya.

Anatomi Insiden: Bangkitnya Malware Mini Shai-Hulud

Serangan terhadap ekosistem software supply chain bukan barang baru, namun insiden actions-cool memperlihatkan pola yang sangat mengkhawatirkan: repository yang sebelumnya pernah dibobol dan dianggap sudah ditangani, ternyata bisa aktif kembali (re-enabled) dengan payload berbahaya yang masih aktif.

Ketika repository pihak ketiga tersebut diambil alih oleh penyerang, malware Mini Shai-Hulud disuntikkan langsung ke dalam codebase action tersebut. Masalah utamanya ada pada siklus eksekusi CI/CD:

1. Blind Trust pada Tag Versi: Mayoritas developer mereferensikan action menggunakan semantic versioning tag (@v1, @v2.1.0). Padahal dalam arsitektur Git, tag bersifat mutable (bisa dipindah-pindah atau di-overwrite kapan saja oleh siapapun yang memiliki akses push ke repository tersebut).
2. Runner Privileges: Runner GitHub Actions secara default memiliki akses ke environment variables, secrets (GITHUB_TOKEN, API keys, deployment credentials), serta filesystem temporary tempat source code Anda di-build.
3. Silent Execution: Ketika pipeline dijalankan, runner menarik commit terbaru yang ditunjuk oleh tag tersebut. Malware dieksekusi tepat di tengah-tengah proses build Anda tanpa memicu kecurigaan karena step CI/CD tetap terlihat "berjalan normal".

Mengapa Git Tag di GitHub Actions Sangat Rentan?

Untuk memahami mengapa tag versi sangat rapuh, kita harus melihat bagaimana Git mengelola referensi objek.

Tag di Git hanyalah sebuah pointer teks biasa di .git/refs/tags/. Siapapun maintainer yang akunnya terkena kompromi (misalnya via credential stuffing, phishing, atau token leak) dapat menjalankan perintah berikut:

# Penyerang mengubah pointer tag v1 ke commit berbahaya
git tag -d v1
git push origin :refs/tags/v1
git tag -a v1 -m "Release v1 with malicious patch"
git push origin v1

Begitu perintah itu dieksekusi di repository upstream, semua pipeline CI/CD di seluruh dunia yang menuliskan uses: upstream-org/cool-action@v1 akan langsung mendownload dan menjalankan kode berbahaya tersebut pada build berikutnya. Tidak ada warning. Tidak ada error build.

Satu-satunya cara mencegah hal ini adalah dengan menggunakan Full Commit SHA (40 karakter hash SHA-1). Commit hash bersifat immutable; mengubah satu baris kode di repository akan menghasilkan commit hash yang sama sekali berbeda.

Implementasi Nyata: Dari Mutable Tag ke Immutable Commit SHA

Mari kita bedah contoh nyata perbaikan konfigurasi workflow. Berikut adalah contoh file workflow yang rentan dan sering ditemukan di project produksi:

# .github/workflows/vulnerable-pipeline.yml
name: Build and Test (Vulnerable)

on:
  push:
    branches: [ main ]
  pull_request:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      # SANGAT RENTAN: Menggunakan tag versi mutable
      - name: Checkout Code
        uses: actions/checkout@v4

      # SANGAT RENTAN: Third-party action dari komunitas menggunakan tag
      - name: Auto Assign Issues
        uses: actions-cool/issues-helper@v3
        with:
          actions: 'add-assignees'
          token: ${{ secrets.GITHUB_TOKEN }}

      - name: Run Build
        run: |
          npm ci
          npm run build

Jika repo actions-cool/issues-helper terkena hack dan tag v3 dimanipulasi untuk mengeksekusi payload Mini Shai-Hulud, runner Anda akan mengeksekusi kode tersebut dan token ${{ secrets.GITHUB_TOKEN }} Anda bisa langsung disalahgunakan untuk mengakses repository privat, mengubah branch protection rules, atau menyisipkan commit berbahaya ke branch utama.

Sekarang, kita ubah workflow di atas menjadi workflow yang sudah menerapkan prinsip defensive supply chain hardening:

# .github/workflows/secure-pipeline.yml
name: Build and Test (Hardened)

on:
  push:
    branches: [ main ]
  pull_request:

# 1. Batasi permission default GITHUB_TOKEN ke level minimum
permissions:
  contents: read

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      # 2. Pin full commit SHA untuk actions resmi GitHub
      # actions/checkout@v4.1.7 (Release date verified)
      - name: Checkout Code
        uses: actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332

      # 3. Pin full commit SHA untuk third-party action + batasi permissions
      # actions-cool/issues-helper@v3.6.0 (Commit SHA yang sudah diaudit)
      - name: Auto Assign Issues
        uses: actions-cool/issues-helper@9ec988a2a5f36e4f3513a96860ad8409395f87b8
        with:
          actions: 'add-assignees'
          token: ${{ secrets.GITHUB_TOKEN }}

      - name: Run Build
        run: |
          npm ci
          npm run build

Penjelasan Baris demi Baris:

1. `permissions: contents: read`: Secara default, jika Anda tidak mendefinisikan blok permissions, GitHub Actions dapat memberikan akses write ke runner untuk beberapa skenario. Dengan mendefinisikan contents: read di root workflow, kita menerapkan prinsip least privilege. Jika ada malware yang berhasil masuk, malware tersebut tidak punya izin untuk melakukan commit balik ke repository.
2. `uses: actions/checkout@692973e...`: Daripada menulis @v4, kita memasukkan 40 karakter commit SHA. Bahkan jika repository actions/checkout diambil alih dan tag v4 diubah, runner kita hanya akan mengeksekusi snapshot commit 692973e... yang sudah kita verifikasi.
3. Komentar `# actions/checkout@v4.1.7`: Selalu letakkan komentar berisi versi semantic di atas baris commit SHA agar tim Anda tetap tahu versi logis apa yang sedang digunakan tanpa harus membuka browser dan mengecek commit history.

Mengelola Pin SHA Secara Otomatis dengan Dependabot

Masalah terbesar yang sering dikeluhkan tim engineering saat beralih ke commit SHA adalah: "Capek update-nya. Bagaimana cara kita tahu kalau ada update keamanan atau fitur baru?"

Jawabannya adalah Dependabot. GitHub memiliki native support untuk memantau dependensi GitHub Actions dan secara otomatis membuat Pull Request ketika ada versi baru, lengkap dengan update commit SHA.

Tambahkan konfigurasi berikut di file .github/dependabot.yml:

# .github/dependabot.yml
version: 2
updates:
  # Monitor dependensi npm/yarn/pnpm
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"

  # Monitor dependensi GitHub Actions
  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"
    commit-message:
      prefix: "ci"
      include: "scope"
    open-pull-requests-limit: 10

Bagaimana Dependabot Bekerja untuk GitHub Actions?

Ketika Anda mengaktifkan ecosystem github-actions di Dependabot:

1. Dependabot akan membaca seluruh file YAML di .github/workflows/.
2. Jika Anda mem-pin action menggunakan SHA seperti uses: actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332 # v4.1.7, Dependabot akan mengecek apakah ada rilis tag baru di repo actions/checkout.
3. Jika versi v4.2.0 dirilis, Dependabot akan otomatis membuka PR yang mengupdate commit SHA ke hash milik v4.2.0 sekaligus mengupdate komentar versinya.
4. Anda cukup mereview changelog di dalam PR Dependabot, memverifikasi tidak ada kode aneh, lalu melakukan merge.

4 Langkah Hardening Wajib untuk Melindungi Pipeline CI/CD

Jika Anda adalah seorang Tech Lead atau Senior Engineer, berikut adalah playbook langkah teknis yang perlu Anda eksekusi segera di seluruh repository tim Anda:

1. Audit Seluruh Workflow Menggunakan Linter Keamanan

Jangan audit manual puluhan file YAML di repository Anda. Gunakan tool static analysis khusus CI/CD seperti zizmor atau actionlint untuk mendeteksi action yang belum di-pin, celah script injection, dan permission berlebih.

Jalankan perintah audit via CLI berikut:

# Menjalankan security audit pada seluruh workflow GitHub Actions
# Tool ini akan menganalisis celah keamanan, unpinned actions, dan credential leak
npx zizmor .github/workflows/

Tool ini akan langsung mengeluarkan daftar file YAML beserta baris-baris yang masih menggunakan tag mutable atau yang memiliki konfigurasi permission yang longgar.

2. Terapkan Pembatasan Network Egress

Malware seperti Mini Shai-Hulud bekerja dengan cara menghubungi server Command and Control (C2) milik penyerang untuk mengirimkan secrets yang dicuri (data exfiltration).

Secara default, runner GitHub Actions diizinkan untuk melakukan koneksi outbound ke internet tanpa batasan. Anda bisa menggunakan solusi seperti step-security/harden-runner di awal step job Anda untuk membatasi traffic internet runner hanya ke domain yang diizinkan (misal: registry npm, maven, atau cloud provider API).

    steps:
      - name: Harden Runner (Block Malicious Egress)
        uses: step-security/harden-runner@91182cccc01eb5e619899d80e4e971d6181294aca # v2.10.1
        with:
          egress-policy: block
          allowed-endpoints: >
            github.com:443
            registry.npmjs.org:443

Catatan Penting: Mengunci network egress adalah lapisan pertahanan terakhir (last line of defense). Bahkan jika sebuah action berhasil disusupi payload malware, malware tersebut tidak akan bisa mengirimkan secrets Anda ke server penyerang karena koneksi outbound diblokir oleh firewall runner.

3. Hindari Long-Lived Secrets, Beralih ke OpenID Connect (OIDC)

Jangan pernah menyimpan AWS_SECRET_ACCESS_KEY atau token cloud jangka panjang di dalam GitHub Actions Secrets jika memungkinkan.

Gunakan mekanisme OpenID Connect (OIDC) antara GitHub Actions dan cloud provider Anda (AWS, Google Cloud, Azure). Dengan OIDC, runner meminta short-lived token yang hanya berlaku selama beberapa menit dan hanya memiliki hak akses sempit sesuai role yang ditentukan. Jika runner terkena kompromi, penyerang tidak akan mendapatkan credential permanen.

4. Batasi Eksekusi Action Pihak Ketiga di Level Organisasi

Jika Anda mengelola GitHub Organization:

• Buka Organization Settings -> Actions -> General.
• Pada opsi Action permissions, pilih: Allow select actions and reusable workflows.
• Izinkan hanya action yang dibuat oleh GitHub (actions/*) dan verified creators yang sudah diaudit oleh tim keamanan internal.

Gotchas & Anti-Patterns yang Sering Terjadi

Dalam proses implementasi security hardening di CI/CD, ada beberapa jebakan yang sering membuat tim developer frustrasi atau merasa sistemnya sudah aman padahal masih bolong:

• Anti-Pattern 1: Pinning Commit SHA pada Action yang Menjalankan `npm install` Tanpa Lockfile: Anda sudah mem-pin action repo ke commit SHA, tetapi action tersebut ternyata mengeksekusi script yang mendownload package eksternal tanpa verifikasi checksum. Pastikan third-party action yang Anda pakai tidak menarik dependency liar saat runtime.
• Anti-Pattern 2: Forking Tapi Tidak Pernah Sync Update Keamanan: Banyak tim memutuskan untuk melakukan fork action ke repository internal perusahaan agar "aman". Namun, setelah di-fork, repo tersebut ditinggalkan selama bertahun-tahun tanpa pernah menerima security patch. Forking tanpa proses maintenance berkala justru menciptakan technical debt dan celah keamanan baru.
• Anti-Pattern 3: Mengabaikan Permission `pull_request_target`: Event trigger pull_request_target berjalan dengan context target base branch dan memiliki akses penuh ke secrets repository. Jika Anda menggunakan action pihak ketiga yang belum terverifikasi di dalam workflow yang dipicu oleh pull_request_target, attacker dari public fork bisa mencuri secrets Anda via PR payload.

Kesimpulan & Action Items

Insiden kembalinya malware Mini Shai-Hulud pada repository actions-cool membuktikan bahwa ancaman supply chain attack pada CI/CD bukan sekadar teori akademis. Mengabaikan keamanan pipeline sama bahayanya dengan membiarkan celah SQL Injection di database produksi Anda.

Sebagai engineer modern, kita tidak boleh lagi menganggap CI/CD sebagai kotak hitam yang otomatis aman.

Berikut adalah Action Items konkret yang bisa Anda kerjakan hari ini:

1. Jalankan audit sekarang: Scan repository Anda menggunakan security linter seperti zizmor untuk menemukan semua third-party action yang belum di-pin.
2. Ubah tag menjadi Full Commit SHA: Ganti semua @v1, @v2, atau @master dengan hash SHA 40 karakter.
3. Aktifkan Dependabot untuk GitHub Actions: Pastikan file .github/dependabot.yml sudah memantau ekosistem github-actions agar proses update tetap berjalan mulus tanpa beban manual.
4. Perketat default permissions: Tambahkan permissions: contents: read di setiap workflow untuk membatasi hak akses GITHUB_TOKEN.

Keamanan software bukan soal membangun benteng yang mustahil ditembus, melainkan memastikan setiap lapis pertahanan—termasuk baris kode di workflow CI/CD Anda—tidak memberikan celah cuma-cuma bagi penyerang.

Sumber

• https://thehackernews.com/2026/09/compromised-github-actions-came-back.html
• https://www.bleepingcomputer.com/news/security/github-actions-re-enabled-with-mini-shai-hulud-payload-still-active/