بومی‌سازی یعنی کمتر به سرویس‌ها و محصولات خارجی وابسته باشیم، اما خودبه‌خود امنیت نمی‌آورد. سیستمی که «ساخت داخل» است هنوز از ده‌ها کتابخانه متن‌باز، کامپایلر، سیستم‌عامل، تراشه و فرم‌ور ساخته می‌شود که هرکدام زنجیره تأمین خودشان را دارند. اگر این زنجیره دیده و کنترل نشود، بومی‌سازی فقط جای ریسک را عوض می‌کند و آن را از بین نمی‌برد. در این مقاله امنیت زنجیره تأمین نرم‌افزار و سخت‌افزار را در پروژه‌های بومی‌سازی در سطح پیشرفته بررسی می‌کنیم: از مدل تهدید و کنترل کیفیت قطعات تا SBOM، امضای کد و ممیزی تأمین‌کنندگان داخلی.
چرا زنجیره تأمین پاشنه آشیل پروژه‌های بومی‌سازی است؟
در بومی‌سازی سیستم‌ها معمولاً توجه به محصول نهایی است: نرم‌افزار ERP داخلی، فایروال بومی یا سرور مونتاژ داخل. اما مهاجم حرفه‌ای همیشه به محصول نهایی حمله نمی‌کند. ساده‌تر است که حلقه ضعیف‌تری را هدف بگیرد، مثلاً یک کتابخانه کوچک، سرور بیلد یک پیمانکار یا محموله قطعاتی که از واسطه خریده شده است.
چند ویژگی پروژه‌های بومی‌سازی این ریسک را بیشتر می‌کند:
- واسطه‌های متعدد در خرید سخت‌افزار: وقتی خرید مستقیم از سازنده ممکن نیست، قطعه چند دست می‌چرخد و احتمال تقلب یا دست‌کاری بالا می‌رود. این موضوع در مقاله ریسک‌های تحریم و وابستگی فناوری هم بررسی شده است.
- اتکای زیاد به متن‌باز: بیشتر محصولات بومی روی پروژه‌های متن‌باز ساخته می‌شوند. این کار منطقی است، ولی بدون مدیریت وابستگی‌ها ریسک ایجاد می‌کند.
- بالغ نبودن فرایندهای امنیتی در تأمین‌کنندگان کوچک: بسیاری از شرکت‌های داخلی تیم کوچکی دارند و فرایند بیلد امن، مدیریت کلید و پاسخ به آسیب‌پذیری در آن‌ها رسمی و مستند نیست.
- به‌روزرسانی‌های آفلاین و آینه‌های (Mirror) داخلی: مخازن داخلی اگر درست امن نشوند، خودشان به نقطه تزریق کد مخرب تبدیل می‌شوند.
مدل تهدید زنجیره تأمین: مهاجم کجا وارد می‌شود؟
برای دفاع درست باید اول نقاط ورود را شناخت. زنجیره تأمین را می‌شود به چند مرحله تقسیم کرد: کد منبع، وابستگی‌ها، فرایند بیلد، توزیع و استقرار. در سخت‌افزار هم مراحل طراحی، ساخت، حمل، مونتاژ و فرم‌ور وجود دارد.
تهدیدهای سمت نرم‌افزار
- دست‌کاری کد منبع: نفوذ به مخزن Git یا حساب یک توسعه‌دهنده و اضافه‌کردن کد مخرب.
- وابستگی آلوده: روش‌هایی مثل Typosquatting (بسته‌ای با نامی شبیه بسته معروف)، Dependency Confusion (بسته عمومی هم‌نام با بسته داخلی که نسخه بالاتری دارد) و تصاحب بسته‌هایی که نگهدارنده‌شان رهایشان کرده است.
- نفوذ به خط بیلد: حمله SolarWinds در سال ۲۰۲۰ نشان داد که اگر سرور بیلد آلوده شود، کد مخرب با امضای معتبر سازنده به دست مشتری می‌رسد.
- مهندسی اجتماعی بلندمدت: در درِ پشتی (Backdoor) کتابخانه xz Utils که در سال ۲۰۲۴ کشف شد (CVE-2024-3094)، مهاجم سال‌ها اعتماد جامعه را جلب کرد تا به جایگاه نگهدارنده برسد و کد مخرب را در فایل‌های تست و اسکریپت بیلد پنهان کند.
- آلوده‌شدن کانال به‌روزرسانی: جایگزین‌کردن بسته روی آینه داخلی یا حمله مرد میانی به فرایند آپدیت.
تهدیدهای سمت سخت‌افزار
- قطعات تقلبی (Counterfeit): تراشه‌های بازیافتی، بازبرچسب‌شده یا ردشده در کنترل کیفیت که به‌جای قطعه اصلی فروخته می‌شوند.
- دست‌کاری در مسیر حمل (Interdiction): باز کردن محموله، اضافه‌کردن قطعه یا تغییر فرم‌ور پیش از تحویل.
- فرم‌ور و BIOS/UEFI آلوده: بدافزاری که پایین‌تر از سیستم‌عامل اجرا می‌شود و با نصب مجدد OS هم پاک نمی‌شود.
- تروجان سخت‌افزاری: تغییر در طراحی مدار یا IP Core، مخصوصاً در FPGA و ASICهایی که طراحی یا ساختشان برون‌سپاری شده است.
کنترل کیفیت کتابخانه‌ها و وابستگی‌های نرم‌افزاری
استفاده از متن‌باز در بومی‌سازی تقریباً اجتناب‌ناپذیر است. در مقاله نقش نرم‌افزار متن‌باز در بومی‌سازی مزایای آن را گفته‌ایم. اینجا سؤال این است که چطور آن را امن مصرف کنیم.
معیارهای پذیرش یک وابستگی
- سلامت پروژه: تعداد نگهدارنده‌های فعال، سرعت رفع آسیب‌پذیری‌ها، سیاست امنیتی مستند و تاریخ آخرین انتشار. ابزارهایی مثل OpenSSF Scorecard این معیارها را به‌صورت خودکار امتیازدهی می‌کنند.
- مجوز (License): سازگاری مجوز با مدل تجاری محصول بومی.
- سطح دسترسی: کتابخانه‌ای که به شبکه، فایل‌سیستم یا اجرای کد دسترسی دارد بررسی دقیق‌تری لازم دارد.
- وابستگی‌های تودرتو: یک بسته ساده ممکن است صدها وابستگی غیرمستقیم بیاورد.
کنترل‌های فنی پیشنهادی
- استفاده از مخزن مصنوعات داخلی (مثل Nexus یا Artifactory یا آینه‌های اختصاصی) به‌عنوان تنها منبع مجاز و بستن دسترسی مستقیم بیلدها به مخازن عمومی.
- قفل‌کردن نسخه‌ها و هش‌ها با lockfileها (مثل
package-lock.json،go.sumیاrequirements.txtبا گزینه--require-hashes). - رزرو نام بسته‌های داخلی و تعریف scope برای جلوگیری از Dependency Confusion.
- اسکن مداوم با ابزارهای تحلیل ترکیب نرم‌افزار (SCA) و هم‌خوانی با پایگاه‌های آسیب‌پذیری مثل OSV و NVD.
- بازبینی دستی تغییرات وابستگی‌های حساس، مخصوصاً اسکریپت‌های نصب و بیلد که در ماجرای xz محل اختفای کد مخرب بودند.
کنترل کیفیت قطعات سخت‌افزاری
در سخت‌افزار نمی‌شود کد را «خواند». به همین دلیل کنترل کیفیت به ترکیبی از اسناد، آزمون و ردیابی نیاز دارد.
- ردیابی منشأ (Provenance): مدارک زنجیره خرید از سازنده یا توزیع‌کننده مجاز تا تحویل. هر حلقه‌ای که سند ندارد ریسک بالا حساب می‌شود.
- بازرسی فیزیکی و آزمایشگاهی: بررسی ظاهری، اشعه ایکس، آزمون الکتریکی و در موارد حساس، Decapsulation نمونه‌ای از قطعات. استانداردهایی مثل SAE AS6081 و AS5553 برای مقابله با قطعات تقلبی مرجع خوبی هستند.
- اعتبارسنجی فرم‌ور: مقایسه هش فرم‌ور با نسخه رسمی سازنده، فعال‌سازی Secure Boot و استفاده از TPM برای Measured Boot.
- آزمون پذیرش نمونه‌ای: نمونه‌گیری آماری از هر محموله و آزمون آن در آزمایشگاه مستقل.
- مهر و موم ضددست‌کاری: برای تجهیزات حساس، بسته‌بندی ضددست‌کاری و ثبت شماره سریال در مبدأ و مقصد.
SBOM: شناسنامه اجزای نرم‌افزار
فهرست اجزای نرم‌افزار (Software Bill of Materials یا SBOM) فهرستی ماشین‌خوان از همه اجزای یک محصول است: کتابخانه‌ها، نسخه‌ها، هش‌ها، مجوزها و روابط وابستگی. وقتی آسیب‌پذیری جدیدی مثل Log4Shell منتشر می‌شود، سازمانی که SBOM دارد در چند دقیقه می‌فهمد کدام سیستم‌هایش آسیب‌پذیرند. سازمانی که SBOM ندارد ممکن است هفته‌ها درگیر جست‌وجو باشد.
استانداردهای اصلی
| ویژگی | SPDX | CycloneDX |
|---|---|---|
| متولی | Linux Foundation | OWASP |
| وضعیت استانداردسازی | استاندارد ISO/IEC 5962 | استاندارد ECMA-424 |
| تمرکز اولیه | مجوزها و انطباق حقوقی، و در نسخه ۳ پروفایل‌های امنیتی | امنیت و مدیریت آسیب‌پذیری |
| پشتیبانی از سخت‌افزار و فرم‌ور | دارد | دارد (HBOM و مدل‌های مرتبط) |
| VEX | از طریق پروفایل‌ها و اسناد جانبی | پشتیبانی داخلی |
هر دو استاندارد به‌طور فعال توسعه می‌یابند و نسخه‌های جدید منتشر می‌کنند. قبل از انتخاب، آخرین نسخه و پشتیبانی ابزارهای خود را بررسی کنید.
SBOM را درست پیاده کنید
- تولید در زمان بیلد و نه بعد از آن: SBOMی که از روی باینری نهایی حدس زده می‌شود ناقص است. ابزارهایی مثل Syft یا افزونه‌های CycloneDX را در خط CI/CD قرار دهید.
- امضای SBOM: SBOM امضانشده خودش ممکن است جعل شود.
- استفاده از VEX: سند VEX (Vulnerability Exploitability eXchange) مشخص می‌کند یک آسیب‌پذیری موجود در SBOM واقعاً قابل بهره‌برداری است یا نه. این کار از هشدارهای کاذب جلوگیری می‌کند.
- الزام قراردادی: در قرارداد با تأمین‌کنندگان داخلی، تحویل SBOM استاندارد همراه هر نسخه را اجباری کنید.
- HBOM برای سخت‌افزار: فهرست قطعات سخت‌افزاری، نسخه فرم‌ورها و منشأ آن‌ها را هم به همین شکل ثبت کنید.
SBOM به‌تنهایی امنیت ایجاد نمی‌کند. ارزشش در این است که آن را به‌طور مداوم با پایگاه‌های آسیب‌پذیری مقایسه کنید و برای تصمیم‌گیری به کار ببرید.
امضای کد و یکپارچگی خط بیلد
امضای کد (Code Signing) ثابت می‌کند که یک مصنوع از طرف تولیدکننده مشخصی آمده و بعد از امضا تغییر نکرده است. اما همان‌طور که ماجرای SolarWinds نشان داد، امضا فقط به اندازه امنیت فرایندی که آن را تولید می‌کند معتبر است.
اصول مدیریت کلید
- نگهداری کلیدهای امضا در HSM یا توکن سخت‌افزاری و هرگز روی دیسک سرور بیلد.
- جداسازی کلید امضای نسخه انتشار از کلیدهای توسعه و تست.
- سیاست چرخش کلید، فرایند ابطال و ثبت همه رویدادهای امضا.
- برای کلیدهای بسیار حساس، الزام امضای چندنفره (M-of-N).
Sigstore و شفافیت
پروژه Sigstore با ابزار cosign امضای بدون کلید بلندمدت (Keyless) را ممکن می‌کند. هویت امضاکننده از طریق OIDC تأیید می‌شود و هر امضا در یک لاگ شفافیت عمومی (Rekor) ثبت می‌شود. در محیط‌های بومی و ایزوله می‌توان نمونه خصوصی Sigstore را با CA و لاگ شفافیت داخلی راه‌اندازی کرد تا وابستگی به سرویس خارجی از بین برود.
چارچوب SLSA و Provenance
چارچوب SLSA (Supply-chain Levels for Software Artifacts) سطح‌های بلوغ امنیت بیلد را تعریف می‌کند. در سطوح بالاتر، بیلد روی پلتفرم ایزوله و مقاوم در برابر دست‌کاری اجرا می‌شود و سند Provenance امضاشده‌ای تولید می‌کند. این سند می‌گوید مصنوع از کدام کد، با کدام دستور و روی کدام سیستم ساخته شده است. مکمل این کار بیلدهای تکرارپذیر (Reproducible Builds) است: اگر دو بیلد مستقل از یک کد منبع باینری کاملاً یکسانی تولید کنند، دست‌کاری در یکی از سرورهای بیلد قابل تشخیص می‌شود. پروژه‌هایی مثل Debian سال‌هاست روی این موضوع کار می‌کنند.
تأیید در زمان استقرار
امضا اگر بررسی نشود فایده‌ای ندارد. در Kubernetes می‌توان با Admission Controllerهایی مثل Kyverno یا Sigstore Policy Controller فقط ایمیج‌هایی را اجرا کرد که امضای معتبر و Provenance قابل قبول دارند. این همان رویکرد معماری Zero Trust است که در زنجیره تأمین به کار رفته است: هیچ مصنوعی بدون تأیید پذیرفته نمی‌شود.
ممیزی تأمین‌کنندگان داخلی
«داخلی بودن» یعنی دسترسی آسان‌تر و پاسخ‌گویی حقوقی روشن‌تر، ولی تضمین امنیت نیست. ممیزی تأمین‌کننده باید فرایندی ساخت‌یافته و تکرارشونده باشد.
محورهای ممیزی
- چرخه توسعه امن (SDLC): بازبینی کد، تست امنیتی خودکار، مدل‌سازی تهدید و رعایت اصولی مثل راهنماهای OWASP.
- امنیت زیرساخت توسعه: احراز هویت چندعاملی برای مخازن، کنترل دسترسی به سرور بیلد و جداسازی شبکه.
- مدیریت وابستگی‌ها: وجود SBOM، سیاست به‌روزرسانی و منبع دریافت کتابخانه‌ها.
- مدیریت آسیب‌پذیری: کانال گزارش‌دهی، مهلت تعهدشده برای وصله و سابقه پاسخ به حوادث.
- زنجیره تأمین سخت‌افزار تأمین‌کننده: این‌که خود او قطعات را از کجا و چگونه تهیه می‌کند.
- تداوم کسب‌وکار: سپردن کد منبع نزد امین (Source Code Escrow) برای وقتی که تأمین‌کننده از بازار خارج شود.
سطح‌بندی ریسک تأمین‌کنندگان
| سطح | نمونه | عمق ممیزی |
|---|---|---|
| بحرانی | فایروال، سیستم‌عامل، HSM، نرم‌افزار کنترل صنعتی | ممیزی حضوری، بازبینی کد، تست نفوذ مستقل و ممیزی سالانه |
| بالا | ERP، نرم‌افزار مالی، سرورها | پرسش‌نامه جامع، SBOM، شواهد فرایندی و بازدید دوره‌ای |
| متوسط | ابزارهای اداری و جانبی | پرسش‌نامه استاندارد و بررسی گواهی‌ها |
| پایین | لوازم جانبی غیرمتصل | بررسی اسناد خرید |
چارچوب‌هایی مثل NIST SP 800-161 برای مدیریت ریسک زنجیره تأمین، NIST SSDF (SP 800-218) برای توسعه امن و ISO/IEC 27036 برای امنیت روابط با تأمین‌کننده، الگوهای خوبی برای طراحی پرسش‌نامه و معیارهای ممیزی هستند. در سطح بین‌المللی هم مقرراتی مثل قانون تاب‌آوری سایبری اتحادیه اروپا (CRA) به‌تدریج تولیدکنندگان را به مدیریت آسیب‌پذیری و مستندسازی اجزای محصول ملزم می‌کنند. این روند نشان می‌دهد SBOM و گزارش‌دهی آسیب‌پذیری در حال تبدیل‌شدن به حداقل انتظار بازار است.
برای این‌که این کنترل‌ها بدون اختلال در کسب‌وکار اجرا شوند، آن‌ها را در فازهای نقشه راه بومی‌سازی سازمانی بگنجانید و از سیستم‌های بحرانی شروع کنید.
سوالات متداول
آیا نرم‌افزار بومی ذاتاً از نظر زنجیره تأمین امن‌تر است؟
نه لزوماً. نرم‌افزار بومی ریسک قطع سرویس و تحریم را کم می‌کند، ولی اگر از کتابخانه‌های بررسی‌نشده استفاده کند یا فرایند بیلد امنی نداشته باشد، می‌تواند به همان اندازه آسیب‌پذیر باشد. امنیت از فرایند می‌آید، نه از محل تولید.
SBOM را باید خودمان تولید کنیم یا از تأمین‌کننده بخواهیم؟
هر دو. تأمین‌کننده باید SBOM امضاشده را همراه هر نسخه تحویل دهد. سازمان هم بهتر است با اسکن مستقل، درستی و کامل‌بودن آن را بسنجد.
امضای کد جلوی حمله‌ای مثل SolarWinds را می‌گیرد؟
به‌تنهایی نه، چون در آن حمله کد مخرب پیش از امضا وارد شده بود. برای این نوع تهدید باید امضا را با بیلد ایزوله، Provenance مطابق SLSA و بیلدهای تکرارپذیر ترکیب کرد.
سازمان کوچک با بودجه محدود از کجا شروع کند؟
با سه کار کم‌هزینه: راه‌اندازی مخزن مصنوعات داخلی به‌عنوان تنها منبع وابستگی‌ها، تولید خودکار SBOM با ابزارهای متن‌باز در CI و فعال‌کردن MFA روی همه مخازن کد و حساب‌های توسعه.
جمع‌بندی
امنیت زنجیره تأمین شرط لازم موفقیت هر پروژه بومی‌سازی است. سازمانی که می‌داند در محصولاتش چه اجزایی وجود دارد (SBOM)، منشأ هر مصنوع را می‌تواند ثابت کند (امضا و Provenance)، کیفیت قطعات و کتابخانه‌ها را می‌سنجد و تأمین‌کنندگانش را به‌طور منظم ممیزی می‌کند، استقلال فناوری واقعی به دست آورده است. بدون این کنترل‌ها، بومی‌سازی وابستگی را از یک نقطه به نقطه دیگری منتقل می‌کند که کمتر دیده می‌شود.
