چرا دریافت فهرست به معنای قابل استفاده بودن آن نیست
یک شرکت فرضی را در نظر بگیرید که نرم‌افزار مدیریت کنترل تردد می‌خرد. به درخواست تیم امنیت، یک جمله به قرارداد افزوده شد: «تأمین‌کننده باید فهرست اجزای نرم‌افزار ارائه دهد.» هنگام راه‌اندازی، تأمین‌کننده یک صفحه‌گسترده فرستاد که نام چند ده جزء را فهرست کرده بود، بدون شماره نسخه و بدون اشاره به این‌که فهرست به کدام انتشار مربوط است. شش ماه بعد، آسیب‌پذیری جدی در یک جزء متن‌باز پرکاربرد افشا شد. تیم امنیت می‌خواست بداند آیا نرم‌افزار کنترل تردد تحت تأثیر است یا نه، اما دید فهرست نمی‌تواند به این پرسش پاسخ دهد. ناچار به تأمین‌کننده ایمیل زدند و یک هفته منتظر پاسخ ماندند. فهرست وجود داشت، اما در زمانی که بیش از همه لازم بود کمکی نکرد.
اداره ملی ارتباطات و اطلاعات آمریکا در سال ۲۰۲۱ سند حداقل اجزای فهرست اجزای نرم‌افزار را منتشر کرد و الزامات را در سه دسته قرار داد: فیلدهای داده، پشتیبانی از خودکارسازی، و رویه‌ها و فرایندها. فیلدهای داده شامل نام تأمین‌کننده، نام جزء، نسخه جزء، سایر شناسه‌های یکتا، روابط وابستگی، نویسنده داده‌های فهرست و برچسب زمانی است. پشتیبانی از خودکارسازی به قالب‌های رایج ماشین‌خوان نیاز دارد. رویه‌ها و فرایندها به دفعات به‌روزرسانی، عمق پوشش، نحوه بیان «ناشناخته‌های شناخته‌شده»، شیوه توزیع و کنترل دسترسی می‌پردازند. در سال ۲۰۲۵ آژانس امنیت سایبری و زیرساخت آمریکا پیش‌نویس به‌روزشده‌ای را برای اظهارنظر عمومی منتشر کرد که افزودن اجزایی مانند هش جزء، مجوز، نام ابزار و زمینه تولید را پیشنهاد می‌دهد؛ فعلاً باید آن را پیش‌نویس دانست، نه سند نهایی.
الزامات قابل پذیرش را در بندهای خرید بنویسید
JOTOglobal پیشنهاد می‌کند مسئول خرید و مسئول امنیت با هم الزامات را در یک پیوست فنی بنویسند، نه این‌که فقط یک جمله اصولی باقی بماند. پیوست باید دست‌کم مشخص کند از کدام قالب ماشین‌خوان استفاده می‌شود؛ هر انتشار و هر نسخه وصله فهرست مطابق خود را داشته باشد؛ فهرست تا چه عمقی پیش برود، برای نمونه دست‌کم وابستگی‌های مستقیم را فهرست کند و میزان پوشش وابستگی‌های غیرمستقیم را بیان کند؛ هر بخشی که قابل تأیید نیست صریحاً «ناشناخته» علامت بخورد و حذف نشود؛ و شیوه تحویل، مهلت به‌روزرسانی و دریافت‌کننده آن معلوم باشد. اگر نرم‌افزار به‌صورت سرویس ابری ارائه می‌شود و شرکت بسته قابل نصب در اختیار ندارد، به‌جای آن از تأمین‌کننده بخواهید فرایند مدیریت اجزا و پاسخ به آسیب‌پذیری خود را شرح دهد و توافق کنید که هنگام انتشار یک آسیب‌پذیری عمومی، در چه مدتی اعلام می‌کند سرویس تحت تأثیر است یا نه.
بندها باید مسئولیت‌های داخلی دریافت و نگهداری فهرست را نیز مشخص کنند. فهرست ممکن است جزئیات فنی تأمین‌کننده را آشکار کند، بنابراین شرکت باید دامنه افرادی را که می‌توانند آن را ببینند محدود کند و طبق بندهای محرمانگی قرارداد نگهداری کند. برای سامانه‌های حیاتی، شرکت می‌تواند یک بیانیه آسیب‌پذیری همراه با فهرست نیز بخواهد که نشان دهد یک آسیب‌پذیری شناخته‌شده در محصول قابل بهره‌برداری است یا نه، تا کار بررسی تک‌تک موارد کاهش یابد. همه این الزامات باید در مرحله مناقصه مطرح شوند تا تأمین‌کنندگان بتوانند توان برآوردن آن‌ها را ارزیابی کنند، نه این‌که هنگام پذیرش اضافه شوند و به اختلاف قراردادی بینجامند. در ارزیابی پیشنهادها می‌توان نمونه فهرست را یکی از موارد امتیازدهی قرار داد و از پیشنهاددهندگان خواست فهرست واقعی یک محصول مشابه را برای مطالعه تیم فنی ارائه دهند.
تحویل را در سه گام بپذیرید
گام نخست، بررسی قالب و کامل بودن است. تیم امنیت فهرست را با یک ابزار متن‌باز یا تجاری رایج باز می‌کند و تأیید می‌کند که فایل قابل تجزیه است، هر جزء نام، نسخه و شناسه یکتا دارد و نویسنده و زمان تولید پر شده‌اند، و بررسی می‌کند که نسخه محصول اعلام‌شده در فهرست با نرم‌افزار واقعاً تحویل‌شده یکسان باشد. گام دوم، مقایسه نمونه‌ای است. مهندسان نرم‌افزار را در یک محیط آزمایشی مجاز نصب می‌کنند، چند جزء اصلی را برمی‌گزینند و نسخه‌ای را که در پوشه نصب، اطلاعات بسته یا هنگام اجرا نمایش داده می‌شود با آنچه در فهرست ثبت شده مقایسه می‌کنند. در صورت تفاوت، اختلاف ثبت می‌شود و از تأمین‌کننده خواسته می‌شود توضیح دهد یا فهرست را دوباره تولید کند.
گام سوم، آزمودن یک جست‌وجوی واقعی است. تیم امنیت یک آسیب‌پذیری تازه افشاشده را برمی‌گزیند، فرض می‌کند باید تأیید کند محصول تحت تأثیر است یا نه، با استفاده از فهرست در سامانه مدیریت دارایی یا آسیب‌پذیری جست‌وجو می‌کند و ثبت می‌کند رسیدن به نتیجه چه مدت طول کشید و آیا باز هم لازم شد با تأمین‌کننده تماس بگیرند. اگر نتایج به قضاوت دستی زیادی نیاز دارد، شناسه‌ها یا عمق فهرست هنوز کافی نیست و این موضوع باید در نظر پذیرش با تاریخ توافق‌شده برای اصلاح ذکر شود. نتایج سه گام، مشکلات یافت‌شده و پاسخ‌های تأمین‌کننده همگی در گزارش پذیرش نوشته می‌شوند و به امضای مشترک خرید، امنیت و صاحب سامانه می‌رسند. اگر تأمین‌کننده تا مهلت توافق‌شده هنوز نتواند فیلدهای کلیدی را تکمیل کند، گزارش پذیرش باید مشخص کند مرحله پرداخت یا شرط نگهداشت مربوط چگونه مدیریت می‌شود و مسئول خرید آن را پیگیری کند.
نگهداری پس از راه‌اندازی، خطاهای رایج و محدوده کاربرد
پس از راه‌اندازی، صاحب سامانه اطمینان می‌یابد که فهرست با هر ارتقا به‌روز می‌شود و در سامانه مدیریت دارایی به نمونه مستقرشده مشخص پیوند می‌خورد. اگر فهرست‌ها فقط در یک پوشه اشتراکی نگهداری شوند، هنگام بروز آسیب‌پذیری اغلب نسخه مطابق پیدا نمی‌شود. یکی از خطاهای رایج این است که فهرست یک تحویل یک‌باره تلقی شود که پس از امضا هرگز به‌روز نمی‌شود. خطای دیگر این باور است که داشتن فهرست یعنی نرم‌افزار امن است. در واقع فهرست فقط می‌گوید «درون آن چه چیزی هست» و نمی‌گوید این اجزا آسیب‌پذیری قابل بهره‌برداری دارند یا نه؛ این موضوع همچنان به اطلاعات آسیب‌پذیری، اطلاعیه‌های تأمین‌کننده و در صورت نیاز آزمون نیاز دارد.
نکات بندها و گام‌های پذیرش در این مقاله، توصیه سازمانی JOTOglobal است و نظر حقوقی محسوب نمی‌شود؛ متن دقیق قرارداد را باید واحد حقوقی شرکت با توجه به مقررات محلی و وضعیت تأمین‌کننده تعیین کند. سند حداقل اجزا عمدتاً برای خریدهای فدرال آمریکا نوشته شده و مناطق و صنایع دیگر ممکن است الزامات اجباری متفاوتی داشته باشند. تأمین‌کنندگان نرم‌افزارهای کوچک یا سفارشی ممکن است نتوانند همه الزامات را یک‌باره برآورده کنند، بنابراین شرکت می‌تواند الزامات را بر اساس اهمیت سامانه سطح‌بندی کند و در قرارداد جدول زمانی برای انطباق تدریجی توافق کند. توصیف اجزای سرویس‌های ابری، میان‌افزار سخت‌افزار و مدل‌های هوش مصنوعی هنوز در حال تحول است و باید با توجه به توان واقعی تأمین‌کنندگان ارزیابی شود.