گوگل با هدف بهبود دقت در ارزیابی وضعیت امنیتی دستگاه‌های اندرویدی، رویکرد سنتی تکیه بر یک تاریخ واحد برای به‌روزرسانی‌های امنیتی (Security Patch Level) را تغییر داده است. در این راستا، نسخه‌های پایدار کتابخانه‌های AndroidX Security State 1.1.0 و Security State Provider 1.0.0 منتشر شده‌اند تا به توسعه‌دهندگان و مدیران IT امکان بررسی دقیق‌تر وضعیت امنیتی دستگاه‌ها را بدهند.
چرا تاریخ Patch Level دیگر کافی نیست؟
در نسخه‌های مدرن اندروید، به‌روزرسانی‌ها از چندین مسیر مختلف ارسال می‌شوند؛ از جمله به‌روزرسانی‌های OTA توسط سازنده و به‌روزرسانی‌های سیستمی در پس‌زمینه از طریق Google Play. به دلیل این ساختار چندکاناله، یک تاریخ تقویمی واحد نمی‌تواند وضعیت واقعی امنیت دستگاه را منعکس کند. مهندسان گوگل معتقدند با تکامل اندروید به سمت سیستم‌های ماژولار، تکیه بر یک ویژگی SPL برای تعیین وضعیت امنیتی (Security Posture) دیگر بهینه نیست.
مکانیزم جدید ارزیابی امنیت
کتابخانه‌های جدید گوگل سه شاخص مجزا را ردیابی می‌کنند تا تصویری جامع از وضعیت دستگاه ارائه دهند:
- سیستم هسته اندروید (Core Android System)
- اجزای ماژولار (Modular Components) که از طریق Google Play به‌روزرسانی می‌شوند.
- کرنل لینوکس (Linux Kernel)
علاوه بر این، اپلیکیشن‌ها می‌توانند با بهره‌گیری از پایگاه داده Open Source Vulnerabilities، وضعیت CVEهای خاص را استعلام کنند. این قابلیت به نرم‌افزارهای حساس اجازه می‌دهد پیش از فعال‌سازی ویژگی‌هایی مانند Bluetooth یا NFC، بررسی کنند که آیا آسیب‌پذیری‌های مربوط به آن جزء خاص برطرف شده است یا خیر.
آینده و چالش‌های پیاده‌سازی
گوگل همچنین در اندروید 17 ویژگی جدیدی به نام Supplemental Patches XML را معرفی خواهد کرد که به سازندگان سخت‌افزار اجازه می‌دهد اصلاحات Backported را به‌صورت مجزا گزارش کنند، بدون اینکه نیاز باشد منتظر به‌روزرسانی ماهانه کل پلتفرم بمانند.
با این حال، کارآمدی این مدل به پذیرش آن توسط تولیدکنندگان تجهیزات اصلی (OEMs) بستگی دارد. تا زمانی که تمامی سازندگان از این سیستم Provider پشتیبانی نکنند، انتقال به بررسی‌های امنیتی جزئی (Granular Security Checks) در سراسر اکوسیستم اندروید به‌صورت یکپارچه نخواهد بود.
تاثیر بر مدیریت سازمانی
برای مدیران SOC و CISOها، این تغییر به معنای امکان تدوین سیاست‌های امنیتی بر اساس آسیب‌پذیری‌های خاص و اجزای درگیر است، نه صرفاً یک تاریخ کلی. به این ترتیب، دستگاهی که تاریخ Patch Level قدیمی دارد اما اصلاحیه مربوط به یک آسیب‌پذیری بحرانی را دریافت کرده است، دیگر به‌اشتباه به عنوان دستگاه ناامن شناسایی نخواهد شد.
