Việc tạo đường cơ sở sẽ hỗ trợ bạn nhiều hơn bạn có thể mong đợi. Có thể bạn đang đọc hướng dẫn này để tìm hiểu cách loại bỏ một số – thậm chí là tất cả – rủi ro liên quan đến thành phần nguồn mở khỏi sản phẩm của mình. Tuy nhiên phần mềm của bạn, ngay cả phần mềm bạn tự phát triển hoàn toàn, sẽ luôn có một số rủi ro. Bạn có thể khó tìm hiểu về vấn đề từ thành phần nguồn mở như lỗ hổng bảo mật, hạn chế giấy phép và các vấn đề về chất lượng, đặc biệt là trong các trường hợp vi phạm nghiêm trọng như SolarWinds và Equifax. Hơn nữa, lợi ích của phần mềm nguồn mở sẽ vượt xa rủi ro của nó khi bạn quản lý phần mềm một cách chính xác và hợp lý. 

Các gói mã nguồn mở giúp các nhà phát triển tiết kiệm thời gian một cách đáng kể bằng cách cho phép họ tập trung vào việc giải quyết các thách thức độc nhất về ứng dụng và cung cấp miễn phí các giải pháp toàn diện, đã được kiểm tra kỹ càng để giải quyết các vấn đề phức tạp. 

Bài đăng này là một phần trong series chia sẻ Những thực hành hay nhất trong việc quản lý thành phần nguồn mở của Sonatype.

Tạo đường cơ sở và tìm ra khả năng chịu đựng rủi ro

Vì rủi ro là điều không thể tránh khỏi, nên giải pháp thiết thực nhất không phải là cố gắng loại bỏ rủi ro mà là quản lý nó. Để làm được điều đó, bạn cần tạo đường cơ sở về những rủi ro đã tồn tại. Khi biết được tiêu chuẩn đó, bạn có thể định ra một bộ quy tắc xác định rủi ro nào có thể chấp nhận được và rủi ro nào thì không. Đây chính là khả năng chấp nhận rủi ro của tổ chức bạn.

Một mô hình phổ biến khi các nhóm áp dụng công cụ quét (scanning) là quét một ứng dụng, sau đó cố gắng loại bỏ tất cả các lỗ hổng mà công cụ Phân tích Thành phần Phần mềm (Software Composition Analysis – SCA) tìm thấy.

Dưới đây là cách tiếp cận để  tạo đường cơ sở rủi ro của bạn.

Xác định các thành phần trong ứng dụng của bạn

Cách tốt nhất để thực hiện việc này là lập một hoá đơn nguyên vật liệu phần mềm (Software Bill of Materials – SBOM). Hoá đơn này liệt kê mọi thành phần trong ứng dụng của bạn và mối quan hệ của chúng với các thành phần khác ở định dạng chuẩn mà cả người và máy đều có thể đọc được. Có hai tiêu chuẩn cho SBOM là CyclconeDX và SDPX. Sonatype đề xuất sử dụng CyclconeDX, vì nó được phát triển chuyên biệt để theo dõi các lỗ hổng bảo mật.

SBOM là bước đầu tiên trong việc quản lý rủi ro từ các gói nguồn mở, vì nó cung cấp cho bạn cách xác định các ứng dụng bạn đang thực sự sử dụng, bao gồm các gói được đưa vào từ các thành phần phụ thuộc của bạn. Hoá đơn này có thể được sử dụng kết hợp với các công cụ phân tích thành phần phần mềm để tạo ra bản báo cáo về các thông tin dễ bị tấn công của bạn. Bạn có thể chia sẻ báo cáo này với khách hàng để nhận đánh giá từ họ, cũng như sử dụng nó để giám sát ứng dụng nhằm biết được các thành phần phụ thuộc mới.

Xác định rủi ro từ các thành phần hiện có

Khi bạn hiểu rõ những gì bạn đang sử dụng, bước tiếp theo sẽ là xác định những rủi ro hiện tại của bạn. Cách tốt nhất để làm việc này là sử dụng một công cụ phân tích thành phần phần mềm. Các công cụ này có thể tự động xác định thành phần nào bạn đang sử dụng, sau đó kiểm tra cơ sở dữ liệu lỗ hổng hiện có để cung cấp cho bạn thông tin chi tiết về các rủi ro tiềm ẩn từ các thành phần phụ thuộc của bạn. Các công cụ tốt nhất sẽ kiểm tra các thành phần tạo tác của dự án, dựa trên các nguồn thông tin công khai và độc quyền để xác định các rủi ro tiềm ẩn thay vì kiểm tra tập tin manifest của ứng dụng hoặc SBOM dựa trên dữ liệu công khai sẵn có. Một số công cụ phổ biến bao gồm Nexus Lifecycle, OSS Index và OWASP Dependency Check.

Quyết định những vấn đề cần khắc phục

Quyết định những gì cần khắc phục khi bạn bắt đầu quản lý rủi ro nguồn mở của mình là một công việc khó khăn. Sẽ rất hiếm khi bạn muốn quay lại và loại bỏ tất cả rủi ro hiện có của mình, đặc biệt là trong các ứng dụng cũ và có cơ sở mã lớn. Quá trình khắc phục sẽ làm mất thời gian phát triển ứng dụng của bạn. Hơn nữa, việc thực hiện lại công việc hiện tại có thể khiến các nhóm phát triển nản lòng và làm phân tán sự chú ý về quy trình chủ động quản lý rủi ro trong tương lai.

Một cách tiếp cận phổ biến là chấp nhận tất cả, trừ những rủi ro nghiêm trọng nhất. Bất kỳ lỗ hổng nghiêm trọng nào, chẳng hạn như easy-to-exploit (dễ khai thác), remote code execution (thực thi mã từ xa) đều phải được giải quyết, vì những lỗ hổng này là mối nguy lớn đối với tổ chức và có thể là cả người dùng của bạn.

Tiến về phía trước nhờ việc tạo đường cơ sở

Mục tiêu trong việc quản lý rủi ro nguồn mở là đổi mới nhanh nhất có thể mà không gặp rủi ro không cần thiết. Thông thường, các ứng dụng hiện tại của bạn sẽ không hoàn toàn đáp ứng các chính sách quản trị nguồn mở mà tổ chức của bạn đã áp dụng. Đây là một sự thoả hiệp, nhưng nó cho phép tổ chức của bạn tập trung vào rủi ro mới xuất hiện và đang tạo ảnh hưởng, hơn là loại bỏ rủi ro hiện tại có thể đồng thời tạo ra nhiều rủi ro hơn. Cách tiếp cận chủ động này sẽ đảm bảo rằng các dự án trong tương lai của bạn gặp ít rủi ro hơn. 

Theo Sonatype