Bài đăng trên blog này tóm tắt những điểm chính rút ra từ hội thảo trực tuyến của chúng tôi “ Software Supply Chain Bí mật: Những điểm yếu mà kẻ tấn công khai thác”. Xem toàn bộ hội thảo trực tuyến tại đây .
Software Rủi ro trong chuỗi cung ứng đã gia tăng đáng kể khi các tổ chức ngày càng phụ thuộc nhiều hơn vào các thành phần mã nguồn mở, các gói phần mềm bên ngoài và các quy trình phát triển tự động. Những lỗ hổng nhỏ từng được coi là vô hại giờ đây lại mang đến những hậu quả nghiêm trọng, đặc biệt khi sự phụ thuộc ngày càng sâu rộng và khó xác minh hơn.
Một ví dụ rõ ràng về sự thay đổi này là sâu máy tính npm Shai-Hulud và Shai-Hulud 2.0 gần đây, lây lan qua các gói phần mềm bị xâm nhập và ảnh hưởng đến hàng nghìn dự án hạ nguồn chỉ trong vài giờ. Những sự cố như vậy cho thấy rõ một điều: những điểm yếu trong chuỗi cung ứng không còn được kiểm soát nữa; chúng lan rộng khắp toàn bộ hệ sinh thái.
Với 70-90% phần mềm hiện đại được cấu thành từ các thành phần mã nguồn mở, mà hầu hết các nhà phát triển không bao giờ trực tiếp nhìn thấy, các vấn đề nhỏ có thể nhanh chóng trở thành những rủi ro lớn. Tuy nhiên, chỉ có 15% các tổ chức cảm thấy tự tin về cách họ quản lý rủi ro mã nguồn mở đó. Với dự đoán 70% các cuộc tấn công AI độc hại sẽ nhắm vào chuỗi cung ứng vào năm 2025, việc xác định các mắt xích yếu trong chuỗi cung ứng phần mềm hiện nay là vô cùng cần thiết.
Đối với các đội ngũ kỹ thuật và an ninh, lợi ích rất đơn giản: việc biết được những điểm yếu này đồng nghĩa với việc ít gặp phải những bất ngờ hơn, thời gian phản hồi nhanh hơn và giảm đáng kể nguy cơ trở thành tâm điểm của các vụ bê bối trong chuỗi cung ứng.
SBOM không còn là tùy chọn nữa.
Để quản lý rủi ro chuỗi cung ứng phần mềm và ứng phó với các lỗ hổng bảo mật, các tổ chức cần có cái nhìn rõ ràng về những gì có trong hệ thống phần mềm của họ. Nền tảng của sự minh bạch này là SBOM (danh sách thành phần phần mềm) , tạo ra sự rõ ràng cần thiết để hiểu rủi ro của các thành phần và hành động nhanh chóng khi vấn đề phát sinh.
SBOM được định nghĩa là một bản kê chi tiết tất cả các thành phần, giấy phép và phụ thuộc (cả mã nguồn đóng và mã nguồn mở) được sử dụng trong một ứng dụng. Bản kê này cung cấp dữ liệu thiết yếu cho tính minh bạch, tuân thủ và quản lý rủi ro.
Những gì không bị coi là dễ bị tổn thương hoặc độc hại hôm nay rất dễ trở nên như vậy vào ngày mai. Vì các lỗ hổng bảo mật liên tục được phát hiện, kể cả trong các phiên bản cũ hơn, nên việc giám sát và kiểm kê thường xuyên là điều cần thiết.
George PrichiciPhó chủ tịch, Sản phẩm, OPSWAT
SBOM so với SCA
Một điều quan trọng cần lưu ý là sự khác biệt giữa SBOM và SCA ( Software (Phân tích thành phần). SBOM là danh mục, hay danh sách các thành phần. SCA đánh giá xem bất kỳ thành phần nào trong số đó có dễ bị tổn thương, lỗi thời hoặc tiềm ẩn rủi ro hay không. Cả hai cùng nhau cung cấp cho các tổ chức cái nhìn sâu sắc cần thiết để đưa ra quyết định sáng suốt, phản ứng nhanh hơn với các vấn đề bảo mật và tăng cường quản lý rủi ro tổng thể.
| Loại | SBOM | SCA |
|---|---|---|
Mục đích | Danh mục linh kiện |
Xác định các lỗ hổng trong các thành phần
|
Bảo hiểm rủi ro | Tuân thủ và khả năng hiển thị | Rủi ro bảo mật, lỗ hổng CVE, rủi ro trong quá trình thực thi |
Thời gian | Chuẩn bị trước khi triển khai / mua sắm | Liên tục / xây dựng & thời gian chạy |
Các phong trào toàn cầu, một phần do các cuộc tấn công như SolarWinds gây ra, hiện nay yêu cầu SBOM (Stack Objective Manager), với các áp lực pháp lý đến từ các tổ chức như CISA, NSA và NIST, cũng như EU và các quốc gia đồng minh NATO, khiến tính minh bạch của SBOM không còn là tùy chọn mà là một kỳ vọng cơ bản đối với bất kỳ nhà cung cấp phần mềm nào.
7 điểm yếu chí mạng mà kẻ tấn công khai thác
Tốc độ phát triển hiện đại, cùng với sự phụ thuộc lớn vào mã nguồn mở và mã nguồn của bên thứ ba, đã tạo ra những lỗ hổng bảo mật nghiêm trọng. Các tác nhân đe dọa đang khai thác bảy điểm yếu chính:
1. Rủi ro về mã nguồn mở và sự phụ thuộc
Khi các nhà phát triển ưu tiên tốc độ, họ thường sử dụng các thư viện mã nguồn mở lớn mà không thực hiện đánh giá mã đầy đủ. Một thành phần duy nhất có thể tạo ra thêm các phụ thuộc bắc cầu. Nếu bạn chỉ giám sát cấp độ cao nhất, bạn có thể bỏ sót mã độc hại được chèn vào các phụ thuộc bắc cầu ẩn đó.
Đây là mô hình mà chúng ta vẫn thường thấy trong các hệ sinh thái mã nguồn mở. Một gói phần mềm bị xâm nhập có thể lan truyền qua các chuỗi phụ thuộc và đạt đến hàng triệu lượt tải xuống trước khi bất kỳ ai nhận ra. Một vụ tấn công chuỗi cung ứng npm gần đây liên quan đến phần mềm độc hại mã hóa đã minh họa chính xác cách thức điều này xảy ra trong thực tế.
Thực hành tốt nhất:
- Quét tất cả các gói mã nguồn mở và toàn bộ chuỗi phụ thuộc của chúng để xác định các lỗ hổng, các thành phần lỗi thời hoặc phần mềm độc hại ẩn trước khi chúng xâm nhập vào mã nguồn của bạn.
- Hãy liên tục giám sát các thành phần phụ thuộc theo thời gian, vì các thành phần an toàn có thể trở nên rủi ro khi xuất hiện các lỗ hổng bảo mật mới hoặc các bản cập nhật độc hại.
- Hãy sử dụng các kho lưu trữ đáng tin cậy và xác minh tính toàn vẹn của gói phần mềm để đảm bảo các gói bạn tải xuống không bị giả mạo.
- Áp dụng các chính sách gắn cờ hoặc chặn các giấy phép rủi ro để các điều khoản giấy phép không tương thích hoặc lây lan không xâm nhập vào bản dựng của bạn.
- Hãy trì hoãn việc sử dụng các gói phần mềm mới được phát hành cho đến khi chúng được kiểm duyệt, nhằm giảm nguy cơ đưa các bản phát hành chưa được xem xét hoặc độc hại vào môi trường của bạn.
2. Rủi ro cấp phép
Các vấn đề về cấp phép hiện nay ảnh hưởng đến kỹ thuật cũng nhiều như pháp lý. Các giấy phép phổ biến, chẳng hạn như GPL, có thể buộc ứng dụng của bạn phải được xuất bản theo cùng một giấy phép, có khả năng khiến công ty bạn mất đi quyền sở hữu trí tuệ (IP) của chính mình. Việc giám sát liên tục là cần thiết vì các điều khoản giấy phép có thể thay đổi, ngay cả đối với các phiên bản cũ hơn, trước đây đã tuân thủ quy định.
Thực hành tốt nhất:
- Sử dụng công cụ phát hiện giấy phép tự động để xác định sớm các giấy phép có rủi ro cao hoặc không tương thích trong quá trình phát triển. Lý do tại sao điều này lại quan trọng được giải thích chi tiết hơn tại đây: Vai trò then chốt của việc phát hiện giấy phép trong bảo mật mã nguồn mở .
- Theo dõi liên tục các thay đổi về giấy phép để nắm bắt những thay đổi có thể ảnh hưởng đến việc tuân thủ quy định hoặc rủi ro về sở hữu trí tuệ.
- Chặn hoặc xem xét các thành phần có giấy phép hạn chế hoặc chứa virus trước khi chúng được đưa vào mã nguồn.
- Duy trì danh sách rõ ràng tất cả các giấy phép đang sử dụng để đơn giản hóa việc kiểm toán và đánh giá rủi ro.
3. Khoảng trống dữ liệu SBOM hoặc dữ liệu SBOM bị thiếu
Mặc dù các quy định yêu cầu chia sẻ SBOM (Stack Object Materials), nhưng một danh sách cấp cao là không đủ. Cần có các dữ liệu chi tiết, bao gồm tác giả, người đóng góp, tần suất phát hành và trạng thái bảo trì, để giảm thiểu và ngăn ngừa hiệu quả.
Thực hành tốt nhất:
- Nâng cao chất lượng báo cáo SBOM bằng cách quét lại các thành phần để bổ sung dữ liệu giấy phép cập nhật, trạng thái lỗ hổng và các siêu dữ liệu quan trọng khác. Ví dụ chi tiết về cách thực hiện việc này được trình bày ở đây trong phần Xác thực và làm giàu báo cáo SBOM của CycloneDX .
- Xác thực và làm phong phú thêm SBOM bằng các công cụ tự động để đảm bảo thông tin đầy đủ, chính xác và có thể sử dụng được.
- Yêu cầu các nhà cung cấp cung cấp đầy đủ thông tin chi tiết về cấu hình phần mềm (SBOM), bao gồm cả các phụ thuộc bắc cầu và tất cả siêu dữ liệu liên quan.
- Liên tục cập nhật và giám sát danh mục SBOM khi các thành phần thay đổi hoặc các lỗ hổng bảo mật mới xuất hiện.
4. Các nhà cung cấp bên thứ ba
Mỗi nhà cung cấp mà bạn dựa vào đều trở thành một phần của chuỗi cung ứng của bạn. Nếu họ cung cấp các linh kiện lỗi thời hoặc bị lỗi, bạn sẽ phải gánh chịu rủi ro đó. Việc lập danh mục vật liệu dựa trên phần mềm (SBOM) hoàn chỉnh, bao gồm cả các phụ thuộc bắc cầu, giúp bạn nhanh chóng hiểu được mức độ rủi ro thay vì phải liên hệ với nhà cung cấp trong khi sự cố xảy ra. Một bài đăng gần đây về Quản lý các lỗ hổng phụ thuộc trong Supply Chain Software của bạn đã khám phá cách các nhóm có thể tăng cường phần này của quy trình.
5. Trí tuệ nhân tạo Supply Chain
Do việc ứng dụng AI diễn ra nhanh chóng, các nhóm thường bỏ qua các hạn chế thông thường, tạo ra một lỗ hổng bảo mật lớn. Kẻ tấn công chèn mã độc vào các mô hình học máy, tệp PICO hoặc thư viện mã nguồn mở. Tấn công chiếm đoạt tên miền do lỗi chính tả (typosquatting) rất phổ biến trong các môi trường như PyTorch, nơi người dùng có thể tải nhầm thư viện, dẫn đến việc phát tán phần mềm độc hại và thực thi mã từ xa trên máy tính của kỹ sư.
6. Container Rủi ro
Việc quét container cần phải phát triển vượt ra ngoài việc chỉ tập trung vào các lỗ hổng bảo mật. Bảo mật hiện đại cũng cần phải quét các phần mềm độc hại, phần mềm khai thác tiền điện tử và các mối đe dọa tác động nhanh được công bố trong các ảnh container có sẵn công khai. Một phân tích gần đây về lỗ hổng CVE-2024-0132 của NVIDIA Container Toolkit cho thấy những vấn đề này dễ bị bỏ qua như thế nào.
7. Rò rỉ bí mật và thông tin đăng nhập
Khi các nhóm làm việc nhanh chóng, họ thường mã hóa cứng các khóa truy cập hoặc thông tin đăng nhập trong mã nguồn để thử nghiệm. Ngay cả khi sau đó bị ghi đè, những bí mật này thường vẫn còn trong lịch sử Git, nơi mà kẻ tấn công dễ dàng tìm thấy thông qua việc quét mã. Cuốn sách "Giải mã các mối đe dọa tiềm ẩn: Cách phát hiện bí mật trong mã nguồn" cho thấy những lỗ hổng này xảy ra như thế nào và các nhóm có thể làm gì để ngăn chặn chúng.
Con đường dẫn đến Secure Software Supply Chain
Để đối phó với những mối đe dọa này, bộ phận an ninh cần áp dụng tư duy "chuyển dịch sang trái", nghĩa là các chính sách được thực thi trước khi phát hành sản phẩm cũng cần được áp dụng sớm hơn trong chu kỳ phát triển. Mục tiêu là tích hợp an ninh như một lớp phủ lên trên quy trình CI/CD hiện có. Cách tiếp cận tự động này đảm bảo việc thực thi khi cần thiết, mà không ảnh hưởng đến năng suất của đội ngũ kỹ sư.
Một giải pháp toàn diện phải cung cấp:
- Quét tự động chuỗi cung ứng trên toàn bộ đường ống dẫn.
- Khả năng xem mã nguồn, vùng chứa và các tệp do nhà cung cấp cung cấp.
- Phân tích vượt xa phạm vi CVE để phát hiện phần mềm độc hại, các vấn đề về giấy phép và các bí mật bị lộ.
Làm sao OPSWAT Giúp thu hẹp những khoảng cách này
- Multiscanning để phát hiện phần mềm độc hại sớm trong quy trình.
- Các cổng bảo mật CI/CD tích hợp cho GitHub, GitLab, TeamCity, Jenkins và nhiều nền tảng khác.
- Tự động tạo SBOM và lập bản đồ lỗ hổng bảo mật
- Ký kết hiện vật và xác thực tính toàn vẹn
- Quét bí mật và thực thi tính toàn vẹn thông tin xác thực
Hãy liên hệ với một trong những chuyên gia của chúng tôi để tìm ra giải pháp phù hợp nhất cho hệ thống của bạn ngay hôm nay.
