این سرویس چیست؟

امنیت زنجیرهٔ تأمین کانتینر یعنی بررسی image، وابستگی‌ها، build و مسیر انتشار نرم‌افزار تا تیم مطمئن شود خروجی نهایی قابل‌اعتماد و قابل‌راستی‌آزمایی است.

امنیت زنجیرهٔ تأمین کانتینر مجموعه‌ای از روش‌ها و ابزارها برای اطمینان از سالم‌بودن image، کد build، وابستگی‌ها و مسیر انتشار نرم‌افزار است. این رویکرد کمک می‌کند تیم‌ها پیش از اجرای یک image در محیط عملیاتی، آسیب‌پذیری‌ها، سطح دسترسی، منشأ build و یکپارچگی خروجی را بررسی کنند و بتوانند شواهد قابل‌اعتنا برای آن ارائه دهند.

CNCF Score چه تغییری ایجاد کرد؟

پروژهٔ Score که یک پروژهٔ Sandbox در بنیاد Cloud Native Computing Foundation است، تجربهٔ خود را از تقویت امنیت imageهای کانتینری و خط انتشار نرم‌افزار منتشر کرده است. این پروژه با پیوستن به برنامهٔ Docker-Sponsored Open Source، استفاده از Docker Hub، Docker Scout، Docker Hardened Images، Docker GitHub Builder و اتصال‌های OIDC را در بخش‌هایی از فرایند توسعه و انتشار خود به کار گرفته است.

این گزارش در ۵ نوامبر ۲۰۲۶ در وبلاگ Docker منتشر شد و ارزش خبری آن فقط به استفادهٔ یک پروژه از چند ابزار محدود نیست. Score نشان می‌دهد چگونه یک پروژهٔ متن‌باز می‌تواند امنیت زنجیرهٔ تأمین کانتینر را از مرحلهٔ نوشتن Dockerfile تا انتشار image و ثبت شواهد build دنبال کند. این تجربه برای تیم‌های کوچک‌تر هم قابل استفاده است، چون بخش مهمی از آن بر خودکارسازی کنترل‌ها و حذف اسرار بلندمدت از pipeline تکیه دارد. تیم‌های فنی می‌توانند مطالب مرتبط با توسعه و زیرساخت را در وبلاگ تکتاز نیز دنبال کنند.

انتقال imageها به Docker Hub

پروژهٔ Score پیش از این imageهای ابزارهایی مانند score-compose، score-k8s، score-helm، score-radius و نمونهٔ sample-score-app را در GitHub Container Registry منتشر می‌کرد. پس از ورود به برنامهٔ Docker، این imageها در Docker Hub نیز ارائه شدند تا یک منبع معتبر و قابل‌تشخیص برای دریافت آن‌ها در اختیار جامعهٔ کاربران قرار گیرد. Docker می‌گوید برنامهٔ پشتیبانی متن‌باز، علاوه بر registry، قابلیت‌هایی مانند نشان تأییدشده، تحلیل استفاده و دسترسی بهتر به ابزارهای مدیریت زنجیرهٔ تأمین را فراهم می‌کند.

Docker Scout و مشاهدهٔ CVEها

یکی از تغییرهای مهم، افزودن Docker Scout به pull requestها و registry است. طبق گزارش Docker، این ابزار تفاوت image ساخته‌شده از شاخهٔ pull request و شاخهٔ اصلی را بررسی می‌کند و دربارهٔ بسته‌های اضافه یا حذف‌شده، CVEهای جدید یا رفع‌شده و رعایت سیاست‌های تعریف‌شده گزارش می‌دهد. چنین مقایسه‌ای باعث می‌شود تیم پیش از merge شدن تغییر، اثر امنیتی آن را در سطح image ببیند؛ نه اینکه فقط بعد از انتشار production متوجه تغییر dependencyها شود.

برای تیم‌های توسعه، این مرحله باید در کنار تست‌های نرم‌افزاری و برنامهٔ امنیت زنجیرهٔ تأمین کانتینر قرار بگیرد. گزارش اسکن به‌تنهایی اثبات نمی‌کند که یک سرویس کاملاً امن است، اما می‌تواند یک گیت قابل‌اندازه‌گیری برای جلوگیری از ورود imageهای دارای آسیب‌پذیری بحرانی، اجرای root یا بسته‌های ناخواسته ایجاد کند. سیاست‌ها باید بر اساس نوع سرویس، سطح ریسک و امکان اصلاح واقعی تنظیم شوند تا اسکن امنیتی به هشدارهای غیرقابل‌مدیریت تبدیل نشود.

imageهای کمینه و provenance قابل بررسی

Docker Hardened Images با هدف کاهش سطح حملهٔ پایه طراحی شده‌اند. این imageها فقط اجزای لازم را نگه می‌دارند، اجرای non-root را به‌عنوان پیش‌فرض دنبال می‌کنند و با SBOM، provenance سطح SLSA و چرخهٔ نگهداری برای اصلاح آسیب‌پذیری‌ها همراه هستند. در نمونهٔ Score، تغییر image پایهٔ ابزار score-radius فقط به اصلاح‌های محدودی در Dockerfile نیاز داشت و تعداد بسته‌ها و CVEهای خروجی قابل مقایسه باقی ماند.

در نمونهٔ NodeJS نیز طبق گزارش Docker، مهاجرت باعث حذف ۲۲ بسته، از جمله package manager و shell، و رفع ۲ CVE شد. نکتهٔ مهم این است که کمینه‌سازی image باید با تست سازگاری انجام شود؛ حذف shell یا ابزارهای تشخیصی ممکن است برای محیط production مناسب باشد، اما نباید بدون بررسی، فرایند build یا عیب‌یابی تیم را مختل کند. همین کنترل مرحله‌ای، یکی از پایه‌های امنیت زنجیرهٔ تأمین کانتینر است.

GitHub Builder و OIDC

پروژهٔ Score برای انتشار imageها از Docker GitHub Builder نیز استفاده کرده است. این workflow قابل‌استفادهٔ مجدد، محیط BuildKit و build چندسکویی را مدیریت می‌کند و provenance امضاشده‌ای تولید می‌کند که commit منبع و هویت builder را ثبت می‌کند. در نتیجه، مصرف‌کننده می‌تواند بهتر بررسی کند image از چه کدی و با چه فرایندی ساخته شده است. این شفافیت برای امنیت زنجیرهٔ تأمین کانتینر اهمیت دارد، چون منشأ artifact را به یک ادعای قابل بررسی تبدیل می‌کند.

همچنین اتصال OIDC جایگزین بخشی از توکن‌های بلندمدت شده است. در این مدل، workflow با مجوز کوتاه‌عمر و رابطهٔ اعتماد تعریف‌شده به registry متصل می‌شود و نیاز به نگهداری دائمی یک Organization Access Token کاهش می‌یابد. این الگو برای امنیت زنجیرهٔ تأمین کانتینر، سطح دسترسی credential را محدودتر می‌کند. این تغییر، در صورت تنظیم درست permissionها و محدودکردن دامنهٔ اعتماد، ریسک افشای credential در pipeline را کمتر می‌کند.

چک‌لیست کاربردی برای تیم‌ها

تیم‌هایی که می‌خواهند امنیت زنجیرهٔ تأمین کانتینر را تقویت کنند، می‌توانند از یک مسیر مرحله‌ای شروع کنند: ابتدا imageها و dependencyهای واقعی را فهرست کنند؛ سپس اسکن CVE و مقایسهٔ pull request را در CI فعال کنند؛ بعد imageهای کمینه و non-root را آزمایش کنند؛ SBOM و provenance را به خروجی build اضافه کنند؛ و در پایان، توکن‌های بلندمدت را با OIDC یا سازوکارهای کوتاه‌عمر جایگزین کنند.

هر تغییر باید در محیط آزمایشی و با سناریوی rollback بررسی شود. در امنیت زنجیرهٔ تأمین کانتینر، قابلیت بازگشت به نسخهٔ سالم بخشی از طراحی است، نه یک اقدام اضطراری پس از بروز مشکل. همچنین لازم است نتیجهٔ اسکن، digest image، commit منبع و هویت builder در کنار release نگهداری شود. این شواهد در زمان عیب‌یابی یا بررسی یک رخداد امنیتی، ارزش بیشتری از یک برچسب کلی مانند «image امن» دارند.

گزارش CNCF Score نشان می‌دهد امنیت زنجیرهٔ تأمین کانتینر یک محصول جداگانه نیست؛ مجموعه‌ای از کنترل‌های کوچک و قابل‌راستی‌آزمایی است که در registry، Dockerfile، CI، هویت‌ها و فرایند انتشار کنار هم قرار می‌گیرند. برای تیم‌های DevSecOps، همین نگاه مرحله‌ای مسیر اجرای امنیت زنجیرهٔ تأمین کانتینر را روشن‌تر می‌کند. جزئیات کامل تجربهٔ پروژه در گزارش رسمی Docker دربارهٔ CNCF Score منتشر شده و مستندات امنیت زنجیرهٔ تأمین Docker نیز برای طراحی کنترل‌های تکمیلی قابل استفاده است.