Kiểm tra bảo mật trước phát hành cho mã AI: ai quyết?
Tóm tắt: Trong các dự án VAON áp dụng quy trình 10 bước, mỗi phiên bản qua một cổng bảo mật trước khi phát hành. Claude Code rà toàn bộ thay đổi, kỹ sư senior tách cảnh báo thật khỏi cảnh báo sai rồi quyết phát hành hay sửa trước. Cổng này đứng trên lớp kiểm tra chạy ở mọi dự án.
Mục lục
- Cổng bảo mật trước phát hành khác gì kiểm tra trên từng pull request?
- Vì sao phải rà lại cả phiên bản khi từng pull request đã được quét?
- Cổng trước phát hành chạy qua những bước nào?
- Ai quyết phát hành, và quyết dựa trên gì?
- Văn bản của Nhật và NIST SSDF liên quan thế nào?
- Khi nào cổng này không chạy hoặc chưa đủ?
- Câu hỏi thường gặp
1. Cổng bảo mật trước phát hành khác gì kiểm tra trên từng pull request?
Cổng bảo mật trước phát hành ở VAON chạy một lần cho mỗi phiên bản, còn kiểm tra tầng 1 chạy trên từng pull request.
| Tầng 1 trên pull request | Cổng trước phát hành | |
|---|---|---|
| Áp dụng ở | Mọi dự án | Các dự án theo quy trình 10 bước (phần lớn, chưa phải tất cả) |
| Thời điểm | Mỗi pull request | Mỗi phiên bản, trước khi phát hành |
| Nhìn thấy | Một thay đổi | Toàn bộ thay đổi của phiên bản |
| Gồm | Quét secret, quét thư viện phụ thuộc, phân tích tĩnh (SAST) | AI rà bảo mật, người đọc kết quả |
| Ai quyết | Máy chặn; trưởng nhóm duyệt merge | Kỹ sư senior quyết phát hành hay sửa |
Tầng 1 còn gồm vài quy tắc nền, cũng chạy ở mọi dự án:
- khoá nhánh chính, chưa review thì không merge;
- cấu hình Claude Code dùng chung do công ty quản lý (lệnh bị cấm, sandbox, MCP server đã duyệt);
- kiểm tra tên thư viện AI đề xuất trước khi cài, vì AI có thể bịa tên package;
- không đặt khoá thật ở môi trường phát triển.
Cổng trước phát hành là bước cuối của quy trình phát triển với Claude Code. Cách cấu hình Claude Code dùng chung có ở bài quy tắc dùng Claude Code trong công việc.
2. Vì sao phải rà lại cả phiên bản khi từng pull request đã được quét?
Phải rà lại cả phiên bản vì một số lỗ hổng chỉ hiện ra khi các thay đổi ghép lại với nhau. Người review mỗi PR chỉ nhìn phần của PR đó.
Ví dụ minh hoạ: PR thứ nhất thêm một API xuất danh sách khách hàng, có kiểm tra quyền. Hai tuần sau, PR thứ hai đổi hàm kiểm tra quyền dùng chung để sửa một lỗi khác. Từng PR đều hợp lý. Ghép lại, API xuất dữ liệu có thể mở cho người không đủ quyền.
Công cụ quét tự động bắt tốt lỗi có mẫu nhận dạng: khoá lọt vào mã, thư viện có lỗ hổng đã công bố. Lỗi phân quyền theo nghiệp vụ thường không có mẫu. Theo tài liệu Claude Code, lệnh /security-review phân tích các thay đổi trên nhánh hiện tại để tìm lỗ hổng. Ví dụ là injection, lỗi xác thực và lộ dữ liệu.
3. Cổng trước phát hành chạy qua những bước nào?
Cổng trước phát hành của VAON có năm bước, và chỉ bước thứ hai do AI làm.
- Chốt phạm vi. Xác định toàn bộ thay đổi từ phiên bản trước tới bản sắp phát hành.
- AI rà bảo mật. Claude Code rà phần thay đổi đó, liệt kê điểm đáng ngờ kèm vị trí và lý do.
- Người đọc từng phát hiện. Kỹ sư senior đối chiếu với mã và đặc tả. Mỗi mục được xếp vào một trong ba nhóm: thật, cảnh báo sai, cần hỏi thêm.
- Quyết định. Còn mục thật chưa sửa thì sửa trước, rà lại, rồi mới phát hành.
- Ghi lại. Kết luận từng mục được lưu cùng hồ sơ phát hành.
Cổng này đi sau ba lớp review trên từng pull request. Thứ tự ba lớp đó có ở bài ba lớp review pull request cho mã AI.
4. Ai quyết phát hành, và quyết dựa trên gì?
Người quyết phát hành là kỹ sư senior của dự án, không phải AI. AI chỉ đưa danh sách điểm đáng ngờ. AI không biết dữ liệu nào bạn cố ý công khai, hay màn hình nào chỉ dùng trong mạng nội bộ.
Bảng dưới là ví dụ minh hoạ, không phải kết quả từ dự án thật:
| Phát hiện của AI | Người kiểm tra điều gì | Kết luận có thể |
|---|---|---|
| Câu truy vấn ghép chuỗi từ dữ liệu người dùng nhập | Dữ liệu có đi qua lớp kiểm tra đầu vào không | Thật: sửa trước khi phát hành |
| API trả về email của người dùng khác | Đặc tả có cho hiển thị email ở màn hình này không | Cần hỏi: tuỳ ý đồ nghiệp vụ |
| Chuỗi giống khoá API trong file cấu hình mẫu | Đó là khoá thật hay chuỗi giả | Cảnh báo sai nếu là chuỗi giả |
Một bài học khi đưa AI vào rà bảo mật: cảnh báo sai là chuyện thường. Giá trị của cổng nằm ở người đọc kết quả, không ở độ dài danh sách. Ở VAON, cổng này cũng không phải lớp bảo mật duy nhất. VAON có đội hạ tầng (infra) riêng, đội này phụ trách cả kiểm thử bảo mật. CTO và Tech Lead tham gia mọi dự án, nên quyết định phát hành luôn có người đủ thẩm quyền đứng tên.
Khi việc sửa làm lùi lịch hoặc đổi phạm vi, VAON báo bạn trong báo cáo hằng tuần. Việc này nằm ở phần rủi ro và việc cần khách quyết.
5. Văn bản của Nhật và NIST SSDF liên quan thế nào?
Cổng trước phát hành của VAON tham chiếu hai tài liệu. VAON dùng chúng làm khung đối chiếu, không nhận là đã đạt chuẩn hay chứng nhận nào.
Tài liệu thứ nhất là văn bản 注意喚起 ngày 18/05/2026 của NCO và METI, đi cùng gói Project YATA-Shield. NCO là Văn phòng An ninh mạng Quốc gia Nhật; METI là Bộ Kinh tế, Thương mại và Công nghiệp. Mục 1 đề nghị công ty phần mềm chủ động dùng AI năng lực cao trước khi phát hành. Mục đích là giảm khả năng lỗ hổng bị phát hiện sau phát hành. Văn bản không nêu tên công cụ và không đặt chuẩn nào để "đạt".
Tài liệu thứ hai là NIST SP 800-218 (SSDF, phiên bản 1.1, 02/2022). Đây là bộ thực hành phát triển phần mềm an toàn, gắn được vào nhiều mô hình phát triển. Nội dung văn bản của Nhật có ở bài bảo mật lập trình với AI: Nhật yêu cầu gì.
6. Khi nào cổng này không chạy hoặc chưa đủ?
Cổng trước phát hành có giới hạn rõ, và bạn nên biết trước dự án mình thuộc trường hợp nào.
- Khách chưa cho phép đưa mã vào AI. Các bước AI không chạy. Phiên bản vẫn qua tầng 1 tự động và người đọc mã.
- Dự án chưa theo quy trình 10 bước. Dự án vẫn có tầng 1 trên mỗi pull request. Nhưng không có cổng rà cả phiên bản.
- Lỗi nằm ngoài mã. Cấu hình máy chủ hay thiết kế hạ tầng không hiện trong phần thay đổi. Phần này thuộc kiểm thử bảo mật, phạm vi thống nhất theo hợp đồng.
- Sau phát hành. Lỗ hổng mới có thể được công bố sau ngày phát hành. Việc theo dõi, vá và giám sát 24/7 được thống nhất riêng trong hợp đồng.
AI rà bảo mật bổ sung cho người, không thay người. AI có cảnh báo sai, và cũng có thể bỏ sót.
7. Câu hỏi thường gặp
Lệnh /security-review có thay được kiểm thử xâm nhập không? Không. Lệnh /security-review rà phần mã thay đổi, không thử tấn công hệ thống đang chạy. VAON có đội hạ tầng riêng, đội này phụ trách cả kiểm thử bảo mật. Phạm vi kiểm thử bảo mật và việc có giám sát 24/7 hay không được thống nhất trong hợp đồng từng dự án.
AI báo nhiều cảnh báo sai thì xử lý thế nào? Cảnh báo sai là chuyện thường với AI rà bảo mật, nên mọi kết quả đều có người đọc. Kỹ sư senior đối chiếu từng mục với mã và đặc tả, rồi ghi lý do khi kết luận là cảnh báo sai. Ghi lý do giúp lần rà sau không phải bàn lại cùng một mục, và bạn xem được vì sao một mục bị bỏ qua.
Nếu tôi không cho đưa mã vào AI, phiên bản còn được kiểm tra gì? Khi bạn chưa cho phép, VAON không đưa mã vào công cụ AI và bước AI rà bảo mật không chạy. Phiên bản vẫn qua tầng 1 ở mọi dự án: quét secret, quét thư viện phụ thuộc, phân tích tĩnh trên mỗi pull request. Nhánh chính vẫn khoá, và người review đọc mã trước khi merge.
VAON dùng NIST SSDF và YATA-Shield như thế nào? Quy trình bảo mật của VAON tham chiếu NIST SP 800-218 (SSDF) và văn bản 注意喚起 ngày 18/05/2026 của NCO và METI. VAON dùng hai tài liệu này làm khung đối chiếu, không nhận là đã đạt chuẩn nào. Văn bản của Nhật là lời đề nghị, không có tiêu chuẩn hay chứng nhận để đạt. Vì vậy VAON cho bạn xem quy trình cụ thể và hồ sơ, thay vì một nhãn.
Còn phát hiện bảo mật chưa sửa kịp thì có phát hành không? Kỹ sư senior quyết định phát hành hay sửa trước, dựa trên kết luận từng mục. Mục được kết luận là lỗ hổng thật thì sửa và rà lại trước khi phát hành. Khi việc sửa làm lùi lịch hoặc đổi phạm vi, VAON báo bạn trong báo cáo hằng tuần. Việc này nằm ở phần rủi ro và việc cần khách quyết.
Việc làm được ngay: hỏi đội phát triển của bạn về bản phát hành gần nhất. "Ai đã đọc kết quả rà bảo mật, và mục nào bị kết luận là cảnh báo sai, vì sao?" Nếu câu trả lời là "công cụ báo xanh", bản đó chưa có người quyết.
Nếu muốn xem cổng này áp vào dự án của bạn thế nào, đặt lịch trao đổi 60 phút miễn phí. CEO tham dự, không cần chuẩn bị tài liệu, không ràng buộc.
