Tại sao SOC 2 không bảo vệ bạn khỏi tấn công chuỗi cung ứng?

Chào các bạn phát triển phần mềm!

Hôm nay, chúng ta sẽ thảo luận về một vấn đề đang khiến tôi băn khoăn trong nhiều tuần qua. Tôi thường thấy các công ty ăn mừng việc tuân thủ SOC 2 như thể họ vừa giành chiến thắng tại Champions League, nhưng rồi lại bị tấn công chuỗi cung ứng một cách thảm hại.

Nó giống như việc bạn khóa cửa trước nhưng để tất cả các cửa sổ mở toang.

Những con số khiến tôi phải suy nghĩ

Trong quá trình nghiên cứu cho một dự án khách hàng, tôi đã vô tình tìm thấy một số dữ liệu khiến tôi phải ngừng lại:

Báo cáo vi phạm dữ liệu 2025 của Verizon:

• 30% tất cả các vụ vi phạm hiện nay liên quan đến bên thứ ba (gấp đôi chỉ trong một năm!)

Báo cáo chi phí vi phạm dữ liệu 2025 của IBM:

• Chi phí vi phạm trung bình: 4.44 triệu USD toàn cầu, 10.22 triệu USD tại Mỹ
• Vi phạm chuỗi cung ứng mất 267 ngày để phát hiện và khắc phục

Nghiên cứu của BlackBerry:

• 75% tổ chức đã bị tấn công chuỗi cung ứng trong năm ngoái

Trong khi chúng ta đang bận rộn kiểm tra các mục trong danh sách SOC 2, thì những kẻ tấn công đang dễ dàng đi vào qua cửa sau thông qua các nhà cung cấp của chúng ta.

Những câu chuyện thực tế: Nghiên cứu điển hình khiến bạn thức trắng đêm

SolarWinds (2020) - Khoảnh khắc "Không tin ai"

Các hacker người Nga đã xâm nhập vào môi trường xây dựng của SolarWinds và phát tán phần mềm độc hại đến 18,000 khách hàng. Các công ty có báo cáo SOC 2 hoàn hảo đã bị tấn công vì họ tin tưởng vào các bản cập nhật phần mềm của nhà cung cấp.

Bài học: Giấy chứng nhận SOC 2 của nhà cung cấp của bạn sẽ không giúp được gì khi quy trình xây dựng của họ bị xâm nhập.

3CX (2023) - Hiệu ứng Domino

Câu chuyện này thật điên rồ. Các kẻ tấn công đã xâm nhập vào phần mềm của Trading Technologies → Nhân viên 3CX tải về → các kẻ tấn công đã chuyển hướng đến máy chủ xây dựng của 3CX → phát tán phần mềm độc hại đến tất cả khách hàng của 3CX.

Nó giống như trò chơi mà một người ngã và kéo theo tất cả mọi người.

Nguồn: Phân tích chi tiết của CrowdStrike

XZ Utils (2024) - Trò chơi kiên nhẫn

Ai đó đã dành hơn 2 năm để xây dựng lòng tin trong cộng đồng mã nguồn mở, trở thành người bảo trì một thư viện nén, sau đó cố gắng cài cắm mã độc vào hàng triệu máy chủ Linux. Cuối cùng chỉ bị phát hiện tình cờ.

Điều đáng sợ: Điều này đã gần như thành công hoàn hảo.

Nguồn: Phân tích của Ars Technica

Ba điểm mù mà kiểm toán SOC 2 của bạn tạo ra

1. An ninh nhà cung cấp chỉ là hình thức

Người kiểm toán SOC 2 của bạn hỏi: "Bạn có đánh giá rủi ro của nhà cung cấp không?"

Bạn cho họ xem tập hồ sơ báo cáo SOC 2 của các nhà cung cấp từ năm ngoái.

✅ Đã kiểm tra. Kiểm toán đã qua.

Thực tế: Những báo cáo đó là các bức tranh tĩnh. Trong khi đó, ReversingLabs đã phát hiện hơn 704,102 gói độc hại trong các kho mã nguồn mở kể từ năm 2019, với mức tăng 1,300% từ 2020-2023.

Các phụ thuộc "đáng tin cậy" của bạn có thể đang bị xâm nhập ngay bây giờ.

2. Khoảng trống SBOM

Câu hỏi nhanh: Bạn có thể liệt kê mọi thành phần bên thứ ba trong các ứng dụng sản xuất của mình không?

Nếu bạn do dự, bạn không đơn độc. Hầu hết các công ty không biết chính xác những gì đang chạy trong hệ thống của họ.

Tại sao điều này quan trọng: Khi Log4j xuất hiện, các công ty có Hóa đơn phần mềm (SBOM) biết được mức độ tiếp xúc của họ trong vòng vài phút. Những công ty khác mất hàng tuần để xác định xem họ có bị ảnh hưởng hay không.

3. Giả định về quy trình xây dựng

Môi trường phát triển của bạn được bảo mật chặt chẽ. Quy trình CI/CD của bạn? Cũng an toàn.

Nhưng còn các gói mà bạn đang tải từ npm, PyPI hoặc Maven Central trong quá trình xây dựng thì sao?

Cả SolarWinds và 3CX đều bị xâm nhập qua quy trình xây dựng của họ, không phải qua máy tính xách tay phát triển.

Những gì thực sự hiệu quả (Từ một người học hỏi)

Tôi xin tiết lộ: Tôi mới tham gia cung cấp dịch vụ đánh giá bảo mật. Bài viết này một phần là tôi học hỏi công khai và một phần là chia sẻ những gì tôi đã phát hiện.

Dưới đây là những gì tôi nghĩ thực sự hữu ích:

Hóa đơn phần mềm (SBOM)

Tạo danh sách tất cả các thành phần phần mềm của bạn. Các tiêu chuẩn như SPDX và CycloneDX giúp điều này có thể đọc được bằng máy.

Tại sao: Biết những gì bạn đang chạy để bạn có thể phản ứng nhanh khi có lỗ hổng xuất hiện.

Quét phụ thuộc

Các công cụ như Snyk, OWASP Dependency-Check, hoặc các tính năng bảo mật của GitHub có thể phát hiện các lỗ hổng đã biết trong các phụ thuộc của bạn.

Tích hợp: Thêm điều này vào quy trình CI/CD của bạn để bạn phát hiện vấn đề trước khi chúng đến sản xuất.

Giám sát nhà cung cấp ngoài SOC 2

Thay vì chỉ thu thập các báo cáo hàng năm, hãy giám sát liên tục tình trạng bảo mật của các nhà cung cấp của bạn.

Thực tế: Hầu hết các công ty biết về các vi phạm của nhà cung cấp từ Twitter, không phải từ hệ thống giám sát của họ.

Thí nghiệm của tôi: Đánh giá bảo mật chuỗi cung ứng

Tôi đang xây dựng một dịch vụ đánh giá bảo mật chuỗi cung ứng. Vì tôi mới trong lĩnh vực này, tôi sẽ bắt đầu với mức giá thực tế:

Những gì tôi cung cấp:

• Phân tích các khoảng trống trong bảo hiểm SOC 2 hiện tại của bạn
• Đánh giá lỗ hổng phụ thuộc phần mềm
• Đánh giá rủi ro nhà cung cấp ngoài các báo cáo tuân thủ
• Các khuyến nghị thực tiễn mà bạn có thể thực hiện

Giá cả: 300-800 USD (Tôi đang thử nghiệm mức giá này)
Thời gian hoàn thành: 3-5 ngày
Sự thành thật: Đây là lần đầu tiên tôi tham gia vào đánh giá bảo mật, vì vậy chúng ta sẽ cùng nhau học hỏi.

Danh sách kiểm tra tự đánh giá

Kiểm tra thực tế nhanh:

• Bạn có thể tạo SBOM cho các ứng dụng chính của mình không?
• Bạn có quét các phụ thuộc để phát hiện lỗ hổng tự động không?
• Bạn có biết trong vòng 24 giờ nếu một nhà cung cấp quan trọng bị vi phạm không?
• Bạn có thể xác minh tính toàn vẹn của các gói bạn tải xuống trong quá trình xây dựng không?

Nếu bạn trả lời "không" cho bất kỳ câu hỏi nào trong số này, việc tuân thủ SOC 2 của bạn không bao phủ các rủi ro thực tế của bạn.

Bước tiếp theo?

Tôi thực sự tò mò về trải nghiệm của bạn. Bạn đã gặp phải các vấn đề về bảo mật chuỗi cung ứng chưa? Những gì đã hiệu quả? Cái gì không?

Hãy để lại suy nghĩ của bạn trong phần bình luận. Hãy cùng nhau tìm ra điều này.

Tài nguyên đã giúp tôi hiểu điều này:

• NIST Cybersecurity Supply Chain Risk Management
• Hướng dẫn SBOM của CISA
• Báo cáo Tình trạng Chuỗi cung ứng phần mềm của Sonatype

Thẻ: #an ninh mạng #bảo mật chuỗi cung ứng #soc2 #devops #học hỏi công khai #bảo mật phần mềm