دوره‌های سازمانی توسعه امن

سرفصل دوره از کجا می‌آید؟

سرفصل ثابت نداریم و جزوه‌ی عمومی تحویل نمی‌دهیم. ستون فقرات دوره از سه منبع ساخته می‌شود: دسته‌های OWASP Top 10:2025 که به زبان و فریم‌ورک خود تیم ترجمه می‌شوند، یافته‌های واقعی ارزیابی‌های قبلی همان سازمان (اگر وجود داشته باشد)، و الگوهای باگی که در بررسی نمونه‌کد تیم پیدا می‌کنیم. نتیجه این است که یک تیم Node.js و یک تیم جاوا، دو دوره‌ی واقعاً متفاوت می‌گیرند — نه یک اسلاید مشترک با مثال‌های عوض‌شده.

۱. مدل‌سازی تهدید در جلسه‌ی طراحی

OWASP دسته‌ی A06:2025 Insecure Design را با یک جمله‌ی کلیدی توضیح می‌دهد: طراحی امن ممکن است ایراد پیاده‌سازی داشته باشد، اما طراحی ناامن را هیچ پیاده‌سازی بی‌نقصی درست نمی‌کند. به همین دلیل دوره از انتهای زنجیره شروع نمی‌کند. تیم یاد می‌گیرد پیش از نوشتن کد، برای هر فیچر جدید مرزهای اعتماد را ترسیم کند، بپرسد «چه کسی این را سوءاستفاده می‌کند و چطور؟» و برای سناریوهای سوءاستفاده هم مثل سناریوهای استفاده، آزمون بنویسد. کارگاه عملی روی یک فیچر واقعی در بک‌لاگ خود تیم اجرا می‌شود. مفهوم پایه در مدل‌سازی تهدید توضیح داده شده است.

۲. بازبینی کد امن و چک‌لیست Pull Request

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

۳. ده دسته‌ی OWASP، روی استک واقعی تیم

هر دسته با یک آزمایشگاه کوچک و بی‌خطر تدریس می‌شود: آسیب‌پذیری بازتولید می‌شود، اثرش دیده می‌شود و بعد رفع می‌شود. تأکیدها را با وزن واقعی ریسک تنظیم می‌کنیم — کنترل دسترسی شکسته (A01:2025) بیشترین زمان را می‌گیرد چون در عمل بیشترین یافته را تولید می‌کند، و پیکربندی نادرست امنیتی (A02:2025) که در نسخه‌ی جاری از رتبه‌ی پنجم به دوم آمده، دیگر چند اسلاید پایانی نیست. دو دسته‌ی تازه‌ی این نسخه هم سرفصل مستقل دارند: شکست‌های زنجیره‌ی تأمین نرم‌افزار (A03:2025) و مدیریت نادرست شرایط استثنایی (A10:2025).

۴. وابستگی‌ها، SBOM و زنجیره‌ی تأمین

دسته‌ی A03:2025 دیگر فقط درباره‌ی «کتابخانه‌ی قدیمی» نیست؛ کل فرایند ساخت، توزیع و به‌روزرسانی را در بر می‌گیرد. در این بخش تیم یاد می‌گیرد فهرست مؤلفه‌های نرم‌افزاری (SBOM) را به‌صورت متمرکز نگه دارد و پیوسته به‌روز کند، مؤلفه‌ها را فقط از منابع رسمی و با راستی‌آزمایی امضا بردارد، تفکیک وظایف را در مخزن و خط لوله‌ی CI/CD اعمال کند، انتشار را مرحله‌ای انجام دهد و روی کل زیرساخت توسعه احراز هویت چندعاملی داشته باشد. حادثه‌های واقعی — از وصله‌ی آلوده‌ی یک فروشنده‌ی معتبر تا کرم خودتکثیر در اکوسیستم بسته‌های npm — به‌عنوان مطالعه‌ی موردی بررسی می‌شوند.

۵. SAST، DAST و بررسی وابستگی در خط لوله

ابزار امنیتی وقتی اثر دارد که در مسیر روزمره‌ی توسعه باشد، نه در یک گزارش فصلی. تیم یاد می‌گیرد کجای خط لوله کدام ابزار را بگذارد، چطور آستانه‌ی شکست بیلد را طوری تنظیم کند که کسی مجبور نشود دورش بزند، و مهم‌تر از همه چطور هشدار کاذب را مدیریت کند — چون ابزاری که نویز تولید کند، ظرف دو هفته خاموش می‌شود. درباره‌ی نام‌گذاری هم دقیق حرف می‌زنیم: ابزار متن‌باز محبوب دیگر «OWASP ZAP» نیست و از سپتامبر ۲۰۲۳ با نام ZAP (زیر چتر Checkmarx) شناخته می‌شود، و نسخه‌ی سازمانی Burp به Burp Suite DAST تغییر نام داده است. این جزئیات ظاهراً کوچک‌اند، اما نشان می‌دهند محتوای یک دوره به‌روز است یا از روی جزوه‌ی چند سال پیش کپی شده.

۶. پیش‌فرض‌های امن و مدیریت خطا

آخرین بخش، عادت‌هایی است که ریسک را بدون افزودن کار روزانه پایین می‌آورد: انکار پیش‌فرض در کنترل دسترسی، فرایند سخت‌سازی یکسان و تکرارپذیر برای همه‌ی محیط‌ها، خاموش‌بودن پیام خطای پرجزئیات در محیط عملیاتی، مدیریت متمرکز خطا و — مهم‌تر از همه — شکستِ بسته به‌جای شکستِ باز. دسته‌ی تازه‌ی A10:2025 دقیقاً به همین می‌پردازد: برنامه‌هایی که در شرایط غیرمنتظره منابع را آزاد نمی‌کنند، تراکنش نیمه‌تمام را درست برنمی‌گردانند یا در خطا جزئیات ساختار پایگاه داده را لو می‌دهند.

چه کسانی باید شرکت کنند؟

مخاطب اصلی، توسعه‌دهندگان بک‌اند و فرانت‌اند و مهندسان API هستند. اما دوره وقتی بیشترین اثر را دارد که سه نقش دیگر هم در بخشی از آن حاضر باشند: مهندس DevOps یا پلتفرم (برای بخش خط لوله و پیکربندی)، رهبر فنی و معمار (برای بخش مدل‌سازی تهدید و بازبینی کد)، و مدیر محصول یا صاحب محصول — دست‌کم در جلسه‌ی مدل‌سازی تهدید، چون بسیاری از باگ‌های منطق کسب‌وکار ریشه در تصمیم‌های محصولی دارند نه در کد. تیم تست و QA هم از بخش سناریوهای سوءاستفاده بهره‌ی مستقیم می‌برد.

اگر سازمان شما به‌دنبال ساختن یا تقویت یک تیم امنیتی داخلی است، این دوره جای آن را نمی‌گیرد؛ ملاحظات آن بحث جداگانه‌ای است که در تیم تست نفوذ سازمانی نوشته‌ایم. برای انتخاب میان دوره‌های موجود در بازار هم معیارهای عملی را در راهنمای انتخاب دوره‌ی امنیت جمع کرده‌ایم.

اثربخشی را چطور می‌سنجیم؟

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

• چگالی نقص امنیتی. تعداد باگ‌های امنیتی کشف‌شده به‌ازای هر اسپرینت یا هر هزار خط کد تغییر‌یافته. عدد مطلق مهم نیست؛ روند مهم است.
• تکرار یافته در ارزیابی‌های پیاپی. صادقانه‌ترین معیار: از یافته‌های ارزیابی قبلی، چند مورد در ارزیابی بعدی دوباره ظاهر شد؟ تکرار یک الگو یعنی دانش منتقل نشده، حتی اگر همه‌ی تیکت‌ها بسته شده باشند.
• زمان تا رفع. فاصله‌ی میان ثبت یک یافته و بسته‌شدن واقعی آن، تفکیک‌شده بر اساس شدت. آموزش معمولاً پیش از آنکه تعداد باگ را کم کند، این عدد را کم می‌کند — چون تیم دیگر برای فهمیدن مسئله وقت تلف نمی‌کند.
• یافته‌های مرحله‌ی بازبینی در برابر یافته‌های پس از انتشار. اگر سهم باگ‌هایی که در Pull Request گرفته می‌شوند بالا برود، یعنی کنترل به سمت چپ زنجیره حرکت کرده است؛ همان چیزی که کل هدف دوره است.

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