همکاری QA و AppSec با نصب SAST و DAST یا افزودن واژه Security به Definition of Done شکل نمیگیرد. رابط عملیاتی زمانی ساخته میشود که Threat و Risk به Security Claim نسخهدار تبدیل شوند، Control و Oracle مشخص باشد، Evidence چندلایه جمع شود، Finding مسیر تصمیم داشته باشد و Release exception/Incident دوباره به Requirement و Test برگردد.
این صفحه مالک چرخه QA–AppSec Assurance Interface است: Context/Asset/Threat → Claim/Control → Verification plan → Evidence/Finding → Risk decision/Exception → Release/Monitor/Incident/Learning. روشهای عمومی در راهنمای تست امنیت نرمافزار، ادغام Scannerها در خط لوله DevSecOps و Risk prioritization عمومی در تست مبتنی بر ریسک مالکیت جدا دارند.
پاسخ کوتاه: همکاری QA و AppSec چیست؟
یک Operating contract میان Product، Engineering، QA، AppSec، Platform و Operations است تا ادعای امنیتی محصول از طراحی تا Production قابلردیابی و قابلتصمیم باشد. QA میتواند در Requirement clarity، Test design، negative paths، evidence quality و regression کمک کند؛ AppSec/دارنده Authority امنیتی Threat، تخصص، قواعد تست تهاجمی، تحلیل آسیبپذیری و Risk advice را هدایت میکند. Product/Business و Release/Risk authority نیز تصمیمهای خود را حفظ میکنند.
قاعده: «Security is everyone’s responsibility» یعنی هر نقش مسئول رفتار و Evidence محدوده خودش است؛ نه اینکه همه مجاز به Exploit، پذیرش Risk، تغییر Policy، دیدن Secret یا اعلام امنیت محصول باشند.
Quality و Security همپوشاناند، اما یکی نیستند
| لنز | سؤال نمونه | Oracle/Authority غالب |
|---|---|---|
| Functional quality | Refund طبق Rule محاسبه میشود؟ | Product requirement/business oracle |
| Security | کاربر غیرمالک میتواند Refund دیگری را ببیند/بسازد؟ | Threat/authorization/security control |
| Privacy | داده برای Purpose مجاز و Retention درست است؟ | Privacy/legal policy + technical evidence |
| Reliability | پس از timeout/retry State بازیابی میشود؟ | SLO/state reconciliation |
| Safety | Failure چه آسیب فیزیکی/انسانی میسازد؟ | Safety authority/hazard analysis |
| Compliance | Control الزام نسخهدار را پوشش میدهد؟ | Applicable requirement/control owner |
| Fraud/abuse | Flow معتبر چگونه سوءاستفاده اقتصادی میشود؟ | Abuse/risk domain owner |
یک رفتار میتواند هم Functional bug و هم Security weakness باشد؛ طبقهبندی برای Route تصمیم است، نه جنگ مالکیت. «محصول امن ذاتاً باکیفیت است» نیز دقیق نیست: ممکن است Control امنیتی درست باشد اما Accessibility یا Correctness شکست بخورد، یا Feature کاملاً کار کند ولی Authorization ناقص باشد.
همگرایی با ادغام نقشها فرق دارد
| مدل | مزیت | ریسک |
|---|---|---|
| Security gate مرکزی | تخصص و استقلال | Queue/دیرهنگام/Context کم |
| AppSec embedded | Feedback سریع و Context | ظرفیت کم/تعارض استقلال |
| Security champion | زبان مشترک در تیم | قهرمان بیوقت/بیاختیار |
| QA security liaison | Claim/Evidence/Test continuity | انتقال مسئولیت تخصصی به QA |
| Self-service paved road | Control و Test reusable | اعتماد کور به Platform |
| Independent assurance | Challenge و conflict separation | هزینه/زمان/فاصله Context |
| Hybrid risk-tiered | عمق متناسب با Risk | Tier gaming/Route ambiguity |
Topology باید با اندازه، Criticality، Regulation، Skill و استقلال موردنیاز تنظیم شود؛ صفحه مدل عملیاتی QA انتخاب Centralized/Embedded/Federated را برای کل سازمان پوشش میدهد. اینجا فقط Interface امنیت–کیفیت را تعریف میکنیم.
منابع رسمی چه میگویند و چه نمیگویند؟
| منبع | کاربرد محدود در این راهنما | نباید نتیجه بگیریم |
|---|---|---|
| NIST SSDF 1.1 | واژگان و Practiceهای سطحبالای توسعه امن در SDLC | Certification، Tool list یا قانون ایران |
| OWASP ASVS | Requirementهای فنی نسخهدار برای Verification وب | Top ۱۰، Risk model یا پوشش همه سیستمها |
| OWASP SAMM Control Verification | پیوند Requirement و Test برای Controlهای نرمافزار | گواهی بلوغ یا نسخه واحد برای هر تیم |
| CISA Secure by Design | مالکیت سازنده بر Outcomeهای امنیت مشتری و بارننداختن همه مسئولیت روی کاربر | الزام حقوقی محلی یا انتقال مسئولیت به QA |
صفحه رسمی CISA در مرورگر قابلخواندن است اما به درخواست خط فرمان این ممیزی پاسخ ۴۰۳ ضدبات داد؛ برای همین سه منبع فنی مستقیم ۲۰۰ ستون اصلیاند. هیچ Frameworkی Evidence یک Release خاص را جایگزین نمیکند.
Operating loop مشترک QA–AppSec
Context/asset/data/actor/business effect → threat/abuse/misuse and trust boundary → versioned security claim + control owner → evidence plan and test authorization → implementation/build/config/dependency identity → automated + manual + operational evidence → finding/unknown/limitation → triage + risk treatment + decision authority → release gate or time-bounded exception → production telemetry/incident/customer signal → control/test/requirement/root-cause improvement
Security Claim؛ واحد همکاری
«امن باشد» Requirement نیست. Claim باید بگوید چه Assetی در برابر کدام Actor/Action، در کدام Scope و State، با کدام Control و Evidence حفاظت میشود. Claim نه اثبات مطلق امنیت است و نه تضمین نبود Vulnerability؛ گزارهای محدود و ابطالپذیر است.
Security Claim Contract claim ID/version/status/owner/approver product journey/asset/data/business effect actor/role/tenant/trust boundary threat/abuse/misuse and excluded threat security property: confidentiality/integrity/availability/authenticity... precondition/state/environment/dependency expected deny/allow/fail-safe/recovery behavior preventive/detective/corrective control identities requirement/source/version and applicability rationale test techniques/oracles/negative/metamorphic paths build/config/policy/key/dependency identities evidence layers and required independence unknowns/assumptions/limitations/expiry failure severity and triage route release hard gate/exception authority production signal/incident feedback change trigger/reverification cadence
نمونه تبدیل Feature به Claim
| Feature sentence | Claim قابلآزمون | Evidence family |
|---|---|---|
| «رسید امن است» | فقط owner سفارش در tenant همان درخواست میتواند receipt کامل را بخواند | policy/unit/API/manual/log |
| «Callback معتبر است» | هر پیام با signature/domain/time policy نامعتبر بدون اثر Ledger رد میشود | unit/property/integration/reconciliation |
| «Audit داریم» | عمل Admin به actor/action/target/result/time نسبت و tamper signal تولید میکند | integration/tamper/operations review |
| «Export داده حساس ندارد» | Fieldهای طبقهبندیشده خارج purpose در export نیستند | schema/unit/DLP fixture/manual sample |
| «Session امن است» | پس از revoke، token/session مطابق bound زمانی پذیرفته نمیشود | state/time/API/cache/multi-node |
Threat، Requirement، Control، Test و Finding را جدا کنید
| مفهوم | پرسش | دام |
|---|---|---|
| Threat | چه Actor/شرطی چه اثر نامطلوبی میسازد؟ | لیست عمومی بدون Context |
| Requirement | چه رفتار/خاصیتی الزام شده است؟ | «مطابق OWASP» بدون ID/version |
| Control | چه چیزی Prevent/Detect/Correct میکند؟ | وجود Library مساوی اثربخشی |
| Test | چه Probe و Oracle ادعا را Challenge میکند؟ | Tool run بدون Claim |
| Evidence | چه Artifactی نتیجه را به Build/Scope وصل میکند؟ | Screenshot سبز |
| Finding | چه Observation خلاف Claim/Expectation است؟ | Scanner alert مساوی vulnerability |
| Risk | در Context، احتمال/Impact/uncertainty چیست؟ | CVSS مساوی business risk |
| Decision | Fix/Mitigate/Accept/Avoid/Transfer/Hold با چه Authority؟ | QA یا Scanner تصمیمگیر |
Control فقط Preventive نیست
| نوع | مثال | سؤال تست |
|---|---|---|
| Preventive | Authorization policy/input validation | آیا action نامجاز قبل از effect متوقف میشود؟ |
| Detective | audit/anomaly alert | آیا event درست، بهموقع و actionable دیده میشود؟ |
| Corrective | revoke/rotate/restore/compensate | آیا اثر و access در bound مشخص Repair میشود؟ |
| Deterrent | notice/accountability | آیا پیام دقیق است و Control واقعی را اغراق نمیکند؟ |
| Compensating | manual approval/limited scope | چه Gapی، تا چه زمان و با چه residual risk میپوشاند؟ |
| Recovery | backup/failover/reconciliation | Integrity و authority پس از recovery حفظ میشود؟ |
Evidence ladder؛ یک ابزار هیچ Claim مهمی را کامل نمیکند
- E0 — Declaration: Requirement/diagram/attestation؛ نیت را نشان میدهد، نه رفتار.
- E1 — Implementation: code/config/dependency/policy review؛ وجود/ساخت Control.
- E2 — Component: unit/property/static tests؛ منطق محدود در fixture.
- E3 — Integration: identity/network/data/state واقعیتر و failure paths.
- E4 — Adversarial/manual: abuse، chaining، business logic و expert challenge مجاز.
- E5 — Operational: telemetry، alert، response، revoke/recovery/reconciliation drill.
- E6 — Independent: review/audit/assessment با Scope و limitation مستقل.
همه Claimها به همه لایهها نیاز ندارند. Threat و Impact تعیین میکند چه ترکیبی کافی است. Evidence presence نیز بهتنهایی Truth، freshness، coverage یا independence را ثابت نمیکند؛ Artifact باید بررسی شود.
آزمایش قطعی: Scanner pass با Claim completeness فرق دارد
یک Fixture مستقل Node.js ۲۴.۱۸.۰ با چهار Claim کاملاً ساختگی ساختیم. سه Job خیالی SAST، SCA و DAST baseline همگی Pass بودند؛ Policy ساده و نادرست بر این اساس Release را Pass میکرد. Gate دوم Evidence لازم هر Claim را جدا بررسی کرد.
AUTHOR_DESIGNED_SECURITY_CLAIM_GATE SAST PASS SCA PASS DAST_BASELINE PASS naive scan pass rate = 100% → PASS C1 receipt owner-only SUPPORTED_FOR_SCOPE C2 duplicate callback INCOMPLETE: MANUAL_ABUSE missing C3 export excludes secrets SUPPORTED_FOR_SCOPE C4 admin attributable SUPPORTED_FOR_SCOPE critical incomplete = C2 decision = HOLD_OR_AUTHORIZED_EXCEPTION
این فقط مکانیک تفاوت دو سؤال را نشان میدهد: «Job ابزار سبز است؟» و «Evidence خاص Claim کامل است؟». همه Claimها، Evidence labelها، Criticality و Ruleها ساخته نویسندهاند؛ حضور Evidence اعلامی است و صحت/کیفیت/تازگی/پوشش آن بررسی نشده. Threat، Exploitability، احتمال، Impact، دقت Scanner، افراد، هزینه و Risk واقعی مدل نشده است. خروجی Security audit، پیادهسازی استاندارد، Maturity assessment، Benchmark، Compliance test یا Release algorithm نیست.
ASVS را با Version و Applicability به کار ببرید
OWASP ASVS یک مبنای Requirement/Verification فنی برای Web application میدهد و توصیه میکند Reference شامل Version باشد، چون شناسهها میتوانند تغییر کنند. «مطابق ASVS» بدون Version، Requirement ID، Level/applicability، Exclusion rationale و Evidence trace مبهم است. ASVS Threat model، Business abuse، Privacy law، Infrastructure کامل یا Risk acceptance شما را جایگزین نمیکند.
Versioned verification reference source = OWASP ASVS version = exact stable version used requirement ID = v<version>-chapter.section.requirement applicable = yes / no / partial / unknown rationale and system boundary mapped security claim/control/test evidence artifact/build/config verdict + limitation + reviewer + time change/recheck trigger
Control verification با Weakness discovery یکی نیست
OWASP SAMM میان Requirements-driven Control Verification و Security Testing برای کشف Weakness تمایز مفیدی میدهد. اولی میپرسد Control تعریفشده درست کار میکند؛ دومی میکوشد ضعفهای فنی/Business logic را فراتر از Requirement موجود آشکار کند. هر دو لازماند: Requirement ناقص ممکن است همه Testهای مبتنی بر خودش را سبز کند.
| مسیر | نمونه | خروجی |
|---|---|---|
| Control verification | non-owner receipt denied | claim verdict |
| Weakness discovery | ID enumeration/chained role confusion | finding/unknown |
| Abuse testing | valid actions combine to drain voucher | business abuse finding |
| Operational verification | alert/revoke/recovery drill | detection/response evidence |
| Independent assessment | bounded expert review | scope-limited assurance/finding |
OWASP Top ۱۰ نقشه کامل تست نیست
Top ۱۰ یک Awareness/risk-category document نسخهدار است، نه Test plan کامل یا فهرست ده Vulnerability ثابت. استفاده درست آن در راهنمای OWASP Top ۱۰ آمده است. Claimها باید از Asset، Flow، Threat و Control خود محصول بیایند؛ سپس منابع مرجع coverage gap را Challenge کنند.
نقش QA؛ Liaison و Evidence engineer، نه «هکر اجباری»
| QA میتواند | فقط با Capability/Authorization | نباید پیشفرض شود |
|---|---|---|
| ابهام Claim/acceptance را آشکار کند | DAST active روی محیط مصوب | Exploit هر Target |
| negative/state/boundary paths بسازد | Threat workshop facilitation | مالک نهایی Threat model |
| functional+security regression را پیوند دهد | Scanner rule tuning | پذیرش Risk/Exception |
| Build/config/data/evidence identity را حفظ کند | Finding validation محدود | تعیین یکنفره Severity |
| Duplicate/late/retry/authorization scenarios را آزمون کند | credential/key tests | دسترسی Secret/Production |
| Unknown/limitation را در Release report بیاورد | Manual abuse testing | Pen tester حرفهای یا Incident commander |
| Test escape را به regression تبدیل کند | Red-team exercise | اعلام «محصول امن است» |
«مثل هکر فکر کن» توصیه مبهمی است و میتواند Authorization، Scope و ایمنی را پنهان کند. بهتر است بگوییم: Abuse/misuse case تعریفشده را با ابزار و مجوز متناسب Challenge کن، Stop condition و Incident route داشته باش و خارج Scope ادامه نده.
Capability و Authorization دو محور مستقلاند
Security test authorization person/team capability evidence target/build/environment/account/tenant technique/tool/payload/rate/time window read/write/destructive/exfiltration boundaries allowed data and evidence handling third-party/cloud/PSP/vendor permission monitoring suppression vs retained detection stop conditions and emergency contact cleanup/recovery/reconciliation finding disclosure and retention approver and expiry
آموزش OWASP یا کار با ZAP نه Capability کامل است و نه Authorization. برعکس، متخصص ماهر نیز بدون مجوز نباید Test تهاجمی اجرا کند. Access باید least privilege و داده/اثر مصنوعی باشد؛ NDA اجازه Exploit نمیسازد.
Decision rightها را قبل از Finding بنویسید
| تصمیم | Inputها | Authority نمونه |
|---|---|---|
| Claim applicability | Product/architecture/threat/compliance | Control/requirement owner |
| Test authorization | technique/target/impact/environment | Security+system owner |
| Finding validity | reproduction/trace/control expected | AppSec/defect owner |
| Technical severity | exploitability/impact/scope | Security triage authority |
| Business priority | exposure/customer/operations/dependency | Product/risk governance |
| Remediation design | root cause/options/regression | Engineering/control owner |
| Risk acceptance/exception | residual risk/compensation/expiry | named risk authority |
| Release | quality+security+operations evidence | release authority |
| Disclosure/notification | finding/incident/legal obligations | security/legal/communications |
Separation of Duties؛ Shared responsibility بدون Self-approval
- نویسنده Control نباید تنها Reviewer اثربخشی همان Control باشد.
- مالک Delivery نباید Risk بحرانی خود را بدون Authority مستقل Accept کند.
- QA که Test را نوشته میتواند Evidence بدهد، اما Risk decision را مالک نمیشود.
- AppSec advisor الزاماً Release owner یا Product priority owner نیست.
- Platform team که Guardrail میسازد باید Consumer integration و bypass را مستقل Verify کند.
- Admin/key holder، Audit reviewer و Approver حساس تا حد معقول جدا باشند.
- Exception owner، approver و compensating-control operator مشخص و قابلردیابیاند.
- تیم کوچک میتواند Review متقاطع/زماندار داشته باشد؛ نبود Headcount توجیه Self-approval خاموش نیست.
از Discovery تا Retirement چه کسی چه Evidence میدهد؟
| مرحله | QA contribution | AppSec contribution | خروجی مشترک |
|---|---|---|---|
| Discovery | journey/quality risk/abuse questions | asset/threat/adversary/context | risk/claim backlog |
| Design | testability/oracle/failure path | trust boundary/control pattern | claim/control/evidence plan |
| Build | unit/integration/state tests | secure coding/rules/review | traceable build evidence |
| CI | fixture/validity/flaky/triage route | SAST/SCA/secret/policy configuration | gated signal |
| Test environment | end-to-end/reconciliation/accessibility | DAST/manual abuse/authorization | claim verdict/finding |
| Release | scope/unknown/regression | risk/finding/exception advice | decision packet |
| Production | synthetic/business reconciliation | telemetry/detection/response | operational assurance |
| Incident | reproduce/regression/evidence integrity | contain/investigate/disclose | root cause/action |
| Retirement | data/feature/test removal verification | key/access/dependency/exposure closure | exit evidence |
Threat workshop را به Test backlog تبدیل کنید
- Journey، Asset، Actor، Data و اثر کسبوکار را روی نمودار مشترک قرار دهید.
- Trust boundary، admin path، dependency و off-chain/manual step را مشخص کنید.
- Misuse/abuse را بدون جزئیات خطرناک خارج نیاز تولید کنید.
- هر Threat را به Prevent/Detect/Correct claim و Owner نگاشت کنید.
- Assumption و excluded threat را نسخهدار ثبت کنید.
- Evidence layer، technique، environment و authorization را انتخاب کنید.
- Hard gate، residual risk، monitor و incident signal را تعیین کنید.
- Change trigger برای Re-threat/Re-test بگذارید.
Test Plan باید Claim-driven باشد، نه Tool-driven
| Technique | سؤال مناسب | Blind spot |
|---|---|---|
| Code review/SAST | الگوی implementation مشکوک کجاست؟ | runtime/config/business context |
| SCA/SBOM analysis | Dependency/version/advisory/exposure چیست؟ | reachability/config/unknown vulns |
| Secret scan | credential-like artifact وارد repo/build شده؟ | runtime store/validity/exposure |
| Unit/property | control logic/invariant روی ورودیها؟ | integration/identity/network |
| API/integration negative | role/tenant/state boundary؟ | client/deployment/manual abuse |
| DAST baseline | known classهای observable روی runtime؟ | auth/business logic/coverage |
| Manual abuse | valid steps چگونه chain/misuse میشوند؟ | scale/repeatability/analyst variation |
| Pen test | مهاجم محدود چه path/impactی میسازد؟ | time/scope/point-in-time |
| Config/IaC/policy test | deployed control با intended policy یکی است؟ | runtime bypass/drift after check |
| Operational drill | detect/contain/revoke/recover واقعاً کار میکند؟ | تهدیدهای تمریننشده |
Pipeline signal باید Valid باشد
Security pipeline signal contract tool/rule/config/database/version identity target repository/artifact/image/build/config full vs incremental scope and baseline credentials/role/authenticated coverage environment reachability and test data exit code/status semantics: pass/fail/error/timeout/skipped finding identity/dedup/suppression/expiry raw artifact retention and access false-positive validation route false-negative/sentinel/canary checks performance/resource/rate limits owner/SLA/escalation and fallback hard gate vs advisory policy change/revalidation trigger
Job سبز ممکن است به معنی «هیچ Findingی گزارش نشد»، «هیچ Ruleی اجرا نشد»، «Target در دسترس نبود اما fail-open شد» یا «همه Findingها baseline/suppressed بودند» باشد. Pass semantics را با Fault injection کنترل کنید: credential خراب، target unreachable، rule disabled، stale database و artifact mismatch باید وضعیت معتبر بسازند.
False Positive و False Negative را جدا مدیریت کنید
| حالت | سؤال | اقدام |
|---|---|---|
| True positive | Observation و impact در Scope معتبر است؟ | finding/triage/remediation |
| False positive | Rule به Control/context غلط نگاشت شده؟ | documented suppression با expiry |
| True negative | Probe معتبر و Coverage کافی بود؟ | scope-limited evidence، نه تضمین |
| False negative | Sentinel/known-bad sample کشف نشد؟ | pipeline invalid/hold/investigate |
| Unknown | timeout/auth/error/coverage gap؟ | inconclusive، نه pass |
| Not applicable | Threat/control واقعاً خارج Scope؟ | versioned rationale/review trigger |
Suppression یک Exception کوچک است
Finding suppression record finding/tool/rule/target/build identity validator and evidence reason: false positive / accepted context / compensating control / duplicate affected scope and residual uncertainty owner/approver/created/expires rule/config/code version production monitor and reopen trigger linked risk/exception/remediation review result and removal evidence
Inline ignore بدون Owner/Expiry، Risk register نیست. Suppression باید در Upgrade، Rule database change، Architecture change، Incident یا Expiry دوباره بررسی شود. تعداد کم Finding نیز میتواند ناشی از suppression debt باشد.
Finding lifecycle با Defect lifecycle همخانواده است، نه یکسان
OBSERVED → NEEDS_VALIDATION | DUPLICATE_RELATED | OUT_OF_SCOPE | SECURITY_INCIDENT → VALIDATED_WEAKNESS | FALSE_POSITIVE | UNKNOWN → SEVERITY_AND_EXPOSURE_ASSESSED → FIX | MITIGATE | AVOID | ACCEPT_EXCEPTION | DEFER → REMEDIATION_IN_PROGRESS → RETEST_PASSED | RETEST_FAILED | CANNOT_VERIFY → MONITOR | DISCLOSE | CLOSE_WITH_REASON → REOPEN on change/incident/expiry
جزئیات Triage، SLA، Duplicate و Reopen در مدیریت نقص نرمافزار آمده است. افزوده امنیتی شامل محدودیت افشا، exploit/evidence handling، CVE/CWE/vendor coordination احتمالی، Risk acceptance و Incident route است.
Severity، Priority و Risk را یکی نکنید
| مفهوم | Input | تصمیم نیست |
|---|---|---|
| Technical severity | impact/exploitability/scope/precondition | ترتیب نهایی Backlog |
| Exposure | reachable actors/data/deployment/time | احتمال دقیق حمله |
| Business impact | customer/finance/operations/legal/safety | CVSS بهتنهایی |
| Priority | risk+dependency+fix/mitigation+deadline | شدت فنی تنها |
| Residual risk | پس از Control/mitigation + uncertainty | صفر با یک Test سبز |
| Release decision | چند Risk/quality/operations trade-off | Pass rate ابزار |
Security Exception؛ زماندار و قابلابطال
Security exception record claim/finding/risk/build/release scope affected assets/users/data/environments evidence, uncertainty and dissent why fix now is not selected feasible alternatives considered compensating controls and their tests production detection/response owner/SLO decision authority and consulted roles start/expiry/review cadence stop/reopen triggers remediation owner/milestones customer/vendor/disclosure implications final closure and verification
Exception به معنی «false positive» یا حذف Finding نیست. Expiry بدون Fix/Review باید Release/feature/access را طبق Policy به Hold یا escalation ببرد، نه اینکه خودکار تمدید شود. QA evidence میدهد؛ Authority مجاز Residual risk را میپذیرد.
Pen test مستقل همچنان جایگاه دارد
Shift-left به معنی حذف آزمون عمیق دیرتر نیست. Automation سریع baseline میدهد؛ متخصص مستقل میتواند Attack chain، Business logic، configuration، deployment و assumptionهایی را Challenge کند که تیم سازنده نمیبیند. بااینحال Pen test point-in-time و Scope-limited است، absence of vulnerabilities را تضمین نمیکند و جای Secure design/continuous verification/monitoring را نمیگیرد.
| نیاز | شرط |
|---|---|
| Independence | conflict، scope و reporting line روشن |
| Authorization | target/technique/data/time/third-party/stop |
| Environment | فیدلیتی لازم و اثر/داده مهارشده |
| Evidence | reproducible but safe؛ secret/PII minimized |
| Remediation | owner/SLA/root cause/regression/retest |
| Closure | retest scope و cannot-verify روشن |
| Learning | class-level prevention، نه فقط patch مورد |
Secure by Design؛ بار را روی مشتری و QA نیندازید
اصل Secure by Design روی مسئولیت سازنده، Defaultهای امن، شفافیت و رهبری سازمانی تأکید دارد. ترجمه عملی برای Interface QA–AppSec این است: Control باید قابلاستفاده و امن بهصورت پیشفرض باشد؛ QA نباید با Testهای بیپایان، Architecture ناامن یا UX پیچیده را جبران کند و مشتری نباید برای امنیت پایه هزینه/پیکربندی نامتناسب متحمل شود. این guidance داوطلبانه/بینالمللی Context است، نه قانون ایران.
سناریوی ایرانی: Callback پرداخت آزمایشی
یک بازارگاه خیالی ایرانی Callback یک PSP کاملاً جعلی را بازطراحی میکند. هیچ بانک، PSP واقعی، کاربر، پول یا تراکنش واقعی وجود ندارد. هدف همکاری QA–AppSec این است که Claimهای Authorization، Authenticity، Integrity، Idempotency، Audit و Recovery به Evidence قابلردیابی تبدیل شوند؛ نه اینکه تیم «محصول را امن» اعلام کند.
Fictional Iranian payment callback context journey = Order→PaymentAttempt→fake PSP→Callback→Ledger→Outbox→Reconciliation identity = tenant/order/payment-attempt/idempotency/run/build/config amount = canonical IRR; displayed toman explicitly labelled locale = Persian/Arabic/Latin digits + Unicode/RTL time = UTC event + Asia/Tehran/Jalali display faults = timeout-before/after-commit, retry, duplicate/late/out-of-order callback data = synthetic; no name/mobile/address/PAN/CVV2/OTP/token/cookie/real secret effects = fake SMS/email/webhook; no real PSP/bank/wallet/merchant/customer security test = sandbox only, authorized accounts/payload/rate/window prohibited = production probing, real credentials, money movement, legal/compliance claim
Claimهای سناریوی پرداخت
| ID | Claim | Evidence ترکیبی | Owner |
|---|---|---|---|
| PAY-C1 | Callback با signature/domain/timestamp نامعتبر هیچ اثر Ledger ندارد | unit/property/API/reconciliation | Backend+AppSec |
| PAY-C2 | Duplicate/retry فقط یک Business effect میسازد | stateful/integration/manual abuse/DB | Backend+QA |
| PAY-C3 | Tenant/order/attempt نامرتبط قابلپیوند نیست | negative authorization/trace/manual | AppSec+QA |
| PAY-C4 | Secret/OTP/PAN در log/report/analytics ظاهر نمیشود | schema/log fixture/secret scan/manual sample | Security+Privacy |
| PAY-C5 | Admin override attributable و محدود است | role/policy/integration/audit tamper | Security+Operations |
| PAY-C6 | Timeout-after-commit به Unknown ایمن و reconciliation میرسد | fault injection/ledger/outbox/runbook | QA+Operations |
| PAY-C7 | نمایش ریال/تومان و State، کاربر را به retry خطرناک هدایت نمیکند | UX/RTL/accessibility/state consistency | Product+QA |
Callback test matrix
| Probe | Expected control behavior | Oracle |
|---|---|---|
| missing/wrong signature | deny before business effect؛ safe audit | response+Ledger/Outbox zero effect |
| stale/future timestamp | policy-bound deny/unknown | config+event+effect |
| same message duplicate | idempotent same outcome | one Ledger effect |
| same order/different attempt | state rule، نه hash-only dedup | Order/Attempt state machine |
| late success after UI timeout | reconcile، no double charge/status lie | PSP fake+Ledger+UI |
| tenant/order swap | deny and alert without data leak | authorization+response content |
| amount/unit mismatch | deny/hold per invariant | raw IRR+contract |
| log injection/oversized field | safe parse/bound/audit | log pipeline+resource |
| key rotation overlap | declared old/new window only | key/config/time identity |
| reconciliation restart | resume idempotently | checkpoint+effects |
فارسی، ریال/تومان و Security UX
- مبلغ canonical را Integer IRR نگه دارید؛ تومان فقط نمایش برچسبدار با rounding rule صریح است.
- ارقام فارسی/عربی/لاتین و Unicode normalization نباید Authorization/Signature canonicalization را مبهم کند.
- شناسه، URL، Hash و کد خطا در RTL visually reorder نشوند؛ Copy مقدار کامل و امن باشد.
- Pending/Unknown/Failed/Finalized معنای متمایز داشته باشند؛ UI از retry مکرر ناشی از پیام مبهم جلوگیری کند.
- UTC برای Event identity و Asia/Tehran/Jalali برای Display از هم تفکیک شوند.
- پیام خطا داده حساب/وجود کاربر/Secret را افشا نکند، اما راه Repair قابلفهم و دسترسپذیر بدهد.
- Screen reader/keyboard/text scaling/contrast روی ورود امن و Error recovery آزموده شود.
- هیچ ادعای قانونی، بانکی یا PSP ایران از این Fixture استخراج نمیشود.
Secret و Sensitive Evidence
Security evidence handling contract classification and minimum necessary fields synthetic/redacted/tokenized fixture identity prohibited secrets/PII/payment/auth material capture tool and local/browser/cache behavior encrypted storage and named access roles report channel and private security route retention/expiry/legal hold authority sharing/export/vendor/subprocessor boundary deletion/verify-absent incident response if evidence itself leaks
Screenshot، HAR، trace، crash dump و Scanner artifact میتوانند Cookie، Token، Header، query، payload و PII داشته باشند. «برای Evidence لازم بود» مجوز Retention نامحدود نیست. برای آزمون Purpose/Retention/Deletion به راهنمای تست حریم خصوصی مراجعه کنید؛ آن صفحه نیز مشاوره حقوقی ایران نیست.
Dependency و Supply-chain Claim
| Signal | سؤال QA–AppSec | تصمیم جدا |
|---|---|---|
| SBOM/package inventory | Artifact واقعاً چه dependency/versionی دارد؟ | presence نه vulnerability verdict |
| Advisory/CVE match | version/exposure/reachability/config چیست؟ | technical triage |
| Signature/provenance | Artifact از pipeline/identity مورد انتظار است؟ | integrity evidence محدود |
| Licence/policy | استفاده/توزیع مجاز و Rule version چیست؟ | legal/policy owner |
| Update | fix چه regression/behavior/change میسازد؟ | QA+security revalidation |
| Unavailable advisory DB | scan invalid/unknown یا fail-open؟ | pipeline validity gate |
| Vendor end-of-life | patch/support/exit plan چیست؟ | architecture/risk decision |
Production Assurance؛ Scanner جای Telemetry نیست
| Claim family | Production signal | Action |
|---|---|---|
| Authorization | denied/allowed anomaly by role/tenant | investigate policy/data without user ranking |
| Authentication/session | failure/revoke/token reuse/session age | contain/revoke/step-up |
| Input/control | reject/error/path distribution | attack vs client bug classification |
| Dependency | inventory/drift/advisory/exposure | triage/update/mitigate |
| Audit | event gap/lag/tamper/parse failure | evidence invalidity/repair |
| Business abuse | duplicate/refund/ledger mismatch | hold/reconcile/investigate |
| Exception | control health/expiry/trigger | reopen/disable/fix |
| Customer signal | support/report/disclosure | secure intake and feedback |
Monitoring نباید به نظارت نامتناسب افراد یا ذخیره Secret تبدیل شود. Signal باید Purpose، denominator، retention، owner و response SLA داشته باشد. نبود Alert اثبات نبود Attack نیست؛ Alert نیز خودکار Incident معتبر نیست.
Incident feedback باید Claim و Test را تغییر دهد
- Timeline، affected build/config/data/actor و Evidence integrity را حفظ کنید.
- Incident را از finding عادی، test artifact leak و false alert تفکیک کنید.
- Contain/eradicate/recover را با Authority عملیات/امنیت اجرا کنید؛ QA فرمانده پیشفرض نیست.
- Exploit path و failed/missing control را به Claimها نگاشت کنید.
- Detection/response/recovery gaps و customer/user burden را ثبت کنید.
- Regression را در پایینترین سطح مفید + integration + operational layer بسازید.
- Rule/fixture/requirement/control/default/architecture را برای حذف class root cause تغییر دهید.
- Exception/suppression مشابه، sibling system و supplier exposure را جستوجو کنید.
- Action effectiveness را پس از Release/Drill مستقل Verify کنید.
Runbook همکاری QA–AppSec در رخداد تست
| رخداد | QA اقدام | AppSec/Security اقدام |
|---|---|---|
| Scanner unknown/error | نتیجه را invalid و build را trace کند | tool/rule/db/credential route را بررسی کند |
| Critical finding | Evidence امن و functional context | validate/severity/containment advice |
| Secret in artifact | انتشار را محدود، reference را حفظ | revoke/rotate/scope/incident |
| Production effect from test | توقف/identity/effect reconciliation | contain/investigate/notify owner |
| Unauthorized probe | خارج Scope را ادامه ندهد | access/security/formal route |
| Disputed false positive | expected/actual/build evidence | independent validation/suppression rule |
| Expired exception | gate status و regression readiness | reassess/reopen/escalate |
Release Gate مشترک
| Gate | Evidence | Stop condition |
|---|---|---|
| Context/claims | versioned assets/threats/claims/owners | Critical flow بیClaim/owner |
| Build identity | source/artifact/config/dependency trace | scan/test روی Artifact دیگر |
| Control evidence | required ladder per critical claim | critical evidence incomplete |
| Pipeline validity | error/timeout/skipped/sentinel semantics | unknown treated as pass |
| Findings | validity/severity/exposure/treatment | critical queue untriaged |
| Suppression | reason/owner/expiry/reopen | blanket/permanent ignore |
| Exception | authority/compensation/monitor/expiry | risk acceptance بیاختیار |
| Secrets/privacy | safe data/evidence/access/retention | active exposure |
| Operations | telemetry/alert/runbook/revoke/recovery | critical control بدون response |
| Decision | quality+security unknowns and dissent | scanner pass used as assurance |
Evidence Packet باید برای تصمیمگیر قابلخواندن باشد؛ ساختار کامل ارائه Scope، denominator، uncertainty، unknown و correction در راهنمای ارائه نتایج تست آمده است.
Evidence Pack انتشار
QA–AppSec release evidence pack release/build/artifact/config/environment identities asset/threat/trust-boundary/claim/control map requirements/standards versions and applicability test authorization and data/evidence handling technique/tool/rule/database/scope/status identities claim verdicts + raw artifact manifest findings/duplicates/false positives/unknowns severity/exposure/business impact and dissent suppressions/exceptions/owners/expiry/monitors remediation/retest/root-cause/class prevention production telemetry/runbook/drill readiness release decision/authority/conditions retention/access/digest/change/reverification triggers
سنجهها؛ Outcome و Flow، نه تعداد Scan
| سؤال | سنجه | Countermetric |
|---|---|---|
| Claimها traceableاند؟ | critical claims with complete map / critical claims | claim scope shrink/expiry debt |
| Pipeline معتبر است؟ | valid runs / intended runs by status | skipped/unknown/fail-open |
| Triage جریان دارد؟ | P50/P95 signal→validated decision by risk | reviewer load/reopen |
| Evidence کامل است؟ | required layers satisfied / claims | artifact freshness/independence gap |
| Exception کنترل است؟ | on-time reviewed/closed / due | auto-renew/residual exposure |
| Control عملیاتی است؟ | drills meeting detect/respond/recover bounds | customer burden/false alerts |
| یادگیری رخ میدهد؟ | class-level actions effectiveness-verified | patch-only recurrence |
| Release بهتر است؟ | decisions with explicit security unknowns | delivery delay/gate bypass |
Vulnerability count، Scan count، Tool coverage، pass rate، mean severity، MTTR یا training completion را KPI فردی نکنید. Opportunity، Scope، tool/rule، disclosure، asset و incentive متفاوتاند و Goodhart میسازند. سنجهها برای اصلاح سیستم Assurance هستند.
نقشها و RACI حداقلی
| نقش | Accountability | Evidence contribution |
|---|---|---|
| Product/business | journey/outcome/priority | business impact/constraints |
| Engineering/control owner | secure implementation/remediation | code/config/design/unit |
| QA | test strategy/oracle/evidence validity | negative/state/integration/regression |
| AppSec | security practice/threat/testing guidance | threat/technique/finding advice |
| Platform/DevOps | paved road/pipeline/environment | artifact/policy/tool validity |
| Operations/SOC | monitor/response/recovery | telemetry/alert/drill/incident |
| Privacy/Legal/Compliance | applicable obligations/advice | requirement/assessment/exception input |
| Risk/release authority | accept/hold/release decision | signed conditions/expiry |
| Independent assessor | bounded challenge | scope-limited findings/limitations |
برنامه ۳۰روزه ساخت Interface
| بازه | خروجی | Exit criteria |
|---|---|---|
| روز ۱–۵ | یک Critical journey، نقش/authority و baseline incident/finding | مالک و non-goal روشن |
| روز ۶–۱۰ | Threat/claim/control/evidence map نسخهدار | پنج Claim بحرانی ابطالپذیر |
| روز ۱۱–۱۵ | pipeline signal contract و validity fault tests | error/skipped/stale هرگز pass نیست |
| روز ۱۶–۲۰ | manual/control/operational probes + triage calibration | Finding state/authority/SLA روشن |
| روز ۲۱–۲۵ | exception/suppression/release packet tabletop | expiry/reopen/monitor آزموده |
| روز ۲۶–۳۰ | incident drill، metrics، retrospective و scale/adapt/stop | یک Claim از incident تا regression بسته |
۲۰ ضدالگوی همکاری QA و AppSec
- گفتن «امن باشد» بدون Claim و Owner.
- تبدیل QA به نگهبان/هکر اجباری.
- Shared responsibility بدون Decision authority.
- اجرای Test تهاجمی بدون Authorization.
- استفاده از Top ۱۰ بهعنوان کل Test plan.
- ارجاع ASVS بدون Version/ID/applicability.
- برابرگرفتن Scanner alert با Vulnerability معتبر.
- برابرگرفتن Job سبز با نبود ضعف.
- تبدیل timeout/error/skipped به Pass.
- اندازهگیری Security با تعداد Scan/Finding.
- Suppression بیOwner/Expiry/Review.
- یکیدانستن Severity، Priority و Risk.
- Risk acceptance توسط QA/Developer بدون Authority.
- Shift-left بهانه حذف Independent testing.
- Test فقط Preventive control و حذف detection/recovery.
- Evidence حاوی Secret/PII در Ticket عمومی.
- Pen test point-in-time بهعنوان Certification دائمی.
- Patch مورد بدون root-cause/class regression.
- امنسازی با بار اضافی روی مشتری/کاربر.
- Incident learning بدون تغییر Claim/Test/Control.
چکلیست نهایی QA–AppSec
- □ Critical journey/asset/data/trust boundary مشخص است.
- □ Threat/abuse به Claim ابطالپذیر و نسخهدار تبدیل شده است.
- □ Requirement/source/version/applicability trace دارد.
- □ Control preventive/detective/corrective owner دارد.
- □ QA/AppSec/Product/Engineering/Operations authority جداست.
- □ Test تهاجمی Scope/مجوز/Stop/cleanup دارد.
- □ Evidence ladder متناسب با Risk تعریف شده است.
- □ Build/config/dependency/tool/rule identities ثبتاند.
- □ Pipeline pass/error/timeout/skipped semantics آزموده شدهاند.
- □ Sentinel/known-bad یا راه کشف false negative داریم.
- □ Finding/duplicate/unknown/false-positive state روشن است.
- □ Severity/exposure/business impact/priority جدا ارزیابی میشوند.
- □ Suppression و Exception owner/expiry/reopen/monitor دارند.
- □ Secret/PII در Fixture/Evidence/Report نیست.
- □ Manual abuse و business logic برای Critical flow پوشش دارند.
- □ Pen test مستقل Scope-limited جایگاه مناسب دارد.
- □ Release Packet، unknown/limitations/dissent را نشان میدهد.
- □ Production telemetry و incident runbook Claim-driven هستند.
- □ Incident به regression و class-level prevention برمیگردد.
- □ Metrics سیستم را اصلاح میکنند، نه فرد را رتبهبندی.
جمعبندی؛ Security را به Evidence قابلتصمیم تبدیل کنید
همکاری QA و AppSec زمانی مفید است که دیوار اطلاعات را بردارد، نه مرز تخصص و Authority را. QA لازم نیست Pen tester شود؛ باید بتواند Claim را بفهمد، Oracle و negative/state path بسازد، Evidence معتبر جمع کند و Unknown را پنهان نکند. AppSec نیز باید Threat/Control/Technique را به زبانی قابلاجرا و قابلتریاژ تبدیل کند.
از یک Journey بحرانی شروع کنید، پنج Claim بنویسید و برای هرکدام Evidence ladder بسازید. سپس عمداً Scanner را با target unreachable یا rule disabled خراب کنید و ببینید آیا Pipeline Unknown را Pass مینامد. بلوغ واقعی تعداد ابزار نیست؛ توان تصمیمگیری صادقانه درباره Claim، Finding، Exception و اثر Production است.
پرسشهای متداول همکاری QA و AppSec
۱. آیا هر مهندس QA باید تست امنیت انجام دهد؟
هر QA باید Claimهای امنیتی مرتبط با Flow، داده، نقش و State را بفهمد و Evidence محدوده خود را درست بسازد؛ اما DAST فعال، abuse عمیق، Pen test یا Exploit به Capability و Authorization نیاز دارد. سازمان نباید کمبود AppSec را با انتقال نامحدود مسئولیت به QA پنهان کند.
۲. تفاوت Security Claim با Security Test چیست؟
Claim گزاره نسخهدار درباره Asset/Actor/Threat/رفتار مورد انتظار و Scope است؛ Test یک Probe و Oracle برای Challenge بخشی از آن است. یک Claim معمولاً به چند Evidence layer نیاز دارد و یک Test ممکن است چند Claim را لمس کند. Test سبز ادعای مطلق امنیت نمیسازد.
۳. آیا Passشدن SAST، SCA و DAST برای Release کافی است؟
خیر. ابتدا باید مطمئن شوید ابزار/Rule/Target/Build/Database/credential و status معتبر بودهاند؛ سپس Blind spotهای Authorization، Business logic، configuration، operation و manual abuse را نسبت به Claim ببینید. سه Job سبز میتوانند یک Evidence بحرانی گمشده را پنهان کنند.
۴. QA و AppSec بر سر Severity اختلاف دارند؛ چه کنیم؟
Observation، reproducibility، technical impact، exploitability، exposure، business impact و uncertainty را جدا ثبت کنید. Authority از پیشتعریفشده Severity/Risk/Priority تصمیم میگیرد و dissent در Packet میماند. اختلاف را با رأی اکثریت، مقام شغلی یا امتیاز Scanner حل نکنید.
۵. Shift-left یعنی Pen test دیگر لازم نیست؟
خیر. Shift-left Feedback را زودتر میکند، اما Independent/manual testing میتواند Attack chain و فرضهای مشترک تیم را Challenge کند. عمق و زمان Pen test بر اساس Risk است؛ خودش نیز Point-in-time و Scope-limited است و جای Secure design، verification مداوم و monitoring را نمیگیرد.
