وقتی سازمانی برای اولین بار به آزمون امنیتی نیاز پیدا میکند، پرسش اغلب اشتباه مطرح میشود. پرسش درست «چطور یک نفوذگر پیدا کنم؟» نیست — پرسش درست این است: «چطور تشخیص دهم این کارشناس تست نفوذ یا این تیم، کار حرفهای و قابل دفاع تحویل میدهد؟» تفاوت این دو پرسش، تفاوت میان یک پروژه‌ی مهندسی با مجوز، دامنه و گزارش قابل ممیزی است و یک ماجرای پرریسک حقوقی. این راهنما معیارهای سنجش را میدهد: چه چیزی بخواهید، گواهی‌نامه‌ها چه چیزی را ثابت می‌کنند و چه چیزی را نه، کدام رفتارها نشانه‌ی هشدارند، و مرزهای قانونی کار کجاست.
در یک نگاه
- شش سنجه‌ی اصلی: شفافیت متدولوژی، نمونهی گزارش سانسورشده، معرف قابل تماس، آمادگی برای NDA، سیاست آزمون مجدد، و تسترهای نام‌دار با سابقه‌ی قابل راستی‌آزمایی.
- گواهی‌نامه‌های معتبر و عملی در حوزه‌ی وب: OSCP، OSWE، BSCP و اعتبارسنجی CREST. راهنمای PCI هم OSCP، CEH و GIAC را در کنار «تجربه‌ی عملی مرتبط» نام می‌برد.
- «OWASP Certified»، «PTES Certified» و «OSSTMM Compliant» وجود خارجی ندارند. دیدن این عبارت‌ها در رزومه یا پیشنهاد، خودش یک نشانه‌ی هشدار است.
- نشانه‌های هشدار: تضمین تعداد یافته، «هک می‌کنیم و نشان می‌دهیم»، نبود فرایند مجوز کتبی، نبود پرسشنامهی اسکوپینگ، و اعلام قیمت پیش از اسکوپینگ.
- هر ارائه‌دهنده‌ای که پیشنهاد آزمون سامانه‌ای را بدهد که مالکش نیستید یا دسترسی به حسابی که در اختیار شما نیست، در حال ارتکاب جرم است و باید از او پرهیز کرد.
چرا «کارشناس تست نفوذ» و نه «نفوذگر»
تست نفوذ یک فعالیت مهندسی با چارچوب مشخص است: دامنهی مکتوب، مجوز امضاشده، متدولوژی قابل ارجاع، شواهد بازتولیدپذیر و گزارش قابل ممیزی. مهارت تهاجمی فقط یکی از ورودی‌های این کار است؛ بقیه‌اش نظم فرایندی، توان مستندسازی و درک کسبوکار مشتری است.
به همین دلیل، معیار انتخاب هم متفاوت است. کسی که میتواند یک آسیب‌پذیری پیدا کند اما نمی‌تواند دامنه تعریف کند، شواهد مستند کند، شدت را با مرجع استاندارد توضیح دهد و راهکار قابل اجرا بنویسد، برای سازمان شما ارزش عملیاتی کمی تولید میکند. یافته‌ای که تیم توسعه نمی‌تواند بازتولید کند، رفع نمیشود.
و بُعد حقوقی: در ایران — مانند بیشتر کشورها — دسترسی غیرمجاز به سامانههای رایانه‌ای جرم است و قانون جرایم رایانه‌ای برای آن مجازات تعیین کرده. تفاوت میان کار قانونی و جرم، تنها یک چیز است: مجوز کتبی از مالک سامانه، با دامنه و بازه‌ی زمانی مشخص. کارشناسی که این سند را بدیهی و اولین قدم می‌داند، دارد به شما میگوید که چارچوب را می‌شناسد. جزئیات و قالب این سند در قرارداد و مجوز تست نفوذ آمده است.
اگر تعریف پایه و جایگاه این کار برایتان تازه است، تست نفوذ چیست نقطه‌ی شروع بهتری از این مقاله است.
شش چیزی که باید پیش از انتخاب بررسی کنید
۱) شفافیت متدولوژی
بخواهید متدولوژی را نام ببرند و بگویند پوشش را با چه چیزی می‌سنجند. پاسخ حرفهای مشخص است: پوشش فنی بر پایهی OWASP WSTG v4.2، ردهبندی ریسک با OWASP Top 10:2025 و CWE، امتیازدهی با CVSS (با ذکر نسخه)، و ساختار چرخه بر پایهی فازهای PTES و NIST SP 800-115. اگر پاسخ «ما تجربه‌ی زیادی داریم و همه‌چیز را تست می‌کنیم» است، هیچ سنجه‌ای برای پوشش وجود ندارد. بحث تفصیلی در متدولوژی تست نفوذ.
۲) نمونهی گزارش سانسورشده
این مؤثرترین آزمون یک ارائه‌دهنده است. نسخه‌ی سانسورشده باید ساختار کامل، عمق یک یافته‌ی واقعی، و شکل شواهد را نشان دهد. اگر پاسخ «به‌دلیل محرمانگی نمی‌توانیم» بود، توجه کنید که سانسور کردن یک گزارش کار سختی نیست؛ نداشتن نمونه معمولاً معنای دیگری دارد. چه چیزی را در نمونه ببینید، در گزارش تست نفوذ فهرست شده.
۳) معرف قابل تماس
نه فقط لوگو روی صفحه‌ی مشتریان. یک یا دو مشتری که حاضر باشند تلفنی درباره‌ی کیفیت گزارش، پاسخ‌گویی در فاز رفع و انجام آزمون مجدد صحبت کنند. طبیعی است که نام مشتریان حساس محرمانه باشد، اما یک ارائه‌دهنده‌ی جاافتاده حداقل چند مرجع دارد.
۴) آمادگی برای NDA و تعیین تکلیف داده
تیم آزمون در جریان کار به داده‌ی واقعی، لاگ درخواست‌ها و شواهد دسترسی پیدا میکند. باید مکتوب باشد: NDA دوطرفه، مدت نگهداری داده‌ی پروژه، محل نگهداری، و سازوکار امحا. ارائه‌دهنده‌ای که از امضای NDA طفره میرود یا نمی‌داند داده را کجا نگه می‌دارد، ریسک عملیاتی است.
۵) سیاست آزمون مجدد
سه پرسش دقیق: چند نوبت؟ تا چه مدت پس از تحویل گزارش؟ کل یافته‌ها یا فقط بحرانی و بالا؟ آزمون مجدد بخشی از کار است نه افزودنی؛ در PCI DSS بند ۱۱٫۴٫۴ هم تکرار آزمون برای تأیید رفع الزام است.
۶) تسترهای نام‌دار با سابقه‌ی قابل راستی‌آزمایی
بپرسید چه کسانی روی پروژه کار می‌کنند و چه کسی گزارش را امضا میکند. سابقه‌ی قابل راستی‌آزمایی شکل‌های متعددی دارد: گواهی‌نامه‌ی عملی، سابقه‌ی مستند در برنامه‌های باگ‌بانتی، CVE منتشرشده، ارائه در رویدادهای تخصصی، یا مشارکت در پروژه‌های متن‌باز. الگوی رایج و نامطلوب در بازار این است که فروش با یک تیم ارشد انجام شود و اجرا با نیروی تازه‌کار.
گواهی‌نامه‌ها: کدام‌ها معنا دارند و چه چیزی را ثابت می‌کنند
گواهی‌نامه شرط لازم نیست و شرط کافی هم نیست، اما سیگنال قابل بررسی است — به‌شرط اینکه بدانید هر کدام چه چیزی را می‌سنجد.
| گواهی‌نامه | ماهیت آزمون | چه چیزی را ثابت میکند |
|---|---|---|
| OSCP (Offensive Security Certified Professional) | آزمون عملی چند‌ساعته در محیط آزمایشگاهی، به‌همراه گزارش‌نویسی | توان بهره‌جویی عملی و نظم گزارش‌دهی. تمرکزش بیشتر شبکه و میزبان است تا وب |
| OSWE (Offensive Security Web Expert) | آزمون عملی با تمرکز بر بهره‌جویی از برنامه‌های وب و بازبینی کد منبع | نزدیک‌ترین گواهی به کار واقعی تست نفوذ وب در سطح پیشرفته |
| BSCP (Burp Suite Certified Practitioner) | آزمون عملی PortSwigger روی سناریوهای وب | تسلط عملی بر آزمون برنامه‌ی وب و ابزار محور کار |
| CREST | نهاد اعتبارسنجی که هم افراد و هم شرکت‌ها را ارزیابی میکند | در بازارهایی که این چارچوب پذیرفته شده، سیگنال بلوغ فرایندی سازمان است |
| CEH، GIAC | در راهنمای تست نفوذ PCI به‌عنوان نمونه نام برده شده‌اند | آشنایی با دامنهی دانش؛ CEH در سطح مفهومی است و جای آزمون عملی را نمی‌گیرد |
راهنمای Penetration Testing Guidance شورای PCI (نسخه‌ی ۱٫۱، سپتامبر ۲۰۱۷) گواهی‌نامه‌هایی مثل OSCP، CEH و GIAC را در کنار تجربه‌ی عملی مرتبط به‌عنوان معیار صلاحیت تستر نام می‌برد — نه به‌جای آن. توجه کنید که این سند برای شماره‌گذاری قدیمی (بند ۱۱٫۳) نوشته شده و برای نسخه‌ی ۴٫x به‌روزرسانی نشده، هرچند مدل سه‌فازی و راهنمای صلاحیت آن همچنان مفید است.
«OWASP Certified»، «گواهی OWASP»، «PTES Certified» و «OSSTMM Compliant» هیچکدام وجود خارجی ندارند. OWASP یک بنیاد غیرانتفاعی تولیدکنندهی استاندارد و راهنماست و نهاد صدور گواهی نیست. PTES هم نهاد راهبری، سازوکار صدور گواهی و چرخه‌ی به‌روزرسانی ندارد — نسخه‌ی ۲٫۰ آن بیش از یک دهه «به‌زودی» بوده و هرگز منتشر نشده. OSSTMM هم آخرین‌بار در نسخه‌ی ۳٫۰۲ به تاریخ دسامبر ۲۰۱۰ منتشر شده و نسخه‌ی ۴ عمومی نیست. دیدن هر یک از این عبارت‌ها در رزومه یا پیشنهاد، نشان میدهد نویسنده استانداردها را نمی‌شناسد. عبارت درست این است: «پوشش آزمون بر پایهی WSTG v4.2 و ردهبندی ریسک بر پایهی OWASP Top 10:2025».
نشانه‌های هشدار: کجا مکالمه را تمام کنید
| نشانه | چرا مشکل است |
|---|---|
| «تضمین می‌کنیم حداقل n آسیب‌پذیری پیدا کنیم» | تعداد یافته را نمی‌توان تضمین کرد. تضمین کردنش یعنی انگیزه‌ی ساختن یافته‌ی بی‌اهمیت برای پر کردن سهمیه |
| «هک می‌کنیم و نشان می‌دهیم» یا «یک بار نفوذ می‌کنیم تا باور کنید» | کار حرفهای با مجوز و دامنه شروع میشود، نه با نمایش. این عبارت نشان میدهد چارچوب حقوقی جدی گرفته نمیشود |
| نبود فرایند مجوز کتبی | شما را در معرض ریسک حقوقی می‌گذارد و نشان میدهد ارائه‌دهنده هم تحت پوشش نیست |
| نبود پرسشنامهی اسکوپینگ | بدون دانستن تعداد نقشها و جریانهای کسبوکار، نه برآورد ممکن است و نه آزمون منطق |
| اعلام قیمت پیش از اسکوپینگ | عدد قطعی بدون دیدن دامنه یعنی کار از پیش تعیین‌شده است — معمولاً چند ساعت اجرای اسکنر |
| ادعای «۱۰۰٪ امنیت» یا «سایت شما را نفوذناپذیر می‌کنیم» | هیچ آزمونی نبود آسیب‌پذیری را اثبات نمی‌کند. این ادعا از اساس غیرفنی است |
| سرویس‌های جانبی مثل «بازیابی حساب» یا «دسترسی به اکانت» | این‌ها خدمات امنیتی نیستند. ارائه‌دهنده‌ای که چنین چیزی می‌فروشد، هم‌زمان با شما هم قابل اعتماد نیست |
| گزارش نمونه‌ای که خروجی PDF یک ابزار است | یعنی محصول نهایی همان است. نشانه‌های تشخیص در مقاله‌ی گزارش آمده |
| نبود بیمه‌ی مسئولیت یا امتناع از تعهد قراردادی | آزمون روی محیط عملیاتی ریسک عملیاتی دارد؛ تقسیم مسئولیت باید مکتوب باشد |
یک نشانه‌ی ظریف‌تر که کمتر گفته میشود: ارائه‌دهنده‌ای که هیچ سؤالی از شما نمی‌پرسد. کارشناس واقعی در جلسه‌ی اول ده‌ها سؤال دارد — معماری، نقشها، جریانهای حساس، محیط‌ها، الزامات انطباق، پنجره‌های زمانی ممنوع. ارائه‌دهنده‌ای که فقط آدرس سایت می‌خواهد، فقط به آدرس سایت نیاز دارد؛ چون قرار است ابزار را روی آن اجرا کند.
پنج سؤال فنی که سطح تیم را نشان میدهد
لازم نیست خودتان متخصص امنیت باشید. این پنج سؤال پاسخ‌های درست شناخته‌شده‌ای دارند و جواب‌ها به شما می‌گویند با چه سطحی طرف هستید.
- «کنترل دسترسی را چطور آزمون میکنید؟» پاسخ درست شامل این‌هاست: گرفتن نشست از هر نقش، بازپخش مجموعه‌ی کامل درخواست‌ها با نشست نقش‌های دیگر، آزمون همه‌ی متدهای HTTP روی هر منبع، و بررسی اندپوینت دوقلوی API. اگر پاسخ به ابزار خلاصه شد، سطح کار مشخص است — مبانی در کنترل دسترسی شکسته.
- «برای منطق کسبوکار چه میکنید؟» پاسخ درست با «اول باید فرایند شما را بفهمیم» شروع میشود و به آزمون‌های مشخص می‌رسد: دور زدن مراحل، سقف‌های قابل تکرار، دستکاری مقادیر محاسبه‌شده. اگر جوابی وجود نداشت، این دسته آزموده نمیشود.
- «از UUID استفاده می‌کنیم، پس IDOR نداریم — درست است؟» پاسخ درست: نه. شناسه‌ی غیرقابل حدس هزینه‌ی کشف را بالا می‌برد اما هیچ بررسی مجوزی اضافه نمی‌کند، و UUID از پاسخ اندپوینت‌های دیگر، خروجی گزارش‌ها و هدر Referer نشت میکند.
- «WAF داریم؛ چقدر ریسک را کم میکند؟» پاسخ درست صریح است: WAF کنترل جبرانی و ابزار خریدن زمان است و نسبت به کنترل دسترسی، منطق کسبوکار، شرایط مسابقه و بخش عمده‌ی DOM XSS کور است، و قابل دور زدن است — معمولاً از راه یافتن IP اصلی سرور.
- «شدت را با چه نسخه‌ای امتیاز می‌دهید؟» پاسخ درست نسخه را نام می‌برد و توضیح میدهد که بردار کامل در گزارش می‌آید. پاسخ کامل‌تر این را هم اضافه میکند که CVSS v4.0 استاندارد جاری است اما v3.1 در داده‌ی واقعی همچنان غالب است، و هر دو قابل دفاع‌اند به‌شرط تصریح.
و یک سؤال ششم که پاسخش رفتاری است نه فنی: «اگر در جریان آزمون نشانه‌ی نفوذ واقعی و قبلی پیدا کنید، چه میکنید؟» پاسخ درست: توقف فوری فعالیت در آن مسیر، تماس با مخاطب تشدید، حفظ شواهد و عدم دستکاری. اگر ارائه‌دهنده برای این وضعیت رویه‌ای ندارد، برای وضعیت‌های بحرانی دیگر هم ندارد.
چارچوب حقوقی و مرزی که عبور از آن جرم است
سه سند، چارچوب قانونی کار را می‌سازند و هیچکدام اختیاری نیستند:
- مجوز کتبی آزمون. فهرست دقیق دارایی‌های مجاز، بازه‌ی زمانی، نام و امضای مالک سامانه یا مقام مجاز، و صراحت در مورد آنچه مجاز نیست. اگر دارایی روی زیرساخت ابری یا CDN ثالث است، ممکن است مجوز آن ارائه‌دهنده هم لازم باشد.
- قرارداد با دامنهی مکتوب. شامل تحویل‌دادنی‌ها، آزمون مجدد، مسئولیت‌ها و حد مسئولیت در صورت اختلال عملیاتی.
- NDA دوطرفه با تعیین تکلیف داده: مدت نگهداری، محل نگهداری، امحا.
هر ارائه‌دهنده‌ای که پیشنهاد کند سامانه‌ای را که مالکش نیستید آزمون کند، یا به حسابی که در اختیار شما نیست دسترسی بگیرد — حساب شخصی، حساب رقیب، سامانهی یک سازمان دیگر — در حال ارتکاب جرم است و شما را هم شریک میکند. این نه «تست نفوذ» است و نه خدمت امنیتی؛ دسترسی غیرمجاز است و قانون جرایم رایانه‌ای برای آن مجازات تعیین کرده. از چنین ارائه‌دهنده‌ای صرف‌نظر کنید و هیچ اطلاعاتی از سامانهی خودتان هم به او ندهید. اگر آسیبپذیریای در سامانهی دیگری یافتهاید، مسیر درست افشای مسئولانه یا یک برنامه‌ی باگ‌بانتی است — سازوکار آن را در ایران باگ‌بانتی توضیح داده‌ایم.
یک نکته‌ی عملی درباره‌ی محیط: آزمون روی محیط عملیاتی ریسک اختلال دارد و آزمون روی Staging ممکن است واقعیت را نشان ندهد (پیکربندی متفاوت، داده‌ی متفاوت، نسخه‌ی متفاوت). رویکرد متعارف، تفکیک است: آزمون‌های خواندنی و بی‌اثر روی محیط عملیاتی و آزمون‌های تغییردهنده روی Staging، با مکتوب کردن این تفکیک در قواعد درگیری. ارائه‌دهنده‌ای که این تفکیک را مطرح نمی‌کند، به ریسک عملیاتی شما فکر نکرده است.
تیم بیرونی، نیروی داخلی، یا فریلنسر؟
سه مسیر وجود دارد و انتخاب درست به اندازه و بلوغ سازمان بستگی دارد.
| مسیر | مناسب برای | ریسک اصلی |
|---|---|---|
| تیم بیرونی (شرکت) | اکثر سازمان‌ها؛ جایی که نیاز به استقلال ارزیابی، تنوع مهارت و مسئولیت قراردادی وجود دارد | هزینه‌ی بالاتر از فریلنسر؛ و اگر بدون بررسی انتخاب شود، همان ریسک اسکن بازاریابی‌شده |
| کارشناس مستقل (فریلنسر) | دامنهی کوچک و مشخص، یا آزمون تکمیلی روی یک قابلیت خاص | وابستگی به یک نفر، نبود بازبینی همتا، دشواری تعهد قراردادی و NDA، و نبود پوشش در بازه‌های شلوغ |
| نیروی داخلی | سازمان بزرگ با چند تیم توسعه و انتشار مکرر | هزینه‌ی ثابت بالا و سوگیری آشنایی: تیم داخلی برنامه را از دید طراح می‌بیند و همان فرض‌های نادرست را دارد |
نکته‌ای که در بندهای انطباق هم دیده میشود: PCI DSS در بندهای ۱۱٫۴٫۲ و ۱۱٫۴٫۳ میگوید آزمون میتواند توسط منبع داخلی واجد صلاحیت یا طرف سوم انجام شود، اما در هر حال استقلال سازمانی تستر الزامی است (و QSA/ASV بودن الزامی نیست). یعنی حتی در مدل داخلی، کسی که کد را نوشته نمی‌تواند ارزیاب مستقل آن باشد.
مدل ترکیبی معمولاً بهترین نسبت هزینه به اثر را دارد: یک «قهرمان امنیت» داخلی برای بازبینی روزمره، آزمون دوره‌ای بیرونی برای ارزیابی مستقل، و آموزش توسعه‌ی امن برای کاهش تولید یافته از ابتدا. مقایسهی کامل اقتصادی این سه مسیر در تیم تست نفوذ و برون‌سپاری امنیت و مسیر ساخت ظرفیت داخلی در دوره‌ی سازمانی توسعه‌ی امن.
فرایند انتخاب: هفت گام عملی
- دارایی‌های خود را فهرست کنید. پیش از تماس با هر ارائه‌دهنده‌ای بدانید چه چیزی دارید: دامنه‌ها، زیردامنه‌ها، APIها، پنل‌ها. چک‌لیست امنیتی نقطه‌ی شروع خوبی است.
- هدف را مشخص کنید. الزام انطباق؟ درخواست مشتری سازمانی؟ انتشار یک قابلیت حساس؟ آماده‌سازی برای سرمایه‌گذاری؟ هدف، دامنه و عمق را تعیین میکند.
- از دو تا سه ارائه‌دهنده پیشنهاد بگیرید و از همه‌شان همان اطلاعات را بخواهید تا مقایسه معنا داشته باشد.
- پرسش‌نامه‌های اسکوپینگ را با هم مقایسه کنید. این خودش یک آزمون است: کدام پرسشنامه سراغ نقشها، جریانهای کسبوکار و سطح API میرود؟
- نمونهی گزارش سانسورشده بگیرید و آن را با معیارهای گزارش تست نفوذ بسنجید.
- جلسه‌ی فنی با تستر بگذارید، نه فقط با فروش. پنج سؤال بخش قبل را بپرسید.
- در قرارداد این چهار عدد را بنویسید: تعداد نفر-روز آزمون دستی، تعداد نقش‌هایی که به‌صورت متقاطع آزموده میشوند، تعداد نوبت آزمون مجدد و بازه‌ی مجاز آن، و فهرست بسته‌ی دارایی‌های داخل دامنه. مبنای عددی هزینه در هزینه تست نفوذ توضیح داده شده.
برای دیدن اینکه محصول نهایی این فرایند چه شکلی دارد، نمونه تست نفوذ روایت یک پروژه را از اسکوپینگ تا آزمون مجدد نشان میدهد. سوابق و رویکرد ما در درباره‌ی پی‌هانتر و مشتریان آمده، شرح خدمات در تست نفوذ وب، و برای شروع گفت‌وگوی فنی می‌توانید از فرم مشاوره استفاده کنید.
پرسش‌های متداول
کارشناس تست نفوذ خوب را از کجا تشخیص دهیم؟
از سه چیز: نمونهی گزارش سانسورشده، پرسشنامهی اسکوپینگ، و جواب سؤال «کنترل دسترسی را چطور آزمون میکنید؟». اگر گزارش نمونه ساختار کامل و شواهد خام دارد، پرسشنامه سراغ نقشها و جریانهای کسبوکار میرود، و پاسخ سؤال سوم به روش دستی مقایسهی نشستها اشاره میکند، با یک تیم حرفهای طرف هستید.
آیا گواهی OSCP برای تست نفوذ وب کافی است؟
OSCP گواهی معتبر و عملی است اما تمرکزش بیشتر بر شبکه و میزبان است. برای کار تخصصی وب، OSWE و BSCP نزدیک‌ترند. مهم‌تر از هر گواهی، سابقه‌ی قابل راستی‌آزمایی روی برنامه‌های وب است: یافته‌های مستند در باگ‌بانتی، CVE منتشرشده، یا نمونهی گزارش با عمق واقعی.
آیا «گواهی OWASP» وجود دارد؟
نه. OWASP یک بنیاد غیرانتفاعی تولیدکنندهی استاندارد و راهنماست و نهاد صدور گواهی نیست. «OWASP Certified»، «PTES Certified» و «OSSTMM Compliant» هیچکدام وجود ندارند. عبارت درست و قابل دفاع این است: «پوشش آزمون بر پایهی OWASP WSTG v4.2 و ردهبندی ریسک بر پایهی OWASP Top 10:2025».
چرا نباید سراغ کسی رفت که میگوید «هک میکنم و نشان میدهم»؟
چون کار حرفهای با مجوز کتبی و دامنهی مشخص شروع میشود، نه با نمایش. این عبارت نشان میدهد چارچوب حقوقی جدی گرفته نمیشود، و همان کسی که برای شما مرز را رد میکند، ممکن است در جای دیگری علیه شما هم رد کند. علاوه بر آن، «یک نفوذ نمایشی» هیچ اطلاعاتی از پوشش و وضعیت کلی سامانهی شما نمیدهد.
اگر کسی پیشنهاد دسترسی به یک حساب یا سامانهی دیگر بدهد چه کنیم؟
مکالمه را تمام کنید. این خدمت امنیتی نیست؛ دسترسی غیرمجاز است و جرم، و پذیرش آن شما را هم درگیر میکند. هیچ اطلاعاتی از سامانهی خودتان هم به چنین شخصی ندهید. اگر آسیبپذیریای در سامانهی دیگری یافتهاید، مسیر قانونی افشای مسئولانه است.
فریلنسر بگیریم یا شرکت؟
برای دامنهی کوچک و مشخص، کارشناس مستقل خوب میتواند کافی و مقرونبهصرفه باشد. برای سامانههای مالی، چندنقشی یا مشمول انطباق، تیم شرکتی مزیتهای ملموسی دارد: بازبینی همتا، تنوع مهارت، تعهد قراردادی و NDA سازمانی، و تداوم در آزمون مجدد. در هر دو حالت، معیارهای این مقاله یکسان اعمال میشوند.
منابع
مهدی مرادلو
محقق امنیتی با تمرکز روی منطق کسبوکار و زنجیره‌های حمله‌ی پیچیده. اسکوپ‌بندی پروژه‌ها و تضمین کیفیت گزارش‌ها با اوست.