ممیزی فنی نرم‌افزار شامل چه چیزی است و چه چیزی نیست؟
4 min read
ممیزی فنی یعنی بررسی با دامنه، نمونه‌برداری و شاهد مشخص، نه گواهی بی‌نقص‌بودن. دامنه، روش، محدودیت‌ها و خروجی قابل‌اقدام را با مرجع‌های ISO، NIST و OWASP مرور می‌کنیم.
«ممیزی فنی» عبارتی است که هر کس چیز دیگری از آن می‌فهمد: یکی یک گزارش امنیتی می‌خواهد، دیگری قضاوت دربارهٔ کیفیت کد، سومی تصمیم برای بازنویسی. این مقاله دامنه و مرز یک ممیزی خوب را روشن می‌کند. هیچ مدت یا قیمتی را ادعا نمی‌کنیم و ممیزی را گواهی یا تضمین بی‌نقص‌بودن معرفی نمی‌کنیم.
ممیزی یعنی چه؟
تعریف عملی: بررسی یک سیستم موجود نسبت به معیارهای مشخص، با شاهد و محدودیت‌های اعلام‌شده، و تبدیل یافته‌ها به فهرست کارهای اولویت‌دار. ISO/IEC 25010 در معرفی مدل کیفیت می‌گوید کیفیت یک سیستم، میزان برآورده‌شدن نیازهای بیان‌شده و ضمنی ذی‌نفعان آن است و این نیازها (کارکرد، کارایی، امنیت، قابلیت نگه‌داری و غیره) در مدل کیفیت دسته‌بندی می‌شوند. (این را از صفحهٔ معرفی ISO 25000 خواندیم؛ متن کامل پولی استاندارد را نخوانده‌ایم.) نتیجه: پیش از ممیزی باید معلوم شود «کدام نیازها» معیار هستند.
دامنه: چه چیزهایی بررسی می‌شود؟
دامنهٔ زیر الگوی پیشنهادی نویسنده است و هر ممیزی باید فقط بخشی را انتخاب کند.
- معماری و کد: ساختار، وابستگی‌ها، قابلیت تغییر.
- آزمون و تحویل: پوشش آزمون، خط تولید استقرار، بازگشت.
- امنیت: کنترل‌های دسترسی، مدیریت اسرار، ورودی‌ها.
- زیرساخت و عملیات: پایش، بکاپ، به‌روزرسانی.
- کارایی و تجربه: اگر مسئلهٔ شما کندی است.
صفحهٔ ممیزی مهندسی FutureForge خروجی‌های همین نوع خدمت را معرفی می‌کند: گزارش وضعیت سیستم، فهرست مسئله‌ها و ریسک‌ها، اولویت‌بندی، بررسی ریسک‌های امنیتی و زیرساختی، پیشنهاد رفع و نقشهٔ راه فنی. این توصیف خدمت خودمان است، نه استاندارد صنعت.
روش‌ها: بازبینی، تحلیل، آزمون
NIST در چارچوب SSDF (PW.7.1) بین code review (بازبینی مستقیم کد توسط انسان) و code analysis (استفاده از ابزار، خودکار یا همراه با انسان) فرق می‌گذارد و می‌گوید باید تعیین شود کدام لازم است. در PW.7.2 نیز یادآوری می‌کند بازبینی یا تحلیل باید بر پایهٔ استانداردهای کدنویسی امن باشد و مسائل و راه‌حل‌ها ثبت و اولویت‌بندی شوند. در PW.8.1 می‌گوید باید تعیین شود آیا آزمون کد اجرایی برای یافتن آسیب‌پذیری‌هایی که بررسی‌های قبلی نیافته‌اند لازم است و چه نوعی. نتیجه برای ممیزی: روش هر بخش را از پیش بگویید و مشخص کنید چه چیزی با ابزار و چه چیزی توسط انسان دیده شده است.
شواهد و نمونه‌برداری
هر یافته باید شاهد داشته باشد: فایل و خط کد، خروجی ابزار، گزارش استقرار یا تصویر تنظیمات. چون ممیزی معمولاً همهٔ کد را نمی‌خواند، باید اعلام کند چه بخش‌هایی را دیده و بر چه مبنایی انتخاب کرده است. برای امنیت وب، OWASP ASVS مبنایی برای آزمون کنترل‌های فنی و فهرست الزامات توسعهٔ امن است و می‌تواند سطحی از اطمینان ایجاد کند؛ اگر ممیز از آن استفاده می‌کند، بخواهید نسخه و سطح را نام ببرد.
ممیزی چه چیزی نیست؟
- گواهی بی‌نقص‌بودن: ممیزی نمونه و در یک زمان مشخص است.
- مشاورهٔ حقوقی یا بررسی انطباق قانونی: مگر صراحتاً در دامنه آمده باشد.
- جایگزین تست نفوذ تخصصی: اگر امنیت اولویت است، دامنهٔ تست نفوذ جدا باید تعریف شود.
- تصمیم بازنویسی: ممیزی شواهد می‌دهد؛ تصمیم با شماست.
خروجی خوب چه شکلی است؟
- خلاصهٔ مدیریتی با سه تا پنج ریسک اصلی.
- فهرست یافته‌ها با شاهد، اثر، احتمال و پیشنهاد.
- اولویت‌بندی بر پایهٔ اثر و هزینهٔ تغییر.
- بخش «نادیده‌ماند» که محدودیت‌ها را صریح می‌گوید.
- برنامهٔ اقدام کوتاه و بلندمدت.
برای تعریف «آماده» به‌عنوان معیار مقایسه، Production-Ready را ببینید و برای تصویر مدیریتی پروژه، چگونه یک پروژهٔ نرم‌افزاری را ارزیابی کنیم.
پیش از سفارش ممیزی
- سؤال اصلی را بنویسید (مثلاً «چرا استقرار ترسناک است؟»).
- دامنه و بخش‌های خارج از دامنه را مکتوب کنید.
- دسترسی لازم را فقط‌خواندنی و محدود بدهید.
- قالب خروجی و بخش «نادیده‌ماند» را بخواهید.
اگر وضعیت سیستمتان را برای ممیزی توضیح می‌دهید، صفحهٔ شروع پروژه نقطهٔ ورود است؛ ارسال فرم تعهدی ایجاد نمی‌کند.
منابع و مراجع
- 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.
Author
SE
Soheil Ebrahimpour is the founder of FutureForge. He works on product design, architecture, and getting custom software into production.
Related notes
If you are unsure about architecture or the build path, we can talk about the project.
Describe the problem and the constraints. If there is a fit, we will schedule a conversation.
