Gambaran Lengkap Strategi Keamanan Open Source yang Diungkap Astral, Pembuat Ruff dan uv
(astral.sh)Astral membuat alat yang diandalkan jutaan developer di seluruh dunia (Ruff, uv, ty), dan baru-baru ini memublikasikan praktik keamanan mereka menyusul insiden peretasan rantai pasok Trivy dan LiteLLM. Pembaca yang dituju ada tiga kelompok: pengguna, maintainer open source lain, dan pengembang sistem CI/CD.
1. Keamanan CI/CD
Default keamanan GitHub Actions bersifat rentan, dan insiden kompromi pada Ultralytics, tj-actions, dan Nx semuanya berasal dari trigger berisiko seperti pull_request_target. Pendekatan Astral adalah sebagai berikut:
Melarang total trigger berbahaya
Trigger seperti pull_request_target dan workflow_run, yang hampir mustahil digunakan dengan aman, dilarang di seluruh organisasi. Banyak proyek mengira mereka membutuhkan trigger ini, tetapi pada praktiknya kebanyakan cukup memakai trigger pull_request yang berhak akses rendah atau log workflow sederhana.
Hash pinning untuk commit action
Alih-alih memakai tag atau branch (yang bisa berubah), mereka mengunci ke SHA commit tertentu dan memverifikasi silang apakah commit tersebut benar-benar sesuai dengan status rilis, untuk mencegah "commit palsu". Astral memakai zizmor bersama kebijakan bawaan GitHub, dan hash pinning juga diterapkan ke nested action yang dipanggil secara tidak langsung.
Prinsip hak akses minimum
Di level organisasi, izin default diatur hanya-baca, dan semua workflow dimulai dari permissions: {} lalu menambahkan izin yang diperlukan hanya di level job. Secret juga diisolasi per environment deployment, bukan di level organisasi atau repositori, agar job pengujian tidak bisa mengakses secret rilis.
2. Keamanan Repositori dan Organisasi
Jumlah akun admin dan akun berhak tinggi diminimalkan, dan sebagian besar anggota organisasi hanya memiliki izin baca/tulis pada repositori yang memang mereka perlukan. 2FA mensyaratkan setidaknya TOTP, yang lebih kuat daripada default GitHub (metode apa pun), dan ke depannya akan diperketat agar hanya WebAuthn dan passkey yang diizinkan.
Branch main dilindungi dengan aturan tidak boleh force push dan wajib pull request, sementara tag rilis dilindungi agar hanya bisa dibuat setelah deployment berhasil. Secara khusus, di level organisasi aturan ini dipaksakan agar bahkan admin repositori pun tidak bisa melewatinya.
3. Otomatisasi (memanfaatkan GitHub App)
Pekerjaan yang tidak bisa dilakukan dengan aman di GitHub Actions, seperti meninggalkan komentar pada PR dari pihak ketiga, dipisahkan ke GitHub App astral-sh-bot. Namun Astral menekankan bahwa GitHub App juga bukan berarti bebas dari celah, dan bila eksekusi kode tak tepercaya diperlukan, trigger pull_request tetap harus digunakan.
4. Keamanan Rilis
Untuk PyPI, crates.io, dan NPM, Astral menggunakan Trusted Publishing agar bisa melakukan deployment tanpa kredensial jangka panjang, dan pada binary serta image Docker mereka melampirkan attestation berbasis Sigstore untuk menyediakan keterkaitan kriptografis antara artefak rilis dan workflow.
Mereka juga menggunakan fitur immutable releases dari GitHub untuk mencegah perubahan pasca-publikasi pada build yang sudah dirilis, serta melarang penggunaan cache selama build rilis guna memblokir serangan cache poisoning.
Proses rilis itu sendiri juga dilindungi ganda: aktivasi environment rilis memerlukan persetujuan manual dari setidaknya satu anggota berwenang lain dalam organisasi. Artinya, untuk melakukan rilis berbahaya, penyerang harus membajak dua akun sekaligus yang masing-masing dilindungi 2FA kuat.
5. Keamanan Dependensi
Dependabot dan Renovate dipakai untuk mengelola pembaruan dependensi serta notifikasi kerentanan yang sudah diketahui, tetapi bersamaan dengan itu diterapkan kebijakan "cooldown" untuk tidak langsung memperbarui segera setelah rilis baru muncul. Tujuannya adalah meminimalkan dampak dari dependensi yang sempat dikompromikan untuk sementara. Fitur ini sudah terintegrasi di uv.
Astral juga menjaga hubungan sosial dengan proyek dan working group terkait seperti Python Packaging Authority (PyPA) dan Python Security Response Team, agar informasi bisa dibagikan saat ada isu yang dilaporkan ke pip dan ternyata juga memengaruhi uv. Penambahan dependensi baru dilakukan secara konservatif, dependensi yang mengandung binary blob dihindari, dan fitur yang tidak perlu dinonaktifkan.
Untuk keberlanjutan proyek-proyek yang mereka andalkan, Astral juga terus memberi kontribusi finansial melalui OSS Fund.
Ringkasan rekomendasi inti
Empat prinsip utama yang ditekankan Astral adalah: menyadari keterbatasan CI/CD dan berani meninggalkan pekerjaan yang tidak bisa dilakukan dengan aman atau memisahkannya ke GitHub App; menghapus kredensial jangka panjang bila memungkinkan dan mengisolasinya ke lingkup sekecil mungkin; memperkuat proses rilis dengan environment deployment, persetujuan, dan tag immutable; serta terus memahami kondisi kesehatan seluruh pohon dependensi.
Implikasi
Dilihat dari perspektif yang sangat terlibat pada PyPI dan keamanan rantai pasok, tulisan ini lebih dari sekadar panduan keamanan: ini adalah contoh praktik nyata tentang bagaimana merancang struktur kepercayaan untuk seluruh ekosistem open source. Khususnya, Trusted Publishing, kebijakan cooldown, dan proses rilis dengan persetujuan ganda layak dijadikan rujukan bagi proyek open source berskala besar.
Tulisan asli: Astral Blog, 2026.04.08
Belum ada komentar.