ممیزی فنی نرم‌افزار شامل چه چیزی است و چه چیزی نیست؟

«ممیزی فنی» عبارتی است که هر کس چیز دیگری از آن می‌فهمد: یکی یک گزارش امنیتی می‌خواهد، دیگری قضاوت دربارهٔ کیفیت کد، سومی تصمیم برای بازنویسی. این مقاله دامنه و مرز یک ممیزی خوب را روشن می‌کند. هیچ مدت یا قیمتی را ادعا نمی‌کنیم و ممیزی را گواهی یا تضمین بی‌نقص‌بودن معرفی نمی‌کنیم.

ممیزی یعنی چه؟

تعریف عملی: بررسی یک سیستم موجود نسبت به معیارهای مشخص، با شاهد و محدودیت‌های اعلام‌شده، و تبدیل یافته‌ها به فهرست کارهای اولویت‌دار. ISO/IEC 25010 در معرفی مدل کیفیت می‌گوید کیفیت یک سیستم، میزان برآورده‌شدن نیازهای بیان‌شده و ضمنی ذی‌نفعان آن است و این نیازها (کارکرد، کارایی، امنیت، قابلیت نگه‌داری و غیره) در مدل کیفیت دسته‌بندی می‌شوند. (این را از صفحهٔ معرفی ISO 25000 خواندیم؛ متن کامل پولی استاندارد را نخوانده‌ایم.) نتیجه: پیش از ممیزی باید معلوم شود «کدام نیازها» معیار هستند.

دامنه: چه چیزهایی بررسی می‌شود؟

دامنهٔ زیر الگوی پیشنهادی نویسنده است و هر ممیزی باید فقط بخشی را انتخاب کند.

• معماری و کد: ساختار، وابستگی‌ها، قابلیت تغییر.
• آزمون و تحویل: پوشش آزمون، خط تولید استقرار، بازگشت.
• امنیت: کنترل‌های دسترسی، مدیریت اسرار، ورودی‌ها.
• زیرساخت و عملیات: پایش، بکاپ، به‌روزرسانی.
• کارایی و تجربه: اگر مسئلهٔ شما کندی است.

صفحهٔ ممیزی مهندسی FutureForge خروجی‌های همین نوع خدمت را معرفی می‌کند: گزارش وضعیت سیستم، فهرست مسئله‌ها و ریسک‌ها، اولویت‌بندی، بررسی ریسک‌های امنیتی و زیرساختی، پیشنهاد رفع و نقشهٔ راه فنی. این توصیف خدمت خودمان است، نه استاندارد صنعت.

روش‌ها: بازبینی، تحلیل، آزمون

NIST در چارچوب SSDF (PW.7.1) بین code review (بازبینی مستقیم کد توسط انسان) و code analysis (استفاده از ابزار، خودکار یا همراه با انسان) فرق می‌گذارد و می‌گوید باید تعیین شود کدام لازم است. در PW.7.2 نیز یادآوری می‌کند بازبینی یا تحلیل باید بر پایهٔ استانداردهای کدنویسی امن باشد و مسائل و راه‌حل‌ها ثبت و اولویت‌بندی شوند. در PW.8.1 می‌گوید باید تعیین شود آیا آزمون کد اجرایی برای یافتن آسیب‌پذیری‌هایی که بررسی‌های قبلی نیافته‌اند لازم است و چه نوعی. نتیجه برای ممیزی: روش هر بخش را از پیش بگویید و مشخص کنید چه چیزی با ابزار و چه چیزی توسط انسان دیده شده است.

شواهد و نمونه‌برداری

هر یافته باید شاهد داشته باشد: فایل و خط کد، خروجی ابزار، گزارش استقرار یا تصویر تنظیمات. چون ممیزی معمولاً همهٔ کد را نمی‌خواند، باید اعلام کند چه بخش‌هایی را دیده و بر چه مبنایی انتخاب کرده است. برای امنیت وب، OWASP ASVS مبنایی برای آزمون کنترل‌های فنی و فهرست الزامات توسعهٔ امن است و می‌تواند سطحی از اطمینان ایجاد کند؛ اگر ممیز از آن استفاده می‌کند، بخواهید نسخه و سطح را نام ببرد.

ممیزی چه چیزی نیست؟

• گواهی بی‌نقص‌بودن: ممیزی نمونه و در یک زمان مشخص است.
• مشاورهٔ حقوقی یا بررسی انطباق قانونی: مگر صراحتاً در دامنه آمده باشد.
• جایگزین تست نفوذ تخصصی: اگر امنیت اولویت است، دامنهٔ تست نفوذ جدا باید تعریف شود.
• تصمیم بازنویسی: ممیزی شواهد می‌دهد؛ تصمیم با شماست.

خروجی خوب چه شکلی است؟

1. خلاصهٔ مدیریتی با سه تا پنج ریسک اصلی.
2. فهرست یافته‌ها با شاهد، اثر، احتمال و پیشنهاد.
3. اولویت‌بندی بر پایهٔ اثر و هزینهٔ تغییر.
4. بخش «نادیده‌ماند» که محدودیت‌ها را صریح می‌گوید.
5. برنامهٔ اقدام کوتاه و بلندمدت.

برای تعریف «آماده» به‌عنوان معیار مقایسه، Production-Ready را ببینید و برای تصویر مدیریتی پروژه، چگونه یک پروژهٔ نرم‌افزاری را ارزیابی کنیم.

پیش از سفارش ممیزی

1. سؤال اصلی را بنویسید (مثلاً «چرا استقرار ترسناک است؟»).
2. دامنه و بخش‌های خارج از دامنه را مکتوب کنید.
3. دسترسی لازم را فقط‌خواندنی و محدود بدهید.
4. قالب خروجی و بخش «نادیده‌ماند» را بخواهید.

اگر وضعیت سیستمتان را برای ممیزی توضیح می‌دهید، صفحهٔ شروع پروژه نقطهٔ ورود است؛ ارسال فرم تعهدی ایجاد نمی‌کند.

منابع و مراجع

• ISO/IEC 25010 (مدل کیفیت محصول) — ISO 25000 (iso25000.com، وب‌سایت معرفی خانوادهٔ ISO 25000).
• Secure Software Development Framework (SSDF) Version 1.1 (NIST SP 800-218) — NIST، فوریه ۲۰۲۲.
• OWASP Application Security Verification Standard (ASVS) — OWASP Foundation.
• ممیزی مهندسی — FutureForge.