GitHub Actions punya package manager, tapi mungkin yang terburuk

• GitHub Actions memiliki struktur untuk mendeklarasikan dan menjalankan dependensi paket melalui sintaks uses: di file workflow, yang pada praktiknya berperan sebagai package manager
• Namun, fitur dasar yang biasanya disediakan package manager lain seperti lockfile, hash integritas, pinning dependensi transitif, dan visibilitas pohon dependensi sama sekali tidak ada
• Hasil riset menunjukkan bahwa sebagian besar pengguna GitHub Actions menjalankan kode eksternal yang tidak terverifikasi, dan kerentanan injeksi kode ditemukan di ribuan workflow
• Meski GitHub telah memperkenalkan beberapa mitigasi (rilis immutable, kebijakan pinning SHA, dll.), masalah dependensi transitif dan reproduksibilitas masih belum terselesaikan
• Cacat struktural ini berdampak pada keamanan supply chain perangkat lunak secara luas, dan masalah yang sama juga menyebar ke sistem CI lain yang berbasis GitHub Actions

---

Struktur manajemen paket GitHub Actions dan masalahnya

• Sintaks seperti uses: actions/checkout@v4 adalah deklarasi dependensi, lalu GitHub menafsirkannya untuk mengunduh dan menjalankannya
  • Ini sama dengan perilaku package manager pada umumnya, tetapi tanpa lockfile, versi yang dipilih bisa berbeda di setiap eksekusi
• Dibandingkan dengan package manager lain (npm, Cargo, NuGet, dll.), Actions tidak memiliki lockfile, pinning transitif, verifikasi integritas, visibilitas pohon dependensi, maupun spesifikasi resolusi
• Ketiadaan lockfile adalah masalah inti, karena resolusi dependensi dapat berubah setiap kali dijalankan sehingga menghasilkan build yang non-deterministik

Hasil riset keamanan dan kerentanan

• Menurut riset USENIX Security 2022, 99,7% repository menjalankan Actions dari developer eksternal, 97% menggunakan pembuat yang tidak terverifikasi, dan 18% melewatkan pembaruan keamanan
• Riset lanjutan menemukan kerentanan injeksi kode di lebih dari 4.300 dari 2,7 juta workflow
• GitHub Actions tidak cukup menyediakan properti keamanan penting CI/CD seperti admittance control, execution control, code control, dan kontrol akses secrets

Cacat teknis utama

• Masalah versi yang dapat berubah: tag seperti @v4 bisa di-tag ulang oleh maintainer ke commit baru, sehingga kode bisa berubah diam-diam
  • Jika ada lockfile, tag tersebut bisa dicatat saat di-resolve ke SHA tertentu
• Ketidaktransparanan dependensi transitif: Action lain yang dipanggil di dalam Composite Action tidak terlihat dan tidak bisa dikendalikan
  • Menurut riset, 54% JavaScript Actions mengandung kelemahan keamanan, dan sebagian besar berasal dari dependensi tidak langsung
  • Dalam insiden tj-actions/changed-files, serangan kebocoran secret terjadi melalui pembaruan dependensi transitif
• Tidak ada verifikasi integritas: npm atau Cargo mencatat hash untuk memverifikasi unduhan, sedangkan Actions hanya bergantung pada kepercayaan berbasis SHA
• Re-run tidak reproduktif: GitHub menyatakan bahwa “jika versi di-force push, maka versi terbaru akan diambil”, sehingga workflow yang sama pun bisa menjalankan kode berbeda
• Pohon dependensi tidak terlihat: tidak ada fitur seperti npm ls atau cargo tree, sehingga tidak ada cara untuk memeriksa keseluruhan struktur dependensi
• Aturan resolusi tidak dibuka: resolusi dependensi di Actions tidak terdokumentasi, dan hanya ada logika unduh rekursif sederhana di kode ActionManager.cs

Keterbatasan struktural tambahan

• Tidak ada registry terpusat: Actions berada di repository Git, sehingga tidak ada fitur pemindaian keamanan, deteksi malware, atau pencegahan typosquatting
• Masalah lingkungan bersama: beberapa Action memodifikasi $PATH yang sama, sehingga hasil bisa berbeda tergantung urutan eksekusi
• Tidak bisa dijalankan offline: harus diunduh dari GitHub setiap kali, sehingga tidak bisa dieksekusi tanpa jaringan
• Kerentanan namespace: username GitHub sekaligus menjadi namespace, sehingga rentan terhadap pengambilalihan akun atau serangan typo
  • Jika ada lockfile dan hash integritas, perubahan kode bisa terdeteksi lewat kegagalan build

Latar belakang desain dan efek rambatnya

• Runner Actions awalnya berbasis Azure DevOps dan dirancang dengan asumsi lingkungan internal yang tepercaya
  • Ketika GitHub memperluasnya menjadi marketplace publik, model kepercayaannya tidak didesain ulang
• Akibatnya, fitur dasar seperti lockfile, verifikasi integritas, pinning transitif, dan visibilitas dependensi tidak ikut tersedia
• Seiring meluasnya fitur deployment paket otomatis berbasis OIDC, celah keamanan di Actions mulai memengaruhi keamanan supply chain seluruh registry paket
• GitLab CI memperkenalkan keyword integrity untuk mendukung verifikasi hash, tetapi GitHub menutup permintaan serupa dengan status “tidak direncanakan”
• Sistem CI yang kompatibel dengan GitHub seperti Forgejo Actions juga harus mempertahankan struktur yang sama, sehingga cacat ini menyebar ke seluruh ekosistem

Usulan perbaikan dan kondisi saat ini

• Komunitas meminta dukungan lockfile (issue #2195), tetapi GitHub menutupnya pada 2022 dengan status “tidak direncanakan”
• Riset Palo Alto membuktikan bahwa pinning SHA saja tidak cukup untuk melindungi dependensi transitif
• Beberapa tim menambal kekurangan ini dengan pembaruan Dependabot, vendoring repository sendiri, dan scanner keamanan zizmor
• Solusi mendasar adalah menghadirkan lockfile yang mencatat SHA dan hash integritas untuk semua Action serta dependensi transitifnya
• Selama GitHub tidak mengadopsinya, keandalan supply chain CI/CD tidak mungkin dijamin

[holywork]

Mungkin baru sadar setelah kena retas.

[GN⁺]

Opini Hacker News

• Saya tidak ingin membela GHA (GitHub Actions), tetapi dokumentasinya memang menyatakan bahwa untuk stabilitas dan keamanan disarankan mengunci commit SHA
  Ini bisa diterapkan sendiri seperti file lock, tetapi tidak sepenuhnya memadai karena transitive dependency tidak bisa dikendalikan
  Pada akhirnya muncul beban untuk melacak patch keamanan dan memperbarui hash, dan tampaknya karena alasan ini penguncian berbasis hash tidak banyak dipakai

  • GitHub sudah mengetahui masalah ini sejak tak lama setelah Actions dirilis, tetapi secara praktis tidak banyak meningkatkan fitur penguncian versi
    Sebagian besar pengguna tidak menyadari masalah ini, dan bahkan yang sadar pun hampir tidak pernah memakai SHA
    Saya pribadi menyukai Actions dan memelihara beberapa di antaranya, tetapi jika melihat repositori publik, 90% memakai @v1, 9% memakai @v1.2, dan hanya 1% yang memakai commit SHA
    Dengan sedikit investasi saja, GitHub seharusnya bisa membuat solusi file lock
  • Strategi di dokumentasi tidak menyelesaikan masalah transitive dependency, jadi dalam praktiknya itu bukan solusi mendasar
  • Pernyataan bahwa mengunci commit SHA itu stabil pada kenyataannya keliru
    Sering kali ada ketergantungan pada versi Node atau versi API tertentu, sehingga saya justru pernah merasa memakai @main lebih baik
  • Saya menganggap penggunaan SHA justru sebuah anti-pattern
    Orang merasa mendapat “versi yang terkunci”, padahal sebenarnya tidak
    Setelah dua kali mengalami masalah, saya sadar — file lock itu entah ada atau tidak ada

• GitHub hampir tidak memelihara Actions buatannya sendiri, dan bahkan fungsi dasar pun akhirnya bergantung pada fork tidak resmi
  Seluruh ekosistemnya terasa seperti dipertahankan dengan solusi sementara

  • Situasi ini tampaknya tidak akan membaik dalam waktu dekat
    Karena GitHub telah mengumumkan bahwa mereka memprioritaskan migrasi ke Azure dibanding pengembangan fitur
    Artikel terkait
  • Hal yang menarik adalah GitHub merupakan layanan yang cukup mahal
    Perusahaan kecil kami pun membayar lebih dari 200 dolar per bulan
    Ini tampaknya dianggap sebagai sumber pendapatan baru yang lebih penting daripada Windows
  • Kualitas setup- actions* terlihat menurun drastis, dan makin banyak keputusan yang aneh
    Mungkin para penulis aslinya sudah keluar dari perusahaan
  • Ini pertama kalinya saya mendengar soal ini, jadi saya penasaran apakah ada contoh konkret
  • Bukankah GitHub baru-baru ini mengumumkan bahwa mereka memperlambat pengembangan fitur umum demi fokus pada pengembangan AI?

• Saya penasaran apakah ada yang pernah memakai ArgoCD sebagai pipeline CI

• Saya rasa GHA adalah contoh kegagalan filosofi 'less is more'
  Masalah terbesarnya adalah bahwa ini telah menjadi standar industri
  Dengan sedikit investasi saja mereka bisa membuat CI yang jauh lebih baik, tetapi rasanya MS mengulangi kesalahan era IE6
  Sekarang ada generasi engineer muda yang tidak punya pengalaman pembanding sehingga tidak menyadari keterbatasannya

  • Semua orang setuju bahwa GHA memang buruk, tetapi mereka tetap memakainya karena menyediakan resource komputasi gratis
    Saya sedang berpikir menjalankan laptop pensiun sebagai server Woodpecker. Saya penasaran seperti apa CI yang benar-benar tidak dibenci orang
  • Saya berasal dari generasi yang dulu harus memakai VSS, jadi bahkan GitHub saat ini pun terasa jauh lebih baik dibanding masa itu
  • Saya cenderung melakukan sebagian besar pekerjaan langsung secara lokal
    Dibanding itu, GHA terasa tidak memberi banyak nilai

• Saya menentang ketika perusahaan hendak berpindah dari Jenkins/Ansible ke GHA, dan sekarang tampaknya itu keputusan yang tepat
  CI selalu membawa beban pemeliharaan yang besar, dan lingkungan Mac khususnya masih sulit ditangani

• Untuk pertanyaan, “Apakah Anda percaya GitHub memberikan kode SHA yang benar?”,
  melihat kenyataan bahwa kebanyakan orang memakai GitHub-hosted runner, kalau Anda tidak bisa mempercayai itu maka sebenarnya sudah ada masalah yang lebih besar

• Saya sempat berpikir bagaimana jika GitHub Actions memiliki arsitektur local-first, dengan dukungan locking berbasis Nix
  cachix/cloud.devenv.sh

  • Ironisnya, bahkan kode itu sendiri di-host di GitHub

• Banyak Actions pihak ketiga di dokumentasi atau contoh langsung merujuk ke branch master
  Satu push berbahaya saja bisa memungkinkan kebocoran data di banyak repositori
  Memakai tag pun bukan pertahanan sempurna karena tag bisa dipindahkan

• Melihat empat properti keamanan inti CI/CD yang disebut para peneliti (autentikasi, eksekusi, kode, akses ke rahasia), saya jadi bertanya-tanya
  Apakah CI/CD benar-benar perlu mengakses secrets?
  Menurut saya cukup jika hanya punya izin untuk memanggil API
  Sistem ideal seharusnya tidak menangani secrets secara langsung, melainkan memprosesnya secara tidak langsung melalui adaptor seperti secure enclave

  • Pernyataan bahwa “CI yang baik seharusnya tidak mendukung secrets” pada akhirnya berarti mengusulkan cara pengelolaan secrets yang lebih rumit
    Dalam kenyataannya, sebagian besar pelanggan tetap membutuhkan secrets
  • Secara teori itu benar, tetapi dalam praktik orang mau tidak mau harus menaruh secrets di CI/CD
    Platform setidaknya harus menyediakan mekanisme pengelolaan secrets yang aman
    Terutama karena proyek open source ingin melakukan deploy langsung dari CI
  • Perusahaan kami memakai alat komersial seperti compiler QNX atau Coverity, dan semuanya membutuhkan secrets untuk mengakses server lisensi
    Saya penasaran seperti apa tepatnya perbedaan dari “pendekatan secure enclave”
  • Jika CI/CD terintegrasi sepenuhnya dengan infrastruktur, deploy mungkin bisa dilakukan tanpa secrets,
    tetapi dalam kenyataan tiap lingkungan berbeda dan biaya implementasinya besar, sehingga kebanyakan akhirnya menetap pada pendekatan container + environment variable
  • Untuk menguji kompatibilitas dengan berbagai cloud DB, Anda membutuhkan credential untuk mengakses tiap DB
    Untuk mengotomatisasi pengujian seperti ini, secrets tidak terhindarkan

• Jika file lock harus di-commit ke repositori, maka muncul masalah bootstrap pada saat pertama kali membuatnya
  Untuk menyelesaikan ini, dibutuhkan kemampuan menjalankan Actions secara lokal
  Ada alat seperti nektos/act, tetapi ini terutama untuk debugging
  Mungkin diperlukan mekanisme terpisah berbasis analisis statis