Patch Gap Project Glasswing: 6.157 Diungkap, 516 Di-patch

Angka yang membuat saya berhenti bukan yang terbesar. Laporan pihak kedua menyebut partner Glasswing telah memverifikasi sedikitnya 129.000 kerentanan. Angka yang penting ada di dashboard disclosure Anthropic: 6.157 diungkap, 516 di-patch, terakhir diperbarui 2 Oktober 2026. Sekitar 5.600 laporan masih menunggu seseorang memperbaikinya.

Tulisan ini membaca angka-angka itu terhadap sumber primernya: update Anthropic bulan Mei, dashboard disclosure, kutipan di mailing list oss-security, dan para kritikus yang menilai angkanya tidak cocok satu sama lain. Setiap angka saya atribusikan ke halaman tempat saya membacanya, tanpa detail exploit, dan paruh kedua berfokus pada pertahanan: apa yang harus diubah maintainer dan tim yang bergantung pada open source minggu ini.

Apa sebenarnya yang diukur sumber-sumber ini

Ada tiga hitungan berbeda yang beredar atas nama Glasswing, dan mencampurnya adalah awal argumen yang keliru. Update Anthropic 22 Mei menyebut partner menemukan lebih dari sepuluh ribu kerentanan severity tinggi atau kritis, sekitar 530 bug tinggi atau kritis sudah diungkap ke maintainer, dan 75 dari 530 itu sudah di-patch. Dashboard disclosure menghitung lebih luas: semua kerentanan yang dilaporkan Anthropic ke maintainer, apa pun severity-nya. Angka ketiga, 129.000 kerentanan terverifikasi dari partner antara April dan Juli, muncul di halaman Software Improvement Group yang mengatribusikannya ke Anthropic tanpa pemeriksaan independen.

Definisi lebih penting daripada judul berita. Dashboard menyatakan disclosed berarti dilaporkan ke maintainer, bukan dipublikasikan, dan patched upstream menghitung fix yang sudah dirilis maintainer, yang menurut dashboard tidak menjamin patch itu sudah terpasang luas. Dashboard juga menyebut jumlah disclosed hanyalah subset dari semua temuan model Claude, karena triage dan review manusia secara independen adalah langkah pembatas laju.

Disclosed versus patched dalam tiga potret

Saya menaruh angka yang bisa saya baca berdampingan. Kolom rasio adalah hitungan saya sendiri, patched dibagi disclosed, dan tiap baris punya penyebut berbeda, jadi bandingkan tren-nya, bukan persentase persisnya.

Di antara dua potret dashboard, jumlah disclosure naik sekitar empat kali lipat sementara patch naik sekitar lima kali lipat, sehingga porsinya hanya bergerak dari 6,1 ke 8,4 persen. Itu menyisakan 5.641 laporan, menurut pengurangan saya, tanpa fix yang diketahui. Dashboard memberi kualifikasi pada angka patch-nya dengan kata to our knowledge, dan kutipan oss-security mencatat sebagian maintainer merilis fix tanpa advisory, jadi angka patched sebenarnya mungkin sedikit lebih tinggi. Selisih sebesar ini tidak akan tertutup.

Mengapa bottleneck-nya manusia, bukan scanner

Anthropic menyatakan kendalanya langsung di update Mei: kemajuan dibatasi seberapa cepat temuan bisa diverifikasi, diungkap, dan di-patch, dan hambatannya adalah kapasitas manusia untuk triage, melapor, serta merancang dan men-deploy patch. Anthropic menambahkan bahwa beberapa maintainer mengaku sangat kewalahan, dan sebagian meminta Anthropic memperlambat laju disclosure. Disebutkan pula bug tinggi atau kritis rata-rata butuh sekitar dua minggu untuk di-patch.

Ini yang perlu dipahami jika Anda memelihara sebuah package. Alat yang menghasilkan laporan lebih cepat daripada kemampuan relawan membacanya tidak otomatis membuat ekosistem lebih aman; ia hanya memindahkan antrean. Saran Anthropic menyasar kedua sisi: developer software sebaiknya mempersingkat siklus patch dan merilis security fix secepat mungkin, sedangkan network defender mempersingkat pengujian dan deployment patch sambil mengandalkan kontrol yang tidak menunggu satu patch tertentu.

Di mana angkanya dipersoalkan

Saya tidak akan mengulang angka-angka ini tanpa kualifikasinya. VulnCheck, dalam tulisan bertanggal 8 September 2026, berargumen hanya 9,8 persen temuan Anthropic yang sampai ke maintainer, menghitung 202 temuan berstatus fixed di ledger yang diperiksanya, dan menyebut Claude menilai 91,5 persen temuan sebagai kritis atau tinggi, dibanding 51,3 persen oleh maintainer. Kesimpulannya, kuitansinya tidak cocok. Bruce Schneier pada Juni menyebut rendahnya jumlah patch aneh dan bahwa permintaan Anthropic agar orang percaya saja adalah masalah besar karena detailnya tidak dirilis.

Mereka adalah kritikus yang membaca ledger publik, dan saya tidak bisa memverifikasi hitungan mereka terhadap dashboard langsung, jadi anggap sebagai tantangan untuk dicek, bukan bantahan. Pihak Anthropic juga punya catatan. Dashboard menyembunyikan nama proyek dan jenis bug sampai fix dirilis, yang standar untuk coordinated disclosure tetapi membuat pihak luar tidak bisa mengaudit tiap item. Angka 129.000 dan 33.000 sampai kepada saya lewat halaman Software Improvement Group, bukan halaman Anthropic yang bisa saya buka, jadi saya mengutipnya sebagaimana dilaporkan, termasuk pernyataan bahwa Anthropic memperkirakan angka sebenarnya sedikitnya lima kali lebih tinggi.

Pembacaan saya: keduanya bisa benar. Sisi penemuan mungkin besar, sisi terverifikasi lebih kecil, dan sisi yang sudah diperbaiki lebih kecil lagi. Angka mana pun yang Anda pilih untuk puncak corong, dasar corong adalah angka yang menentukan risiko Anda sendiri.

Jika Anda memelihara proyek open source

Anda tidak bisa mengalahkan mesin dalam triage, jadi buat pintu depan semurah mungkin. Private vulnerability reporting dari GitHub, yang diaktifkan owner atau administrator repository lewat Settings lalu Advanced Security, memberi pelapor tombol Report a vulnerability di halaman Advisories dan memberi notifikasi ke administrator dan security manager yang memantau repository. SECURITY.md singkat lalu memberi tahu pelapor apa yang Anda butuhkan. Ini yang akan saya jadikan titik awal, termasuk baris yang menanyakan apakah alat AI dipakai, karena itu memungkinkan Anda menyortir antrean berdasarkan seberapa banyak yang sudah diverifikasi manusia.

# SECURITY.md  (repository root, or .github/SECURITY.md)
# Goal: a reporter, human or AI-assisted, knows in one screen where to go,
# what a good report contains, and what you will and will not promise.

## Reporting a vulnerability

Use "Report a vulnerability" on this repository's Security > Advisories tab.
Please do not open a public issue.

A report we can act on within days contains:
- the affected version or commit
- the smallest input or configuration that shows the problem
- what an attacker gains (read, write, crash, code execution)
- whether you used an automated or AI tool to find it, and what a human
  has verified by hand

## What to expect

- Acknowledgement: best effort, from a volunteer team.
- Duplicates and unverified machine output may be closed with a pointer
  to this file. That is not a judgement of you; it is triage capacity.
- We publish a GitHub Security Advisory when a fix ships.

## Supported versions

| Version | Receives security fixes |
| ------- | ----------------------- |
| 3.x     | yes                     |
| 2.x     | critical only           |
| < 2.0   | no                      |

Dua batasan yang jujur. File yang menyebut duplikat boleh ditutup melindungi waktu Anda tetapi akan mengecilkan hati sebagian pelapor yang baik, jadi tulis dengan ramah. Dan GitHub juga memungkinkan Anda menambah VULNERABILITY_REPORT.yml di direktori .github untuk menyesuaikan form dan mewajibkan CWE pada tiap laporan; saya belum menguji skema file itu, jadi baca dokumentasinya sebelum menyalin versi orang lain.

Jika Anda bergantung pada open source

Tugas Anda adalah memperpendek waktu antara fix tersedia dan fix berjalan di production. Dependabot bisa mengelompokkan semua security update dalam satu pull request, dan dokumentasi menyebut cooldown hanya tersedia untuk version update, bukan security update, sehingga pengaturan penundaan tidak akan menahan sebuah fix. Pasangkan dengan scan lockfile agar Anda tahu apa yang sebenarnya Anda rilis.

# .github/dependabot.yml
version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "daily"
    # Security updates are subject to a separate, fixed limit of 10 open PRs.
    # This limit only governs ordinary version updates.
    open-pull-requests-limit: 10
    groups:
      # One PR per run for security updates instead of one PR per advisory.
      security-group:
        applies-to: "security-updates"
        patterns:
          - "*"
    # Cooldown delays ordinary version bumps only. It is documented as not
    # available for security updates, so a fix is never held back by it.
    cooldown:
      default-days: 5
      semver-major-days: 30

# Know what you ship, from the lockfile, with no network calls to your code.
osv-scanner scan -L package-lock.json --format json --output-file osv-report.json

# Several lockfiles in a monorepo:
osv-scanner scan -r ./services/

# Wrong: running "osv-scanner fix" on a dependency tree you do not trust.
# The tool's own docs warn that guided remediation can trigger the package
# manager to run scripts or follow external registries.
# Right: run fix only on your own repository, on a throwaway branch.
osv-scanner fix -M package.json -L package-lock.json

Pengelompokan dan scan itu rekomendasi saya, bukan dari Anthropic. Saran Anthropic untuk defender adalah mempersingkat pengujian dan deployment patch, dan halaman Software Improvement Group menyebut menunggu tiga bulan untuk mem-patch kerentanan kritis kini jauh lebih besar liabilitasnya. Konfigurasi di atas adalah salah satu cara menindaklanjutinya.

Apa yang bisa salah, dan siapa memegang langkah mana

Kesalahan yang mahal adalah menganggap patch yang dirilis sama dengan sistem yang sudah aman. Dashboard sendiri memperingatkan bahwa patched upstream tidak menjamin pemasangan luas, dan satu pull request security berkelompok yang gagal satu tes bisa menahan semua fix di dalamnya, yang merupakan kewaspadaan saya sendiri soal pengelompokan, bukan perilaku yang didokumentasikan. Empat pihak di bawah masing-masing memegang langkah berbeda, dan masing-masing punya titik gagal.

Tabel ini sintesis saya dari rekomendasi Anthropic untuk developer dan defender, ditambah laporan kapasitas maintainer di update Mei. Ini bukan kerangka yang diterbitkan salah satu sumber itu.

Yang dikerjakan hari Senin

Lima langkah, dalam urutan yang akan saya kerjakan, masing-masing cukup kecil untuk satu hari kerja.

1. Aktifkan private vulnerability reporting di setiap repository publik milik Anda, dan commit SECURITY.md dengan tabel supported versions.
2. Jalankan osv-scanner pada setiap lockfile dan simpan laporan JSON sebagai baseline yang bisa di-diff minggu depan.
3. Aktifkan Dependabot security update yang dikelompokkan dalam satu pull request, lalu ukur berapa hari sebuah pull request security menunggu sebelum di-merge.
4. Cari bagian paling lambat di pipeline Anda antara merge dan production, lalu catat angkanya. Anthropic dan halaman Software Improvement Group sama-sama menunjuk kecepatan deployment.
5. Cek tanggal pembaruan terakhir dashboard disclosure Anthropic sebelum mengutip angka apa pun, karena halaman itu hidup dan angkanya akan bergerak.

Aturan yang saya bawa: angka penemuan adalah headline, angka patched adalah antrean, dan angka terpasang adalah risiko Anda. Penemuan menjadi jauh lebih murah di 2026, sementara triage, perbaikan, dan deploy masih pekerjaan manusia. Bangun proses Anda di sekitar yang paling lambat dari ketiganya, karena di situlah 5.641 laporan tanpa fix menunggu.