پیش از دسترسی فنی، مالکیت و مرز کار را روشن کنید
فهرست تحویل را از دارایی و اختیار شروع کنید: مخزن کد، دامنه، میزبانی، پایگاه داده، ذخیره فایل، پیام‌رسانی، پرداخت و حساب‌های تحلیل. برای هرکدام مالک سازمانی، مسئول اجرایی و وابستگی قراردادی را بنویسید. NIST SSDF زبان مشترکی برای گفت‌وگوی خریدار و عرضه‌کننده درباره توسعه امن فراهم می‌کند؛ پیشنهاد این راهنما آن است که همین گفت‌وگو به اقلام تحویلی قابل بررسی تبدیل شود. داشتن نسخه‌ای از کد، به‌تنهایی اختیار مدیریت دامنه یا دسترسی به داده را نشان نمی‌دهد.
- دامنه بررسی و اجازه تغییر را ثبت کنید: چه دارایی، چه محیط و چه روش‌هایی مجازند؟
- حساب‌های سازمانی و نقش‌های فردی را با روش رسمی سرویس منتقل کنید و لغو دسترسی قبلی را متناسب با مسئولیت باقی‌مانده برنامه‌ریزی کنید.
- برای شروع گفت‌وگو، فهرست دارایی کافی است؛ رمز، کلید یا داده مشتری را در فرم درخواست قرار ندهید.
منبع فنی این بخش: NIST [۱]
از تیم جدید بخواهید خط پایه را بازسازی کند
به‌جای پذیرش پوشه‌ای با عنوان «نسخه نهایی»، از یک نسخه مشخص شروع کنید. تیم تحویل‌گیرنده باید با مستندات، وابستگی‌های ثبت‌شده و دسترسی مجاز خودش محیط بررسی را اجرا کند و یک جریان مهم را نشان دهد. مثال فرضی: برای سامانه سفارش، ورود کاربر، ایجاد سفارش آزمایشی و مشاهده آن توسط اپراتور خط پایه است. هر مرحله‌ای که به لپ‌تاپ شخصی، فایل نامعلوم یا توضیح شفاهی وابسته مانده، شکاف تحویل است و باید مالک اصلاح داشته باشد.
- شاهد: نسخه کد، پیش‌نیازهای اجرا، نام تنظیمات موردنیاز و داده آزمایشی مجاز.
- کنترل: پیام‌رسانی، پرداخت و اتصال‌های محیط بررسی به عملیات واقعی اثر ناخواسته نگذارند.
- برای انتشار، بازگشت و بازیابی به راهنمای تخصصی استقرار ارجاع دهید و اجرای عملی آن را در پذیرش جدا ثبت کنید.
منبع فنی این بخش: NIST [۱]
ادعای «امن است» را به کنترل و شاهد تبدیل کنید
OWASP ASVS مجموعه نیازمندی‌هایی برای طراحی، توسعه و آزمون امنیت برنامه فراهم می‌کند و می‌توان از آن در قرارداد استفاده کرد. در تحویل، عبارت کلی «بررسی براساس OWASP» کافی نیست؛ نسخه استاندارد، کنترل منتخب، دارایی و روش آزمون را ثبت کنید. مثال فرضی: مالکیت فاکتور باید با دو حساب مستقل و درخواست مستقیم به API بررسی شود، نه فقط از روی منوی پنل. یافته باید شرایط بازتولید، اثر، مالک اصلاح و نتیجه بازآزمایی داشته باشد.
| عبارت مبهم | پرسش پذیرش | شاهد مورد انتظار |
|---|---|---|
| احراز هویت پیاده‌سازی شده | نشست، بازیابی حساب و لغو دسترسی در دامنه بررسی چگونه آزموده شدند؟ | سناریو، نسخه و نتیجه ثبت‌شده |
| داده‌ها محافظت می‌شوند | کاربر غیرمجاز در درخواست مستقیم به رکورد چه می‌بیند؟ | آزمون مجاز و غیرمجاز با داده نمونه |
| آسیب‌پذیری رفع شد | همان شرایط بازتولید پس از اصلاح چه نتیجه‌ای دارد؟ | بازآزمایی و وضعیت ریسک باقی‌مانده |
منبع فنی این بخش: OWASP [۲]
وابستگی‌ها را با مسیر اصلاح تحویل بگیرید
راهنمای OWASP مدیریت وابستگی آسیب‌پذیر را وابسته به زمینه و امکان اصلاح می‌داند؛ گزارش ابزار، تصمیم نهایی نگهداری نیست. پیشنهاد عملی این است که نام و نسخه وابستگی مستقیم و غیرمستقیم را به نسخه تحویلی وصل کنید و برای هشدار، وجود جزء در سامانه و شرایط استفاده را بررسی کنید. مثال فرضی: بسته‌ای در ابزار ساخت با کتابخانه فعال روی مسیر عمومی پیامد یکسانی ندارد. بااین‌حال نبود اثبات بهره‌برداری، دلیل حذف خودکار یافته از فهرست نیست.
- برای هر مورد: جزء و نسخه، منبع هشدار، محل استفاده، اثر، گزینه اصلاح و مسئول تصمیم ثبت شود.
- اگر ارتقا ممکن است، تغییرات ناسازگار و جریان‌های حیاتی را آزمون و مسیر بازگشت را تعیین کنید.
- اگر اصلاح فعلاً ممکن نیست، کنترل جبرانی، ریسک باقی‌مانده و موعد بازبینی داشته باشید؛ فایل گزارش بدون مالک، برنامه نگهداری نیست.
منبع فنی این بخش: OWASP [۳]
امکان تشخیص خطا را بدون انباشت داده حساس تحویل دهید
راهنمای ثبت رویداد OWASP میان ثبت مفید رخداد و نگهداری داده‌ای مانند رمز، توکن و کلید محرمانه تمایز می‌گذارد. در تحویل، یک خطای نمونه را از گزارش کاربر تا رویداد فنی دنبال کنید: چه زمانی، در کدام نسخه و با چه شناسه پیگیری رخ داده است؟ سپس بررسی کنید چه کسی مجاز به دیدن گزارش‌هاست و چه مدت نگهداری می‌شوند. محیط بررسی هم نباید به محل تکثیر بی‌قاعده اطلاعات مشتری تبدیل شود.
- پیشنهاد پذیرش: خطای کنترل‌شده قابل تشخیص باشد و گزارش آن رمز، توکن یا داده مشتری غیرضروری نداشته باشد.
- مالک هشدار، مسیر ارجاع و مسئول رسیدگی به شکست ثبت رویداد مشخص شوند.
- نمونه گزارش تحویلی تا حد لازم حذف یا پوشانده شود و دسترسی نگهداری با نیاز واقعی هماهنگ بماند.
منبع فنی این بخش: OWASP [۴]
رخداد، اصلاح عیب و توسعه جدید را با مسئولیت روشن تعریف کنید
قرارداد مبهم «پشتیبانی کامل» زمینه اختلاف می‌سازد. یک ماتریس پیشنهادی تهیه کنید که اختلال سرویس، نقص موجود، ارتقای وابستگی و قابلیت جدید را جدا توضیح دهد. برای هرکدام دریافت‌کننده درخواست، اطلاعات لازم، اولویت‌بندی و مرجع تأیید تغییر مشخص شود. زمان پاسخ را از زمان رفع جدا تعریف کنید؛ رفع ممکن است به دسترسی، تصمیم کسب‌وکار یا سرویس ثالث وابسته باشد. به‌جای تعهد بدون شاهد، دامنه و فرض‌های قابل اجرا را با دو طرف ثبت کنید.
| نوع کار | اطلاعات ورودی | تصمیم لازم |
|---|---|---|
| اختلال فعال | جریان متأثر، زمان، دامنه اثر و شواهد مجاز | مالک فرماندهی رخداد و اختیار اقدام |
| اصلاح عیب | شرایط بازتولید و رفتار مورد انتظار | اولویت، معیار پذیرش و انتشار اصلاح |
| نگهداری پیشگیرانه | نسخه، هشدار یا پایان پشتیبانی اعلام‌شده عرضه‌کننده | پنجره تغییر و آزمون سازگاری |
| قابلیت جدید | مسئله کاربر، مرز داده و نتیجه مطلوب | دامنه و برآورد جداگانه پس از بررسی |
منبع فنی این بخش: NIST [۱]
تحویل را با یک تغییر محدود و فهرست شکاف‌ها بپذیرید
برای پذیرش، یک اصلاح کوچک و مجاز را انتخاب کنید که تیم جدید از بازتولید تا بازآزمایی آن را پیش ببرد. این تمرین جای ممیزی جامع را نمی‌گیرد؛ نشان می‌دهد مسیر انجام کار در دامنه مشخص قابل استفاده است. نسخه تحویلی، نتیجه آزمون و مسئول پشتیبانی را ثبت کنید. سپس شکاف‌ها را به موارد مانع انتقال، اصلاح برنامه‌ریزی‌شده و ریسک پذیرفته‌شده با مالک و موعد بازبینی تقسیم کنید. وضعیت نامعلوم را به‌عنوان «تأییدشده» گزارش نکنید.
- تحویل پذیرفته‌شده: دسترسی‌های لازم، مستند اجرا، خط پایه، مسیر تغییر و تماس مسئول قابل استفاده‌اند.
- تحویل مشروط: شکاف مشخص، مالک اقدام، مرز مسئولیت موقت و تاریخ بازبینی ثبت شده است.
- ادامه همکاری: فهرست اصلاح‌ها براساس اثر و وابستگی مرتب شود؛ تعداد یافته بسته‌شده به‌تنهایی معیار کیفیت نیست.