Endor Labs, một công ty phần mềm hỗ trợ bảo mật và bảo trì phần mềm nguồn mở, đã phát hành một báo cáo xác định 10 rủi ro vận hành và bảo mật hàng đầu trong phần mềm nguồn mở vào năm 2023.
Được thực hiện bởi nhóm Trạm 9 của Endor Labs, báo cáo có sự đóng góp của hơn 20 giám đốc an ninh thông tin trong ngành từ các công ty nổi tiếng bao gồm Adobe, HashiCorp, Discord và Palo Alto Networks.
Theo Endor Labs, việc phụ thuộc quá nhiều vào phần mềm nguồn mở đã ghi lại một số lỗ hổng đã biết, được coi là Lỗ hổng phổ biến và Phơi nhiễm; những lỗ hổng này thường bị bỏ qua và có thể bị kẻ tấn công khai thác nếu không được khắc phục.
Henrik Plate, nhà nghiên cứu bảo mật hàng đầu tại Endor Labs cho biết: “Phần mềm nguồn mở đại diện cho một mỏ vàng cho các nhà phát triển ứng dụng, nhưng nó cần các khả năng bảo mật hiệu quả như nhau. “Trong một môi trường mà hơn 80% mã trong các ứng dụng mới có thể đến từ các kho lưu trữ hiện có, rõ ràng là có những rủi ro nghiêm trọng liên quan.”
Rủi ro nguồn mở hàng đầu năm 2023
Nổi bật bên dưới là những điểm chính trong báo cáo của Endor Labs về 10 rủi ro nguồn mở hàng đầu năm 2023.
1. Các lỗ hổng đã biết
Báo cáo tiết lộ rằng một phiên bản thành phần nguồn mở có thể chứa mã dễ bị tổn thương do các nhà phát triển của nó vô tình đưa vào. Lỗ hổng bảo mật có thể bị khai thác trong phần mềm hạ nguồn, có khả năng ảnh hưởng đến tính bảo mật, tính toàn vẹn hoặc tính khả dụng của hệ thống và dữ liệu của nó.
2. Thỏa hiệp gói hợp pháp
Theo báo cáo của Endor, những kẻ tấn công có thể nhắm mục tiêu các tài nguyên hợp pháp từ một dự án hoặc cơ sở hạ tầng phân phối hiện có để tiêm mã độc vào một thành phần. Ví dụ: họ có thể chiếm đoạt tài khoản của những người bảo trì dự án hợp pháp hoặc khai thác các lỗ hổng trong kho lưu trữ gói. Kiểu tấn công này có thể nguy hiểm vì mã độc có thể được phân phối như một phần của gói hợp pháp và có thể khó phát hiện.
3. Tấn công nhầm lẫn tên
Kẻ tấn công có thể tạo các thành phần có tên giống với tên của các thành phần hệ thống hoặc mã nguồn mở hợp pháp. Báo cáo của Endor Labs tiết lộ rằng điều này có thể được thực hiện thông qua:
- Typo-ngồi xổm: Kẻ tấn công tạo một tên viết sai chính tả tên của thành phần ban đầu.
- Đánh cắp thương hiệu: Kẻ tấn công gợi ý một tác giả đáng tin cậy.
- Combo ngồi xổm: Kẻ tấn công chơi với các mẫu đặt tên phổ biến trong các ngôn ngữ hoặc hệ sinh thái khác nhau.
Những cuộc tấn công này có thể được sử dụng để lừa người dùng tải xuống và sử dụng các thành phần độc hại mà họ cho là hợp pháp.
4. Phần mềm không rõ nguồn gốc
Theo báo cáo của Endor Labs, phần mềm không rõ nguồn gốc là một vấn đề hoạt động. Một thành phần hoặc phiên bản của một thành phần có thể không còn được phát triển tích cực, điều đó có nghĩa là các bản vá cho các lỗi chức năng và lỗi không hoạt động có thể không được cung cấp kịp thời hoặc hoàn toàn không bởi dự án nguồn mở ban đầu. Điều này có thể khiến phần mềm dễ bị khai thác bởi những kẻ tấn công nhắm vào các lỗ hổng đã biết.
5. Phần mềm lỗi thời
Để thuận tiện, một số nhà phát triển sử dụng phiên bản lỗi thời của cơ sở mã khi có phiên bản cập nhật. Điều này có thể dẫn đến việc dự án bỏ lỡ các bản sửa lỗi và bản vá bảo mật quan trọng, khiến dự án dễ bị khai thác.
6. Phụ thuộc không được theo dõi
Các nhà phát triển dự án có thể không nhận thức được sự phụ thuộc vào một thành phần vì một số lý do:
- Nó không phải là một phần của hóa đơn nguyên liệu phần mềm của thành phần ngược dòng.
- Các công cụ phân tích thành phần phần mềm không chạy hoặc không phát hiện ra nó.
- Phần phụ thuộc không được thiết lập bằng trình quản lý gói, điều này có thể dẫn đến các sự cố bảo mật vì các lỗ hổng trong phần phụ thuộc không được theo dõi có thể không được chú ý.
7. Giấy phép và rủi ro quy định
Một thành phần hoặc dự án có thể không có giấy phép hoặc có thể có giấy phép không tương thích với mục đích sử dụng hoặc không hoặc không thể đáp ứng các yêu cầu của chúng.
Sử dụng các thành phần phù hợp với các điều khoản cấp phép của họ là rất quan trọng. Không làm như vậy, chẳng hạn như sử dụng một thành phần không có giấy phép hoặc không tuân thủ các điều khoản của nó, có thể dẫn đến vi phạm bản quyền hoặc giấy phép. Trong những trường hợp như vậy, người giữ bản quyền có quyền thực hiện hành động pháp lý.
Ngoài ra, việc vi phạm các yêu cầu pháp lý và quy định có thể hạn chế hoặc cản trở khả năng giải quyết các ngành hoặc thị trường nhất định.
8. Phần mềm chưa trưởng thành
Một dự án nguồn mở có thể không tuân theo các phương pháp hay nhất về phát triển, chẳng hạn như sử dụng lược đồ tạo phiên bản tiêu chuẩn, có bộ kiểm tra hồi quy hoặc có hướng dẫn hoặc tài liệu đánh giá. Điều này có thể dẫn đến một thành phần nguồn mở không hoạt động đáng tin cậy hoặc an toàn, khiến nó dễ bị khai thác.
Dựa vào một thành phần hoặc dự án chưa trưởng thành có thể gây ra rủi ro hoạt động đáng kể. Chẳng hạn, phần mềm phụ thuộc vào nó có thể không hoạt động như dự định, dẫn đến các vấn đề về độ tin cậy của thời gian chạy.
9. Thay đổi không được chấp thuận (có thể thay đổi)
Khi sử dụng các thành phần không được đảm bảo giống hệt nhau khi được tải xuống vào các thời điểm khác nhau, sẽ có rủi ro bảo mật đáng kể. Điều này được thể hiện qua các cuộc tấn công như Codecov Bash Uploader, trong đó các tập lệnh đã tải xuống được dẫn trực tiếp tới bash mà không cần xác minh tính toàn vẹn của chúng trước đó. Việc sử dụng các thành phần có thể thay đổi cũng đặt ra mối đe dọa đối với tính ổn định và khả năng tái sản xuất của các bản dựng phần mềm.
10. Phụ thuộc thiếu/quá cỡ
Báo cáo của Endor đã chỉ ra rằng việc phụ thuộc quá mức/dưới mức vào các thành phần có thể là một rủi ro hoạt động. Chẳng hạn, các thành phần nhỏ, chẳng hạn như những thành phần chỉ chứa một vài dòng mã, dễ gặp rủi ro tương tự như các thành phần lớn hơn. Những rủi ro này bao gồm chiếm đoạt tài khoản, yêu cầu kéo độc hại và các lỗ hổng trong quy trình tích hợp liên tục và phát triển liên tục.
Mặt khác, các thành phần lớn có thể đã tích lũy nhiều tính năng không cần thiết cho các trường hợp sử dụng tiêu chuẩn. Các tính năng này làm tăng bề mặt tấn công của thành phần và có thể giới thiệu các phụ thuộc không được sử dụng, dẫn đến các phụ thuộc cồng kềnh.
Các bước cần thực hiện để giảm thiểu những rủi ro nguồn mở này
Dưới đây là các mẹo từ Endor Labs về cách các nhà phát triển phần mềm và người quản lý CNTT có thể giảm thiểu những rủi ro nguồn mở này.
Thường xuyên quét mã để phát hiện các gói bị xâm phạm
Ngăn chặn các gói bị xâm phạm là một vấn đề phức tạp vì không có giải pháp chung cho tất cả. Để giải quyết vấn đề này, các tổ chức có thể tham khảo các tiêu chuẩn và khung mới nổi như Khung tiêu thụ chuỗi cung ứng an toàn OpenSSF (S2C2F).
Họ có thể chọn và ưu tiên các biện pháp bảo vệ phù hợp nhất với yêu cầu của mình dựa trên nhu cầu bảo mật cụ thể và khả năng chịu rủi ro của họ.
Kiểm tra xem một dự án có tuân theo các phương pháp hay nhất về phát triển hay không
Để đánh giá chất lượng và tiền tệ của dự án, hãy kiểm tra tài liệu của dự án và phát hành ghi chú về tính đầy đủ và kịp thời. Tìm kiếm các huy hiệu cho biết phạm vi kiểm tra hoặc sự hiện diện của các quy trình CI/CD có thể phát hiện hồi quy.
Ngoài ra, bạn có thể đánh giá một dự án bằng cách kiểm tra số lượng người bảo trì và cộng tác viên đang hoạt động, tần suất phát hành bản phát hành mới cũng như số lượng vấn đề và yêu cầu kéo được mở và đóng. Việc tra cứu thông tin về chiến lược hỗ trợ hoặc bảo trì của dự án cũng rất quan trọng — ví dụ: sự hiện diện và ngày tháng của các phiên bản hỗ trợ dài hạn.
Luôn cập nhật các phần phụ thuộc và kiểm tra các đặc điểm của mã trước khi sử dụng chúng
Để đảm bảo an toàn cho mã, việc kiểm tra cả mã và các đặc điểm của dự án là rất quan trọng. Ví dụ về các đặc điểm mã cần kiểm tra bao gồm các móc nối trước và sau khi cài đặt cũng như tải trọng được mã hóa. Đối với các đặc điểm của dự án, hãy xem xét kho lưu trữ mã nguồn, tài khoản của người bảo trì, tần suất phát hành và số lượng người dùng xuôi dòng.
Một cách để luôn cập nhật các phần phụ thuộc là sử dụng các công cụ tạo yêu cầu hợp nhất hoặc kéo với các đề xuất cập nhật. Điều quan trọng nữa là ưu tiên các bản cập nhật phụ thuộc và các mục tồn đọng định kỳ.
Đánh giá và so sánh các công cụ phân tích thành phần phần mềm
Các nhóm bảo mật phải đảm bảo các công cụ SCA có khả năng tạo ra các hóa đơn vật liệu chính xác, cả ở cấp độ chi tiết thô, chẳng hạn như đối với các phụ thuộc được khai báo với sự trợ giúp của các công cụ quản lý gói như Maven hoặc npm và cấp độ chi tiết, chẳng hạn như đối với các tạo phẩm giống như các tệp đơn lẻ được bao gồm “ngoài dải” mà không cần sử dụng trình quản lý gói.
Sử dụng các thành phần tuân thủ các điều khoản cấp phép nguồn mở
Các nhà lãnh đạo CNTT nên đảm bảo các nhà phát triển phần mềm của họ tránh sử dụng các thành phần nguồn mở mà không có giấy phép, vì điều này có thể tạo ra rủi ro pháp lý. Để đảm bảo tuân thủ và tránh các vấn đề pháp lý tiềm ẩn, điều quan trọng là phải xác định các giấy phép có thể chấp nhận được cho các thành phần được sử dụng trong quá trình phát triển phần mềm.
Các yếu tố cần xem xét bao gồm cách thành phần được liên kết, mô hình triển khai và sơ đồ phân phối dự kiến. Khi bạn đã xác định được các giấy phép có thể chấp nhận được, hãy tuân thủ các yêu cầu được nêu trong các giấy phép nguồn mở đó.
Đọc tiếp: Các mối đe dọa an ninh mạng hàng đầu năm 2023 (TechRepublic)
