Strategi keamanan open source Astral

 (astral.sh)
1 poin oleh GN⁺ 2026-04-11 | 1 komentar | Bagikan ke WhatsApp
  • 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)
Iklan

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
    Iklan
  • 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
    Iklan
  • 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

Bacaan terkait

1 komentar

 
GN⁺ 2026-04-11
Komentar Hacker News

  • Rasanya terlalu banyak langkah yang harus dilalui untuk memakai CI GitHub dengan aman
    Dengan struktur seperti ini, saya merasa mustahil untuk mengoperasikannya secara aman dari sisi keamanan
    Membangun keamanan supply chain di atas sistem yang bahkan tidak mematuhi prinsip dasar seperti pemisahan hak akses atau isolasi terasa tidak realistis

    • Saya juga berpikir serupa. Baru-baru ini saya meneliti cara menjalankan kode yang ditulis agen dengan aman di GitHub Actions, dan cukup berhasil dengan sandbox-action
      Tapi konfigurasinya terlalu rumit, jadi tidak terlihat sebagai pendekatan yang skalabel. Akan jauh lebih baik kalau default-nya dibuat lebih aman
    • Saya penasaran apakah ada sistem build alternatif yang layak dipakai sebagai pengganti kompleksitas GitHub CI ini
      Setelah membaca seluruh artikelnya, saya jadi berpikir bahwa kompleksitas seperti ini mungkin memang masalah yang melekat di ranah ini
    • Sebenarnya ini tidak berbeda dari masalah umum di package registry
      Kebanyakan tidak mendukung rilis immutable, dan sekalipun mendukung, strukturnya sering otomatis menarik versi baru sehingga rentan terhadap serangan
      Agar benar-benar aman, dependensi yang sudah diverifikasi harus dikelola di registry internal sendiri dengan versi yang dipatok, tetapi itu realistisnya hanya bisa dilakukan perusahaan sekelas Google

  • Binary uv dari stagex yang dibuat tim kami adalah satu-satunya di dunia yang dibangun dengan bootstrap penuh dari source dan artefak deterministik yang ditandatangani multi-signature
    Kami menggunakan skema tanda tangan berbasis smart card yang terhubung ke web of trust berusia 25 tahun dan lebih dari 5000 kunci
    Tapi tetap menjengkelkan bahwa justru para relawan yang lebih serius mengerjakan keamanan supply chain seperti ini

    • Pasar sebenarnya sudah memberi jawabannya. Orang-orang menginginkan kemudahan, bukan keamanan
      Bahkan kalau alat seperti OpenClaw membuat kunci dan rahasia bocor, pengguna tetap memakainya
      Anda berusaha mengurangi attack surface, sementara pasar justru memperluasnya
    • Sebenarnya tidak perlu kesal. Anda sedang membuat distro Linux yang reproducible, dan mitra Anda menjual layanan dukungan di atasnya
      Tanpa relawan, proyek seperti Debian juga tidak akan ada. Daripada mengeluh, lebih baik bersaing dengan hasil yang lebih baik
    • (Saya penulis TFA) Jumlah atau usia kunci bukan ukuran kepercayaan
      Kalau pada akhirnya Anda tetap menyediakan artefak hasil build pihak ketiga, maka threat model-nya tidak jelas
      Semua build uv berasal dari resolusi yang dikunci, dan kami menyediakan artefak yang sudah ditandatangani. Nilai commit yang ditandatangani dengan kumpulan identitas berbeda tidak begitu jelas
    • Lisensi open source sendiri memang dirancang agar perusahaan bisa memakainya secara gratis
      Tidak ada alasan bagi OpenAI untuk sengaja mengeluarkan uang demi memperkuat keamanan supply chain
    • Akuisisi itu baru terjadi beberapa minggu lalu, jadi akan lebih aneh kalau OpenAI langsung mengubah proses build-nya
      Saya paham kritik teknisnya, tetapi rasanya berlebihan jika langsung membebankan tanggung jawabnya ke OpenAI pada momen ini

  • Sebagai referensi, Trusted Publishing di PyPI diimplementasikan bersama oleh William Woodruff dan tim Trail of Bits

  • Saya ingin bertanya kepada tim Astral. Bagaimana kalian mengelola situasi ketika sudah berupaya sejauh ini tetapi tetap sangat bergantung pada GitHub itu sendiri?
    Jika GitHub diretas atau konfigurasi berubah karena bug, bagaimana kalian meresponsnya?

    • Kami juga berkomunikasi langsung dengan GitHub. Karena mereka adalah infrastruktur inti, kami memantau perubahan platform dengan saksama
    • GitHub memang penuh bug. Workflow gagal saat mencoba clone branch dari repositorinya sendiri pun sering terjadi

  • Ekosistem open source sangat tangguh, tetapi sandboxing kode pihak ketiga masih kurang
    Setiap kali memakai uv, kelebihannya memang kemudahan mengelola banyak versi Python, tetapi itu juga berarti ia berjalan di host machine tanpa isolasi, dan itu membuat saya tidak nyaman

    • Saya selalu memakai uv di dalam Docker. Dalam kondisi seperti itu, cukup praktis

  • Masalah besar dalam supply chain saat ini adalah banyak tool dan dependensi diunduh tanpa verifikasi asal-usul
    Karena itu saya sedang mengembangkan asfaload, solusi verifikasi file multi-signature yang open source
    Ini adalah struktur yang bisa mencegah insiden seperti axios

    • Bukankah itu memang tujuan dari release attestations? Lihat dokumentasi terkait
    • Arah pendekatannya tampak benar. Hanya saja, karena kode atau produknya belum dipublikasikan, sulit untuk menilainya
    • Menurut saya, daripada verifikasi penulis tertentu, akan lebih baik memeriksa semua kode dengan alat audit kode otomatis

  • Walaupun GitHub Actions dipatok ke commit SHA, tetap berbahaya jika action tersebut menarik dependensi lain
    Solusi yang benar-benar kuat adalah memiliki kode sendiri secara langsung di pipeline CI, atau melakukan fork lalu memeliharanya sendiri

    • Ini juga dibahas di artikelnya. Kami mengambil pendekatan defense in depth
      Semua action diaudit, dan jika ada dependensi yang bisa berubah, kami perbaiki atau ganti (saya dari Astral)
    • Keamanan selalu soal trade-off
      Mengelola seluruh stack sendiri memang paling aman, tetapi tidak realistis
      Mematok hash adalah penguatan keamanan yang nyaris gratis
      Pada akhirnya, yang penting adalah menyadari dengan jelas sampai sejauh mana Anda memberi kepercayaan
    • Bagaimanapun, jika memakai action pihak ketiga, Anda tetap harus membaca dan memverifikasi kodenya sendiri. Fork saja tidak otomatis menyelesaikan masalah

  • Melihat insiden Trivy dan litellm belakangan ini, jelas sekali kita butuh panduan keamanan proses rilis
    Saran di artikel ini praktis dan bisa langsung diterapkan
    Inti keamanan supply chain bergantung pada seberapa aman default dari platform yang kita andalkan

  • Ringkasannya sangat bagus. Sepertinya ini bisa menjadi referensi yang berguna untuk proyek open source lain juga

  • Saya memelihara repomatic, tool Python CLI sekaligus reusable workflow
    Sebagian besar praktik keamanan dalam artikel ini sudah disertakan sebagai default
    Tujuannya adalah menciptakan lingkungan di mana keamanan menjadi default
    Setelah membaca artikelnya, saya menambahkan pemeriksaan kebijakan persetujuan PR fork
    Detailnya bisa dilihat di repositori GitHub