Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn là QA Lead của một startup fintech tại TP.HCM. Sản phẩm chạy mượt, mọi test case chức năng đều pass xanh mướt, khách hàng khen giao diện đẹp. Rồi một sáng thứ Bảy, đội vận hành phát hiện có kẻ đã khai thác một lỗ hổng SQL Injection ở màn hình đăng nhập và tải về toàn bộ 40.000 bản ghi thông tin khách hàng — số CMND, số tài khoản, số dư. Không một test case chức năng nào của bạn bắt được điều này, đơn giản vì bạn chỉ kiểm tra "phần mềm làm đúng những gì được yêu cầu", chứ chưa bao giờ kiểm tra "phần mềm KHÔNG làm những gì kẻ xấu muốn".
Đó chính là khoảng trống mà Security Testing lấp đầy. Với vai trò QA Leader, bạn không cần trở thành hacker mũ trắng chuyên nghiệp, nhưng bạn BẮT BUỘC phải hiểu quy trình security testing để: (1) đưa nó vào chiến lược test tổng thể, (2) biết khi nào cần thuê pentest bên ngoài, (3) đọc hiểu báo cáo lỗ hổng và quản lý việc vá lỗi, và (4) thuyết phục ban lãnh đạo rằng bảo mật không phải chi phí mà là bảo hiểm. Đặc biệt trong bối cảnh Việt Nam với Nghị định 13/2023 về bảo vệ dữ liệu cá nhân và các yêu cầu của Ngân hàng Nhà nước, bỏ qua security testing giờ đây không chỉ là rủi ro kỹ thuật mà còn là rủi ro pháp lý và uy tín.
Khái niệm cốt lõi
Security Testing là gì và khác gì testing thông thường
Testing chức năng trả lời câu hỏi "Hệ thống có làm đúng điều nó nên làm không?". Security testing trả lời câu hỏi ngược lại: "Hệ thống có bị ép làm điều nó KHÔNG nên làm không?". Nó tập trung vào bốn thuộc tính kinh điển (mô hình CIA + hai bổ sung):
- Confidentiality (Bảo mật): dữ liệu chỉ người có quyền mới xem được.
- Integrity (Toàn vẹn): dữ liệu không bị sửa đổi trái phép.
- Availability (Sẵn sàng): hệ thống không bị đánh sập (ví dụ DoS).
- Authentication & Authorization: đúng người, đúng quyền.
Các cấp độ / kỹ thuật security testing
Đây là phần "xương sống" mà một QA Leader cần nắm để thiết kế chiến lược. Có bốn lớp bổ sung cho nhau, không thay thế nhau:
SAST — Static Application Security Testing (Phân tích tĩnh): Quét mã nguồn khi chương trình KHÔNG chạy. Công cụ như SonarQube, Checkmarx, Semgrep đọc code và phát hiện các mẫu nguy hiểm: chuỗi SQL nối trực tiếp, mật khẩu hardcode, dùng hàm mã hóa yếu (MD5). Ưu điểm: chạy sớm, ngay trong pipeline CI, chi phí sửa rẻ vì bắt lỗi lúc lập trình. Nhược điểm: nhiều false positive và không thấy được lỗ hổng phát sinh lúc runtime.
DAST — Dynamic Application Security Testing (Phân tích động): Quét ứng dụng ĐANG CHẠY từ bên ngoài, giống góc nhìn của hacker không có source code (black-box). Công cụ tiêu biểu: OWASP ZAP (miễn phí), Burp Suite (chuẩn công nghiệp), Acunetix. Nó tự động gửi hàng nghìn payload độc hại vào các endpoint để dò XSS, SQLi, lỗi cấu hình. Ưu: tìm lỗ hổng thực tế mà kẻ tấn công thật sự thấy. Nhược: chạy muộn (cần môi trường triển khai), không chỉ ra dòng code nào lỗi.
SCA — Software Composition Analysis (Phân tích thành phần / dependency): Ngày nay 70–90% một ứng dụng là thư viện bên thứ ba. SCA (Snyk, Dependabot, OWASP Dependency-Check) đối chiếu danh sách thư viện bạn dùng với cơ sở dữ liệu lỗ hổng đã công bố (CVE). Sự cố Log4Shell năm 2021 là ví dụ điển hình: một thư viện logging phổ biến chứa lỗ hổng khiến hàng triệu ứng dụng dính đòn chỉ sau một đêm. SCA chính là lá chắn cho loại rủi ro này.
IAST — Interactive Application Security Testing: Lai giữa SAST và DAST. Một agent được cắm vào runtime, vừa thấy code vừa thấy hành vi thực thi, nên vừa chính xác cao vừa ít false positive. Chi phí cao hơn, thường dùng ở tổ chức trưởng thành.
Penetration Testing (Pentest) — con người thay vì công cụ
Nếu SAST/DAST là quét tự động, thì pentest là chuyên gia con người mô phỏng một cuộc tấn công thật, có chủ đích và sáng tạo. Máy không nghĩ ra được chuỗi tấn công phức tạp kiểu "lợi dụng lỗi phân quyền A để lấy token, rồi kết hợp với lỗi logic B để nâng quyền admin". Con người thì có. Pentest thường chia ba mức theo lượng thông tin cấp cho tester:
- Black-box: tester không biết gì về hệ thống (giống hacker ngoài).
- Grey-box: tester có tài khoản người dùng thường, một phần tài liệu.
- White-box: tester có cả source code và sơ đồ kiến trúc (kỹ lưỡng nhất).
Tình huống thực tế
Tình huống 1 — Sàn thương mại điện tử và lỗ hổng phân quyền
Một sàn TMĐT tầm trung ở Hà Nội (gọi là "ShopViet", ~2 triệu người dùng) tự tin vì đã tích hợp OWASP ZAP vào pipeline, mỗi lần deploy đều quét DAST và không thấy cảnh báo đỏ. Tuy nhiên khi thuê một đội pentest grey-box, chuyên gia chỉ mất 3 giờ để phát hiện một lỗi IDOR (Insecure Direct Object Reference): URL xem đơn hàng có dạng /order/detail?id=100234, và chỉ cần đổi số id, người dùng bất kỳ có thể xem đơn hàng — kèm địa chỉ, số điện thoại — của người khác.
Vì sao ZAP không bắt được? Vì đây là lỗi logic nghiệp vụ, không phải mẫu tấn công cú pháp. Máy không biết "đơn 100234 lẽ ra chỉ thuộc về user A". CVSS của lỗi này là 7.5 (High). Bài học: công cụ tự động là điều kiện cần nhưng không đủ; các lỗ hổng phân quyền (Broken Access Control — hạng mục số 1 trong OWASP Top 10) gần như luôn cần con người kiểm thử. QA Leader nên thiết kế test case phân quyền thủ công như một phần bắt buộc của mỗi tính năng liên quan đến dữ liệu người dùng.
Tình huống 2 — Fintech và yêu cầu pentest định kỳ theo quy định
Một công ty ví điện tử tại TP.HCM chuẩn bị xin giấy phép trung gian thanh toán. Ngân hàng Nhà nước và tiêu chuẩn PCI-DSS (nếu xử lý thẻ) yêu cầu pentest độc lập ít nhất mỗi năm một lần và sau mỗi thay đổi hạ tầng lớn. QA Leader ở đây đã làm đúng: xây dựng lịch security testing phân tầng — SAST + SCA chạy tự động mỗi commit, DAST chạy hằng đêm trên môi trường staging, và pentest bên thứ ba (thuê một công ty như VNPT Cyber Immunity hoặc CyRadar) hai lần mỗi năm.
Lần pentest đầu tiên tìm ra 23 lỗ hổng: 2 Critical, 5 High, 16 còn lại Medium/Low. Điều quan trọng không phải con số, mà là quy trình sau đó: đội đã đưa từng lỗ hổng vào defect tracking như một bug thật, gán severity theo CVSS, đặt SLA vá (Critical: 24h, High: 7 ngày), và quan trọng nhất là retest để xác nhận đã vá đúng. Bài học: với ngành có quy định, pentest không phải lựa chọn mà là nghĩa vụ tuân thủ; và một báo cáo pentest chỉ có giá trị khi được quản lý vòng đời như bug, có retest chứng minh, chứ không phải xếp xó.
Tình huống 3 — Startup SaaS và cú sốc dependency
Một startup SaaS 15 người xây sản phẩm bằng Node.js, tốc độ ship tính năng rất nhanh nhưng chưa từng để tâm đến bảo mật thư viện. Khi một khách hàng doanh nghiệp lớn yêu cầu bảng đánh giá bảo mật trước khi ký hợp đồng, họ chạy Snyk lần đầu và phát hiện 47 lỗ hổng đã biết trong các dependency, trong đó có một CVE cho phép Remote Code Execution qua một thư viện parse ảnh cũ. Không ai trong đội viết dòng code lỗi nào cả — lỗ hổng đến từ thư viện họ npm install hai năm trước và không bao giờ cập nhật.
Họ mất một tuần để nâng cấp, thay thế và test lại. Sau đó họ cài Dependabot để tự động tạo pull request cập nhật mỗi khi có CVE mới. Bài học: với các đội nhỏ chạy nhanh, mối nguy lớn nhất thường không nằm ở code họ viết mà ở code họ mượn. SCA là "quả ngọt dễ hái" — chi phí gần như bằng 0, tích hợp trong vài giờ, nhưng chặn được cả một lớp tấn công.
Hướng dẫn từng bước
Đây là quy trình xây dựng và vận hành security testing mà bạn có thể áp dụng ngay với vai trò QA Leader:
Bước 1 — Đánh giá bề mặt tấn công và phân loại rủi ro. Trước khi test, hãy lập bản đồ: hệ thống có những điểm vào nào (form đăng nhập, API công khai, upload file, tích hợp bên thứ ba)? Dữ liệu nào nhạy cảm nhất? Ứng dụng ngân hàng khác hoàn toàn blog nội bộ. Dùng nguyên tắc risk-based để dồn nguồn lực vào nơi rủi ro cao nhất.
Bước 2 — Cài lớp phòng thủ tự động vào pipeline (shift-left). Tích hợp SAST (ví dụ Semgrep) và SCA (ví dụ Snyk) chạy trên mỗi pull request. Đặt "quality gate": nếu phát hiện lỗ hổng Critical/High mới, build fail. Đây là lớp rẻ nhất và bắt lỗi sớm nhất.
Bước 3 — Chạy DAST định kỳ trên môi trường giống production. Cấu hình OWASP ZAP hoặc Burp quét tự động hằng đêm trên staging. Tinh chỉnh để giảm false positive, xây dựng "baseline" để chỉ báo động khi có lỗ hổng MỚI.
Bước 4 — Bổ sung kiểm thử bảo mật thủ công có mục tiêu. Với mỗi tính năng chạm dữ liệu người dùng, viết test case cho phân quyền (thử truy cập dữ liệu người khác), kiểm tra input độc hại, kiểm tra session/logout. Đây là nơi QA đóng góp trực tiếp mà không cần công cụ đắt tiền.
Bước 5 — Lên lịch pentest độc lập. Ít nhất mỗi năm một lần, hoặc theo yêu cầu tuân thủ. Chuẩn bị kỹ scope (được test gì, không được test gì), rules of engagement (giờ nào, môi trường nào, ai là đầu mối khi có sự cố), và thỏa thuận pháp lý — vì pentest không có văn bản cho phép là hành vi phạm pháp.
Bước 6 — Quản lý lỗ hổng như bug thật. Nhập mọi phát hiện vào hệ thống tracking, chấm CVSS, gán SLA vá theo severity, và bắt buộc retest sau khi vá. Theo dõi chỉ số như "thời gian trung bình để vá lỗ hổng Critical" (Mean Time to Remediate).
Bước 7 — Báo cáo và lặp lại. Tổng hợp xu hướng cho ban lãnh đạo (số lỗ hổng theo thời gian, tỉ lệ vá đúng hạn) và đưa các mẫu lỗi lặp lại vào chương trình đào tạo secure coding cho lập trình viên.
Lỗi thường gặp & mẹo
Lỗi 1 — Tin rằng quét tự động là đủ. Như tình huống ShopViet cho thấy, DAST/SAST không bắt được lỗi logic nghiệp vụ. Mẹo: luôn kết hợp automated + manual + pentest con người theo tỉ lệ hợp lý với mức rủi ro.
Lỗi 2 — "Report tồn kho". Nhiều đội chạy pentest chỉ để có tấm giấy chứng nhận, báo cáo 30 lỗ hổng rồi... để đó. Bảo mật không nằm ở việc TÌM lỗ hổng mà ở việc VÁ và XÁC NHẬN đã vá. Mẹo: không lỗ hổng nào được đóng nếu chưa retest thành công.
Lỗi 3 — Bỏ quên dependency. Đội tự tin về code của mình nhưng quên rằng phần lớn ứng dụng là thư viện mượn. Mẹo: SCA là bước đầu tiên nên làm vì rẻ và hiệu quả cao.
Lỗi 4 — Chạy pentest mà không có giấy phép và scope rõ ràng. Đây vừa là rủi ro pháp lý vừa gây gián đoạn production (một số kỹ thuật có thể làm sập hệ thống). Mẹo: luôn có văn bản cho phép, scope viết rõ, và test trên môi trường được chỉ định.
Lỗi 5 — Chấm severity theo cảm tính. "Lỗi này nghe có vẻ nghiêm trọng" không phải cách ưu tiên. Mẹo: dùng CVSS làm ngôn ngữ chung để cả kỹ thuật lẫn quản lý đồng thuận thứ tự vá.
Mẹo vàng cho QA Leader: Đừng cố biến cả đội thành chuyên gia bảo mật. Thay vào đó, hãy tạo văn hóa "security-aware" — mỗi QA biết đặt câu hỏi bảo mật cơ bản cho tính năng của mình, và biết khi nào cần gọi chuyên gia. Một QA hỏi "nếu tôi đổi id trên URL thì sao?" đã ngăn được hàng loạt lỗ hổng IDOR.
Bài tập thực hành
- Lập bản đồ bề mặt tấn công: Chọn một ứng dụng bạn đang làm (hoặc một app quen thuộc như ví điện tử). Liệt kê tất cả điểm vào dữ liệu (form, API, upload) và đánh dấu 3 điểm rủi ro cao nhất kèm lý do.
- Trải nghiệm DAST: Tải OWASP ZAP (miễn phí) và chạy quét baseline trên một ứng dụng cố ý dễ tổn thương như OWASP Juice Shop. Ghi lại 5 lỗ hổng nó tìm được và tra cứu mỗi lỗi thuộc hạng mục nào trong OWASP Top 10.
- Thiết kế test phân quyền: Viết 5 test case thủ công để phát hiện lỗi Broken Access Control cho chức năng "xem đơn hàng" trong một sàn TMĐT giả định.
- Chấm điểm ưu tiên: Cho danh sách 4 lỗ hổng với mô tả (SQLi trên login, XSS trên trang tìm kiếm, thiếu HTTPS ở trang tĩnh, thư viện có CVE RCE). Hãy sắp xếp thứ tự vá và giải thích dựa trên tác động, dùng logic CVSS.
- Xây kế hoạch pentest: Viết một scope và rules of engagement một trang cho việc thuê pentest cho ứng dụng ở bài tập 1: được test gì, không được gì, môi trường, thời gian, đầu mối liên hệ khẩn cấp.
Tóm tắt
Security testing là mảnh ghép mà testing chức năng không bao giờ thay thế được: nó kiểm tra hệ thống KHÔNG làm điều kẻ xấu muốn. Bốn lớp kỹ thuật bổ sung nhau — SAST quét code tĩnh, DAST quét app đang chạy, SCA canh chừng thư viện bên thứ ba, và IAST kết hợp cả hai — tạo thành lưới phòng thủ tự động rẻ và sớm. Nhưng công cụ không đủ: pentest với trí tuệ con người là bắt buộc để bắt các lỗ hổng logic như phân quyền, và với ngành fintech/ngân hàng ở Việt Nam đó còn là nghĩa vụ tuân thủ.
Với vai trò QA Leader, giá trị bạn tạo ra không phải tự mình hack, mà là: đưa security vào chiến lược test theo hướng risk-based, tích hợp lớp tự động vào pipeline, biết khi nào thuê chuyên gia ngoài, và — quan trọng nhất — quản lý vòng đời lỗ hổng như bug thật với CVSS, SLA và retest bắt buộc. Ba tình huống trong bài đều chỉ về một sự thật: tìm ra lỗ hổng chỉ là nửa đầu; vá được và chứng minh đã vá mới là bảo mật thật sự.