تاریخ رویداد یا اطلاعیهٔ اصلی: · این مطلب در تاریخ انتشار بالا تهیه شده است.
آنچه باید بدانید
- نتیجهٔ نامشخص یا تحلیل‌نشده به معنی امن بودن برنامه نیست.
- برای هر هشدار، محیط واقعی، مسئول اصلاح و زمان پیگیری را ثبت کنید.
- تغییر وابستگی و فایل قفل را پیش از انتشار در محیط آزمایشی بررسی کنید.
در اکتبر ۲۰۲۶ چه چیزی تغییر کرد؟
گیت‌هاب در ۲۸ اکتبر ۲۰۲۶ پیش‌نمایش عمومی تحلیل Reachability را برای مخزن‌های JavaScript و TypeScript روی Enterprise Cloud معرفی کرد. این قابلیت شواهد مسیر فراخوانی را کنار هشدار آسیب‌پذیری قرار می‌دهد. پیش‌نمایش فایروال بسته‌ها که در ۲۰ اکتبر معرفی شد، موضوع جداگانه‌ای است و نصب بسته‌های npm را کنترل می‌کند. اولی به ترتیب اصلاح کمک می‌کند و دومی پیش از نصب تصمیم می‌گیرد؛ شرایط دسترسی هر کدام را در اطلاعیهٔ اصلی بخوانید.
برای هر هشدار یک پروندهٔ تصمیم بسازید
فهرست طولانی هشدارها بدون شناخت نسخهٔ نصب‌شده ارزش عملی کمی دارد. نام سرویس، نسخهٔ بسته، شناسهٔ انتشار، فایل قفل، مسیر در معرض اینترنت، مسئول بررسی و مهلت اصلاح را کنار هم ثبت کنید. مشخص کنید بسته در محصول نهایی استفاده می‌شود یا فقط ابزار توسعه است. این تفاوت روی اولویت اثر دارد، ولی خطر مرحلهٔ ساخت را حذف نمی‌کند.
فرض را با مدرک اشتباه نگیرید. شاید صفحهٔ عمومی از یک پردازشگر استفاده نکند، اما کار واردسازی اطلاعات در پس‌زمینه همان کد را اجرا کند. مسئول آن بخش باید مسیر را بررسی کند. برای مورد فوری، مسئول محدودسازی موقت و مسئول انتشار اصلاح را هم‌زمان تعیین کنید.
نتیجهٔ تحلیل را درست تفسیر کنید
در مستندات گیت‌هاب چهار حالت قابل‌دسترسی، احتمالاً قابل‌دسترسی، غیرقابل‌دسترسی و تحلیل‌نشده وجود دارد. حالت احتمالی را مانند حالت قابل‌دسترسی بررسی کنید. نتیجهٔ غیرقابل‌دسترسی، هشدار را خودکار نمی‌بندد. تنظیمات محیط واقعی، مسیرهای غیرمستقیم و تفاوت نسخهٔ مستقر همچنان مهم هستند. اگر حساب شما این قابلیت را ندارد، بررسی اطلاعیه و آزمایش برنامه هنوز قابل انجام است.
اصلاح را قابل بررسی منتشر کنید
- تغییر بسته و فایل قفل را در یک شاخه ثبت کنید و راهنمای مهاجرت سازنده را بخوانید.
- آزمون‌ها و ساخت پروژه را اجرا کنید؛ سپس قابلیت آسیب‌دیده، ورود کاربر و کارهای پس‌زمینه را در محیط آزمایشی بررسی کنید.
- همان خروجی آزمایش‌شده را منتشر کنید؛ نصب دوبارهٔ وابستگی‌ها روی سرور اصلی می‌تواند خروجی متفاوتی بسازد.
- نسخهٔ مستقر، نتیجهٔ آزمایش و روش بازگشت را ثبت کنید. بسته شدن هشدار باید به اصلاح واقعی وصل باشد.
مرحلهٔ نصب را فراموش نکنید
بعضی خطرها هنگام نصب بسته ایجاد می‌شوند و به اجرای عادی برنامه وابسته نیستند. محیط ساخت را موقت و دسترسی آن را محدود نگه دارید. تغییر ناگهانی وابستگی‌ها باید پیش از دسترسی به اطلاعات تولید بررسی شود. سیاست تأخیر نصب نیز برای اصلاح فوری معتبر به مسیر استثنا نیاز دارد؛ دور زدن دائمی کنترل، نتیجهٔ مناسبی نیست.
از یک مخزن شروع کنید
ده هشدار قدیمی یک پروژه را انتخاب کنید و ببینید چند مورد مسئول، تصمیم مستند و اصلاح آزمایش‌شده دارند. ابهام‌های باقی‌مانده را در جلسهٔ انتشار بعدی مرور کنید. برای ادامه، راهنمای استقرار امن با GitHub Actions و مدیریت و تعویض کلیدهای API را بخوانید.
منابع و مطالعهٔ بیشتر
گزارش این مطلب بر پایهٔ منابع اصلی زیر است. توصیه‌های اجرایی، راهنمای عمومی کیاوا هستند و باید با شرایط پروژه تطبیق داده شوند.
تجربهٔ شما، ادامهٔ این مطلب.
پرسشی دارید یا این راهنما را امتحان کرده‌اید؟ تجربه‌تان را بنویسید.
این گفت‌وگو با شما شروع می‌شود.
پرسش خوب یا تجربهٔ کوتاه شما می‌تواند به خوانندهٔ بعدی کمک کند.
گفت‌وگو 0
تازه‌ترین دیدگاه‌ها