Giải pháp an ninh trong phát triển phần mềm với AI: Hết “lập trình theo cảm hứng”, bắt đầu quy trình Secure SDLC

Giải pháp an ninh trong phát triển phần mềm với AI: Hết “lập trình theo cảm hứng”, bắt đầu quy trình Secure SDLC

Nhiều lập trình viên sử dụng AI như Claude Code hay Cursor hẳn đã từng gặp tình trạng “vấn đề 4 phút”: AI tạo ra code hoạt động mượt mà, giao diện đẹp, upload file thành công… nhưng sau đó lại để lại loạt lỗ hổng bảo mật như XSS qua SVG, path traversal và bucket S3 công khai.

Nguyên nhân là các mô hình AI này chỉ tối ưu cho code chạy được, chưa chú trọng bảo mật. Việc thêm prompt nhắc nhở “luôn viết code an toàn” thôi là chưa đủ, vì bảo mật cần được quản lý theo từng giai đoạn cụ thể của quy trình phát triển phần mềm.

Từ “lập trình cảm hứng” đến quy trình phát triển an toàn với AI

Thay vì để AI tự do viết code theo lệnh tổng quát, nhóm phát triển đã tạo ra 8 tác nhân AI chuyên biệt tương ứng với từng bước trong quy trình phát triển phần mềm an toàn (Secure SDLC):

• Product Manager: chuyển đổi user story thành yêu cầu bảo mật theo chuẩn OWASP ASVS.
• AppSec Engineer: thực hiện mô hình hóa nguy cơ STRIDE, phân tích kết quả SAST/DAST.
• Cloud/Platform Engineer: rà soát cấu hình Terraform/Kubernetes để phát hiện lỗ hổng CSPM và mật khẩu cứng.
• GRC Analyst: đối chiếu kiểm soát với các tiêu chuẩn SOC 2, ISO 27001, GDPR, cập nhật sổ đăng ký rủi ro.

Ngoài ra còn có Dev Lead, Release Manager, Security Champion, và AI Security Engineer đảm bảo quy trình không bị bỏ sót. Các tác nhân này không chạy tự động trong kho mã mà được gọi qua Model Context Protocol (MCP), bắt buộc AI tạo ra các tài liệu an ninh dạng Markdown cụ thể phục vụ kiểm tra.

Phân chia giai đoạn Secure SDLC trong CLI

Thực tế áp dụng: Ví dụ upload file

Thay vì cho AI code luôn, quy trình “Secure SDLC agents” yêu cầu:

• Gọi Product Manager để khởi tạo file security-requirements.md, map theo ASVS Level 2, nhấn mạnh kiểm tra magic byte thay vì chỉ kiểm tra MIME type.
• Gọi AppSec Engineer xây dựng mô hình mối đe dọa, phát hiện SVG chứa script không thể lọc an toàn nên cần chặn.
• Khi tạo pull request, Dev Lead agent dựa trên bối cảnh threat model và yêu cầu ASVS để phát hiện lỗi mà lập trình “vibe” không thấy.
• Cloud/Platform Engineer rà soát Terraform, phát hiện cấu hình S3 bucket mở công khai gây rủi ro nghiêm trọng và chặn merge.

Mô hình mối đe dọa STRIDE của AppSec Engineer

Dev Lead phát hiện lỗi trong Pull Request

Không phải AI tự quyết trong CI/CD

Một số người thắc mắc liệu những tác nhân AI này có chạy trong pipeline GitHub Actions không? Câu trả lời là không.

Các mô hình AI hiện chưa đủ tính phi định lượng để đưa ra quyết định an ninh tự động trong CI/CD. Thay vào đó, pipeline chạy các công cụ truyền thống như Gitleaks, Checkov, CodeQL, npm audit và xác nhận các tài liệu AI tạo ra có tồn tại, đầy đủ trước khi cho phép merge.

AI chủ yếu làm trọng trách phân tích và mô hình hóa mối đe dọa ngay trong IDE của nhà phát triển, còn CI/CD đảm bảo quy trình không bị bỏ qua.

Kết luận: An ninh là kỹ thuật chứ không phải diễn xuất

Nhóm tác giả nhấn mạnh cách tiếp cận hiện tại của AI khiến nợ kỹ thuật và nợ bảo mật tích tụ lớn. Tác nhân AI Secure SDLC không thay thế kỹ sư An ninh Ứng dụng hay kiểm thử thâm nhập, mà hỗ trợ yêu cầu sớm, tạo ra tài liệu nhất quán và phát hiện lỗi kiến trúc cơ bản mà công cụ SAST truyền thống dễ bỏ qua.

Bạn có thể cài đặt công cụ Secure SDLC qua npm hoặc từ marketplace Claude, tích hợp dễ dàng các git hook, mẫu file và server MCP vào dự án.

Chi tiết mã nguồn và hướng dẫn: https://github.com/Kaademos/secure-sdlc-agents

Nếu bạn là chuyên gia AppSec đang thử nghiệm với các AI coder, nhóm tác giả rất mong nhận được góp ý về các prompt ASVS trong mục comment của repo.

---

Qua ví dụ này, ta thấy rõ sự phát triển mới trong việc ứng dụng AI cho lập trình bảo mật: không chỉ cần code nhanh, mà phải thiết lập quy trình có kiểm soát và bằng chứng để bảo vệ sản phẩm an toàn hơn từ đầu đến cuối.