پایپلاین یک فینتک ایرانی ۱۶ هشدار امنیتی تولید کرده و داشبورد سبز است؛ بعد از 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: noneSafe 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_runSARIF 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_lineageTitle، 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 هشتمرحلهای
- Validate run: Scan health و scope معتبر است؟
- Reproduce/inspect: Evidence واقعی است یا parser/rule artifact؟
- Classify: TP، FP، Duplicate، Out-of-scope، Accepted risk یا Inconclusive؛
- Map: Asset/Artifact/Owner/Requirement/CWE/CVE؛
- Contextualize: Reachability، Exposure، privilege، data، controls؛
- Prioritize: impact، exploitation، urgency و fix path؛
- Act: fix/mitigate/rotate/isolate/retire/exception؛
- 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) / ReopenedScanner «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
- Fix/mitigation و Artifact digest جدید را ثبت کنید؛
- Original evidence را روی نسخه آسیبپذیر Reproduce نگه دارید؛
- همان Attack/Source-sink/Component check را روی نسخه جدید اجرا کنید؛
- Regressionهای پیرامونی و bypass variantها را بسنجید؛
- Compensating control و deploy state را Verify کنید؛
- Valid scan health و coverage را تأیید کنید؛
- 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
- PR: SAST/SCA/Secret/IaC روی Commit و lockfile؛
- Build: image digest، SBOM و container scan؛
- Staging: authenticated DAST/API role matrix و controlled observer؛
- Nightly: Fuzz/Full scan/Truth regression؛
- Ingest: Canonical Case و dedupe با Raw evidence؛
- Triage: IRR/toman/tenant/PSP context و ownership؛
- Gate: critical coverage/KEV/Secret/exception checks؛
- 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/exitCost 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
- Tool taxonomy بهجای threat coverage؛
- Alert count بهعنوان موفقیت؛
- صفر Finding بدون Scan health؛
- PoC روی Demo vendor بدون Truth set؛
- Benchmark عمومی بهعنوان Production recall؛
- Severity scanner برابر Risk؛
- CVSS Base یا EPSS بهتنهایی؛
- ناپدیدشدن Finding برابر Fix؛
- عنوان/line/CVE بهعنوان fingerprint کامل؛
- Suppress همیشگی بدون expiry؛
- FP نامیدن True weakness با control؛
- Gate روی Run timeout/auth-failed؛
- Active scan بدون RoE/kill؛
- Business logic بدون lane هدفمند؛
- سبد بدون 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 معتبر کنید.
