GitHub mở API cho AI Scan: bật chính sách chưa có nghĩa là kho đã được quét

GitHub công bố ngày 13/11/2026 rằng quản trị viên có thể bật hoặc tắt AI Scan cho kho mã qua REST API ở cấp tổ chức và từng kho. Thay đổi hữu ích nhất với đội quản lý nhiều dự án: họ có thể đọc lại chính sách để phát hiện cấu hình lệch. Tuy nhiên, công tắc vừa được thêm chỉ thay đổi quyền sử dụng tính năng. Một kho có chính sách đã bật vẫn có thể chưa từng được quét.

Hai công tắc phục vụ hai phạm vi

Trong nhật ký thay đổi của GitHub, tùy chọn mới có tên repository_scan. Nó nằm trên các điểm cuối đọc và cập nhật cấu hình AI Scan ở cấp tổ chức hoặc kho. Trường pr_scan đã có từ trước dành cho tính năng AI Scan trên yêu cầu hợp nhất mã. Hai trường cần được theo dõi riêng: một đội có thể muốn quét theo phạm vi kho nhưng chưa bật chế độ liên quan đến yêu cầu hợp nhất, hoặc ngược lại tùy cách họ tổ chức kiểm tra.

API cho phép sửa cả hai trường trong một yêu cầu. Theo GitHub, nếu một trong hai thay đổi bị chặn, yêu cầu trả mã 422 và cả hai đều không đổi. Tính chất đó ngăn trạng thái nửa thành công trong một lần ghi. Nó cũng có nghĩa một công việc tự động cần đọc nguyên nhân, rồi đọc lại trạng thái thay vì đánh dấu rằng trường thứ nhất đã được áp dụng. Mã lỗi trong một yêu cầu cụ thể không phải là bằng chứng tất cả kho khác của tổ chức cũng có cấu hình như vậy.

Kế thừa không giống với ép bật

Khi tổ chức tắt AI Scan cấp kho, các kho thuộc tổ chức đó không thể tự bật. Khi tổ chức bật, các kho kế thừa nhưng có thể chọn tắt riêng. Nếu chính sách cấp doanh nghiệp không cho phép tính năng, yêu cầu bật sẽ bị từ chối với mã 422. Vì vậy, mục tiêu quản trị cần được diễn đạt rõ: đội muốn cho phép tùy chọn trên toàn tổ chức, hay muốn mọi kho thuộc một danh mục đáp ứng một mức kiểm tra nhất định? Cấu hình mặc định chỉ giúp giải quyết việc đầu tiên.

Ví dụ, một công ty giả định có kho mẫu thử, kho chứa ứng dụng thanh toán và kho cũ chỉ dùng để tham chiếu. Bật mặc định có thể thích hợp với các kho phát triển tích cực, nhưng có thể có ngoại lệ được phê duyệt. Khi rà trạng thái, nên giữ cả mục đích và người chịu trách nhiệm của từng ngoại lệ. Nếu chỉ thu về danh sách có hoặc không, đội vận hành khó biết một kho bị tắt vì quyết định hợp lệ hay do cấu hình trôi khỏi chuẩn.

Bật tính năng không tạo bằng chứng quét

GitHub nêu rõ bật AI Scan cho kho không bắt đầu lượt quét. Người có quyền ghi vẫn chạy quét theo yêu cầu, và mỗi lượt sử dụng tín dụng GitHub Code Security AI. Một bảng theo dõi tốt nên có ít nhất hai số: bao nhiêu kho thuộc phạm vi đã cho phép tính năng, và bao nhiêu kho đã hoàn thành một lượt quét phù hợp với yêu cầu. Số thứ hai còn cần mốc thời gian và phạm vi được kiểm tra. Một lượt quét từ trước khi đổi kiến trúc có thể không phản ánh phần mã mới.

Báo cáo cũng nên giữ trạng thái thất bại riêng với trạng thái hoàn thành nhưng không có phát hiện. Khi lượt quét không chạy được, bảng rỗng không có nghĩa kho sạch. Khi lượt quét hoàn tất, phát hiện vẫn cần được đối chiếu với mã, quyền truy cập và khả năng kích hoạt trong môi trường sử dụng. Kết quả AI Scan có thể giúp chọn nơi cần xem trước, nhưng đội phát triển vẫn cần các phép kiểm tra khác nhằm bao phủ cấu hình triển khai, thành phần phụ thuộc và hành vi khi chạy.

Đưa cấu hình vào quy trình thay đổi có thể kiểm tra lại

Một cách triển khai là bắt đầu bằng thao tác đọc, lưu cấu hình hiện tại và xác định phạm vi thử nghiệm nhỏ. Khi dùng quyền cập nhật, tiến trình chỉ nên được cấp quyền cần cho nhóm kho đã chọn. Sau mỗi lần ghi, nó đọc lại chính sách và lưu lý do sai lệch. Nếu chính sách cấp cao hơn chặn thao tác, chuyển trường hợp đó cho người phụ trách thay vì thử lặp lại vô hạn. Một thử nghiệm ở kho mẫu có thể xác minh cách hệ thống phản ứng với lựa chọn tắt riêng, chính sách chặn và yêu cầu sửa hai trường cùng lúc.

Đội quản lý ngân sách có thể dự tính số lượt cần chạy theo mức rủi ro của từng kho, sau đó so với mức tín dụng sử dụng thật. Với ứng dụng xử lý dữ liệu khách hàng, có thể đặt mục tiêu về độ mới của lần quét. Với kho đã lưu trữ, cân nhắc liệu lượt quét mới có mang lại thông tin hữu ích hay không. Định kỳ rà lại giúp lịch kiểm tra theo kịp việc kho đổi chủ hoặc một dự án thử trở thành dịch vụ thật.

Điểm đáng giá của API là làm chính sách dễ kiểm tra và áp dụng nhất quán hơn. Bằng chứng an ninh đến từ bước sau: một lượt quét đã chạy, kết quả được xem xét và vấn đề có người xử lý. Nếu bảng theo dõi tách rõ các mốc đó, đội quản trị có thể giải thích vì sao một kho được coi là đã kiểm tra, thay vì đưa ra kết luận chỉ từ trạng thái của một công tắc trong trang quản trị.

Nguồn: GitHub Changelog ngày 13/11/2026.

Ảnh minh họa: Giao diện Gitweb minh họa cây tệp trong kho Git; không phải giao diện AI Scan của GitHub. Qorg11 qua Wikimedia Commons, CC0 1.0.