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.

Hãy thiết lập mức độ chấp nhận rủi ro của bạn trên từng ứng dụng và xem xét mức độ nghiêm trọng của rủi ro cùng với chi phí khắc phục. Đồng thời, hãy lập ngân sách cho các khoản nợ kỹ thuật và chia ứng dụng của bạn thành các cấp dựa trên mức độ quan trọng của chúng để đảm bảo ngân sách được phân bổ hiệu quả.

Hiểu về khả năng chịu đựng và chấp nhận rủi ro

Điều quan trọng là phải thừa nhận rằng các ứng dụng của bạn sẽ không bao giờ ở trạng thái hoàn toàn không có rủi ro thành phần. Trên thực tế, nếu bạn muốn một ứng dụng không có rủi ro về thành phần, bạn cần tạo một ứng dụng không có bất kỳ thành phần nào, nhưng chắc hẳn là ngân sách phát triển đó khó mà khả thi đối với tổ chức của bạn. Đó là lý do ta cần thiết lập mức độ chấp nhận rủi ro.

Thay vào đó, bạn cần quyết định mức độ rủi ro mà bạn sẵn sàng chấp nhận – nghĩa là những rủi ro bạn sẽ không cố gắng loại bỏ, giảm thiểu hoặc khắc phục. Đây chính là khả năng chấp nhận rủi ro của bạn. Một số rủi ro đủ nhỏ để bạn có thể bỏ qua một cách an toàn. Một số rủi ro nghiêm trọng hơn, nhưng việc đầu tư ngân sách phát triển cho chúng có thể không hợp lý. Cũng có những rủi ro rất nghiêm trọng, nhưng đơn giản là không thể nào giải quyết được.

Sau đó, bạn cần ưu tiên giải quyết những rủi ro còn lại. Một số vấn đề sẽ cần được khắc phục ngay lập tức, trong khi những vấn đề khác có thể đợi được đến sprint tiếp theo, bản phát hành tiếp theo hoặc thậm chí là giai đoạn đầu tư tiếp theo.

Thiết lập mức độ chấp nhận rủi ro trên cơ sở ứng dụng

Đối với một ứng dụng cụ thể, có một số yếu tố bạn cần xem xét khi ước tính mức độ rủi ro chấp nhận được, chẳng hạn như:

– Mức độ đe doạ tương đối của rủi ro đối với tổ chức?

– Có thể nâng cấp thành phần này lên phiên bản ít rủi ro hơn không?

– Việc nâng cấp thành phần có đòi hỏi quá trình làm lại để khắc phục các thay đổi phạm vi hay không?

– Lỗ hổng có thể bị khai thác trong ứng dụng hay không? Có thể giảm thiểu khả năng bị khai thác hay không?

– Có thể sử dụng một thành phần mã nguồn mở khác thay thế không?

Lập ngân sách cho nợ kỹ thuật

Việc tuân thủ bất kỳ chính sách quản trị phần mềm nguồn mở và miễn phí (free and open source software – FOSS) nào đều sẽ làm chậm quá trình đổi mới, như một yếu tố của nợ kỹ thuật. Điều này tương đương với số giờ phát triển thực sự trong việc nâng cấp thành phần phụ thuộc, CI testing, khắc phục sự cố, và thật không may – có thể dẫn đến quá trình làm lại. Một dự án thường sẽ phân bổ từ 10 đến 30% ngân sách để quản lý nợ kỹ thuật. Việc xác định mức độ rủi ro có thể chấp nhận được của ứng dụng sẽ giúp ưu tiên công việc khắc phục tương ứng với những ràng buộc về ngân sách.

Để xử lý nợ kỹ thuật một cách hiệu quả, hãy nhóm các ứng dụng theo cấp độ, tuỳ thuộc vào mức độ quan trọng của chúng đối với tính liên tục và tác động của doanh nghiệp, sau đó chỉ định ngân sách nợ kỹ thuật tương ứng. Các câu hỏi sau đây có thể giúp bạn xác định cấp độ rủi ro của ứng dụng:

– Ứng dụng có mang lại lợi thế cạnh tranh quan trọng cho tổ chức không?

– Ứng dụng có xử lý các khoản thanh toán, đơn đặt hàng hoặc thông tin cá nhân không?

– Chi phí của ứng dụng làm rò rỉ dữ liệu người dùng là bao nhiêu?

– Ứng dụng đáp ứng nhu cầu nội bộ hay nhu cầu bên ngoài?

– Ứng dụng đang trong giai đoạn phát triển tích cực hay chỉ là mã nguồn kế thừa?

– Ứng dụng có phải tuân thủ bất kỳ yêu cầu bên ngoài nào không?

– Có vấn đề nào mang lại rủi ro cho các ứng dụng khác hay không?

Đừng giải quyết vấn đề lỗi thời bằng cách cập nhật tự động

Một số dự án tránh vấn đề lỗi thời bằng các tự động nâng cấp các thành phần phụ thuộc khi chúng có phiên bản mới. Điều này thường được thực hiện bằng cách bao gồm một version range trong tập tin manifest mà không có giới hạn trên hay một phiên bản được chỉ định thành phiên bản chính tiếp theo. Thực tiễn này đưa ra một loạt vấn đề khác còn rủi ro hơn cả vấn đề lỗi thời. Nhìn chung, lời khuyên của Sonatype là bạn nên định nghĩa các phiên bản phụ thuộc và/hoặc sử dụng các tập tin lock ẩn để sử dụng các phiên bản đã được kiểm tra từ đầu. Rủi ro trong việc tự động cập nhật phiên bản bao gồm:

– Các cộng đồng đáng tin cậy bị những người đóng góp với ý đồ xấu khai thác một cách nghiêm trọng.

– Các cuộc tấn công Dependency confusion nhằm vào các namespaces không được đặt trước là tình trạng đang rất phổ biến.

– Các bản phát hành mới có thể vô tình gây ra những thay đổi đáng kể.

– Nhiều công cụ SCA có sẵn thực hiện namespace-matching mà không xác minh các tập tin nhị phân được sử dụng.

Theo Sonatype