GitHub chặn merge khi PR lộ secret, nhưng chưa hỗ trợ phát hiện bằng AI

Ngày 9/9/2026, GitHub đưa quy tắc Require secret scanning alerts are resolved vào public preview, cho phép repository ruleset chặn pull request làm phát sinh cảnh báo secret chưa xử lý. Thông báo thay đổi ngày 9/9 của GitHub nêu rõ quy tắc này được bổ sung tại lớp pull request và dành cho khách hàng có GitHub Secret Protection hoặc GitHub Advanced Security.

Cách bật là tạo hoặc sửa branch ruleset, chọn các repository và branch cần bảo vệ, sau đó kích hoạt Require secret scanning alerts are resolved. PR sẽ không thể merge khi lần quét head commit chưa hoàn tất hoặc khi commit trong PR tạo ra cảnh báo mở thuộc loại secret đã chọn; bản tin độc lập của ReleaseBytes cũng ghi nhận hai điều kiện này cùng trạng thái public preview.

Hai điều kiện khiến pull request bị chặn

Điều kiện thứ nhất liên quan đến head commit, tức commit mới nhất của pull request. GitHub phải hoàn tất secret scanning cho commit này trước khi ruleset có thể cho phép merge; trạng thái quét còn chờ tự nó đã đủ để giữ PR lại, ngay cả khi chưa có cảnh báo mở.

Điều kiện thứ hai chỉ xét cảnh báo do các commit trong chính pull request đưa vào. Sau khi quét xong, PR vẫn bị chặn nếu còn cảnh báo mở khớp với một secret type được chọn trong ruleset. Vì vậy, quy tắc không yêu cầu toàn bộ lịch sử repository phải sạch mọi cảnh báo trước đó.

Phạm vi mặc định là secret được tìm thấy bằng provider patterns. Quản trị viên có thể bổ sung custom patterns hoặc generic patterns, nhưng việc chọn nhóm nào sẽ quyết định cảnh báo nào có quyền chặn merge. Một cảnh báo nằm ngoài phạm vi đã chọn không trở thành điều kiện thực thi của ruleset này.

Checklist cấu hình ở repository và organization

Repository muốn dùng quy tắc phải bật secret scanning cùng GitHub Secret Protection hoặc GitHub Advanced Security. Tài liệu cấu hình chính thức của GitHub cũng giới hạn các lựa chọn được hỗ trợ ở provider, custom và generic patterns, đồng thời nói rõ AI-detected secrets chưa thể tham gia quy tắc.

Ở cấp repository, người có quyền quản trị vào Settings → Rulesets → Rulesets, chọn New ruleset → New branch ruleset hoặc sửa ruleset hiện có. Sau đó cần đặt branch mục tiêu, bật quy tắc trong phần Branch protections, chọn secret types và chuyển enforcement status sang Active khi sẵn sàng áp dụng.

1. Kiểm tra GitHub Secret Protection hoặc GitHub Advanced Security đã được bật.
2. Kiểm tra secret scanning đang hoạt động trên repository.
3. Chọn đúng branch cần bảo vệ, chẳng hạn branch mặc định hoặc branch phát hành.
4. Bật Require secret scanning alerts are resolved.
5. Chọn provider, custom và generic patterns theo chính sách của nhóm.
6. Rà soát danh sách bypass trước khi đặt ruleset ở trạng thái Active.

Ở cấp organization, organization owner, security manager hoặc thành viên có vai trò admin có thể vào Organization Settings → Repository → Rulesets, tạo branch ruleset rồi chọn repository và branch mục tiêu. Trước khi áp dụng hàng loạt, cần đối chiếu điều kiện cấp phép và trạng thái secret scanning của từng repository; ruleset không bù được một repository chưa đáp ứng điều kiện tiên quyết.

Việc chọn secret types nên phản ánh cách tổ chức đang phát hiện thông tin xác thực. Provider patterns phù hợp với định dạng đã biết của nhà cung cấp; custom patterns mở rộng sang mẫu nội bộ; generic patterns bao phủ những dạng bí mật chung hơn. Đây là phạm vi thực thi, không chỉ là bộ lọc hiển thị cảnh báo.

Merge protection bổ sung, không thay thế push protection

Hai cơ chế can thiệp ở hai thời điểm khác nhau. Push protection cố chặn secret ngay khi nội dung được đẩy lên GitHub, còn merge protection kiểm tra pull request trước khi thay đổi đi vào branch được ruleset bảo vệ.

• Thời điểm: push protection hoạt động trong quá trình push; merge protection hoạt động tại cổng hợp nhất PR.
• Mục tiêu: lớp đầu giảm khả năng secret đi vào repository; lớp sau ngăn cảnh báo chưa xử lý đi vào branch quan trọng.
• Điều kiện riêng: merge protection còn chờ secret scanning hoàn tất trên head commit.
• Phạm vi: ruleset có thể áp dụng cho provider, custom hoặc generic patterns được lựa chọn riêng.

Chỉ bật quy tắc mới không có nghĩa secret chưa từng xuất hiện trên GitHub. Nội dung có thể đã nằm trong branch của pull request trước khi bị chặn ở bước merge, và thao tác khóa merge không thu hồi một thông tin xác thực đã lộ. Vì thế, push protection vẫn là lớp phòng ngừa sớm, còn ruleset mới là cổng kiểm soát bổ sung.

Sự khác biệt này cũng cho phép tổ chức áp dụng mức kiểm soát khác nhau theo giai đoạn. Chẳng hạn, một nhóm có thể không muốn chặn mọi generic pattern lúc push nhưng vẫn yêu cầu đánh giá cảnh báo tương ứng trước khi merge vào branch được bảo vệ. Đây là lựa chọn chính sách cần cân bằng giữa độ bao phủ và khối lượng cảnh báo phải xử lý.

Xử lý cảnh báo, bypass và giới hạn public preview

Khi PR bị chặn, bước đầu tiên là xác định nguyên nhân: head commit còn đang được quét hay đã có cảnh báo mở. Nếu nguyên nhân là lần quét chưa hoàn tất, nhóm cần chờ kết quả của commit hiện tại; nếu có commit mới, head commit thay đổi và cổng kiểm tra phải đánh giá trạng thái mới.

Với cảnh báo hợp lệ, quy trình vận hành nên coi thông tin xác thực đã commit là có nguy cơ bị lộ: vô hiệu hóa hoặc xoay vòng secret tại hệ thống phát hành nó, loại bỏ giá trị khỏi mã và xử lý cảnh báo. Chỉ xóa chuỗi trong một commit tiếp theo không đảo ngược việc giá trị đó từng xuất hiện trong repository.

Nếu kết quả được đánh giá là sai hoặc là giá trị không còn rủi ro, người có thẩm quyền cần xử lý cảnh báo với lý do và ghi chú có thể kiểm tra lại. PR chỉ vượt qua điều kiện thông thường khi không còn cảnh báo mở phù hợp với secret types của ruleset và lần quét head commit đã hoàn tất.

Quyền bypass dành cho tình huống và chủ thể được tổ chức cho phép vượt qua ruleset, nhưng không làm secret an toàn hơn và không thay thế việc xử lý cảnh báo. Danh sách bypass vì thế nên giới hạn ở vai trò, nhóm hoặc ứng dụng thực sự cần đường đi ngoại lệ, đồng thời tách quyết định cho phép merge khỏi quyết định thu hồi thông tin xác thực.

Giới hạn quan trọng nhất hiện nay là AI-detected secrets chưa được hỗ trợ. Điều này chỉ có nghĩa cảnh báo thuộc nhóm phát hiện bằng AI chưa thể dùng làm tín hiệu chặn của quy tắc mới; không nên diễn giải thành việc GitHub không có khả năng phát hiện loại secret đó ở những phần khác của sản phẩm.

Tính đến ngày 12/9/2026, quy tắc vẫn là public preview và có thể thay đổi. GitHub chưa công bố trên các trang được kiểm tra thời điểm phát hành ổn định hoặc khi nào AI-detected secrets sẽ được đưa vào cổng merge; do đó, quản trị viên cần giữ push protection và các biện pháp ứng phó secret hiện có trong khi theo dõi phạm vi hỗ trợ tiếp theo.

Đọc thêm:

• Vá ảo chặn tấn công sớm, nhưng không thay thế bản sửa trong mã nguồn
• Gắn nhãn “remote” chưa đủ: chỉ 2,2–12,4% việc làm không giới hạn nơi ở
• Jalapeño nhanh hơn nhưng chưa bán: giới hạn lớn trong chip AI của OpenAI