Security scan khác gì security audit? Vì sao scanner không đủ cho web app thật

ℹ️ Info: TL;DR: Security scan là bước kiểm tra nhanh bằng công cụ. Security audit là quá trình xác minh thủ công trong phạm vi được ủy quyền, nối các dấu hiệu rời rạc thành rủi ro thật và roadmap fix rõ ràng. Với SMB có web app/API riêng, scanner là điểm bắt đầu, không phải câu trả lời cuối cùng.

1. Vì sao chủ doanh nghiệp hay nhầm hai khái niệm này?

Khi một công cụ trả về 30-100 cảnh báo, cảm giác đầu tiên là: "Mình đã audit xong rồi".

Thực tế không đơn giản vậy.

Scanner có thể nói bạn thiếu header, dùng thư viện cũ, hoặc có endpoint đáng chú ý. Nhưng scanner thường không biết:

• Luồng đăng nhập của bạn hoạt động ra sao.
• Quyền admin và quyền nhân viên khác nhau thế nào.
• Một endpoint có liên quan đến đơn hàng, dữ liệu khách hay thanh toán không.
• Hai lỗi nhỏ khi nối lại có thành rủi ro lớn không.
• Lỗi nào cần fix ngay, lỗi nào có thể đưa vào backlog.

Với founder, câu hỏi quan trọng không phải là "có bao nhiêu warning". Câu hỏi quan trọng là: "Có rủi ro nào đủ thật để ảnh hưởng khách hàng, doanh thu hoặc deal với đối tác không?"

2. Security scan là gì?

Security scan là quá trình dùng tool để kiểm tra nhanh các dấu hiệu phổ biến.

Ví dụ:

• Security headers.
• SSL/TLS configuration.
• Public CVE theo version đã lộ.
• Endpoint hoặc file public dễ nhận diện.
• Một số pattern cấu hình sai thường gặp.

Scan tốt vì nhanh, rẻ, lặp lại được. Nó phù hợp để tạo baseline định kỳ hoặc phát hiện lỗi cấu hình dễ thấy.

Nhưng scan có giới hạn lớn: nó nhìn hệ thống như một danh sách dấu hiệu, không như một sản phẩm có người dùng, dữ liệu, quyền hạn và quy trình kinh doanh.

3. Security audit là gì?

Security audit là kiểm tra có phạm vi, có xác minh thủ công, có đánh giá tác động và có roadmap fix.

Một audit đúng nghĩa thường trả lời các câu hỏi:

• Rủi ro này có tái hiện được không?
• Điều kiện khai thác là gì?
• Ai có thể bị ảnh hưởng?
• Dữ liệu hoặc hành động nào có thể bị lạm dụng?
• Lỗi này đứng một mình hay nối được với lỗi khác?
• Team nên fix theo thứ tự nào?

Điểm khác biệt không nằm ở việc dùng tool hay không. Audit vẫn dùng tool. Khác biệt nằm ở việc con người chịu trách nhiệm xác minh và diễn giải rủi ro.

4. Bảng so sánh nhanh

5. Khi nào scan là đủ?

Scan có thể đủ nếu bạn chỉ cần:

• Kiểm tra nhanh trước khi launch landing page đơn giản.
• Theo dõi định kỳ những lỗi cấu hình phổ biến.
• Có team kỹ thuật đủ mạnh để tự triage toàn bộ warning.
• Không xử lý dữ liệu nhạy cảm, thanh toán, tài khoản người dùng hoặc API quan trọng.

Nếu website chỉ là brochure site, scan định kỳ có thể là một bước hợp lý.

6. Khi nào cần audit?

Bạn nên cân nhắc audit nếu có một trong các dấu hiệu sau:

• Web app có đăng nhập, phân quyền, admin portal hoặc API riêng.
• Có dữ liệu khách hàng, đơn hàng, thanh toán, hợp đồng hoặc hồ sơ nhân sự.
• Sắp raise round, ký với khách enterprise hoặc bị đối tác hỏi về security posture.
• Vừa outsource build app và chưa có ai kiểm tra độc lập.
• Có nhiều integration: payment gateway, POS, CRM, LarkBase, ERP, webhook.
• Team kỹ thuật nhỏ, không có security engineer chuyên trách.

Đây là nhóm mà Diginno đang tập trung: SMB có hệ thống thật, nhưng chưa đủ lớn để có CISO/SOC riêng.

7. Audit tốt nên có gì trong report?

Một report hữu ích với founder và team kỹ thuật nên có:

• Executive summary: đọc nhanh để hiểu mức độ rủi ro.
• Risk matrix: lỗi nào critical/high/medium/low.
• Technical finding: mô tả đủ để dev hiểu và fix.
• PoC đã verify: chứng minh lỗi thật, nhưng không public bừa bãi.
• Attack chain: nếu nhiều lỗi nhỏ nối thành rủi ro lớn.
• Business impact: ảnh hưởng dữ liệu, tiền, vận hành hoặc uy tín.
• Remediation roadmap: fix gì trước, fix gì sau.
• Retest status: xác nhận sau khi sửa.

Scanner thường dừng ở một phần nhỏ của danh sách trên.

8. Nguyên tắc quan trọng: phải có scope và ủy quyền

Security audit không phải là "thấy site ai đó rồi tự kiểm tra sâu".

Một audit đúng cần có:

• Phạm vi domain/app/API rõ ràng.
• Thời gian kiểm thử rõ ràng.
• Tài khoản test nếu cần.
• Giới hạn kỹ thuật: không DDoS, không phá dữ liệu, không vượt scope.
• Cách báo cáo và xử lý finding.

Đây là lý do Diginno không đi theo hướng audit lén hoặc email dọa khách. Trust-first quan trọng hơn một lead ngắn hạn.

9. Diginno làm khác gì?

Diginno định vị security audit cho SMB theo 3 nguyên tắc:

1. Audit như hacker nghĩ, không phải như scanner chạy. Report phải có attack chain, business logic và roadmap, không chỉ list warning.
2. AI-augmented, không AI-thay-người. AI hỗ trợ recon, đọc pattern và draft report; finding quan trọng vẫn phải được con người verify.
3. SMB-friendly. Scope gọn, SOW ngắn, pricing rõ, SLA 5-10 ngày cho web audit pilot.

Nếu bạn đang vận hành SaaS, e-commerce hoặc web app có API riêng, có thể xem thêm dịch vụ Security Audit cho SMB của Diginno.

✅ Success: Bước nhỏ nhất nên làm: đặt lịch security screen 15 phút. Không probe sâu, không dọa, chỉ rà nhanh những dấu hiệu public và xác định có nên audit sâu hơn không.