Quy Trình Fix Bảo Mật
cho Vibe Coder
Một prompt pipeline giúp developer chưa rành bảo mật: research best practice hiện tại trước, audit có bằng chứng, dừng lại chờ người xác nhận, rồi fix từng lỗi một, giải thích rõ ràng ở mỗi bước.
1. Research
Research best practice hiện tại cho stack này
2. Audit
Quét STRIDE + OWASP, dựa trên kết quả Bước 1
3. Checkpoint
Trình bày kết quả. Dừng lại. Chờ người xác nhận.
4. Fix Loop
Fix từng lỗi một, an toàn nhất trước
5. Tổng Kết
Trước / sau + còn lại gì + việc cần làm thủ công
Ctrl/Cmd + cuộn chuột để zoom · kéo để di chuyển · ⤢ để mở rộng
Prompt copy-paste sẵn dưới đây triển khai toàn bộ quy trình được giải thích ở các phần tiếp theo. Thay {SCOPE} bằng đường dẫn hoặc repo cần fix trước khi dùng.
Xác định tech stack (framework, ngôn ngữ, auth library, hosting, dependency chính), rồi research từng mục:
- Bản OWASP Top 10 hiện tại và các vấn đề riêng của stack
- Các CVE / advisory đã biết cho version dependency đang dùng
- Docs bảo mật chính thức của framework, không phải blog post chung chung
- Có library nào đang dùng đã deprecated và có bản thay thế an toàn hơn không
- CIS Benchmark cho config hạ tầng (Docker, cloud, Kubernetes) nếu app có phần deployment
Kiến thức nhớ sẵn (có thể đã cũ) không đủ để khẳng định thông tin theo version (CVE, default hiện tại), phải verify với nguồn hiện tại trước. Tóm tắt kết quả research trong 3 tới 6 gạch đầu dòng trước khi qua bước tiếp, để audit dựa trên chuẩn hiện tại chứ không phải đoán mò.
Prompt copy-paste cho bước này
- Vấn đề là gì, trong một câu đơn giản, không dùng thuật ngữ chưa giải thích
- Một kịch bản khai thác (exploit) cụ thể, không chỉ nêu tên category
- Nguồn từ Bước 1 để chứng minh (CVE ID, CWE ID, category OWASP, trích docs)
- Mức độ nghiêm trọng (severity)
Ai đó có thể đánh cắp dữ liệu người dùng hoặc chiếm app ngay bây giờ.
Khai thác được nếu bỏ chút công sức, gây thiệt hại thật nếu xảy ra.
Phạm vi hẹp hoặc ảnh hưởng thấp, nhưng vẫn nên fix.
Best practice, chưa có nguy hiểm thật sự lúc này.
Cải thiện tùy chọn, không có rủi ro trực tiếp.
Prompt copy-paste cho bước này
Toàn bộ danh sách finding được trình bày, rồi quy trình dừng lại. Không có gì được fix cho đến khi developer nói rõ là được phép làm.
Checkpoint này tồn tại để người chưa rành không bao giờ bị bất ngờ bởi hàng loạt thay đổi. Họ thấy rõ vấn đề và lý do trước khi code của họ bị đụng vào.
Prompt copy-paste cho bước này
Thứ tự: Critical → High → Medium → Low. Mỗi finding lặp lại chu trình này:
Ctrl/Cmd + cuộn chuột để zoom · kéo để di chuyển · ⤢ để mở rộng
Chỉ thay đổi nhỏ nhất để bịt lỗ hổng. Không rename, không "dọn dẹp code", không đụng vào code xung quanh. Fix bảo mật và chỉnh style là hai việc khác nhau.
Nếu fix cần API key, password, hay env var mới, dừng lại và nói rõ developer cần thêm gì, ở đâu. Một secret placeholder viết thẳng vào code tự nó đã là một lỗ hổng.
Prompt copy-paste cho bước này
Ví dụ một finding đã fix trông như thế nào trong báo cáo:
Backlog Medium / Low (ví dụ)
- Medium Endpoint danh sách admin không giới hạn pagination
- Low Thiếu security header (X-Content-Type-Options)
Vài thứ không thể fix bằng cách sửa code: thay API key bị lộ bằng key mới, bật 2FA cho tài khoản hosting/admin, nâng cấp gói hosting để có rate limiting thật sự. Những việc này phải liệt kê rõ ràng, không được bỏ qua âm thầm.
Prompt copy-paste cho bước này
Không bao giờ áp dụng một fix mà không thể giải thích trong một câu đơn giản.
Không bao giờ tự bịa secret, key, hay password. Dừng lại và hỏi thay vì đoán.
Một fix, một lần test, một commit. Không bao giờ gộp nhiều fix lại với nhau.
Không thay đổi behavior hay UX âm thầm. Phải báo trước khi áp dụng.
Nếu fix làm hỏng gì đó, revert và báo cáo lại thay vì vá tạm qua loa.
Mọi finding phải dựa trên nguồn thật: CVE, CWE, category OWASP, docs chính thức.
Khi một finding không rõ ràng, dừng lại và hỏi thay vì đoán.
STRIDE và OWASP Top 10 không phải là tất cả. Tùy nhu cầu, các framework dưới đây có thể bổ sung thêm.
Mỗi finding giờ trích thêm CWE ID bên cạnh CVE ID và category OWASP, giúp phân loại lỗi chính xác hơn.
Research thêm CIS Benchmark cho config hạ tầng (Docker, cloud, Kubernetes) khi app có phần deployment.
Threat model gắn với business impact, nặng hơn STRIDE
Mô hình chấm điểm severity, hay đi kèm STRIDE
Hàng trăm yêu cầu kiểm thử cụ thể, chi tiết hơn Top 10 nhiều
Nêu đúng loại lỗi, ví dụ CWE-89 SQL injection, thay vì chỉ một category chung
Ma trận tactic và technique kẻ tấn công thật sự dùng, hợp với red-team persona
Chuẩn provenance cho build, biết code build ra từ đâu và bằng cách nào
Danh sách kiểm kê dependency, CycloneDX hoặc SPDX, hơn hẳn chỉ chạy npm audit
Thực hành bảo mật xuyên suốt quy trình phát triển phần mềm
Chuẩn hardening cho config OS, cloud, container
Chuẩn tuân thủ, chỉ cần khi app phải qua audit chính thức