Báo cáo lỗ hổng CRA: mô hình 24 giờ cho nhà sản xuất Thái Lan

Nghĩa vụ báo cáo của Đạo luật Khả năng phục hồi Không gian mạng của EU (Cyber Resilience Act, CRA) bắt đầu áp dụng từ ngày 11 tháng 9 năm 2026. Nhà sản xuất tại Thái Lan phát triển máy móc công nghiệp, thiết bị IoT hoặc phần mềm nhúng cho thị trường EU cần một mô hình vận hành đưa việc báo cáo lỗ hổng CRA từ cảnh báo sớm trong 24 giờ sang thông báo 72 giờ và báo cáo cuối cùng. Bài viết kết nối phân loại phạm vi, PSIRT, SBOM sản phẩm, ENISA Single Reporting Platform (SRP), yêu cầu RFP, lộ trình 90 ngày và kiểm thử nghiệm thu.

Lưu ý quan trọng: Đây là hướng dẫn vận hành dựa trên thông tin chính thức có sẵn vào ngày 20 tháng 9 năm 2026, không phải tư vấn pháp lý. Khả năng áp dụng, vai trò của chủ thể kinh tế, nghĩa vụ báo cáo và tuyến báo cáo đúng phụ thuộc vào sản phẩm, hợp đồng và mô hình phân phối tại EU. Hãy xác nhận từng trường hợp với chuyên gia pháp lý, đánh giá sự phù hợp và an ninh mạng có năng lực.

Vì sao báo cáo lỗ hổng CRA không chỉ là công việc tài liệu

Khi chuẩn bị cho CRA, doanh nghiệp thường nghĩ trước đến phát triển an toàn, hồ sơ kỹ thuật, dấu CE và đánh giá sự phù hợp. Báo cáo là một hoạt động khác: đồng hồ bắt đầu từ một sự kiện thực tế. Khi nhà sản xuất nhận biết bằng chứng đáng tin cậy về việc lỗ hổng đang bị khai thác, hoặc nhận biết một sự cố nghiêm trọng ảnh hưởng đến an ninh của sản phẩm, cảnh báo sớm phải được gửi không chậm trễ không chính đáng và trong mọi trường hợp không quá 24 giờ.

Trọng tâm đó khác với hướng dẫn ETSI EN 303 645 về bằng chứng an ninh sản phẩm nói chung. Nó cũng khác với hướng dẫn diễn tập ứng phó sự cố OT tập trung vào vận hành và khôi phục nhà máy. Bài viết này tập trung vào quy trình pháp định của nhà sản xuất để chuyển một sự kiện sản phẩm thành báo cáo cho cơ quan EU.

SOC của nhà máy có thể cô lập mã độc nhưng vẫn không trả lời kịp các câu hỏi về sản phẩm:

• Đối tượng bị ảnh hưởng là tài sản nội bộ hay sản phẩm đã giao cho khách hàng?
• Model, firmware, thành phần phần mềm, nhóm khách hàng và quốc gia thành viên nào bị ảnh hưởng?
• Đây là lỗ hổng thông thường hay có bằng chứng đáng tin cậy về actively exploited vulnerability?
• Sự kiện có thể là severe incident ảnh hưởng đến an ninh sản phẩm theo Điều 14 hay không?
• Pháp nhân nào là manufacturer, ai ra quyết định nội bộ và ai gửi qua SRP?
• CSIRT designated as coordinator (CDaC) nào là đúng?
• Trong 24 giờ đầu, điều gì đã được xác nhận, điều gì chưa biết và khi nào sẽ cập nhật?

Vì vậy, yêu cầu 24 giờ không phải là bài tập điền biểu mẫu. Đó là một quy trình phối hợp sổ đăng ký sản phẩm, product SBOM, thông tin tình báo lỗ hổng, dữ liệu phân phối EU, quyết định PSIRT, rà soát pháp lý, leo thang quản trị và nộp SRP theo cùng một đồng hồ.

Dòng thời gian pháp định sau ngày 11 tháng 9 năm 2026

Điều 14 của Quy định (EU) 2024/2847 và FAQ về SRP của ENISA quy định các mốc sau. Mỗi mốc là giới hạn ngoài cùng; nghĩa vụ cơ bản vẫn là báo cáo không chậm trễ không chính đáng.

Điểm khởi đầu theo luật không phải là ngày CVE được công bố hay ngày bản vá hoàn thành. Đó là khi nhà sản xuất nhận biết AEV hoặc SI. Trong vận hành, tổ chức nên bắt đầu đồng hồ nội bộ ngay khi nhận tín hiệu hoặc trường hợp nghi ngờ đầu tiên để điều tra và leo thang sớm; đồng hồ nội bộ này không thay thế điểm nhận biết theo luật. Hồ sơ vụ việc nên lưu riêng thời điểm tiếp nhận tín hiệu, thời điểm xác nhận bằng chứng khai thác đáng tin cậy, thời điểm xác định nhà sản xuất đã nhận biết AEV hoặc SI, thời điểm leo thang cho pháp lý và quản lý, và thời điểm nộp. Gộp chúng thành một mốc sau này sẽ làm mất dấu vết quyết định.

Không chờ điều tra hoàn chỉnh mới gửi cảnh báo 24 giờ

Cảnh báo sớm không phải báo cáo nguyên nhân gốc hoàn chỉnh. ENISA giải thích rằng một số trường có thể chưa bắt buộc ở giai đoạn cảnh báo nhưng sẽ trở thành bắt buộc trong thông báo 72 giờ hoặc báo cáo cuối. Bản dự thảo hiệu quả cần tách biệt sự kiện đã xác nhận, đánh giá ban đầu có cơ sở, vấn đề chưa rõ và lịch cập nhật tiếp theo.

Điều này không cho phép dữ liệu cơ bản luôn ở trạng thái “chưa biết”. Mã định danh sản phẩm, các quốc gia thành viên nơi sản phẩm được cung cấp, người phụ trách và thời điểm nhận biết phải truy xuất được trong hoạt động bình thường. Nếu 18 giờ đầu chỉ dùng để tìm bảng tính, sẽ không còn đủ thời gian cho quyết định, rà soát và nộp.

Phân biệt AEV và SI

Theo CRA, AEV là lỗ hổng có bằng chứng đáng tin cậy rằng tác nhân độc hại đã khai thác trong một hệ thống mà không có sự cho phép của chủ sở hữu. “Có thể khai thác”, một proof of concept đã công bố hoặc kết quả quét không tự động có cùng ý nghĩa. SI liên quan đến sự kiện ảnh hưởng nghiêm trọng, hoặc có khả năng ảnh hưởng nghiêm trọng, đến khả năng của sản phẩm trong việc bảo vệ tính sẵn sàng, xác thực, toàn vẹn hoặc bí mật của dữ liệu hay chức năng quan trọng; hoặc dẫn đến, hay có thể dẫn đến, việc đưa vào hoặc thực thi mã độc.

Việc phân loại có thể cần diễn giải pháp lý, nhưng đội kỹ thuật có thể chuẩn bị bằng chứng: log liên quan, đường khai thác, hành vi quan sát được, sản phẩm và phiên bản bị ảnh hưởng, khả năng tái hiện trong môi trường khách hàng, tác động đến dữ liệu hoặc chức năng, chỉ dấu xâm nhập và biện pháp tạm thời đã xác minh. Gắn nhãn rõ từng mục là sự kiện, đánh giá hay giả định.

Xác định sản phẩm và vai trò trong 30 phút đầu

Một máy được chế tạo tại Thái Lan có thể chứa PLC, máy tính công nghiệp, HMI, cổng bảo trì từ xa, bảng điều khiển đám mây, ứng dụng di động và thư viện nguồn mở. OEM, ODM, chủ thương hiệu, nhà nhập khẩu EU và nhà phân phối có thể là các pháp nhân khác nhau. Bộ phận CNTT không nên tự chọn chủ thể báo cáo khi ranh giới sản phẩm và vai trò kinh tế còn chưa rõ.

Dùng phiếu phân loại ban đầu theo thứ tự:

1. Đối tượng có thể là “product with digital elements” thuộc phạm vi CRA hay không?
2. Sản phẩm đã được cung cấp trên thị trường EU chưa, theo model, thương hiệu, hợp đồng và tuyến bán nào?
3. Tổ chức đóng vai trò manufacturer, authorised representative, importer hay distributor đối với sản phẩm đó?
4. Sự kiện chỉ giới hạn ở CNTT doanh nghiệp hay có thể ảnh hưởng đến an ninh sản phẩm?
5. Bằng chứng nào cho thấy có thể là AEV hoặc SI?
6. Hiện đã xác định được phiên bản, thành phần, quốc gia thành viên và người dùng nào?
7. Ai ghi thời điểm nhận biết và dựa trên bằng chứng nào?

Phiếu này không tự động kết luận pháp lý. Mục đích là cung cấp đủ sự kiện cho PSIRT, pháp lý và chủ sở hữu đánh giá sự phù hợp quyết định nhanh. Sản phẩm ở ranh giới cần có đường leo thang định trước đến chuyên gia có năng lực.

ENISA Single Reporting Platform và định tuyến CSIRT

SRP là nền tảng báo cáo CRA duy nhất do ENISA phát triển, vận hành và duy trì. Nền tảng hoạt động từ ngày 11 tháng 9 năm 2026. Nhà sản xuất nộp thông báo AEV và SI bắt buộc theo phương thức điện tử, chọn CDaC liên quan và báo cáo một lần thay vì gửi riêng cho nhiều cơ quan quốc gia. Theo nguyên tắc chung, nội dung cũng được cung cấp đồng thời cho ENISA, còn CDaC tiếp nhận sẽ phổ biến thông tin liên quan đến các CSIRT và cơ quan khác khi cần.

Nhà sản xuất có trụ sở tại Thái Lan chọn CDaC như thế nào

FAQ của ENISA, cập nhật ngày 17 tháng 9 năm 2026, nêu rằng chỉ cần một thông báo cho một AEV hoặc SI, kể cả khi nhà sản xuất có nhiều chi nhánh EU hoặc công ty mẹ ở ngoài EU. Nhà sản xuất phải tự phối hợp nội bộ.

Main establishment trong EU là quốc gia thành viên nơi các quyết định liên quan đến an ninh mạng sản phẩm chủ yếu được đưa ra. Nếu không xác định được, sử dụng quốc gia có cơ sở EU với số nhân viên cao nhất. Khi nhà sản xuất không có main establishment tại EU, Điều 14(7) áp dụng thứ tự sau dựa trên thông tin nhà sản xuất có:

1. quốc gia thành viên nơi authorised representative đại diện cho số lượng sản phẩm có yếu tố số nhiều nhất được thành lập;
2. nếu không áp dụng, quốc gia nơi importer đưa số lượng sản phẩm lớn nhất ra thị trường được thành lập;
3. nếu không áp dụng, quốc gia nơi distributor cung cấp số lượng sản phẩm lớn nhất được thành lập;
4. nếu không có trường hợp nào, quốc gia thành viên có số người dùng sản phẩm nhiều nhất.

Thuật ngữ rất quan trọng. ENISA gọi người dùng SRP là Assigned Representative (AR). Vai trò vận hành nền tảng này khác với authorised representative, một vai trò chủ thể kinh tế theo CRA. Quy trình nội bộ không được dịch hoặc viết tắt hai vai trò thành một khái niệm mơ hồ.

ENISA duy trì danh sách CDaC, được cập nhật ngày 10 tháng 9 năm 2026. Không suy đoán tuyến chỉ từ danh sách quốc gia bán hàng. Hãy lưu sự kiện, lý do chọn và người rà soát. ENISA cảnh báo rằng chọn sai CDaC có thể khiến thông báo bị vô hiệu và phải nộp lại.

Đưa quyền truy cập SRP vào mô hình vận hành

Khi ra mắt, SRP chỉ có tiếng Anh. Assigned Representative cần tài khoản EU Login cá nhân có MFA. Primary AR tạo liên kết ban đầu với nhà sản xuất và có thể mời Secondary AR. FAQ nêu một nhà sản xuất có một Primary AR và tối đa 20 Secondary AR. Cả hai có thể nộp và cập nhật theo quyền; AR gắn với cùng nhà sản xuất có thể tiếp tục xử lý cùng thông báo, ngoại trừ draft được lưu cục bộ trong tài khoản cá nhân.

ENISA cho biết việc xác minh liên kết diễn ra song song và không chặn nộp; nếu đã có EU Login hoạt động, đăng ký chỉ mất vài phút. Hướng dẫn cũng khuyến nghị đăng ký khi cần nộp thông báo thay vì tạo liên kết không cần thiết từ trước. Do đó, khả năng sẵn sàng nên tập trung vào danh sách người đã được duyệt, MFA, thuật ngữ tiếng Anh, phương án khi nghỉ phép hoặc nghỉ việc, rà soát hai người và lưu bằng chứng. Khi diễn tập, dùng hướng dẫn hiện hành và tabletop walkthrough được kiểm soát, không tạo thông báo giả trên hệ thống thật.

Biến product SBOM từ một tệp thành truy vấn trong 24 giờ

CRA định nghĩa SBOM là hồ sơ chính thức chứa chi tiết thành phần và quan hệ chuỗi cung ứng trong các yếu tố phần mềm của sản phẩm. Chỉ lưu tệp SBOM chưa tạo ra năng lực vận hành. Quy trình phải truy ngược từ thành phần có lỗ hổng đến sản phẩm, phiên bản, build, khách hàng, quốc gia thành viên, trạng thái hỗ trợ và người phụ trách khắc phục.

Dữ liệu tối thiểu cần kết nối

Kiểm kê tài sản nhà máy trong hướng dẫn quản lý tài sản OT không giống sổ đăng ký sản phẩm đã cung cấp cho khách hàng. Loại thứ nhất bảo vệ và bảo trì tài sản tại cơ sở của nhà sản xuất. Loại thứ hai phục vụ phân tích tác động và báo cáo cho sản phẩm đã giao. Hai hệ thống có thể dùng mã chung, nhưng chủ sở hữu, quyền cập nhật và thời hạn lưu phải minh bạch.

Lỗ hổng trong thành phần bên thứ ba

Nếu AEV nằm trong thư viện nguồn mở hoặc mô-đun mua ngoài, không kết luận rằng nó không liên quan vì công ty không viết mã. Ngược lại, cũng không giả định mọi nhà sản xuất dùng cùng thành phần đều có kết luận báo cáo giống nhau. Kiểm tra cách tích hợp, khả năng tiếp cận hàm có lỗi, cấu hình, tuỳ chọn build, phiên bản sản phẩm, bằng chứng khai thác đáng tin cậy và nội dung nhà sản xuất thực sự nhận biết. Đối chiếu với hướng dẫn của Commission về third-party components và xin xác nhận chuyên môn.

Hồ sơ PSIRT phải chứa ánh xạ vào sản phẩm của chính nhà sản xuất, không chỉ sao chép upstream advisory. Ghi phiên bản thành phần, chức năng sử dụng, call path, mức phơi bày bên ngoài, compile setting, compensating control, bản phát hành bị ảnh hưởng, kế hoạch sửa, câu hỏi cho supplier và biện pháp khách hàng đã xác minh.

Vận hành báo cáo 24 giờ, 72 giờ và cuối cùng qua PSIRT

24 giờ đầu: làm cho cảnh báo sớm khả thi

Các khoảng trên là mục tiêu vận hành mẫu, không phải phân bổ do luật quy định. Chúng tạo buffer cho chờ và làm lại, không phải lý do để giữ báo cáo đến giờ thứ 24.

Thông báo 72 giờ: cập nhật đánh giá ban đầu

Đến giai đoạn 72 giờ, cập nhật sản phẩm và phiên bản, bản chất chung của khai thác hoặc sự cố, đánh giá tác động ban đầu, biện pháp đã thực hiện hoặc dự kiến, biện pháp người dùng có thể áp dụng và độ nhạy của thông tin. Nếu patch chưa sẵn sàng, mô tả biện pháp tạm thời đã xác minh như cô lập, đổi cấu hình, vô hiệu hoá chức năng, tăng giám sát hoặc hạn chế truy cập.

Quản lý thay đổi rõ ràng. Nếu giả thuyết ban đầu bị bác bỏ, không ghi đè mà không để dấu vết. Ghi bằng chứng mới và lý do đánh giá thay đổi. ENISA lưu ý counter và reminder của nền tảng không thay thế trách nhiệm của nhà sản xuất trong việc tính hạn từ thời điểm nhận biết và báo cáo không chậm trễ. Đồng hồ chuẩn phải được duy trì trong case nội bộ.

Báo cáo cuối: khép lại biện pháp và nguyên nhân

Đối với AEV, báo cáo cuối đến hạn không muộn hơn 14 ngày sau khi biện pháp khắc phục hoặc giảm thiểu có sẵn. Nội dung gồm mức độ và tác động của lỗ hổng, thông tin về tác nhân độc hại nếu có, và chi tiết bản cập nhật hoặc biện pháp khác. Đối với SI, báo cáo cuối đến hạn trong vòng một tháng sau thông báo 72 giờ, gồm mô tả chi tiết, mức độ và tác động, mối đe doạ hoặc nguyên nhân gốc có khả năng nhất, và biện pháp đã áp dụng hay đang tiếp tục.

Không đóng case chỉ vì patch đã phát hành. Tiêu chí hoàn tất nên gồm phạm vi phân phối, chữ ký, rollback, thông báo khách hàng, xác nhận triển khai khi khả thi, residual risk, cập nhật SBOM và hồ sơ kỹ thuật, và hành động phòng ngừa. Quy trình cũng phải có người xử lý báo cáo trung gian nếu CDaC yêu cầu.

Phân chia trách nhiệm giữa trụ sở Thái Lan và hoạt động EU

Với nhà sản xuất ngoài EU, thông tin thường chia giữa trụ sở Thái Lan, công ty bán hàng EU, importer, distributor và đối tác dịch vụ. Ma trận tốt phải tách quyết định, nộp, khắc phục kỹ thuật và truyền thông khách hàng.

RACI này chỉ là điểm khởi đầu. Hãy điều chỉnh theo cơ cấu pháp nhân. Nghỉ phép, chênh lệch múi giờ hoặc một người phê duyệt vắng mặt không được làm dừng quy trình. Xác định cửa sổ làm việc giao nhau giữa Thái Lan và châu Âu; vai trò trực mở case và chuẩn bị bằng chứng trước khi ngày làm việc tiếp theo ở châu Âu bắt đầu.

Yêu cầu báo cáo CRA cần đưa vào RFP

Khi mua nền tảng PSIRT, hệ thống SBOM, vulnerability intelligence, case management hoặc dịch vụ ngoài, hãy so sánh kết quả có thể trình diễn thay vì tên tính năng.

Dữ liệu và truy xuất

• Truy ngược từ thành phần đến sản phẩm, phiên bản, build, nhóm khách hàng và quốc gia thành viên.
• Nhận SPDX hoặc CycloneDX, kiểm tra trường thiếu, bản ghi trùng và phiên bản không nhất quán.
• Liên kết CVE, supplier advisory và bằng chứng khai thác với case.
• Quản lý phiên bản early warning, 72-hour notification, final report và user communication.
• Lưu timestamp có thể kiểm toán cho sự kiện, giả định, quyết định, phê duyệt và thay đổi.
• Retention, access control và export phù hợp vòng đời sản phẩm và support period.

Workflow và tính liên tục

• Luồng riêng cho AEV candidate, SI candidate và lỗ hổng thông thường.
• Tính SLA và cảnh báo từng giai đoạn từ awareness time đã ghi.
• Vai trò Thái Lan và EU, phê duyệt thay thế, trực và escalation.
• Soạn tiếng Anh và rà soát hai người cho SRP chỉ có tiếng Anh.
• Bàn giao không phụ thuộc local draft của một Assigned Representative.
• Bằng chứng khi SRP gián đoạn, liên hệ CDaC khi cần và nộp sau khi dịch vụ phục hồi.
• Tách tự động hoá nội bộ khỏi thao tác nhập SRP của con người vì ENISA chưa cung cấp API trong bản đầu.

An ninh và bằng chứng

• Least privilege và MFA cho dữ liệu lỗ hổng, khách hàng và patch chưa công bố.
• Audit log cho export, attachment, approval và thay đổi trước/sau nộp.
• Masking để không dùng dữ liệu thật trong môi trường kiểm thử.
• Điều khoản backup, restore, vùng lưu trữ, subcontractor và thông báo sự cố.
• Xuất case, SBOM và bằng chứng ở định dạng đọc được khi kết thúc hợp đồng.

Không yêu cầu nhà cung cấp chỉ tuyên bố “CRA compliant”. Hãy đưa scenario, input, expected result và evidence vào RFP. Quyết định pháp lý thuộc về người chịu trách nhiệm; hệ thống hỗ trợ sự kiện, thời gian và dấu vết.

Lộ trình triển khai 90 ngày

Ngày 1–30: xác định phạm vi và đồng hồ

Tháng đầu tiên cần xác định khi nào đồng hồ bắt đầu và ai sở hữu, thay vì chờ nền tảng hoàn hảo.

• Lập scope register cho sản phẩm, model, pháp nhân, thương hiệu và tuyến vào EU.
• Ánh xạ vai trò manufacturer và các chủ thể khác; đánh dấu sản phẩm ranh giới để chuyên gia rà soát.
• Chỉ định PSIRT lead, người trực, legal, conformity owner, EU owner và ứng viên SRP AR.
• Thiết lập intake channel cho AEV/SI candidate và quy tắc awareness time duy nhất.
• Thu thập sự kiện cần cho lựa chọn CDaC và lên lịch chuyên gia rà soát.
• Soạn mẫu 24h, 72h và final cùng người phê duyệt thay thế.
• Đo thời gian truy từ SBOM của một sản phẩm đại diện đến nhóm khách hàng.

Đầu ra gồm scope register, role matrix, triage sheet, deadline calculator, contact tree và notification template. Quyết định “ngoài phạm vi” cũng phải có lý do và phê duyệt.

Ngày 31–60: kết nối dữ liệu và thủ tục

Kết nối product SBOM, build provenance, sales/installation và support data bằng mã ổn định. Không chờ mọi sản phẩm hoàn hảo; ưu tiên theo mức hiện diện tại EU, kết nối, phơi bày đe doạ và support period còn lại.

• Định nghĩa SBOM quality gate cho phiên bản, dependency và artefact linkage.
• Thử truy từ thông tin lỗ hổng đến sản phẩm bị ảnh hưởng.
• Giao chủ sở hữu cho dữ liệu importer, distributor, Member State và customer contact.
• Cấu hình bàn giao từ 24h sang 72h và final.
• Tạo English glossary và review rules.
• Thêm bước kiểm tra SRP guidance, CDaC list và Commission guidance mới nhất.
• Thiết lập supplier notification SLA và phiếu hỏi third-party component.

Ngày 61–90: diễn tập và lưu bằng chứng nghiệm thu

Dùng kịch bản giả định đại diện thay vì chỉ đọc quy trình trong cuộc họp. Ghi rõ là giả định và không dùng dữ liệu khách hàng hay lỗ hổng thật.

Ví dụ, giả định PSIRT tại Thái Lan nhận biết lúc 14:00 ICT về bằng chứng khai thác đáng tin cậy ảnh hưởng đến third-party library trong industrial gateway đã cung cấp cho EU. Giới hạn 24 giờ là 14:00 ICT ngày hôm sau; giới hạn 72 giờ là 14:00 ICT sau ba ngày. Đây là phép tính huấn luyện nhất quán, không phải kết luận pháp lý cho vụ việc thật.

Đo thời gian tạo case, tìm SBOM, trích xuất phiên bản, trích xuất quốc gia thành viên, đánh giá AEV candidate, leo thang, soạn cảnh báo tiếng Anh, peer review, lưu bằng chứng mô phỏng và bàn giao 72 giờ. Chấm theo thời gian, dữ liệu thiếu, làm lại, chờ phê duyệt và khả năng thay thế, không chỉ pass/fail.

Kiểm thử nghiệm thu: xác minh năng lực báo cáo, không chỉ xem demo

Thêm mục tiêu nội bộ, không chỉ “trong 24 giờ”. Ví dụ tạo case trong 30 phút, trích xuất tác động cho sản phẩm đại diện trong hai giờ, và có dự thảo cảnh báo trong 12 giờ. Đây là mục tiêu do công ty thiết lập, không phải số trong luật.

Sai sót thường gặp và cách sửa

Sai sót 1: để sự cố corporate SOC và sự cố sản phẩm trong cùng một hàng đợi không phân loại

Hai loại có thể liên quan, nhưng sổ đăng ký và trách nhiệm bên ngoài khác nhau. Xác định điều kiện tách common intake sang product-security case có ID riêng.

Sai sót 2: chờ CVE rồi mới bắt đầu đồng hồ

Định nghĩa và thời hạn CRA không coi CVE là trigger duy nhất. Ghi bằng chứng khai thác đáng tin cậy và thời điểm nhận biết; dùng CVE/EUVD làm tham chiếu hỗ trợ.

Sai sót 3: SBOM là tệp bàn giao, sales register nằm riêng trong ERP

Năng lực cần có là quan hệ có thể tìm kiếm. Định nghĩa key và owner kết nối component, artefact, product version, serial/customer population và Member State.

Sai sót 4: giao toàn bộ cho văn phòng bán hàng EU

Đội EU có thể dẫn việc nộp và làm việc với cơ quan, nhưng bằng chứng kỹ thuật, SBOM và kế hoạch sửa thường ở Thái Lan. Cần một case owner và bàn giao múi giờ để tạo một thông báo thống nhất.

Sai sót 5: yêu cầu nguyên nhân gốc hoàn chỉnh trong 24 giờ

Early warning là giai đoạn đầu của quy trình cập nhật. Nêu rõ bất định rồi cập nhật trong 72 giờ và báo cáo cuối. Đồng thời, dữ liệu sản phẩm, phân phối và liên hệ vốn có sẵn không nên bị để ở trạng thái chưa biết.

Câu hỏi thường gặp về báo cáo CRA trong 24 giờ

Mọi lỗ hổng đều phải báo cáo trong 24 giờ theo CRA phải không?

Báo cáo bắt buộc theo Điều 14 tập trung vào AEV và SI ảnh hưởng an ninh sản phẩm. Không tự động gửi mọi phát hiện chưa bị khai thác ra bên ngoài. Hãy đánh giá định nghĩa, bằng chứng và tác động. ENISA cho biết voluntary reporting sẽ được bổ sung trong giai đoạn SRP sau. Xin tư vấn chuyên môn cho từng vụ việc.

Đồng hồ CRA 24 giờ bắt đầu khi nào?

Bắt đầu khi nhà sản xuất nhận biết AEV hoặc SI. Tuỳ sự kiện, thời điểm đó có thể không trùng với lúc nhận thư, công bố CVE hay phê duyệt quản lý. Lưu timestamp riêng và lý do xác định awareness point.

Công ty Thái Lan có thể gửi email trực tiếp cho ENISA thay SRP không?

Thông báo bắt buộc được nộp qua SRP bằng endpoint CDaC phù hợp. Nếu SRP tạm ngừng, ENISA yêu cầu nộp khi hệ thống phục hồi. Nếu cần liên lạc ngay, có thể liên hệ CDaC trực tiếp, nhưng vẫn phải nộp SRP sau khi phục hồi.

SRP Assigned Representative có giống EU authorised representative không?

Không. Assigned Representative là vai trò Primary/Secondary AR trên nền tảng ENISA. Authorised representative là khái niệm chủ thể kinh tế theo CRA. Phải tách trong mô tả vai trò và bản dịch.

Ai báo cáo AEV trong third-party component?

Kết luận phụ thuộc tích hợp, tác động, bằng chứng và vai trò kinh tế. Ánh xạ thông tin upstream vào sản phẩm thực tế rồi đối chiếu hướng dẫn của Commission. Không giả định báo cáo của upstream xoá nghĩa vụ của nhà sản xuất, cũng không giả định mọi bên tích hợp có nghĩa vụ giống nhau.

Có product SBOM là đã sẵn sàng báo cáo CRA chưa?

Chưa. SBOM phải kết nối với phiên bản, build, quốc gia thành viên, nhóm khách hàng, biện pháp sửa và notification case. Quản lý thời hạn, phê duyệt, nhập SRP, thông báo người dùng và báo cáo cuối là các năng lực riêng.

Có thể hoàn thành triển khai CRA trong 90 ngày không?

Không nhất thiết cho mọi sản phẩm và câu hỏi pháp lý. Lộ trình này tạo minimum viable reporting capability cho sản phẩm ưu tiên và đạt đến quy trình đã diễn tập, có bằng chứng. Sản phẩm còn lại, chất lượng dữ liệu và sửa hợp đồng tiếp tục theo mức rủi ro.

Kết luận: vận hành PSIRT, SBOM và dữ liệu EU theo cùng một đồng hồ

Báo cáo lỗ hổng CRA không thành công chỉ nhờ nhập biểu mẫu nhanh. Nhà sản xuất phải xác định phạm vi sản phẩm và vai trò, lưu thời điểm nhận biết, truy tác động qua product SBOM, gửi cảnh báo sớm qua SRP đến đúng CDaC và chuyển bằng chứng sang thông báo 72 giờ cùng báo cáo cuối. Với nhà sản xuất Thái Lan, quy trình cũng phải nối kỹ thuật tại Thái Lan với trách nhiệm EU, Assigned Representatives, rà soát pháp lý và conformity, cũng như thông báo người dùng.

TOMAS TECH hỗ trợ nhà sản xuất tại Thái Lan cấu trúc product register và liên kết SBOM, PSIRT workflow, yêu cầu RFP, kế hoạch 90 ngày và acceptance test. Chúng tôi không thay thế tư vấn pháp lý; chúng tôi giúp xây dựng bằng chứng kỹ thuật và vận hành mà chuyên gia cần. Quý doanh nghiệp có thể liên hệ với chúng tôi ngay từ giai đoạn lập kế hoạch.

Tài liệu tham khảo

1. European Commission, Cyber Resilience Act reporting obligations
2. ENISA, CRA Single Reporting Platform: Frequently Asked Questions
3. ENISA, Single Reporting Platform
4. European Commission, Cyber Resilience Act – Implementation
5. European Commission, Cyber Resilience Act summary
6. EUR-Lex, Regulation (EU) 2024/2847
7. ENISA, List of CSIRTs Designated as Coordinators
8. ENISA, CRA SRP Guidance – AR User Registration