کتابخونههای EOL دیگه فقط بدهی فنی نیستن
خلاصهٔ کاملتر
به گفتهٔ نویسنده، دورهای که انطباق (compliance) کار تیم GRC بود و توسعهدهنده فقط کد میداد تموم شده. تو این وایتپیپر بیست استاندارد، چارچوب و مقررات امنیتی مرور شده و ادعای مرکزیش اینه که تقریباً همهشون روی سه اصل مشترک همگرا شدن: نگه داشتن فهرست دقیق اجزای نرمافزار (بهشکل SBOM)، رفع آسیبپذیریهای شناختهشده تو یه بازهٔ تعریفشده که برای موارد بحرانی معمولاً ۳۰ روز یا کمتره، و داشتن یه فرایند مستند و تکرارپذیر برای شناسایی و اولویتبندی و رفع.
حرف اصلی مقاله اینه که نرمافزار end-of-life این سه تا رو ذاتاً نقض میکنه. وقتی یه فریمورک یا رانتایم دیگه وصلهٔ امنیتی نمیگیره، هر CVE بعدی برای همیشه بیوصله میمونه. مثال خود مقاله PCI DSS ـه: بند ۶.۳.۳ یک ماه وقت میده تا وصلهٔ بحرانی نصب بشه، ولی این بند فرض کرده وصلهای وجود داره؛ روی یه فریمورک منسوخ، عمل کردن بهش از اساس غیرممکنه. بند ۱۲.۳.۴ هم مرور سالانهٔ فناوریها و رصد تاریخ EOL رو الزامی کرده.
تو بخش آمریکا، نویسنده HIPAA رو مثال میزنه که متنش اسمی از EOL نبرده ولی «معقول و مناسب» بودن تدابیر رو میخواد؛ و میگه بعد از یه نشت داده، دفاع از یه کامپوننت بدون پشتیبانی با CVE شناختهشده تقریباً غیرممکنه. FedRAMP و کنترل SI-2 مهلتهای ۳۰، ۹۰ و ۱۸۰ روزه دارن که هر اسکن ماهانه دوباره همون یافته رو تولید میکنه. تو CMMC و NIST SP 800-171 هم بند «رفع بهموقع نقصها» استثنایی برای پروژههای مرده نداره، و قواعد افشای SEC بحث رو به سطح ریسک مادی و دعوای حقوقی میبره.
سمت اروپا لحن صریحتره. DORA مستقیم گفته فهرست داراییهای ICT باید داراییهای نزدیک به پایان عمر رو ردیابی کنه و سیستمهای legacy مستند و برنامهریزی بشن. NIS2 تو مادهٔ ۲۱ رسیدگی به آسیبپذیری و امنیت زنجیرهٔ تأمین رو الزام قانونی کرده، مهلتهای گزارش حادثه ۲۴ و ۷۲ ساعته گذاشته و جریمهها رو تا ۱۰ میلیون یورو یا ۲ درصد گردش مالی جهانی برده، با مسئولیت شخصی برای مدیران. GDPR هم با معیار «state of the art» تو مادهٔ ۳۲ همین نتیجه رو میده. تو کانادا هم CCSPA با جریمه تا ۱۵ میلیون دلار کانادا و مسئولیت شخصی مدیران داره فاز به فاز اجرا میشه.
توصیههای عملی مقاله برای توسعهدهندهها کمابیش همهجا یکیه: SBOM رو تو CI و روی هر ریلیز بساز نه تو اکسل، تاریخ EOL هر فریمورک و رانتایم رو مثل یه ددلاین انطباق ببین نه آیتم بکلاگ، و هر کامپوننت رو تو یکی از سه حالت روشن بذار؛ یا بالادست نگهداریش میکنه، یا از رده خارج و جایگزین میشه، یا از یه مسیر پشتیبانی تجاری وصله میگیره. نویسنده تأکید میکنه تصمیم ریسک رو همون موقع مکتوب کن، چون بعد از حادثه همون مستندات بهترین دفاعه. البته یادمون باشه خود هیرودِوز تو کار فروش همین پشتیبانی توسعهیافتهست، پس این توصیهٔ آخر منافع خودشم هست.
نکات کلیدی:
- تقریباً همهٔ چارچوبهای امنیتی سه چیز میخوان: فهرست اجزا، رفع آسیبپذیری تو مهلت مشخص، فرایند مستند
- نرمافزار EOL چون دیگه وصله نمیگیره، این مهلتها رو از اساس غیرقابلاجرا میکنه
- PCI DSS یک ماه برای وصلهٔ بحرانی و FedRAMP مهلتهای ۳۰/۹۰/۱۸۰ روزه گذاشتن
- DORA و NIS2 صریحاً سراغ ردیابی EOL و امنیت زنجیرهٔ تأمین رفتن، با مسئولیت شخصی مدیران
- SBOM خودکار تو CI و رصد تاریخ EOL وابستگیها، ارزونترین کاریه که تیم مهندسی میتونه بکنه
