یک اسکن شبانه ۱۲هزار Finding میسازد؛ ۳۰۰ مورد «Critical» هستند. تیم توسعه Scan را پرنویز میداند، تیم امنیت روی SLA فوری تأکید میکند و هیچکس نمیداند کدام مورد واقعاً به دارایی اینترنتیِ حساس میرسد. مشکل کمبود ابزار نیست؛ خروجی Tool به Evidence، Context، Owner و تصمیم تبدیل نشده است.
ابزارهای تست امنیت از SAST و DAST تا SCA، Secret scanning، IaC، Container و Network scanner، بخش مهم یک برنامهٔ AppSec هستند؛ اما هیچکدام امنیت را تضمین یا Penetration test و تحلیل منطق کسبوکار را حذف نمیکنند. این راهنما دستهبندی درست، زمان اجرا، محدودیت، انتخاب، Scan ایمن، Triage، اولویتبندی، Retest و گزارش را با یک مثال عملی توضیح میدهد.
برای طراحی Threat model، سطحهای تست و مرز Penetration/Security testing، ابتدا راهنمای جامع تست امنیت نرمافزار را ببینید؛ این مقاله روی Toolchain و عملیات Finding تمرکز دارد.
اصل ایمنی: اسکن فعال، Fuzzing یا Probe فقط روی دارایی و محدودهای انجام شود که مجوز صریح دارید. برای Production باید Rule of Engagement، Rate/Window، دادهٔ مجاز، Stop condition، Incident contact و Recovery plan از پیش تصویب شود. اگر مجوز یا مرز روشن نیست، اسکن را شروع نکنید.
خلاصهٔ اجرایی: هر ابزار چه سوالی را پاسخ میدهد؟
| دسته | ورودی/دید | سوال اصلی | محدودیت مهم |
|---|---|---|---|
| SAST | Source/bytecode/binary؛ بدون اجرای هدف | آیا الگوی کد و Data flow مشکوک است؟ | Runtime/config/business context را کامل نمیبیند |
| SCA/SBOM | Manifest، lockfile، artifact | چه Componentی داریم و چه Risk شناختهشدهای دارد؟ | Presence الزاماً Reachability/Exploitability نیست |
| Secret scanning | Repo، history، image، artifact | Credential/Token احتمالی نشت کرده؟ | Regex/entropy خطا دارد؛ Rotation مستقل لازم است |
| IaC/Cloud config | Terraform/Kubernetes/Cloud config | Misconfiguration یا policy violation چیست؟ | State واقعی ممکن است Drift داشته باشد |
| Container/image | Package، OS layer، config | Component/setting آسیبپذیر چیست؟ | Runtime exposure و exploit path را کامل ثابت نمیکند |
| DAST/API scanner | سیستم در حال اجرا؛ بیرون به داخل | کدام رفتار قابلمشاهده شواهد ضعف دارد؟ | فقط مسیر، Role و State پیمودهشده را میبیند |
| IAST | Agent داخل Runtime + ترافیک تست | کدام مسیر اجرا و Data flow آسیبپذیر دیده شد؟ | Coverage وابسته به Test traffic و پشتیبانی Agent است |
| Network/vulnerability scan | Host، port، service، version/config | کدام دارایی/سرویس Exposure یا CVE محتمل دارد؟ | Banner/version و کنترل جبرانی میتوانند نتیجه را تغییر دهند |
| Manual review/pentest | Context، Threat، چند منبع Evidence | آیا منطق، زنجیره حمله یا کنترل قابل دورزدن است؟ | زمانبر، Skill-dependent و Snapshot زمانی است |
مرز «اسکنر» و «تحلیلگر» یک استاندارد دقیق بازار نیست. DAST غالباً Web scanner نامیده میشود؛ SAST یک تحلیلگر است؛ یک Platform میتواند چند Technique را ترکیب کند. ابزار را با ورودی، Technique، Surface، Output و Limit مقایسه کنید، نه واژهٔ تبلیغاتی.
ابزار Finding میسازد، نه حکم قطعی
یک Finding باید از این Stateها عبور کند:
- Detected: Rule یا Probe نشانهای ساخته است.
- Normalized/Deduplicated: Tool/Rule/Location/Component/Version یکسان همبسته شدهاند.
- Validated: Evidence، Scope و Context بررسی شده است.
- Risk-rated: Exposure، Asset impact، Exploit evidence و Control لحاظ شدهاند.
- Assigned: Owner، اقدام و Deadline دارد.
- Fixed/Mitigated/Accepted: تغییر یا تصمیم Risk ثبت شده است.
- Retested: رفع و نبود Regression با Evidence تأیید شده است.
- Closed/Reopened: Outcome و نسخه قابلردیابی است.
False positive یعنی Tool دربارهٔ شرط مورد ادعا اشتباه کرده؛ «در Priority ما نیست» False positive نیست. همچنین True positive لزوماً Risk بالا نیست. این واژگان را در Workflow جدا نگه دارید.
Coverage را از Requirement امنیتی آغاز کنید
فهرست OWASP Top ۱۰ یا تعداد Ruleهای ابزار، Coverage کامل نیست. OWASP ASVS 5.0 Requirementهای نسخهدار برای Verification کنترلهای فنی Web فراهم میکند. Scope محصول میتواند Requirementهای ASVS، Threat model، Policy سازمانی، Abuse case و Incidentهای قبلی را به Test technique و Evidence نگاشت کند.
| Requirement/Risk | Technique پیشنهادی | Evidence تکمیلی |
|---|---|---|
| ورودی آلوده به Sink حساس نرسد | SAST + code review + DAST هدفمند | Data flow، Test و Fix diff |
| Dependency شناختهشده مدیریت شود | SCA/SBOM | Version، reachability، KEV/exploit، mitigation |
| مجوز Tenant شکسته نشود | API/DAST role matrix + manual | دو Tenant ایزوله و Expected policy |
| Secret وارد Artifact نشود | Pre-commit/CI secret scan | Rotation/revocation و history cleanup |
| Storage عمومی نباشد | IaC policy + cloud state review | Runtime config و access test مجاز |
| سرویس غیرضروری Exposure نداشته باشد | Asset/network scan | Owner، CMDB، firewall path و exception |
OWASP Web Security Testing Guide نیز یک روش متوازن از Threat modeling، Review، Source analysis، Penetration testing و Test scenario ارائه میکند. Scanner بهتنهایی تمام این روشها را اجرا نمیکند.
SAST: تحلیل ایستا چه میبیند و چه نمیبیند؟
SAST کد منبع، Bytecode یا Binary را بدون اجرای کامل هدف بررسی میکند. Rule ساده ممکن است Pattern ناامن را پیدا کند؛ تحلیل پیشرفتهتر AST، Control flow و Taint/Data flow را دنبال میکند.
برای چه چیزهایی مفید است؟
- Source→sanitizer→sinkهای مشکوک؛
- API ناامن یا الگوریتم رمزنگاری نامناسب؛
- خطای Validation/Encoding و Path handling؛
- Hardcoded credential یا ضعفهای خاص زبان؛
- Ruleهای سازمانی در PR/IDE؛
- Location و Fix guidance نزدیک به Developer.
محدودیت
- همهٔ زبان، Meta-programming، Generated code یا Frameworkها را یکسان نمیفهمد.
- Configuration، deployment و runtime identity ممکن است بیرون دید باشد.
- Data flow بین Service/Queue/Template میتواند قطع شود.
- Path نظری شاید در Runtime قابلدسترسی نباشد؛ برعکس Rule ناکافی شاید Defect واقعی را جا بیندازد.
- Scan شدن ۱۰۰٪ فایلها به معنی پوشش ۱۰۰٪ Weaknessها نیست.
SAST با تست استاتیک و Review انسانی مکمل است. Tool Pattern را سریع مییابد؛ Reviewer Intent، architecture و business rule را بهتر میفهمد.
Gate مناسب
بهجای «هر Finding = Fail»، Baseline و Policy داشته باشید: Finding بحرانی جدید در کد تغییرکرده، Confidence کافی، Rule مصوب و Owner. Debt قدیمی باید Backlog/SLA جدا داشته باشد تا Developer برای Noise تاریخی کل Gate را خاموش نکند.
SCA، SBOM و Risk وابستگیها
Software Composition Analysis Manifest، Lockfile، Package manager، Binary یا Container layer را برای Component/version/license و Vulnerability شناختهشده تحلیل میکند. SBOM Inventory استانداردشدهای از Componentهاست؛ خود SBOM Scanner یا تضمین صحت نیست.
Finding وابستگی را با این سوالها Triage کنید
- Version دقیق و Package واقعی در Artifact نهایی وجود دارد؟
- Dependency مستقیم است یا Transitive؟
- کد آسیبپذیر Reachable یا Feature مربوط فعال است؟
- Runtime/OS/config شرط Exploit را فراهم میکند؟
- دارایی Internet-facing یا High-value است؟
- CVE در CISA Known Exploited Vulnerabilities Catalog یا دارای Evidence فعال Exploit است؟
- Fix/upgrade موجود و با Compatibility چه Trade-offی دارد؟
- Compensating control چه چیزی را واقعاً مسدود میکند؟
NIST SSDF 1.1 Practiceهای توسعه امن را در SDLC ادغام میکند تا Vulnerability کمتر تولید، اثر موارد کشفنشده محدود و علتهای ریشهای اصلاح شوند. SCA فقط یک کنترل در این برنامه است؛ Policy خرید Component، provenance، Build integrity و Response نیز لازماند.
License و Security را یکی نکنید
یک Component میتواند از نظر CVE پاک و از نظر License/Policy نامجاز باشد؛ یا برعکس. Workflow، Owner و Evidence حقوقی/امنیتی را جدا اما قابلهمبستگی نگه دارید.
Secret scanning: کشف پایان کار نیست
Secret scanner با Pattern، Entropy و Provider-specific validation به دنبال Token، Key، password و credential میگردد. Source branch تنها Scope نیست؛ Git history، PR diff، CI log، container layer، package، backup و Artifact نیز ممکن است Secret داشته باشند.
اگر Secret معتبر پیدا شد:
- Incident/credential owner را طبق Runbook درگیر کنید.
- Secret را Revoke/Rotate کنید؛ حذف خط از آخرین Commit کافی نیست.
- Scope استفاده، Log و دسترسی احتمالی را بررسی کنید.
- History/Artifact را طبق Policy و بدون ازبینبردن Evidence لازم پاکسازی کنید.
- مصرفکننده را به Vault/short-lived identity منتقل کنید.
- Preventive control را در Pre-commit/PR/CI اضافه کنید.
برای Test از Credential مصنوعی/کمدسترسی و Namespace جدا استفاده کنید. اصول Data minimization و Masking در راهنمای مدیریت داده تست مکمل این کنترل است.
IaC، Cloud، Container و Kubernetes scanning
این ابزارها Policy و Misconfiguration را در Template یا State بررسی میکنند:
- Public exposure، Security group و ingress بیشازحد؛
- IAM/Role با مجوز گسترده؛
- Encryption، logging، backup یا retention غیرفعال؛
- Container با user/root، capability، writable filesystem یا package پرریسک؛
- Kubernetes RBAC، secret mount، network policy و resource/security context؛
- Image base و packageهای OS/application؛
- Terraform/Kubernetes manifest در برابر Policy سازمان.
Template سبز Runtime را تضمین نمیکند: Drift، console change، admission mutation و default provider ممکن است State دیگری بسازد. Pre-deploy IaC scan را با post-deploy cloud/config inventory و Test مجاز کنترل ترکیب کنید.
DAST و API scanner: سیستم در حال اجرا را میبیند
DAST مانند Client بیرونی با Application/API تعامل، ورودی و Response را تحلیل میکند. برای Authentication/session، بعضی Injectionها، Header/config و رفتار Runtime مفید است؛ اما Coverage آن به Crawl، API definition، Role، State، داده و Route بستگی دارد.
Crawl هوشمند کافی نیست
- API spec و authenticated context هر Role را بدهید.
- Seed URL/route و state transitionهای مهم را تعریف کنید.
- CSRF/OTP/SSO و anti-automation را با روش مجاز تنظیم کنید.
- دو Tenant و Resource مالک/غیرمالک برای Authorization test بسازید.
- Out-of-band interaction را فقط با Endpoint کنترلشده به کار ببرید.
- GraphQL/gRPC/WebSocket را فقط اگر Tool واقعاً پشتیبانی و PoC شده پوششخورده بنامید.
DAST نمیتواند همهٔ نقصهای Business logic را از روی Crawl حدس بزند. قیمت منفی، دوبارمصرفشدن Coupon، ترتیب Approval یا شکستن جداسازی Tenant به Test model و دانش دامنه نیاز دارد. راهنمای OWASP Top ۱۰:۲۰۲۵ و روش تست نشان میدهد هر Risk به Technique و Oracle خاص نیاز دارد.
IAST: دید Runtime وابسته به ترافیک
IAST Agent/Instrumentation را داخل Runtime قرار میدهد و هنگام اجرای Test، مسیر کد و Data flow را مشاهده میکند. Location دقیقتر میتواند Triage را آسان کند، اما عبارت «مثبت کاذب بسیار کم» تضمین عمومی نیست.
- بدون Test traffic، مسیر اجرا نشده Evidence نمیسازد.
- Agent باید Language/Framework/runtime version را پشتیبانی کند.
- Performance overhead و دادهٔ جمعآوریشده باید اندازهگیری شود.
- استفاده در Production نیازمند Risk/Privacy/Change approval جداست.
- Async/microservice boundary ممکن است Trace را قطع کند.
- نتیجه همچنان Validation و Owner میخواهد.
در معماری توزیعشده، Agent یا Scanner ممکن است Trace را در مرز HTTP، Queue و Event از دست بدهد؛ راهنمای تست میکروسرویسها برای Contract، Trace correlation و Failureهای میانسرویسی مکمل این تحلیل است.
Asset discovery، Network scan و Vulnerability management
Discovery tool میزبان، Port و Service را پیدا میکند؛ Vulnerability scanner آن Evidence را با Plugin/CVE/config check ترکیب میکند؛ Vulnerability management علاوه بر Scan، Inventory، Ownership، SLA و Lifecycle را مدیریت میکند. این سه را یکی ندانید.
Credentialed در برابر uncredentialed
Uncredentialed scan دید مهاجم بیرونی را تقریب میزند اما Patch/config داخلی را کامل نمیبیند. Credentialed scan Inventory دقیقتری میدهد، ولی Credential پرقدرت و Agent/Account خودش Risk است. Least privilege، Vault، rotation، source allowlist و audit لازماند.
Banner و Version فقط قرینهاند
Backport Patch، Proxy، custom build یا banner masking میتواند تطابق Version→CVE را غلط کند. Package inventory، vendor advisory، build provenance و safe validation را کنار نتیجه بگذارید.
Fuzzing و Penetration testing کجا قرار میگیرند؟
Fuzzer ورودیهای فراوان یا ساختاریافته میسازد تا Crash، hang، memory error یا invariant violation پیدا کند. Coverage-guided fuzzing با DAST عمومی یکسان نیست و Harness، Corpus، Sanitizer و Crash triage میخواهد.
Penetration test یک Tool category نیست؛ Engagement هدفمند با Scope و Rule of Engagement است که میتواند از Scanner، Review، Exploit validation کنترلشده و تحلیل انسانی استفاده کند. Scanner report بدون تحلیل منطق، زنجیره حمله و Impact، Penetration test کامل نیست.
Scan ایمن: Rule of Engagement اجباری
| فیلد | پرسش |
|---|---|
| Authority | چه مالک/قراردادی چه فعالیتی را مجاز کرده؟ |
| Scope | Domain/IP/API/account/role و Exclusion دقیق چیست؟ |
| Environment | Staging یا Production؛ Clone/backup/recovery چیست؟ |
| Technique | Passive، active، fuzz، credentialed، destructive plugin؟ |
| Window/Rate | زمان، concurrency، request rate و resource budget؟ |
| Data | چه Payload/Account/PII مجاز یا ممنوع است؟ |
| Identity | Source IP، User-Agent، test tenant و credential؟ |
| Monitoring | چه Metric/Alert/Log برای اثر Scan دیده میشود؟ |
| Stop | چه Error/Latency/data effect فوراً Scan را متوقف میکند؟ |
| Contacts | Operator، system owner، SOC/SRE و escalation؟ |
| Cleanup | Record، account، file، queue و notification چگونه پاک میشوند؟ |
| Evidence | Artifact کجا، تا چه زمان و با چه Redaction ذخیره میشود؟ |
روی Production از Payload مخرب یا تست تغییردهندهٔ State صرفاً برای «اطمینان» استفاده نکنید. ابتدا Passive/safe mode، محیط مشابه، synthetic tenant و rate پایین را ارزیابی کنید. هر ابزار Definition متفاوتی از Safe دارد؛ Plugin و نسخه را بررسی کنید.
Pipeline لایهای بدون فلجکردن Developer
| Lane | Signal | Gate نمونه |
|---|---|---|
| IDE/pre-commit | Rule سریع SAST/secret | Feedback آموزشی؛ Credential واقعی Stop |
| PR | Diff SAST، SCA، IaC، secret | Finding جدید با policy/confidence مصوب |
| Build | SBOM، image/package scan، provenance | Artifact/Component gate |
| Integration | IAST/fuzz/API security test | Riskهای critical flow |
| Staging | Authenticated DAST و configuration | Release policy + verified finding |
| Scheduled | Full SAST/SCA/DAST/asset scan | Backlog با Owner/SLA؛ release link در صورت Risk |
| Production-safe | Passive/config/credentialed مجاز | Runbook، rate/stop و incident path |
Fast lane باید سریع و قابلاعتماد باشد؛ Scan کامل را میتوان در Lane جدا اجرا کرد، اما نتیجهٔ پرخطر نباید بیمالک بماند. طراحی Gate، Retry و Failure ownership را با Continuous Testing در CI/CD و انتخاب Candidateهای اتوماسیون را با استراتژی اتوماسیون تست هماهنگ کنید.
Triage و اولویتبندی: CVSS خام کافی نیست
CVSS 4.0 گروههای Base، Threat، Environmental و Supplemental دارد. Base severity ویژگی ذاتی/بدترینحالت معقول را خلاصه میکند؛ Risk اختصاصی سازمان نیست. Score و Vector/version را با هم ذخیره کنید و Context را اضافه کنید.
فاکتورهای Queue
- اعتبار Finding و Confidence/validation؛
- Asset owner، داده و Business criticality؛
- Internet/external exposure و network path؛
- Reachability و runtime/config شرط؛
- Exploit evidence، CISA KEV و Threat intelligence معتبر؛
- Privilege و blast radius؛
- Compensating control و قابلیت Detection/response؛
- Fix/patch availability و Change risk؛
- Age، recurrence و deadline قانونی/قراردادی؛
- وابستگی به Finding دیگر و chain potential.
| وضعیت | Severity فنی | Context | اقدام نمونه |
|---|---|---|---|
| CVE در Service اینترنتی، KEV، مسیر فعال | High | دارایی مالی، بدون کنترل کافی | فوری/Incident-style با mitigation |
| همان CVE در Build tool غیرقابلدسترسی Runtime | High | Reachability پایین؛ supply-chain review لازم | زمانبندی بر اساس Evidence، نه Ignore |
| Broken authorization بدون CVE | بدون CVSS vendor | Cross-tenant data access | Risk بالا با تست/مالک فوری |
| Header کماثر پشت کنترل جبرانی | Low/Medium | Exposure محدود | Backlog یا Accept با expiry |
فرمول واحد جهانی نسازید. Policy اولویت باید Version، Weight، استثنا و Owner داشته باشد و با Incident/Threat تغییر کند.
Deduplication، Suppression و Risk acceptance
Deduplicate
یک Root cause ممکن است در SAST، DAST و IAST چند Finding بسازد. شناسهٔ مشترک بر اساس Asset، Component، weakness/CWE، location/route، version و evidence نگه دارید؛ Sourceها را حذف نکنید چون Confidence را بالا میبرند.
Suppress
Suppression فقط با Reason، Scope، Approver، Evidence و Expiry:
- False positive تأییدشده؛
- Not applicable با شرط مستند؛
- Duplicate به Finding اصلی؛
- Accepted risk با Owner و Review date؛
- Compensating control با Test evidence.
Suppress سراسری Rule برای خاموشکردن Noise میتواند Finding واقعی آینده را پنهان کند. Rule tuning را با نمونهٔ True/False و Change review انجام دهید.
مثال عملی: سرویس پرداخت فروشگاه ایرانی
Scope
- Repository سرویس پرداخت و Container image؛
- API در Staging با دو Tenant مصنوعی؛
- Terraform/Kubernetes همان محیط؛
- دامنه/IP مشخص، خارج از Production؛
- Callback Sandbox درگاه؛ بدون کارت/دادهٔ واقعی.
Signalهای چند ابزار
| منبع | Finding | Validation/Context |
|---|---|---|
| SAST | ورودی به Query string-building میرسد | مسیر با repository واقعی و parameterization بررسی شود |
| SCA | Library با CVE High | Artifact/version/reachability/KEV و fix سازگاری |
| Secret | کلید شبیه Sandbox token در history | Provider/owner اعتبار را امن بررسی و Rotate کند |
| IaC | Service account مجوز گسترده | State واقعی و use case؛ least privilege diff |
| DAST/API | Tenant B به resource ID متعلق به A پاسخ میگیرد | دو Account مصنوعی؛ Expected policy و audit evidence |
| Container | Package OS قدیمی | Base image provenance و runtime exposure |
| Network | Admin port از Runner network قابلدسترسی | Exposure policy، firewall path و owner |
تصمیم
Cross-tenant authorization حتی بدون CVE یا Score خودکار، بهدلیل دسترسی داده Risk بالایی دارد و Release را متوقف میکند. CVE Library تنها پس از تأیید Artifact/Reachability/Exploit evidence وارد Priority میشود. Secret معتبر فوراً Rotation/incident path میگیرد. IAM و Admin port با Owner زیرساخت و Control test اصلاح میشوند.
Retest
- Fix دقیق با همان دو Tenant و Negative control؛
- Regression روی Roleهای مجاز؛
- SAST/Data-flow و Unit/integration test جدید؛
- Artifact/SBOM تازه و نبود Version قدیمی؛
- Secret revocation و Scan history/artifact؛
- IaC plan + state verification؛
- DAST محدود همان Route، نه Full destructive rescan؛
- Evidence به Build، environment و Finding اصلی وصل شود.
انتخاب ابزار امنیت با PoC، نه جدول Feature
| معیار | پرسش PoC |
|---|---|
| Coverage | زبان/framework/API/auth/asset واقعی را میبیند؟ |
| Precision/recall نمونه | روی Benchmark داخلی با Truth set چه پیدا/جا میاندازد؟ |
| Evidence | Rule، trace/location، request/response امن و remediation context دارد؟ |
| Triage | Developer در چند دقیقه Valid/False/Unknown را تشخیص میدهد؟ |
| Workflow | Dedupe، owner، suppression expiry، retest و API/export دارد؟ |
| CI | Incremental/full، duration، exit code و policy-as-code؟ |
| Scale | Repo/asset/tenant و scan window واقعی را تحمل میکند؟ |
| Safety | Rate، plugin، safe mode، scope و stop قابلکنترلاند؟ |
| Security | Source/Artifact/Secret کجا میروند؟ least privilege و audit؟ |
| Operations | Rule feed، upgrade، offline/proxy، backup و owner؟ |
| Economics | License + infra + triage + tuning + training + exit؟ |
Truth set داخلی
چند نمونهٔ تأییدشده از Weaknessهای رایج خود، نمونهٔ Safe و Fix شده بسازید. Candidate باید True case و Negative control را اسکن کند. فقط Demo vendor یا تعداد Rule مقایسهٔ معتبری نیست. Truth set نباید Exploit خطرناک یا Secret واقعی داشته باشد.
ابزارهای نمونه، نه رتبهبندی
- SAST: Engineهای language-specific، CodeQL/Semgrep/Sonar-class و Vendor platform؛
- DAST: OWASP ZAP، Burp-class و Scannerهای تجاری؛
- SCA/SBOM/Image: Dependency-checking و Trivy/Grype/Syft-class؛
- Secret: Gitleaks/TruffleHog-class و Provider scanning؛
- IaC: Checkov/tfsec/Trivy-class و Cloud policy platform؛
- Network/VM: Nmap برای Discovery و Greenbone/Tenable/Qualys-class برای Vulnerability management؛
- IAST: Agentهای تجاری متناسب Runtime.
این نامها صرفاً نمونهٔ خانوادهاند. Capability، Maintainer، License، Rule feed و دسترسی سرویس تغییر میکنند؛ نسخه و قرارداد روز را از منبع رسمی Verify کنید.
ملاحظات تیمهای ایرانی
- Package/rule/CVE feed و Container database از شبکه و CI داخل ایران واقعاً Update میشوند؟
- آیا SaaS بهدلیل موقعیت، Account یا پرداخت قابلاستفاده و مجاز است؟
- Source code، SBOM، IP، Screenshot و Finding به خارج از سازمان ارسال میشوند؟
- Self-hosted/offline mirror برای Rule/feed و signature چگونه امن Update میشود؟
- License، تمدید، ارز و پشتیبانی رسمی قابل اتکاست؟
- متن/URL/نام فارسی و Unicode در Rule/Report خراب نمیشود؟
- Sandbox درگاه، OTP/SMS و IP allowlist برای Scanner هماهنگ است؟
- دادهٔ واقعی مشتری در Scan account، request یا artifact استفاده نشود.
- زمان و تقویم گزارش SLA برای تیمهای داخل/خارج صریح باشد.
دورزدن کنترل سرویس یا اجرای Scanner ناشناخته از Source غیرمعتبر راهحل نیست؛ Candidate نامطمئن باید رد یا با معماری مجاز جایگزین شود.
قالب Finding امنیتی قابلکپی
ID / source / rule / version: …
Asset / owner / environment / build: …
Weakness/CWE/CVE: …
Title: رفتار + شرط + اثر
Evidence: Sanitized path/request/response/trace/location …
Expected control/requirement: ASVS/policy/threat …
Validation status/confidence: Detected/validated/unknown …
Exposure/reachability: …
CVSS version/vector/score: …
Threat/KEV/exploit evidence: …
Business/asset impact: …
Compensating controls: …
Recommended options: fix/mitigate/accept …
Owner/SLA/approver: …
Retest steps/evidence: …
Suppression/acceptance expiry: …
گزارش نباید Secret، Payload خطرناک کامل یا PII را در Ticket عمومی قرار دهد. اصول Expected/Actual، Environment و Evidence در قالب گزارش باگ حرفهای قابلاستفاده است، اما Workflow امنیتی به Disclosure، Severity context و دسترسی محدود هم نیاز دارد.
متریکهای مفید برنامه ابزارهای امنیت
| متریک | پرسش تصمیم | ضدالگو |
|---|---|---|
| Asset/repo coverage | کدام Scope و Owner هنوز بدون Signal است؟ | درصد بدون کیفیت Inventory |
| Validated finding rate | کدام Rule/Tool نیاز به tuning دارد؟ | کمبود Finding را موفقیت دانستن |
| Time to triage | Signal چهقدر بیمالک میماند؟ | SLA یکسان برای همه Contextها |
| Time to remediate by risk | Risk پراثر کجا گیر میکند؟ | Average که Tail را پنهان کند |
| Reopen/recurrence | Fix یا root-cause control ناقص است؟ | بستن Ticket بدون Retest |
| Suppression aging | استثناهای منقضی چه شدند؟ | Suppress دائمی بدون Owner |
| Pipeline signal time | Feedback در زمان تصمیم میرسد؟ | Scan سریع اما پرنویز |
| KEV/exposed backlog | Exploit evidence روی دارایی حساس؟ | CVSS خام بدون Context |
«تعداد Vulnerability کشفشده» بهتنهایی KPI کیفیت نیست؛ Tool پرنویز یا Scope بزرگتر عدد را بالا میبرد. Denominator، Scope، Version و Decision را کنار Metric بنویسید.
برنامهٔ ۳۰روزه راهاندازی Toolchain امنیت
هفتهٔ اول: Scope و Requirement
- Asset/repo/service owner و Criticality را Inventory کنید.
- Threat/ASVS/policy را به Technique و Lane نگاشت کنید.
- Authority، Rule of Engagement و data boundary را تصویب کنید.
- Baseline Findingهای فعلی و Truth set امن بسازید.
هفتهٔ دوم: PoC
- حداکثر دو/سه Candidate هر Gap را روی Tech واقعی اجرا کنید.
- True/negative sample، CI، authentication و safe scan را بسنجید.
- زمان Run/Triage/Tuning و Data flow را ثبت کنید.
- دسترسی ایران، offline/proxy و Update feed را امتحان کنید.
هفتهٔ سوم: Workflow
- Normalization، dedupe، severity context و ownership را تعریف کنید.
- Suppression/acceptance با expiry و approval بسازید.
- Fast/full lane، failure routing و safe scheduled scan را فعال کنید.
- Finding template، Retest و Evidence retention را آموزش دهید.
هفتهٔ چهارم: Pilot و بازنگری
- یک سرویس پرریسک را End-to-end پوشش دهید.
- Findingها را تا Fix/Retest یا Risk acceptance واقعی دنبال کنید.
- Noise، missed truth، duration و developer experience را مرور کنید.
- Scale/Retune/Replace/Stop و بازبینی ۳۰/۶۰/۹۰روزه تعیین کنید.
اشتباههای رایج در ابزارهای تست امنیت
- Finding = Vulnerability قطعی: Validation و Context حذف میشود.
- Scanner report = Penetration test: منطق و chain انسانی پوشش ندارد.
- SAST = پوشش کامل: Scan فایل با Detection همه Weaknessها یکی میشود.
- IAST = بدون False positive: Agent/traffic/interpretation نادیده گرفته میشود.
- CVSS Base = Business risk: Exposure، KEV و Asset impact حذف میشوند.
- Severity = Priority: Threat و fix/control context دیده نمیشود.
- False positive = فعلاً مهم نیست: Risk واقعی اشتباه Suppress میشود.
- Full scan روی Production: Authorization، rate، data effect و stop وجود ندارد.
- یک Tool برای همهچیز: Gapها پشت Dashboard واحد پنهان میشوند.
- Gate همهٔ Debt قدیمی: Developer Tool را دور میزند.
- Retry/Rescan تا سبز: Flake و state تغییرکرده پنهان میشود.
- SBOM = امنیت Supply chain: provenance/policy/response فراموش میشود.
- Secret حذف شد = حل شد: Revocation و scope بررسی نمیشود.
- Suppression بیانقضا: Exception به blind spot دائمی تبدیل میشود.
- Tool SaaS بدون Data review: Source و Finding حساس خارج میرود.
چکلیست نهایی ابزارهای تست امنیت
- Asset، Owner، Criticality و Scope معلوم است.
- Requirement/Threat به Technique و Evidence نگاشت شده است.
- ابزار با ورودی/دید/Limit تعریف شده، نه نام بازاری.
- SAST، SCA، Secret، IaC/Container، DAST/API و Network gap بررسی شدهاند.
- Truth set و Negative control در PoC وجود دارد.
- Authority و Rule of Engagement پیش از Scan فعال ثبت شدهاند.
- Production scan دارای rate/window/stop/contact/recovery است.
- Findingها Normalized، Deduplicated و Validated میشوند.
- CVSS version/vector همراه Threat/Environmental context ذخیره است.
- KEV/exploit، reachability، exposure و asset impact در Priority میآیند.
- False positive، accepted risk و duplicate Stateهای جدا دارند.
- Suppression دارای Reason/Owner/Approver/Expiry است.
- هر Finding اقدام، SLA و Retest دارد.
- Secret/PII در Artifact و Ticket Redact میشود.
- CI fast/full lane و Failure owner روشن است.
- Rule/feed/version و Upgrade cadence مدیریت میشود.
- License، supply chain، SaaS data flow و دسترسی ایران Review شدهاند.
- Metric با Scope/Denominator/Decision تفسیر میشود.
سوالات متداول ابزارهای تست امنیت
SAST و DAST چه تفاوتی دارند؟
SAST کد/Bytecode/Binary را بدون اجرای کامل تحلیل میکند و Location/Data flow احتمالی میدهد؛ DAST از بیرون با سیستم در حال اجرا تعامل میکند و رفتار Runtime را میبیند. SAST config/Runtime و DAST مسیر پیمودهنشده/منطق پنهان را کامل نمیبیند؛ ترکیبشان با Review و تست دستی Coverage بهتری میدهد.
آیا Scanner آسیبپذیری همان Penetration test است؟
خیر. Scanner Signal خودکار دربارهٔ CVE، config یا رفتار میسازد. Penetration test Engagement مجاز و هدفمند با Scope، تحلیل انسانی، زنجیرهٔ حمله و Impact validation است. Scanner میتواند ابزار Pentest باشد، اما گزارش خام آن جای روش کامل را نمیگیرد.
چطور False positive ابزار امنیت را مدیریت کنیم؟
Evidence و Requirement را بررسی، Rule/Location/Version را بازتولید امن و نتیجه را با Reason ثبت کنید. Suppression باید Scope، Owner و Expiry داشته باشد. «فعلاً Priority ندارد» False positive نیست؛ آن را Risk-rated/accepted/deferred جدا نگه دارید.
آیا CVSS بالا یعنی باید همیشه اول Fix شود؟
CVSS شدت فنی را ساختار میدهد، نه Risk کامل سازمان. نسخه/vector، Threat و Environmental را همراه KEV/exploit، reachability، exposure، Criticality دارایی، کنترل جبرانی و Fix availability ببینید. نقص Authorization مهم ممکن است CVE/CVSS آماده نداشته باشد اما Priority بالایی داشته باشد.
آیا ابزار متنباز برای برنامه AppSec کافی است؟
متنباز یا تجاری بودن بهتنهایی کیفیت را تعیین نمیکند. Coverage Tech، precision/recall روی Truth set، Evidence، Rule feed، CI، safety، ownership، support، license و TCO را PoC کنید. هر Tool—رایگان یا پولی—به Triage، tuning، remediation و Retest انسانی نیاز دارد.
منابع و یادداشت بازبینی
چرخهٔ توسعه امن با NIST SSDF ۱.۱؛ Requirementهای Application با OWASP ASVS ۵.۰؛ روش Web با OWASP WSTG؛ اولویت Exploit واقعی با CISA KEV؛ و Severity با FIRST CVSS ۴.۰ تطبیق داده شده است. آخرین بازبینی محتوایی: ۱۵ مرداد ۱۴۰۵. Capability، Rule، CVE feed، License و سرویس ابزارها تغییر میکند؛ نسخه/قرارداد روز را از منبع رسمی بررسی و هر اسکن فعال را فقط با مجوز اجرا کنید.
جمعبندی: Toolchain امنیت خوب بیشترین Alert را تولید نمیکند؛ Signal درست را در زمان مناسب به Owner میرساند و تا Fix/Retest یا پذیرش Risk قابلردیابی نگه میدارد. Requirement را قبل از Scanner تعریف کنید، روشها را لایهای بچینید، Production را با Rule of Engagement محافظت کنید و CVSS را با Context واقعی دارایی و تهدید کامل کنید.
