بازار دوره امنیت سایبری پر است از سرفصل‌هایی که شبیه هم به‌نظر می‌رسند و نتیجه‌های کاملاً متفاوت می‌دهند. تفاوت را عنوان دوره مشخص نمی‌کند؛ چهار چیز مشخص میکند: اینکه دوره روش‌شناسی می‌آموزد یا کلیک روی ابزار، اینکه چند ساعت واقعی دست روی کیبورد است، اینکه مدرس خودش چه چیزی را تست کرده، و — تیزترین و ساده‌ترین فیلتر — اینکه سرفصلش روی OWASP Top 10:2025 به‌روز است یا هنوز روی نسخهی ۲۰۲۱ مانده. این راهنما هم برای فردی نوشته شده که می‌خواهد دوره بخرد، هم برای مدیر فنی‌ای که می‌خواهد برای تیم توسعه‌اش آموزش توسعهی امن بگیرد و بعد بتواند اثرش را با عدد نشان دهد.
در یک نگاه
- تیزترین فیلتر ارزیابی یک دوره: سرفصل باید بر پایهی OWASP Top 10:2025 باشد. سرفصل ۲۰۲۱ یعنی محتوا دست‌کم یک نسل عقب است.
- دوره‌ای که یافته را به ابزار گره می‌زند به‌جای مکانیزم، شما را در سطح «اجرای اسکنر» متوقف میکند.
- آموزش سازمانی توسعهی امن با آموزش فردی یکی نیست: مخاطب، سرفصل، و مهم‌تر از همه معیار سنجش متفاوت است.
- اثر آموزش را با سه متریک بسنجید: چگالی نقص امنیتی، نرخ تکرار یافتهها در تستهای نفوذ متوالی، و زمان تا رفع.
- آموزش جایگزین تست نفوذ نیست و تست نفوذ جایگزین آموزش نیست — دو شکاف متفاوت را می‌بندند.
دوره امنیت سایبری خوب دقیقاً چه چیزی را عوض میکند
پیش از هر معیاری، تعریف نتیجه را روشن کنیم. خروجی یک دورهی امنیت، «آشنایی» نیست؛ تغییر رفتار قابل مشاهده است. برای یک فرد یعنی بتواند روی یک برنامه‌ی ناآشنا سطح حمله را نقشه‌برداری کند، فرضیه بسازد و یافته را اثبات کند. برای یک تیم توسعه یعنی الگوی کدی که تا دیروز می‌نوشتند عوض شود و همان دستهی نقص در تست بعدی تکرار نشود.
این تعریف بلافاصله چند نوع دوره را حذف میکند: دوره‌ای که فقط تعریف آسیب‌پذیری‌ها را مرور میکند، دوره‌ای که خروجی‌اش صرفاً یک گواهی حضور است، و دوره‌ای که همه‌ی تمرین‌هایش تماشای ویدیوی حل مسئله است. اگر پس از پایان دوره نتوانید یک کار مشخص را انجام دهید که پیش از آن نمی‌توانستید، آن دوره کار نکرده — فارغ از اینکه چقدر خوب ارائه شده باشد.
«در پایان این دوره، شرکت‌کننده دقیقاً چه کاری را می‌تواند انجام دهد که الان نمی‌تواند، و با چه سنجه‌ای آن را نشان می‌دهید؟» پاسخ روشن به این سؤال، بیشتر از هر سرفصلی درباره‌ی کیفیت دوره می‌گوید. پاسخ مبهم هم به‌اندازه‌ی کافی گویاست.
تیزترین فیلتر: سرفصل بر پایهی OWASP Top 10:2025 است یا ۲۰۲۱؟
این ساده‌ترین و کاربردی‌ترین فیلتری است که می‌توانید بدون دانش تخصصی اعمال کنید. نسخهی جاری منتشرشده‌ی OWASP Top 10، ویرایش ۲۰۲۵ است — هشتمین نسخهی این فهرست. اگر سرفصل یک دوره هنوز روی ۲۰۲۱ است، یعنی محتوا دست‌کم یک نسل عقب مانده و احتمالاً بقیهی جزئیاتش هم همین‌قدر قدیمی است.
چرا این تفاوت واقعی است و صرفاً تغییر شماره نیست:
| در سرفصل ۲۰۲۱ | در OWASP Top 10:2025 | چرا برای تیم توسعه فرق میکند |
|---|---|---|
| A10:2021 — SSRF یک دستهی مستقل | SSRF در A01:2025 Broken Access Control ادغام شده | SSRF دیگر یک «آسیب‌پذیری خاص» نیست؛ نمونه‌ای از شکست کنترل دسترسی است و آموزشش باید کنار آن باشد |
| A06:2021 — Vulnerable and Outdated Components | A03:2025 Software Supply Chain Failures — دامنه‌ی بسیار وسیع‌تر | موضوع دیگر فقط «کتابخانه‌ی قدیمی» نیست؛ کل فرایند ساخت، توزیع و به‌روزرسانی و خط لوله‌ی CI/CD را در بر میگیرد |
| A05:2021 — Security Misconfiguration در رتبهی ۵ | A02:2025 — صعود به رتبهی ۲ | وزن آموزشی پیکربندی امن باید بالا برود، نه اینکه در انتهای دوره چند اسلاید بگیرد |
| — | A10:2025 Mishandling of Exceptional Conditions (دستهی کاملاً جدید) | مدیریت خطا، حالت شکست امن و آزادسازی منابع، موضوع آموزشی مستقل شده‌اند |
| A09:2021 — Logging and Monitoring Failures | A09:2025 — Logging and Alerting Failures | تغییر تمرکز از جمع‌آوری منفعل لاگ به هشدار و واکنش عملی |
چند نشانه‌ی دیگر از سرفصل کهنه که به همین سادگی قابل تشخیص است: نوشتن «OWASP ZAP» (این ابزار از سپتامبر ۲۰۲۳ از OWASP جدا شده و نام درستش ZAP یا ZAP by Checkmarx است)، نام بردن از «Burp Suite Enterprise Edition» (که به Burp Suite DAST تغییر نام داده)، و امتیازدهی شدت فقط با CVSS v3.1 بدون هیچ اشاره‌ای به CVSS v4.0. مروری بر خود دسته‌ها را در راهنمای OWASP Top 10 و صفحه‌ی OWASP در دانشنامه آورده‌ایم.
روش‌شناسی می‌آموزد یا کلیک روی ابزار؟
تفاوت این دو در ساختار سرفصل دیده می‌شود، نه در ادعای تبلیغاتی. دورهی ابزارمحور فصل‌هایش نام ابزار است: «فصل ۳: کار با Nmap»، «فصل ۵: sqlmap». دورهی روش‌محور فصل‌هایش مرحلهی کار است: شناسایی و نقشه‌برداری سطح حمله، آزمون مدیریت نشست، آزمون کنترل دسترسی، آزمون منطق کسب‌وکار، گزارش.
مرجع فنی این ساختار، OWASP WSTG است. نسخهی پایدار جاری آن v4.2 است (منتشرشده در سال ۲۰۲۰؛ نسخهی ۵ در دست توسعه است و پروژه یک نسخهی وب «پایدار» را به‌روز نگه می‌دارد). این راهنما حدود ۹۷ آزمون نام‌گذاری‌شده را در ۱۲ دسته سازمان میدهد و هر آزمون شناسه‌ی خودش را دارد — مثلاً WSTG-ATHZ-04 برای IDOR. یک دورهی جدی می‌تواند سرفصلش را به این شناسه‌ها نگاشت کند؛ اگر نتواند، یعنی پوشش سیستماتیکی در کار نیست.
«دوره‌ای که ابزارهای بیشتری آموزش دهد بهتر است.» عکس آن درست است. فهرست بلند ابزار معمولاً نشانه‌ی نبود روش است — و اغلب شامل ابزارهایی است که جایگاهشان در تست نفوذ وب کوچک یا منسوخ شده. دو نمونه‌ی رایج: Metasploit یک چارچوب بهره‌برداری شبکه و میزبان است و در تست وب کاربرد محدودی دارد؛ Nikto یک اسکنر وب‌سرور قدیمی و پرنویز است که برنامه‌های امروزی، SPA و API را نمی‌فهمد. دوره‌ای که این‌ها را کنار Burp به‌عنوان «ابزارهای اصلی تست نفوذ وب» می‌گذارد، محتوایش را از منابع قدیمی برداشته است.
یک سؤال دقیق برای سنجش: «برای کشف نقص کنترل دسترسی چه رویکردی آموزش می‌دهید؟» اگر پاسخ نام یک ابزار بود، دوره را رد کنید. هیچ اسکنری نمی‌تواند بداند کدام کاربر مجاز به دیدن کدام رکورد است؛ این دسته — که در OWASP Top 10:2025 رتبهی اول است — فقط با آزمون دستی و درک منطق برنامه پیدا می‌شود.
مدرس کیست و واقعاً چه چیزی تست کرده
در آموزش امنیت، فاصله‌ی بین «کسی که موضوع را خوانده» و «کسی که موضوع را انجام داده» در همان جلسهی اول معلوم می‌شود — چون مدرس دستهی دوم می‌تواند بگوید کجاها روش شکست خورده و چرا. چند سؤال قابل طرح و قابل راستی‌آزمایی:
- نمونه‌ی گزارش بی‌خطرشده. ساختار گزارش، نحوه‌ی مستندسازی شواهد و کیفیت توصیه‌های رفع، مستقیم‌ترین شاخص تجربه‌ی میدانی است.
- خروجی عمومی قابل بررسی. گزارش‌های افشاشده، CVE ثبت‌شده، ابزار یا افزونه‌ی منتشرشده، یا نوشته‌های فنی دارای عمق.
- روش‌شناسی مورد استفاده. بپرسید پوشش آزمون بر چه پایه‌ای تعریف می‌شود. پاسخ حرفه‌ای به WSTG و طبقه‌بندی ریسک با OWASP Top 10 و CWE اشاره میکند.
- حد و مرزها. مدرسی که می‌گوید «این ابزار این کار را انجام نمی‌دهد» یا «این ادعا اثبات‌نشده است»، صادق‌تر از کسی است که همه‌چیز را قطعی می‌گوید.
«این دوره استخدام را تضمین میکند.» هیچ دوره‌ای نمی‌تواند استخدام را تضمین کند، چون تصمیم استخدام دست کارفرماست و مبتنی بر ارزیابی عملی و نمونه‌کار است. همچنین مراقب ادعای «گواهی معتبر بینالمللی» بدون نام بردن از نهاد صادرکننده باشید. و یک نکته‌ی قطعی: «گواهی OWASP» وجود ندارد — OWASP یک بنیاد غیرانتفاعی است که استاندارد منتشر میکند و هیچ برنامه‌ی صدور گواهی برای Top 10 یا WSTG ندارد.
زمان واقعی آزمایشگاه، نه تعداد اسلاید
مهارت امنیت وب با تکرار ساخته می‌شود، نه با تماشا. معیار عملی: دست‌کم نیمی از زمان دوره باید صرف کاری شود که شرکت‌کننده خودش انجام میدهد. در دوره‌های سازمانی توسعهی امن، این نسبت باید بالاتر هم برود، چون هدف تغییر عادت کدنویسی است.
چند سؤال مشخص درباره‌ی آزمایشگاه:
- محیط تمرین چیست و چطور در دسترس قرار میگیرد؟ محیط‌های قانونی و رایج شامل PortSwigger Web Security Academy، OWASP Juice Shop و برنامه‌های آسیبپذیر عمدی خودمیزبان (مثلاً روی Docker) است.
- آیا شرکت‌کننده پس از دوره هم به محیط دسترسی دارد؟ تکرار پس از دوره، همان چیزی است که یادگیری را تثبیت میکند.
- در دورهی سازمانی: آیا تمرین‌ها روی استک واقعی خود تیم اجرا می‌شود؟ تمرین روی زبان و فریم‌ورکی که تیم هر روز با آن کار میکند، چند برابر تمرین عمومی اثر دارد.
هیچ دورهی حرفه‌ای‌ای تمرین روی سامانه‌ی متعلق به دیگری را تجویز نمی‌کند. اگر دوره‌ای «تمرین روی هدف واقعی» را به‌عنوان مزیت تبلیغ میکند و منظورش سامانه‌ای بیرون از مالکیت یا مجوز کتبی است، آن دوره شما را در معرض مسئولیت حقوقی قرار میدهد. تمرین قانونی یعنی محیط آزمایشگاهی، محیط خودمیزبان، یا دامنه‌ی اعلام‌شده‌ی یک برنامه‌ی رسمی باگ‌بانتی.
برای آشنایی با ابزاری که بیشترین زمان آزمایشگاه صرف آن می‌شود، Burp Suite نقطه‌ی شروع است؛ و ترتیب کلی مهارت‌ها در نقشه راه یادگیری تست نفوذ وب آمده است.
دورهی فردی در برابر دورهی سازمانی توسعهی امن
این دو محصول متفاوت‌اند و اشتباه گرفتنشان پرهزینه است. یک تیم توسعهی ده‌نفره که ثبت‌نام انفرادی در یک دورهی «تست نفوذ» میکند، پول را برای هدف اشتباه خرج کرده: توسعه‌دهنده لازم نیست تست‌کننده شود؛ لازم است کدی بنویسد که در تست نمی‌شکند.
| دورهی فردی | دورهی سازمانی توسعهی امن | |
|---|---|---|
| هدف | ساخت مهارت شخصی و مسیر شغلی | کاهش نقص امنیتی در کدی که تیم تولید میکند |
| مخاطب | فرد، با سطح و انگیزه‌ی شخصی | تیم توسعه، QA و DevOps با استک مشترک |
| سرفصل | عمومی و مستقل از سازمان | نگاشت‌شده به زبان، فریم‌ورک و معماری واقعی همان تیم |
| تمرین | محیط آزمایشگاهی عمومی | نمونه‌کدهای بی‌خطرشده‌ی خود تیم و یافتههای تست نفوذ قبلی همان سازمان |
| سنجش | آزمون پایانی یا حل آزمایشگاه | متریک فرایندی: چگالی نقص، نرخ تکرار یافته، زمان تا رفع |
| خروجی | مهارت و نمونه‌کار فردی | چک‌لیست بازبینی امن، الگوهای امن مشترک و تغییر در تعریف «انجام‌شده» |
اگر به‌دنبال مسیر فردی هستید، فهرست دوره‌ها و کلاس‌ها نقطه‌ی شروع است. اگر مدیر فنی هستید و می‌خواهید سرفصل روی استک خودتان بسته شود و اثرش سه ماه بعد با عدد گزارش شود، دورهی سازمانی توسعهی امن دقیقاً برای همین طراحی شده است.
سرفصل آموزش توسعهی امن برای تیم توسعه چه باید داشته باشد
سرفصل خوب، فهرست آسیب‌پذیری نیست؛ نگاشتی است بین دسته‌های ریسک و کاری که تیم در چرخه‌ی توسعهی خودش انجام میدهد. هستهی حداقلی که هر دورهی سازمانی باید داشته باشد:
| موضوع | تیم چه چیزی یاد میگیرد | لنگرگاه در OWASP Top 10:2025 |
|---|---|---|
| مدلسازی تهدید در جلسهی طراحی | پیش از نوشتن کد، سناریوی سوءاستفاده را کنار سناریوی استفاده بنویسند؛ مرز اعتماد را مشخص کنند | A06:2025 Insecure Design — «طراحی ناامن را پیاده‌سازی بی‌نقص هم درست نمی‌کند» |
| کنترل دسترسی سمت سرور | الگوی متمرکز مجوزدهی، رد پیش‌فرض، بررسی مالکیت رکورد در هر درخواست | A01:2025 Broken Access Control |
| پیکربندی امن و سخت‌سازی | فرایند تکرارپذیر یکسان در توسعه، تست و تولید؛ حذف نمونه‌ها و قابلیت‌های غیرلازم؛ هدرهای امنیتی | A02:2025 Security Misconfiguration |
| وابستگی‌ها، SBOM و زنجیرهی تأمین | سیاهه‌ی متمرکز و پیوسته‌ی اجزا، دریافت فقط از منبع رسمی با تأیید امضا، تفکیک وظایف در خط لوله | A03:2025 Software Supply Chain Failures |
| ورودی، خروجی و تزریق | جداسازی داده از دستور با پرس‌وجوی پارامتری، اعتبارسنجی مثبت سمت سرور، کدگذاری خروجی متناسب با زمینه | A05:2025 Injection (شامل XSS) |
| احراز هویت و نشست | MFA، مدیریت نشست سمت سرور، اعتبارسنجی ادعاهای aud و iss در JWT | A07:2025 Authentication Failures |
| مدیریت خطا و حالت شکست | شکست امن به‌جای شکست باز، آزادسازی منابع، پیام خطای بدون افشای جزئیات | A10:2025 Mishandling of Exceptional Conditions |
| لاگ و هشدار | ثبت رویدادهای امنیتی با زمینه‌ی کافی، کدگذاری خروجی لاگ برای جلوگیری از تزریق لاگ | A09:2025 Logging and Alerting Failures |
سه بخش عملی که سرفصل را از «کلاس» به «تغییر فرایند» تبدیل میکند
- بازبینی کد امن. نه به‌عنوان مفهوم، بلکه به‌شکل یک چک‌لیست عملیاتی برای Pull Request. جزئیات روش در بازبینی کد امن آمده است.
- SAST و DAST در خط لوله‌ی CI/CD. با انتظارات واقع‌بینانه: تحلیل ایستا دسته‌های تزریق و کاربرد نادرست رمزنگاری را خوب میگیرد و نقص کنترل دسترسی و منطق کسب‌وکار را تقریباً هرگز پیدا نمی‌کند. تیم باید یاد بگیرد یافتهها را تریاژ کند، وگرنه خط لوله را دور می‌زند.
- پیش‌فرض‌های امن و «جاده‌ی آسفالت». کتابخانه و الگوی داخلی که مسیر امن را آسان‌ترین مسیر کند. این مؤثرترین کنترل بلندمدت است، چون به حافظه‌ی افراد وابسته نیست.
برای پیوند دادن این سرفصل به تصویر کلی امنیت برنامه، امنیت اپلیکیشن وب و برای شروع کار مدلسازی تهدید، مدلسازی تهدید نقطه‌ی ورود مناسبی هستند.
اثر آموزش را چطور اندازه بگیریم
آموزشی که سنجیده نمی‌شود، در بودجه‌ی سال بعد اولین چیزی است که حذف می‌شود. سنجش اثر پیچیده نیست، اما یک شرط دارد: متریک پایه باید پیش از دوره ثبت شود.
| متریک | تعریف عملیاتی | سیگنال موفقیت | دام |
|---|---|---|---|
| چگالی نقص امنیتی | تعداد یافتههای امنیتی بهازای واحد کار (اسپرینت، هزار خط کد یا سرویس) | کاهش پایدار در چند دورهی متوالی، نه یک اسپرینت | تغییر حجم یا نوع کار، عدد را جابه‌جا میکند؛ همیشه نرمال‌سازی کنید |
| نرخ تکرار یافتهها | سهم یافتههای تست نفوذ جدید که در همان دستهی تست قبلی هم وجود داشت | افت این نرخ، قویترین شاهد اثر آموزش است | نیازمند طبقه‌بندی یکنواخت یافتهها بین دو تست (با CWE یا دستهی OWASP) |
| زمان تا رفع | میانهی فاصله‌ی گزارش تا تأیید رفع، تفکیک‌شده بر اساس شدت | کاهش میانه، به‌ویژه در شدت‌های بالا | میانگین را گزارش نکنید؛ چند مورد طولانی آن را بی‌معنا میکند |
| یافتههای بازبینی کد | تعداد مسائل امنیتی که در Pull Request گرفته می‌شود | افزایش اولیه (یعنی تیم دارد میبیند)، سپس کاهش | افزایش اولیه را شکست تعبیر نکنید — انتقال کشف به مرحلهی زودتر، هدف است |
| نقص فرارکرده | مسائل امنیتی که تا محیط تولید یا تا تست نفوذ رسیده‌اند | کاهش سهم آن‌ها از کل یافتهها | وابسته به پوشش تست؛ بدون تست منظم، عدد گمراه‌کننده است |
یک بازه‌ی سنجش واقع‌بینانه، حدود سه ماه پس از دوره است — کمتر از آن، هنوز کد کافی نوشته نشده تا تفاوت دیده شود. و برای اینکه «نرخ تکرار یافتهها» اصلاً قابل محاسبه باشد، به یک چرخه‌ی منظم مدیریت آسیب‌پذیری نیاز دارید که یافتهها را با طبقه‌بندی یکسان ثبت و پیگیری کند.
مدل قهرمان امنیت (Security Champion)
مؤثرترین ساختاری که یک سازمان می‌تواند پس از دوره برپا کند، معمولاً استخدام یک نفر جدید نیست؛ انتخاب یک نفر از داخل هر تیم توسعه است. قهرمان امنیت یک توسعه‌دهنده‌ی معمولی است که بخشی از وقتش رسماً به امنیت اختصاص یافته.
چیزی که این نقش را کارآمد میکند و چیزی که آن را به یک عنوان تشریفاتی تبدیل میکند، در جزئیات است:
- وقت رسمی، نه داوطلبانه. اگر سهم مشخصی از ظرفیت اسپرینت به این کار اختصاص نیابد، اولین ددلاین آن را حذف میکند.
- مسئولیت روشن. بازبینی امنیتی Pull Requestهای حساس، طرح سؤال امنیتی در جلسهی طراحی، تریاژ اولیه‌ی یافتههای ابزارها، و پیگیری رفع.
- آموزش عمیقتر از بقیهی تیم. قهرمان امنیت به یک لایه‌ی آموزش تخصصی‌تر نیاز دارد — معمولاً کارگاه تکموضوعی مثل مدلسازی تهدید یا بازبینی کد امن.
- مسیر ارجاع مشخص. باید بداند چه چیزی را خودش تصمیم میگیرد و چه چیزی را به تیم امنیت یا مشاور بیرونی ارجاع میدهد.
در سازمان‌های کوچک، یک قهرمان برای کل تیم فنی کافی است؛ در سازمان‌های بزرگ‌تر، یک نفر بهازای هر تیم محصول. رابطه‌ی این نقش با تیم آزمون بیرونی و تقسیم کار بین آن‌ها در ساختار تیم تست نفوذ شرح داده شده است.
آموزش جایگزین تست نیست، تست هم جایگزین آموزش نیست
این صادقانه‌ترین جمله‌ای است که یک ارائه‌دهنده‌ی هر دو خدمت می‌تواند بگوید: این دو یکدیگر را جایگزین نمی‌کنند، چون دو شکاف متفاوت را می‌بندند.
آموزش، نرخ تولید نقص را پایین میآورد. اثرش بلندمدت، تدریجی و روی کدی است که هنوز نوشته نشده. اما آموزش هیچ تضمینی درباره‌ی کدی که همین حالا در تولید اجرا می‌شود نمی‌دهد، و هیچ آموزشی مانع خطای انسانی نمی‌شود.
تست نفوذ، وضعیت فعلی را میسنجد. یافتهی واقعی و قابل اثبات میدهد، اما نقطهای در زمان است: گزارش امروز درباره‌ی کدی که فردا نوشته می‌شود چیزی نمی‌گوید. سازمانی که فقط تست میخرد، هر سال همان دستهی یافتهها را میبیند و هزینه‌ی رفع را تکرار میکند — و دقیقاً همین «نرخ تکرار یافتهها» است که نشان میدهد شکاف در دانش تیم است، نه در پوشش تست.
«ما WAF داریم و تیم را هم آموزش داده‌ایم، پس تست لازم نیست.» WAF ساختاراً نسبت به مهم‌ترین دسته‌ها نابیناست: نقص کنترل دسترسی (A01:2025)، منطق کسب‌وکار، شرایط رقابتی و بخش عمده‌ی XSS مبتنی بر DOM را نمی‌بیند، و قابل دور زدن است. WAF یک لایه‌ی کاهش ریسک است، نه رفع آسیب‌پذیری در کد. هرگز «نصب WAF» را به‌عنوان راه‌حل یک نقص سطح کد نپذیرید.
ترکیب کارآمد ساده است: مدلسازی تهدید در طراحی، آموزش و الگوهای امن در توسعه، بازبینی کد و ابزار در خط لوله، و تست نفوذ دوره‌ای به‌عنوان راستی‌آزمایی مستقل — با آزمون مجدد پس از رفع. اگر مطمئن نیستید نقطه‌ی شروع تیم شما کدام است، یک جلسهی مشاوره برای تعیین ترتیب کار، ارزان‌ترین قدم اول است.
پرسش‌های متداول
چطور یک دوره امنیت سایبری خوب را از دورهی بیکیفیت تشخیص دهم؟
با چهار فیلتر، بهترتیب سرعت: (۱) سرفصل بر پایهی OWASP Top 10:2025 است یا هنوز ۲۰۲۱؟ (۲) فصلها نام مرحلهی کار است یا نام ابزار؟ (۳) چند درصد زمان، تمرین عملی روی محیط قانونی است؟ (۴) مدرس چه خروجی قابل بررسیای دارد — نمونه گزارش، CVE، ابزار یا نوشتهی فنی؟ نشانههای هشدار: تضمین استخدام، «گواهی معتبر بینالمللی» بدون نام نهاد صادرکننده، و ادعای «گواهی OWASP» که اصلاً وجود ندارد.
سرفصل دوره باید بر اساس OWASP Top 10 کدام سال باشد؟
ویرایش ۲۰۲۵. این نسخهی جاری منتشرشده است و تفاوتهایش با ۲۰۲۱ ساختاری است، نه صوری: SSRF در دستهی کنترل دسترسی ادغام شده، دستهی اجزای آسیبپذیر به «شکست زنجیرهی تأمین نرمافزار» گسترش یافته، پیکربندی نادرست به رتبهی دوم صعود کرده و یک دستهی کاملاً جدید برای مدیریت شرایط استثنایی اضافه شده است. سرفصل ۲۰۲۱ یعنی محتوا یک نسل عقب است.
دوره امنیت برای تیم توسعه چند جلسه باید باشد؟
عدد ثابتی وجود ندارد و به هدف بستگی دارد. برای پوشش هستهی توسعهی امن روی استک یک تیم، یک دورهی چندجلسهای با تمرین بین جلسات معمولاً از یک بوتکمپ فشردهی یکباره اثر ماندگارتری دارد، چون فرصت تمرین روی کد واقعی بین جلسات ایجاد میکند. برای بستن یک ضعف مشخص (مثلاً مدلسازی تهدید یا مدیریت Secrets)، کارگاه کوتاه تکموضوعی کافی است. معیار درست، تعداد جلسه نیست؛ سنجش اثر سه ماه بعد است.
آموزش توسعه امن جای تست نفوذ را میگیرد؟
خیر، و برعکسش هم درست نیست. آموزش نرخ تولید نقص را پایین میآورد و اثرش روی کدی است که هنوز نوشته نشده. تست نفوذ وضعیت فعلی سامانه را میسنجد و یافتهی اثباتپذیر میدهد، اما نقطهای در زمان است. سازمانی که فقط تست میخرد هر سال همان دسته یافتهها را میبیند؛ سازمانی که فقط آموزش میخرد، از وضعیت فعلی تولیدش بیخبر میماند.
چطور بفهمم دوره روی تیم اثر داشته است؟
با ثبت متریک پایه پیش از دوره و مقایسهی آن حدود سه ماه بعد. سه متریک اصلی: چگالی نقص امنیتی بهازای واحد کار، نرخ تکرار یافتهها در تستهای نفوذ متوالی (قویترین شاهد)، و میانهی زمان تا رفع به تفکیک شدت. انتظار داشته باشید یافتههای بازبینی کد ابتدا افزایش پیدا کند؛ این یعنی تیم شروع کرده به دیدن مسائل، و انتقال کشف به مرحلهی زودتر دقیقاً هدف است.
مدل Security Champion برای تیم کوچک هم جواب میدهد؟
بله، و در تیم کوچک حتی سادهتر است: یک نفر برای کل تیم فنی کافی است. سه شرط موفقیت: سهم مشخصی از ظرفیت اسپرینت رسماً به این کار اختصاص یابد (نه کار داوطلبانهی بعد از ساعت کاری)، مسئولیتها روشن باشد (بازبینی امنیتی PR، سؤال امنیتی در جلسهی طراحی، تریاژ یافتهها)، و آن فرد یک لایه آموزش عمیقتر از بقیهی تیم ببیند.
منابع
علیرضا کیا
متخصص تست نفوذ وب و اندروید با سابقه‌ی مدیریت تیم نفوذ در داتین. مهندسی معکوس اپ‌ها و کشف ذخیره‌سازی ناامن، تخصص اوست.