GitHub quét secret nhanh hơn 86%, nhưng mật khẩu không định dạng mới đáng chú ý

Trong báo cáo kỹ thuật ngày 13/10/2026, GitHub cho biết pipeline mới giảm 86% thời gian quét trung vị sau push và tăng 11,5% tỷ lệ chấp nhận cảnh báo có trọng số theo chủ kho mã so với pipeline dùng mô hình ngôn ngữ lớn trước đó; chi phí phục vụ bộ phân loại nhỏ cũng thấp hơn hơn 98% so với các lệnh gọi mô hình từ xa. Thay đổi hướng vào một loại credential khó nhận ra bằng hình dạng chuỗi: mật khẩu không có tiền tố hay định dạng token đặc trưng.

Thông báo phát hành ngày 7/10/2026 của GitHub nêu rõ mô hình đọc mã xung quanh giá trị đáng ngờ và đã thay thế mô hình dùng cho các cảnh báo Password do AI phát hiện ở khách hàng hiện có. Khả năng dùng nó để chặn secret khi push đang trong thử nghiệm riêng tư; kiểm tra secret bằng lệnh GitHub Copilot /security-review được dự kiến đưa vào thử nghiệm riêng tư sau đó. Các kết quả đo vì thế gắn với một pipeline đã vận hành, trong khi những nơi áp dụng tiếp theo có trạng thái truy cập khác nhau.

Vì sao mật khẩu không có định dạng token khó phát hiện

Token có cấu trúc thường để lại dấu hiệu như tiền tố, độ dài, bộ ký tự hoặc checksum. Với mật khẩu tự do, một chuỗi ký tự có thể là thông tin đăng nhập thật, nhưng cũng có thể là mã định danh bản dựng, giá trị mẫu trong tài liệu hoặc dữ liệu thử nghiệm. Cùng một giá trị trông giống mật khẩu sẽ mang ý nghĩa khác nhau nếu nó nằm cạnh địa chỉ cơ sở dữ liệu vận hành hoặc trong một tệp dùng để kiểm thử.

Pipeline mới xử lý sự mơ hồ đó theo hai bước. Biểu thức chính quy trước tiên tìm rộng những chuỗi có vẻ là credential; bộ phân loại ModernBERT được tinh chỉnh sau đó đánh giá từng ứng viên cùng đường dẫn tệp, tên biến, loại secret và phần mã hoặc văn bản lân cận. Đầu ra là điểm ước lượng khả năng ứng viên thực sự nhạy cảm. Những trường hợp đủ độ tin cậy được chuyển thành cảnh báo, còn các giá trị giống secret nhưng có vẻ vô hại được lọc đi.

Cách làm này giữ phần tìm ứng viên nhanh và có quy tắc rõ ràng, đồng thời dành việc phân biệt ngữ cảnh cho mô hình. Nó cũng cho thấy ranh giới của khả năng phát hiện: bộ phân loại chỉ đánh giá các ứng viên đã qua bước tìm kiếm ban đầu, và ngưỡng chuyển điểm số thành cảnh báo ảnh hưởng đến số phát hiện được gửi đi. Mật khẩu thiếu định dạng cố định đáng chú ý chính vì hình dạng chuỗi đơn lẻ ít giúp phân biệt credential thật với một giá trị chỉ giống nó.

Dữ liệu huấn luyện kết hợp phản hồi từ tính năng phát hiện secret, ứng viên tìm thấy trong kho mã và ví dụ tổng hợp cho những trường hợp dễ nhầm. Các ví dụ khó gồm secret trong tài liệu, dữ liệu kiểm thử, khóa công khai và chuỗi checksum. Trước khi chia dữ liệu để huấn luyện và đánh giá, các trường hợp có chung kho mã, giá trị ứng viên hoặc ví dụ được nhóm lại nhằm tránh những bản gần trùng xuất hiện ở cả hai phía.

Ba phép đo nói lên ba điều khác nhau

Thời gian quét được đo ở trung vị thời gian thực thi sau push trong môi trường sản xuất. Trung vị là điểm giữa của các lượt quét trong phép đo, không phải thời gian tối đa hoặc mức cải thiện của từng lần push. Chỉ số này mô tả tốc độ của cả pipeline ở một công đoạn cụ thể; nó không đo khả năng nhận diện mọi secret có thể tồn tại trong kho mã.

Tỷ lệ chấp nhận cảnh báo lại đo phản ứng của khách hàng đối với những phát hiện đã được gửi tới họ trong thử nghiệm A/B. Cách tính đặt trọng số theo chủ kho mã để một khách hàng xử lý hàng loạt cảnh báo không chi phối kết quả chung. Tỷ lệ chấp nhận cao hơn là tín hiệu cảnh báo hữu ích hơn trong phép đo đó, nhưng không thể chuyển thành tỷ lệ tất cả secret đã được tìm thấy: những secret bị bỏ sót không xuất hiện trong tập cảnh báo được chấp nhận.

Bài tường thuật của Help Net Security ngày 14/10/2026 ghi nhận phép đánh giá ngoại tuyến trên cùng lưu lượng công khai: pipeline mới đạt precision cao hơn 13% và recall cao hơn 19% so với pipeline cũ; hai tác giả Batu Ozturkler và Shengyu Fu được dẫn lời: “Higher precision means fewer distracting alerts”. Precision xét trong các phát hiện được đưa ra có bao nhiêu là secret thật, còn recall xét trong các secret thật của tập đánh giá có bao nhiêu được phát hiện. Đây là mức tăng tương đối giữa hai pipeline trên tập được đánh giá, không phải tỷ lệ phát hiện tuyệt đối trên toàn GitHub.

Chi phí phục vụ là phép đo thứ ba, thuộc về việc vận hành mô hình. Mẫu so sánh của nó là bộ phân loại nhỏ với các lệnh gọi mô hình ngôn ngữ lớn từ xa, không phải hóa đơn của khách hàng. Bộ phân loại được xuất sang định dạng ONNX và lượng tử hóa để suy luận nhanh hơn. Chi phí xử lý thấp hơn cùng thời gian phản hồi ngắn hơn giúp giải thích vì sao GitHub có thể thử đưa việc phân loại credential không cấu trúc vào lúc push, khi kết quả phải có trước khi thay đổi được chấp nhận.

Mô hình hiện được dùng ở đâu

Phạm vi đã triển khai rõ nhất là cảnh báo sau push cho khách hàng đang dùng tính năng phát hiện Password bằng AI trong GitHub Secret Protection hoặc GitHub Advanced Security. Sau khi mã đã được ghi nhận, secret scanning kiểm tra nội dung và tạo cảnh báo để người phụ trách điều tra, khắc phục. Những lượt quét cảnh báo hiện có tiếp tục nằm trong gói bảo vệ của khách hàng, không phát sinh khoản phí bổ sung chỉ vì chuyển sang mô hình mới.

Push protection kiểm tra sớm hơn, trước khi một push được chấp nhận. Với credential không cấu trúc do AI phát hiện, tính năng này còn ở giai đoạn thử nghiệm riêng tư và cần được quản trị viên bật theo chính sách áp dụng. Nó cho phép xử lý giá trị đáng ngờ trước khi giá trị ấy đi vào lịch sử kho mã. Đó là một khác biệt thực tế so với cảnh báo sau push, nơi secret đã có thể xuất hiện trong nội dung được ghi nhận.

Phần kiểm tra secret dự kiến bổ sung vào /security-review của Copilot CLI và ứng dụng Copilot cũng chưa được phát hành rộng rãi. GitHub dự kiến dùng AI Credits cho các lượt kiểm tra tự chọn mới ở push protection và /security-review, tách khỏi cảnh báo do AI phát hiện vốn đã nằm trong gói bảo vệ. Vì vậy, mức tiết kiệm chi phí phục vụ mô hình không cho biết một tổ chức sẽ trả bao nhiêu khi bật những luồng kiểm tra mới.

Một cảnh báo Password cần được xử lý thế nào

Khi cảnh báo xuất hiện, câu hỏi đầu tiên là giá trị bị đánh dấu có thực sự dùng để xác thực hay chỉ là ví dụ, dữ liệu thử nghiệm hoặc một mã định danh vô hại. Đường dẫn tệp, tên biến và mã lân cận là những dấu hiệu đã tham gia vào quyết định của mô hình; người xử lý cần đặt phát hiện vào đúng ngữ cảnh đó. Chấp nhận hay bác bỏ cảnh báo chỉ có ý nghĩa khi đã xác định giá trị có thể truy cập dịch vụ nào và còn hiệu lực hay không.

Nếu credential thật đã vào lịch sử kho mã, chỉ xóa chuỗi ở phiên bản hiện tại không làm credential hết hiệu lực. Hướng xử lý là thu hồi hoặc xoay vòng giá trị bị lộ, rồi sửa nơi lưu trữ để mã không tiếp tục chứa nó. Với giá trị mẫu, việc phân loại đúng cảnh báo giúp giảm nhiễu. Phản hồi từ các trường hợp bị bỏ sót hoặc báo sai cũng là dữ liệu GitHub dự kiến đưa trở lại quá trình huấn luyện và đánh giá khi phạm vi áp dụng mô hình mở rộng.

Đọc thêm:

• GitHub chặn merge khi PR lộ secret, nhưng chưa hỗ trợ phát hiện bằng AI
• OSS Scanner quét mã nguồn mở miễn phí, báo lỗi có thể chưa được người duyệt
• Mật khẩu bị báo lộ: đổi một nơi vẫn chưa chặn credential stuffing