تصور کنید هر روز با صدها هشدار امنیتی مواجه شوید که نیمی از آن‌ها اصلاً در سیستم شما فعال نیستند. این کابوسِ روزمره برای تیم‌های امنیت و SREهاست که در سیل گزارش‌های آسیب‌پذیری غرق شده‌اند.
به نقل از فابیان کامِل (Fabian Kammel)، فرآیند فعلی شناسایی و اولویت‌بندی (Triage) آسیب‌پذیری‌ها به‌شدت ناکارآمد است؛ زیرا بر اساس اسکن‌های ایستا از لیست مواد نرم‌افزاری (SBOM) — شبیه به فهرست مواد تشکیل‌دهنده روی بسته‌بندی غذا که لزوماً نمی‌گوید کدام ماده در لحظه اثر می‌کند — انجام می‌شود. این یعنی حتی اگر کدی آسیب‌پذیر باشد اما هرگز در زمان اجرا فراخوانی نشود، باز هم هشدار صادر می‌شود. این شکست سیستماتیک باعث شده تا تیم‌های امنیتی در سیل گزارش‌های آسیب‌پذیری تولید شده توسط LLMها غرق شوند؛ گزارش‌هایی که اغلب فاقد قابلیت بهره‌برداری (Exploitability) در دنیای واقعی هستند.
این مشکل برای مدیران سیستم (SysAdmins)، مهندسان قابلیت اطمینان سایت (SREs) و تیم‌های AppSec به نقطه بحرانی رسیده است، چرا که آن‌ها مجبورند هر روز تک‌تک CVEهای جدیدی که ظاهر می‌شوند را به‌صورت دستی ارزیابی کنند. طبق گزارش‌های فنی، اکثر سازمان‌ها از یک خط لوله ساده استفاده می‌کنند: ابتدا یک SBOM تولید می‌کنند، آن را با ابزارهایی مثل Grype اسکن می‌کنند و سپس ساعت‌ها وقت صرف می‌کنند تا بفهمند آیا یک هشدار با شدت «بالا» (High) واقعاً در محیط خاص آن‌ها خطرناک است یا خیر. این فشار روانی و کاری حتی متصوب‌کنندگان پروژه‌های متن‌باز را نیز درگیر کرده است؛ بسیاری از آن‌ها سرعت توسعه ویژگی‌های جدید را کاهش داده‌اند تا صرفاً بر روی شناسایی و اولویت‌بندی آسیب‌پذیری‌ها تمرکز کنند.
برای حل این معضل، صنعت به سمت تبادل قابلیت بهره‌برداری از آسیب‌پذیری (VEX - Vulnerability Exploitability eXchange) حرکت کرده است. یک سند VEX در واقع یک اطلاعیه امنیتی ماشین‌خوان است که صراحتاً به کاربر می‌گوید آیا یک محصول نرم‌افزاری خاص واقعاً در برابر یک آسیب‌پذیری شناخته‌شده در معرض خطر است یا خیر. اما چالش اصلی این است: آیا می‌توان این بیانیه‌ها را به‌صورت خودکار تولید کرد تا از یک فرآیند شناسایی مقیاس‌پذیر پشتیبانی شود؟
برای درک بهتر، یک برنامه Go را در نظر بگیرید که از کتابخانه golang.org/x/text نسخه ۰.۳۸.۰ استفاده می‌کند. یک اسکن استاندارد با استفاده از Syft برای تولید SBOM در قالب JSON (استاندارد CycloneDX) و سپس اسکن آن با Grype، دو آسیب‌پذیری با شدت بالا را گزارش می‌دهد: مورد GO-2026-5970 با امتیاز EPSS 0.5% و مورد GO-2026-6629 با امتیاز EPSS 0.3%. اما یک تحلیل دسترسی (Reachability Analysis) فاش می‌کند که آسیب‌پذیری اول فقط در بسته golang.org/x/text/unicode/norm و آسیب‌پذیری دوم فقط در بسته golang.org/x/text/secure/precis وجود دارد. از آنجایی که برنامه شما اصلاً از این بسته‌ها استفاده نمی‌کند، در عمل آسیب‌پذیر نیست.
در حالی که ابزارهایی مثل govulncheck این کار را برای زبان Go خودکار می‌کنند — از طریق تحلیل ایستا و استفاده از پایگاه داده آسیب‌پذیری‌های Go برای بررسی مسیرهای Import و نمادهای (Symbols) متأثر — اما این فرآیند وقتی در سطح کل سیستم‌عامل اعمال شود، به‌طور کامل شکست می‌خورد.
شکست شناسایی در سطح سیستم‌عامل
وقتی یک کانتینر داکر مبتنی بر دبیان (به‌طور خاص نسخه debian:trixie) اسکن می‌شود، یک اسکن واحد می‌تواند صدها مورد تطابق برگرداند. بر اساس مستندات کامِل در ۱۱ اکتبر ۲۰۲۶، اسکن یک سرور OpenSSH منجر به شناسایی ۲۸۴ مورد آسیب‌پذیری شد. تفکیک این موارد بر اساس شدت به این صورت بود: ۳ مورد بحرانی (Critical)، ۶۵ مورد بالا (High)، ۸۰ مورد متوسط (Medium)، ۳۹ مورد پایین (Low) و ۹۷ مورد ناچیز (Negligible). نکته قابل توجه این بود که هر ۲۸۴ مورد در وضعیت «اصلاح‌نشده» (not-fixed) لیست شده بودند.
به‌عنوان مثال، آسیب‌پذیری CVE-2007-2768 از سال ۲۰۰۷ در منبع اصلی (Upstream) اصلاح نشده است. این آسیب‌پذیری به مهاجم اجازه می‌دهد اگر sshd از رمزهای یک‌بار مصرف OPIE از طریق PAM استفاده کند، متوجه شود که آیا یک نام کاربری در سیستم وجود دارد یا خیر. برای اینکه یک مهندس بفهمد آیا این مورد واقعاً یک ریسک است، باید یک ممیزی دستی دقیق انجام دهد:
- بررسی تنظیمات SSHD: اجرای دستور
sshd -Tبرای تایید اینکهusepamروی yes است، اماkbdinteractiveauthenticationروی no تنظیم شده باشد (زیرا این تنها راهی است کهsshdدرخواست را به PAM می‌سپارد). - بازرسی قوانین PAM: جست‌وجو (Grep) در فایل‌های
/etc/pam.d/sshdو/etc/pam.d/common-authبرای اطمینان از اینکه هیچ ماژولopieپیکربندی نشده است. - تایید باینری‌ها: استفاده از دستورات
findوdpkg -lبرای تایید اینکه هیچ فایلی با الگویpam_opie*روی سیستم وجود ندارد.
انجام این تاییدات دستی برای ۲۸۳ مورد دیگر، هر بار که یک پیکربندی تغییر می‌کند، برای یک تیم انسانی از نظر ریاضی غیرممکن است. این وضعیت منجر به ایجاد «بدهی شناسایی» (Triage Debt) می‌شود؛ جایی که وصله‌های حیاتی به دلیل دفن شدن زیر کوهی از هشدارهای بی‌ربط، نادیده گرفته می‌شوند. در حالی که این روش بر مدیریت گزارش‌ها تمرکز دارد، برخی راهکارهای پیشرفته‌تر تلاش می‌کنند حفره‌های امنیتی هسته لینوکس را بدون نیاز به بازراه‌اندازی سیستم خنثی کنند تا تداوم سرویس حفظ شود.
مکانیزم NixOS
سیستم‌عامل NixOS با تبدیل کل پیکربندی سیستم به کد، این بازی را تغییر می‌دهد. چون وضعیت سیستم در NixOS توصیفی (Declarative) است — یعنی در یک فایل پیکربندی .nix و یک Flake تعریف می‌شود — شرایط امنیتی را می‌توان مستقیماً در تعریف سیستم کدنویسی کرد.
کامِل ابزار nixos-vex را معرفی کرده است که اجازه می‌دهد بیانیه‌های VEX شرطی ایجاد کنید. در اینجا VEX دیگر یک فایل متنی ایستا نیست، بلکه تابعی از پیکربندی سیستم است. منطق این ابزار در زبان Nix نوشته شده و سیستم به‌طور پویا وضعیت یک CVE را بر اساس بیلد (Build) واقعی تعیین می‌کند:
- حضور بسته: سیستم بررسی می‌کند آیا بسته
opieدر Nix store وجود دارد یا خیر (!(pkgs ? opie)). - پرچم‌های پیکربندی: بررسی می‌کند که آیا
services.openssh.settings.KbdInteractiveAuthenticationرویfalseتنظیم شده است. - تحلیل قوانین PAM: از تابع
lib.anyاستفاده می‌کند تا تمام قوانین PAM را برای سرویسsshdاسکن کند و مطمئن شود هیچmodulePathای شامل رشته «opie» نیست.
اگر این شرایط برقرار باشد، سیستم به‌طور خودکار یک فایل VEX JSON (مطابق با استاندارد openvex.dev/ns/v0.2.0) تولید می‌کند و آن CVE را با دلیل «عدم حضور کد آسیب‌پذیر» (vulnerable_code_not_present) به عنوان not_affected علامت‌گذاری می‌کند.
یکپارچه‌سازی شناسایی خودکار
این فرآیند، خط لوله امنیتی را از یک ممیزی دستی به یک بررسی CI/CD تبدیل می‌کند. با استفاده از sbomnix برای تولید SBOM و اتصال آن به فید VEX خودکار، نویزها فوراً فیلتر می‌شوند.
در مثال OpenSSH، روند یکپارچه‌سازی به این شکل است:
۱. فایل VEX با استفاده از دستور nix build ساخته می‌شود.
۲. مسیر خروجی حاصل از طریق پرچم --vex به ابزار Grype پاس داده می‌شود.
۳. ابزار Grype به‌طور هم‌زمان SBOM و فایل VEX را پردازش می‌کند.
در این مورد خاص، تعداد آسیب‌پذیری‌ها از ۲۷۲ مورد به ۲۷۱ کاهش یافت، زیرا CVE شناسایی‌شده با موفقیت نادیده گرفته شد. هزینه بررسی مجدد آسیب‌پذیری پس از هر تغییر در پیکربندی تقریباً به صفر می‌رسد، زیرا منطق بررسی در فرآیند بیلد Nix تعبیه شده و توسط زیرساخت CI مدیریت می‌شود.
تغییر پارادایم امنیتی
این رویکرد، بار اثبات را از دوش ممیز امنیتی به پیکربندی سیستم منتقل می‌کند. وقتی یک CVE شناسایی و منطق آن کدنویسی شد، این دانش برای تمام ماشین‌هایی که از آن پیکرباری استفاده می‌کنند، برای همیشه حفظ می‌شود.
برای کل صنعت، این به معنای حرکت از «وصله زدن کورکورانه» (Blind Patching) — که در آن تیم‌ها هر کتابخانه‌ای را بدون توجه به میزان استفاده به‌روز می‌کنند — به سمت «وصله زدن مبتنی بر دسترسی» (Reachability-based Patching) است. این کار باعث کاهش زمان توقف سیستم (Downtime) و جلوگیری از بروز خطاهای رگرسیون (Regressions) ناشی از به‌روزرسانی‌های غیرضروری می‌شود. همچنین به تیم‌ها اجازه می‌دهد ابزارهایی مثل Dependabot را برای برخی اجزا خاموش کنند و تنها زمانی وصله بزنند که یک آسیب‌پذیری واقعاً قابل دسترسی باشد.
با این حال، این روش نیازمند اعتماد بالا به منطق کدنویسی شده است. کامِل اشاره می‌کند که nixos-vex هنوز نباید به عنوان یک منبع داده با اعتماد بسیار بالا (High-trust) استفاده شود، بلکه بیشتر نقش یک نقشه راه (Blueprint) برای مدیریت مقیاس‌پذیر آسیب‌پذیری‌ها در اکوسیستم Nix را دارد. هدف او به اشتراک گذاشتن این فرآیند و در نهایت کمک به ادغام این قابلیت‌ها در اکوسیستم گسترده‌تر Nix است.
برای پیاده‌سازی این رویکرد، تیم‌ها باید با شناسایی متداول‌ترین CVEهای «مثبت کاذب» در زیرساخت خود شروع کنند و سپس تلاش کنند پرچم‌های پیکربندی خاصی که این آسیب‌پذیری‌ها را بی‌اثر می‌کند، نقشه‌برداری نمایند.
گام بعدی شما
- شناسایی متداول‌ترین CVEهای «مثبت کاذب» در زیرساخت خود را شروع کنید.
- پرچم‌های پیکربندی خاصی که این آسیب‌پذیری‌ها را بی‌اثر می‌کند، نقشه‌برداری کنید.
- اگر از NixOS استفاده می‌کنید، ابزار nixos-vex را برای خودکارسازی این منطق در خط لوله CI/CD تست کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره تراشه‌های Blackwell مراجعه کنید.
گفتگو