Surat terbuka Akrites untuk bersama-sama menjaga keamanan open source

• Seiring penemuan kerentanan berbasis AI melampaui kecepatan respons para maintainer, Akrites diluncurkan sebagai kolaborasi industri untuk bersama-sama memperkuat perangkat lunak open source inti
• Menemukan kerentanan serius dulu membutuhkan waktu berminggu-minggu bagi para ahli, tetapi kini model AI dapat menemukan beberapa kerentanan hanya dalam hitungan menit, sehingga beban respons meningkat tajam
• AWS, Anthropic, Chainguard, Cisco, Citi, Ericsson, Google, IBM, Microsoft dan GitHub, NVIDIA, OpenAI, Red Hat, Rust Foundation, dan lainnya akan mengoordinasikan perbaikan upstream serta pengungkapan yang bertanggung jawab
• Untuk mengurangi laporan duplikat dan patch yang saling bertentangan, Akrites menyediakan titik koordinasi rahasia dan Security Incident Response Team khusus, serta menjadi maintainer pilihan terakhir untuk paket inti yang tidak memiliki maintainer
• Karena setelah patch dipublikasikan penyerang dapat menggunakan AI untuk merekayasa balik kerentanannya, ukuran keberhasilan bukanlah publikasi itu sendiri, melainkan patch benar-benar didistribusikan sampai ke sistem nyata

---

Kecepatan keamanan open source yang diubah oleh AI

• Open source menjadi fondasi infrastruktur dan layanan penting yang diandalkan orang setiap hari, seperti perbankan, telekomunikasi, dan utilitas
• Karena komponen open source yang sama digunakan luas di seluruh tech stack, banyak sistem akhirnya berbagi potensi cacat yang sama
• AI mengubah keseimbangan antara penyerang dan pembela, serta menurunkan struktur biaya untuk menemukan dan menggunakan kembali kerentanan
  • Menemukan kerentanan serius dulu membutuhkan waktu berminggu-minggu bagi para ahli, tetapi kini mesin dapat melakukannya hanya dalam hitungan menit
  • Ada juga kasus ketika model AI mengembalikan beberapa kerentanan dalam satu kali eksekusi
  • Kemampuan yang sama juga dapat digunakan untuk pertahanan, tetapi jika disalahgunakan, penemuan kerentanan dapat menjadi terpipeline

Struktur laporan duplikat yang menekan maintainer

• Proses respons keamanan dan pengungkapan yang ada selama ini berjalan dengan berbagai organisasi dan tim yang bergerak secara longgar dan terpisah, sehingga masalah yang sama bisa ditangani secara bersamaan atau memunculkan patch yang saling bertentangan dan banyak laporan
• Jika puluhan perusahaan memindai library yang sama secara independen lalu masing-masing mengirimkan laporan, maintainer akan tenggelam dalam derau
• Semakin banyak pihak yang mengetahui kerentanan yang belum dipatch, semakin besar pula kemungkinan kebocoran sebelum perbaikan, dan risiko itu menyebar ke seluruh ekosistem
• Respons dengan niat baik tetapi tanpa koordinasi pun dapat memperburuk masalah dan membuang waktu

Cara respons bersama Akrites

• Akrites diluncurkan sebagai upaya untuk mendistribusikan sistem dan alat bersama guna menemukan, memperbaiki, dan mengungkapkan secara bertanggung jawab kerentanan pada perangkat lunak open source inti
• Para pesertanya meliputi Amazon Web Services, Anthropic, Chainguard, Cisco, Citi, Endor Labs, Ericsson, Google, IBM, JPMorganChase, Microsoft dan GitHub, NVIDIA, OpenAI, RapidFort, Red Hat, Rust Foundation, Sonatype, Vodafone, Zscaler, dan lainnya
• Pusat responsnya adalah upstream yang memiliki maintainer
  • Menyediakan satu tempat berbasis kerahasiaan dan kepercayaan untuk mengoordinasikan penemuan, perbaikan, dan pengungkapan kerentanan
  • Security Incident Response Team khusus menjadi satu mitra yang dapat diprediksi bagi maintainer, alih-alih banyak laporan yang tidak terkoordinasi
  • Perbaikan diarahkan kembali ke repositori asli dan alur maintainer tiap proyek
• Jika paket inti tidak memiliki maintainer, Akrites menyatakan akan mengambil peran sebagai maintainer pilihan terakhir agar perbaikan dapat tersampaikan tepat waktu

Mengapa distribusi lebih penting daripada publikasi patch

• Ketika patch dipublikasikan, penyerang dapat menggunakan AI untuk dengan cepat merekayasa balik kerentanan sebenarnya, mengembangkan exploit, dan memulai serangan
• Karena itu, keberhasilan Akrites harus diukur bukan dari apakah patch telah dipublikasikan, melainkan apakah patch tersebut sudah didistribusikan ke sistem nyata
• Akrites berupaya meningkatkan tingkat koordinasi dengan bekerja sama dengan pemilik dan operator infrastruktur penting, upaya masyarakat sipil, serta pemerintah
• Kerahasiaan bukan sesuatu yang bisa dinegosiasikan, dan karena cacat yang belum diungkap pada paket yang didistribusikan luas pada dasarnya seperti senjata, pencegahan kebocoran menjadi prioritas

Beban dan komitmen yang ditekankan organisasi peserta

• Endor Labs menyatakan bahwa dari ribuan kerentanan open source yang teridentifikasi dalam beberapa bulan terakhir, proporsi yang telah dipatch kurang dari 5%
• OpenInfra menyatakan bahwa komunitas OpenStack telah menerbitkan 20 advisory keamanan hanya pada kuartal ini, sementara sepanjang 2025 jumlahnya 2
• JPMorganChase melihat bahwa karena AI telah memangkas waktu antara penemuan dan eksploitasi kerentanan hingga hampir real-time, waktu dari perbaikan hingga distribusi juga harus dipersingkat
• Chainguard, Sonatype, RapidFort, Red Hat, dan lainnya menyatakan bahwa perbaikan kerentanan sebaiknya dilakukan melalui koordinasi upstream dalam alur perangkat lunak asli dan maintainer, bukan tersebar dalam fork atau di balik tembok yang diprivatisasi
• Organisasi peserta berkomitmen mengerahkan tenaga engineering, keahlian keamanan, pendanaan, dan teknologi AI untuk memperkuat perangkat lunak bersama

[GN⁺]

Komentar Hacker News

• Banyak pihak yang terlibat di open source hampir pasti akan skeptis melihat daftar perusahaan yang berpartisipasi ini, dan itu wajar
  Intinya adalah bagaimana mewujudkan “menemukan dan memperbaiki kerentanan pada perangkat lunak open source penting lalu mengungkapkannya secara bertanggung jawab”. Jika berkontribusi lewat kanal yang sudah ada dan pull request, mereka bisa berjalan bersama komunitas, tetapi jika melakukan fork dengan dalih ‘keamanan’, itu bisa menyingkirkan komunitas, memecah sumber daya, dan dalam jangka panjang membunuh banyak proyek. Bug bounty punya potensi, tetapi untuk bug kritis, kecepatan dan waktu pengungkapannya bisa tidak cocok, dan dukungan pendanaan juga dampaknya terbatas jika tidak digabungkan dengan dukungan untuk maintainer

  • Saya dipekerjakan oleh Linux Foundation, tetapi tidak tahu kondisi internal proyek ini; sebagai gantinya, saya bisa menjelaskan apa yang dilakukan proyek-proyek yang saya dukung: program HackerOne sedang dikurangi karena lebih banyak noise daripada sinyal
    PQCA memberi akses ke hardware melalui kredit AWS untuk menjalankan pembuktian dan CI, serta juga menjalankan mentorship berbayar. OWF juga menyediakan kredit AWS dan hosting layanan untuk pengujian. LFDT telah menyediakan mentorship berbayar, biaya review oleh Trail of Bits, operasional acara, maintainer summit di New York, dukungan untuk runner GitHub CI berukuran besar, dan lainnya. Tim kami, dari sudut pandang developer relations OWF/PQCA/LFDT, hanya terdiri dari 3 pegawai penuh waktu, 1 kontraktor, dan 1 manajer, tetapi kami bekerja cukup keras untuk membantu para developer
    LFDT: https://www.lfdecentralizedtrust.org/
    OWF: https://openwallet.foundation/
    PQCA: https://pqca.org/
    Contoh benchmark PQCA: https://pq-code-package.github.io/mldsa-native/dev/bench/
  • Pikiran pertama saya saat melihat siapa yang ikut dan apa yang ingin mereka lakukan juga sama. Barang bersama tidak boleh jatuh ke tangan perusahaan yang mencari untung
    Apa pun bentuknya, ini harus terdesentralisasi agar tidak ada satu lokasi pusat atau satu entitas tunggal yang bisa menjalankan kendali
  • Aneh kalau berbicara seolah-olah “perusahaan-perusahaan ini bukan bagian dari pihak open source”. Open source bukan klub eksklusif
  • Dari yang saya baca, saya memahaminya sebagai berkontribusi dengan cara yang sudah ada jika memungkinkan, dan mengambil langkah terpisah jika memang diperlukan. Jika ini Linux Foundation, maka tentu harus mengutamakan open source dan komunitas
    Mereka memang bicara soal kontribusi pendanaan, tetapi bagaimana dan untuk apa itu diberikan juga penting. Kebanyakan proyek belum siap menerima atau memanfaatkan donasi. Namun akan bagus jika semua proyek open source bisa mendapat akses AI yang cukup besar untuk meninjau codebase dan pull request sehingga beban pemeliharaan berkurang, dan beberapa upaya seperti itu memang sudah ada

• Ini cuma aksi pencitraan korporat
  Microsoft bilang akan “menyumbangkan keahlian, sumber daya, dan teknologi AI untuk secara bertanggung jawab mengidentifikasi dan memperbaiki kerentanan”, tetapi Microsoft mengoperasikan NPM dan GitHub serta punya akses ke model AI terbaik dan data center yang sangat besar. Meski begitu, keamanan produk mereka sendiri memburuk dengan cepat, dan layanan-layanannya menjadi hub utama tempat berbagai exploit menyebar
  Jika ingin melihat bagaimana Microsoft menangani masalah keamanan di proyek open source miliknya sendiri, saya merekomendasikan thread GitHub ini: https://github.com/dotnet/efcore/issues/38257
  EF Core saat ini mendistribusikan versi SQLite yang memiliki kerentanan serius. Masalah ini ditemukan lebih dari setahun lalu, dan SQLite memperbaikinya dalam waktu seminggu, tetapi EF Core tidak menandai drivernya sebagai rentan sampai baru-baru ini ketika seorang pengguna melaporkannya lagi dan berdebat dengan para developer. Perbaikan untuk versi stabil .NET Core saat ini diperkirakan baru akan masuk sekitar dua bulan lagi

  • Menyebut CVE-2025-70873 sebagai kerentanan serius tampak agak berlebihan. Itu hanya berlaku jika penyerang diizinkan membuat sistem mengambil file ZIP sembarang, jadi selama pengguna tidak dibuat mengimpor file ZIP sembarang, itu tidak terlalu serius
  • Sebelum diakuisisi Microsoft, GitHub bahkan membuat Electron karena ingin membangun IDE dengan JavaScript, dan itu menyenangkan, lalu akhirnya menjadi sesuatu yang berguna dalam bentuk yang sama sekali berbeda. Inovasi teknis memang terjadi seperti itu
    Setelah akuisisi, alih-alih melanjutkan arus itu dengan VSCode, Microsoft malah menciptakan suasana yang meremehkan Electron, dan sekarang banyak orang membenci Electron tanpa bisa menjelaskan alasannya. VSCode juga tidak mem-fork Atom, melainkan membuat sesuatu yang serupa dari nol, hasilnya lebih besar dan lebih lambat, dan sekarang bahkan ditambah Copilot. Saya akhirnya kembali ke Pulsar, fork Atom yang bagus
    Microsoft selalu melihat peluang dan dinamika persaingan saat mengakuisisi, tetapi jarang benar-benar memanfaatkan apa yang dibelinya dengan baik. Polanya adalah menyingkirkan karyawan bagus dan kode bagus lalu merusak produknya. Saya tidak mengerti kenapa semua orang masih terus memakai produk Microsoft. Kita harus meninggalkan LinkedIn dan pindah bersama ke sistem version control lain. Selama developer open source tidak menunjukkan tindakan, bukan cuma kata-kata, Microsoft akan terus menjadi lebih buruk

• Kami tidak akan melakukan itu. Hanya membuat deklarasi besar, lalu membiarkan perusahaan komersial merusaknya, dan kemudian mengeluh keras tentang keadaan seolah-olah kami sendiri tidak melakukan apa-apa
  Ke depannya, sepertinya akan muncul arus yang saya sebut undo fork. Ini adalah fork untuk kembali berpikir lagi ke titik sebelum kegilaan dimulai, sesuatu yang hanya bisa dilakukan oleh orang-orang yang tidak terikat pada tuntutan komersial

  • Dalam beberapa hal, pergeseran ini sudah dimulai sejak momen berpindah dari Free Software ke Open Source, dan lajunya tidak melambat
  • Lebih buruk lagi. Open source bisa dikuasai oleh perusahaan pemasaran yang penuh gembar-gembor, dan menjadi sarana untuk mengekstrak tenaga kerja gratis demi membuat apa yang mereka inginkan, bukan apa yang kita inginkan
  • 95% open source yang berguna dibuat atau dipelihara oleh perusahaan komersial. Linux, Postgres, dan yang semacam itu termasuk di sini, tidak menghitung utilitas-utilitas kecil
  • Linux Foundation saat ini pada dasarnya mirip perusahaan global lain dengan agenda politik. Jika mengikuti aliran uangnya, terlihat bahwa perusahaan-perusahaanlah yang mengendalikannya, mereka telah melumpuhkan Torvalds, dan bekerja bersama mereka pun hampir selalu terasa seperti mimpi buruk
    Saya selalu menyarankan orang yang tertarik pada open source untuk menjauhi Linux Foundation. Akhir-akhir ini, lembaga itu lebih menjadi penghalang daripada pendukung kebebasan perangkat lunak

• Untuk menjaga open source, kita harus mulai bukan dari kata-kata, melainkan dari dukungan nyata kepada proyek dan pengembang
  Dari sudut pandang pengembang OpenBSD, menyediakan perangkat keras baru untuk pengembang itu sangat penting. Banyak pengembang masih bekerja dengan ThinkPad berusia 5–10 tahun yang sudah perlu diganti
  https://www.openbsd.org/want.html
  OpenBSD Foundation masih kekurangan sekitar 50% untuk mencapai target penggalangan dana 2026
  https://www.openbsdfoundation.org/campaign2026.html

  • Selain mendanai proyek open source yang digunakan, akan bagus juga kalau bisa mendukung langsung kontributor dan pengembang individu yang bekerja di proyek itu. Banyak dari mereka adalah relawan, dan dukungan bulanan kecil pun bisa membuat perbedaan besar
    https://brynet.ca/wallofpizza.html
  • Saya ingin membeli beberapa YubiKey untuk melindungi kunci GPG yang bisa dipakai mengunggah ke Debian, tetapi kalau memang perlu, sepertinya saya harus membelinya dengan uang saya sendiri

• Pada bagian “Amazon Web Services ikut serta,” semua kredibilitas tulisan ini langsung hilang

• Ini terbaca sebagai upaya sentralisasi dan kontrol. Siapa pun Akrites, ini hanya akan memberi perusahaan teknologi besar termasuk Google kekuatan untuk mengendalikan open source
  Terima kasih, tapi tidak. Saya masih ingat Google berusaha memblokir instalasi pihak ketiga melalui .apk di Android September ini

  • Kekhawatirannya sama. Jika paket open source penting menjadi bergantung pada rilis “keamanan” dari perusahaan-perusahaan ini, bukankah itu berarti mereka nantinya bisa memaksakan verifikasi identitas pada paket tersebut?
    Terkait hal itu, kebanyakan orang pintar yang saya kenal melihat open source AI sebagai sesuatu yang membuat Anthropic dan OpenAI tidak layak secara finansial. Banyak perusahaan yang mencantumkan namanya di sini punya keterkaitan besar dengan kedua perusahaan itu, dan mereka punya insentif untuk mengguncang open source AI sebelum pelanggan mereka merasakan kejutan harga. Saya sudah menunggu langkah mereka berikutnya, dan ini mungkin bagian darinya

• Informasi yang paling penting adalah bagian yang mengatakan para peserta akan menyumbangkan sumber daya engineering
  Kita harus lihat dulu apakah itu akan berjalan sesuai rencana. Selain itu, saya tidak terlalu terkesan dengan klaim proyek ini. Strukturnya menguntungkan sentralisasi dan jaringan yang berpusat pada korporasi, sehingga berlawanan total dengan arah yang didorong etika peretas untuk alasan yang baik

  • Ini tidak terlihat inklusif. Tampak seperti satu lapisan lagi yang memusatkan kerentanan yang masuk, mengumpulkan informasi, dan menanganinya secara rahasia
    Ini juga bisa menjadi sumber tekanan tambahan. Mungkin mereka memang bisa menyaring kerentanan nyata dengan baik, tetapi hasilnya tetap akan didorong ke maintainer sebagai prioritas tinggi. Banyak maintainer sudah kelelahan bahkan tanpa kebisingan AI, dan meskipun patch disediakan, tetap saja perlu review
    Dalam skenario terbaik, ini bisa mengurangi kebisingan, tetapi pekerjaannya sendiri tetap ada. Industri secara umum perlu mendanai proyek open source agar mereka punya otoritas untuk menanganinya sendiri. Kemungkinan itu juga yang terbaik untuk kualitas. Jika memang perlu menyaring kebisingan AI, tambahkan saja fungsi itu, tetapi jangan buat struktur rahasia dan tidak transparan yang mengontrol semuanya
  • Singkatnya, ini terlihat seperti kolaborasi palsu di mana perusahaan-perusahaan menyita waktu tanpa memberi apa pun kembali. Saya setuju bahwa ini berlawanan total dengan apa yang didorong etika peretas

• Saya menunggu hari ketika melihat judul seperti, “Kita semua bergantung pada open source. Kita akan mendanainya bersama”

  • Cukup banyak perusahaan besar sebenarnya sudah “mendanai open source” dengan mempekerjakan karyawan untuk ikut berkontribusi. Misalnya, itu bisa dilihat dari alamat email perusahaan yang muncul di LKML

• Saya suka nama “Akrites”
  Bagi orang non-Yunani mungkin kurang berkesan, tetapi bagi orang Yunani ini memberi citra yang cukup kuat

  • Ringkasnya bagi yang ingin mencari tahu, akritai adalah sebutan untuk prajurit perbatasan yang menjaga wilayah timur Kekaisaran Bizantium pada abad ke-9 hingga ke-11
    akron berarti tepi atau perbatasan, jadi kira-kira berarti “orang perbatasan”. Poin pentingnya adalah kita tidak bisa begitu saja memproyeksikan konflik atau prasangka modern ke sejarah seribu tahun lalu. Dalam konteks sejarah, ini mirip banyak perbatasan antara peradaban yang berbeda, dan yang penting adalah bahwa mereka merupakan organisasi kelompok yang berkumpul untuk mempertahankan tanah mereka sendiri
  • Contoh yang lebih baru adalah pidato Davos Mark Carney. Khususnya bagian “kekuatan menengah harus bertindak bersama. Jika kita tidak duduk di meja, kita akan ada di menu” yang teringat
    [1] https://en.wikipedia.org/wiki/Mark_Carney%27s_Davos_speech

• Menurut saya, memposting hal seperti ini di Hacker News tidak banyak artinya. Mayoritas orang di sini sangat menerima gelombang AI dan tidak terlalu peduli
  Selain itu, banyak perusahaan dalam daftar itu justru menjadi tersangka utama atas kondisi open source saat ini

  • Saya tidak menerima sampah AI, dan juga kurang paham dari mana kesimpulan itu berasal. Sebagian besar komentar justru cukup menentang sampah AI
    Namun, saya setuju bahwa banyak perusahaan dalam daftar itu adalah tersangka utama atas kondisi open source. Ini terlihat seperti iklan promosi untuk whitewashing perusahaan-perusahaan tersebut, dan sulit dipercaya bahwa mereka benar-benar peduli pada etika open source