تست امنیت

عملیاتی‌سازی ابزارهای AppSec؛ از Coverage تا Triage و Retest

انتشار در تاریخ توسط محمد عسکری

پایپ‌لاین یک فین‌تک ایرانی ۱۶ هشدار امنیتی تولید کرده و داشبورد سبز است؛ بعد از Dedup فقط ۱۰ Case یکتا می‌ماند. تیم هشت عیب واقعی را پیدا کرده، اما یک نقص بحرانی دسترسی بین Tenantها اصلاً در ابزارها دیده نشده است. سبد ابزار AppSec با تعداد Scanner یا Alert سنجیده نمی‌شود؛ با پوشش تهدید، نرخ کشف عیب واقعی، زمان بستن حلقه و شواهد Fix سنجیده می‌شود.

این راهنما دسته‌بندی SAST/DAST/SCA را تکرار نمی‌کند. از Asset و Security requirement شروع می‌کند، یک Coverage contract می‌سازد، ابزارها را روی Truth set محلی می‌سنجد، Findingهای چندمنبعی را Normalize/Dedupe/Triage می‌کند، اولویت و Gate/Exception را کنترل و Fix را با Retest مستقل تأیید می‌کند.

پاسخ کوتاه: ابزار AppSec را چگونه عملیاتی کنیم؟

برای هر Application/Artifact، Owner، Criticality، Data، Trust boundary و Threat را ثبت کنید؛ Requirementهای نسخه‌دار را به Test technique و Tool lane نگاشت کنید؛ با seeded true/false cases نرخ TP/FN/TN/FP را بسنجید؛ خروجی را با Run/Artifact/Rule/Location/Fingerprint نرمال و Dedup کنید؛ سپس Context دارایی، Reachability، Exposure، Exploitation evidence و Impact را برای تصمیم اضافه کنید. Gate فقط روی Finding معتبر، جدید و policy-relevant باشد و Exception بدون Owner/Expiry/Compensating control ممنوع شود.

  • Coverage: چه Requirement/Threat/Assetی را چه روشی می‌سنجد؟
  • Detection: چه عیب واقعی را پیدا یا جا می‌اندازد؟
  • Decision: Finding چگونه Validate، Prioritize و Assign می‌شود؟
  • Closure: Fix، Retest، Regression و Residual risk چگونه اثبات می‌شوند؟
  • Health: Scanner، Credential، Corpus، Rule و Integration سالم‌اند؟

مرز این مقاله با راهنماهای دیگر

راهنمای ابزارهای تست امنیت خانواده‌های SAST، DAST، IAST، SCA/SBOM، Secret، IaC، Container، Cloud، Network و Fuzzing را با محدودیت‌هایشان توضیح می‌دهد. این مقاله مرحله بعد را مالک است: چگونه چند lane را به یک برنامه عملیاتی با Coverage، Triage، SLA و Retest تبدیل کنیم.

تحلیل استاتیک کد برای QA Rule-to-decision و Quality Gate ویژه SAST/Linter را عمیق می‌کند؛ راهنمای تست امنیت نرم‌افزار نیز استراتژی کلی/RoE را پوشش می‌دهد. ۱۲۳۱ به مدیریت سبد AppSec و Finding flow میان همه این روش‌ها می‌پردازد.

Scanner با برنامهٔ امنیتی برابر نیست

ابزار یک Sensor است. Coverage آن به زبان، Framework، Build، config، authentication، crawl، test traffic، rule pack، version و data quality وابسته است. نبود Finding ممکن است معنای «امن» نداشته باشد؛ شاید Scanner اصلاً Build نشده، Login نکرده، Route را ندیده، Artifact اشتباه را اسکن کرده یا Rule لازم خاموش بوده است.

چهار نوع Evidence

  • Scan health: Scope و Artifact درست، Rule load، auth/crawl/build موفق؛
  • Finding evidence: Source/sink، request/response، component/version یا config path؛
  • Context evidence: Exposure، Reachability، data/privilege و compensating control؛
  • Closure evidence: Patch/config، regression، same-scope retest و deployment identity.

از Asset inventory شروع کنید

Application name برای Scope کافی نیست. Repository، service، API، web/mobile client، image، package، IaC، cloud account، environment و data store را با Owner و Artifact identity ثبت کنید. Shadow service یا Repository یتیم هیچ Scannerی را دریافت نمی‌کند.

فیلد نمونه کاربرد
Asset/Owner checkout-api / payments-team مسئول Fix/Exception
Criticality/Data Tier 1 / payment+PII Rigor/SLA
Artifact image digest + commit جلوگیری از اسکن نسخه اشتباه
Exposure internet/internal/admin Threat context
Tech Node/PostgreSQL/K8s Tool/Rule compatibility
Lifecycle active/EOL/migration Remediation/retirement plan

Threat model به Coverage contract تبدیل شود

لیست «SAST+DAST+SCA داریم» Coverage نیست. برای هر Trust boundary و abuse case، Requirement و روش اثبات بنویسید. نقص‌های authorization، race، workflow abuse، financial invariant و tenant isolation اغلب به Test هدفمند/Manual/Model-based نیاز دارند و با Scanner عمومی کامل نمی‌شوند.

برای ریسک‌های Web، مرور آسیب‌پذیری‌های رایج OWASP نقطه شروع Awareness است، نه Coverage contract؛ Requirement، Asset، Environment، Test method و Oracle همچنان باید صریح باشند.

Coverage matrix نمونه

Threat/Requirement Primary lane Complement Oracle
Injection prevention SAST/DAST Manual/API tests ASVS + source/runtime evidence
Object/Tenant authorization Targeted API tests Manual review Role×Action×Object matrix
Known vulnerable dependency SCA/SBOM Reachability/runtime inventory Artifact/version/affected-range
Secret exposure Secret scan History/artifact/log checks Canary + rotation evidence
Cloud public access IaC/CSPM Runtime config query Effective policy
Parser crash/state issue Fuzzing Sanitizer/property tests Crash/invariant
Refund workflow abuse Threat-led manual/automation Telemetry review Financial invariant

در lane فازینگ نیز صرف اجرای Engine کافی نیست؛ Harness، Corpus، Oracle، Crash triage و Repro باید سالم باشند. راهنمای عملی Fuzz Testing این زنجیره را از Harness تا مدیریت Crash باز می‌کند.

ASVS و WSTG را نسخه‌دار نگه دارید

OWASP ASVS 5.0.0 Requirementهای فنی امنیت وب را با شناسه نسخه‌دار ارائه می‌کند و برای Verification/Procurement قابل استفاده است. `v5.۰.۰-۱.۲.۵` از `۱.۲.۵` دقیق‌تر است؛ شناسه بدون Version در آینده مبهم می‌شود.

OWASP WSTG نیز توصیه می‌کند Scenario با Version ارجاع شود؛ Release وبی پایدار فعلی ۴.۲ است و Latest مسیر توسعه را نشان می‌دهد. ASVS می‌گوید چه Controlی لازم است؛ WSTG Techniqueهای تست وب را می‌دهد؛ Tool output به‌تنهایی هیچ‌کدام را کامل اثبات نمی‌کند.

Coverage contract قابل کپی

asset: checkout-api@sha256:...
requirement: ASVS v5.0.0-<id>
threat: tenant-A reads tenant-B order
environment: staging-prodlike-1405.05
primary_method: authorization_matrix_test
complements: DAST + code_review
oracle: expected deny + no side effect + audit event
owner: payments-security
frequency: PR + release
evidence: run-id / request-response digest / trace
known_limitations: admin paths excluded
exception: none

Safe execution و Rules of Engagement

Active scan، fuzzing و exploit validation می‌توانند داده/State/Availability را تغییر دهند. Target، time window، source IP، test identity، allowed techniques، rate/concurrency، synthetic data، prohibited actions، stop condition، monitoring، escalation، artifact handling و cleanup باید کتبی باشند.

  • Production فقط با authorization صریح و روش کم‌خطر؛
  • Payment/SMS/email/delete واقعی Block؛
  • Credential اختصاصی با نقش‌های نماینده و expiry؛
  • Egress و callback فقط به Observer کنترل‌شده؛
  • DoS/brute-force/destructive payload خارج Scope مگر مجوز ویژه؛
  • Kill switch مستقل و On-call حاضر؛
  • Data retention/redaction و disclosure path روشن.

PoC ابزار باید Truth set داشته باشد

OWASP Benchmark Caseهای True/False و scoring بر پایه TP/FN/TN/FP برای سنجش accuracy/coverage/speed ابزارهای AST ارائه می‌کند و برای انتشار نتیجه، version/config/reproducibility می‌خواهد. خود پروژه هشدار می‌دهد Caseها از برنامه واقعی ساده‌ترند؛ Benchmark عمومی را با Corpus محلی جایگزین نکنید، آن را مکمل نگه دارید.

Truth set محلی

برای Stack واقعی، چند Weakness نماینده را در Lab/branch کنترل‌شده Seed کنید و Negativeهای مشابه بسازید: query پارامتری/غیرپارامتری، authorization درست/غلط، reachable/unreachable dependency، active/revoked secret، private/public storage. Case باید ID، CWE/requirement، severity، artifact، expected detection، allowed lane و cleanup داشته باشد.

Confusion matrix

TP: عیب واقعی و گزارش درست
FN: عیب واقعی اما ابزار/سبد پیدا نکرد
TN: الگوی امن و گزارش‌نشده
FP: الگوی امن اما گزارش‌شده

Recall = TP / (TP + FN)
Precision = TP / (TP + FP)
FPR = FP / (FP + TN)

Accuracy در Dataset نامتوازن می‌تواند فریب دهد. معیار را به تفکیک CWE/Language/Framework/Severity/scan mode بدهید؛ Recall بحرانی Hard gate است و با Precision میانگین جبران نمی‌شود.

Scan health پیش از Finding count

هر Run باید Target/Artifact/Tool/engine/rule-pack/config/baseline identity و زمان شروع/پایان داشته باشد. Health checkها:

  • SAST: Build/parse coverage، file/language count، rule load و excluded paths؛
  • DAST: Authentication state، crawl/API operation coverage، request errors و rate؛
  • SCA: lockfile/image/runtime scope، package resolution، feed age و artifact digest؛
  • Secret: current/history/artifact scope و canary detection؛
  • IaC/Cloud: template revision، account/region و runtime drift؛
  • Fuzz: harness health، execs، corpus/coverage و crash pipeline.

اگر Login شکست خورده یا فقط ۲۰٪ Routeها Crawl شده‌اند، صفر Finding نتیجه معتبر نیست. Verdict Run باید `valid`, `degraded`, `invalid` یا `inconclusive` باشد و Gate روی Run نامعتبر سبز نشود.

Normalize بدون نابودکردن Evidence

هر Tool taxonomy و خروجی خودش را دارد. Canonical record باید مشترک باشد اما Raw finding، report digest و parser version را حفظ کند. تبدیل نباید Path، flow، request/response، package range یا confidence را حذف کند.

finding_id / source_finding_id
tool + engine/rule/config/version
run_id + artifact_digest + environment
rule_id + CWE/CVE + requirement_ref
location/flow/request/evidence_ref
title + description + confidence
scanner_severity + contextual_priority
state + owner + SLA + exception_expiry
first_seen / last_seen / fixed_in / retest_run

SARIF 2.1.0 استاندارد OASIS برای تبادل خروجی ابزارهای تحلیل ایستا است و می‌تواند Aggregate را ساده کند. SARIF Format همه DAST/SCA/Cloud/Pentest semantics یا Vulnerability Management workflow نیست؛ Extension/sidecar لازم را صریح کنید.

CWE، CVE و Rule ID یکی نیستند

CWE فهرست community-developed از نوع Weaknessهای نرم‌افزار/سخت‌افزار است؛ CVE یک Vulnerability مشخص در Product/Version است؛ Rule ID منطق یک Scanner است. نگاشت Rule→CWE می‌تواند یک‌به‌چند یا نادقیق باشد. Finding کد شما لزوماً CVE ندارد و یک CVE وابستگی لزوماً Reachable/Exposed نیست.

Dedup: Alert را با Vulnerability Case اشتباه نکنید

یک SQL injection ممکن است توسط SAST، DAST و Pentest گزارش شود؛ هدف حفظ Evidenceهای مکمل زیر یک Case است، نه حذف کور یکی. Fingerprint نمونه:

canonical_asset + weakness_family + normalized_location
+ source/sink_or_endpoint + security_boundary + affected_artifact_lineage

Title، line number یا CVE به‌تنهایی کلید پایدار نیست. Code refactor line را جابه‌جا می‌کند؛ یک CVE روی چند Component instance/Artifact اثر متفاوت دارد؛ و دو XSS در دو Trust boundary Caseهای جدا هستند.

Duplicate، Related و Chained را جدا کنید

  • Duplicate: همان Weakness/Asset/Root cause/Effect؛
  • Related: Root cause یا Fix مشترک اما instance متفاوت؛
  • Chained: چند Weakness برای Attack path ترکیب می‌شوند؛
  • Reintroduced: Fix شده و در Artifact جدید برگشته؛
  • Recurring pattern: موارد مستقل از یک practice gap.

Triage هشت‌مرحله‌ای

  1. Validate run: Scan health و scope معتبر است؟
  2. Reproduce/inspect: Evidence واقعی است یا parser/rule artifact؟
  3. Classify: TP، FP، Duplicate، Out-of-scope، Accepted risk یا Inconclusive؛
  4. Map: Asset/Artifact/Owner/Requirement/CWE/CVE؛
  5. Contextualize: Reachability، Exposure، privilege، data، controls؛
  6. Prioritize: impact، exploitation، urgency و fix path؛
  7. Act: fix/mitigate/rotate/isolate/retire/exception؛
  8. Verify: same-scope retest، regression و deployment evidence.

تیم Triage باید Reason code و Evidence بنویسد. تغییر State بدون توضیح، داده آموزشی/متریک آینده را آلوده می‌کند.

False Positive و False Negative را عملیاتی کنید

False Positive

Finding ادعا دارد Weakness وجود دارد اما Evidence/Context نشان می‌دهد وجود ندارد. «فعلاً قابل exploit نیست» همیشه FP نیست؛ ممکن است True weakness با کنترل جبرانی یا Accepted risk باشد. FP rule tuning باید expiry/retest و اثر بر FN داشته باشد.

False Negative

Truth set، incident، manual test یا ابزار مکمل عیبی را پیدا می‌کند که lane مورد انتظار جا انداخته است. Root cause را در Scope، parser/build، rule، data-flow depth، crawl/auth، framework support، config، baseline یا ذات روش پیدا کنید. FN مهم‌تر از Alert silence است.

Inconclusive

وقتی Source/Runtime/Evidence یا Permission کافی ندارید، به زور TP/FP نسازید. Owner، missing evidence، deadline و next action ثبت کنید؛ Inconclusive منقضی‌نشده می‌تواند Gate را Review کند.

Priority از Severity بزرگ‌تر است

CVSS 4.0 ویژگی‌ها و Severity آسیب‌پذیری را با گروه‌های Base، Threat، Environmental و Supplemental منتقل می‌کند؛ Base score به‌تنهایی Risk سازمان نیست. Scanner severity را بدون Vector/version نپذیرید.

CISA KEV فهرست زنده Vulnerabilityهای دارای شواهد exploit در دنیای واقعی است و CISA آن را یک ورودی اولویت‌بندی می‌داند. KEV نبودن به معنای امن یا غیرقابل‌استفاده‌بودن نیست؛ Findingهای بدون CVE/Business logic اصلاً در KEV ظاهر نمی‌شوند.

EPSS احتمال مشاهده exploit یک CVE در ۳۰ روز آینده را برآورد می‌کند؛ خود FIRST تأکید می‌کند EPSS Risk score کامل نیست و Context/Impact/Control را ندارد. تاریخ و نسخه مدل را همراه Score نگه دارید.

Context card

بعد پرسش
Asset/Exposure Internet-facing؟ Admin؟ reachable؟
Impact چه Data/Privilege/financial effect؟
Exploit KEV/Threat intel/repro/EPSS تاریخ‌دار؟
Control Compensating control واقعاً تست شده؟
Preconditions Auth/role/user action/config؟
Blast radius Tenant/account/fleet/region؟
Fix/Exposure window Patch/mitigation/redeploy چقدر طول می‌کشد؟

Dependency finding: Presence با Exploitability فرق دارد

برای CVE وابستگی، subject artifact، package identity، exact version/affected range، dependency path، runtime deployment، vulnerable function reachability، config/exposure و compensating control را بررسی کنید. گزارش «package در lockfile است» Presence evidence است، نه Impact نهایی.

کیفیت SBOM، VEX، KEV/EPSS و artifact binding در راهنمای SBOM و پاسخ به آسیب‌پذیری عمیق‌تر پوشش داده شده است.

Secret finding یک Ticket عادی نیست

Secret واقعی را ابتدا Revoke/Rotate و Blast radius را بررسی کنید؛ بعد تاریخچه، artifact/cache/log/mirror و root cause را پاک/کنترل کنید. حذف String از آخرین Commit کافی نیست. Scanner report نباید خود Secret را در Ticket/Chat تکرار کند.

Cloud/IaC: Intended و Effective state

Template امن ممکن است در Runtime drift کرده باشد و Runtime امن ممکن است از Template ناامن دوباره Deploy شود. Finding را با Account/Region/Resource/Policy revision و effective access پیوند دهید. Fix باید هر دو منبع Drift و State جاری را ببندد.

Business logic lane ضروری است

Scanner عمومی معمولاً نمی‌داند Refund بیش از اصل پرداخت، Coupon loop، duplicate callback یا Cross-tenant approval خلاف سیاست است. Threat-led Test، State model، invariant، role matrix و تست اکتشافی/Manual complement لازم است. Automation را برای Replay این Contract بسازید، نه برای تولید Alert بیشتر.

آزمایش قطعی سبد AppSec

یک برنامه مستقل Node.js ۲۴.۱۸.۰ روی ده Case ساختگی اجرا شد؛ چهار Case بحرانی و شش High بودند. Baseline شامل SAST/DAST/SCA/Secret/IaC بود. سه Finding از lane دستی authorization/workflow اضافه شد. هیچ ابزار یا Vendor واقعی Benchmark نشده است.

baseline raw_alerts=16 unique_cases=10 duplicates=6 tp=8 fp=2 fn=2 critical=3/4 recall=80.0% precision=80.0% gate=fail(critical_recall)
plus_focused_lane raw_alerts=19 unique_cases=12 duplicates=7 tp=10 fp=2 fn=0 critical=4/4 recall=100.0% precision=83.3% gate=pass
decision=add_focused_authorization_lane

تفسیر نتیجه

شش Alert تکراری هیچ Coverage تازه‌ای نساختند. Baseline هشت عیب از ده عیب را گرفت، اما tenant authorization بحرانی را جا انداخت و Gate را شکست. lane هدفمند با سه Finding خام، دو عیب گمشده را گرفت، Precision را نیز بهتر کرد و Critical recall را کامل کرد. نتیجه «یک ابزار بیشتر بخرید» نیست؛ Gap را با روش مناسب پر کنید.

محدودیت‌ها: Dataset کوچک/ساختگی است؛ TN/FPR در خروجی نمونه گزارش نشده؛ Effort، Runtime، confidence و uncertainty واقعی مدل نشده‌اند. در PoC production باید Truth set بزرگ‌تر، negative cases، چند زبان/Framework، versioned config و بازبینی مستقل داشته باشید.

Finding state machine

New -> NeedsTriage -> Confirmed -> Assigned -> InRemediation
    -> ReadyForRetest -> VerifiedFixed -> Closed

branches:
  FalsePositive / Duplicate / OutOfScope
  AcceptedRisk(expiring) / Mitigated(expiring)
  Inconclusive(evidence deadline) / Reopened

Scanner «Closed» یا «Not found» را Closure نهایی نگیرد. Rule خاموش، Scope کم، line shift یا auth failure نیز Finding را ناپدید می‌کند. VerifiedFixed باید Artifact جدید، valid scan، same-scope retest و Regression evidence داشته باشد.

NIST SSDF 1.1 پاسخ به آسیب‌پذیری را در کنار آماده‌سازی سازمان، حفاظت از نرم‌افزار و تولید نرم‌افزار امن قرار می‌دهد. بنابراین AppSec toolchain فقط Detection نیست؛ Evidence، Remediation، پاسخ به Root cause و بهبود چرخه توسعه نیز جزو طراحی عملیاتی‌اند.

Quality Gate را روی New risk بسازید

Legacy backlog را یک‌شبه Block نکنید و آن را هم برای همیشه Baseline نکنید. Gate نمونه:

  • Scan health همه laneهای اجباری Valid؛
  • هیچ Finding جدید Critical/Policy-blocking تأییدشده؛
  • Critical truth-set recall در نسخه Tool/Rule جدید افت نکرده؛
  • هیچ Secret active یا KEV applicable بدون action؛
  • Exception منقضی یا بدون Owner وجود ندارد؛
  • Coverage requirementهای Release کامل/صریحاً Waive شده؛
  • Regression/Retest Evidence به Artifact همان Release وصل است.

Threshold عمومی `CVSS >= ۷` همه Contextها را نمی‌گیرد. Policy را بر Asset tier، Finding class، exploitation evidence، exposure و control بنا کنید و Decision authority را نام ببرید.

Exception و Risk acceptance

Exception باید Finding/Asset/Artifact، rationale، impact، exposure، compensating control، evidence، Owner، Approver، created/expiry، review trigger و remediation plan داشته باشد. «False positive» راه فرار از SLA نیست؛ FP دلیل فنی قابل‌بازتولید می‌خواهد.

Compensating control را تست کنید

WAF، network isolation، feature flag یا additional monitoring فقط وقتی Mitigation است که روی Attack path واقعی تست و Monitor شود. با تغییر architecture/config/control یا رسیدن KEV/Threat intelligence، Exception باید زودتر از Expiry بازبینی شود.

Retest contract

  1. Fix/mitigation و Artifact digest جدید را ثبت کنید؛
  2. Original evidence را روی نسخه آسیب‌پذیر Reproduce نگه دارید؛
  3. همان Attack/Source-sink/Component check را روی نسخه جدید اجرا کنید؛
  4. Regressionهای پیرامونی و bypass variantها را بسنجید؛
  5. Compensating control و deploy state را Verify کنید؛
  6. Valid scan health و coverage را تأیید کنید؛
  7. Case را VerifiedFixed یا Reopened کنید.

ناپدیدشدن Rule finding کافی نیست. برای SQL injection، query پارامتری و تست malicious/benign؛ برای Secret، revocation؛ برای CVE، package/artifact/affected function؛ برای cloud config، effective policy؛ و برای authorization، role×object denial لازم است.

CI/CD lanes و بودجه

Lane زمان هدف
IDE/Pre-commit ثانیه Secret/Lint/ruleهای high-signal
PR دقیقه New-code SAST/SCA/IaC + unit security
Build artifact دقیقه Image/SBOM/signature/config
Staging ده‌ها دقیقه Auth DAST/API/IAST targeted
Nightly ساعت Full scans/fuzz/crawl/benchmark
Release Risk-based Coverage/Gate/Exception/Retest pack
Continuous ops Event/time KEV/feed/drift/exposure/incident

هر lane باید timeout، concurrency، cache/baseline identity، retry policy و invalid-run behavior داشته باشد. Timeout را Pass نکنید؛ `inconclusive` یا `invalid` نشان دهید.

Finding ingestion و یکپارچه‌سازی

خروجی چند Tool باید با contract وارد Vulnerability management شود. Parser version، raw-report digest، import count، rejected records و mapping errors را مانیتور کنید. راهنمای یکپارچه‌سازی ابزارها الگوهای Idempotency، duplicate/out-of-order، retry، Trace و Reconciliation را برای این مسیر توضیح می‌دهد.

پلتفرم‌هایی مانند OWASP DefectDojo نمونه‌ای از لایه Orchestration و مدیریت Finding هستند؛ اما وجود Platform به‌تنهایی کیفیت Parser، Dedupe، Ownership یا Closure evidence را تضمین نمی‌کند و همان contract و reconciliation لازم است.

یک API success تضمین نمی‌کند همه Findingها وارد شده‌اند. Source count/set را با مقصد Reconcile و Delete/close/tombstone semantics را صریح کنید.

SLA و Queue design

SLA را فقط با Severity scanner نسازید. Asset tier، exploit evidence، exposure، data/privilege impact و fix availability را وارد کنید. Clock را از `confirmed_at` یا policy-defined event آغاز کنید و زمان‌های waiting-for-evidence/owner را پنهان نکنید.

مالکیت

  • Product team: Fix و regression؛
  • AppSec: Policy، Triage، benchmark و exception review؛
  • Platform: Scanner runtime/integration/credential/health؛
  • Asset owner: Priority و business impact؛
  • Risk authority: Acceptance/waiver؛
  • Incident response: active exploit/secret/urgent containment.

Metricهای سالم

  • Asset coverage با Owner/Criticality؛
  • Requirement/Threat coverage، نه فقط Tool coverage؛
  • Valid/degraded/invalid scan rate؛
  • Critical recall، Recall/Precision/FPR روی Truth set؛
  • Unique Cases در برابر raw alerts/duplicates؛
  • Time-to-triage/remediate/retest با percentile؛
  • Reopen/reintroduced/recurring weakness rate؛
  • Exception volume/age/expiry/trigger review؛
  • Verified fix rate و deployment lag؛
  • False-negative source و coverage gaps؛
  • Parser/import/reconciliation error؛
  • Developer interruption per valid finding.

«تعداد Vulnerability کم شد» ممکن است از Rule خاموش، Scope کمتر یا Dedup تهاجمی باشد. هر Outcome metric را با health/coverage guardrail همراه کنید.

PoC سبد AppSec در دو هفته

روز ۱ تا ۲: Scope/Truth

Asset/Artifact/Threat/Requirement/RoE، Truth set و Hard gates را Freeze کنید. Offering/engine/rule/config/Tier دقیق هر Tool را ثبت کنید.

روز ۳ تا ۵: Run health/Detection

Happy/negative/seeded cases را اجرا و TP/FN/TN/FP را به تفکیک Slice بسنجید. Auth/crawl/build/feed/coverage health را مستقل گزارش کنید.

روز ۶ تا ۸: Normalize/Triage

Raw evidence→Canonical record→Fingerprint→Dedupe/related/chained→Context card را با Reviewer دوم اجرا کنید. Repair time و mapping loss را اندازه بگیرید.

روز ۹ تا ۱۰: Failure/Operations

Scanner timeout، auth failure، stale feed، parser reject، duplicate import، rate limit، revoked credential و rule upgrade را تزریق کنید؛ invalid-run و Reconciliation را بسنجید.

روز ۱۱ تا ۱۲: Fix/Retest/Gate

چند Finding واقعی را Fix، ReadyForRetest و VerifiedFixed کنید. Exception expiry، reintroduced case و Gate روی New risk را تمرین کنید.

روز ۱۳ تا ۱۴: Decision

Coverage gap، critical recall، Precision/effort، TCO، Iran access، workflow، confidence و residual risk را مرور کنید. Adopt/Complement/Replace/Reject را laneبه‌lane تصمیم بگیرید.

سناریوی ایرانی فین‌تک

دارایی‌ها: Checkout API، Settlement worker، admin panel، mobile app، container image و Terraform. Threatها: SQL injection، SSRF preview، tenant authorization، duplicate refund، Secret history، public bucket و CVE dependency. داده مصنوعی است و هیچ PSP/Production واقعی هدف Active scan نیست.

برای مسیر ورود و APIهای چندمستأجری، آزمون role×action×object باید علاوه بر Token validation، مرز Issuer، Audience، Scope و Session را پوشش دهد؛ راهنمای تست امنیت OAuth و OIDC سناریوهای این لایه را تفکیک می‌کند.

Operating flow

  1. PR: SAST/SCA/Secret/IaC روی Commit و lockfile؛
  2. Build: image digest، SBOM و container scan؛
  3. Staging: authenticated DAST/API role matrix و controlled observer؛
  4. Nightly: Fuzz/Full scan/Truth regression؛
  5. Ingest: Canonical Case و dedupe با Raw evidence؛
  6. Triage: IRR/toman/tenant/PSP context و ownership؛
  7. Gate: critical coverage/KEV/Secret/exception checks؛
  8. Retest: same Attack + business invariant + artifact/deploy evidence.

شرایط ایران و unavailable scenario

SaaS region، Account/payment، plugin/update/feed، license activation، support و upload source/artifact ممکن است برای Offering/Tier/زمان مشخص محدود یا ناپایدار باشد. Legal/Procurement/IT باید Evidence تاریخ‌دار جمع کنند؛ ادعای کلی کافی نیست.

  • آیا Engine/Rule/KEV/CVE feed آفلاین و امضاشده Mirror می‌شود؟
  • Feed age و last-success visible و Gate-aware است؟
  • Source/SBOM/secret خارج کشور می‌رود؟ Retention/region چیست؟
  • اگر SaaS قطع شد، raw report/SARIF/export و backlog محفوظ است؟
  • Fallback lane همان coverage/recall را دارد یا Risk آشکار می‌شود؟
  • Clock/Unicode/Persian path/file/branch در parser سالم است؟

TCO سبد ابزار

TCO = licenses + runners/agents + scan_compute/storage/egress
    + onboarding/rule_tuning + integration/parsers
    + triage/remediation/retest + benchmark/maintenance
    + training/on-call/incident + migration/exit

Cost per scan به‌تنهایی گمراه‌کننده است. Cost per valid unique finding، per covered critical requirement و per verified fix را همراه Developer interruption و FN risk بسنجید. Tool ارزان با Alert flood یا Gap بحرانی ارزان نیست.

Scorecard سبد و lane

محور وزن نمونه Evidence
Requirement/Threat coverage ۲۰٪ versioned coverage matrix
Critical recall/Precision ۲۰٪ public+private truth set
Scan health/diagnosability ۱۰٪ failure injection
Evidence/Triage/Dedupe ۱۵٪ second-person workflow
CI/Retest/Gate ۱۵٪ end-to-end fix drill
Security/Data/Access/Exit ۱۰٪ contract/unavailable/export
TCO/Scale/Operations ۱۰٪ measured workload

Score صفر تا پنج بر اساس Evidence: Unknown، ادعا، Demo، Pilot، failure/recovery proven، و production over change cycles. Critical recall، active Secret، unsafe RoE و incomplete export Hard gate باشند؛ Score میانگین آن‌ها را جبران نکند.

۱۵ ضدالگوی برنامه ابزار AppSec

  1. Tool taxonomy به‌جای threat coverage؛
  2. Alert count به‌عنوان موفقیت؛
  3. صفر Finding بدون Scan health؛
  4. PoC روی Demo vendor بدون Truth set؛
  5. Benchmark عمومی به‌عنوان Production recall؛
  6. Severity scanner برابر Risk؛
  7. CVSS Base یا EPSS به‌تنهایی؛
  8. ناپدیدشدن Finding برابر Fix؛
  9. عنوان/line/CVE به‌عنوان fingerprint کامل؛
  10. Suppress همیشگی بدون expiry؛
  11. FP نامیدن True weakness با control؛
  12. Gate روی Run timeout/auth-failed؛
  13. Active scan بدون RoE/kill؛
  14. Business logic بدون lane هدفمند؛
  15. سبد بدون Reconciliation/Retest/Exit.

چک‌لیست نهایی

  • □ Asset/Artifact/Owner/Criticality ثبت‌اند.
  • □ Threat و Requirement نسخه‌دارند.
  • □ Coverage matrix lane+complement+Oracle دارد.
  • □ RoE و stop/kill/data controls تصویب شده‌اند.
  • □ Offering/engine/rule/config/version دقیق‌اند.
  • □ Truth set مثبت/منفی/بحرانی محلی دارد.
  • □ TP/FN/TN/FP به تفکیک Slice سنجیده‌اند.
  • □ Scan health و invalid/inconclusive run اجرا می‌شوند.
  • □ Canonical record Raw evidence را حفظ می‌کند.
  • □ Fingerprint، Duplicate/Related/Chained را تفکیک می‌کند.
  • □ Triage state/reason/evidence/owner مشخص است.
  • □ CVSS/KEV/EPSS با context استفاده می‌شوند.
  • □ Secret/CVE/Cloud/logic workflow تخصصی دارند.
  • □ Gate روی New risk و valid coverage است.
  • □ Exception Owner/Approver/Expiry/Trigger دارد.
  • □ Retest به Artifact و same scope وصل است.
  • □ Parser/import/reconciliation مانیتور می‌شوند.
  • □ Iran access/feed age/unavailable آزموده شده‌اند.
  • □ TCO شامل Triage/Fix/Retest/Exit است.
  • □ Critical gap، residual risk و review date ثبت‌اند.

سؤالات متداول مدیریت ابزارهای AppSec

آیا SAST، DAST و SCA برای AppSec کافی‌اند؟

برای بسیاری از signalها مفیدند، اما Coverage کامل نیست. Authorization، workflow/race/financial invariant، runtime/cloud drift، secret history، parser states و exploit chain ممکن است laneهای Targeted API/manual/fuzz/runtime لازم داشته باشند. Threat matrix Gap را تعیین می‌کند.

چطور False Positive را کم کنیم بدون اینکه False Negative زیاد شود؟

ابتدا run/config/evidence را Validate و Rule را روی Truth set مثبت و منفی بسنجید. Suppression را Narrow، reasoned و expiring کنید؛ تغییر rule pack را با Critical recall regression آزمایش کنید. کم‌کردن Alert به‌خودی‌خود هدف نیست.

بهترین معیار برای ابزار امنیت چیست؟

یک معیار کافی نیست. Critical recall، Recall/Precision/FPR، threat/requirement coverage، scan-health validity، triage/repair effort، verified-fix time، integration reliability و TCO را کنار هم ببینید. Hard gateهای Safety/Access/Export را جدا نگه دارید.

چه زمانی Finding را Fixed ببندیم؟

وقتی Fix/mitigation روی Artifact جدید وجود دارد، original attack/check دیگر اثر ندارد، variant/regressionها پاس‌اند، Scan scope سالم است و نسخه اصلاح‌شده واقعاً Deploy شده است. صرف ناپدیدشدن هشدار یا تغییر line کافی نیست.

آیا CVSS یا EPSS برای اولویت‌بندی کافی است؟

خیر. CVSS ویژگی/Severity را منتقل می‌کند و EPSS احتمال exploit مشاهده‌شده CVE را پیش‌بینی می‌کند. Asset، exposure، reachability، data/privilege impact، KEV/threat evidence، controls و fix window برای Priority واقعی لازم‌اند.

جمع‌بندی

برنامهٔ ابزار AppSec یک مجموعه Scanner نیست؛ یک سیستم اندازه‌گیری و تصمیم است. باید ثابت کند چه چیزی را با چه اعتبار و محدودیتی دیده، Findingها را چگونه به Case واقعی تبدیل کرده، چه Gapی باقی مانده و Fix روی همان Artifact/Environment چگونه تأیید شده است.

آزمایش ساختگی نشان داد شش Alert تکراری Coverage نمی‌سازند و یک lane هدفمند کوچک می‌تواند Gap بحرانی را ببندد. از Asset/Threat/Requirement شروع کنید، Truth set و Scan health بسازید، Finding را Normalize اما Evidence را حفظ کنید، Priority را Contextual و Exception را منقضی کنید، و Gate را تنها پس از Retest و Reconciliation معتبر کنید.

محمد عسکری

محمد هستم، توسعه‌دهنده وب با بیش از ده سال تجربه در برنامه‌نویسی سمت سرور و کاربر. به یادگیری و اشتراک‌گذاری دانش علاقه‌مندم و اخیراً تمرکزم را روی حوزه تست نرم‌افزار گذاشته‌ام تا تجربیاتم را در این زمینه نیز به اشتراک بگذارم و به درک بهتر کیفیت نرم‌افزار کمک کنم.

دیدگاهتان را بنویسید