Defending Code Reference Harness - Framework open-source Anthropic untuk menemukan dan memperbaiki kerentanan berbasis AI

• Defending Code Reference Harness adalah implementasi referensi untuk melakukan penemuan dan perbaikan kerentanan secara otonom dengan Claude, disusun berdasarkan pembelajaran yang diperoleh melalui kolaborasi dengan tim keamanan di berbagai organisasi
• Repositori ini bukan produk, melainkan implementasi referensi, dan saat ini tidak dipelihara serta tidak menerima kontribusi
• Anthropic menyediakan alternatif terkelola berupa Claude Security, yang dapat menemukan dan memperbaiki kerentanan di source code berbagai proyek serta mengelola siklus hidup triage, validasi perbaikan, dan pembuatan perbaikan cepat
• Skills untuk Claude Code yang tersedia adalah /quickstart, /threat-model, /vuln-scan, /triage, /patch, /customize, yang mendukung penetapan cakupan interaktif, pemindaian, triage, dan pekerjaan patch
• harness/ adalah pipeline referensi otonom dengan alur recon → find → verify → report → patch, dan disesuaikan untuk eksplorasi kerentanan memori C/C++ menggunakan Docker dan ASAN
• Struktur umum pipeline referensi, prompt, dan metode sandboxing-nya dapat digunakan ulang, tetapi tidak langsung berjalan pada semua codebase, sehingga perlu di-port dengan /customize agar sesuai dengan bahasa, detektor, dan jenis kerentanan
• /quickstart, /threat-model, /vuln-scan, /triage, serta /patch untuk hasil statis hanya melakukan baca-tulis file, sehingga dapat dijalankan tanpa sandbox di Claude Code jika penggunaan tiap alat telah ditinjau dan disetujui
• Pipeline referensi otonom dan /patch untuk hasil pipeline menjalankan kode target, sehingga akan menolak berjalan di luar sandbox gVisor kecuali sengaja dibypass secara eksplisit
• Untuk menjalankan pipeline, gVisor dan image agen harus disiapkan dengan scripts/setup_sandbox.sh, dan diperlukan Docker serta variabel lingkungan ANTHROPIC_API_KEY atau CLAUDE_CODE_OAUTH_TOKEN
• Tahap eksekusi dibagi menjadi build, recon, find, verify, dedupe, report, patch; agen find membuat malformed input di container terisolasi dan terus mengeksplorasi sampai biner ASAN crash 3 dari 3 percobaan
• Pada tahap verify, agen grader terpisah hanya menerima proof of concept di container baru untuk mereproduksi crash, dan tahap dedupe menentukan apakah itu bug baru, contoh yang lebih baik dari bug yang sudah ada, atau duplikat
• Tahap report menulis exploitability analysis terstruktur yang mencakup primitive class, reachability, escalation path, dan severity; tahap patch membuat usulan perbaikan lalu memeriksa build, memastikan proof of concept asli tidak crash, tes lolos, dan mencari ulang kemungkinan bypass
• Alur penggunaan awal adalah membuat threat model serta static scan, triage, dan candidate patch pada Day 1; menghasilkan findings yang tervalidasi lewat eksekusi pada library C/C++ di Day 2; lalu membuat targets/<your-service>/ untuk target sendiri pada Days 3-5
• Saat di-port ke stack sendiri, Anda perlu mendefinisikan sinyal finding, bentuk proof of concept, serta cara build dan eksekusi; referensi C/C++ menggunakan ASAN crash signature, file input yang memicu crash, dan Dockerfile berbasis clang+ASAN sebagai acuan
• Triage dan patching otonom masih merupakan masalah terbuka; strategi validasi /patch memang menaikkan standar, tetapi severity dan prioritas bergantung pada penilaian tiap lingkungan, dan patch yang tervalidasi tidak selalu dapat di-upstream

[GN⁺]

Komentar Hacker News

• Ini lebih mirip jig bengkel. Kalau mau, Anda bisa membeli crosscut sled, tapi kebanyakan tukang kayu membuatnya sendiri
  Dua tahun lalu situasinya berbeda karena biaya membuat harness sendiri besar, tetapi sekarang lebih masuk akal melihat hal seperti ini sebagai referensi ide lalu membuatnya sendiri sesuai cara kerja, antarmuka, target, definisi upaya, dan cara notifikasi yang cocok untuk diri sendiri

  • Analogi jig bengkel ini memang sangat tepat. Banyak perangkat lunak sedang bergeser dari sesuatu untuk penggunaan umum menjadi sesuatu untuk penggunaan yang sangat dipersonalisasi
    Sebelum AI, membuat perangkat lunak untuk menyelesaikan masalah sendiri butuh banyak tenaga manusia, jadi orang sering sekalian bersusah payah menggeneralisasikannya agar bisa dipakai ulang orang lain. Sekarang upayanya nyaris nol, jadi perangkat lunaknya tetap tidak digeneralisasi
    Belakangan ini saya hampir tidak pernah membagikan hal-hal yang saya buat[0], karena kecil kemungkinan berguna bagi orang lain, dan kalau mereka butuh sesuatu yang mirip, mereka bisa membuat sesuatu yang pas untuk mereka alih-alih memperluas atau memperbaiki milik saya. Seperti jig
    0: https://redfloatplane.lol/blog/17-why-share/ dan tulisan terkait
  • Ini persis itu. Saya sudah berkali-kali mengatakan bahwa “menggunakan komputer akan secara transparan mencakup komputer yang menulis dan menjalankan kode untuk kita”, dan kalau bukan teknisi, orang bahkan bisa saja tidak menyadari hal itu. Arah yang Anda sebutkan tadi juga menuju ke sana
    Dalam hidup kita, sering kali lebih baik membuat alat yang khusus untuk tujuan tertentu, dan setiap kali model baru muncul, kompleksitas alat seperti itu juga meningkat
    Hal seperti ini benar-benar alat pribadi. Ia menyelesaikan masalah yang mungkin juga dimiliki orang lain, tetapi sangat terikat pada cara kerja pribadi sehingga sulit dijelaskan atau disesuaikan untuk orang lain. Karena itu ia seperti jig bengkel
    Saya juga punya sekitar 10 skrip dan program kustom seperti ini, dan ini pertama kalinya saya merasakan hal seperti ini lagi sejak kuliah. Waktu itu saya punya waktu untuk mengutak-atik konfigurasi sesuka hati, dan sekarang kita punya agen
    Saya ingin menunjukkannya ke teman-teman, tetapi saat saya mencoba menelusuri di kepala bagaimana menjelaskannya, rasanya mereka tidak akan memahami berbagai keanehannya. Karena itu memang keanehan saya. Ini potongan teknologi yang cukup kompleks yang sangat baik menyelesaikan masalah saya, dan masalah-masalah itu adalah variasi pribadi dari masalah yang lebih luas, dan setidaknya untuk saat ini saya tidak berniat mendukungnya
    Sangat jelas kita sedang bergerak ke arah ini, tetapi banyak orang masih percaya bahwa kode adalah milik kaum elite. Untuk kode produk mungkin benar, tetapi selebihnya, sebentar lagi bahkan komputer orang tua kita kemungkinan akan menjalankan kode yang ditulis sendiri untuk mereka. Dari sisi keamanan itu menakutkan, tetapi kalau dipikir-pikir menarik
  • Siapa pun bisa membuat harness jika mau, tetapi kebanyakan orang tidak punya kemauan untuk itu
    Lagi pula, bahkan kalau dikerjakan sendiri, alur kerja AI yang saya poles selama beberapa bulan langsung terasa usang karena ultracode
  • Saya sedang mencari cara untuk mengungkapkan perubahan ini, dan analogi ini tepat sekali. Nilai library dan komponen infrastruktur dalam rekayasa perangkat lunak sedang turun dengan cepat
    Saya rasa di banyak organisasi, makin sedikit pengguna yang datang ke tim yang menangani pekerjaan seperti ini
  • Saya juga melihat masa depan open source kurang lebih seperti ini. Daripada mengambil dan memakai library open source, kita akan lebih sering memakainya ulang sebagai inspirasi desain untuk alat kustom yang kita buat
    Biaya membuat milik sendiri sudah terlalu murah, dan biaya terjebak dalam building block milik orang lain terlalu mahal
    Namun, menambatkan AI coding ke alat yang sudah ada itu sangat kuat

• Saya penasaran berapa biaya untuk menjalankan ini
  Menurut https://github.com/anthropics/defending-code-reference-harne...:

  Sebagai patokan kasar, perkirakan sekitar 10K token input tanpa cache per menit per agen, dan sekitar 2K token output. Anda dapat meningkatkan paralelisme hingga batas ITPM akun Anda (sekitar 10 agen per 100K ITPM)
  Tebakan saya, dengan Opus biayanya mungkin ratusan dolar, dan dengan Mythos mungkin ribuan dolar

  • Makin jelas bahwa membuat kode membutuhkan lebih sedikit token daripada membuat kode itu aman
    Mungkin bahkan bisa berbeda sampai satu orde magnitudo tunggal
  • Menurut saya biaya Opus saja sudah terlalu mahal untuk ditanggung, dan saya tidak tahu bagaimana perbandingannya dengan Mythos
    Dari kalkulator ini, cukup mengejutkan bahwa perusahaan dengan 100 developer bisa mencapai sekitar $2,5 juta per tahun untuk biaya token
    https://ai-cost-calculator.arnica.io
  • Alur kerja mode ultra code Claude juga bekerja sangat mirip, dan menghabiskan batas penggunaan sesi dalam jumlah yang cukup wajar tergantung kompleksitas tugas
    Hanya saja kalau dijalankan lewat API, sepertinya biayanya akan cepat membengkak
  • Saya benar-benar membuat kalkulator untuk memperkirakan biaya pemindaian, termasuk apakah dijalankan terus-menerus atau tidak: https://ai-cost-calculator.arnica.io
    Ini memang hanya perkiraan jadi bisa saja meleset, tetapi setidaknya memberi gambaran kisaran kasar berdasarkan pengalaman kami. Saya ingin mendengar masukan
  • Dibandingkan layanan terkelola mereka, perkiraan ini kemungkinan bisa menjadi sepersepuluh dari biaya yang diharapkan, tergantung codebase
    Tetapi bahkan kalau dipatok dengan angka yang lebih besar, ini masih bisa sekitar sepersepuluh dari biaya kontrak keamanan formal untuk penemuan yang ditargetkan alat seperti ini. Ini jenis hasil yang tidak akan keluar hanya dari review PR atau /security-review, dan perlu pakar yang memimpin pekerjaan awal untuk framework open source. Waktu dan jeda untuk mencari tahu bagaimana menjalankan kontrak seperti itu bahkan belum dihitung
    Terus terang, kalau ini penting, bahkan jika satu pemindaian menghabiskan anggaran vibe coding sebulan penuh, ini tetap sangat murah dalam skala “beberapa sen per dolar”
    Pada saat yang sama, hasilnya tetap membutuhkan pakar. Sarannya bisa membantu atau justru aktif merugikan, dan itu bergantung pada kualitas pekerjaan awal
    Kepada kepala departemen TI, saya akan menyarankan: keluarkan beberapa ribu dolar untuk menjalankan ini, dapatkan anggaran lewat halaman hasil yang menakutkan, lalu bangun hubungan dengan red team yang bisa menemukan dan mengklasifikasikan kerentanan, membantu memperbaikinya bila perlu, dan melatih tim internal agar lebih berorientasi pada keamanan

• “Repositori ini tidak dipelihara dan tidak menerima kontribusi.”
  Hmm :)

  • Kenapa Claude tidak memeliharanya?
  • Yang ini dipelihara, dan harus disesuaikan dengan semua model pinned secepat mungkin
    https://github.com/space-bacon/SRT
    Bisa sangat meningkatkan semua model pinned dalam semalam. Ayo gas

• Dari pengalaman kami, tanpa harness yang bagus, tidak banyak yang bisa didapat dari codex/claude. Dan kami harus menghabiskan waktu dan energi untuk mencari tahu kenapa agen coding tidak bisa menemukan bug yang ditemukan manusia
  Sebagai auditor, setiap minggu saya melihat bug yang tidak ditemukan harness kami (https://zkao.io/), dan kami harus menemukan teknik yang cukup menarik agar alat bisa menemukan bug itu. Yang dibicarakan di sini terutama adalah kerentanan kriptografis, bukan bug webapp sederhana
  Jadi masuk akal kalau perusahaan juga punya harness sendiri, dan mau membayar layanan yang fokus membuat harness yang bagus berdasarkan pengalaman. Firma audit yang melihat banyak bug dan bisa meluangkan waktu untuk “mengajarkan” bug-bug itu ke harness kemungkinan akan paling unggul dalam hal ini
  Sebaliknya, triase juga membutuhkan teknik yang sama bagusnya. Kalau tidak, akan muncul mesin yang saya sebut audit vibe, yang hanya membanjiri dengan false positive sampai makin melelahkan developer yang sudah capek menghadapi submission AI murahan di bug bounty dan alat AI yang mereview semua PR
  Pada akhirnya, jika harness tidak mengembalikan bug apa pun, kita jadi bertanya, “Jadi artinya memang tidak ada bug?” Pada akhirnya ini kembali menjadi permainan reputasi: memilih alat terbaik atau tim terbaik, yaitu tim yang tahu alat terbaik itu apa, lalu mencari tahu siapa mereka

• Keamanan jelas merupakan use case AI/LLM yang sangat bagus. Karena sebagian besar pekerjaannya adalah mencocokkan pola masalah keamanan yang sudah dikenal dengan teks bahasa pemrograman yang dianalisis dengan sangat presisi
  Yang menonjol adalah, pada use case yang paling kuat, perusahaan AI tampaknya ingin menjual teknik itu sebagai layanan alih-alih menjual output mentah. Saat nilai output rendah, mereka menjual token
  Jika token AI benar-benar semagis itu untuk menciptakan nilai baru dalam pengembangan aplikasi perangkat lunak secara umum, mereka tidak akan menjual token secara langsung. Mereka akan menimbun token dan memakainya untuk menguasai perangkat lunak SaaS di industri mana pun yang mereka inginkan
  Ini mirip seperti orang yang menjual kursus mahal tentang pasar saham memberi sinyal bahwa, dibanding memakai pengetahuannya untuk langsung menghasilkan uang di pasar saham, dia punya lebih banyak keuntungan dari menjual kursus

  • Atau mereka mungkin ingin diversifikasi
    Untuk membangun produk dengan token AI, mereka harus membuat dan menjual keseluruhan produk, sesuatu yang belum banyak mereka kuasai, dan mereka akan bersaing dengan pelanggan mereka sendiri. Itu bukan posisi yang bagus bagi pemasok AI yang masih memantapkan diri. Itu akan menjadi distraksi besar saat bisnis yang ada saja sudah sangat sibuk, dan secara strategis juga tidak terlalu bernilai
  • Saya tidak paham logika “mereka harus menimbun token dan menguasai perangkat lunak SaaS di industri mana pun yang mereka inginkan”
    Saya pernah menjalankan dan menjual SaaS yang cukup sukses, dan bagian yang melelahkan serta bikin frustrasi adalah hal-hal yang tidak bisa dibantu LLM. Mengoding produk bukan bottleneck, juga bukan faktor yang menjamin kesuksesan
  • Kesimpulan itu sama sekali tidak mengikuti. Pendapatan Anthropic dari penjualan token tumbuh 10x YoY
    Bahkan kalau token mereka benar-benar ajaib, dan mereka bisa masuk ke industri yang ada, menyingkirkan pemain lama, lalu tumbuh 100% per tahun di industri itu, tetap lebih baik memprioritaskan penjualan token. Karena itu sendiri sudah merupakan bisnis yang hebat
    Yang ditunjukkan logika itu hanya bahwa ada batasnya. Token tidak cukup kuat untuk langsung menghasilkan uang tanpa batas di semua area software. Dan itu tampaknya benar
  • Interpretasi lain adalah bahwa membangun ekosistem lebih bernilai dalam jangka panjang
    Awalnya banyak perusahaan melarang karyawannya menulis source code ke LLM jarak jauh karena kekhawatiran keamanan. Sekarang banyak perusahaan mulai percaya bahwa karena kekhawatiran keamanan, semua source code harus dianalisis oleh LLM jarak jauh
    Jika mempercayai Anthropic menjadi hal yang dinormalisasi, mereka akan bisa menjual lebih banyak layanan yang memerlukan akses ke source code
  • Mengejutkan bahwa belum ada pembaruan MetaSploit AI terintegrasi yang mulai menelepon dan mengirim pesan ke banyak orang di dalam perusahaan sampai menemukan orang yang terlihat rentan, lalu diserahkan ke red team manusia atau diarahkan lebih langsung oleh mereka

• Sedikit topik lain, tapi sepertinya seseorang sedang membunuh semua tautan GitHub bagus di postingan ini dengan dead/flag, dan saya tidak tahu kenapa

• Menemukan satu lubang selalu lebih mudah daripada menutup semua lubang. Para peretas juga punya alat yang sama, jadi ini adalah perlombaan senjata yang tidak bisa dimenangkan

  • Jelas bahwa LLM sangat mengubah perhitungan model ancaman, tetapi pengamatan ini saja tidak menjelaskan bagaimana atau kenapa itu berubah
    Asimetri yang disebutkan itu adalah sifat yang sudah ada pada software bahkan sebelum LLM
  • Pihak bertahan punya konteks yang tidak diketahui penyerang

• Cukup menarik. Saya sudah lama membuat dan memakai alat serupa:
  https://github.com/bobinson/vulture
  Saya cukup menderita karena false positive, dan selama ini memakai Claude + MCP seperti alat audit versi hemat. Dalam beberapa hari terakhir saya mendapat hasil yang lebih baik dari model yang dihosting Nvidia

• Sebelum tahu apakah Claude memakai token secara efisien dengan harness ini, ini mungkin tidak seberguna seperti kedengarannya

• Sudah jelas bahwa Anthropic sekarang membuat dan memaketkan harness untuk use case tertentu
  Ini semacam padanan Claude Design untuk keamanan
  Harness-nya berbeda, packaging-nya berbeda, dan persona targetnya berbeda, jadi cara distribusinya juga tentu berbeda
  Yang menarik, kalau melihat tulisan perusahaan yang melaporkan tentang Mythos, semuanya membuat harness sendiri. Cisco bahkan memublikasikan spesifikasi salah satunya
  Tetapi yang berhasil menemukan cara untuk memaketkan dan mendistribusikannya adalah Anthropic. Ini strategi go-to-market yang bagus

  • Postingan ini dan organisasi GitHub itu juga menimbulkan salah paham. Anthropics dan Anthropic itu berbeda