Vulnerability Disclosure Program: Cách xây dựng VDP cho doanh nghiệp

Một nhà nghiên cứu tìm thấy lỗ hổng trên hệ thống của mày sẽ làm gì? Nếu website không có kênh rõ, họ có thể gửi sales@, nhắn LinkedIn, đăng công khai hoặc bỏ cuộc. Mỗi lựa chọn đều làm doanh nghiệp mất thời gian quý giá. Vulnerability Disclosure Program (VDP) tạo một con đường được định nghĩa trước để người ngoài báo cáo, doanh nghiệp xác nhận, xử lý và phối hợp công bố có trách nhiệm.

VDP không làm hệ thống tự an toàn và không thay penetration testing có phạm vi. Pentest chủ động thuê chuyên gia kiểm tra trong thời gian xác định; VDP là kênh luôn mở cho phát hiện tình cờ hoặc nghiên cứu thiện chí. Hai hoạt động bổ sung nhau: pentest có coverage có chủ đích, VDP mở rộng khả năng nhận tín hiệu ngoài lịch đánh giá.

VDP là gì — và khác bug bounty ở đâu?

VDP là chính sách cùng quy trình cho phép công chúng báo cáo lỗ hổng theo điều kiện công khai. Chương trình mô tả tài sản, loại kiểm thử, hành vi bị cấm, cách gửi báo cáo, cách doanh nghiệp phản hồi và bảo vệ nghiên cứu thiện chí. Bug bounty bổ sung cơ chế thưởng theo điều kiện, severity và quyết định của chương trình. Một VDP có thể không trả thưởng; một bug bounty cần bộ máy VDP bên dưới để intake, triage, fix và giao tiếp.

Đừng mở bounty để “thuê crowd pentest giá rẻ”. Researcher chọn mục tiêu và kỹ thuật theo incentive; doanh nghiệp vẫn phải chịu chi phí triage, duplicate, communication, remediation và fraud control. Nếu intake hiện tại còn bỏ quên email, mở thưởng chỉ đổ thêm lưu lượng vào đường ống vỡ.

Bảy điều kiện tối thiểu trước khi công bố VDP

• Executive sponsor và program owner: có người quyết định scope, ngoại lệ, disclosure và xung đột giữa fix với lịch sản phẩm.
• Asset inventory: biết domain/app nào thuộc mình, vendor nào vận hành và ai sở hữu remediation.
• Kênh intake có người trực: email/form tạo ticket, cảnh báo và backup contact; không phụ thuộc một cá nhân nghỉ phép.
• Triage năng lực: phân biệt lỗ hổng, hardening, spam, duplicate; tái hiện an toàn và bảo vệ bằng chứng.
• Escalation critical: liên hệ trực tiếp on-call/incident response khi báo cáo cho thấy khai thác thực hoặc dữ liệu bị lộ.
• Remediation workflow: ticket riêng tư, owner, deadline theo rủi ro, re-test và quyết định risk acceptance.
• Legal alignment: safe harbor, terms, privacy, export/sanctions khi cần và quyền đối với tài sản bên thứ ba được rà soát.

Viết policy: rõ quyền, rõ giới hạn, bớt ngôn ngữ đe dọa

Policy nên được security, engineering, legal và communications cùng viết. Nó phải dễ đọc với một researcher quốc tế; cân nhắc tiếng Việt và tiếng Anh. CISA nhấn mạnh việc phát triển, công bố và duy trì quy trình hỗ trợ VDP trong hướng dẫn cho cơ quan liên bang Mỹ. Doanh nghiệp Việt Nam không bị ràng buộc bởi chỉ thị đó, nhưng có thể học cấu trúc vận hành và tinh thần hỗ trợ nghiên cứu thiện chí.

Safe harbor cần luật sư điều chỉnh theo pháp nhân và thị trường: doanh nghiệp nêu rằng sẽ không khởi kiện hoặc đề nghị điều tra đối với nghiên cứu thiện chí tuân policy, đồng thời không thể miễn trách nhiệm đối với hệ thống bên thứ ba hay hành vi ngoài phạm vi. Tránh câu mơ hồ “không làm ảnh hưởng hệ thống” mà không giải thích hành vi. Nhà nghiên cứu cần biết mức test nào được coi là hợp lý.

Scope và dữ liệu: ranh giới phải theo quyền sở hữu thật

Liệt kê domain/app chính và quy tắc cho asset liên quan. Với SaaS nhiều tenant, yêu cầu researcher dùng tài khoản tự tạo và chỉ tương tác dữ liệu của họ. Loại trừ vendor-hosted page mà doanh nghiệp không có quyền cho phép kiểm thử; cung cấp cách báo nếu researcher không chắc ownership. Đừng wildcard toàn bộ `*.example.com` nếu subdomain trỏ tới dịch vụ third party hoặc tenant customer.

Policy phải yêu cầu thu thập bằng chứng tối thiểu, redact token/PII, không exfiltrate, không pivot và dừng khi gặp dữ liệu không thuộc tài khoản test. Nếu báo cáo cho thấy dữ liệu cá nhân bị truy cập, VDP phải chuyển thành incident workflow để bảo toàn bằng chứng và đánh giá theo Luật Bảo vệ dữ liệu cá nhân cùng Nghị định 356/2025, thay vì tiếp tục xử lý như ticket bug bình thường.

Thiết kế intake và triage không làm kiệt sức đội ngũ

1. Xác nhận nhận báo cáo. Tự động tạo ticket riêng tư và mã tham chiếu; không tự động xác nhận lỗ hổng hợp lệ.
2. Safety screening. Kiểm tra dữ liệu, khai thác đang diễn ra, credential/secrets và ảnh hưởng production; critical chuyển incident response ngay.
3. Completeness. Thu asset, endpoint, prerequisite, bước tái hiện, impact, evidence, environment và contact; hỏi bổ sung cụ thể.
4. Validation. Tái hiện bằng account/data test, giới hạn quyền xem evidence và ghi version; không chuyển payload không tin cậy tùy tiện.
5. Classification. Đánh giá severity theo exploitability, exposure, privilege, data và business impact; CVSS là input, không phải toàn bộ quyết định.
6. Ownership. Gán engineering/product owner, remediation target và security reviewer; duplicate liên kết vào root issue nhưng vẫn phản hồi lịch sự.
7. Communication. Cập nhật khi trạng thái thay đổi hoặc theo nhịp đã công bố; không biến im lặng thành chiến lược pháp lý.
8. Closure. Fix/re-test, ghi recognition nếu được đồng ý, thống nhất disclosure và rút bài học vào SDLC.

Chống spam bằng filtering, rate control và CAPTCHA phù hợp cho form, nhưng giữ email hoặc phương án thay thế cho reporter gặp accessibility/automation barrier. File đính kèm và URL là input thù địch: sandbox, giới hạn loại/kích thước, quét malware và không mở PoC trên máy production. Triage workstation cùng credential phải được cô lập tương xứng.

security.txt theo RFC 9116: biển chỉ đường, không phải giấy phép

RFC 9116 định nghĩa file máy đọc được tại `/.well-known/security.txt`. File phải có ít nhất Contact và Expires; có thể có Policy, Encryption, Acknowledgments, Canonical và Preferred-Languages. Expires buộc doanh nghiệp kiểm tra thông tin định kỳ. Dùng HTTPS, content type text/plain UTF-8 và Canonical đúng vị trí; cân nhắc chữ ký OpenPGP nếu đội có khả năng vận hành khóa.

RFC nói rõ security.txt bổ trợ, không thay policy, và sự hiện diện của file không tự cấp quyền kiểm thử. Vì vậy Policy URL phải trỏ đến trang VDP đầy đủ. Thiết lập monitor cho HTTP status, expiry, contact và tampering; file stale có thể gửi báo cáo nhạy cảm đến địa chỉ sai. Trang VDP của Trustline là ví dụ về nơi chính sách công khai có thể kết nối với kênh tiếp nhận.

SLA, phối hợp công bố và cách tránh hứa quá tay

Đừng sao chép SLA của chương trình khổng lồ. Công bố expectation mà đội giữ được: thời gian acknowledgment mục tiêu, khi nào reporter nhận validation/update và cách xử lý disclosure. Thời gian fix phụ thuộc severity, exposure, kiến trúc và release; dùng target nội bộ theo rủi ro, còn với reporter hãy minh bạch tiến độ mà không hứa ngày trước khi owner đánh giá.

• Thống nhất embargo/disclosure theo từng case; không mặc định reporter phải im lặng vô thời hạn.
• Không yêu cầu chuyển giao quyền sở hữu nghiên cứu quá rộng chỉ để nhận báo cáo.
• Recognition cần sự đồng ý về tên/handle và nội dung; có researcher muốn ẩn danh.
• Nếu không trả thưởng, nói rõ từ đầu; quà tùy ý không được mô tả như bounty entitlement.
• Khi fix cần nhiều bên, chỉ định coordinator và giữ reporter cập nhật thay vì đẩy họ qua vendor chain.

Đo chương trình và quyết định khi nào mở bug bounty

Theo dõi số báo cáo theo trạng thái nhưng ưu tiên median/thống kê phân phối thời gian acknowledgment, validation, assignment, remediation và update; tỷ lệ duplicate/noise; finding theo asset/root cause; lỗi lặp; coverage asset; satisfaction của reporter. Không đặt KPI “giảm số báo cáo” cho triage team — họ sẽ có động lực đóng nhầm hoặc làm reporter bỏ đi.

Cân nhắc bounty khi VDP đã chạy ổn, asset owner sửa đúng hạn, finance/legal có quy tắc trả thưởng, scope đủ rõ và doanh nghiệp muốn chủ động tăng lượng nghiên cứu. Có thể bắt đầu private/invite để kiểm tra năng lực vận hành trước public. Nhưng pentest vẫn cần cho release critical hoặc coverage đã cam kết; bounty không bảo đảm researcher kiểm tra mọi workflow.

Kết luận: mở cửa chỉ khi bên trong có người đón

VDP tốt biến một tương tác dễ đối đầu thành quy trình hợp tác: reporter biết giới hạn, doanh nghiệp nhận tín hiệu sớm, engineering có owner, legal có nguyên tắc và khách hàng thấy sự minh bạch. Giá trị không nằm ở trang policy bóng bẩy mà ở phản hồi đều, sửa thật và học từ root cause.