یک پاسخ 200 OK فقط میگوید درخواست پردازش شده است؛ نمیگوید کاربر مجاز بوده سفارش شخص دیگری را ببیند، Token درست منقضی میشود یا اطلاعات حساس در Log نرفته است. تست امنیت نرمافزار کنترل میکند که کنترلهای امنیتی در برابر سناریوهای واقعی و خطاهای طراحی واقعاً کار میکنند.
در این راهنما از فهرست ابزارها عبور میکنیم و یک روش اجرایی میسازیم: دارایی و تهدید را میشناسیم، الزام امنیتی قابل آزمون مینویسیم، SAST و DAST و تست دستی را در جای درست قرار میدهیم، یافته را بر اساس ریسک اولویتبندی میکنیم و پس از اصلاح Retest انجام میدهیم. همه آزمونهای فعال باید فقط با مجوز کتبی، Scope روشن و روی محیط کنترلشده انجام شوند.
خروجی این مقاله:
- تعریف دقیق Security Testing و مرز آن با اسکن و تست نفوذ؛
- مدل پوشش از طراحی تا Production؛
- نمونه ماتریس دسترسی فروشگاه اینترنتی؛
- قالب Rules of Engagement و گزارش یافته؛
- چکلیست قابل استفاده برای تیم QA، توسعه و امنیت.
تست امنیت نرمافزار چیست؟
تست امنیت فرایند ارزیابی و راستیآزمایی کنترلهایی است که از داراییهای سیستم در برابر تهدید محافظت میکنند. دارایی میتواند داده مشتری، موجودی کیف پول، Token، سورسکد، کلید امضا، سرویس سفارش یا حتی قابلیت بازیابی سامانه باشد. طبق OWASP WSTG، یک تست امنیت باید نشان دهد برنامه الزامهای امنیتی ذینفعان را برآورده میکند؛ صرف اجرای Scanner این اطمینان را ایجاد نمیکند.
امنیت معمولاً در خانواده ویژگیهای کیفی مطرح میشود و در راهنمای تست غیرکارکردی جای دارد، اما همه تستهای امنیت «غیرکارکردی محض» نیستند. بررسی اینکه مشتری نتواند سفارش مشتری دیگر را ببیند، آزمون یک کنترل دسترسی و رفتار قابل مشاهده سیستم است. دستهبندی مهمتر از پوشش نیست: هم ویژگی امنیتی را آزمون کنید، هم مقاومت سیستم در برابر سوءاستفاده را.
هدف امنیت «نبود باگ» نیست
هیچ تیمی نمیتواند با یک Run ثابت کند سیستم برای همیشه امن است. کد، Dependency، تنظیمات، تهدیدها و مسیرهای حمله تغییر میکنند. خروجی حرفهای تست امنیت، سطح اطمینان مستند برای Scope، نسخه و زمان مشخص است؛ همراه با محدودیتها و ریسک باقیمانده.
اصول امنیت را به تست قابل اجرا تبدیل کنید
سهگانه CIA نقطه شروع خوبی است، اما باید به رفتار قابل مشاهده تبدیل شود:
| هدف | سؤال تست | شاهد مورد انتظار |
|---|---|---|
| محرمانگی | آیا مشتری A میتواند داده مشتری B را بخواند؟ | رد دسترسی، بدون افشای جزئیات حساس |
| یکپارچگی | آیا مبلغ یا وضعیت سفارش خارج از قواعد تغییر میکند؟ | اعتبارسنجی سمت سرور و Audit Trail |
| دسترسپذیری | آیا ورودی یا وابستگی نامعمول سرویس را ناپایدار میکند؟ | Timeout، محدودسازی، بازیابی و Alert کنترلشده |
| احراز هویت | Session و Token چگونه صادر، باطل و منقضی میشوند؟ | چرخه عمر قابل پیشبینی و امن |
| مجوزدهی | هر نقش روی هر Object چه عملی میتواند انجام دهد؟ | کنترل سمت سرور برای هر درخواست |
| ثبت و هشدار | آیا رویداد حساس قابل پیگیری است بدون ثبت Secret؟ | Log کمینه، شناسه همبستگی و Alert عملیاتی |
این سؤالها را از مرحله تحلیل نیازمندی ثبت کنید. جمله «سیستم امن باشد» قابل تست نیست؛ جمله «کاربر نقش پشتیبان فقط چهار رقم آخر شماره تماس سفارش را میبیند و مشاهده در Audit Log ثبت میشود» قابل آزمون است.
Threat، Vulnerability و Risk چه تفاوتی دارند؟
- دارایی (Asset): چیزی که برای کسبوکار ارزش دارد.
- تهدید (Threat): عامل یا رویدادی که میتواند به دارایی آسیب بزند.
- آسیبپذیری (Vulnerability): ضعف طراحی، پیادهسازی، پیکربندی یا عملیات که قابل سوءاستفاده است.
- ریسک (Risk): ترکیب احتمال/شرایط سوءاستفاده و پیامد آن در محیط واقعی سازمان.
- کنترل (Control): اقدامی برای پیشگیری، کشف، محدودسازی یا بازیابی.
مثلاً Endpoint سفارش یک دارایی دادهای را در معرض کاربر قرار میدهد؛ Broken Access Control آسیبپذیری است؛ مشاهده آدرس مشتری دیگر پیامد است؛ بررسی مالکیت سفارش در سمت سرور یک کنترل پیشگیرانه و ثبت تلاش نامجاز یک کنترل کشفی است.
OWASP Top ۱۰، ASVS و WSTG را کجا استفاده کنیم؟
OWASP Top ۱۰:۲۰۲۵ برای آگاهی و اولویت اولیه
نسخه فعلی OWASP Top ۱۰:۲۰۲۵ ریسکهایی مانند Broken Access Control، Security Misconfiguration، Software Supply Chain Failures، Cryptographic Failures، Injection، Insecure Design و Mishandling of Exceptional Conditions را برجسته میکند. این فهرست «ده تست کامل» یا گواهی امنیت نیست؛ برای گفتوگو درباره ریسکهای رایج و یافتن شکافهای آشکار مفید است.
OWASP ASVS ۵.۰.۰ برای الزام و پوشش
ASVS مبنایی برای راستیآزمایی کنترلهای فنی برنامه وب و نوشتن الزامهای توسعه امن ارائه میدهد. Requirementهای مرتبط را با نسخه استاندارد در Traceability Matrix ثبت کنید؛ برای مثال هر Requirement محصول به Test Case، نتیجه و Finding مرتبط شود. انتخاب سطح و Requirement باید با ریسک برنامه انجام شود، نه با کپیکردن کل استاندارد.
OWASP WSTG برای روش اجرای تست وب
WSTG حوزههایی مانند مدیریت هویت، Authentication، Authorization، Session، ورودی، منطق کسبوکار، Client-side و API را به سناریوهای تست تبدیل میکند. نسخه Stable را برای Baseline رسمی و شناسه نسخهدار را برای گزارش استفاده کنید؛ بخش Latest ممکن است تغییر کند.
انواع تست امنیت و مرز هرکدام
| روش | چه چیزی میبیند؟ | محدودیت مهم |
|---|---|---|
| Threat Modeling | دارایی، Trust Boundary، مسیر سوءاستفاده و کنترل طراحی | خودش اجرای تست نیست؛ پوشش را هدایت میکند |
| Secure Code Review | منطق، جریان داده، کنترل دسترسی و خطای طراحی در کد | به Context و مهارت انسانی نیاز دارد |
| SAST | سورس/Bytecode بدون اجرای برنامه | Context زمان اجرا محدود و False Positive محتمل |
| SCA | Dependency، نسخه و ریسک زنجیره تأمین | وجود CVE بهتنهایی Reachability و ریسک محلی را ثابت نمیکند |
| Secrets Scanning | کلید و Credential افشاشده در کد یا History | Rotation و پاکسازی History همچنان فرایند انسانی میخواهد |
| DAST | رفتار برنامه در حال اجرا از بیرون | دید محدود به مسیرهای قابل دسترس و داده Crawlشده |
| Security API Testing | Object/Function Authorization، Schema، Flow و Abuse Case | فقط Status Code کافی نیست |
| Penetration Testing | ترکیب ضعفها و اثر قابل بهرهبرداری در Scope مجاز | نمونهبرداری زماندار است و پوشش کامل نمیدهد |
بازبینی دستی و ابزار مکملاند. SAST با DAST یکی نیست و DAST هم «بازبینی کد در حال اجرا» نیست. برای مبانی تحلیل بدون اجرا، تست استاتیک و برای دید کدمحور تست جعبه سفید را بخوانید.
اسکن آسیبپذیری با تست نفوذ فرق دارد
Vulnerability Assessment
هدف، کشف و دستهبندی ضعفها در سطح تعریفشده است. Scanner میتواند Signature یا Misconfiguration شناختهشده را سریع پیدا کند، اما خروجی آن باید Validate و با Context محصول غنی شود. هشدار ابزار مساوی آسیبپذیری تأییدشده نیست.
Penetration Test
هدف، آزمودن امکان و اثر سوءاستفاده از مسیرهای منتخب در چارچوب مجاز است. متخصص ممکن است چند ضعف را زنجیره کند یا منطق کسبوکار را بررسی کند. Pentest معمولاً زمان و Scope محدود دارد؛ پس عبارت «هیچ موردی پیدا نشد» به معنای «هیچ ضعفی وجود ندارد» نیست.
Security Audit
Audit بررسی میکند کنترل، فرایند یا پیکربندی با معیار مشخص منطبق است یا نه. انطباق میتواند شاهد مفیدی باشد، اما Compliance و Security مترادف نیستند. استاندارد حداقل را تعریف میکند؛ Threat Model محصول ممکن است کنترل بیشتری بخواهد.
پیش از تست فعال، Rules of Engagement بنویسید
تست امنیت بدون مجوز میتواند غیرقانونی، مخرب یا سبب Incident واقعی شود. حتی در سازمان خودتان، توافق کتبی از Owner سامانه لازم است.
حداقل محتوای RoE
- مالک کسبوکار، مالک فنی و فرد مجازکننده؛
- Hostname، API، IP، Tenant، نسخه و محیط دقیقِ داخل Scope؛
- موارد خارج Scope مانند سامانه پرداخت، پیامک و زیرساخت شخص ثالث؛
- بازه زمانی، نرخ درخواست، Source IP و حسابهای تست؛
- روشهای مجاز و ممنوع؛ بهویژه DoS، Social Engineering و دسترسی به داده واقعی؛
- Stop Condition مانند افزایش Error Rate یا دریافت داده غیرمنتظره؛
- کانال تماس فوری، Escalation و روش متوقفکردن تست؛
- نحوه رمزنگاری، نگهداری، اشتراک و حذف Evidence؛
- برنامه Cleanup برای حساب، فایل، Token و داده ساختهشده.
تست Availability مخرب یا شبیهسازی DDoS را با یک دستور عمومی شروع نکنید. چنین آزمایشی به محیط، ظرفیت، هماهنگی عملیات و طرح بازیابی اختصاصی نیاز دارد.
فرایند تست امنیت از Scope تا Retest
۱. Context و داراییها را بشناسید
معماری، Data Flow، نقشها، APIها، Dependencyها، Trust Boundaryها و دادههای حساس را فهرست کنید. فقط URL عمومی سطح حمله نیست؛ Admin Panel، Queue، Storage، Webhook، Job زمانبندیشده و Pipeline نیز مهماند.
۲. Threat Model و الزام امنیتی بسازید
برای هر دارایی بپرسید چه کسی، از کدام مرز و با چه هدفی میتواند به آن آسیب بزند. سپس کنترل و انتظار آزمونپذیر بنویسید. Threat Model باید پس از تغییر معماری، نقش یا جریان مالی بهروزرسانی شود.
۳. پوشش مبتنی بر ریسک طراحی کنید
Requirementهای محصول، ASVS، WSTG، OWASP Top ۱۰ و ریسک خاص صنعت را به Test Case متصل کنید. یک فروشگاه ایرانی علاوه بر ریسکهای عمومی، باید مالکیت سفارش، بازپرداخت، کیف پول، کد تخفیف، درگاه پرداخت و دسترسی اپراتور پشتیبانی را بسنجد.
۴. تستها را در لایه مناسب اجرا کنید
- هنگام طراحی: Threat Modeling و Abuse Case؛
- هنگام کدنویسی: Review، SAST، SCA و Secrets Scan؛
- روی Build: پیکربندی، Container/IaC و Artifact Integrity؛
- در محیط اجرا: DAST، تست API و تست دستی نقش/منطق؛
- دورهای: Pentest مستقل و بازبینی سطح حمله؛
- پس از انتشار: Logging، Alerting، مدیریت آسیبپذیری و Incident Readiness.
۵. Finding را تأیید و ایمن ثبت کنید
Reproduce کنید، Scope اثر را به کمترین نمونه لازم محدود کنید و Evidence حساس را Redact کنید. اطلاعات مشتری، Token فعال یا Payload قابل سوءاستفاده را در Ticket عمومی نگذارید. اصول نوشتن مراحل تکرارپذیر را از راهنمای گزارش باگ بگیرید، اما کانال و سطح دسترسی گزارش امنیتی باید محدودتر باشد.
۶. اصلاح، Retest و Regression
پس از Fix فقط همان درخواست را تکرار نکنید؛ کنترل ریشهای، نقشهای مجاور، مسیرهای جایگزین و Regression را هم بررسی کنید. اگر Fix فقط در UI دکمه را پنهان کرده ولی API مجوزدهی ندارد، Finding بسته نشده است. نتیجه Retest را در چرخه اجرای تست با نسخه Build و Evidence ثبت کنید.
مثال عملی: ماتریس دسترسی سفارش
فرض کنید نقشهای Guest، Customer، Support و Admin داریم. بهجای شروع با Payload، ابتدا انتظار مجوزدهی را روشن کنید:
| عملیات | Guest | Customer | Support | Admin |
|---|---|---|---|---|
| مشاهده سفارش | ممنوع | فقط سفارش خود | طبق وظیفه، داده Maskشده | طبق نقش و با Audit |
| تغییر آدرس | ممنوع | فقط سفارش خود و پیش از ارسال | محدود و ثبتشده | طبق سیاست |
| بازپرداخت | ممنوع | درخواست طبق Flow | بدون اختیار نهایی یا با سقف | اختیار تعریفشده و ثبتشده |
| خروجی گرفتن | ممنوع | فقط داده خود | حداقل داده لازم | محدود، Alert و Audit |
Test Caseهای کلیدی
- Customer A با شناسه سفارش Customer B نباید داده یا وجود/عدم وجود آن را افشا کند؛
- تغییر شناسه در Path، Query، Body و GraphQL Variable باید همان کنترل سمت سرور را طی کند؛
- Support فقط فیلدهای لازم را ببیند و دسترسی حساس ثبت شود؛
- تغییر نقش یا Logout باید Session/Token قبلی را طبق سیاست بیاعتبار کند؛
- بازپرداخت تکراری نباید دو اثر مالی بسازد؛
- خطای غیرمنتظره نباید Stack Trace، Secret یا جزئیات داخلی را برگرداند؛
- تلاشهای غیرمجاز باید با شناسه همبستگی ثبت و در آستانه تعریفشده Alert شوند.
برای طراحی عمیقتر Authorization در Endpointها، راهنمای تست API را به این ماتریس متصل کنید. OWASP API Security Top ۱۰:۲۰۲۳ نیز نشان میدهد Authorization همچنان محور اصلی ریسک API است.
تست ورودی فقط Injection نیست
ورودی امن باید در Context درست اعتبارسنجی و خروجی در Context مصرف Encode شود، اما پوشش امنیت فراتر از Payloadهای Injection است:
- نوع، طول، Range و ترکیب Unicode ورودی؛
- فایل، نام فایل، MIME، اندازه و محل ذخیره؛
- Mass Assignment و فیلدهایی که Client نباید کنترل کند؛
- Redirect، Callback، Webhook و URLهای ورودی؛
- حالتهای Null، Timeout، Retry و پاسخ ناقص Dependency؛
- Race Condition، درخواست تکراری و Idempotency عملیات مالی؛
- Rate Limit و Abuse Flow مانند ساخت انبوه حساب یا مصرف کد تخفیف.
در OWASP Top ۱۰:۲۰۲۵، Mishandling of Exceptional Conditions یادآوری میکند که Fail-open، خطای منطقی و مدیریت نادرست شرایط استثنایی نیز ریسک امنیتیاند. برای همین Test Caseهای منفی و State Transition بهاندازه اسکن Signature اهمیت دارند.
پوشش امنیت در CI/CD
هدف Shift Left این نیست که یک Scanner همه PRها را قرمز کند؛ هدف بازخورد زودهنگام، مالکیت روشن و کنترل متناسب با مرحله است.
| مرحله | کنترل پیشنهادی | سیاست شکست |
|---|---|---|
| Commit/PR | Secrets Scan، SAST هدفمند، Review تغییر حساس | Secret معتبر یا Finding جدید با معیار روشن Block شود |
| Build | SCA، SBOM، امضای Artifact، Container/IaC Scan | بر اساس Reachability، Exposure و Policy |
| Staging | DAST محدود، API Authorization، Config و Error Handling | Finding تأییدشده پرریسک Release را متوقف کند |
| Scheduled | اسکن کاملتر، Pentest، Surface Review | SLA اصلاح و Exception زماندار |
| Production | Monitoring، Alerting، Dependency/Vulnerability Intake | Playbook رخداد و Rollback/Containment |
Threshold ابزار را بدون Baseline فعال نکنید. Finding جدید را از بدهی موجود جدا کنید، Owner و SLA داشته باشید و Exception را با تاریخ انقضا ثبت کنید. معماری Lane و Gate را در تست مداوم در CI/CD ببینید.
یافته امنیتی را چگونه اولویتبندی کنیم؟
CVSS ۴.۰ چارچوبی برای بیان ویژگی و شدت آسیبپذیری است، اما Base Score بهتنهایی اولویت کسبوکار نیست. برای Triage این Contextها را کنار Severity بگذارید:
- اهمیت دارایی و نوع داده در معرض خطر؛
- اینترنتی یا داخلی بودن سطح حمله؛
- سطح دسترسی و تعامل لازم؛
- شواهد بهرهبرداری یا قابلیت ترکیب با ضعف دیگر؛
- اثر مالی، عملیاتی و اعتماد کاربر؛
- کنترل جبرانی، قابلیت کشف و زمان بازیابی؛
- تعداد Tenant، کاربر یا رکورد متاثر؛
- الزام قراردادی و سیاست داخلی مرتبط.
قالب کوتاه Finding
- عنوان: رفتار آسیبپذیر + دارایی متاثر؛
- Scope/Build: محیط، Endpoint و نسخه؛
- پیششرط: نقش و داده آزمایشی؛
- Steps: حداقل مراحل تکرار، بدون داده اضافی؛
- Actual/Expected: کنترل فعلی و انتظار امنیتی؛
- Impact: سناریوی اثر در Context کسبوکار؛
- Evidence: Redactشده و با دسترسی محدود؛
- Severity/Risk: روش امتیازدهی و فرضها؛
- Recommendation: رفع ریشهای، نه فقط فیلتر UI؛
- Retest: نتیجه، Build و Regression مرتبط.
معیارهای مفید برنامه تست امنیت
تعداد Finding خام معیار کیفیت نیست؛ Scanner پرسروصدا میتواند عدد را بالا ببرد بدون کاهش ریسک. این شاخصها عملیترند:
- درصد الزامهای پرریسک با Test و Evidence معتبر؛
- زمان تا Triage، زمان تا Fix و زمان تا Retest بر اساس Severity/Risk؛
- درصد Findingهای بازشده مجدد یا Fix ناقص؛
- Findingهای Escapeشده به Production و علت ریشهای؛
- سن Dependency یا Secret تاییدشده؛
- False Positive و زمان تحلیل ابزار؛
- درصد تغییرهای حساس که Threat Model/Review دریافت کردهاند؛
- پوشش Alert و تمرین پاسخ برای سناریوهای حیاتی.
نمودار باید روند و اقدام بعدی را نشان دهد. «صفر Finding» ممکن است نتیجه Scope کم، تست ضعیف یا نبود مشاهدهپذیری باشد.
ملاحظات امنیتی محصولات ایرانی
- درگاه پرداخت، سرویس پیامک، احراز هویت و CDN را Dependency مستقل با Trust Boundary مشخص ببینید؛
- Sandbox یا Mock رسمی به کار ببرید و سرویس ثالث را بدون مجوز تست نکنید؛
- شماره موبایل، کد ملی، آدرس فارسی، Unicode و اعداد فارسی/لاتین را در Validation و Masking پوشش دهید؛
- دسترسی ابزار تجاری، Feed آسیبپذیری و Update Scanner را پیش از اتکا در Pipeline بررسی کنید؛
- محدودیت شبکه نباید باعث Pin کردن Dependency قدیمی یا خاموش کردن Verification شود؛ Mirror و فرایند بهروزرسانی کنترلشده بسازید؛
- Evidence حاوی داده مشتری را روی پیامرسان یا Ticket عمومی جابهجا نکنید؛ کانال امن و Retention محدود تعریف کنید.
الزام حقوقی به صنعت، قرارداد و حوزه فعالیت بستگی دارد. این مقاله جایگزین مشاوره حقوقی یا ارزیابی رسمی انطباق نیست.
اشتباهات رایج در تست امنیت
OWASP Top ۱۰ را چکلیست کامل میدانیم
Top ۱۰ سند آگاهی است. ریسک منطق کسبوکار، معماری و دارایی خاص شما ممکن است در آن بهصورت مستقیم دیده نشود. ASVS، WSTG و Threat Model را برای پوشش قابل ردیابی ترکیب کنید.
فقط Scanner میخریم
ابزار بدون Scope، Tuning، Validation، Owner و SLA یک صف هشدار میسازد. ابتدا تصمیم بگیرید چه Findingی چه زمانی و توسط چه کسی بررسی و اصلاح میشود.
فقط آخر انتشار Pentest میکنیم
Pentest ارزشمند است، اما جای Secure Design، Review، SCA، تست نقشها و Monitoring را نمیگیرد. امنیت باید در کل SDLC حضور داشته باشد؛ چارچوب NIST SSDF نیز شیوههای توسعه امن را برای ادغام در SDLC پیشنهاد میکند.
پس از Fix فقط Ticket را میبندیم
Retest باید رفع ریشهای را روی همان Build تایید کند و مسیرهای مشابه را Regression بگیرد. تغییر کنترل امنیتی بدون Test Case ماندگار، دوباره آسیبپذیر میشود.
چکلیست تست امنیت نرمافزار
- مجوز کتبی، Scope، RoE، Stop Condition و تماس اضطراری داریم.
- دارایی، نقش، Data Flow، Trust Boundary و Dependencyها مشخصاند.
- الزامهای امنیتی قابل آزمون و Traceable هستند.
- OWASP Top ۱۰ فقط برای آگاهی و ASVS/WSTG برای پوشش استفاده شدهاند.
- Threat Model تغییرهای حساس را پوشش میدهد.
- SAST، SCA، Secrets، DAST و تست دستی در لایه مناسباند.
- Authorization در سطح Object، Function و Field آزموده میشود.
- Session، Token، Logout، Expiry و Revocation پوشش دارند.
- ورودی، Upload، Error، Retry، Race و Abuse Flow تست شدهاند.
- Log داده حساس ندارد و Alert قابل اقدام است.
- Findingها Validate، Redact و در کانال محدود ثبت میشوند.
- Severity با Context کسبوکار به Risk Priority تبدیل میشود.
- Fix با Retest و Regression بسته میشود.
- Exception امنیتی Owner و تاریخ انقضا دارد.
- محدودیتها و ریسک باقیمانده در گزارش نهایی صریحاند.
سوالات متداول تست امنیت
تست امنیت نرمافزار فقط تست غیرکارکردی است؟
امنیت یک ویژگی کیفی مهم است، اما تست کنترلهایی مانند مجوز مشاهده سفارش یا Logout رفتار کارکردی قابل مشاهده را هم میسنجد. برای پوشش درست، بر ریسک و الزام تمرکز کنید، نه بر برچسب دستهبندی.
تفاوت SAST و DAST چیست؟
SAST کد یا Bytecode را بدون اجرای برنامه تحلیل میکند؛ DAST رفتار برنامه در حال اجرا را از بیرون میآزماید. هرکدام دید و محدودیت متفاوت دارد و جای دیگری را کامل نمیگیرد.
آیا OWASP Top ۱۰ برای تست کامل کافی است؟
خیر. Top ۱۰ سند آگاهی درباره ریسکهای مهم وب است. برای Requirement و Coverage از ASVS، برای روشهای تست وب از WSTG و برای ریسکهای خاص محصول از Threat Model استفاده کنید.
هر چند وقت یکبار تست امنیت انجام دهیم؟
بازخورد خودکار و Review باید متناسب با تغییرها پیوسته باشد؛ تست دستی و Pentest بر اساس ریسک، تغییر معماری، انتشار مهم و برنامه دورهای انجام شود. یک بازه واحد برای همه محصولات وجود ندارد.
آیا CVSS بالاتر همیشه باید زودتر رفع شود؟
CVSS شدت فنی را استاندارد میکند، اما اولویت اصلاح به Exposure، اهمیت دارایی، Threat فعال، کنترل جبرانی و اثر کسبوکار نیز وابسته است. امتیاز و Context را با هم ثبت کنید.
جمعبندی
تست امنیت موثر از ابزار شروع نمیشود؛ از دارایی، تهدید و انتظار قابل آزمون شروع میشود. Scope و مجوز را روشن کنید، استاندارد را متناسب با ریسک انتخاب کنید، روشهای طراحی، کد، Dependency، محیط اجرا و تست دستی را ترکیب کنید و هر Finding را تا Retest ریشهای دنبال کنید. نتیجه مطلوب «گزارش ضخیم» نیست؛ کاهش ریسک قابل توضیح و قابل سنجش است.
