گوگل با OSS Rebuild امنیت پکیج‌های اوپن‌ سورس را افزایش می‌دهد

معرفی OSS Rebuild: پروژه‌ای برای بازسازی اعتماد

در همین راستا، پروژه جدیدی به اسم OSS Rebuild معرفی شده که هدفش تقویت اعتماد در اکوسیستم پکیج‌های متن بازه. این کار با بازتولید مستقل پکیج‌های اصلی (upstream artifacts) انجام میشه. وقتی حملات زنجیره تامین، وابستگی‌های پرکاربرد رو هدف قرار میدن، OSS Rebuild به تیم‌های امنیتی اطلاعات قدرتمندی میده تا بدون اینکه باری روی دوش نگهدارنده‌های اصلی پروژه‌ها بیفته، از این خطرات جلوگیری کنن.

این پروژه چند تا بخش اصلی داره:

• اتوماسیون: برای استخراج تعریف‌های ساخت (build definitions) برای پکیج‌های موجود در PyPI (پایتون)، npm (جاوا اسکریپت/تایپ اسکریپت) و Crates.io (راست).
• SLSA Provenance: برای هزاران پکیج در این اکوسیستم‌ها، گواهی اصالت یا «Provenance» تولید میشه که با نیازمندی‌های سطح سوم ساخت SLSA (یا همون SLSA Build Level 3) مطابقه، اونم بدون اینکه ناشر پکیج نیاز به دخالتی داشته باشه.
• ابزارهای مشاهده و تایید ساخت: تیم‌های امنیتی میتونن این ابزارها رو با گردش‌کارهای مدیریت آسیب پذیری فعلی خودشون ترکیب کنن.
• تعاریف زیرساخت: به سازمان‌ها اجازه میده تا نمونه‌های شخصی خودشون از OSS Rebuild رو اجرا کنن تا بتونن گواهی اصالت رو بازسازی، تولید، امضا و توزیع کنن.

هدف OSS Rebuild اینه که با شفاف کردن مصرف پکیج‌ها، به جامعه امنیتی قدرت بده تا زنجیره تامین خودشون رو عمیقا درک و کنترل کنن؛ درست مثل وقتی که از یک مخزن کد منبع (source repository) استفاده میکنن. این شفافیت از طریق یک فرایند ساخت اعلانی (declarative)، ابزارهای نظارتی بر ساخت و قابلیت‌های مانیتورینگ شبکه به دست میاد که در چارچوب SLSA، متادیتاهای امنیتی دقیق، بادوام و قابل اعتمادی تولید میکنه.

این پروژه از مدل زیرساخت میزبانی شده‌ای استفاده میکنه که قبلا در OSS-Fuzz برای شناسایی مشکلات حافظه به کار گرفته شده بود. OSS-Fuzz با استفاده از منابع میزبانی شده، چالش‌های امنیتی در نرم افزارهای متن باز رو حل میکنه و OSS Rebuild هم با همین رویکرد، این بار برای امن کردن زنجیره تامین نرم افزار تلاش میکنه. جالبه بدونید که OSS-Fuzz تا ماه می ۲۰۲۵ به شناسایی و رفع بیش از ۱۳ هزار آسیب پذیری و ۵۰ هزار باگ در ۱۰۰۰ پروژه کمک کرده.

چطور کار میکنه؟

این سیستم با استفاده از اتوماسیون و روش‌های ابتکاری، یک تعریف ساخت احتمالی برای پکیج مورد نظر پیدا و اون رو بازسازی میکنه. بعد، نتیجه رو به صورت معنایی با فایل اصلی مقایسه میکنه و هر دو رو نرمال سازی میکنه تا ناپایداری‌هایی که باعث شکست مقایسه بیت به بیت میشن (مثل فشرده سازی آرشیو) حذف بشن. وقتی پکیج بازتولید شد، تعریف ساخت و نتیجه اون از طریق SLSA Provenance منتشر میشه. این گواهی به مصرف کننده‌ها اجازه میده تا به طور قابل اعتمادی منشا پکیج رو در تاریخچه کد منبع تایید کنن، فرایند ساختش رو بفهمن و تکرارش کنن و حتی اون رو برای تولید SBOM های دقیق‌تر به کار ببرن.

با اتوماسیون فعلی OSS Rebuild برای PyPI، npm و Crates.io، بیشتر پکیج‌ها بدون نیاز به دخالت کاربر یا نگهدارنده پروژه، محافظت میشن. جاهایی که اتوماسیون فعلا نمیتونه پکیج رو کامل بازتولید کنه، امکان تعریف دستی مشخصات ساخت وجود داره تا کل جامعه از مشارکت افراد سود ببره.

حتی استفاده از هوش مصنوعی هم برای بازتولید پکیج‌ها در حال بررسیه. فرایندهای ساخت و انتشار معمولا در مستندات به زبان عادی توضیح داده شدن که استفاده از اونها با منطق گسسته سخته، اما برای مدل‌های زبانی روز به روز کاربردی‌تر میشه. آزمایش‌های اولیه نشون داده که این رویکرد برای خودکارسازی اکتشاف و تست، حتی در پیچیده‌ترین ساخت‌ها، با دخالت محدود انسان، عملیه.

این سیستم چه مشکلاتی رو شناسایی میکنه؟

OSS Rebuild میتونه چند دسته از حملات زنجیره تامین رو شناسایی کنه:

• کد منبعی که ثبت نشده (Unsubmitted Source Code): وقتی پکیج‌های منتشر شده کدی دارن که در مخزن کد منبع عمومی وجود نداره، OSS Rebuild برای اون فایل گواهی صادر نمیکنه.
  • مثال واقعی: حمله به solana/webjs در سال ۲۰۲۴. در این حمله، نسخه‌های آلوده به بدافزار از کتابخونه جاوا اسکریپتی پرکاربرد @solana/web3.js از طریق رجیستری npm توزیع شد. یک حساب کاربری @solana که دسترسی انتشار داشت، هک شد و ازش برای اضافه کردن کد مخرب استفاده شد.
• محیط ساخت به خطر افتاده (Build Environment Compromise): با ایجاد محیط‌های ساخت استاندارد و حداقلی با نظارت جامع، OSS Rebuild میتونه فعالیت‌های مشکوک در حین ساخت رو شناسایی کنه یا از ابتدا از قرار گرفتن در معرض اجزای آلوده جلوگیری کنه.
  • مثال واقعی: حمله به tj-actions/changed-files در سال ۲۰۲۵. در این حمله، این اکشن محبوب گیت‌هاب دستکاری شد و باعث شد مخازن عمومی که ازش استفاده میکردن، اطلاعات حساسشون (secrets) رو در لاگ‌ها فاش کنن.
• بک‌دورهای مخفی (Stealthy Backdoors): حتی بک‌دورهای پیچیده‌ای مثل بک‌دور xz هم اغلب الگوهای رفتاری غیرعادی در حین ساخت نشون میدن. قابلیت‌های تحلیل دینامیک OSS Rebuild میتونه مسیرهای اجرایی غیرمعمول یا عملیات مشکوکی رو که شناسایی اونها با بررسی دستی غیرعملیه، تشخیص بده.
  • مثال واقعی: حمله به xz-utils در سال ۲۰۲۴.

چه کسانی از OSS Rebuild سود میبرن؟

برای شرکت‌ها و متخصصان امنیت:

• بهبود متادیتا بدون تغییر رجیستری: اطلاعات پکیج‌های اصلی رو غنی میکنه بدون اینکه نیازی به نگهداری رجیستری‌های سفارشی یا مهاجرت به اکوسیستم جدیدی باشه.
• تکمیل SBOM: با اضافه کردن اطلاعات دقیق نظارت بر ساخت به لیست مواد نرم افزاری (SBOM)، تصویر امنیتی کامل‌تری ایجاد میکنه.
• تسریع واکنش به آسیب پذیری: مسیری برای فروش، پچ کردن و میزبانی مجدد پکیج‌های اصلی با استفاده از تعاریف ساخت قابل تایید فراهم میکنه.

برای ناشران و نگهدارندگان پکیج‌های متن باز:

• تقویت اعتماد به پکیج: به مصرف کننده‌ها تایید مستقلی از یکپارچگی ساخت پکیج‌ها میده، صرف نظر از اینکه ساخت اصلی چقدر پیچیده بوده.
• بازسازی یکپارچگی پکیج‌های قدیمی: برای پکیج‌های قدیمی هم گواهی‌های ساخت با کیفیت بالا تولید میکنه، حتی اگه در زمان انتشار اونها چنین چیزی پشتیبانی نمیشده.
• کاهش حساسیت امنیتی CI: به ناشران اجازه میده روی کار اصلی توسعه تمرکز کنن. با انجام بازسازی‌های جداگونه، محیط CI دیگه برای امنیت پکیج‌ها حیاتی نیست.

نگاهی به تلاش‌های دیگر در حوزه امنیت زنجیره تامین

البته OSS Rebuild تنها تلاش در این زمینه نیست. جامعه امنیتی با طرح‌هایی مثل Security Scorecard، Trusted Publishers در PyPI و پشتیبانی بومی npm از SLSA به این چالش‌ها پاسخ داده. اما هیچکدوم از اینها راه حل نهایی نیستن. هر کدوم روی جنبه خاصی از مشکل تمرکز میکنن و اغلب مصالحه‌هایی مثل انتقال کار به ناشران و نگهدارنده‌ها دارن.

• SecurityScorecard: این پلتفرم به تیم‌های مدیریت ریسک شخص ثالث (TPRM) و مرکز عملیات امنیت (SOC) کمک میکنه تا ریسک فروشنده‌ها رو در کل اکوسیستم تامین کننده شناسایی، اولویت بندی و برطرف کنن. این ابزار به جای ارزیابی‌های ثابت، روی پاسخ‌دهی در لحظه تمرکز میکنه.
• Trusted Publishers در PyPI: نگهدارنده‌های پکیج در PyPI میتونن از روش انتشار امن‌تری به نام «Trusted Publishing» استفاده کنن که نیازی به رمزهای عبور طولانی مدت یا توکن‌های API نداره. این روش از استاندارد OpenID Connect (OIDC) برای تبادل توکن‌های هویتی کوتاه مدت بین یک سرویس شخص ثالث مورد اعتماد (مثل گیت‌هاب اکشنز) و PyPI استفاده میکنه.
• Package Provenance در npm: حالا میشه موقع ساخت پروژه‌های npm در گیت‌هاب اکشنز، با اضافه کردن فلگ --provenance، گواهی اصالت رو هم همراه پکیج منتشر کرد. این داده‌های اصالت به مصرف کننده‌ها راهی قابل تایید میده تا پکیج رو به مخزن کد منبع و دستورالعمل‌های ساخت مشخصش مرتبط کنن.

چارچوب SLSA: ستون فقرات اعتماد

پروژه OSS Rebuild و ابتکاراتی مثل Package Provenance در npm به شدت به چارچوبی به نام SLSA (Supply-chain Levels for Software Artifacts) متکی هستن. SLSA به صورت مجموعه‌ای از سطوح امنیتی سازماندهی شده که تضمین‌های فزاینده‌ای برای امنیت زنجیره تامین ارائه میده.

این سطوح در مسیرهای مختلفی تقسیم میشن. فعلا تمرکز اصلی روی مسیر ساخت (Build Track) هست:

مسیر/سطح	نیازمندی‌ها	تمرکز
Build L0	(هیچی)	(بدون تضمین)
Build L1	وجود گواهی اصالت (Provenance) که نشون میده پکیج چطور ساخته شده	اشتباهات، مستندسازی
Build L2	گواهی اصالت امضا شده که توسط یک پلتفرم ساخت میزبانی شده تولید شده	دستکاری بعد از ساخت
Build L3	پلتفرم ساخت مستحکم شده	دستکاری در حین ساخت

OSS Rebuild گواهی‌هایی تولید میکنه که با SLSA Build Level 3 مطابقت دارن. این یعنی پلتفرم ساخت کنترل‌های قوی داره تا از تاثیرگذاری اجراهای مختلف روی هم جلوگیری کنه و اجازه نده اطلاعات حساس مورد استفاده برای امضای گواهی اصالت، در دسترس مراحل ساخت تعریف شده توسط کاربر قرار بگیره.

چطور از OSS Rebuild استفاده کنیم؟

ساده‌ترین راه برای دسترسی به گواهی‌های OSS Rebuild، استفاده از رابط خط فرمان مبتنی بر Go هست.

# نصب ابزار
$ go install github.com/google/oss-rebuild/cmd/oss-rebuild@latest

# مشاهده نسخه‌های موجود برای یک پکیج
$ oss-rebuild list pypi absl-py

# دریافت گواهی اصالت برای یک نسخه خاص
$ oss-rebuild get cratesio syn 2.0.39

# یا حتی بازسازی پکیج برای خودتون
$ oss-rebuild get npm lodash 4.17.20 --output=dockerfile | \
docker run $(docker buildx build -q -)

گواهی‌ها در یک فرمت مبتنی بر استاندارد ذخیره میشن و به صورت سلسله مراتبی در یک فضای ذخیره سازی (bucket) سازماندهی شدن:

gs://{bucket}/{ecosystem}/{package}/{version}/{artifact}/rebuild.intoto.jsonl

این گواهی‌ها رو میشه مستقیما از Google Cloud Storage هم با ابزاری مثل gsutil دریافت کرد. به طور پیش فرض، باکت ذخیره سازی گوگل عمومی هست و بدون نیاز به احراز هویت GCP قابل استفاده است.

ارتباط SLSA Provenance و SBOM

خیلی‌ها میپرسن که SLSA Provenance چه ارتباطی با SBOM (Software Bill of Materials) داره. SBOM معمولا روی درک نرم افزار برای ارزیابی ریسک از طریق آسیب پذیری‌های شناخته شده و انطباق با مجوزها تمرکز داره. اما SLSA Provenance و مسیر ساخت اون، روی اعتبار فرایند ساخت تمرکز دارن.

این دو در سطوح مختلفی از انتزاع کار میکنن. داده‌های دقیق در یک SBOM معمولا اجزای موجود در یک محصول نهایی رو توصیف میکنن، در حالی که SLSA Provenance به صورت کلی‌تر، پارامترهای یک ساخت رو که خارج از پلتفرم ساخت هستن، توصیف میکنه. در واقع، SLSA Provenance میتونه با توصیف نحوه ایجاد یک SBOM، اعتبار اون رو افزایش بده.