خبر آسیب‌پذیری Log4j باید با شناسه CVE، دامنه نسخه‌ها و شرایط بهره‌برداری خوانده شود. متن قبلی این صفحه از «آسیب‌پذیری جدید با امتیاز ۸.۵» و همه نسخه‌های پیش از ۲.۲۴.۱ سخن می‌گفت، بدون اینکه مرجع یا شناسه‌ای بدهد. این ادعا قابل اتکا نبود و در این بازنویسی حذف شده است. موضوع این راهنما روش بررسی اطلاعیه‌های واقعی Log4j و درس‌های مدیریت وابستگی است. برای تعیین وضعیت یک سامانه، آخرین اطلاعیه رسمی و نسخه دقیق کد در حال اجرا لازم است؛ یک عنوان خبری به تنهایی کافی نیست.
ابتدا محصول و ماژول را مشخص کنید
نام Log4j در یک گزارش ممکن است به کتابخانه، ماژول خاص یا بسته همراه یک محصول دیگر اشاره کند. صفحه امنیت Apache Logging Services اطلاعیه‌ها را با جزئیات منتشر می‌کند. به affected component، نسخه‌های درگیر و توضیح شرایط توجه کنید. حضور یک نام در فهرست وابستگی‌ها همیشه به معنی فعال‌بودن مسیر آسیب‌پذیر نیست. در مقابل، نبود آن در وابستگی مستقیم هم کافی نیست؛ برنامه ممکن است بسته را از طریق وابستگی غیرمستقیم یا فایل همراه محصول دریافت کرده باشد.
Log4Shell نام شناخته‌شده رخداد CVE-2021-44228 در سال ۲۰۲۱ است. این نام را نباید برای هر اطلاعیه بعدی Log4j استفاده کرد. آسیب‌پذیری‌های متفاوت می‌توانند به پیکربندی، Appender یا شرایط دسترسی متفاوتی وابسته باشند. اگر گزارش فقط می‌گوید «Log4j آسیب‌پذیر است»، توضیح لازم برای اقدام عملی را نداده است. نام CVE به شما امکان می‌دهد اطلاعیه ناشر، گزارش ابزار و تصمیم تیم را به یک مورد مشخص وصل کنید و از ترکیب چند رخداد جلوگیری کنید.
برای محصولی که از فروشنده دریافت شده، نسخه کتابخانه داخلی را با نسخه خود محصول اشتباه نگیرید. شماره انتشار یک سامانه ممکن است هیچ شباهتی به نسخه Log4j نداشته باشد. فروشنده باید وضعیت بسته داخلی و اصلاح منتشرشده را توضیح دهد. جایگزین‌کردن دستی یک JAR در محصول بسته‌بندی‌شده می‌تواند رفتار پشتیبانی‌شده را تغییر دهد. قبل از چنین اقدامی، مسیر اصلاح توصیه‌شده فروشنده و وابستگی‌های محصول را بخوانید. هدف، اصلاح کد در حال اجراست و صرف تغییر نام یک فایل این هدف را ثابت نمی‌کند.
نسخه واقعی کجا قرار دارد؟
فایل build فقط بخشی از تصویر است. ممکن است نسخه دیگری در فایل نهایی، container قدیمی یا مسیر کتابخانه‌های مشترک قرار گرفته باشد. برای بررسی، خروجی ساخته‌شده و محیط اجرا را هم در نظر بگیرید. برنامه‌های Java گاهی چند بسته را در یک فایل بزرگ کنار هم قرار می‌دهند و نام ساده فایل از محتویات داخلی خبر نمی‌دهد. موجودی شما باید مشخص کند کدام مؤلفه در کدام artifact و روی کدام سرویس نصب شده است، نه اینکه فقط یک ردیف نسخه در مخزن پیدا شود.
اگر چند تیم از یک base image استفاده می‌کنند، مالک آن تصویر را مشخص کنید. اصلاح برنامه بدون اصلاح تصویر پایه ممکن است نسخه قدیمی را در ساخت بعدی برگرداند. cache ساخت و محیط‌های آزمایشی نیز می‌توانند نسخه‌های متفاوتی نگه دارند. این مسئله بیشتر از جست‌وجوی یک کلمه در کد است؛ به زنجیره ساخت و انتشار مربوط می‌شود. برای هر مورد، مسیر دریافت، نسخه حل‌شده و محل اجرای نهایی را ثبت کنید تا بررسی‌های بعدی از ابتدا تکرار نشوند.
SBOM فهرست مؤلفه‌های نرم‌افزار است و به یافتن وابستگی‌ها کمک می‌کند. ارزش آن به کامل‌بودن و اتصال به خروجی واقعی بستگی دارد. فایلی که ماه‌ها پیش تولید شده و با artifact منتشرشده رابطه روشن ندارد، برای تعیین وضعیت امروز کافی نیست. SBOM را همراه شناسه خروجی، زمان ساخت و منبع تولید نگه دارید. از وجود آن نتیجه نگیرید که همه مؤلفه‌ها سالم‌اند؛ این سند موجودی است و تصمیم درباره ریسک به اطلاعیه و شرایط اجرا نیاز دارد.
شرایط بهره‌برداری را بخوانید
هر آسیب‌پذیری پیش‌شرط دارد. ممکن است مهاجم به داده ورودی دسترسی داشته باشد، امکان تغییر پیکربندی بخواهد یا مسیر خاصی باید فعال باشد. توضیح اطلاعیه را به معماری سرویس خود وصل کنید. اگر شرطی در سامانه برقرار نیست، آن را با دلیل ثبت کنید؛ اگر نامعلوم است، بررسی لازم را مشخص کنید. نتیجه «آسیب‌پذیر نیست» بدون بیان شرط و شاهد، برای بازبین بعدی قابل استفاده نیست. همین دقت از نتیجه‌گیری بی‌پشتوانه درباره همه سرورها جلوگیری می‌کند.
CVSS برای توصیف شدت بر پایه مجموعه‌ای از ویژگی‌هاست و اولویت محلی شما را به تنهایی تعیین نمی‌کند. سرویس عمومی که داده ناشناس می‌گیرد با ابزار داخلی محدود شرایط یکسانی ندارد. وجود داده حساس، مجوز فرایند و مسیر خروج شبکه هم روی پیامد اثر دارند. از امتیاز برای مرتب‌کردن بررسی اولیه استفاده کنید، سپس زمینه اجرا را اضافه کنید. پایین‌بودن امتیاز نباید موجب نادیده‌گرفتن یک مسیر حساس شود و بالابودن آن هم جای شناخت دامنه واقعی را نمی‌گیرد.
ابزار اسکن ممکن است فقط نسخه فایل را تشخیص دهد یا تحلیل بیشتری از مسیر اجرا انجام دهد. این دو نتیجه را هم‌ارز نگیرید. اگر یافته‌ای را False Positive می‌دانید، دلیل باید به مؤلفه، نسخه و شرایط آن اشاره کند. FAQ امنیت Apache درباره گزارش‌های رایج و نسبت‌دادن نادرست بعضی مشکلات توضیح دارد. پاسخ رسمی کمک می‌کند اختلاف را دقیق‌تر بررسی کنید، اما باز هم باید محیط خود را بشناسید و فقط با نام یک کلاس حکم کلی ندهید.
به‌روزرسانی باید به محیط اجرا برسد
برای اصلاح، نسخه پشتیبانی‌شده مناسب پروژه را از اطلاعیه رسمی انتخاب کنید. نیازمندی Java و تغییرات ناسازگار را هم بخوانید. جمله «به آخرین نسخه بروید» بدون شناخت محیط می‌تواند یک سرویس قدیمی را از کار بیندازد. اگر ارتقا به تغییر بزرگ‌تری وابسته است، مراحل آن را جدا تعریف کنید و راهکار موقت را دقیقاً مطابق توصیه معتبر بررسی کنید. تنظیمات قدیمی که زمانی برای یک CVE مطرح شده‌اند نباید بدون بررسی برای همه رخدادهای تازه کپی شوند.
تغییر فایل build باید به artifact تازه و استقرار آن منتهی شود. مشخص کنید چه خروجی ساخته شد، کدام سرویس آن را دریافت کرد و چه نسخه‌ای اکنون اجرا می‌شود. بازبودن یک Pull Request اصلاحی با رفع مشکل در تولید برابر نیست. اگر استقرار چند مرحله دارد، وضعیت هر مرحله را گزارش کنید. عبارت کوتاه «اصلاح شد» ممکن است باعث شود تیم عملیات پیگیری نسخه زنده را متوقف کند، در حالی که تغییر فقط در شاخه توسعه حاضر است.
اگر برنامه از محصول ثالث استفاده می‌کند، اطلاعیه فروشنده را نیز دنبال کنید. ممکن است نسخه اصلاحی در قالب بسته کامل عرضه شود و تغییر جداگانه کتابخانه پشتیبانی نشود. اگر تأمین‌کننده هنوز پاسخ نداده، وضعیت نامعلوم را در موجودی ثبت کنید و مسیر پیگیری داشته باشید. مالک کسب‌وکار باید از محدودیت آگاه باشد تا درباره کاهش دسترسی یا توقف موقت تصمیم بگیرد. برنامه اقدام روشن از یک فهرست طولانی هشدار که هیچ مسئول ندارد مفیدتر است.
حداقل دسترسی دامنه پیامد را کم می‌کند
فرایند ثبت لاگ نباید به همه رازها و همه مسیرهای سیستم دسترسی داشته باشد. اجرای برنامه با حساب محدود، جداسازی سرویس‌ها و محدودیت خروج شبکه می‌توانند پیامد بعضی رخدادها را کاهش دهند. این کنترل‌ها جای اصلاح کتابخانه را نمی‌گیرند. اگر مسیر آسیب‌پذیر باقی بماند، محدودیت محیط فقط بخشی از توان مهاجم را کم می‌کند. در گزارش ریسک، اصلاح علت و کنترل جبرانی را جدا بنویسید تا کسی محدودشدن دسترسی را با رفع کامل مسئله اشتباه نگیرد.
لاگ‌ها خودشان هم ممکن است داده حساس داشته باشند. توکن، رمز یا اطلاعات کامل مشتری را صرفاً برای راحتی عیب‌یابی ثبت نکنید. قالب رخداد را طوری طراحی کنید که شناسه پیگیری و علت خطا را بدهد، بدون اینکه راز عملیاتی در هر خط تکرار شود. هنگام حادثه، این تفاوت مهم است: اگر مهاجم به فایل لاگ برسد، حجم داده موجود تعیین می‌کند چه چیزی افشا می‌شود. نگهداری و دسترسی به لاگ بخشی از طراحی امنیت برنامه است.
رفع آسیب‌پذیری با پاسخ به حادثه فرق دارد
اگر احتمال اجرای مخرب وجود دارد، صرف ارتقای کتابخانه برای بستن گزارش حادثه کافی نیست. باید زمان مواجهه، رخدادهای مشکوک و داده‌های در دسترس بررسی شوند. نصب نسخه اصلاحی مسیر آینده را تغییر می‌دهد، اما درباره آنچه پیش از نصب رخ داده چیزی ثابت نمی‌کند. تیم باید میان آسیب‌پذیری موجود، تلاش مشاهده‌شده و بهره‌برداری تأییدشده فرق بگذارد. گزارش دقیق این سطح‌ها از ایجاد اطمینان کاذب و از بزرگ‌نمایی بی‌دلیل جلوگیری می‌کند.
رازهایی که ممکن است افشا شده باشند باید با فرایند مناسب لغو و جایگزین شوند. شواهد لازم را طبق سیاست تیم نگه دارید و بررسی را از محیط قابل اعتماد انجام دهید. برای گزارش مدیریتی، نام سرویس، بازه زمانی و اقدامات انجام‌شده را با محدودیت‌های بررسی بنویسید. اگر بخشی از داده هنوز در دسترس نیست، آن را صریح ثبت کنید. چنین گزارشی به تصمیم بعدی کمک می‌کند؛ جمله‌های کلی درباره «امنیت کامل» قابل دفاع نیستند و مسیر پیگیری را مبهم می‌کنند.
برای آمادگی، یک فهرست کوتاه از سرویس‌ها، مالک آن‌ها و محل artifact بسازید و راه دریافت اطلاعیه مؤلفه‌های مهم را مشخص کنید. مقاله امنیت زنجیره تأمین npm درباره کنترل وابستگی‌ها در اکوسیستم دیگری توضیح می‌دهد و Code Review مؤثر به ثبت دلیل تغییر کمک می‌کند. وقتی خبر بعدی رسید، شناسه CVE را به این موجودی وصل کنید و وضعیت نسخه زنده را تعیین کنید؛ این نخستین اقدام مشخص و قابل گزارش است.
هنوز دیدگاهی ثبت نشده
اولین نفری باشید که نظر می‌دهد!