Defending Code Reference Harness - เฟรมเวิร์กโอเพนซอร์สจาก Anthropic สำหรับค้นหาและแก้ไขช่องโหว่ด้วย AI
(github.com/anthropics)- Defending Code Reference Harness คือชุดอ้างอิงสำหรับให้ Claude ทำการค้นหาและแก้ไขช่องโหว่แบบอัตโนมัติ โดยเป็นโครงการที่จัดทำขึ้นจากบทเรียนที่ได้จากการทำงานร่วมกับทีมความปลอดภัยของหลายองค์กร
- ที่เก็บนี้ไม่ใช่ผลิตภัณฑ์ แต่เป็น ชุดอ้างอิง และปัจจุบันไม่มีการบำรุงรักษาแล้ว รวมถึงไม่รับ contribution
- Anthropic มีทางเลือกแบบ managed ในชื่อ Claude Security ซึ่งสามารถค้นหาและแก้ไขช่องโหว่ในซอร์สโค้ดของหลายโปรเจกต์ พร้อมจัดการวงจรชีวิตของ triage, fix validation และ rapid fix generation ได้
- skills สำหรับ Claude Code มี
/quickstart,/threat-model,/vuln-scan,/triage,/patch,/customizeและรองรับการกำหนดขอบเขตแบบโต้ตอบ การสแกน การ triage และงานแพตช์ harness/คือไปป์ไลน์อ้างอิงแบบอัตโนมัติของลำดับงาน recon → find → verify → report → patch และปรับให้เหมาะกับการค้นหาช่องโหว่หน่วยความจำใน C/C++ โดยใช้ Docker และ ASAN- โครงสร้างทั่วไปของไปป์ไลน์อ้างอิง พรอมป์ต์ และวิธี sandboxing สามารถนำกลับมาใช้ได้ แต่จะไม่ทำงานได้ทันทีในทุกโค้ดเบส และต้องพอร์ตให้เข้ากับภาษา ตัวตรวจจับ และประเภทช่องโหว่ผ่าน
/customize /quickstart,/threat-model,/vuln-scan,/triageและ/patchสำหรับผลลัพธ์แบบสแตติกจะทำเพียงอ่านและเขียนไฟล์เท่านั้น และสามารถรันใน Claude Code โดยไม่ต้องใช้แซนด์บ็อกซ์ได้ หากมีการตรวจสอบและอนุมัติการใช้เครื่องมือแต่ละตัว- ไปป์ไลน์อ้างอิงแบบอัตโนมัติ และ
/patchสำหรับผลลัพธ์ของไปป์ไลน์จะรันโค้ดเป้าหมาย จึงปฏิเสธการทำงานนอก gVisor sandbox เว้นแต่จะมีการข้ามอย่างชัดแจ้ง - การรันไปป์ไลน์ต้องเตรียม gVisor และอิมเมจของเอเจนต์ด้วย
scripts/setup_sandbox.shและต้องมี Docker พร้อมตัวแปรสภาพแวดล้อมANTHROPIC_API_KEYหรือCLAUDE_CODE_OAUTH_TOKEN - ขั้นตอนการรันแบ่งเป็น build, recon, find, verify, dedupe, report และ patch โดยเอเจนต์ find จะสร้าง malformed input ในคอนเทนเนอร์ที่แยกออกมา และค้นหาต่อจนกว่าไบนารี ASAN จะ crash ครบ 3 จาก 3 ครั้ง
- ขั้น verify จะมี grader agent แยกต่างหากที่รับเฉพาะ proof of concept ไปยังคอนเทนเนอร์ใหม่เพื่อทำซ้ำการ crash และขั้น dedupe จะตัดสินว่าเป็นบั๊กใหม่ เป็นตัวอย่างที่ดีกว่าของบั๊กเดิม หรือเป็นรายการซ้ำ
- ขั้น report จะเขียน exploitability analysis แบบมีโครงสร้าง ซึ่งรวม primitive class, reachability, escalation path และ severity ส่วนขั้น patch จะสร้างแนวทางแก้ไข แล้วตรวจสอบการ build การไม่ crash ของ proof of concept เดิม การผ่านการทดสอบ และการค้นหาซ้ำว่าถูก bypass ได้หรือไม่
- โฟลว์การใช้งานเริ่มต้นคือ Day 1 สร้าง threat model พร้อม static scan, triage และ candidate patch, Day 2 สร้าง findings ที่ยืนยันได้จากการรันจริงในไลบรารี C/C++, และ Days 3-5 สร้าง
targets/<your-service>/สำหรับเป้าหมายของตนเอง - เมื่อต้องพอร์ตไปยังสแตกของตนเอง ต้องกำหนดสัญญาณของ finding รูปแบบของ proof of concept และวิธี build/รัน โดยชุดอ้างอิง C/C++ ใช้ ASAN crash signature, crashing input file และ Dockerfile ที่อิง clang+ASAN เป็นเกณฑ์
- triage และ patching แบบอัตโนมัติยังคงเป็นปัญหาที่เปิดอยู่ และแม้กลยุทธ์การตรวจสอบของ
/patchจะยกระดับมาตรฐาน แต่ severity และลำดับความสำคัญยังขึ้นกับการตัดสินตามแต่ละสภาพแวดล้อม และแพตช์ที่ผ่านการยืนยันแล้วก็ไม่ได้หมายความว่าจะ upstream ได้เสมอไป
1 ความคิดเห็น
ความเห็นจาก Hacker News
นี่ใกล้เคียงกับ จิ๊กในเวิร์กช็อป มากกว่า ถ้าอยากได้ก็ซื้อ crosscut sled ได้ แต่ช่างไม้ส่วนใหญ่ทำใช้เอง
เมื่อ 2 ปีก่อน สถานการณ์ต่างออกไปเพราะต้นทุนในการทำ harness ของตัวเองสูง แต่ตอนนี้ดูเหมือนว่าวิธีที่ดีที่สุดคือมองของพวกนี้เป็นแรงบันดาลใจด้านไอเดีย แล้วทำขึ้นเองให้เข้ากับวิธีทำงาน อินเทอร์เฟซ เป้าหมาย นิยามของ effort และวิธีแจ้งเตือนของตัวเอง
ก่อนยุค AI การทำซอฟต์แวร์มาแก้ปัญหาของตัวเองต้องใช้แรงคนเยอะ เลยยอมลงแรงเพิ่มเพื่อทำให้มันเป็นแบบทั่วไปที่คนอื่นเอาไปใช้ต่อได้ แต่ตอนนี้แทบไม่ต้องออกแรงแล้ว ซอฟต์แวร์เลยคงสภาพไม่ถูกทำให้เป็นแบบทั่วไป
ช่วงนี้ฉันแทบไม่แชร์สิ่งที่ตัวเองทำเลย[0] เพราะมันไม่น่าจะช่วยคนอื่นได้มากนัก และถ้าใครต้องการอะไรคล้ายกัน เขาก็สร้างของที่พอดีกับตัวเองได้เลย แทนที่จะมาขยายหรือแก้ของฉัน เหมือนจิ๊กนั่นแหละ
0: https://redfloatplane.lol/blog/17-why-share/ และบทความที่เกี่ยวข้อง
ในชีวิตเรามีหลายกรณีที่การสร้าง เครื่องมือเฉพาะจุดประสงค์ จะดีกว่า และทุกครั้งที่มีโมเดลใหม่ออกมา ความซับซ้อนของเครื่องมือพวกนี้ก็ยิ่งเพิ่มขึ้น
ของแบบนี้เป็นเครื่องมือส่วนตัวจริง ๆ มันแก้ปัญหาที่คนอื่นก็อาจมีได้ แต่ผูกติดกับวิธีทำงานเฉพาะตัวมาก จนอธิบายหรือปรับให้คนอื่นใช้ตามได้ยาก เพราะงั้นมันจึงเป็นจิ๊กในเวิร์กช็อป
ฉันเองก็มีสคริปต์และโปรแกรมปรับแต่งเฉพาะทางแบบนี้อยู่ราว 10 ชิ้น และนี่เป็นครั้งแรกนับตั้งแต่สมัยมหาวิทยาลัยที่รู้สึกแบบนี้ ตอนนั้นมีเวลาแต่งค่าตั้งค่าตามใจชอบ ส่วนตอนนี้เรามี เอเจนต์
อยากเอาไปให้เพื่อนดูเหมือนกัน แต่พอลองไล่ในหัวว่าจะอธิบายยังไง ก็คิดว่าพวกเขาคงไม่เข้าใจความประหลาดหลายอย่างของมัน เพราะมันเป็นความประหลาดของฉันเอง มันคือชิ้นส่วนเทคนิคที่ค่อนข้างซับซ้อนและแก้ปัญหาของฉันได้ดีมาก และปัญหาเหล่านั้นก็เป็นรูปแบบย่อยเชิงส่วนตัวของปัญหาที่กว้างกว่า อย่างน้อยตอนนี้ฉันก็ยังไม่คิดจะซัพพอร์ตมัน
ชัดเจนมากว่าเรากำลังไปในทิศทางนี้ แต่คนจำนวนมากก็ยังเชื่อว่าโค้ดเป็นเรื่องของชนชั้นหัวกะทิ โค้ดสำหรับทำผลิตภัณฑ์อาจยังเป็นแบบนั้นได้ แต่ส่วนที่เหลือดูเหมือนว่าอีกไม่นานแม้แต่คอมพิวเตอร์ของพ่อแม่เราก็จะรันโค้ดที่เขียนขึ้นมาเพื่อตัวมันเอง โดยตรง เรื่องความปลอดภัยก็น่ากลัว แต่พอคิดดูก็น่าสนใจ
แถมถึงจะทำเอง เวิร์กโฟลว์ AI ของฉันที่ขัดเกลามาหลายเดือนก็กลายเป็นของล้าสมัยไปทันทีเพราะ ultracode
ฉันคิดว่าในหลายองค์กร จำนวนผู้ใช้ที่เข้ามาหาทีมที่รับผิดชอบงานพวกนี้กำลังลดลงเรื่อย ๆ
ต้นทุนของการสร้างของเองถูกเกินไป และต้นทุนของการติดอยู่กับองค์ประกอบพื้นฐานของคนอื่นแพงเกินไป
แต่การยึด AI coding เข้ากับเครื่องมือที่มีอยู่เดิมนั้นทรงพลังมหาศาล
สงสัยว่าค่าใช้จ่ายในการรันสิ่งนี้อยู่ที่เท่าไร
ตาม https://github.com/anthropics/defending-code-reference-harne... ระบุว่า:
อาจต่างกันถึงระดับเลขหลักเดียวเท่าตัวเลยก็ได้
ดูจากเครื่องคิดเลขนี้ บริษัทที่มีนักพัฒนา 100 คนอาจมีค่าใช้จ่ายโทเค็นต่อปีไปถึง 2.5 ล้านดอลลาร์ ซึ่งค่อนข้างช็อก
https://ai-cost-calculator.arnica.io
แต่ถ้ารันผ่าน API ค่าใช้จ่ายน่าจะพุ่งเร็ว
มันเป็นแค่ค่าประมาณ จึงอาจคลาดเคลื่อนได้ แต่ก็แสดงช่วงคร่าว ๆ ตามประสบการณ์ของเรา อยากได้ฟีดแบ็ก
แต่ถึงจะใช้ตัวเลขที่สูงกว่านั้น มันก็อาจยังเป็นเพียงประมาณหนึ่งในสิบของต้นทุนสัญญางานด้านความปลอดภัยแบบเป็นทางการสำหรับการค้นพบที่เครื่องมือพวกนี้เล็งไว้ ผลลัพธ์แบบนี้ไม่ได้มาจากแค่ PR review หรือ
/security-reviewแต่ต้องให้ผู้เชี่ยวชาญเป็นคนนำงานเตรียมการล่วงหน้าของเฟรมเวิร์กโอเพนซอร์ส และฉันยังไม่ได้รวมเวลาและความล่าช้าในการหาวิธีดำเนินสัญญาแบบนั้นไว้ด้วยพูดตรง ๆ คือ ถ้ามันสำคัญ ต่อให้การสแกนครั้งเดียวกินงบ vibe coding หนึ่งเดือน มันก็ยังถูกมากในระดับ “ไม่กี่เซ็นต์ต่อดอลลาร์”
ขณะเดียวกัน ผลลัพธ์ที่ได้ก็ยังต้องอาศัยผู้เชี่ยวชาญอยู่ดี ข้อเสนอแนะอาจมีประโยชน์มาก หรืออาจเป็นโทษอย่างจริงจังก็ได้ และมันขึ้นกับคุณภาพของงานเตรียมการล่วงหน้า
ถ้าเป็นหัวหน้าฝ่ายไอที ฉันคงแนะนำให้จ่ายเงินไม่กี่พันดอลลาร์เพื่อรันสิ่งนี้ เอาผลลัพธ์ที่น่ากลัวไปใช้ของบ แล้วสร้างความสัมพันธ์กับทีม red team ที่สามารถช่วยค้นหา จัดประเภท และถ้าจำเป็นก็ช่วยแก้ช่องโหว่ พร้อมทั้งฝึกทีมภายในให้มีแนวคิดแบบ มุ่งเน้นความปลอดภัย ได้
“ที่เก็บนี้ไม่ได้รับการบำรุงรักษาและไม่รับ contribution”
หืม :)
https://github.com/space-bacon/SRT
สามารถปรับปรุง fixed model ทั้งหมดได้อย่างมากภายในชั่วข้ามคืน ไปกันเลย
จากประสบการณ์ของเรา ถ้าไม่มี harness ที่ดี ก็แทบไม่ได้อะไรจาก codex/claude มากนัก และคุณต้องเสียเวลาและพลังงานไปกับการหาว่าทำไม coding agent ถึงหา bug ที่มนุษย์หาเจอไม่ได้
ในฐานะ auditor ผมเห็น bug ทุกสัปดาห์ที่ harness ของเรา(https://zkao.io/) หาไม่เจอ และต้องค้นหาเทคนิคที่ค่อนข้างน่าสนใจเพื่อทำให้เครื่องมือหา bug แบบนั้นเจอ ที่พูดถึงตรงนี้ส่วนใหญ่คือ ช่องโหว่ทางคริปโตกราฟี ไม่ใช่ bug เว็บแอปธรรมดา
เพราะงั้นจึงดูสมเหตุสมผลที่บริษัทต่าง ๆ จะมี harness ของตัวเอง และยอมจ่ายให้กับบริการที่มุ่งสร้าง harness ที่ดีจากประสบการณ์จริง บริษัท audit ที่เห็น bug จำนวนมากและใช้เวลา “สอน” bug เหล่านั้นให้กับ harness น่าจะทำเรื่องนี้ได้ดีที่สุด
ในทางกลับกัน การจัดประเภทก็ต้องใช้เทคนิคที่ดีพอ ๆ กัน ไม่อย่างนั้นก็จะเกิดเครื่องจักรที่ผมเรียกว่า vibe auditing ซึ่งปล่อยแต่ false positive มากพอจะทำให้นักพัฒนาที่เหนื่อยกับ AI submission คุณภาพแย่ใน bug bounty และเครื่องมือ AI ที่รีวิวทุก PR ยิ่งล้าเข้าไปอีก
สุดท้าย ถ้า harness ไม่ส่ง bug กลับมาเลย คุณก็จะเริ่มคิดว่า “งั้นแปลว่าไม่มี bug ใช่ไหม?” สุดท้ายมันก็ย้อนกลับไปเป็นเกมเรื่องชื่อเสียงในการเลือกเครื่องมือที่ดีที่สุดหรือทีมที่ดีที่สุด ซึ่งก็คือทีมที่รู้ว่าเครื่องมือที่ดีที่สุดคืออะไร และต้องหาว่าใครคือทีมนั้น
ความปลอดภัยเป็น use case ของ AI/LLM ที่ยอดเยี่ยมอย่างชัดเจน เพราะงานส่วนใหญ่คือการนำรูปแบบของปัญหาความปลอดภัยที่รู้จักอยู่แล้วไปเทียบกับข้อความภาษาการเขียนโปรแกรมที่ต้องวิเคราะห์อย่างละเอียดมาก
สิ่งที่น่าสังเกตคือ ใน use case ที่ทรงพลังที่สุด บริษัท AI พยายามขายเทคนิคนั้นในรูปแบบบริการ แทนที่จะขายผลลัพธ์ดิบ ๆ ถ้ามูลค่าของ output ต่ำ พวกเขาก็ขาย token
ถ้า AI token มีความมหัศจรรย์พอจะสร้างมูลค่าใหม่ในการพัฒนาแอปพลิเคชันซอฟต์แวร์ทั่วไปได้จริง พวกเขาคงไม่ขาย token ตรง ๆ แต่จะกัก token ไว้และใช้มันเพื่อยึดครองซอฟต์แวร์ SaaS ในทุกอุตสาหกรรมที่ต้องการ
มันคล้ายกับคนที่ขายคอร์สราคาแพงเรื่องตลาดหุ้น ซึ่งเป็นสัญญาณว่าการขายคอร์สให้ผลตอบแทนมากกว่าการเอาความรู้นั้นไปทำเงินในตลาดหุ้นด้วยตัวเอง
การสร้างผลิตภัณฑ์จาก AI token หมายความว่าพวกเขาต้องสร้างและขายผลิตภัณฑ์ครบวงจร ซึ่งเป็นสิ่งที่พวกเขายังมีประสบการณ์น้อยกว่า และยังต้องไปแข่งขันกับลูกค้าของตัวเองด้วย นี่ไม่ใช่ตำแหน่งที่ดีสำหรับผู้ให้บริการ AI ที่ยังอยู่ระหว่างการตั้งหลัก ทั้งยังเป็นสิ่งที่ทำให้เสียสมาธิมาก ในเมื่อธุรกิจเดิมก็มีเรื่องให้จัดการมากพออยู่แล้ว และในเชิงกลยุทธ์ก็ไม่ได้มีคุณค่ามากนัก
ผมเคยทำ SaaS ที่ประสบความสำเร็จในระดับใช้ได้และขายกิจการได้ ส่วนที่เหนื่อยและน่าหงุดหงิดคือสิ่งที่ LLM ช่วยไม่ได้ การเขียนโค้ดตัวผลิตภัณฑ์ไม่ใช่คอขวด และก็ไม่ใช่ปัจจัยที่รับประกันความสำเร็จ
ต่อให้ token ของพวกเขามหัศจรรย์จริง และสามารถเข้าไปในอุตสาหกรรมเดิม แย่งลูกค้าเดิม และเติบโต 100% ต่อปีในอุตสาหกรรมนั้นได้ การให้ความสำคัญกับการขาย token ก่อนก็ยังดีกว่าอยู่ดี เพราะมันเป็นธุรกิจที่ยอดเยี่ยมในตัวมันเอง
สิ่งที่ตรรกะนี้แสดงให้เห็นก็แค่ว่ามีข้อจำกัดอยู่บ้าง token ยังไม่ได้ทรงพลังถึงระดับสร้างเงินได้ไม่จำกัดทันทีในทุกส่วนของซอฟต์แวร์ ซึ่งก็ดูจะเป็นความจริง
ในช่วงแรก หลายบริษัทห้ามพนักงานป้อนซอร์สโค้ดลงใน LLM ระยะไกลเพราะความกังวลด้านความปลอดภัย ตอนนี้กลับมีหลายบริษัทที่เริ่มเชื่อว่าเพราะเหตุผลด้านความปลอดภัย พวกเขาควรวิเคราะห์ซอร์สโค้ดทั้งหมดด้วย LLM ระยะไกล
ถ้าการเชื่อใจ Anthropic กลายเป็นเรื่องปกติ พวกเขาก็จะขายบริการอื่น ๆ ที่ต้องเข้าถึงซอร์สโค้ดได้มากขึ้น
พูดอีกเรื่องนิดหน่อย เหมือนว่าจะมีใครบางคนคอยกดให้ลิงก์ดี ๆ ใน GitHub ของโพสต์นี้เป็น dead/flag จนหายหมด แต่ไม่เข้าใจว่าทำไปทำไม
การหาเพียงช่องโหว่เดียว ง่ายกว่าการอุดทุกช่องโหว่เสมอ และเพราะแฮกเกอร์ก็มีเครื่องมือแบบเดียวกัน นี่จึงเป็น การแข่งขันสะสมอาวุธ ที่ไม่มีทางชนะ
ความไม่สมมาตร ที่พูดถึงนั้นเป็นคุณสมบัติที่มีอยู่ในซอฟต์แวร์ก่อนยุค LLM อยู่แล้ว
ค่อนข้างน่าสนใจ ผมสร้างและใช้เครื่องมือคล้าย ๆ กันมาพักหนึ่งแล้ว:
https://github.com/bobinson/vulture
เจอปัญหา false positive หนักเหมือนกัน และใช้ Claude + MCP เป็นเหมือนเครื่องมือ audit แบบคนงบน้อย ช่วงไม่กี่วันที่ผ่านมานี้ได้ผลลัพธ์ที่ดีกว่าจาก โมเดลที่โฮสต์โดย Nvidia
จนกว่าจะรู้ว่า Claude ใช้ token ได้มีประสิทธิภาพกับ harness นี้หรือไม่ มันอาจไม่ได้มีประโยชน์เท่าที่ฟังดู
ชัดเจนว่า Anthropic ตอนนี้กำลังสร้างและทำให้ harness สำหรับ use case เฉพาะกลายเป็นสินค้า
มันเหมือนกับ Claude Design เวอร์ชันสำหรับงานความปลอดภัย
harness ต่างกัน การแพ็กเกจก็ต่างกัน และ persona เป้าหมายก็ต่างกัน ดังนั้นวิธีกระจายจึงต่างกันเป็นธรรมดา
สิ่งที่น่าสนใจคือ ถ้าดูโพสต์ของบริษัทต่าง ๆ ที่รายงานเกี่ยวกับ Mythos จะเห็นว่าทุกคนต่างก็สร้าง harness ของตัวเอง Cisco ถึงขั้นเผยแพร่สเปกของหนึ่งในนั้นออกมาด้วย
แต่ Anthropic คือฝ่ายที่หาวิธีแพ็กเกจและกระจายสิ่งนี้ได้ นี่เป็น กลยุทธ์การเข้าสู่ตลาด ที่ยอดเยี่ยม