Autofix Của GitHub Chính Thức GA. Nhưng Chữ “Đã Kiểm Chứng” Hẹp Hơn Nhiều So Với Nghe Tưởng.

Ngày 15/10, GitHub đưa agentic autofix cho code scanning lên GA (general availability). Ý tưởng khá đơn giản: Copilot được giao một alert CodeQL, đọc codebase, viết fix, mở một draft pull request, và phần mô tả PR ghi là fix đã “validated” — đã được kiểm chứng. Nếu bạn đọc chữ đó theo cách phần lớn kỹ sư vẫn hiểu — test đã chạy, hành vi đã được kiểm tra, lỗi đã thật sự biến mất — thì bạn đang suy diễn nhiều hơn những gì GitHub thực sự cam kết. Bước “kiểm chứng” ở đây là chạy lại CodeQL lần hai. Không có gì trong luồng GA chạy lại test suite của bạn cả.

Luồng làm việc thực tế như thế nào

Một alert CodeQL — có thể là một cái lẻ, hoặc một batch tối đa 25 alert cùng lúc — được giao cho Copilot, do maintainer giao tay hoặc tự động qua repository rule. Copilot đọc đoạn code bị gắn cờ cùng các file liên quan, đề xuất một fix, rồi mở draft PR kèm phần tóm tắt bằng văn bản là đã sửa gì và vì sao. Trước khi PR đó được chuyển sang trạng thái sẵn sàng, GitHub chạy lại CodeQL trên code đã sửa để xác nhận đúng alert đó không còn bật nữa. Đó là bước mà thông báo gọi là “validation”.

Đây là một bước kiểm tra thật và có giá trị — không phải là không có gì. Nó nghĩa là fix không chỉ là một lời giải thích nghe hợp lý mà chẳng liên quan gì tới pattern bị gắn cờ thật; chính công cụ phân tích tĩnh đã tìm ra vấn đề ban đầu cũng xác nhận rằng vấn đề, theo định nghĩa của nó, không còn tồn tại. Nhưng việc một công cụ phân tích tĩnh trả lời “pattern này còn khớp không” là một câu hỏi khác hẳn với “ứng dụng còn hoạt động đúng không”. Một fix khiến alert SQL injection biến mất bằng cách bọc câu query trong một try/catch quá rộng, hoặc thay đổi cách xử lý input theo kiểu âm thầm phá vỡ một tính năng phía sau, vẫn có thể qua bước kiểm chứng này một cách sạch sẽ. Thông báo GA không nói ngược lại điều đó — nhưng chữ “validated” nằm trong phần mô tả PR mà reviewer chỉ lướt qua, lại rất dễ gây hiểu nhầm đúng kiểu đó.

Phạm vi hẹp hơn “sửa lỗi bảo mật” nói chung

Bản GA đi kèm những ranh giới thật, và chúng quan trọng khi bạn quyết định có nên bật tính năng này hay không. Nó chỉ hoạt động với alert từ bộ query CodeQL mặc định của GitHub, trên nhánh mặc định của repository. Nó không bao phủ alert từ custom CodeQL query, từ các bộ query mở rộng như security-extended hay security-and-quality, hoặc từ công cụ phân tích tĩnh của bên thứ ba được kết nối vào code scanning qua SARIF upload. Nếu tư thế bảo mật của tổ chức bạn dựa nhiều vào một bộ custom query riêng — mà đó chính là kiểu tổ chức có đủ trình độ bảo mật trưởng thành để đang xem xét công cụ này ngay từ đầu — thì một phần không nhỏ alert của bạn vẫn chưa nằm trong phạm vi. Giới hạn batch tối đa 25 alert mỗi lần giao là một rào chắn hợp lý, tránh việc một reviewer bị giao năm mươi PR cùng lúc, nhưng cũng nghĩa là một repo có backlog alert lớn sẽ cần nhiều vòng giao việc, chứ không phải một lần dọn sạch.

Chính tài liệu của GitHub đã nói rõ khoảng trống này

Phải khen GitHub ở điểm này: tài liệu về sử dụng có trách nhiệm cho tính năng này không thổi phồng. Nó cảnh báo thẳng rằng một fix qua được kiểm tra CodeQL vẫn có thể sai về mặt ngữ nghĩa — khác về hành vi so với những gì code lẽ ra phải làm — và nói điều đó rõ ràng, không giấu trong một chú thích nhỏ. Bản năng đó là đúng. Vấn đề là cảnh báo đó nằm trong tài liệu mà hầu hết người ta chỉ lướt qua một lần, còn chữ “validated” lại nằm ngay trong chính PR — thứ mà reviewer thực sự hành động dựa vào, dưới áp lực thời gian. Hai tín hiệu đó kéo về hai hướng ngược nhau, và PR luôn thắng theo mặc định, vì nó là thứ nằm ngay trước mặt reviewer, kèm sẵn một nút approve bên cạnh.

Rủi ro thật không nằm ở agent. Nó nằm ở sự mệt mỏi khi review theo batch.

Review của con người trước khi merge vẫn là bắt buộc — GitHub không bỏ cổng chặn đó, và cũng không nên bỏ. Nhưng “bắt buộc phải review” và “review có hiệu quả” là hai chuyện khác nhau, và thiết kế batch-25 chính là điều kiện làm mờ đi sự khác biệt đó. Một team bảo mật dọn sạch backlog 200 alert qua tám vòng giao việc sẽ thấy tám batch draft PR đổ về cùng một ngày, mỗi PR đều mang nhãn “validated” và một đoạn tóm tắt nghe rất hợp lý. So sánh trung thực ở đây không phải là “fix do agent viết so với fix do con người viết” — mà là “một reviewer đọc kỹ một PR, so với một reviewer lướt qua hai mươi lăm PR đều trông rất tự tin”. Tình huống thứ hai mới là nơi một fix âm thầm phá vỡ tính năng khác lọt qua được, không phải vì agent tệ bất thường, mà vì khối lượng lớn cộng với một nhãn trấn an là công thức kinh điển gây mệt mỏi khi review, bất kể ai hay cái gì viết ra đoạn code đó.

Vậy nên làm gì với tính năng này

Đây là một công cụ thật sự hữu ích cho đúng loại vấn đề nó nhắm tới: alert CodeQL từ bộ query mặc định, trên nhánh mặc định, loại alert thường bị bỏ không ai xử lý hàng tháng vì chẳng ai nhận trách nhiệm triage. Bật nó lên để xử lý backlog đó là một quyết định hợp lý. Điều cần điều chỉnh nằm ở tổ chức, không phải ở công nghệ: đừng để chữ “validated” trong mô tả PR thay thế cho việc test suite của bạn thực sự chạy qua thay đổi đó, và đừng để kích thước batch vượt quá khả năng tập trung thật của reviewer. Nếu CI của bạn chưa bắt buộc PR autofix phải qua toàn bộ test suite trước khi con người kịp mở diff ra xem, đó chính là khoảng trống cần lấp trước khi mở rộng quy mô dùng tính năng này — không phải vì agent không đáng tin, mà vì “công cụ phân tích tĩnh hết kêu” và “code vẫn hoạt động đúng” là hai khẳng định khác nhau, và chỉ một trong hai thực sự được kiểm tra giúp bạn.