Trong sáu tháng qua, Chainguard đã tăng gấp đôi sản lượng từ 500 triệu lên hơn 1 tỷ container build manifest. Chúng tôi cũng đã vượt qua con số 3.000 container image duy nhất và 675.000 phiên bản image trong danh mục của mình. Đó là những con số tiêu đề ấn tượng, nhưng tôi muốn chia sẻ những gì thực sự đứng sau chúng. Bản thân con số ít thú vị hơn hệ thống đã tạo ra nó và lý do tại sao chúng tôi phải tư duy lại căn bản hệ thống đó để đạt được kết quả này.
Build manifest thực sự đại diện cho điều gì?
Hãy chính xác về những gì chúng ta đang đếm. Làm thế nào để định nghĩa một "build manifest"? Hãy coi đó là mỗi lần Chainguard Factory tạo ra một artifact mới, có thể xác minh: một image mới cho go:1.26.5, một bản rebuild của nginx được kích hoạt bởi một bản patch libc, một biến thể kiến trúc mới, một SBOM được tạo lại sau khi thay đổi phụ thuộc - tất cả các sự kiện này đều tạo ra một bản build mới và do đó là các artifact mới.
Ở quy mô của chúng tôi, một dự án duy nhất như Python có thể có hàng chục phiên bản được hỗ trợ, mỗi phiên bản có nhiều bản build kiến trúc, mỗi bản được rebuild liên tục khi thượng nguồn thay đổi, khi các phụ thuộc được patch và khi chúng tôi tăng cường bảo mật cho base image hơn nữa. Con số này cho thấy toàn bộ danh mục của chúng tôi luôn mới mẻ tại bất kỳ thời điểm nào trên mọi dự án mà chúng tôi hỗ trợ.
Sự khác biệt đó là ranh giới giữa một danh mục an toàn vào ngày bạn pull một image và một danh mục an toàn vào mọi ngày sau đó. Hầu hết việc quản lý lỗ hổng bảo mật được xây dựng xoay quanh vế trước, nhưng chúng tôi đang xây dựng cơ sở hạ tầng cho vế sau.
Cách chúng tôi xây dựng
Mọi thứ bắt đầu với Chainguard OS, hệ điều hành Linux được xây dựng cho mục đích riêng biệt của chúng tôi. Chainguard OS được thiết kế cho các khối lượng công việc cloud-native hiện đại và mang lại cho chúng tôi quyền kiểm soát hoàn toàn đối với chuỗi cung ứng phần mềm. Không giống như các bản phân phối Linux truyền thống và kế thừa, Chainguard OS được thiết kế để tích hợp và phân phối phần mềm liên tục, cũng như các bản rebuild và nano-update nhanh chóng. Chúng tôi nắm bắt tất cả các bản cập nhật bảo mật, chức năng và hiệu suất do cộng đồng mã nguồn mở xây dựng và phân phối chúng đến khách hàng nhanh nhất có thể. Chúng tôi không phát hành một bản release sau mỗi sáu tháng rồi để bản phân phối đó cũ đi. Chainguard OS sử dụng cơ chế rolling release và các artifact mới được xuất xưởng cả ngày, mỗi ngày.
Chainguard Factory là cơ sở hạ tầng và engine có tính agentic hỗ trợ quá trình phân phối này. Mọi artifact ra khỏi factory đều có các lớp phòng thủ và được xây dựng từ nguồn với SLSA Level 3 provenance, chữ ký Sigstore và SBOM đầy đủ.
Quy mô và kiến trúc của factory giúp việc rebuild ở khối lượng này trở nên khả thi. Vì các bản build mang tính khai báo (declarative) và có thể tái lập (reproducible), chúng tôi có thể tạo lại một image mà không lo lắng về trạng thái ẩn hoặc sự sai lệch (drift) giữa những gì chúng tôi dự định xuất xưởng và những gì thực sự được xuất xưởng. Nhưng chỉ riêng khả năng tái lập không giúp bạn đạt được một tỷ build manifest trong khoảng thời gian chúng ta đang nói tới. Tốc độ (Velocity) đòi hỏi một thứ khác: biết khi nào cần rebuild và có khả năng hành động theo tín hiệu đó ngay lập tức, trên hàng nghìn dự án phụ thuộc lẫn nhau, mà không cần con người can thiệp vào mọi quyết định.
Tại sao chúng tôi xây dựng Factory 2.0
Chainguard Factory ban đầu đã tự động hóa các cơ chế xây dựng. Nó sẽ lấy định nghĩa gói, giải quyết các phụ thuộc, xây dựng gói, ký tên và xuất xưởng. Nhưng kiến trúc đó là một hệ thống hướng sự kiện truyền thống, và khi danh mục của chúng tôi phát triển, các giới hạn của nó trở nên không thể phớt lờ. Nó biến thành cái mà chúng tôi gọi nội bộ là một "mớ hỗn độn đổ dồn" (cascading mess). Các SRE chìm trong các thông báo sự kiện, các hàng đợi trở nên mong manh, các lỗi build trùng lặp và xung đột công việc xảy ra phổ biến. Bất cứ khi nào một tác vụ chỉ thành công một phần hoặc gặp phải điều gì đó không lường trước được, nó cần con người can thiệp để khắc phục. Chúng tôi phải đối mặt với "vòng lặp CVE vô tận": bất kể đội ngũ làm việc chăm chỉ đến đâu, cơ sở hạ tầng vẫn liên tục phải đấu tranh với sự sai lệch cấu hình và sự xuống cấp thay vì đón đầu nó.
Factory 2.0, được hỗ trợ bởi cái mà chúng tôi gọi là DriftlessAF, là câu trả lời của chúng tôi cho vấn đề đó. Đó là một hệ thống build tự điều chỉnh, xếp lớp việc đối soát (reconciliation) có tính agentic, hỗ trợ bởi AI lên trên cơ chế tự động hóa xác định hiện có của chúng tôi. Cụ thể, điều đó có nghĩa là:
- Một vòng lặp đối soát (reconciliation loop): Thay vì phản ứng với các sự kiện riêng lẻ, DriftlessAF liên tục so sánh trạng thái mong muốn với trạng thái thực tế và nỗ lực thu hẹp khoảng cách bất cứ khi nào một CVE được báo cáo, một phiên bản gói mới xuất hiện ở thượng nguồn, một thực hành tốt nhất mới được triển khai hoặc khi chúng tôi xác định một tiêu chí mới nào đó.
- Hàng đợi công việc liên tục: Một số lượng lớn các bot đối soát được phân công công việc liên tục từ một hàng đợi chung, đối soát trạng thái được phát hiện từ các code repository, security feed và các nguồn khác với trạng thái mục tiêu của chúng tôi.
- Dự phòng theo thiết kế: Vì mỗi tác vụ đều hướng tới một trạng thái cuối cùng đã được xác định thay vì thực hiện một hành động một lần duy nhất, một hạng mục công việc thất bại có thể đơn giản là bị loại bỏ hoặc thử lại. Hệ thống cuối cùng sẽ hội tụ về kết quả đúng, thay vì yêu cầu mọi bước phải thành công ngay lần đầu tiên.
- AI được sử dụng đúng chỗ: Các bot đối soát sử dụng AI đặc biệt để xử lý các phán đoán không có cấu trúc mà tự động hóa truyền thống không thể thực hiện được — như suy luận về một thành phần mới được thêm vào trong một bản phát hành phụ hoặc backport một bản khắc phục CVE cho một phiên bản gói và ngôn ngữ cũ hơn — trong khi vẫn làm việc thông qua các công cụ có cấu trúc cao, có thể xác minh để ngăn vòng lặp không bị "ảo giác" dẫn đến kết quả xấu. Hơn nữa, hệ thống học hỏi từ những thành công trước đó. Theo thời gian, hệ thống ngày càng trở nên độc lập và mạnh mẽ hơn trong việc xử lý các tác vụ phức tạp.
Giá trị ở đây là AI đang hấp thụ khối lượng công việc vận hành nặng nề — những phán đoán đơn giản, phân loại chi tiết và hàng nghìn quyết định nhỏ — vốn từng là nút thắt cổ chai đối với tốc độ rebuild.
Tại sao tốc độ lại quan trọng
Mô hình đe dọa đã thay đổi, và tốc độ trên quy mô lớn là tất cả. Những kẻ tấn công đang ngày càng tận dụng các công cụ AI tương tự để phát hiện lỗ hổng, tạo exploit và chuỗi exploit phức tạp cho các cuộc tấn công hiệu quả. AI có thể quét các đồ thị phụ thuộc, chuỗi các điểm yếu và tạo ra một bản exploit hoạt động nhanh hơn nhiều so với một kẻ tấn công là con người. Khi chu kỳ thời gian của kẻ tấn công bị nén lại, chu kỳ thời gian của người phòng thủ cũng phải nén lại ít nhất một lượng tương đương.
Tốc độ rebuild là thứ giúp danh mục luôn an toàn. Mỗi giờ chúng tôi cắt giảm được trong khoảng thời gian từ khi thượng nguồn thay đổi đến khi có một image được build lại, ký tên và xác minh là một giờ mà kẻ tấn công không có để khai thác. Việc tăng gấp đôi sản lượng từ 500 triệu lên 1 tỷ build manifest trong sáu tháng là bằng chứng cho thấy vòng lặp đối soát đang hoạt động với tốc độ có thể bắt kịp với xu hướng của bối cảnh đe dọa.
Bản chất agentic và tự động của Chainguard Factory cũng cho phép đội ngũ kỹ sư của chúng tôi đóng vai trò là chuyên gia cho các agent, phân xử các thay đổi được đề xuất và tập trung vào việc cải thiện hơn nữa cơ sở hạ tầng factory, chất lượng đầu ra và phạm vi tổng thể của mọi thứ mà Chainguard Factory xây dựng và duy trì.
Bước tiếp theo là gì
Chúng tôi không chậm lại từ đây. Đội ngũ tiếp tục mở rộng DriftlessAF, framework agentic mã nguồn mở cốt lõi của chúng tôi trong Chainguard Factory, với nhiều bot đối soát hơn, nhiều nguồn cung cấp cho hàng đợi công việc hơn và nhiều danh mục chạy qua vòng lặp tự chữa lành hơn thay vì con đường hướng sự kiện cũ. Và bởi vì cốt lõi của DriftlessAF hiện là mã nguồn mở, các đội ngũ khác đang đối mặt với các vấn đề tự động hóa quy mô lớn của riêng họ có thể xây dựng dựa trên những gì chúng tôi đã học được thay vì bắt đầu từ con số không.
Nếu bạn muốn xem những gì thực sự có trong danh mục hiện nay, container image catalog của chúng tôi là nơi tốt nhất để xem xét. Và nếu bạn muốn tìm hiểu sâu hơn về chính hệ thống này, bạn có thể kiểm tra DriftlessAF.
Lưu ý: Bài viết này được viết chuyên sâu và đóng góp bởi Matt Moore, Đồng sáng lập và CTO của Chainguard.
