- 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
Belum ada komentar.