Rà soát thư viện bên ngoài trong suốt vòng đời cập nhật

Quyết định dùng thư viện tiếp tục có ý nghĩa lâu sau khi cài đặt. Bản cập nhật có thể sửa vấn đề bảo mật, đổi hành vi hoặc buộc ứng dụng thay đổi. Vì vậy, khách hàng nên rà soát vòng đời cập nhật, không chỉ hỏi nhóm có dùng gói uy tín hay không. Người chịu trách nhiệm và độ bao phủ kiểm thử trở nên quan trọng khi cảnh báo tiếp theo xuất hiện.

Biết dịch vụ thực sự chứa những gì

Nên có danh mục nối thành phần triển khai với phiên bản, chức năng nghiệp vụ và nhóm phụ trách. Bao gồm phụ thuộc gián tiếp, tức gói được đưa vào qua gói khác, cùng mã gửi tới trình duyệt. Danh sách trên máy lập trình viên không đủ chứng minh thành phần đang chạy cho khách hàng.

OWASP khuyến nghị phân tích phụ thuộc tự động ngay từ đầu và lưu ý nguồn phát hiện có thể bỏ sót lỗ hổng chưa có mã nhận dạng công khai.[6] Coi quét là công cụ phát hiện, không phải bằng chứng thư viện không có vấn đề bảo mật. Duy trì thông báo nhà cung cấp và thông tin bảo trì trong quy trình rà soát.

Biến phát hiện thành quyết định có chủ sở hữu

Với từng phát hiện, hỏi chức năng đã triển khai nào bị ảnh hưởng, mã liên quan có được đi tới hay không và nhà cung cấp khuyến nghị gì. Ghi người phụ trách và quyết định xử lý. Không để cảnh báo biến mất chỉ vì nhãn mức độ gây bất tiện.

OWASP mô tả việc thử phụ thuộc đã vá trong môi trường kiểm thử và điều chỉnh mã khi cập nhật làm thay đổi lời gọi hàm.[6] Yêu cầu bằng chứng các luồng nghiệp vụ vẫn hoạt động sau thay đổi. Với phụ thuộc gián tiếp, hỏi gói trực tiếp nào cần điều chỉnh thay vì ép phiên bản mà không giải thích.

Ví dụ giả định: tạo tài liệu báo giá

Trong dịch vụ báo giá giả định, thư viện tài liệu có cảnh báo bảo mật. Nhóm nối gói bị ảnh hưởng với bước tạo báo giá và xác định gói cha đưa nó vào. Phiên bản cập nhật làm thay đổi bố cục tài liệu được tạo.

Khách hàng xem báo giá mẫu và kiểm thử tự động phần tổng tiền trước khi duyệt cập nhật. Trong lúc chờ, một người chịu trách nhiệm ghi hạn chế tạm thời và điều kiện rà soát. Ví dụ minh họa quy trình quyết định, không khẳng định biện pháp tạm đã giải quyết lỗ hổng nền.

Bằng chứng về khả năng duy trì phụ thuộc

Yêu cầu bộ bằng chứng nhỏ và hiện hành thay vì báo cáo lớn không giao hành động. Nối bộ bằng chứng với quy trình phát hành.

• Xác định phiên bản triển khai và phụ thuộc gián tiếp quan trọng.
• Chỉ định nhóm tiếp nhận và phân loại cảnh báo nhà cung cấp.
• Kiểm thử luồng bị ảnh hưởng và khả năng quay lui khi đề xuất cập nhật.
• Ghi biện pháp tạm thời kèm chủ sở hữu và điều kiện rà soát.
• Lập phương án thay thế khi thành phần cần thiết không còn được sửa lỗi.

Dành nguồn lực cho cập nhật khó

Nâng cấp ngay không phải lúc nào cũng tương thích với ứng dụng. Trì hoãn để lại rủi ro cần chấp nhận rõ ràng, còn thay thế đòi hỏi công sức kỹ thuật. Thống nhất ai có thẩm quyền chấp nhận đánh đổi và cần bằng chứng nào. Tiêu chí mua hữu ích là năng lực phản ứng được duy trì, không phải lời hứa mọi gói luôn ở phiên bản mới nhất. Ghi trách nhiệm bảo trì trong thỏa thuận dịch vụ trước khi duyệt thành phần.