SAST و DAST چیست؟ تفاوت تست امنیت استاتیک و داینامیک وب‌سایت

پاسخ کوتاه: SAST و DAST دو روش مکمل برای تست امنیت نرم‌افزار و وب‌سایت هستند. SAST یا Static Application Security Testing کد برنامه را بدون اجرای آن بررسی می‌کند و به‌دنبال الگوهای ناامن، جریان‌های داده مشکوک و خطاهای برنامه‌نویسی می‌گردد؛ در مقابل، DAST یا Dynamic Application Security Testing برنامه در حال اجرا را از بیرون آزمایش می‌کند تا ضعف‌هایی را شناسایی کند که در رفتار واقعی وب‌سایت، API، احراز هویت، پیکربندی و تعاملات Runtime ظاهر می‌شوند. تفاوت SAST و DAST به معنی برتری مطلق یکی بر دیگری نیست؛ یک برنامه امنیتی حرفه‌ای معمولاً از هر دو استفاده می‌کند.

امنیت یک وب‌سایت فقط با اسکن سرور یا نصب WAF تأمین نمی‌شود. بسیاری از آسیب‌پذیری‌های مهم از داخل کد برنامه ایجاد می‌شوند، در حالی که گروه دیگری از مشکلات فقط زمانی آشکار می‌شوند که اپلیکیشن واقعاً اجرا شده و با مرورگر، API، پایگاه داده، Reverse Proxy، Session، Cookie و سایر اجزای زیرساخت تعامل داشته باشد.

به همین دلیل یکی از سؤالات مهم در Application Security این است که کد را باید بررسی کنیم یا برنامه در حال اجرا را؟

پاسخ درست معمولاً «هر دو» است.

SAST تلاش می‌کند مشکلات را از داخل کد و در مراحل اولیه توسعه پیدا کند. DAST همان برنامه را از دید یک کاربر یا سیستم خارجی بررسی می‌کند. یکی بیشتر به سؤال «در کد چه چیزی ممکن است ناامن باشد؟» پاسخ می‌دهد و دیگری بررسی می‌کند «برنامه‌ای که اکنون اجرا شده در عمل چه رفتار امنیتی دارد؟».

در این مقاله به‌صورت دقیق بررسی می‌کنیم SAST و DAST چیست، تفاوت تست امنیت استاتیک و داینامیک وب‌سایت در کجاست، هر روش چه نوع آسیب‌پذیری‌هایی را بهتر پیدا می‌کند، چرا نتایج ابزارها همیشه قطعی نیستند، False Positive و False Negative چه معنایی دارند، این دو روش چگونه وارد CI/CD و DevSecOps می‌شوند و برای یک وب‌سایت یا نرم‌افزار واقعی چگونه باید از آن‌ها استفاده کرد.

SAST چیست؟

SAST مخفف عبارت Static Application Security Testing است و در فارسی می‌توان آن را «تست امنیت ایستای برنامه» یا «تحلیل امنیتی استاتیک» نامید.

در این روش، برنامه لازم نیست در حال اجرا باشد.

ابزار SAST می‌تواند بسته به فناوری مورد استفاده، یکی یا چند مورد از این موارد را بررسی کند:

• Source Code
• Bytecode
• Intermediate Code
• Compiled Binary
• ساختار کنترل برنامه
• جریان داده یا Data Flow
• مسیر ورود و خروج داده
• فراخوانی Functionها
• APIهای حساس
• الگوهای برنامه‌نویسی ناامن

OWASP ابزارهای SAST را ابزارهایی معرفی می‌کند که Source Code یا نسخه کامپایل‌شده کد را برای پیدا کردن ضعف‌های امنیتی تحلیل می‌کنند و می‌توانند در جریان توسعه و حتی IDE استفاده شوند.

هدف اصلی SAST این است که قبل از آنکه آسیب‌پذیری به محیط Production برسد، نشانه‌های آن در کد شناسایی شوند.

یک مثال ساده از منطق SAST

فرض کنید برنامه ورودی کاربر را دریافت می‌کند.

سپس این ورودی بدون Validation یا کنترل مناسب به یک عملیات حساس می‌رسد.

ابزار SAST می‌تواند مسیر داده را بررسی کند:

User Input ↓ Application Variable ↓ Processing ↓ Sensitive Function

اگر ابزار تشخیص دهد داده کنترل‌نشده از یک Source ناامن به یک Sink حساس می‌رسد، ممکن است آن را به‌عنوان یک Finding امنیتی گزارش کند.

این نوع بررسی را معمولاً با مفاهیمی مانند موارد زیر می‌بینیم:

Source

Sink

Data Flow

Control Flow

Taint Analysis

Sanitization

یکی از قدرت‌های مهم SAST همین امکان دنبال‌کردن مسیر داده در کد است.

SAST چگونه کار می‌کند؟

روش دقیق تحلیل به ابزار بستگی دارد و همه SASTها از یک موتور یکسان استفاده نمی‌کنند.

بعضی ابزارها نسبتاً ساده‌اند و الگوهای شناخته‌شده را جست‌وجو می‌کنند.

برخی دیگر تحلیل پیچیده‌تری انجام می‌دهند و ارتباط میان Functionها، Variableها و مسیرهای مختلف اجرای برنامه را مدل‌سازی می‌کنند.

Pattern Matching

در ساده‌ترین حالت، ابزار به‌دنبال Patternهای مشخص می‌گردد.

برای مثال:

• استفاده از Functionهای ناامن
• Hardcoded Secret
• الگوریتم‌های رمزنگاری ضعیف
• تنظیمات امنیتی نامناسب در کد
• ورودی کنترل‌نشده

این روش سریع است، اما Context برنامه را همیشه به‌خوبی درک نمی‌کند.

Abstract Syntax Tree

ابزارهای پیشرفته‌تر می‌توانند کد را به ساختاری مانند AST یا Abstract Syntax Tree تبدیل کنند.

این کار به ابزار اجازه می‌دهد به‌جای نگاه کردن صرف به متن فایل، ساختار منطقی برنامه را درک کند.

برای مثال:

کدام Function فراخوانی شده است؟

چه Variableهایی به آن داده شده‌اند؟

نتیجه به کجا منتقل می‌شود؟

Data Flow Analysis

در Data Flow Analysis ابزار دنبال می‌کند داده چگونه در برنامه حرکت می‌کند.

این روش برای شناسایی ضعف‌هایی که ورودی غیرقابل اعتماد در آن‌ها نقش دارد بسیار مهم است.

Control Flow Analysis

Control Flow مسیرهای احتمالی اجرای برنامه را بررسی می‌کند.

برای مثال:

اگر شرط A برقرار شد چه اتفاقی می‌افتد؟

اگر کاربر دارای Role خاص بود چه مسیری اجرا می‌شود؟

اگر Exception رخ داد چه اتفاقی می‌افتد؟

ترکیب این تکنیک‌ها باعث می‌شود SAST بتواند بسیار بیشتر از یک جست‌وجوی متنی ساده باشد.

مزایای SAST چیست؟

یکی از مهم‌ترین مزیت‌های SAST این است که می‌تواند خیلی زود وارد Software Development Life Cycle شود.

لازم نیست منتظر Deploy شدن برنامه باشیم.

شناسایی مشکل قبل از انتشار

فرض کنید توسعه‌دهنده هنوز روی یک Feature کار می‌کند.

کد Commit می‌شود.

Pipeline به‌صورت خودکار SAST را اجرا می‌کند.

اگر یک مشکل جدی شناسایی شود، تیم می‌تواند قبل از Merge یا Release آن را بررسی کند.

این مدل با مفهوم Shift Left Security ارتباط دارد؛ یعنی کنترل امنیت تا حد ممکن به مراحل ابتدایی توسعه منتقل شود.

نمایش محل احتمالی مشکل

SAST معمولاً می‌تواند Finding را به بخشی از کد مرتبط کند.

برای نمونه:

File

Function

Line Number

Data Flow

Code Location

این ویژگی برای توسعه‌دهنده بسیار ارزشمند است، زیرا به‌جای دریافت پیامی کلی مانند «احتمال SQL Injection وجود دارد»، می‌تواند متوجه شود مسئله احتمالاً در کدام قسمت برنامه ایجاد شده است.

OWASP نیز اشاره می‌کند که یکی از مزایای SAST این است که می‌تواند کد مشکل‌دار و حتی محل آن را به توسعه‌دهنده نشان دهد.

امکان اجرای مداوم

SAST معمولاً قابلیت خوبی برای Automation دارد.

می‌توان آن را در موارد زیر اجرا کرد:

IDE

Pre-Commit

Pull Request

Merge Request

Build Pipeline

Nightly Scan

Release Pipeline

به همین دلیل SAST یکی از ابزارهای رایج DevSecOps است.

محدودیت‌های SAST چیست؟

SAST بسیار مفید است، اما نباید نتیجه آن را معادل «اثبات آسیب‌پذیری واقعی» در نظر گرفت.

برنامه را در Runtime نمی‌بیند

بزرگ‌ترین محدودیت SAST در نام آن مشخص است: Static.

ابزار برنامه را در وضعیت واقعی اجراشده نمی‌بیند.

بنابراین ممکن است نداند:

Reverse Proxy چگونه تنظیم شده است.

Headerها در Production چگونه تغییر می‌کنند.

WAF چه چیزی را مسدود می‌کند.

Cookie واقعاً با چه Attributeهایی ارسال می‌شود.

Web Server چه Configuration دارد.

کدام Feature Flag فعال است.

Infrastructure چه محدودیت‌هایی اعمال می‌کند.

مشکل Context

فرض کنید ابزار یک مسیر خطرناک احتمالی پیدا کرده است.

اما ممکن است قبل از رسیدن داده به نقطه حساس، Validation دیگری وجود داشته باشد که ابزار آن را به‌درستی درک نکرده باشد.

نتیجه می‌تواند False Positive باشد.

برعکس، اگر Framework یا ساختار پیچیده‌ای وجود داشته باشد که ابزار آن را نشناسد، ممکن است آسیب‌پذیری واقعی را نبیند.

این حالت False Negative است.

مشکلات منطقی

آسیب‌پذیری‌های Business Logic معمولاً به فهم منطق کسب‌وکار نیاز دارند.

برای مثال:

آیا یک کاربر باید بتواند این عملیات مالی را انجام دهد؟

آیا ترتیب مراحل خرید قابل دور زدن است؟

آیا محدودیت خاصی فقط در Frontend اعمال شده است؟

آیا کاربر A به اطلاعات کاربر B دسترسی دارد؟

تشخیص چنین مشکلاتی صرفاً از طریق تحلیل اتوماتیک کد دشوار است.

OWASP نیز محدودیت‌هایی مانند مشکلات Authentication، Access Control، Configuration و False Positive را برای تحلیل خودکار SAST مطرح می‌کند.

DAST چیست؟

DAST مخفف Dynamic Application Security Testing است و به معنی تست امنیت داینامیک یا پویا است.

برخلاف SAST، در این روش برنامه باید در حال اجرا باشد.

DAST معمولاً از بیرون با Application تعامل می‌کند.

یعنی ابزار لزوماً Source Code را نمی‌بیند.

مسیر ساده آن می‌تواند چنین باشد:

DAST Scanner ↓ HTTP/HTTPS Request ↓ Running Web Application ↓ Response ↓ Security Analysis

OWASP، DAST را روشی معرفی می‌کند که از طریق Frontend با Web Application ارتباط برقرار می‌کند و معمولاً بدون دسترسی به Source Code، رفتار امنیتی برنامه در حال اجرا را بررسی می‌کند.

به همین دلیل DAST معمولاً در دسته Black-Box Testing قرار می‌گیرد.

DAST چگونه کار می‌کند؟

یک DAST Scanner ابتدا باید سطح قابل مشاهده Application را پیدا کند.

این کار می‌تواند شامل مواردی مانند این باشد:

• Crawl کردن صفحات
• شناسایی Endpointها
• مشاهده Formها
• بررسی Parameterها
• بررسی Linkها
• تعامل با APIها
• بررسی Headerها
• مشاهده Cookieها
• شناسایی Authentication Flow

سپس Scanner درخواست‌های کنترل‌شده‌ای ایجاد می‌کند و پاسخ Application را تحلیل می‌کند.

هدف بررسی رفتار امنیتی برنامه است، نه خواندن Source Code.

مرحله Discovery

ابزار ابتدا سعی می‌کند Attack Surface قابل مشاهده را درک کند.

مثلاً:

/login

/account

/api/

/search

/checkout

/upload

این مرحله برای Coverage بسیار مهم است.

اگر Scanner نتواند یک بخش Application را پیدا کند، طبیعتاً نمی‌تواند آن را تست کند.

مرحله Test

پس از Discovery، تست‌های مختلفی بر اساس نوع Endpoint انجام می‌شود.

در تست دفاعی استاندارد، هدف شناسایی نشانه‌های ضعف است، نه ایجاد تخریب یا آسیب به داده‌ها.

مرحله Analysis

Scanner Responseها را بررسی می‌کند.

مثلاً:

Response Code

Header

Body

Redirect

Cookie Behavior

Error Message

Response Difference

Server Behavior

نتیجه می‌تواند یک Finding احتمالی باشد که نیاز به Validation انسانی دارد.

مزایای DAST چیست؟

بزرگ‌ترین مزیت DAST این است که Application واقعی را می‌بیند.

نه نسخه‌ای فرضی از کد.

مشاهده نتیجه نهایی همه لایه‌ها

یک وب‌سایت واقعی فقط Source Code نیست.

ممکن است شامل موارد زیر باشد:

CDN

WAF

Reverse Proxy

Load Balancer

Web Server

Application

Authentication Provider

Database

Cache

API Gateway

Container

Cloud Configuration

DAST از بیرون نتیجه نهایی تعامل این لایه‌ها را مشاهده می‌کند.

به همین دلیل بعضی خطاهایی که در Source Code مشخص نیستند ممکن است در DAST دیده شوند.

مناسب برای بررسی Runtime

برخی مشکلات فقط زمانی وجود دارند که Application اجرا شود.

مثلاً:

Security Header اشتباه

Cookie Configuration نامناسب

TLS Configuration

Error Handling نامناسب

Exposure یک Endpoint

Server Misconfiguration

رفتار Authentication

Redirect ناامن

مشکلات Runtime

DAST برای چنین مواردی مزیت مهمی دارد.

مستقل از زبان برنامه‌نویسی

برای یک DAST Scanner معمولاً اهمیت اصلی این است که Application چگونه از طریق HTTP یا API رفتار می‌کند.

ممکن است Backend با PHP، Java، Python، Go، Node.js یا .NET نوشته شده باشد.

DAST بیشتر Response نهایی را می‌بیند.

این ویژگی در محیط‌هایی که چند فناوری مختلف دارند مفید است.

محدودیت‌های DAST چیست؟

DAST نیز به‌تنهایی کافی نیست.

کد را نمی‌بیند

اگر DAST یک رفتار مشکوک پیدا کند، معمولاً نمی‌تواند مانند SAST مستقیماً بگوید مشکل در خط مشخص یک فایل خاص قرار دارد.

توسعه‌دهنده باید Root Cause را پیدا کند.

Coverage محدود به مسیرهای قابل دسترس

اگر Scanner نتواند Endpoint را پیدا کند، Login انجام دهد یا Workflow خاصی را طی کند، ممکن است آن بخش اصلاً تست نشود.

این مشکل در برنامه‌های مدرن بسیار مهم است.

برای مثال:

Single Page Application

APIهای پیچیده

GraphQL

Multi-Step Workflow

Role-based Areas

Admin Panel

Authenticated API

محدودیت Business Logic

ابزار اتوماتیک لزوماً نمی‌فهمد که قیمت یک محصول نباید توسط کاربر قابل تغییر باشد یا یک عملیات فقط باید یک بار انجام شود.

به همین دلیل تست دستی امنیت و بررسی Business Logic همچنان اهمیت دارند.

OWASP نیز تأکید می‌کند که برخی ضعف‌ها مانند مشکلات منطق کسب‌وکار و Race Condition ممکن است به ارزیابی انسانی نیاز داشته باشند.

تفاوت SAST و DAST در یک نگاه

<table> <thead> <tr> <th>ویژگی</th> <th>SAST</th> <th>DAST</th> </tr> </thead> <tbody> <tr> <td>نوع تست</td> <td>Static</td> <td>Dynamic</td> </tr> <tr> <td>نیاز به اجرای برنامه</td> <td>خیر</td> <td>بله</td> </tr> <tr> <td>دسترسی به Source Code</td> <td>معمولاً بله</td> <td>معمولاً خیر</td> </tr> <tr> <td>دید اصلی</td> <td>داخل برنامه</td> <td>رفتار خارجی برنامه</td> </tr> <tr> <td>مدل رایج</td> <td>White-Box / Code Analysis</td> <td>Black-Box</td> </tr> <tr> <td>زمان مناسب</td> <td>مراحل اولیه توسعه</td> <td>پس از قابل اجرا شدن Application</td> </tr> <tr> <td>محل Finding</td> <td>اغلب تا سطح فایل و کد</td> <td>اغلب Endpoint یا رفتار Application</td> </tr> <tr> <td>Runtime Configuration</td> <td>محدود</td> <td>قوی‌تر</td> </tr> <tr> <td>CI/CD Integration</td> <td>بسیار مناسب</td> <td>مناسب، به‌خصوص روی Test/Staging</td> </tr> <tr> <td>نیاز به Validation انسانی</td> <td>بله</td> <td>بله</td> </tr> </tbody> </table>

تفاوت SAST و DAST از نظر White-Box و Black-Box

یکی از روش‌های ساده برای درک تفاوت SAST و DAST استفاده از مفهوم جعبه سفید و جعبه سیاه است.

SAST؛ نگاه از داخل

در SAST ابزار به ساختار داخلی Application دسترسی دارد.

مثل این است که نقشه ساختمان را در اختیار یک بازرس قرار دهیم.

بازرس می‌تواند ببیند:

لوله‌ها از کجا عبور کرده‌اند.

کابل‌ها کجا قرار دارند.

درب‌ها چگونه طراحی شده‌اند.

حتی قسمت‌هایی که هنوز کسی از آن‌ها استفاده نکرده است نیز روی نقشه وجود دارند.

DAST؛ نگاه از بیرون

DAST بیشتر شبیه بازدیدکننده‌ای است که ساختمان ساخته‌شده را بررسی می‌کند.

نقشه را ندارد.

اما می‌تواند ببیند:

کدام در واقعاً باز است.

کدام قفل کار نمی‌کند.

چه چیزی از بیرون قابل مشاهده است.

رفتار واقعی سیستم چیست.

هر دو نگاه ارزشمند هستند.

نقشه ممکن است مشکلی را نشان دهد که هنوز از بیرون قابل مشاهده نیست.

در مقابل، رفتار واقعی ساختمان ممکن است مشکلی داشته باشد که روی نقشه مشخص نباشد.

SAST چه آسیب‌پذیری‌هایی را می‌تواند بهتر شناسایی کند؟

هیچ فهرستی برای تمام ابزارهای SAST یکسان نیست، زیرا توانایی ابزار، زبان برنامه‌نویسی و Framework بسیار مهم است.

اما به‌صورت کلی SAST در مواردی مانند این‌ها مفید است:

• Code Injection Patternها
• SQL Injection احتمالی
• XSS در مسیرهای قابل تحلیل
• استفاده ناامن از Functionها
• Hardcoded Credentials
• Hardcoded API Key
• Weak Cryptographic Usage
• Path Manipulation
• Unsafe Deserialization Pattern
• Command Execution Pattern
• Insecure Randomness
• ضعف‌های Memory Safety در زبان‌های مرتبط
• نشت اطلاعات حساس در کد
• Validation ناقص ورودی
• استفاده ناامن از APIهای حساس

نکته مهم عبارت «احتمالی» است.

SAST معمولاً Finding تولید می‌کند.

این Finding باید بررسی شود تا مشخص شود واقعاً Vulnerable است یا خیر.

DAST چه آسیب‌پذیری‌هایی را بهتر شناسایی می‌کند؟

DAST از طریق رفتار Runtime کار می‌کند و برای مواردی مانند این‌ها مناسب است:

• برخی انواع Injection
• XSS قابل مشاهده در Runtime
• Security Misconfiguration
• HTTP Security Header Issues
• Cookie Security Problems
• Session-related Weaknesses
• TLS-related Configuration
• Error Information Leakage
• Open Redirect
• Authentication Behavior
• بعضی مشکلات Access Control
• Endpoint Exposure
• Server Configuration Issues
• برخی مشکلات API Security

باز هم توانایی ابزارها متفاوت است.

یک DAST Scanner نباید جای Penetration Test انسانی را بگیرد.

چرا بعضی آسیب‌پذیری‌ها فقط در SAST دیده می‌شوند؟

فرض کنید در کد یک مسیر خطرناک وجود دارد، اما برای فعال شدن به شرایط خاصی نیاز دارد.

ممکن است DAST هرگز به آن مسیر نرسد.

برای مثال:

Feature هنوز در UI لینک نشده است.

Endpoint فقط در حالت خاصی فراخوانی می‌شود.

کد Legacy همچنان داخل پروژه وجود دارد.

Branch خاصی به‌ندرت اجرا می‌شود.

SAST می‌تواند آن کد را ببیند، حتی اگر DAST نتواند آن را Trigger کند.

چرا بعضی مشکلات فقط در DAST مشخص می‌شوند؟

در طرف مقابل، ممکن است Source Code صحیح به نظر برسد اما Deployment اشتباه باشد.

مثلاً:

Header امنیتی حذف شده است.

Reverse Proxy تنظیم نادرستی دارد.

Cookie در محیط Production بدون Attribute مناسب ارسال می‌شود.

یک Backup File از Web Root قابل دسترسی شده است.

Debug Mode فعال مانده است.

Endpoint آزمایشی Deploy شده است.

این مسائل ممکن است در Source Code اصلی Application مشخص نباشند.

اما DAST نسخه در حال اجرا را مشاهده می‌کند.

False Positive در SAST و DAST چیست؟

False Positive یعنی ابزار یک مورد را به‌عنوان مشکل امنیتی گزارش کند، در حالی که پس از بررسی مشخص شود آسیب‌پذیری واقعی وجود ندارد.

برای مثال ابزار ممکن است تصور کند ورودی کاربر بدون Validation به یک عملیات حساس می‌رسد، اما در مسیر دیگری که Scanner به‌درستی درک نکرده Sanitization انجام شده باشد.

False Positive صرفاً مزاحمت نیست.

اگر تعداد آن زیاد شود، چند مشکل ایجاد می‌کند:

• تیم توسعه به هشدارها اعتماد نمی‌کند.
• زمان Security Team هدر می‌رود.
• Findingهای واقعی میان Noise گم می‌شوند.
• Pipeline عملاً غیرقابل استفاده می‌شود.

به همین دلیل کیفیت Ruleها و Tuning ابزار بسیار مهم است.

False Negative چیست؟

False Negative خطرناک‌تر است.

یعنی آسیب‌پذیری واقعاً وجود دارد اما ابزار آن را گزارش نمی‌کند.

هیچ SAST یا DAST حرفه‌ای نباید با این ذهنیت استفاده شود که:

«Scan سبز است، پس برنامه امن است.»

نتیجه صحیح این است:

«Scanner در محدوده Coverage و Capability خودش Finding مهم دیگری پیدا نکرده است.»

این تفاوت در زبان امنیت بسیار مهم است.

Coverage؛ مهم‌تر از تعداد Findingها

یک گزارش با ۲۰۰ Finding الزاماً بهتر از گزارشی با ۲۰ Finding نیست.

یکی از معیارهای کلیدی Coverage است.

در SAST باید پرسید:

آیا تمام Repository اسکن شده؟

آیا زبان‌ها پشتیبانی می‌شوند؟

آیا Generated Code حذف شده؟

آیا Framework شناخته می‌شود؟

آیا Data Flow بین Moduleها بررسی می‌شود؟

در DAST باید پرسید:

آیا تمام Endpointها Crawl شدند؟

آیا Authentication انجام شد؟

آیا صفحات Roleهای مختلف بررسی شدند؟

آیا APIها وارد Scope شدند؟

آیا SPA و JavaScript Routing دیده شدند؟

اگر Coverage پایین باشد، نتیجه Scan می‌تواند احساس امنیت کاذب ایجاد کند.

SAST در چرخه توسعه نرم‌افزار کجا اجرا می‌شود؟

یکی از بزرگ‌ترین نقاط قوت SAST امکان اجرای زودهنگام آن است.

یک Workflow مناسب می‌تواند چنین باشد:

Developer ↓ IDE Security Check ↓ Commit ↓ Pull Request ↓ SAST Scan ↓ Review ↓ Merge ↓ Build

این روش باعث می‌شود بعضی مشکلات زمانی پیدا شوند که Developer هنوز Context کد را به خاطر دارد.

OWASP استفاده از تست‌های امنیتی خودکار مانند SAST و DAST را در نقاطی مانند Pull Request، Merge و اجرای دوره‌ای در فرایند توسعه مطرح می‌کند.

SAST داخل IDE

بازخورد سریع‌ترین حالت ممکن است.

توسعه‌دهنده کد می‌نویسد و Tool همان زمان هشدار می‌دهد.

مزیت:

Fix ارزان‌تر و سریع‌تر.

محدودیت:

Scan ممکن است سبک‌تر و محدودتر باشد.

SAST در Pull Request

یکی از بهترین نقاط برای اجرای SAST است.

کد جدید قبل از Merge بررسی می‌شود.

بهتر است Policy مشخص باشد.

مثلاً:

Critical → Block Merge

High → Security Review

Medium → Ticket

Low → Track

البته Severity ابزار نباید بدون Context معیار نهایی باشد.

DAST در SDLC کجا اجرا می‌شود؟

DAST به Application قابل اجرا نیاز دارد.

بنابراین معمولاً بعدتر وارد Workflow می‌شود.

نمونه:

Build ↓ Deploy to Test Environment ↓ Integration Test ↓ DAST ↓ Security Review ↓ Release

محیط مناسب DAST اغلب Staging یا یک محیط ایزوله شبیه Production است.

چرا DAST روی Production همیشه انتخاب خوبی نیست؟

بعضی تست‌های Dynamic می‌توانند:

Load ایجاد کنند.

Log زیادی بسازند.

Session ایجاد کنند.

داده آزمایشی تولید کنند.

Workflow برنامه را تغییر دهند.

به همین دلیل نوع Scan باید متناسب با Environment انتخاب شود.

اسکن فعال Production باید با دقت، Scope و کنترل مناسب انجام شود.

SAST و DAST در CI/CD

DevSecOps تلاش می‌کند Security را از یک مرحله جداگانه در انتهای پروژه به بخشی از جریان توسعه تبدیل کند.

NIST نیز در Secure Software Development Framework بر ادغام اقدامات امنیتی با SDLC تأکید می‌کند تا ضعف‌ها پیش از انتشار کاهش یابند و علت‌های ریشه‌ای مشکلات بهتر مدیریت شوند.

یک Pipeline ساده می‌تواند چنین باشد:

Source Code ↓ SAST ↓ SCA ↓ Build ↓ Unit Tests ↓ Deploy to Staging ↓ DAST ↓ Security Gate ↓ Production

این مدل بسیار قوی‌تر از حالتی است که تیم امنیت فقط چند روز قبل از Release پروژه را ببیند.

Security Gate چیست؟

Security Gate یک Policy تصمیم‌گیری است.

برای مثال:

وجود Critical Finding تأییدشده → Release متوقف شود.

High Finding → نیاز به Security Approval.

Medium Finding → Fix Deadline.

Low Finding → Risk Tracking.

اما Gate باید هوشمند باشد.

اگر هر False Positive باعث شکست Build شود، توسعه‌دهندگان به‌سرعت از ابزار خسته می‌شوند.

Security Gate باید:

Risk-based

Context-aware

Tunable

Documented

باشد.

تفاوت SAST و DAST با SCA

یکی از اشتباهات رایج این است که SAST و SCA یکسان در نظر گرفته شوند.

این دو ابزار هدف متفاوتی دارند.

SAST

کد Application را از نظر ضعف‌های امنیتی تحلیل می‌کند.

SCA

Software Composition Analysis بیشتر روی Componentها و Dependencyهای شخص ثالث تمرکز دارد.

برای مثال:

Application شما ممکن است کد اختصاصی امنی داشته باشد.

اما از Library آسیب‌پذیر استفاده کند.

SAST الزاماً برای Inventory و CVEهای Dependency طراحی نشده است.

SCA برای این مسئله اهمیت زیادی دارد.

در معماری مدرن بهتر است هر دو وجود داشته باشند.

تفاوت DAST با Vulnerability Scanner زیرساخت

DAST عمدتاً Application Layer را هدف می‌گیرد.

اما Network Vulnerability Scanner ممکن است موارد دیگری را بررسی کند:

Open Ports

Operating System

Network Services

TLS Service

Software Version

Exposed Management Service

Misconfiguration

این ابزارها مکمل هستند.

اسکن شبکه جای DAST را نمی‌گیرد و DAST نیز جای Infrastructure Security Assessment را نمی‌گیرد.

IAST چیست و چه ارتباطی با SAST و DAST دارد؟

IAST مخفف Interactive Application Security Testing است.

این روش تلاش می‌کند بخشی از مزایای تحلیل داخلی و تست Runtime را ترکیب کند.

Application اجرا می‌شود اما Instrumentation یا Agent می‌تواند رفتار داخلی را نیز مشاهده کند.

مدل ساده:

Test Input ↓ Running Application ↓ IAST Agent observes internal execution ↓ Finding

IAST می‌تواند Context بیشتری نسبت به DAST ارائه کند، اما Deployment و Integration آن نیز پیچیده‌تر است.

OWASP در راهنمای توسعه امن، SAST، DAST و IAST را به‌عنوان روش‌های متفاوت تست امنیت Application در فرایند DevSecOps مطرح می‌کند.

آیا SAST جای Code Review امنیتی را می‌گیرد؟

خیر.

ابزار SAST می‌تواند تعداد زیادی Pattern را سریع بررسی کند.

اما انسان می‌تواند Contextی را درک کند که ابزار ممکن است نبیند.

برای مثال:

منطق دسترسی

Business Rule

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

Threat Model

Architecture

رفتار غیرعادی Workflow

بهترین مدل:

Automated SAST

*

Manual Secure Code Review برای قسمت‌های حساس

است.

آیا DAST جای Penetration Test را می‌گیرد؟

خیر.

DAST خودکار برای Coverage گسترده و تکرارپذیر عالی است.

اما Penetration Test انسانی می‌تواند ارتباط میان چند ضعف را درک کند.

برای نمونه Pentester ممکن است متوجه شود:

Feature A اطلاعاتی آشکار می‌کند.

Feature B محدودیت ناقصی دارد.

ترکیب این دو یک Risk واقعی ایجاد می‌کند.

Scanner اتوماتیک ممکن است هر دو مورد را جداگانه یا حتی اصلاً شناسایی نکند.

به همین دلیل امنیت حرفه‌ای معمولاً چند لایه Verification دارد.

تست امنیت WordPress با SAST و DAST

در WordPress نیز هر دو روش کاربرد دارند، اما Scope باید درست تعریف شود.

SAST در WordPress

اگر تیم شما Plugin یا Theme اختصاصی توسعه می‌دهد، SAST می‌تواند کد PHP، JavaScript یا بخش‌های مرتبط را بررسی کند.

موارد قابل توجه:

Input Validation

Output Encoding

Nonce Handling Pattern

Database Query Handling

File Operations

Authentication Logic

Capability Check

Secret Exposure

Custom REST API

Ajax Handler

اما کیفیت نتیجه به توانایی ابزار در درک WordPress API بستگی دارد.

DAST در WordPress

DAST نسخه اجراشده سایت را بررسی می‌کند.

برای نمونه می‌تواند بخش‌های قابل مشاهده مانند این موارد را ارزیابی کند:

Login

REST API

Custom Form

Search

Upload Interface

HTTP Headers

Cookie Configuration

Public Endpointها

Redirect Behavior

اما برای پنل Admin باید Authentication و Scope کاملاً کنترل‌شده باشد.

DAST و سایت‌هایی که WAF دارند

وجود WAF می‌تواند روی نتیجه DAST تأثیر بگذارد.

فرض کنید Scanner درخواست خاصی ارسال می‌کند.

WAF آن را Block می‌کند.

DAST ممکن است نتیجه بگیرد Application در برابر آن تست مقاوم است.

اما سؤال مهم این است:

آیا خود Application امن است یا WAF مشکل را موقتاً پوشانده است؟

این دو موضوع متفاوت هستند.

در Security Assessment باید مشخص شود هدف چیست:

تست کل Stack؟

یا تست خود Application؟

اگر هدف بررسی Defense in Depth باشد، وجود WAF بخشی از طراحی امنیتی است.

اگر هدف بررسی Root Cause در کد باشد، باید Application نیز جداگانه ارزیابی شود.

Authentication یکی از چالش‌های اصلی DAST

بخش بزرگی از Applicationهای مدرن پشت Login قرار دارند.

اگر DAST فقط صفحات Public را ببیند، Coverage بسیار محدود خواهد بود.

Scanner باید بتواند Authentication Flow مجاز را مدیریت کند.

موضوعات مهم:

Session

Token

Cookie

OAuth

OIDC

2FA در محیط Test

Roleهای مختلف

Session Expiration

اگر برنامه چند Role داشته باشد، فقط تست یک حساب کافی نیست.

مثلاً:

Guest

Customer

Editor

Manager

Administrator

هر Role Attack Surface متفاوتی دارد.

APIها و تفاوت SAST و DAST

در معماری مدرن، بخش بزرگی از منطق برنامه در API قرار دارد.

SAST می‌تواند Implementation API را بررسی کند.

DAST می‌تواند API در حال اجرا را از بیرون ارزیابی کند.

برای API بهتر است Scanner از Specification نیز استفاده کند.

مانند:

OpenAPI

Swagger

GraphQL Schema در محیط مجاز

این کار Coverage را افزایش می‌دهد.

اما مهم‌ترین مشکلات API اغلب به Authorization و Business Logic مرتبط هستند و Automation به‌تنهایی کافی نیست.

اهمیت Threat Modeling قبل از SAST و DAST

اگر ندانیم چه چیزی را محافظت می‌کنیم، Scan تبدیل به فهرستی از Alertها می‌شود.

Threat Modeling کمک می‌کند مشخص شود:

Asset چیست؟

Trust Boundary کجاست؟

کدام Data حساس است؟

چه Roleهایی داریم؟

کدام Endpoint حساس است؟

کدام سرویس External است؟

بدترین Failure Scenario چیست؟

سپس SAST و DAST می‌توانند بر اساس Risk واقعی اولویت‌بندی شوند.

Severity با Risk برابر نیست

یکی دیگر از خطاهای رایج این است که Severity ابزار مستقیماً معادل Risk کسب‌وکار تلقی شود.

Risk به عوامل بیشتری وابسته است.

برای نمونه:

Exploitability

Impact

Exposure

Authentication Requirement

Data Sensitivity

Business Context

Compensating Controls

Reachability

یک Finding با Severity بالا ممکن است در یک مسیر غیرقابل دسترس باشد.

در مقابل یک Finding ظاهراً متوسط ممکن است روی سیستم مالی بسیار حساس قرار داشته باشد.

بنابراین Triaging لازم است.

Triaging نتایج SAST و DAST

Triaging یعنی Findingها قبل از Fix بررسی و دسته‌بندی شوند.

یک فرآیند مناسب:

Finding ایجاد شد ↓ Duplicate Check ↓ Validation ↓ Context Analysis ↓ Risk Rating ↓ Owner Assignment ↓ Fix ↓ Retest ↓ Close

بدون Triaging، Dashboard امنیت به انبار هشدار تبدیل می‌شود.

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

ترکیب مناسبی از افراد لازم است:

Developer

Application Security Engineer

Security Champion

Software Architect

در بعضی Findingها توسعه‌دهنده Context کد را بهتر می‌داند.

در بعضی دیگر Security Engineer Risk را بهتر ارزیابی می‌کند.

هدف نباید این باشد که Security Team به تنهایی هزاران Alert را مدیریت کند.

Security Champion چه نقشی دارد؟

Security Champion معمولاً عضوی از تیم توسعه است که دانش امنیتی بیشتری دارد و ارتباط میان تیم Security و Developerها را ساده‌تر می‌کند.

در پروژه بزرگ، این نقش می‌تواند به موارد زیر کمک کند:

Triage

Rule Tuning

Secure Coding

Threat Modeling

Developer Training

Security Review

این مدل باعث می‌شود امنیت فقط مسئولیت یک تیم جداگانه نباشد.

چگونه SAST مناسب انتخاب کنیم؟

انتخاب ابزار فقط براساس تعداد Vulnerability Rule اشتباه است.

پشتیبانی از زبان

اولین سؤال:

آیا ابزار زبان و Framework شما را خوب می‌شناسد؟

یک Scanner فوق‌العاده برای Java ممکن است برای PHP انتخاب مناسبی نباشد.

Framework Awareness

Framework اهمیت زیادی دارد.

برای مثال Security Model در:

Laravel

Django

Spring

ASP.NET

WordPress

React

Next.js

متفاوت است.

هرچه Scanner Context بیشتری بداند، نتیجه بهتر خواهد بود.

سرعت

Full Scan ممکن است زمان زیادی ببرد.

برخی تیم‌ها مدل دو مرحله‌ای دارند:

Pull Request → Incremental Scan

Nightly → Full Scan

قابلیت CI/CD

ابزار باید با Pipeline سازگار باشد.

مثلاً:

CLI

API

GitHub/GitLab Integration

SARIF

JSON Output

Exit Code

کیفیت Finding

Finding خوب باید توضیح دهد:

مشکل چیست؟

کجاست؟

چرا خطرناک است؟

Data Flow چگونه است؟

چگونه اصلاح شود؟

چگونه DAST مناسب انتخاب کنیم؟

در DAST معیارها کمی متفاوت‌اند.

Crawler قوی

اگر Crawler Application را پیدا نکند، Scan ناقص خواهد بود.

Authentication

آیا Scanner می‌تواند Login برنامه را مدیریت کند؟

API Support

آیا OpenAPI یا سایر API Definitionها را می‌خواند؟

JavaScript Support

برای SPAها بسیار مهم است.

Scan Control

آیا می‌توان تعیین کرد:

چه Hostهایی مجاز هستند؟

چه URLهایی خارج Scope هستند؟

چه تست‌هایی اجرا شوند؟

Rate چقدر باشد؟

این کنترل برای جلوگیری از اختلال ضروری است.

Reporting

Report باید قابل استفاده برای Developer باشد، نه فقط تیم Security.

یک معماری پیشنهادی DevSecOps برای SAST و DAST

یک مدل متعادل می‌تواند چنین باشد:

Developer IDE ↓ Lightweight Security Analysis ↓ Git Push ↓ Pull Request ↓ SAST ↓ Secret Scan ↓ SCA ↓ Build ↓ Automated Tests ↓ Deploy to Staging ↓ DAST ↓ Manual Review for Sensitive Changes ↓ Release ↓ Continuous Monitoring

این مدل مفهوم Continuous Security Testing را بهتر از یک تست سالانه اجرا می‌کند.

آیا هر Commit باید Full SAST و Full DAST اجرا کند؟

نه لزوماً.

این تصمیم باید بر اساس سرعت Pipeline و Risk باشد.

یک مدل عملی:

روی Commit

Lint

Secret Detection

Fast SAST

روی Pull Request

SAST مرتبط با تغییرات

SCA

Policy Check

Nightly

Full SAST

Broad DAST

قبل از Release مهم

Full Security Pipeline

Manual Review

Regression Security Test

این روش تعادل مناسبی بین سرعت و Coverage ایجاد می‌کند.

تست امنیت Regression چیست؟

فرض کنید یک آسیب‌پذیری پیدا و Fix شده است.

نباید فقط یک بار آن را بررسی کنیم.

بهتر است Test مربوط به آن وارد Regression Security Testing شود.

هدف:

اگر همان مشکل در آینده دوباره ایجاد شد، Pipeline آن را تشخیص دهد.

این کار یکی از مؤثرترین راه‌های جلوگیری از بازگشت آسیب‌پذیری‌های قدیمی است.

چگونه False Positive را کاهش دهیم؟

ابزار را نباید نصب کرد و برای همیشه با Ruleهای Default رها کرد.

راهکارهای مفید:

• تنظیم Ruleها براساس Technology
• حذف Ruleهای نامرتبط
• تعریف Trusted Sanitizer
• Baseline کردن پروژه قدیمی
• Mark کردن False Positive تأییدشده
• آموزش Developerها
• بررسی دوره‌ای Rule Set
• تفکیک New Finding از Existing Finding

هدف کم کردن Noise بدون کور کردن Scanner است.

Baseline در پروژه قدیمی

فرض کنید پروژه‌ای ده ساله را برای اولین بار SAST می‌کنید.

ممکن است هزاران Finding دریافت کنید.

اگر Pipeline را روی «صفر Finding» تنظیم کنید، هیچ Release دیگری ممکن نخواهد بود.

یک راهکار واقع‌بینانه:

Existing Findings → Baseline

New Critical/High Findings → Block

Old Findings → Remediation Program

در طول زمان Technical Security Debt کاهش پیدا می‌کند.

اشتباهات رایج در استفاده از SAST و DAST

تصور اینکه Scan سبز یعنی سایت امن است

هیچ Scanner پوشش کامل ندارد.

SAST و DAST فقط بخشی از Security Verification هستند.

استفاده فقط از SAST

SAST Runtime و Deployment واقعی را کامل نمی‌بیند.

استفاده فقط از DAST

DAST دید کاملی به Source Code و مسیرهای داخلی ندارد.

اسکن DAST بدون Login

در Application احراز هویت‌شده، این کار بخش بزرگی از Attack Surface را حذف می‌کند.

اعتماد کامل به Severity ابزار

Risk باید با Context سازمان تعیین شود.

Fix نکردن Root Cause

گاهی تیم فقط Symptom را برطرف می‌کند.

مثلاً Rule خاصی در WAF می‌گذارد، اما Code Vulnerability باقی می‌ماند.

اجرا کردن DAST بدون Scope

Scanner امنیتی نباید بدون محدوده مشخص روی Environment حساس اجرا شود.

Block کردن Pipeline با تمام Findings

اگر Low و False Positive نیز Release را متوقف کنند، تیم به‌مرور Security Gate را دور خواهد زد.

نداشتن Owner

هر Finding باید Owner داشته باشد.

Security Issue بدون مسئول معمولاً حل نمی‌شود.

نداشتن Retest

بستن Ticket بدون Verification کافی نیست.

Fix باید دوباره بررسی شود.

SAST و DAST چه چیزی را پیدا نمی‌کنند؟

این سؤال از «چه چیزی پیدا می‌کنند؟» مهم‌تر است.

SAST و DAST ممکن است در شناسایی موارد زیر محدودیت داشته باشند:

• Complex Business Logic
• معماری ناامن
• Threatهای سازمانی
• فرایند Recovery ضعیف
• ضعف انسانی
• Social Engineering
• ضعف مدیریت دسترسی سازمانی
• بعضی Race Conditionها
• برخی Authorization Chainها
• سوءاستفاده ترکیبی از چند Feature
• Riskهای خارج از Scope Application

بنابراین Application Security باید شامل کنترل‌های دیگری نیز باشد.

SAST و DAST در کنار چه روش‌هایی استفاده شوند؟

یک برنامه کامل‌تر می‌تواند شامل این موارد باشد:

Threat Modeling

Secure Code Review

SAST

DAST

SCA

Secret Scanning

Infrastructure Scanning

Container Scanning

IaC Scanning

Penetration Testing

Configuration Review

Security Monitoring

Logging

Incident Response

NIST نیز توصیه می‌کند اقدامات امنیتی به‌عنوان مجموعه‌ای از Practiceها در SDLC ادغام شوند، نه اینکه امنیت به یک ابزار یا تست واحد محدود شود.

چک‌لیست پیاده‌سازی SAST

• زبان‌ها و Frameworkهای پروژه مشخص شده‌اند.
• Scanner از فناوری پروژه پشتیبانی می‌کند.
• Repositoryهای اصلی در Scope هستند.
• Generated Code از Scan مناسب حذف شده است.
• Rule Set تنظیم شده است.
• Pull Request Scan فعال است.
• Full Scan دوره‌ای وجود دارد.
• Critical Findingها Security Gate دارند.
• False Positiveها مدیریت می‌شوند.
• Findingها Owner دارند.
• Fixها Retest می‌شوند.
• Metrics ثبت می‌شوند.
• Developerها گزارش را می‌فهمند.

چک‌لیست پیاده‌سازی DAST

• Environment تست مشخص است.
• Scope دقیق تعریف شده است.
• Authentication پیکربندی شده است.
• Roleهای مهم پوشش داده می‌شوند.
• APIها وارد Scope شده‌اند.
• Scanner صفحات JavaScript را در صورت نیاز می‌بیند.
• Crawl Coverage بررسی می‌شود.
• Rate Scan کنترل شده است.
• داده آزمایشی مدیریت می‌شود.
• Scan مخرب روی Production اجرا نمی‌شود مگر با برنامه مشخص.
• Findingها Validate می‌شوند.
• Fixها Retest می‌شوند.

معیارهای مفید برای اندازه‌گیری برنامه امنیتی

فقط تعداد Finding معیار خوبی نیست.

شاخص‌های بهتر می‌توانند شامل موارد زیر باشند:

Mean Time to Remediate

از زمان پیدا شدن Finding تا Fix چقدر طول می‌کشد؟

Reopened Vulnerabilities

چند مشکل پس از Fix دوباره برگشته‌اند؟

New Vulnerabilities per Release

آیا کیفیت امنیتی Releaseها بهتر می‌شود؟

Scan Coverage

چه درصدی از Repository و Endpointها تحت تست هستند؟

False Positive Rate

آیا Tool Tuning مؤثر بوده است؟

Critical Finding Age

آیا آسیب‌پذیری‌های مهم مدت زیادی باز می‌مانند؟

Security Debt

چه تعداد Finding قدیمی باقی مانده است؟

این Metrics می‌توانند بلوغ واقعی برنامه امنیتی را بهتر نشان دهند.

برای یک سایت کوچک SAST مهم‌تر است یا DAST؟

به معماری سایت بستگی دارد.

اگر سایت یک Application اختصاصی است و Source Code در اختیار تیم قرار دارد، SAST ارزش بالایی دارد.

اگر سایت عمدتاً یک CMS آماده با تعداد زیادی Plugin است، SCA، Patch Management، Configuration Review و DAST نیز اهمیت زیادی خواهند داشت.

بهترین تصمیم براساس Risk است.

برای مثال یک سایت فروشگاهی کوچک نیز اطلاعات حساس و عملیات مالی دارد و نباید صرفاً به دلیل اندازه سازمان، Security Testing کنار گذاشته شود.

برای یک پروژه جدید از کجا شروع کنیم؟

یک مسیر عملی:

1. Threat Model اولیه ایجاد کنید.
2. Secure Coding Guideline مشخص کنید.
3. SAST را وارد Pull Request کنید.
4. Dependencyها را با SCA کنترل کنید.
5. Secret Scanning فعال کنید.
6. Staging مشابه Production بسازید.
7. DAST را روی Staging اجرا کنید.
8. Findingها را Triage کنید.
9. Critical و Highها را قبل از Release مدیریت کنید.
10. برای Release حساس Penetration Test انسانی انجام دهید.
11. Findings تأییدشده را وارد Regression Test کنید.
12. Metrics امنیتی را در طول زمان بررسی کنید.

این روش بسیار مؤثرتر از یک «اسکن امنیتی نهایی» در روز آخر پروژه است.

برای یک پروژه قدیمی از کجا شروع کنیم؟

پروژه Legacy وضعیت متفاوتی دارد.

اولین Full SAST ممکن است تعداد زیادی Finding ایجاد کند.

DAST نیز ممکن است مشکلات متعدد Deployment را گزارش کند.

در این حالت اولویت‌بندی ضروری است.

ترتیب مناسب:

Internet-facing Critical Issues

↓

Authentication & Authorization

↓

Sensitive Data

↓

High-risk Code Paths

↓

Known Vulnerable Dependencies

↓

Configuration

↓

Remaining Technical Security Debt

هدف اصلاح Risk واقعی است، نه صرفاً صفر کردن Dashboard.

آیا ابزار رایگان کافی است؟

رایگان یا تجاری بودن Tool به‌تنهایی کیفیت Security Program را مشخص نمی‌کند.

ابزار رایگان با Configuration درست، Scope مناسب و تیم آگاه می‌تواند بسیار مفید باشد.

ابزار گران‌قیمت بدون Process صحیح ممکن است فقط Dashboard زیبایی تولید کند.

هنگام انتخاب باید این موارد بررسی شوند:

Accuracy

Coverage

Language Support

Framework Support

Integration

Performance

Reporting

Workflow

Developer Experience

Maintenance

Cost

آیا هوش مصنوعی جای SAST و DAST را می‌گیرد؟

هوش مصنوعی می‌تواند تحلیل کد، Triage و توضیح Findingها را بهبود دهد، اما اصول بنیادین تست امنیت همچنان باقی می‌مانند.

هر سیستم مبتنی بر AI نیز باید از نظر موارد زیر ارزیابی شود:

False Positive

False Negative

Context

Data Privacy

Source Code Exposure

Model Reliability

Reproducibility

در امنیت، اعتماد کامل به یک موتور خودکار—چه Rule-based و چه AI-based—رویکرد مناسبی نیست.

آینده Application Security به سمت ترکیب داده‌ها می‌رود

یکی از چالش‌های تیم‌های امنیتی امروز این است که ابزارهای مختلف گزارش‌های جداگانه تولید می‌کنند.

SAST یک Finding دارد.

DAST Finding دیگری دارد.

SCA یک Dependency را گزارش می‌کند.

Cloud Scanner یک Misconfiguration پیدا می‌کند.

اما ممکن است همه آن‌ها به یک Application مرتبط باشند.

به همین دلیل Application Security مدرن به سمت Correlation حرکت می‌کند.

هدف فقط «پیدا کردن تعداد بیشتری Alert» نیست.

هدف پاسخ به این سؤال است:

کدام مشکل واقعاً قابل دسترسی است، چه Assetی را تحت تأثیر قرار می‌دهد و Fix کدام مورد بیشترین کاهش Risk را ایجاد می‌کند؟

سؤالات متداول

SAST چیست؟

SAST یا Static Application Security Testing روشی برای تحلیل امنیتی کد برنامه بدون نیاز به اجرای Application است. این روش می‌تواند Source Code یا در برخی ابزارها Bytecode و Binary را بررسی کند و مشکلات احتمالی امنیتی را به توسعه‌دهندگان گزارش دهد.

DAST چیست؟

DAST یا Dynamic Application Security Testing برنامه در حال اجرا را از بیرون بررسی می‌کند. Scanner با وب‌سایت یا API تعامل می‌کند و رفتار امنیتی واقعی Application را تحلیل می‌کند.

مهم‌ترین تفاوت SAST و DAST چیست؟

مهم‌ترین تفاوت این است که SAST داخل کد را بدون اجرای برنامه بررسی می‌کند، اما DAST نسخه در حال اجرا را از بیرون آزمایش می‌کند. بنابراین هرکدام بخش متفاوتی از Risk را مشاهده می‌کنند.

SAST بهتر است یا DAST؟

هیچ‌کدام به‌طور مطلق بهتر نیستند. SAST برای شناسایی زودهنگام مشکلات کد مناسب است و DAST رفتار Runtime و Deployment را بررسی می‌کند. استفاده ترکیبی پوشش بهتری ایجاد می‌کند.

آیا SAST به Source Code نیاز دارد؟

در اغلب موارد بله، اگرچه بعضی ابزارها می‌توانند Bytecode یا Binary را نیز تحلیل کنند.

آیا DAST به Source Code نیاز دارد؟

معمولاً خیر. DAST از طریق Interface قابل دسترسی Application مانند HTTP و API با سیستم تعامل می‌کند.

آیا SAST می‌تواند SQL Injection را پیدا کند؟

بسیاری از ابزارهای SAST توانایی شناسایی Patternها و Data Flowهای مرتبط با SQL Injection را دارند، اما نتیجه باید Validate شود و هیچ ابزاری پوشش صددرصد ندارد.

آیا DAST می‌تواند XSS را پیدا کند؟

بسیاری از DAST Scannerها برای شناسایی انواعی از XSS طراحی شده‌اند، اما Coverage به Endpoint، Authentication، JavaScript Handling و توانایی Scanner بستگی دارد.

آیا SAST برای WordPress کاربرد دارد؟

اگر Plugin، Theme یا کد PHP اختصاصی دارید، SAST می‌تواند مفید باشد. برای WordPress باید ابزار و Ruleهایی انتخاب شوند که Context این اکوسیستم را درک کنند.

آیا DAST را می‌توان روی سایت Production اجرا کرد؟

برخی حالت‌های Passive یا کنترل‌شده ممکن است روی Production قابل استفاده باشند، اما Active Scan می‌تواند بار یا تغییرات ناخواسته ایجاد کند. محیط Staging ایزوله معمولاً گزینه مناسب‌تری برای تست گسترده است.

آیا SAST و DAST جای Penetration Test را می‌گیرند؟

خیر. آن‌ها Automation و Coverage تکرارپذیر ایجاد می‌کنند، اما Pentest انسانی برای بررسی Business Logic، ترکیب چند ضعف و سناریوهای پیچیده همچنان اهمیت دارد.

تفاوت SAST با SCA چیست؟

SAST عمدتاً کد Application را بررسی می‌کند، در حالی که SCA روی Componentها و Dependencyهای شخص ثالث، نسخه آن‌ها و آسیب‌پذیری‌های شناخته‌شده تمرکز دارد.

IAST چیست؟

IAST برنامه در حال اجرا را با مشاهده داخلی Runtime تحلیل می‌کند و تلاش دارد بخشی از مزایای تحلیل داخلی SAST و تست پویا را ترکیب کند.

آیا یک گزارش بدون Finding یعنی وب‌سایت امن است؟

خیر. هیچ ابزار امنیتی پوشش کامل ندارد. نبود Finding فقط نشان می‌دهد ابزار در Scope و Capability مشخص خود مورد دیگری پیدا نکرده است.

SAST باید چه زمانی اجرا شود؟

بهتر است SAST از مراحل اولیه توسعه شروع شود و در IDE، Pull Request و CI/CD اجرا شود.

DAST باید چه زمانی اجرا شود؟

زمانی که یک نسخه قابل اجرای Application در Test یا Staging وجود دارد. اجرای دوره‌ای و پیش از Releaseهای مهم می‌تواند بسیار مفید باشد.

جمع‌بندی

SAST و DAST دو دید متفاوت به امنیت یک Application ارائه می‌کنند.

SAST از داخل به نرم‌افزار نگاه می‌کند. Source Code، Data Flow، Functionها و Patternهای برنامه‌نویسی را بررسی می‌کند و تلاش می‌کند مشکلات را زمانی پیدا کند که هنوز در مرحله توسعه هستند. به همین دلیل SAST ابزار مهمی برای Shift Left، Secure Coding و CI/CD محسوب می‌شود.

اما کد تنها بخشی از واقعیت یک وب‌سایت است.

وقتی نرم‌افزار Deploy می‌شود، Web Server، Reverse Proxy، Authentication، Cookieها، APIها، Headerها، TLS، Cache، WAF و Configuration نیز وارد معادله می‌شوند. اینجاست که DAST ارزش خود را نشان می‌دهد؛ زیرا نسخه واقعی و در حال اجرای Application را از بیرون بررسی می‌کند.

بنابراین سؤال صحیح این نیست که «SAST بهتر است یا DAST؟»

سؤال صحیح این است:

کدام Riskها را SAST می‌بیند، کدام Riskها را DAST می‌بیند و چه چیزی ممکن است از دید هر دو پنهان بماند؟

یک برنامه امنیتی قابل دفاع باید بداند هیچ Scannerی کامل نیست.

SAST می‌تواند False Positive تولید کند.

DAST ممکن است Endpointی را پیدا نکند.

هر دو ممکن است بعضی مشکلات Business Logic را از دست بدهند.

SCA برای Dependencyها لازم است.

Threat Modeling برای معماری لازم است.

Manual Code Review برای Context لازم است.

Penetration Testing برای سناریوهای پیچیده لازم است.

Monitoring برای آنچه پس از Release اتفاق می‌افتد لازم است.

در نتیجه، تفاوت SAST و DAST نباید باعث انتخاب یکی و حذف دیگری شود. بهترین معماری Application Security از آن‌ها به‌عنوان دو لایه مکمل استفاده می‌کند: SAST برای پیدا کردن ضعف‌ها در کد و مراحل اولیه توسعه، و DAST برای ارزیابی رفتار امنیتی نرم‌افزار واقعی در Runtime.

هرچه این کنترل‌ها زودتر و منظم‌تر وارد SDLC شوند، امنیت از یک تست نهایی و مقطعی به بخشی از فرایند واقعی توسعه تبدیل می‌شود؛ دقیقاً همان تغییری که DevSecOps به‌دنبال آن است.