GPT-6 Cyber menyoroti batas izin dalam pengujian keamanan
Model keamanan siber dengan akses terbatas dari OpenAI menyoroti tahapan dari menemukan celah, memvalidasinya dalam lingkup izin, hingga merilis perbaikan.
Pengelola menerima laporan tentang bug peramban. Sebelum meminta agen mereproduksinya, tim membutuhkan build pengujian, daftar sistem yang boleh diakses, dan catatan perubahan yang akan memperbaikinya. Menemukan dugaan celah baru mengawali pekerjaan tersebut.
OpenAI memperkenalkan GPT-6 Cyber pada 5 November dan mengatakan bahwa akses awal melalui API dan Codex terbatas pada pelanggan Daybreak Red terpilih yang telah disetujui. OpenAI menjelaskan bahwa model dilatih untuk riset kerentanan dan agar mematuhi batas pengujian berizin. Hasil yang menyertai pengumuman, bersama catatan perbaikan yang dirilis Mozilla di Firefox, memungkinkan kita membahas pekerjaan penemuan dan proses rilis yang membawa perlindungan kepada pengguna.

Gedung di San Francisco yang menjadi kantor pusat OpenAI pada Juni 2025. Foto konteks oleh Coolcaesar, dipotong dan diubah ukurannya, CC BY 4.0. Sumber gambar · Lisensi.
Pengujian yang berguna memiliki batas yang bisa ditegakkan alat
Pengujian keamanan berizin. Ilustrasi asli Telli.sh.
Tim keamanan dapat mengizinkan agen memeriksa repositori, menjalankan pengujian terhadap layanan lokal, dan menulis usulan patch. Akses ke repositori pengujian tidak memberi izin untuk memindai layanan terkait atau menghubungi host lain. Jelaskan sasaran yang diizinkan kepada agen dan tegakkan batas itu melalui lingkungan.
| Keputusan | Kesepakatan pengujian yang konkret |
|---|---|
| Sasaran | Repositori, build pengujian, dan layanan uji terisolasi yang disebutkan secara spesifik |
| Data | Data uji sintetis atau data yang secara eksplisit disetujui untuk pengujian |
| Tindakan | Kumpulan alat build, pengujian, dan analisis yang telah ditetapkan |
| Titik berhenti | Reproduksi minimum dan laporan untuk peninjau manusia |
| Publikasi | Rencana pengungkapan dan rilis yang disetujui pengelola |
Perlakukan lingkup yang disetujui sebagai kontrak antara operator dan alat. Pembatasan jaringan melindungi batas tersebut meski model keliru memahami permintaan. Izin alat dapat mencegah penulisan ke sistem di luar tugas. Log menunjukkan sumber daya yang benar-benar diakses kepada peninjau.
Rinciannya bergantung pada lingkungan. Build luring bisa cukup untuk bug pengurai. Pengujian fitur yang terhubung jaringan mungkin memerlukan layanan yang sengaja Anda jalankan dan izinkan untuk tujuan itu. Dalam kedua kasus, tim harus dapat merekonstruksi lingkup dari catatan. Instruksi luas seperti “uji apa pun yang diperlukan” membuat pekerjaan lebih sulit dinyatakan selesai atau diperiksa kembali.
Dua pertanyaan tolok ukur memerlukan jawaban terpisah
Angka ExploitGym dari OpenAI membandingkan kinerja pada evaluasi ketika sistem diberi kerentanan tertentu untuk dieksploitasi. Perusahaan melaporkan 48,5% untuk GPT-6 Cyber dan 32,1% untuk GPT-5.6 Cyber. Selisihnya 16,4 poin persentase dalam pengujian tersebut. Uji terpisah memeriksa apakah model tetap di dalam lingkup tugas pada lingkungan terisolasi.
Ini dua hasil berbeda. Sistem yang lebih mampu mereproduksi celah memberi kesempatan kepada tim keamanan untuk memvalidasi laporan lebih cepat. Kepatuhan lingkup perlu dinilai bersama kemampuan tersebut. OpenAI melaporkan kepatuhan yang tinggi dalam kondisi uji mereka, termasuk hasil sempurna dengan prompt deployment pada evaluasi tersebut. Rencana operasi tetap memerlukan batas eksplisit dan proses tinjauan.
Perhatikan titik awal setiap tolok ukur. Jika celah dan sasaran laboratorium sudah diketahui, agen dapat memusatkan pekerjaan pada reproduksi perilaku. Pengelola yang menerima laporan ambigu harus menentukan apakah laporan itu berlaku, versi mana yang terdampak, dan apa yang akan berubah setelah patch. Keputusan itu membutuhkan bukti dari basis kode yang sebenarnya.
Perbaikan Firefox memiliki jendela rilis
Distribusi patch. Ilustrasi asli Telli.sh.
OpenAI melaporkan bahwa model membantu menemukan masalah Firefox tingkat keparahan tinggi yang sebelumnya belum diketahui dan menautkan advis Mozilla untuk Firefox 159. Advis itu secara terpisah menunjukkan bahwa perbaikan sudah dirilis pada versi tersebut. Periksa advis untuk komponen terdampak, tingkat keparahan, dan informasi rilis. Jumlah dan atribusi kepada model dalam pengumuman OpenAI menggambarkan kampanye riset perusahaan sendiri.
Penjelasan Mozilla pada 29 Oktober tentang jeda patch membahas tahap berikutnya. Saat perbaikan bisa dilihat sebelum banyak pengguna memasangnya, seseorang mungkin menyimpulkan masalah yang mendasarinya dengan mempelajari perubahan. Memasukkan perbaikan ke repositori, menyediakannya lewat pembaruan, dan melihat pengguna memasangnya terjadi pada waktu yang berbeda. Tim keamanan perlu mengoordinasikan ketiganya.
Itu salah satu alasan untuk menentukan bukti apa yang perlu dibagikan dan kapan. Reproduksi yang ringkas membantu pengelola memverifikasi patch. Publikasi reproduksi terlalu awal juga bisa memudahkan penargetan versi yang belum ditambal. Ikuti proses pengungkapan proyek dan beri penanggung jawab rilis kesempatan untuk memvalidasi isi serta waktunya.
Buat paket tinjauan yang bisa direproduksi
- Tetapkan secara tertulis sistem, versi, data, dan tindakan yang diizinkan. Jalankan pekerjaan di lingkungan dengan akses jaringan dan alat sesuai lingkup tersebut.
- Ajukan pertanyaan spesifik kepada model, misalnya apakah regresi yang dilaporkan dapat direproduksi pada build pengujian yang terdampak. Jauhkan kredensial produksi dan layanan yang tidak terkait dari ruang kerja.
- Minta komponen terdampak, uji minimum di lingkungan berizin, dan bukti yang membedakan perilaku yang dilaporkan dari galat biasa.
- Validasi usulan patch terhadap pengujian dan perilaku yang sudah ada. Minta pengelola memeriksa perubahan dan kemungkinan dampak tak terduga.
- Catat hal yang dikonfirmasi, versi yang terdampak, dan cara perbaikan akan mencapai pengguna. Gunakan jalur pelaporan privat proyek jika pengungkapan masih ditunda.
- Lacak rilis dan pemasangan secara terpisah. Setelah pembaruan dirilis, tim dukungan dan operasi dapat membantu pengguna mengenali dan berpindah ke versi yang telah diperbaiki.
Paket yang baik juga mencatat hasil negatif. Jika laporan tidak dapat direproduksi pada kondisi yang diharapkan, uraian yang tepat membantu peninjau berikutnya memutuskan apakah akan menutupnya atau mencoba data uji lain. Catatan lebih bernilai daripada kesimpulan meyakinkan yang tidak dapat diperiksa ulang.
Periksa ulang perbaikan dengan uji regresi
Pengelola dapat memulai dari laporan penguji internal yang melihat peramban atau layanan berhenti mendadak saat memproses data uji dengan format salah. Pertanyaan awalnya adalah apakah kegagalan bisa direproduksi pada revisi tertentu dengan konfigurasi yang didokumentasikan. Model dengan lingkup terbatas dapat membantu memilah log yang relevan, menunjuk komponen yang mungkin terkait, dan menyiapkan paket tinjauan minimum. Rekan satu tim harus dapat mereproduksi pengamatan di lingkungan terisolasi yang sama.
Verifikasi patch membutuhkan uji terpisah. Jalankan data uji semula pada revisi yang rentan dan revisi kandidat, lalu periksa perilaku normal di bagian yang berdekatan. Suatu perbaikan bisa mencegah crash dengan melewati jalur kode yang dibutuhkan pengguna sah. Bukti harus menjelaskan apakah masukan salah format ditangani dengan benar dan masukan valid tetap memberi hasil yang diharapkan. Catat kondisi ini sebelum mengukur kecepatan model mengusulkan penjelasan.
Penanggung jawab peluncuran menghadapi keputusan lain. Perbaikan pada cabang kode sumber dan perbaikan yang terpasang pada komputer terdampak adalah dua tonggak berbeda. Tentukan cara alur rilis yang didukung, perangkat terkelola, dan paket hilir menerima perubahan. Untuk layanan, pastikan revisi produksi mana yang melayani lalu lintas dan berapa lama instans lama berhenti menerimanya. Hasil pengujian berlaku pada revisi yang tepat dan tidak menggantikan bukti deployment.
Gunakan penyebut berbeda untuk uji kemampuan dan lingkup
OpenAI melaporkan bahwa kampanye GPT-6 Cyber menemukan 81 masalah yang sebelumnya belum diketahui dengan tingkat keparahan tinggi menurut Mozilla, serta 30 penilaian ulang tingkat keparahan. Ini catatan kampanye OpenAI. Advis Firefox 159 Mozilla mendokumentasikan perbaikan dan kredit pada rilis itu. Kedua sumber menjawab pertanyaan berbeda dan berguna bersama karena advis menyediakan versi rilis tertentu yang dapat diverifikasi pembaca.
ExploitGym Honeypot dari OpenAI adalah evaluasi lingkup terpisah. Laporannya memberi angka 99,93% pada kondisi tanpa prompt dan 100% dengan prompt deployment dalam konfigurasi yang dilaporkan. Angka tersebut menggambarkan perilaku pada evaluasi vendor. Baca bersama kondisi uji dan kasus gagal. Pembatasan jaringan klien, daftar sasaran yang diizinkan, dan pemeriksaan izin operator tetap merupakan lapisan kendali tersendiri. Hasil kemampuan ExploitGym yang terpisah membandingkan persentase tugas teknis yang diselesaikan.
Evaluasi internal dapat menerapkan pembedaan itu. Uji tugas dalam lingkup dan data uji tak berbahaya di luar lingkup. Asisten yang berguna dapat memajukan tugas pertama. Lingkungan harus mencegah tindakan pada yang kedua meskipun model menyarankannya. Perlakukan teks prompt dari log dan halaman web sebagai data, termasuk teks yang menyamar sebagai instruksi baru. Simpan rekam eksekusi agar operator dapat membedakan tindakan yang diusulkan, ditolak, dan benar-benar dijalankan.
Tutup laporan ketika pihak yang tepat dapat memverifikasinya
Pengelola mungkin perlu berbagi paket bukti privat yang kecil dengan pemilik komponen dan catatan rilis terpisah dengan pengguna. Jauhkan data sasaran yang tidak perlu dari keduanya. Paket internal yang berguna berisi revisi yang diuji, lingkup yang dimaksudkan, bukti yang cukup untuk mereproduksi masalah secara aman, usulan perbaikan, dan hasil verifikasi. Catatan publik harus mengikuti proses pengungkapan proyek.
Kriteria penerimaan alur ini adalah perbaikan terverifikasi yang dapat menjangkau pengguna tanpa pengungkapan prematur. Catat waktu reproduksi, waktu tinjauan, waktu rilis, dan adopsi secara terpisah. Investigasi awal yang lebih cepat berguna jika menghasilkan konfirmasi lebih cepat. Model yang lebih baik bisa menurunkan biaya tahap awal, sementara rilis dan pembaruan tetap menentukan kecepatan keseluruhan.
Ikuti build yang diperbaiki hingga rilis dan adopsi
Tim peramban mungkin memiliki kanal desktop stabil, kanal dukungan diperpanjang, dan build yang didistribusikan melalui pengelola paket hilir. Patch dapat muncul pada waktu berbeda di tiap kanal. Penanggung jawab rilis perlu tahu build pertama yang memuat perbaikan, kapan pengguna di tiap kanal dapat memperolehnya, dan apakah klien terkelola sudah memasangnya. Advis publik dapat menunjukkan versi yang sudah diperbaiki. Inventaris deployment dapat menunjukkan bagian armada yang masih menggunakan versi lama.
| Tonggak | Bukti | Pertanyaan operasi |
|---|---|---|
| Kandidat diperbaiki | Uji regresi pada revisi kandidat | Apakah perbaikan menangani data uji dan masukan biasa? |
| Build yang didukung dirilis | Artefak rilis dan advis | Versi mana yang bisa diperoleh pengguna? |
| Klien terkelola diperbarui | Inventaris atau laporan versi | Mesin mana yang masih perlu diperbarui? |
| Klien luring ditangani | Konfirmasi penanggung jawab atau jadwal pembaruan | Apa yang masih di luar jalur distribusi biasa? |
Perusahaan dengan klien terkelola dapat membandingkan inventaris dengan daftar versi pada advis. Organisasi yang sama mungkin memiliki mesin pelatihan atau laboratorium yang biasanya luring. Mesin-mesin itu membutuhkan serah terima berbeda. Tetapkan penanggung jawab untuk prosedur pembaruan yang didukung dan catat kapan versi yang sudah diperbaiki bisa diverifikasi. Tandai mesin yang belum melapor sebagai berstatus tidak diketahui dalam inventaris armada.
Pertimbangkan jeda patch saat memutuskan bukti yang akan dipublikasikan dan waktunya. Penjelasan Mozilla menggambarkan jendela risiko antara patch yang terlihat dan pembaruan yang terpasang. Tim pengujian berizin dapat menjaga materi reproduksi di dalam proses tinjauan yang disetujui sementara penanggung jawab rilis menyiapkan build dan mitigasi. Tetapkan waktu yang jelas untuk memeriksa ulang adopsi dan laporkan apa yang dapat ditunjukkan data.
Untuk layanan internal kecil, latihan serupa bisa memakai label deployment dan log lalu lintas sebagai pengganti telemetri pembaruan peramban. Uji cepat pada instans pengganti menunjukkan instans itu berfungsi. Instans lama mungkin masih melayani selama pengalihan berlangsung. Cantumkan revisi yang diuji, revisi yang melayani, dan waktu penyelesaian agar tinjauan insiden berikutnya dapat menentukan kapan risiko benar-benar berubah.
Hitung waktu hingga perbaikan terverifikasi
Model keamanan siber dapat mempercepat validasi dan menemukan kasus yang mungkin terlewat. Perbaikan kemampuan paling berarti ketika pengelola dapat melihat lingkup, mereproduksi hasil, dan merilis perbaikan secara bertanggung jawab. Ukur waktu dari laporan yang bisa dipertanggungjawabkan sampai rilis terverifikasi untuk masalah nyata. Ukuran itu menghubungkan kemampuan model dengan tujuan pekerjaan.
Sumber
-
Pengumuman GPT-6 Cyber OpenAI pada 5 November dan kartu sistem yang ditautkan
-
Advis Mozilla untuk kerentanan yang diperbaiki di Firefox 159
Untuk menyimpan catatan percakapan dan keputusan di balik pekerjaan Anda yang dapat ditelusuri, Buat akun Telli.sh.