چک‌لیست برنامه‌نویسی امن؛ کنترل‌های ضروری از طراحی تا انتشار

این چک‌لیست را چگونه در پروژه استفاده کنیم؟

همه کنترل‌ها برای همه سامانه‌ها وزن یکسان ندارند. ابتدا داده‌های حساس، نقش‌ها، مسیرهای اعتماد، سرویس‌های بیرونی و اثر سوءاستفاده را مشخص کنید؛ سپس هر کنترل مرتبط را به یک مسئول، مرحله اجرا و شاهد پذیرش متصل کنید.

نکته: NIST SSDF رویکرد مبتنی بر ریسک و نتیجه را توصیه می‌کند؛ چک‌لیست نباید به تیک‌زدن کنترل‌های نامرتبط تبدیل شود.

نیازمندی و طراحی امن

• دارایی‌ها، داده‌های حساس، نقش‌ها و مرزهای اعتماد را پیش از پیاده‌سازی ثبت کنید.
• Threat Model را برای جریان‌های حیاتی و اتصال‌های بیرونی تهیه و با تغییر معماری بازبینی کنید.
• الزام‌های امنیتی را شماره‌دار، قابل آزمون و متناسب با سطح ریسک بنویسید.
• فرض کنید Client، شبکه و ورودی بیرونی قابل اعتماد نیستند؛ کنترل اصلی را سمت سرور اجرا کنید.
• مسیرهای خطا، سوءاستفاده، بازیابی و محدودیت نرخ را کنار مسیر موفق طراحی کنید.
• داده‌ای را که نیاز ندارید جمع‌آوری نکنید و مدت نگهداری و حذف آن را تعیین کنید.

هویت، نشست و کنترل دسترسی

• از سازوکار احراز هویت استاندارد و کتابخانه نگهداری‌شده استفاده کنید؛ الگوریتم اختصاصی نسازید.
• گذرواژه را با الگوریتم Password Hashing مناسب و تنظیمات قابل ارتقا نگهداری کنید.
• کنترل مجوز را در هر درخواست سمت سرور و بر اساس نقش، مالکیت و دامنه داده اعمال کنید.
• شناسه قابل حدس را مجوز تلقی نکنید و دسترسی افقی و عمودی را جداگانه آزمایش کنید.
• Session و Token باید انقضا، ابطال، Rotation و محافظت در برابر سرقت داشته باشند.
• عملیات حساس مانند تغییر دسترسی یا حساب مقصد، تأیید و Audit متناسب با ریسک داشته باشد.

ورودی، خروجی، فایل و حفاظت داده

• ورودی را بر اساس نوع، طول، محدوده و قالب مورد انتظار در مرز اعتماد اعتبارسنجی کنید.
• برای Query از Parameterization استفاده کنید و داده را با رشته SQL یا Command ترکیب نکنید.
• خروجی را متناسب با Context مقصد Encode کنید تا XSS و تزریق مشابه کاهش یابد.
• آپلود فایل را از نظر نوع واقعی، اندازه، نام، محل ذخیره و دسترسی اجرا محدود کنید.
• Serialization، Template، Redirect و درخواست‌های خروجی را با Allowlist و محدودیت بررسی کنید.
• داده حساس را در انتقال و محل ذخیره با روش استاندارد محافظت و دسترسی آن را حداقلی کنید.
• اطلاعات شخصی، Token، رمز و جزئیات داخلی را در پاسخ خطا یا Log نمایش ندهید.

Secrets، وابستگی‌ها و زنجیره ساخت

• کلید و Secret را در کد، Git، Image، فایل قابل دانلود یا برنامه سمت کاربر قرار ندهید.
• Secretها را برای هر محیط و سرویس جدا، با Scope حداقلی و برنامه Rotation مدیریت کنید.
• نسخه وابستگی‌ها و ابزار Build را قفل و منبع دریافت Package را کنترل کنید.
• وابستگی مستقیم و انتقالی را با SCA یا ابزار مناسب پایش و یافته‌ها را مالک‌گذاری کنید.
• مجوز نرم‌افزاری، وضعیت نگهداری و End-of-Life وابستگی حیاتی را بررسی کنید.
• دسترسی CI/CD، Registry و Artifact را حداقلی کنید و Branch/Release حساس را محافظت کنید.
• Artifact نسخه نهایی را قابل ردیابی به Commit و Pipeline تأییدشده نگه دارید.

Logging، مدیریت خطا و پایش

• رویدادهای امنیتی مانند ورود ناموفق، تغییر مجوز و عملیات حساس را با زمینه کافی ثبت کنید.
• Log نباید شامل رمز، Token، Session، داده کامل پرداخت یا اطلاعات شخصی غیرضروری باشد.
• پیام خطای کاربر ساده باشد و جزئیات فنی فقط در مسیر کنترل‌شده ثبت شود.
• شناسه همبستگی برای اتصال درخواست، خطا و رخدادهای سرویس‌ها در نظر بگیرید.
• Log را در برابر تغییر و دسترسی غیرمجاز محافظت و دوره نگهداری آن را مشخص کنید.
• برای الگوهای غیرعادی، خطای تکرارشونده و سوءاستفاده از عملیات حساس هشدار تعریف کنید.

بازبینی، تست، انتشار و پاسخ به آسیب‌پذیری

• تغییر حساس بدون بازبینی همتا و عبور تست‌های مرتبط وارد شاخه انتشار نشود.
• SAST، SCA و Secret Scanning را در Pipeline اجرا کنید و قاعده برخورد با یافته را بنویسید.
• DAST یا آزمون API را روی محیط مجاز و نزدیک به Production برای مسیرهای پرریسک اجرا کنید.
• تست کنترل دسترسی، ورودی مرزی، Rate Limit و خطای سرویس بیرونی را به Regression اضافه کنید.
• تنظیمات امن، Headerها، TLS، حساب سرویس و دسترسی زیرساخت را جدا از کد بازبینی کنید.
• انتشار باید Health Check، مانیتورینگ و Rollback قابل اجرا داشته باشد.
• مسیر دریافت، اولویت‌بندی، اصلاح و افشای مسئولانه آسیب‌پذیری‌های پس از انتشار را مشخص کنید.

کارفرما چه شواهدی باید تحویل بگیرد؟