Một ứng dụng có thể được viết an toàn nhưng vẫn gặp sự cố vì thành phần do bên khác cung cấp. Thư viện mã nguồn mở, gói cài đặt, công cụ xây dựng và image container đều có thể trở thành điểm xâm nhập nếu đội ngũ không biết chúng đến từ đâu, đang dùng phiên bản nào và được đưa vào sản phẩm bằng cách nào. Hãy hình dung một nhóm phát triển sử dụng một thư viện tiện ích nhỏ trong nhiều dịch vụ. Một bản cập nhật mới được phát hành, quy trình CI/CD tự động tải về rồi đóng gói vào ứng dụng. Nếu gói này bị chèn mã độc hoặc tài khoản duy trì bị chiếm quyền, kẻ tấn công có thể tiếp cận hệ thống qua chính quy trình phát hành hợp lệ. Vì vậy, bảo vệ chuỗi cung ứng phần mềm không chỉ là việc quét mã nguồn tìm lỗ hổng. Bắt đầu bằng danh mục thành phần Mỗi sản phẩm nên có danh sách thành phần phần mềm, thường gọi là SBOM. Danh sách này cần ghi tên thư viện, phiên bản, nguồn tải, giấy phép và mối quan hệ phụ thuộc. Không nên chỉ lập một lần rồi bỏ quên; danh mục phải được cập nhật sau mỗi lần xây dựng hoặc phát hành. Với dự án nhỏ, có thể bắt đầu từ lockfile của trình quản lý gói và danh sách image đang chạy. Đặt một người chịu trách nhiệm đối chiếu danh mục này với kho mã, registry và môi trường sản xuất. Khi có cảnh báo về một thành phần, đội ngũ sẽ biết sản phẩm nào bị ảnh hưởng thay vì phải tìm thủ công trong nhiều kho riêng biệt. Giảm việc tải thành phần một cách tùy tiện Một số biện pháp thực dụng gồm: - Khóa phiên bản phụ thuộc, tránh để hệ thống tự động nhận mọi bản cập nhật mới. - Ưu tiên registry nội bộ có cơ chế kiểm duyệt và lưu lại phiên bản đã sử dụng. - Kiểm tra checksum hoặc chữ ký của gói khi nhà cung cấp hỗ trợ. - Tách quyền đọc, ghi và phát hành trong registry; tài khoản chỉ nên có quyền cần thiết. - Không để máy xây dựng có quyền truy cập rộng vào dữ liệu sản xuất. - Đánh giá cả thư viện phụ thuộc gián tiếp, vì một gói trực tiếp có thể kéo theo nhiều thành phần khác. Tự động hóa nhưng vẫn cần điểm kiểm soát Trong CI/CD, có thể thêm bước kiểm tra danh sách phụ thuộc, giấy phép, lỗ hổng đã biết và sự thay đổi bất thường của gói. Tuy nhiên, công cụ quét chỉ là tín hiệu hỗ trợ, không phải bằng chứng rằng phần mềm an toàn tuyệt đối. Một phiên bản chưa có cảnh báo vẫn có thể chứa hành vi đáng ngờ hoặc bị phát hành từ nguồn không đáng tin. Nên tạo quy tắc chặn đối với các trường hợp rủi ro cao, chẳng hạn gói thay đổi nhà phát hành đột ngột, phiên bản không nằm trong lockfile, image không có chữ ký hoặc quy trình xây dựng sử dụng nguồn tải không được phê duyệt. Các trường hợp chưa đủ chắc chắn có thể chuyển sang hàng đợi xem xét thủ công để tránh làm gián đoạn mọi bản phát hành. Bảo vệ artifact sau khi xây dựng Artifact đã được kiểm tra phải được lưu trong kho tin cậy, gắn mã phiên bản bất biến và có thông tin về thời điểm, công cụ, mã nguồn đã tạo ra nó. Không nên xây dựng lại cùng một phiên bản ở nhiều nơi rồi coi các kết quả là tương đương. Môi trường xây dựng nên được cô lập, dùng tài khoản ngắn hạn và không chứa khóa bí mật lâu dài. Nếu phát hiện một thư viện bị nghi ngờ, hãy xác định các phiên bản và sản phẩm liên quan, tạm dừng phát hành, cô lập artifact, thu hồi thông tin đăng nhập có thể đã bị lộ và kiểm tra nhật ký của máy xây dựng. Sau đó thay thế thành phần, xây dựng lại từ nguồn đã xác minh và ghi lại quyết định xử lý. Đừng chỉ xóa thư viện khỏi mã nguồn mà quên kiểm tra các image hoặc gói đã triển khai trước đó. Một kế hoạch khả thi cho tháng đầu tiên là: lập danh sách thành phần của các ứng dụng quan trọng, khóa phiên bản phụ thuộc, giới hạn quyền trong registry, bổ sung kiểm tra vào pipeline và diễn tập quy trình thu hồi một artifact. Những bước này không loại bỏ toàn bộ rủi ro, nhưng giúp doanh nghiệp biết mình đang sử dụng gì, phát hiện thay đổi sớm hơn và phản ứng có căn cứ khi một mắt xích trong chuỗi cung ứng gặp vấn đề.