OSS Scanner: đợt kiểm tra bảo mật miễn phí cho mã nguồn mở quan trọng

Thử nghĩ đến một công trình mà cả khu phố đều dựa vào: cây cầu cũ, tháp nước, dãy chung cư phía trên tiệm bánh mì. Có người đề nghị kiểm tra miễn phí, định kỳ, mỗi vết nứt một tờ ghi chú: nứt ở đâu, vì sao nứt, kèm bản phác cách sửa. Chỉ một điều kiện: người kiểm tra là một cỗ máy, và chẳng ai đọc lại ghi chú của nó trước bạn.

Đại khái đó là thứ Anthropic mở ra ngày 8/10/2026 với tên gọi OSS Scanner. Dưới đây là chương trình này là gì, dành cho ai, và dùng sao cho khỏi bị ngợp vì báo cáo.

Ý tưởng trong một câu

OSS Scanner là dịch vụ miễn phí, tự nguyện đăng ký, trong đó Anthropic dùng những mô hình mạnh nhất của mình để quét định kỳ các dự án mã nguồn mở quan trọng, rồi gửi email cho maintainer những gì tìm được, mỗi báo cáo kèm cách tái hiện lỗi và, khi làm được, một bản vá đề xuất, mà không qua người duyệt trước khi gửi.

Chương trình làm gì

Khi dự án đã được nhận, scanner build dự án từ Dockerfile do bạn cung cấp trong một máy ảo cô lập, rồi ngắt Internet và chạy phân tích trong một sandbox được gia cố. Theo trang dịch vụ, các agent kiểm tra chéo lỗi, đề xuất bản vá và phân tích nguyên nhân gốc, dùng nhiều harness, có cái tốn kém hoặc còn thử nghiệm, để đào tới những lỗi nằm sâu hơn. Việc quét được lặp lại theo thời gian để bắt cả lỗi mới phát sinh lẫn lỗi lần trước bỏ sót; tần suất không cố định, tùy vào tải hệ thống và mức độ dự án được sử dụng.

Trang dịch vụ chỉ nói « những mô hình mạnh nhất của chúng tôi », không nêu tên mô hình nào cho dịch vụ này. Một số bài báo nhắc đến Claude Mythos, nhưng mình không tìm được xác nhận trên các trang của Anthropic, nên không khẳng định.

Một báo cáo gồm những gì

Báo cáo được gửi qua email theo từng đợt (định dạng có thể thay đổi), mỗi cái có một mã như ANT-2026-ABCD1234 để ghi nhận công. Tùy trường hợp, một báo cáo có thể gồm:

• Proof of concept (PoC). Phần tái hiện lỗi: một input hoặc một đoạn script ngắn thực sự kích hoạt được lỗi. Đây là khác biệt giữa « trông có vẻ nguy hiểm » và « xem này, nó sập thật ».
• Phân tích nguyên nhân gốc. Vì sao lỗi tồn tại: thiếu kiểm tra biên, giả định sai về độ dài input. Sửa đúng nguyên nhân chứ không chỉ triệu chứng thì cũng chặn luôn được biến thể ngay bên cạnh.
• Bản vá đề xuất. Một cách sửa ứng viên, tối giản hoặc gần như merge được ngay, tùy theo yêu cầu bạn ghi trong threat model.
• Mức độ nghiêm trọng, chấm theo thang của chính dự án nếu bạn cung cấp.

Ai có thể tham gia

Tiêu chuẩn khá giống OSS-Fuzz của Google, dịch vụ fuzzing miễn phí ra đời năm 2016 sau vụ Heartbleed, vốn nhận các dự án có lượng người dùng đáng kể hoặc giữ vai trò then chốt với hạ tầng CNTT toàn cầu. Anthropic thì nói đến những dự án đã có chỗ đứng, có tác động quan trọng tới hạ tầng và an toàn của người dùng, xét duyệt theo từng trường hợp. Các yếu tố được nêu, nói nôm na:

• Mức độ phơi ra trước tấn công từ xa. Code xử lý dữ liệu đến từ mạng hay từ người lạ (parser, server, thư viện đọc định dạng file) chính là cửa ngõ cho kẻ tấn công.
• Số người dùng và số dự án phụ thuộc. Một lỗi trong thư viện được hàng nghìn dự án dùng, trên thực tế là hàng nghìn lỗi.
• Tuổi đời và tần suất cập nhật. Dự án lâu năm, còn hoạt động thì xử lý được báo cáo; dự án bỏ hoang thì không.
• OpenSSF Criticality Score. Điểm từ 0 đến 1 ước lượng mức ảnh hưởng của một dự án, tính từ các tín hiệu như tuổi đời, số người đóng góp, tần suất commit, số bản phát hành và số dự án phụ thuộc.
• Giấy phép mã nguồn mở phổ biến. Dịch vụ dành cho mã nguồn mở theo nghĩa thông thường.
• Sao, fork và số liệu sử dụng. Tín hiệu chưa hoàn hảo, nhưng cho thấy độ phủ.
• Dự án quan trọng tới đâu về bảo mật, và với những ngành nào. Một thư viện TLS nặng ký hơn nhiều so với một theme trình chiếu.
• Hồ sơ điền đủ các trường bắt buộc. Hồ sơ thiếu thì cứ thế nằm chờ.

Danh sách này chưa đầy đủ; nếu tầm quan trọng của dự án không hiển nhiên, hãy viết vài dòng giải thích vì sao nó quan trọng về bảo mật.

Ai thường không được nhận

Dự án vừa mới tạo, và các bản fork, trừ khi bản fork khác hẳn bản gốc và tự nó đủ điều kiện. Dịch vụ cũng nhắm tới những nhóm đã đủ sức theo kịp các báo cáo mức cao và nghiêm trọng đã được xác minh: nếu một loạt phát hiện nặng đổ về sẽ làm bạn tê liệt, thì còn hơi sớm. Cuối cùng, người đăng ký phải là maintainer chính hoặc được maintainer chính cho phép, và được cả công ty cho phép nếu dự án do một tổ chức duy trì.

Đăng ký từng bước

1. Fork anthropics/oss-scanner và tạo trong projects/ một thư mục mang tên dự án của bạn.

2. Thêm file project.yaml dựa trên template. Chỉ repo và primary_contact là luôn bắt buộc:

   repo: https://github.com/example/project
   primary_contact: security@example.org
   auto_ccs:
     - maintainer@example.org
   homepage: https://example.org
   disabled: false
   dockerfile: .oss-scanner/Dockerfile
   threat_model: .oss-scanner/threat_model.md
   output_format:
     email:
       min_severity: low
     github_security_advisory:
       min_severity: none

   Các địa chỉ email trong file này là công khai, nên hãy dùng một alias bảo mật thay vì hộp thư cá nhân.

3. Cung cấp Dockerfile để cài mọi dependency và build dự án. Bước build có mạng, bước kiểm tra thì không, nên hãy tải sẵn mọi thứ mà build và test cần. Nên để Dockerfile ngay trong repository của bạn: sau này sửa không cần mở pull request mới.

4. Viết threat_model.md (không bắt buộc nhưng rất nên có): dự án làm gì, dữ liệu không tin cậy đi vào từ đâu, phần nào nằm ngoài phạm vi, và bạn chấm mức nghiêm trọng thế nào.

5. Kiểm tra trên máy bằng tools/validate.py, rồi tools/check kèm tên dự án; lệnh này build image giống hệt scanner và mở một shell không có mạng. Nếu test chạy qua trong đó thì nhiều khả năng scanner cũng chạy được.

6. Mở pull request và đồng ý với điều khoản. Một người sẽ xem xét và kiểm tra liên hệ có đúng là đầu mối bảo mật thật không, chẳng hạn địa chỉ ghi trong SECURITY.md của bạn. Điều kiện tham gia được kiểm tra lại trước mỗi lần gửi báo cáo.

Muốn tạm dừng, đặt disabled thành true; muốn rút hẳn, xóa thư mục của bạn đi.

Với maintainer, điều này có nghĩa gì

Lợi ích thì rõ: một đợt audit bảo mật định kỳ mà phần lớn dự án tình nguyện không bao giờ có tiền thuê, kèm sẵn cách tái hiện và bản vá, lại được định hướng theo threat model của bạn.

Nhưng khối lượng việc cũng thật, và bản điều khoản nói rất rõ. Báo cáo do AI tạo ra và « có thể không đầy đủ, không chính xác »; bạn chịu trách nhiệm đọc lại từng báo cáo và bản vá đi kèm trước khi sửa gì. Báo cáo phải được giữ kín cho tới khi lỗi được sửa hoặc đã công bố. Những phát hiện chưa được xác minh không bị áp thời hạn công bố 90 ngày, và Anthropic nói sẽ không công khai chúng. Nếu sau này có người xác minh một phát hiện qua chương trình công bố lỗ hổng của Anthropic, lỗi đó có thể được công bố 90 ngày sau khi bạn được thông báo. Anthropic còn cho biết tương lai có thể đặt thời hạn công bố cho một số báo cáo mức nghiêm trọng cao, có báo trước và cho phép từ chối. Dịch vụ được cung cấp « nguyên trạng », và trách nhiệm của Anthropic giới hạn ở mức 1.000 đô la.

Vài thói quen giúp việc phân loại nhẹ nhàng hơn:

• Tái hiện lỗi trước tiên, trong một môi trường dùng xong là bỏ.
• Chấm lại mức nghiêm trọng theo thang của bạn, không phải của mô hình.
• Gom nhóm theo nguyên nhân gốc: năm báo cáo có khi chỉ là một lỗi.
• Review bản vá như pull request của người lạ, và báo lại các cảnh báo sai.

Với tất cả chúng ta, điều này có nghĩa gì

Bạn dùng phần mềm thì cũng là đang dùng mã nguồn mở, nên một đợt kiểm tra miễn phí cho phần móng là tin vui. Có điều tìm ra lỗi chưa phải là sửa xong. The New Stack tóm gọn trong một tiêu đề: Claude tìm ra 29.000 lỗi tiềm năng trong mã nguồn mở, nhưng mới có 516 lỗi được sửa. Điểm nghẽn chuyển từ khâu phát hiện sang quỹ thời gian của maintainer.

Đó là lý do công bố có phối hợp quan trọng: maintainer được báo riêng, có thời gian sửa, rồi chi tiết mới được công khai, để kẻ xấu không biết đến lỗ hổng trước khi người dùng kịp vá. Với phần còn lại chúng ta: cập nhật dependency đều đặn, theo dõi cảnh báo bảo mật, và ủng hộ maintainer bằng tiền hay thời gian review.

Lời kết

OSS Scanner mang đến cho các dự án quan trọng thứ trước nay chỉ những nhóm nhiều tiền mới có: một cái nhìn bảo mật đều đặn và kỹ lưỡng, kèm sẵn cách tái hiện và bản nháp để sửa. Cái giá phải trả không phải là tiền, mà là sự chú tâm. Mô hình viết báo cáo; vẫn cần một con người tái hiện, đánh giá và phát hành bản sửa.

Bài tóm tắt độc lập, không liên kết với Anthropic. Mọi thông tin đều lấy từ các nguồn bên dưới.