- Astral, yang mengembangkan alat seperti Ruff, uv, dan ty yang digunakan para developer di seluruh dunia, mempertahankan keamanan dan keandalan semua produknya sebagai nilai inti
- Untuk merespons meningkatnya serangan rantai pasok belakangan ini, Astral mengungkap teknik internal untuk memperkuat keamanan di seluruh proses build, distribusi, dan rilis
- Dalam CI/CD berbasis GitHub Actions, Astral menerapkan sistem perlindungan berlapis seperti pin hash, hak akses minimum, dan pemisahan rahasia
- Pada tahap rilis, Astral memastikan integritas distribusi dengan Trusted Publishing, Sigstore attestations, dan Immutable Releases
- Melalui pendekatan ini, Astral bertujuan meningkatkan tingkat keamanan ekosistem open source secara keseluruhan dan membangun sistem pertahanan yang berkelanjutan
Pendekatan keamanan open source Astral
- Astral mengembangkan alat seperti Ruff, uv, dan ty yang digunakan jutaan developer di seluruh dunia, serta menjadikan keamanan dan keandalan alat-alat tersebut sebagai nilai inti
- Seiring meningkatnya serangan rantai pasok, termasuk kasus peretasan Trivy dan LiteLLM, Astral membagikan teknik keamanan internal untuk menjamin keamanan alat mereka serta proses build dan distribusi
- Astral membagikan praktik terbaik keamanan yang dapat dijadikan referensi oleh pengguna, maintainer open source, dan developer sistem CI/CD
Keamanan CI/CD
- Astral mengotomatiskan pengembangan dan distribusi melalui workflow CI/CD yang luas berbasis GitHub Actions, dan memanfaatkannya sebagai komponen inti keamanan
- Build dan pengujian dijalankan di lingkungan yang terkontrol dan dapat diamati, bukan di lingkungan lokal
- Menyadari bahwa pengaturan keamanan bawaan GitHub Actions lemah, Astral menerapkan penguatan berikut
- Melarang sepenuhnya trigger berisiko seperti
pull_request_target dan workflow_run
- Mem-pin semua action ke hash commit (SHA) tertentu dan memverifikasi silang apakah ada impostor commit
- Menerapkan alat audit
unpinned-uses dan impostor-commit dari zizmor bersama kebijakan GitHub
- Melakukan pin hash pada seluruh graf dependensi, termasuk action dependensi tidak langsung yang tidak bisa dipin secara langsung
- Karena pin hash saja tidak cukup, Astral mendeteksi cacat imutabilitas melalui peninjauan manual dan bila perlu bekerja sama dengan proyek upstream untuk memperbaikinya
- Contoh: memetakan URL unduhan biner dan hash-nya agar ditanamkan sebagai kondisi immutable
- Izin workflow dibatasi menjadi read-only secara default, dan hanya hak akses minimum yang diperlukan yang diberikan per job
- GitHub Secrets dikelola sebagai variabel lingkungan deployment yang dipisahkan per lingkungan, sehingga pekerjaan test dan lint tidak dapat mengakses rahasia rilis
- Sebagai alat bantu, Astral menggunakan zizmor (analisis statis) dan pinact (pin hash otomatis)
Keamanan repositori dan organisasi
- Di organisasi Astral, jumlah akun dengan hak admin diminimalkan, dan sebagian besar anggota hanya memiliki izin baca/tulis pada repositori yang diperlukan
- Semua anggota diwajibkan menggunakan autentikasi dua faktor (2FA) yang kuat, dengan metode autentikasi minimal setara TOTP
- Jika GitHub hanya mengizinkan metode tahan phishing (WebAuthn, Passkeys), Astral berencana segera beralih
- Aturan perlindungan branch diterapkan ke seluruh organisasi
- Branch
main tidak boleh di-force push, dan semua perubahan hanya dapat dilakukan melalui PR
- Pembuatan pola branch tertentu seperti
advisory-* dan internal-* dilarang
- Aturan perlindungan tag memastikan tag hanya dapat dibuat setelah distribusi rilis berhasil
- Perubahan atau penghapusan tag dilarang, dan rilis hanya dapat dilakukan dari branch
main
- Bahkan admin repositori tidak bisa melewati aturan perlindungan; semua perlindungan dipaksakan di tingkat organisasi
- Astral mempublikasikan kumpulan aturan ini sebagai gist agar dapat dijadikan referensi oleh proyek lain
Otomatisasi
- Dengan GitHub Actions, sebagian pekerjaan seperti meninggalkan komentar pada PR pihak ketiga tidak dapat dilakukan dengan aman
- Untuk itu, Astral menggunakan GitHub App astral-sh-bot agar event dapat diproses dengan aman di luar Actions
- GitHub App menerima data event yang sama, tetapi berjalan di lingkungan tempat kode dan data dipisahkan
- Namun, App juga tidak menghilangkan kredensial sensitif
- Karena kerentanan seperti SQLi dan prompt injection dapat tetap ada, App perlu dikembangkan dengan tingkat keamanan yang sama seperti software biasa
- Menggunakan App tidak otomatis menjamin keamanan eksekusi kode yang tidak tepercaya
- Pendekatan GitHub App lebih unggul dari sisi keamanan, tetapi menambah kompleksitas
- Perlu pengembangan dan hosting App, sehingga bisa menjadi beban bagi developer individu atau proyek kecil
- Framework Python Gidgethub membantu menyederhanakan pengembangan
- Astral berencana merilis astral-sh-bot sebagai open source, dan merekomendasikan tutorial Mariatta sebagai referensi
Keamanan rilis
- Alat-alat Astral didistribusikan melalui berbagai kanal selain GitHub, termasuk PyPI, Homebrew, dan image Docker
- Untuk mencegah serangan rantai pasok, Astral menerapkan langkah-langkah berikut
- Menggunakan Trusted Publishing untuk menghilangkan kredensial registry
- Membuat attestations berbasis Sigstore untuk menjamin keterkaitan kriptografis antara artefak build dan workflow
- Menggunakan fitur Immutable Releases dari GitHub untuk mencegah modifikasi setelah dipublikasikan
- Tidak menggunakan build cache untuk mencegah serangan kontaminasi cache
- Proses rilis diisolasi dalam deployment environment khusus
- Aktivasi lingkungan rilis memerlukan persetujuan anggota tim lain, untuk mencegah rilis berbahaya akibat kompromi satu akun
- Mempertahankan persetujuan multi-tahap dengan lingkungan
release-gate dan perantara persetujuan berbasis GitHub App
- Tag hanya dapat dibuat setelah rilis berhasil
- Standalone installer memverifikasi integritas biner melalui checksum yang tertanam
- Setelah rilis, pembaruan dokumentasi, manifest versi, dan hook pre-commit dilakukan dengan akun bot khusus dan PAT yang dipilah secara rinci
- Di masa depan, Astral berencana menambahkan code signing untuk macOS dan Windows
Keamanan dependensi
- Astral menggunakan Dependabot dan Renovate untuk mengelola pembaruan dependensi dan notifikasi kerentanan
- Astral menerapkan periode cooldown untuk menunda pembaruan segera setelah rilis baru, sehingga mengurangi risiko serangan rantai pasok sementara
- Renovate mendukung pengaturan cooldown per grup, dan mitigasi diterapkan pada dependensi internal mereka sendiri
- Astral juga melakukan kolaborasi berkelanjutan dan kontribusi keamanan dengan proyek-proyek upstream utama
- Astral berbagi informasi keamanan dengan organisasi seperti Python Packaging Authority dan Python Security Response Team
- Penambahan dependensi baru ditinjau dengan hati-hati, dan penghapusan dependensi yang tidak perlu terus diupayakan
- Khususnya, mereka menghindari dependensi yang menyertakan binary blob dan menonaktifkan fitur yang tidak diperlukan
- Astral juga memberikan dukungan finansial pada proyek open source inti melalui OSS Fund
Kesimpulan dan pelajaran utama
- Keamanan open source adalah gabungan persoalan teknis dan sosial yang membutuhkan respons berkelanjutan
- Prinsip utama yang ditekankan Astral
- Menyadari keterbatasan CI/CD, dan bila tak terhindarkan menggunakan isolasi eksternal seperti GitHub App
- Menghapus dan meminimalkan kredensial jangka panjang, serta memanfaatkan Trusted Publishing dan autentikasi OIDC
- Memperkuat proses rilis dengan aturan persetujuan, tag, branch, dan penerapan Immutable Release
- Menjaga kesadaran terhadap dependensi, serta memperkuat keamanan proyek upstream melalui alat dan kolaborasi
- Astral akan terus mengevaluasi dan menyempurnakan teknik-teknik ini, serta mengembangkan sistem pertahanan seiring perubahan perilaku penyerang
Ringkasan catatan kaki
- PEP 740 dari PyPI mengizinkan unggahan attestations, tetapi saat ini belum kompatibel dengan implementasi Trusted Publishing milik Astral sehingga penerapannya masih ditunda
- Checksum di dalam skrip instalasi memiliki efektivitas terbatas saat dijalankan langsung dengan
curl ... | bash, tetapi berguna saat di-vendor dalam CI/CD
Belum ada komentar.