AI sedang merusak dua budaya kerentanan

• Setelah Copy Fail diungkap, Hyunwoo Kim menilai perbaikan sebelumnya belum memadai dan membagikan patch pada hari yang sama, tetapi prosedur perbaikan terbuka-diam ala Linux terungkap lewat penemuan dari luar dan berujung pada berakhirnya embargo
• Di Linux, khususnya area jaringan, ada praktik membagikan dampak keamanan ke daftar tertutup sambil mempercepat perbaikan bug secara terbuka, dengan tujuan mempertahankan keberadaan kerentanan yang sebenarnya tetap dalam embargo selama beberapa hari
• Setelah orang lain menemukan perubahan publik tersebut, memahami dampak keamanannya, lalu mempublikasikannya, detail lengkapnya kemudian diungkap
• Karena AI menurunkan biaya untuk menilai makna keamanan dari tiap commit, menemukan kerentanan dari perbaikan yang dipublikasikan diam-diam menjadi lebih mudah dan rasio sinyal terhadap noise juga meningkat
• Praktik pengungkapan terkoordinasi 90 hari tradisional juga mulai melemah; dalam kasus ini, hanya 9 jam setelah laporan kerentanan ESP dari Kim, Kuan-Ting Chen juga melaporkannya secara independen, sehingga embargo yang sangat singkat mungkin menjadi arah yang lebih baik

---

Benturan antara Copy Fail dan praktik perbaikan keamanan Linux

• Setelah kerentanan Copy Fail dipublikasikan, Hyunwoo Kim menilai perbaikan sebelumnya belum cukup dan membagikan patch pada hari yang sama
• Kim mengikuti prosedur yang umum di Linux, khususnya di area jaringan
  • Dampak keamanan dibagikan ke daftar tertutup para insinyur keamanan Linux
  • Perbaikan bug dilakukan secara terbuka, diam-diam, dan cepat
  • Tujuannya adalah menjaga keberadaan kerentanan serius tetap dalam embargo selama beberapa hari, sementara hanya perbaikannya yang terlihat publik
• Setelah orang lain menemukan perubahan tersebut dan memahami dampak keamanannya, hal itu lalu dipublikasikan
• Karena kerentanannya dianggap sudah terungkap, embargo pun berakhir, dan detail lengkapnya kemudian dipublikasikan

Tekanan yang dibuat AI pada dua budaya kerentanan

• Budaya pengungkapan terkoordinasi

  • Saat menemukan bug keamanan, temuan itu diberitahukan secara privat kepada maintainer, lalu biasanya diberi waktu seperti 90 hari untuk memperbaikinya
  • Tujuannya adalah agar perbaikan lebih dulu didistribusikan sebelum kerentanannya diketahui luas

• Budaya “bug adalah bug”

  • Ini pendekatan yang sangat umum di Linux: jika kernel melakukan sesuatu yang seharusnya tidak dilakukan, diasumsikan seseorang dapat mengubahnya menjadi serangan
  • Perbaikannya dilakukan secepat mungkin tanpa menarik perhatian pada fakta bahwa itu adalah kerentanan
  • Di tengah banyaknya perubahan yang lewat, harapannya orang tidak menyadarinya, dan masih ada waktu untuk menambal sistem

• Risiko pendekatan perbaikan terbuka meningkat karena AI

  • Pendekatan ini sejak awal memang tidak pernah bekerja sempurna, tetapi menjadi masalah yang lebih besar ketika AI makin mahir menemukan kerentanan
  • Karena banyak perbaikan keamanan terus muncul, meninjau commit menjadi aktivitas yang semakin menarik dan rasio sinyal terhadap noise meningkat
  • Biaya bagi AI untuk menilai tiap commit saat melintas makin rendah, sementara efektivitasnya makin tinggi

• Embargo panjang juga mulai melemah

  • Di masa lalu, karena deteksi lambat, jika laporan dikirim ke vendor dan diberi jendela pengungkapan 90 hari, kemungkinan kecil orang lain akan menemukannya dalam masa itu
  • Kini asumsi itu melemah karena kelompok yang didukung AI memindai kerentanan perangkat lunak dalam skala besar
  • Dalam kasus ini, hanya 9 jam setelah Kim melaporkan kerentanan ESP, Kuan-Ting Chen juga melaporkannya secara independen
  • Embargo dapat menciptakan kesan tidak mendesak yang keliru, sekaligus membatasi pihak yang bisa memperbaiki cacat tersebut, sehingga berpotensi memperbesar risiko

• Arah yang mungkin dan uji model sederhana

  • Solusinya belum jelas, tetapi embargo yang sangat singkat tampak sebagai pendekatan yang baik, dan seiring waktu mungkin perlu makin dipersingkat
  • AI dapat mempercepat bukan hanya penyerang tetapi juga pihak bertahan, sehingga embargo yang dulu terlalu singkat untuk berguna bisa menjadi layak
  • Ketika f4c50a403 diberikan ke Gemini 3.1 Pro, ChatGPT-Thinking 5.5, dan Claude Opus 4.7, ketiganya langsung mengenalinya sebagai patch keamanan
  • Saat hanya diberi diff tanpa konteks commit, Gemini yakin itu adalah perbaikan keamanan, GPT menilai kemungkinan besar ya, sedangkan Claude menilai kemungkinan besar bukan
  • Uji ini hanyalah contoh sangat cepat dengan menjalankan tiap model sekali menggunakan prompt "Without searching, does this look like a security patch?", sehingga sulit memberi makna besar pada perbandingan antar model

[GN⁺]

Komentar Hacker News

• Perubahan ini sudah lama diperkirakan, dan bahkan sebelum kita tahu apa itu LLM, retakan yang terlihat sekarang sudah bisa diprediksi
  Katalisnya adalah meningkatnya transparansi perangkat lunak. Adopsi open source dan perangkat lunak dengan source-available meningkat pesat, dan kemampuan alat rekayasa balik serta dekompilasi juga membaik drastis. Era ketika perangkat lunak closed source komersial pada umumnya benar-benar tersembunyi secara berarti dari penyerang serius sudah berakhir lebih dari 10 tahun lalu
  Sejak BinDiff, masalah ini berkembang perlahan. Saat perangkat lunak ditambal, pada dasarnya kerentanannya juga ikut terungkap. Selama ini orang menyangkalnya karena butuh tingkat keahlian tertentu untuk menyadari bahwa patch berarti pengungkapan kerentanan, tetapi AI menghapus alasan itu
  Sekarang, setiap kali sesuatu di-merge ke mainline Linux, beberapa organisasi memasukkan diff tersebut ke prompt LLM, menilai secara agresif apakah itu perbaikan kerentanan, dan menghasilkan panduan eksploitasi. Hal yang sama kemungkinan segera terjadi pada sebagian besar proyek open source besar seperti nginx, OpenSSL, dan Postgres
  Praktik coordinated disclosure tidak dirancang untuk lingkungan seperti ini, dan sebenarnya menurut saya juga sudah tidak cocok selama 10 tahun terakhir
  Anehnya saya tidak terlalu terganggu oleh situasi ini, karena praktik coordinated disclosure selalu menerima begitu saja asumsi bahwa menunda pengungkapan demi kenyamanan operasional admin sistem adalah hal yang baik. Asumsi itu patut dipertanyakan. Menunda pengungkapan juga merampas informasi dari operator sistem yang sebenarnya punya pilihan lain selain sekadar memasang patch

  • Pernyataan bahwa “era ketika perangkat lunak closed source komersial pada umumnya benar-benar tersembunyi secara berarti dari penyerang serius sudah berakhir lebih dari 10 tahun lalu” hampir terasa jelas, tetapi garis pertahanan terakhir adalah tidak mendistribusikan perangkat lunaknya dan bergantung pada arsitektur server-klien
    Jika kerentanan makin mudah dideteksi dan dieksploitasi, pendekatan seperti ini bisa jadi makin umum. Tentu saja, ini tidak selalu memungkinkan
    Selama 11 tahun terakhir, cukup menjengkelkan melihat binary klien game yang diobfuscate dengan ProGuard didekompilasi berkali-kali dan diunggah ke GitHub. Hanya kode server yang tidak didistribusikan yang tetap privat
    Menariknya, sampai protokol jaringan diubah lebih jarang dari seminggu sekali, tidak ada masalah dengan penyerang yang merekayasa baliknya. Sekarang, penyerang yang dibantu LLM tampaknya juga bisa mengikuti kecepatan itu
  • Saya selalu paham alasan bisnis di balik coordinated vulnerability disclosure, dan di tempat kerja saya juga harus mengikuti kebijakan itu, tetapi secara pribadi saya selalu berada di kubu full disclosure. Saya sudah lama menunggu perubahan ini

• Ini tampaknya bukan masalah AI yang benar-benar baru, melainkan lebih seperti masalah lama yang dikemas ulang sebagai masalah AI
  Jauh sebelum LLM muncul, orang sudah membandingkan diff commit kernel untuk mencari mana yang merupakan perbaikan keamanan. Begitu patch diposting secara publik, perlombaannya pada dasarnya sudah dimulai
  Saya juga tidak yakin mempersingkat masa embargo benar-benar membantu. Organisasi yang bisa melakukan patch dalam hitungan jam sudah baik-baik saja, dan yang lain tetap butuh beberapa hari atau minggu
  Justru semakin murah biaya pembuatan exploit, coordinated disclosure mungkin bukan menjadi kurang penting, melainkan lebih penting

  • Memang benar bahwa “orang sudah membandingkan diff commit kernel untuk mencari mana yang merupakan perbaikan keamanan”, tetapi itu butuh keterampilan dan biasanya tidak dilakukan secara konsisten maupun sistematis. Dengan AI, siapa pun bisa melakukannya pada perangkat lunak apa pun
    Soal “tidak yakin mempersingkat masa embargo membantu”, inti pertanyaannya adalah kenapa 90 hari dan bukan 2 tahun. Argumen tulisan ini adalah bahwa meningkatnya frekuensi penemuan simultan telah mengubah faktor-faktor yang dulu menentukan keseimbangan itu. Jika banyak orang di luar embargo pada akhirnya juga akan menemukan exploit-nya, maka masa embargo bukan jendela nyata, melainkan ilusi
    Saya setuju bahwa “eksploitasi murah membuat coordinated disclosure lebih penting”. Tetapi pada saat yang sama, itu juga membuatnya kurang layak dijalankan. Jika script kiddie pun bisa menemukan dan mengeksploitasi zero-day, kapasitas untuk melakukan koordinasi runtuh
    Budaya whitehat selalu punya semacam etika guild pengrajin. Jika guild itu pecah, etika itu juga kehilangan pijakan
  • Saya tidak mengikuti seluruh perkembangan Linux secara terus-menerus, tetapi saya tidak tahu apakah dulu pernah ada kasus eksploitasi yang berfungsi dipublikasikan di mailing list bahkan sebelum patch masuk ke kernel
    Saya belum pernah melihat itu, dan bahkan dengan mempertimbangkan nuansa yang agak sensasional, sekarang saya mendapat kesan bahwa hal seperti ini akan sering terjadi berkat LLM
  • Torvalds mengatakan bahwa ketika masalah besar ditemukan, tidak perlu ada keributan susulan; mengungkap bug itu sendiri sudah cukup [1]
    Karena itu, tidak mengejutkan bahwa Dirtyfrag dipublikasikan sebagai perubahan kernel Linux [2]
    [1] https://www.zdnet.com/article/torvalds-criticises-the-securi...
    [2] https://afflicted.sh/blog/posts/copy-fail-2.html
  • Lebih tepat jika dibilang ini adalah masalah lama yang diperparah oleh AI
  • Rasanya saya menulis variasi dari hal yang sama setiap minggu, jadi jika boleh malas, saya akan membagikan versi yang pernah saya tulis sebelumnya
    https://news.ycombinator.com/item?id=47921829

• Ada masalah besar
  Amerika Serikat sedang berperang, dan sebagian besar dunia saat ini juga menjalankan perang setingkat serangan siber. Amerika Serikat, UE, sebagian besar Timur Tengah, Israel, dan Rusia termasuk di dalamnya
  Layanan penting seperti Ubuntu, GitHub, Let’s Encrypt, dan Stryker pernah diserang hingga down berhari-hari, dan seluruh sistem rumah sakit juga sempat lumpuh sebagian
  Di tengah situasi ini, AI membuat kecepatan pembuatan serangan jauh lebih cepat. Lebih cepat daripada kecepatan pihak bertahan merespons. Dulu serangan zero-day jarang terjadi, sekarang sudah jadi hal biasa
  Keadaan akan memburuk sebelum membaik, dan mungkin bisa jauh lebih buruk

  • Saya tidak tahu bagaimana ini bisa membaik

• Bagian yang mengatakan “sekarang ada begitu banyak perbaikan keamanan sehingga menjadi lebih menarik untuk memeriksa commit. Rasio sinyal terhadap noise lebih tinggi” terasa patut dipertanyakan
  Bagian pentingnya adalah “biaya AI untuk mengevaluasi tiap commit yang lewat makin murah dan makin efektif”. Dengan AI, asumsi bahwa “perubahannya terlalu banyak sehingga orang tidak akan sadar” runtuh

• Pengujian cepat ini tidak menunjukkan banyak hal. Jika Anda langsung bertanya “apakah ini patch keamanan?”, Anda menyiratkan dan mengarahkan AI untuk menghasilkan keluaran yang menyetujui premis itu
  Confusion matrix akan lebih berguna. Tentu saja, saya paham tulisan ini bukan posting uji kemampuan AI yang rinci

  • Saya setuju bahwa ini bukan bukti tambahan yang besar. Akan sangat menarik jika seseorang menjalankan pengujian yang sama pada N commit dari daftar itu, termasuk commit ini
  • Secara ideal, yang dibutuhkan adalah koefisien phi, yaitu MCC, yang bisa dihitung dari confusion matrix hasil klasifikasi ya/tidak oleh LLM terhadap seluruh diff kernel
    Ini bisa dihitung dari jumlah true positive, true negative, false positive, dan false negative

• Kita membutuhkan siklus patch dan rilis otomatis
  Sampai sekarang, kita mengandalkan proses manual yang luar biasa lambat: menerima laporan, menyelidiki, memverifikasi, menambal, lalu menyiapkan rilis. Sangat umum butuh berbulan-bulan untuk mengeluarkan perbaikan. Itu terlalu lambat di era ketika penyerang bisa memuntahkan exploit baru dalam hitungan jam
  Jika ingin mengurangi mean time to patch, kita harus berulang kali memperbaiki bottleneck di seluruh rantai nilai
  Setelah menerima laporan bug, kita seharusnya bisa menghasilkan produk yang sudah ditambal dan siap diuji QA dalam waktu 1 jam. Ini perlu distandardisasi atau dijadikan open source, lalu dipakai di seluruh rantai pasok perangkat lunak: kernel Linux → distro → produk yang memakai distro → pengguna. Dengan AI, tidak ada alasan ini tidak bisa dilakukan; kita hanya lambat

• AI akan memangkas jendela pembaruan secara dramatis. Memikirkan cooldown dependensi pada 2026 adalah pendekatan terburuk; sekarang kita justru harus memikirkan pemanasan dependensi
  Sebentar lagi, konsep cara mengungkap kerentanan dengan aman di proyek open source akan hilang. SaaS terpusat akan punya keunggulan keamanan besar di sini

  • SaaS terpusat closed source akan punya keunggulan keamanan besar
    Kerentanan remote code execution pada dependensi open source berarti semuanya sama-sama rentan pada saat patch keamanannya dipublikasikan, jadi saya tidak paham kenapa ini masih diperdebatkan
  • Organisasi yang memakai Linux juga bisa membentuk web of trust dengan masing-masing mengeluarkan biaya tertentu untuk terus memindai dan menambal dependensinya memakai AI, lalu saling mengirim patch dan hasil pemindaian

• Ucapan lama Tony Hoare tentang “tidak adanya bug yang jelas” dan “secara jelas bebas dari bug” terasa lebih tepat dari sebelumnya di era LLM

• Penjelasan yang memperlakukan bug sekadar sebagai bug secara pribadi terasa cukup tidak masuk akal bagi saya, tetapi saya tahu di dunia Linux ada banyak orang yang lebih mementingkan prinsip daripada masalah praktis
  Meski begitu, 90 hari terasa lama
  Pada akhirnya, perusahaan AI besar tampaknya perlu membantu orang-orang yang mengelola infrastruktur inti internet. Menjalankan AI terbaru dan terbaik pada hal-hal seperti nginx menurut saya adalah keuntungan kolektif bagi kita semua

• Bagian yang mengatakan “untungnya AI bisa mempercepat pihak bertahan sama seperti penyerang di sini, sehingga masa embargo yang sebelumnya terlalu pendek untuk berguna jadi bisa dijalankan” adalah aspek penting dari ruang masalah ini
  Risiko keamanan pada akhirnya bisa berubah menjadi perlombaan senjata soal siapa yang mampu membelanjakan lebih banyak biaya token

  • Yang menarik, ini berarti kode closed source menjadi aset yang lebih besar bagi pihak bertahan
    Penyerang tidak bisa menghabiskan token di sana, tetapi pihak bertahan bisa membelanjakan token untuk pekerjaan hardening berdasarkan source code. Penyerang jadi terikat pada pengujian black-box saja