چینگارد در تنها شش ماه تولید خود را از ۵۰۰ میلیون به بیش از یک میلیارد منیفست ساخت کانتینر رساند. همزمان کاتالوگ به ۳٬۰۰۰ تصویر منحصربهفرد و ۶۷۵٬۰۰۰ نسخه رسید. اما ارقام تیتر خبر فقط نیمهی ماجراست؛ چیزی که این حجم را ممکن ساخته، بازاندیشیِ ریشهای در نحوهی تولید، امضای و تحویل تصاویر کانتینر است.
منیفست ساخت در چینگارد دقیقاً چیست؟
هر بار که فکتوری چینگارد (Chainguard Factory) یک مصنوع (artifact) جدید و قابل تأیید تولید میکند، یک منیفست ثبت میشود: تصویری تازه برای go:1.26.5، بازسازی nginx بهخاطر وصلهی libc، یک نوع معماری جدید، یا یک SBOM بازتولیدشده پس از تغییر وابستگی. در مقیاس فعلی، یک پروژه مثل پایتون دهها نسخه پشتیبانیشده دارد، هر کدام با چند معماری، و هر کدام بارها بازسازی میشوند — هر وقت آپستریم تغییر کند، وابستگی پچ شود، یا تصویر پایه سختتر (harden) گردد. این شمارش نشان میدهد کاتالوگ در هر لحظه و برای هر پروژه چقدر «تازه» و امن است؛ تفاوتِ 
کانتالوگی که در روز پول امن است با کانتالوگی که هر روز بعد از آن هم امن بماند.
مبنای فنی: چینگارد اواس و مدل رولینگ
همه چیز از چینگارد اواس (Chainguard OS) آغاز میشود؛ یک توزیع لینوکس هدفمند برای بارهایکار بومیابری که کنترل کامل زنجیره تامین را در دست میگیرد. برخلاف توزیعهای سنتی که هر شش ماه یک انتشار قطع میکنند، چینگارد اواس از مدل انتشار رولینگ (rolling release) بهره میبرد — مصنوعات جدید روزانه و sepanjang روز تحویل میشوند. این معماری به ما اجازه میدهد بروزرسانیهای امنیتی، عملکردی و کارایی جامعه متنباز را با تأخیرِ نزدیک به صفر به مشتریان برسانیم.
فکتوری ۱.۰: وقتی رویدادها کنترل را از دست دادند
نسخه اول فکتوری مکانیک ساخت را خودکار میکرد: تعریف بسته → حل وابستگی → ساخت → امضا → ارسال. اما معماری رویدادمحور سنتی، با رشد کاتالوگ، به یک پیچوخم آبشاری
تبدیل شد. صفها شکننده شدند، اعلانها مهندسان SRE را غرق کرد، و تضاد اقلامکار (work-item conflicts) روال روزانه شد. هر شکست جزئی نیازمند مداخله انسانی میشد و تیم مدام در حلقه بیباکُنده CVE
گیر کرده بود — بهجای پیشگیری، دائماً انحراف پیکربندی (configuration drift) و رگباری را جبران میکرد.
فکتوری ۲.۰ و DriftlessAF: تعدیل خودمختار بهجای واکنش رویدادی
پاسخ چینگارد، فکتوری ۲.۰ است که با موتور DriftlessAF توانمند شده. این سیستم خوداصلاحکننده (self-correcting)، لایهای از تعدیل (reconciliation) عاملانمحور و مبتنی بر هوش مصنوعی بر روی خودکارسازی قطعی موجود میافزاید:
- حلقه تعدیل مداوم: بهجای واکنش به رویدادهای مجزا، DriftlessAF حالت مطلوب (desired state) را با حالت واقعی مقایسه میکند و شکاف را هر وقت که یک CVE گزارش شود، نسخه بسته جدیدی در آپستریم بیاید، یا یک بهترین روش جدید تدوین گردد، میبندد.
- صف کار اشتراکی و رباتهای تعدیل: تعداد زیادی ربات تعدیل (reconciler bots) به طور مداوم از یک صف مشترک اقلامکار تخصیص مییابند و حالت کشفشده از مخازن کد، خوراکهای امنیتی و سایر منابع را با هدف تعدیل میکنند.
- از طراحی پیشینه (Redundant by design): چون هر تسک به سمت یک حالت پایان تعریفشده کار میکند، یک اقلامکار ناموفق میتواند به سادگی رها یا مجدداً امتحان شود بدون اینکه کل پایلاین فلج گردد.
چرا بازتولیدپذیری (Reproducibility) تنها نصف ماجراست
ساختهای اعلانی و قابلبازتولید تضمین میکنند که انحراف (drift) بین آنچه قصد داریم و آنچه تحویل میدهیم وجود نداشته باشد. اما سرعت (velocity) برای رسیدن به یک میلیارد منیفست در شش ماه، چیزی فراتر از بازتولیدپذیری میطلبید: دانستنِ کی باید بازسازی کرد و اقدام فوری بر روی آن سیگنال در هزاران پروژه وابسته، بدون انسان در حلقه برای هر تصمیم. DriftlessAF دقیقاً این قطعیتِ زمانی و مقیاس را فراهم میکند.
آینده: امنیت هر روز، نه فقط روز اول
این معماری تغییر پارادایم است: از مدیریت آسیبپذیریِ واکنشی به زیرساختی که امروز، فردا و هفتهی بعد هم تضمین میکند تصویرِ که پول میکنید، از آخرین وصلههای امنیتی و بهترین روشهای سختسازی برخوردار است. فکتوری ۲.۰ در حال حاضر پایهی تمام تصاویر چینگارد است و مسیر را برای مقیاسهای بزرگتر هم هموار میسازد.
