Defending Code Reference Harness - Framework mã nguồn mở của Anthropic để phát hiện và sửa lỗ hổng bằng AI
(github.com/anthropics)- Defending Code Reference Harness là bản triển khai tham chiếu để thực hiện phát hiện và sửa lỗ hổng tự động bằng Claude, được xây dựng dựa trên những bài học rút ra từ quá trình hợp tác với các nhóm bảo mật của nhiều tổ chức
- Kho lưu trữ này không phải là sản phẩm mà là bản triển khai tham chiếu, hiện không được bảo trì và cũng không nhận đóng góp
- Anthropic cung cấp phương án thay thế được quản lý là Claude Security, có thể tìm và sửa lỗ hổng trong mã nguồn của nhiều dự án, đồng thời quản lý vòng đời triage, xác thực bản vá và tạo bản sửa nhanh
- Các skill cho Claude Code cung cấp
/quickstart,/threat-model,/vuln-scan,/triage,/patch,/customize, hỗ trợ xác định phạm vi tương tác, quét, triage và vá lỗi harness/là pipeline tham chiếu tự động theo luồng recon → find → verify → report → patch, được tối ưu cho việc tìm kiếm lỗ hổng bộ nhớ trong C/C++ bằng Docker và ASAN- Có thể tái sử dụng cấu trúc chung, prompt và cách sandbox của pipeline tham chiếu, nhưng nó không hoạt động ngay với mọi codebase và cần được port bằng
/customizecho phù hợp với ngôn ngữ, bộ dò và loại lỗ hổng /quickstart,/threat-model,/vuln-scan,/triagevà/patchđối với kết quả tĩnh chỉ thực hiện đọc/ghi tệp, nên có thể chạy không cần sandbox trong Claude Code nếu bạn xem xét và phê duyệt việc sử dụng từng công cụ- Pipeline tham chiếu tự động và
/patchcho kết quả của pipeline có thực thi mã mục tiêu, nên sẽ từ chối chạy bên ngoài sandbox gVisor trừ khi bị bỏ qua một cách rõ ràng - Để chạy pipeline cần chuẩn bị gVisor và image tác tử bằng
scripts/setup_sandbox.sh, đồng thời cần Docker và biến môi trườngANTHROPIC_API_KEYhoặcCLAUDE_CODE_OAUTH_TOKEN - Các bước thực thi được chia thành build, recon, find, verify, dedupe, report, patch; tác tử find tạo malformed input trong container cô lập và tiếp tục tìm kiếm cho đến khi binary ASAN crash 3/3 lần
- Ở bước verify, một tác tử grader riêng trong container mới chỉ nhận proof of concept để tái hiện crash; bước dedupe xác định đó là lỗi mới, ví dụ tốt hơn của lỗi cũ hay là trùng lặp
- Bước report viết phân tích khả năng khai thác có cấu trúc gồm primitive class, reachability, escalation path, severity; bước patch tạo bản sửa rồi xác minh build thành công, proof of concept gốc không còn crash, test vượt qua và không thể dễ dàng bị vượt qua
- Quy trình sử dụng ban đầu là: ngày 1 tạo threat model, quét tĩnh, triage và candidate patch; ngày 2 tạo các finding đã được xác minh bằng thực thi trên thư viện C/C++; ngày 3-5 tạo
targets/<your-service>/cho mục tiêu riêng - Khi port sang stack riêng, cần định nghĩa tín hiệu finding, dạng proof of concept và cách build/chạy; bản tham chiếu C/C++ lấy ASAN crash signature, crashing input file và Dockerfile dựa trên clang+ASAN làm chuẩn
- Triage và vá lỗi tự động vẫn là bài toán mở; chiến lược xác minh của
/patchnâng tiêu chuẩn, nhưng severity và mức độ ưu tiên còn phụ thuộc từng môi trường, và bản vá đã xác minh không phải lúc nào cũng có thể upstream
1 bình luận
Ý kiến trên Hacker News
Cái này giống đồ gá trong xưởng hơn. Nếu muốn thì bạn có thể mua một cái bàn trượt cắt ngang, nhưng đa số thợ mộc đều tự làm lấy
Hai năm trước thì khác vì chi phí tự làm harness của mình còn cao, nhưng bây giờ tốt nhất là xem mấy thứ này như nguồn tham khảo ý tưởng rồi tự xây theo cách làm việc, giao diện, đối tượng và định nghĩa nỗ lực, cũng như cách thông báo của riêng mình
Trước thời AI, để tạo ra phần mềm giải quyết vấn đề của chính mình cần khá nhiều công sức của con người, nên người ta thường bỏ thêm công để khái quát hóa nó để người khác cũng có thể tái sử dụng. Giờ thì chuyện đó gần như không còn tốn công nữa, nên phần mềm cứ thế giữ nguyên ở dạng không được khái quát hóa
Dạo này tôi gần như không còn chia sẻ những thứ mình làm ra[0], vì khả năng nó giúp ích cho người khác là khá thấp, và nếu họ cần thứ tương tự thì họ có thể tự làm cái khớp chính xác với mình thay vì mở rộng hay chỉnh sửa cái của tôi. Giống như đồ gá vậy
0: https://redfloatplane.lol/blog/17-why-share/ và các bài liên quan
Trong đời sống của chúng ta có rất nhiều lúc tốt hơn là nên tạo ra công cụ chuyên dụng theo mục đích, và mỗi khi model mới ra thì độ phức tạp của các công cụ đó cũng tăng lên
Đây thật sự là công cụ cá nhân. Nó giải những vấn đề mà người khác cũng có thể gặp, nhưng lại gắn chặt với cách làm việc riêng của từng người đến mức khó giải thích hay điều chỉnh cho người khác. Nên nó đúng là đồ gá trong xưởng
Bản thân tôi cũng có khoảng 10 script và chương trình kiểu tùy biến như vậy, và đây là lần đầu tiên kể từ thời đại học tôi mới lại có cảm giác này. Hồi đó là vì tôi có thời gian để tùy biến cấu hình thoải mái, còn bây giờ thì có agent
Tôi muốn khoe cho bạn bè xem, nhưng mỗi khi thử hình dung cách giải thích thực tế thì lại thấy họ sẽ không hiểu được hàng loạt điểm kỳ quặc. Vì đó là những điểm kỳ quặc của chính tôi. Chúng là các mảnh kỹ thuật khá phức tạp nhưng giải quyết cực tốt những vấn đề của riêng tôi, mà những vấn đề đó lại là biến thể cá nhân của các vấn đề rộng hơn, và ít nhất lúc này tôi không có ý định hỗ trợ chúng
Việc chúng ta đang đi theo hướng này là quá rõ ràng, vậy mà nhiều người vẫn tin code là thứ dành cho giới tinh hoa. Có thể code cho sản phẩm thì đúng là như vậy, nhưng phần còn lại thì chẳng bao lâu nữa ngay cả máy tính của bố mẹ bạn cũng sẽ chạy code do chính nó tự viết ra cho bản thân nó. Nghĩ tới bảo mật thì hơi đáng sợ, nhưng cũng rất thú vị
Hơn nữa, dù có tự làm thì các workflow AI mà tôi đã mài giũa suốt mấy tháng cũng bị ultracode làm cho lỗi thời ngay lập tức
Tôi nghĩ ở nhiều tổ chức, số người dùng tìm đến các đội phụ trách kiểu việc này đang ngày càng ít đi
Chi phí để tự làm cái của mình giờ quá rẻ, còn chi phí bị mắc kẹt trong những khối cấu thành cơ bản của người khác thì quá đắt
Nhưng việc neo AI coding vào các công cụ sẵn có thì vẫn cực kỳ mạnh mẽ
Tôi tò mò không biết chạy cái này tốn bao nhiêu tiền
Theo https://github.com/anthropics/defending-code-reference-harne...:
Có lẽ còn có thể chênh tới một bậc độ lớn một chữ số
Nhìn vào cái calculator này thì khá sốc: một công ty có 100 lập trình viên có thể tốn khoảng 2,5 triệu USD tiền token mỗi năm
https://ai-cost-calculator.arnica.io
Chỉ là nếu chạy qua API thì có vẻ chi phí sẽ phình ra rất nhanh
Đây là ước tính nên có thể sai, nhưng ít nhất nó cho thấy một khoảng giá gần đúng dựa trên kinh nghiệm của chúng tôi. Tôi rất muốn nghe phản hồi
Nhưng ngay cả nếu lấy con số lớn hơn, nó vẫn có thể chỉ bằng khoảng 1/10 chi phí của một hợp đồng bảo mật chính thức cho kiểu phát hiện mà công cụ này nhắm tới. Đây là những kết quả không thể có chỉ từ PR review hay
/security-review, mà cần chuyên gia dẫn dắt phần chuẩn bị ban đầu của framework open source. Tôi thậm chí còn chưa tính thời gian và độ trễ để tìm ra cách triển khai một hợp đồng như vậyNói thẳng ra, nếu việc đó quan trọng thì ngay cả khi một lần quét tiêu tốn cả ngân sách vibe coding của một tháng, nó vẫn cực kỳ rẻ theo kiểu “vài xu trên mỗi đô la”
Đồng thời, kết quả đó vẫn cần chuyên gia xử lý. Các đề xuất có thể hữu ích, cũng có thể gây hại nghiêm trọng, và điều đó phụ thuộc vào chất lượng phần chuẩn bị ban đầu
Tôi sẽ khuyên một trưởng bộ phận IT nên bỏ vài nghìn đô để chạy cái này, dùng trang kết quả đầy đáng sợ đó để xin ngân sách, rồi xây dựng quan hệ với một red team có thể giúp tìm ra lỗ hổng, phân loại chúng, sửa nếu cần, và huấn luyện đội nội bộ theo hướng đặt bảo mật làm trọng tâm
“Kho lưu trữ này không còn được bảo trì và không nhận đóng góp.”
Hừm :)
https://github.com/space-bacon/SRT
Có thể cải thiện đáng kể mọi mô hình đã tinh chỉnh chỉ sau một đêm. Làm thôi
Theo kinh nghiệm của chúng tôi, nếu không có harness tốt thì chẳng khai thác được bao nhiêu từ codex/claude. Và phải tốn rất nhiều thời gian, công sức để tìm ra vì sao các coding agent lại không phát hiện được những lỗi mà con người tìm ra
Với tư cách kiểm toán viên, tuần nào tôi cũng thấy các lỗi mà harness của chúng tôi (https://zkao.io/) không tìm ra, và phải khám phá ra những kỹ thuật khá thú vị để khiến công cụ tìm được các lỗi đó. Ở đây chủ yếu là lỗ hổng mật mã học, chứ không phải lỗi webapp đơn giản
Vì vậy, có vẻ hợp lý khi các công ty vừa có harness riêng, vừa trả tiền cho những dịch vụ tập trung vào việc xây dựng harness tốt dựa trên kinh nghiệm. Các công ty kiểm toán có thể xem được nhiều lỗi và có thời gian để “dạy” những lỗi đó cho harness có lẽ sẽ làm việc này tốt nhất
Ngược lại, khâu phân loại cũng cần những kỹ thuật tốt tương ứng. Nếu không thì sẽ tạo ra thứ mà tôi gọi là kiểm toán kiểu vibe, chỉ tuôn ra đủ loại dương tính giả để làm các lập trình viên vốn đã mệt mỏi vì những bài nộp AI chất lượng thấp trong bug bounty và các công cụ AI review mọi PR càng thêm kiệt sức
Cuối cùng, nếu harness không trả về lỗi nào, bạn lại phải băn khoăn “vậy có nghĩa là không có lỗi nào sao?”. Rốt cuộc, mọi thứ lại quay về trò chơi danh tiếng: chọn công cụ tốt nhất hoặc đội ngũ tốt nhất, tức là đội biết công cụ nào là tốt nhất, rồi tìm xem đó là ai
Bảo mật rõ ràng là một ca sử dụng AI/LLM rất tuyệt vời. Vì phần lớn công việc là đối chiếu các mẫu vấn đề bảo mật đã biết với văn bản ngôn ngữ lập trình cực kỳ chính xác của đối tượng phân tích
Điều đáng chú ý là trong những ca sử dụng mạnh nhất, các công ty AI dường như muốn bán kỹ thuật đó dưới dạng dịch vụ hơn là bán đầu ra thô. Khi giá trị của đầu ra thấp thì họ bán token
Nếu token AI thực sự kỳ diệu đến mức tạo ra giá trị mới trong phát triển ứng dụng phần mềm nói chung, thì họ đã không trực tiếp bán token. Họ sẽ tích trữ token và dùng chúng để thống trị phần mềm SaaS ở bất kỳ ngành nào họ muốn
Điều này hơi giống tín hiệu khi một người bán khóa học đắt tiền về thị trường chứng khoán có vẻ kiếm được nhiều hơn từ việc bán khóa học thay vì trực tiếp kiếm tiền trên thị trường bằng chính kiến thức của mình
Để xây dựng sản phẩm bằng token AI, họ phải xây dựng và bán một sản phẩm hoàn chỉnh mà họ ít kinh nghiệm hơn, đồng thời cạnh tranh với chính khách hàng của mình. Đó không phải vị thế tốt cho một nhà cung cấp AI còn đang trong giai đoạn ổn định. Chỉ riêng việc kinh doanh hiện tại đã có quá nhiều thứ phải xử lý, nên đây là một sự xao nhãng lớn và về mặt chiến lược cũng không có nhiều giá trị
Tôi đã từng vận hành và bán một SaaS thành công ở mức khá, và những phần mệt mỏi, bực bội là những thứ LLM không thể giúp. Việc code sản phẩm không phải nút thắt cổ chai, cũng không phải yếu tố đảm bảo thành công
Ngay cả nếu token của họ thật sự kỳ diệu, và họ có thể bước vào các ngành hiện hữu, đẩy bật những công ty đang có mặt ở đó và tăng trưởng 100% mỗi năm trong ngành đó, thì ưu tiên bán token vẫn tốt hơn. Vì bản thân nó đã là một công việc kinh doanh tuyệt vời
Điều mà lập luận này cho thấy chỉ là nó có giới hạn. Token không mạnh đến mức ngay lập tức tạo ra tiền vô hạn trong mọi ngóc ngách của phần mềm. Điều đó có vẻ là sự thật
Ban đầu, nhiều công ty cấm nhân viên đưa mã nguồn vào LLM từ xa vì lo ngại bảo mật. Giờ thì nhiều công ty bắt đầu tin rằng chính vì lo ngại bảo mật, mọi mã nguồn phải được phân tích bằng LLM từ xa
Nếu việc tin tưởng Anthropic trở thành điều bình thường, họ sẽ có thể bán thêm nhiều dịch vụ đòi hỏi quyền truy cập vào mã nguồn
Hơi lạc đề một chút, nhưng có vẻ như ai đó đang giết sạch các liên kết GitHub hay trong bài này bằng dead/flag, mà tôi không hiểu tại sao lại làm vậy
Tìm ra một lỗ hổng luôn dễ hơn bịt mọi lỗ hổng. Hacker cũng có cùng bộ công cụ, nên đây là một cuộc chạy đua vũ trang không thể thắng
Tính bất đối xứng được nhắc đến là đặc tính đã tồn tại trong phần mềm từ trước thời LLM
Khá thú vị. Tôi đã xây dựng và dùng một công cụ tương tự được một thời gian:
https://github.com/bobinson/vulture
Tôi đã vật lộn với dương tính giả, và dùng Claude + MCP như một công cụ kiểm toán kiểu nhà nghèo. Trong vài ngày gần đây, tôi có kết quả tốt hơn từ các mô hình do Nvidia host
Trước khi biết Claude dùng token hiệu quả thế nào với harness này, có thể nó không hữu ích như vẻ bề ngoài
Rõ ràng Anthropic giờ đang tạo và đóng gói harness cho các ca sử dụng cụ thể
Có thể xem đây là phiên bản tương đương với Claude Design cho bảo mật
Harness khác, cách đóng gói khác, persona mục tiêu khác, nên cách phân phối đương nhiên cũng khác
Điều thú vị là nếu xem các bài viết của công ty từng báo cáo về Mythos, thì ai cũng đang tự xây harness của riêng mình. Cisco thậm chí còn công khai đặc tả của một trong số đó
Nhưng Anthropic là bên đã tìm ra cách đóng gói và phân phối thứ này. Đây là một chiến lược thâm nhập thị trường rất tốt