By ITCuli

Securing open source software dependencies in the public cloud

Securing open source software dependencies in the public cloud

Bảo mật phụ thuộc phần mềm mã nguồn mở trên public cloud không chỉ là việc quét CVE rồi nâng mọi package lên bản mới nhất. Bài viết của Canonical nhấn mạnh hai điểm phải được quản trị cùng lúc: chuỗi cung ứng phần mềm (software supply chain) và việc vá dependency nhưng vẫn giữ ổn định vận hành. Đây là bài toán rất thực tế cho đội ngũ chạy ứng dụng trên Ubuntu, AWS, Azure hoặc Google Cloud.

Chuỗi cung ứng phần mềm mã nguồn mở trên đám mây công cộng
Chuỗi cung ứng, build và package đều là bề mặt cần kiểm soát.

Không chỉ source code: rủi ro nằm trong đường build

Một artefact triển khai thường gồm code nội bộ, dependency bên thứ ba, package repository, CI/CD và môi trường build. Mỗi chặng là một điểm có thể bị thay đổi hoặc bị khai thác. Canonical dùng sự cố SolarWinds để minh họa: mã độc không nhất thiết xuất hiện trong source code sản phẩm; nó có thể bị chèn ở giai đoạn build. Vì vậy, code review đơn thuần không đủ. Doanh nghiệp cần tin cậy, hoặc tự kiểm soát được, quy trình tạo package và binary được đưa vào production.

Với quản trị viên, điều này chuyển thành các việc cụ thể: giới hạn quyền sửa pipeline; ký và kiểm tra artefact; lưu SBOM; khóa phiên bản dependency; theo dõi nguồn package; đồng thời tách quyền build, phê duyệt và triển khai. Khi xảy ra cảnh báo, cần biết chính xác image, VM hoặc dịch vụ nào đã dùng phiên bản bị ảnh hưởng, thay vì chỉ gửi một email chung chung.

Vá lỗ hổng nhưng không làm vỡ ứng dụng

Các dependency mã nguồn mở có maintainer và lịch phát hành riêng. Khi phát hiện lỗi bảo mật, đội ngũ thường có ba lựa chọn: bỏ qua, tự dành thời gian tích hợp bản sửa, hoặc dùng dịch vụ bảo trì bảo mật dài hạn. Bỏ qua là lựa chọn nguy hiểm: nguồn bài viết nhắc vụ Equifax năm 2017, khi bản vá Apache Struts đã có nhưng không được đưa vào production trong nhiều tháng. Hậu quả là dữ liệu của gần 150 triệu người bị lộ và khoản dàn xếp 575 triệu USD.

Lấy bản upstream mới nhất có thể nhanh, nhưng bản release đó thường gộp security fix, bug fix và tính năng mới. API hoặc hành vi runtime có thể thay đổi. Khi ấy, một CVE trở thành đợt regression test lớn: kiểm tra build, integration, user acceptance test và kế hoạch rollback. Cách khác là vendor dependency, tự backport patch vào codebase. Cách này giảm thay đổi trước mắt nhưng làm tổ chức gánh trách nhiệm duy trì một nhánh riêng, khó xác định các CVE tương lai có tác động hay không.

Đánh giá ảnh hưởng khi cập nhật dependency
Đánh giá cả mức độ phơi nhiễm lẫn nguy cơ thay đổi API trước khi triển khai.

ESM và Ubuntu Pro: phương án Canonical đề xuất

Canonical giới thiệu Expanded Security Maintenance (ESM), có trong Ubuntu Pro, như một lựa chọn thứ ba. Theo nguồn chính thức, ESM bao phủ hàng nghìn package thuộc repository main và universe trong tối đa 15 năm sau ngày phát hành Ubuntu. Với CVE mức cao hoặc nghiêm trọng, đội bảo mật Canonical tạo package đã vá, đưa qua quy trình build đáng tin cậy và phát hành bản thay thế tương thích.

Điểm vận hành quan trọng là bản thay thế hướng tới chỉ chứa security fix, giữ API và chức năng ổn định. Điều đó không loại bỏ hoàn toàn nhu cầu test, nhưng giúp giảm phạm vi thay đổi khi so với nâng nguyên dependency lên nhánh mới. Ubuntu Pro trên AWS, Azure và Google Cloud có entitlement gắn sẵn, ESM bật mặc định, thanh toán qua nhà cung cấp cloud. Với Oracle Cloud hoặc IBM Cloud, Canonical hướng người dùng liên hệ trực tiếp để triển khai.

Checklist cho đội ngũ IT

  • Lập inventory package, container image, repository và dịch vụ dùng dependency; xuất SBOM cho workload quan trọng.
  • Phân loại advisory theo mức Ä‘á»™ phÆ¡i nhiá»…m thá»±c tế, internet-facing hay ná»™i bá»™, trÆ°á»›c khi Æ°u tiên vá.
  • Xác minh provenance của artefact, quyền CI/CD và chữ ký package; không chỉ tin vào source repository.
  • So sánh changelog giữa bản Ä‘ang chạy, upstream má»›i và bản ESM/backport để biết thay đổi ngoài security fix.
  • Thá»­ trên staging vá»›i smoke test, integration test, backup và tiêu chí rollback rõ ràng.
  • Vá»›i Ubuntu dài hạn, kiểm tra trạng thái Ubuntu Pro/ESM trên từng instance và lÆ°u bằng chứng compliance.
  • Sau triển khai, theo dõi log, lá»—i ứng dụng và trạng thái service; cập nhật danh mục tài sản.
Checklist bảo mật dependency trên public cloud
Checklist triển khai bản vá dependency có kiểm soát.

Conclusion / Kết luận

Open-source dependencies increase delivery speed, but they also extend the trust boundary beyond code written by an internal team. A dependable response to vulnerability disclosure combines supply-chain controls, tested patching and an explicit ownership model. For organizations operating older Ubuntu workloads in public cloud, Ubuntu Pro and ESM can reduce the pressure to absorb unrelated upstream changes while maintaining a supported security posture.

Với doanh nghiệp, quyết định phù hợp không phải luôn là “update ngay lên latest”. Hãy chọn bản vá có nguồn gốc rõ ràng, biết nó tác động đến workload nào, kiểm thử theo mức rủi ro và triển khai có thể quay lui. Khi dependency được quản trị như một phần của sản phẩm, đội ngũ vừa giảm thời gian xử lý CVE vừa tránh tạo ra sự cố mới trong production.

Nguồn / Source

Canonical Ubuntu Blog — Securing open source software dependencies in the public cloud. Bài viết này được biên soạn lại theo nguồn gốc nêu trên.