Laporan kerentanan tidak lagi istimewa

• Dalam pemeliharaan open source, issue dan PR biasa bisa ditangani secara opsional, tetapi di masa lalu laporan kerentanan adalah pengecualian yang memerlukan penanganan khusus demi melindungi pengguna
• Keistimewaan itu berasal dari wawasan langka dan kerahasiaan yang memberi peneliti kesempatan untuk memperbaiki lebih dulu sebelum penyerang, dan proyek membalasnya dengan respons cepat, investigasi, berbagi progres, serta pemberian kredit
• Pada 2026, baik maintainer maupun penyerang sama-sama bisa menjalankan LLM, sehingga bottleneck berpindah dari menemukan isu potensial ke menyaring kerentanan yang benar-benar nyata
• Peneliti eksternal tanpa hubungan kepercayaan sulit memberi kontribusi besar dalam penyaringan, dan rasio sinyal terhadap noise saat meninjau output LLM menjadi mirip dengan meninjau kotak masuk security@
• Waktu maintainer seharusnya lebih banyak digunakan untuk klasifikasi, perbaikan cepat, dan pencegahan daripada sekadar merespons laporan, serta dibutuhkan cara untuk menjalankan analisis LLM di CI

---

Mengapa laporan kerentanan dulu menjadi pengecualian

• Maintainer open source yang bekerja secara terbuka menerima issue, PR, dan masukan seperti hadiah, lalu dapat memilih untuk menerimanya, mengabaikannya, atau hanya memanfaatkan sebagian sesuai kebutuhan
• Laporan kerentanan di masa lalu adalah kasus khusus yang menyimpang dari prinsip ini
  • Peneliti keamanan memilih pelaporan privat alih-alih langsung memublikasikannya agar proyek punya waktu memperbaiki lebih dulu
  • Umumnya ada ekspektasi bahwa proyek akan segera mengonfirmasi laporan, menyelidikinya, membagikan perkembangan kepada pelapor, dan pada akhirnya memberi kredit atas penemuannya
• Ekspektasi ini muncul dari anggapan bahwa pelapor bukanlah orang yang menuntut perbaikan bug atau implementasi fitur, melainkan pihak yang memberikan layanan kepada proyek
  • Nilai utamanya adalah wawasan dan kerahasiaan yang memungkinkan patch dirilis sebelum penyerang meluncurkan exploit
  • Mengabaikan laporan kerentanan dipandang sebagai sinyal bahwa proyek tidak peduli pada keamanan pengguna

Asumsi yang runtuh pada 2026

• Pada 2026, asumsi yang membuat laporan kerentanan terasa istimewa makin sulit dipertahankan
  • LLM bekerja hampir sebaik sebagian besar peneliti keamanan, dan siapa pun bisa menjalankannya
  • Alat yang sama bisa dijalankan oleh maintainer maupun penyerang
• Yang langka bukan lagi kemampuan menemukan isu potensial, melainkan pekerjaan klasifikasi untuk menentukan mana yang benar-benar merupakan kerentanan
• Peneliti eksternal tanpa hubungan kepercayaan sebelumnya sulit berkontribusi secara bermakna pada proses klasifikasi ini
  • Rasio sinyal terhadap noise saat meninjau keluaran LLM hampir sama dengan saat menyisir kotak masuk security@
• Pentingnya kerahasiaan, embargo, dan koordinasi juga berkurang dibanding sebelumnya
  • Penyerang tidak perlu menunggu tulisan pengungkapan penuh; mereka bisa langsung menanyakan kerentanan kepada LLM mereka sendiri
  • Namun, besar kemungkinan penyerang juga mengalami bottleneck klasifikasi yang sama seperti pihak bertahan

Pergeseran prioritas maintainer

• Masa ketika laporan kerentanan bersifat istimewa mungkin sudah berakhir
• Hal yang lebih penting sekarang adalah klasifikasi, perbaikan cepat, dan pencegahan
• Perlu dicari cara menjalankan analisis LLM di CI
• Pandangan ini bukan posisi resmi tim Go Security, melainkan opini pribadi dari mantan lead tim Go Security
• Saat penanganan laporan kerentanan berbenturan dengan penegakan Code of Conduct, tidak ada jawaban yang pasti
  • Penilaian harus mempertimbangkan tingkat keseriusan perilaku, apakah itu masalah pribadi atau berdampak pada komunitas, serta sumber daya tim yang menangani security@
• Praktik pengungkapan publik memiliki sejarah yang rumit
  • Di masa lalu, peneliti yang beritikad baik pernah menghadapi ancaman hukum atau tuntutan pidana
  • Dalam realitas open source tahun 2026, tidak ada peneliti yang takut dituntut karena laporan kerentanan, dan proyek juga tidak boleh menyiratkan penuntutan sebagai pengganti kebijakan pelaporan yang terdokumentasi
• Penghentian kanal laporan kerentanan curl selama sebulan awalnya terasa berlebihan, tetapi demi melindungi pengguna, kini tidak lagi jelas apakah merespons laporan kerentanan adalah penggunaan waktu terbaik

[GN⁺]

Komentar Lobste.rs

• Menurut saya, pengungkapan kerentanan yang tergesa-gesa masih jauh lebih membantu penyerang daripada pihak bertahan. Dari yang saya alami dan lihat sendiri, bahkan saat memakai model terdepan pun tingkat false positive bisa mendekati 90%
  Tambahan lagi, saya melihat kalimat, “pemeliharaan dan pengembangan berkelanjutan untuk protokol kriptografi open source penting bagi adopsi luas teknologi blockchain”, dan cukup mengejutkan bahwa masih ada orang yang percaya pada teknologi blockchain

  • Saya sempat bingung kenapa kalimat itu ada di sana, ternyata itu pesan yang dikirim oleh salah satu sponsor Filippo
    Pada titik ini, mungkin kontribusi paling bernilai yang diberikan teknologi blockchain kepada dunia adalah menyediakan insentif finansial yang sangat kuat untuk membuat implementasi protokol kriptografi yang benar-benar aman. Sebagiannya mungkin juga bisa berguna bagi orang lain
  • Saya penasaran apa yang dimaksud dengan false positive di sini. Apakah maksudnya model mengklaim menemukan kerentanan, tetapi setelah diperiksa ternyata bukan masalah?
    Saya kira pada titik ini kemampuan menemukan kerentanan dan memahami kode secara umum sudah cukup mapan sebagai hal yang dikuasai LLM, jadi saya penasaran apakah memang begitu dalam praktiknya. Akan bagus kalau Anda bisa menjelaskan sedikit lebih jauh dari pengalaman langsung Anda atau memberi rujukan yang layak dibaca. Saya tidak memakai LLM jadi sulit menilai sejauh mana kemampuannya saat ini, dan saya sungguh penasaran apakah saya perlu mengubah asumsi saya

• Laporan kerentanan yang istimewa harus diperlakukan secara istimewa, dan pihak bertahan perlu menyiapkan cara verifikasi yang lebih baik serta model ancaman yang dipublikasikan. Dengan begitu, orang bisa memenuhi dan memverifikasi standar yang lebih tinggi untuk diakui sebagai laporan yang benar-benar bagus

  • Pada akhirnya, mungkin memang akan dirangkum seperti itu. Laporan kerentanan pada umumnya tidaklah istimewa, tetapi sebagian laporan yang bertingkat keparahan tinggi atau sangat tepercaya memang perlu dianggap sebagai laporan kerentanan yang istimewa

• Saya setuju bahwa sekarang menemukan isu keamanan jadi lebih mudah dan hambatan masuknya lebih rendah, sehingga mailing list keamanan kemungkinan lebih berisik dibanding dulu. Meski begitu, saya tetap jelas akan memprioritaskan laporan bug dari perusahaan konsultan keamanan bereputasi seperti Trail of Bits atau Zellic
  Bukan hanya karena saya percaya mereka tidak akan mengirim laporan yang asal-asalan, tetapi juga karena menurut saya kombinasi peneliti keamanan papan atas dan LLM lebih baik daripada sekadar menjalankan LLM di CI

  • Saya baru-baru ini bekerja dengan vendor seperti itu, dan laporan yang asal-asalan tetap masuk. Hanya saja kualitas laporannya memang lebih tinggi
    LLM, siapa pun yang mengarahkannya, tetap bisa salah memahami model ancaman dan bisa malas dalam cara mereka membuktikan sebuah “eksploit”. Jika peneliti keamanan melewatkan kesalahan seperti ini, pada akhirnya itu akan diteruskan kepada kami sebagai maintainer. containerd menerima laporan yang asal-asalan dari vendor-vendor seperti ini, perusahaan riset LLM, perusahaan model dasar yang sudah dikenal, dan juga J Random User di internet
    Kesulitan lain yang Filippo tidak cukup bahas di sini adalah laporan duplikat. Jika melihat advisories terbaru containerd, Anda bisa melihat bahwa duplikasi adalah masalah besar lain dalam triage dan pembagian perhatian. Sebagai contoh, ada kredit untuk 9 peneliti/grup terpisah, termasuk grup bereputasi seperti yang disebut sebelumnya. Ini menunjukkan bahwa (a) LLM cenderung menemukan banyak isu yang sama tidak peduli siapa yang menggunakannya, dan (b) laporan dari pelapor yang sudah dikenal tidak otomatis istimewa. Sebaliknya, yang ini benar-benar tidak memiliki laporan duplikat, sehingga kreditnya hanya diberikan kepada satu orang, dan pelapornya bukan orang yang sebelumnya kami kenal atau punya hubungan dengan kami