امنیت، هویت، استقرار و تاب‌آوری · فصل ۳ — Retention، TLS، Supply Chain و Verification Baseline · 93
OWASP ASVS و NIST SSDF به‌عنوان Verification Baseline
ASVS/SSDF را به checklist یکسان یا badge نهایی تبدیل می‌کند و version/applicability/evidence را جدا ثبت نمی‌کند. می‌تواند برای «OWASP ASVS و NIST SSDF به‌عنوان Verification Baseline» threat/trust boundary، کنترل و evidence را در یک سناریوی محدود تعریف و justify کند.
Use OWASP ASVS and NIST SSDF as a Verification Baseline — en-US
خلاصهٔ درس
ASVS/SSDF را به checklist یکسان یا badge نهایی تبدیل می‌کند و version/applicability/evidence را جدا ثبت نمی‌کند.
می‌تواند برای «OWASP ASVS و NIST SSDF به‌عنوان Verification Baseline» threat/trust boundary، کنترل و evidence را در یک سناریوی محدود تعریف و justify کند.
خروجی این درس
می‌تواند برای «OWASP ASVS و NIST SSDF به‌عنوان Verification Baseline» threat/trust boundary، کنترل و evidence را در یک سناریوی محدود تعریف و justify کند.
_Locale: fa-IR · Lesson: SEC-016 · Public order: 93_
خروجی و artifact کاری
این درس برای ساختن رکورد رهگیری baseline راستی‌آزمایی امنیت نسخه ۱ است: یک artifact تصمیم که مشاهده، فرض، محدودیت و evidence موردنیاز را از هم جدا می‌کند. هدف حفظ یک مدل قابل‌انتقال است، نه حفظ‌کردن نام ابزارها.
می‌تواند برای «OWASP ASVS و NIST SSDF به‌عنوان Verification Baseline» threat/trust boundary، کنترل و evidence را در یک سناریوی محدود تعریف و justify کند.
مدل مرزی
OWASP ASVS و NIST SSDF زمانی کنار هم مفیدند که scope متفاوت آن‌ها حفظ شود. ASVS requirementهای verification امنیت application را فراهم می‌کند و SSDF practiceهای توسعه امن software را سازمان می‌دهد. این دو checklist قابل جایگزینی نیستند و به‌تنهایی certification نمی‌سازند. baseline قابل دفاع، version/status منبع، applicability، evidence، rowهای open و residual risk را صریح نگه می‌دارد.
در هر بخش سه برچسب نگه دارید: «مشاهده‌شده»، «استنباط محدود» و «نیازمند بررسی». اگر evidence در دسترس نیست، نتیجه را unknown ثبت کنید؛ نام ابزار یا pass شدن یک happy path جای evidence را نمی‌گیرد.
1. منبع و status را pin کنید
requirement identifier بدون version ASVS evidence پایدار نیست. material نهایی و draft در SSDF باید دقیق label شود؛ آگاهی از draft اجازه معرفی آن به‌عنوان authority نهایی نیست.
2. Scopeها را جدا نگه دارید
rowهای ASVS درباره verification کنترل application هستند و rowهای SSDF درباره اجرای practice توسعه امن. crosswalk مفید evidence را link می‌کند، اما mapping یک‌به‌یک اختراع نمی‌کند.
3. Applicability دلیل می‌خواهد
PASS، FAIL، OPEN و NOT_APPLICABLE تصمیم هستند. N/A بدون rationale مبتنی بر threat، architecture یا process یک row بسته‌شده محسوب نمی‌شود.
4. Evidence باید قابل یافتن و متصل به build باشد
هر row باید test، review، artifact یا process record دقیق و release/build مرتبط را معرفی کند. dashboard سبز عمومی یا report قدیمی کافی نیست.
5. تکمیل baseline certification نیست
مجموعه انتخاب‌شده می‌تواند در threat/product boundary اعلام‌شده به release decision کمک کند؛ امنیت یا compliance همگانی را ثابت نمی‌کند.
روش پنج‌مرحله‌ای
- service boundary مصنوعی، threat summary، release identity و تاریخ evidence را freeze کنید.
- version ASVS و requirementهای انتخابی را ثبت و version/status publication مربوط به SSDF را جدا نگه دارید.
- برای هر row پیش از PASS/FAIL/OPEN/N/A، applicability rationale بنویسید.
- evidence locator دقیق اضافه و اتصال آن به همان build و behavior مورد نظر را verify کنید.
- version، publication status، locator و N/A rationale را mutate کنید؛ gate باید fail-closed و gap را حفظ کند.
مثال حل‌شده
یک account service مصنوعی دو reference از ASVS 5.0.0 و دو practice از SSDF 1.1 انتخاب می‌کند. row اول به authentication test متصل به build اشاره و PASS می‌شود؛ row دوم evidence ندارد و OPEN می‌ماند. یک practice SSDF به review record وصل است. material نسخه 1.2 فقط به‌عنوان draft awareness ثبت می‌شود و baseline نهایی را جایگزین نمی‌کند. حذف version، معرفی draft به‌عنوان final، حذف locator و N/A بدون rationale همگی رد می‌شوند.
ماتریس تصمیم و evidence
| موضوع | مرز/مالک | evidence | تصمیم یا محدودیت |
|---|---|---|---|
| control در ASVS 5.0.0 | applicable | auth test متصل به build | PASS در boundary انتخابی |
| control در ASVS 5.0.0 | applicable | بدون evidence | OPEN |
| practice در SSDF 1.1 | applicable | review/process record | PASS فقط برای process evidence |
| آگاهی از draft نسخه 1.2 | authority نهایی نیست | رکورد publication status | INFORMATIONAL |
| row نوع N/A | threat boundary متفاوت | rationale مکتوب | N/A با residual note |
خطاهای محتمل و روش اصلاح
- فرض mapping یک‌به‌یک و قابل جایگزینی میان ASVS و SSDF
- تلقی baseline انتخابی به‌عنوان certification امنیت
- معرفی draft نسخه SSDF به‌عنوان guidance نهایی
- اعمال یکسان همه requirementها بدون applicability analysis
برای هر مورد، ادعا را محدود کنید، یک counterexample بسازید و بنویسید کدام مشاهده می‌تواند آن را تأیید یا رد کند.
تمرین انتقال
سناریو را طوری تغییر دهید که یکی از فرض‌های مثال دیگر برقرار نباشد. بدون کپی‌کردن تصمیم قبلی، رکورد رهگیری baseline راستی‌آزمایی امنیت نسخه ۱ را دوباره بسازید؛ سپس تفاوت decision rule و تفاوت دادهٔ ورودی را توضیح دهید.
این درس چه چیزی را ثابت نمی‌کند
این درس certification، تضمین production یا پوشش همه implementationها را ادعا نمی‌کند. نتیجه فقط در مرز سناریو، sourceهای تاریخ‌دار و observationهای ثبت‌شده معتبر است.
خودسنجی
- [ ] آیا مسئولیت‌ها را از نام framework یا tool جدا کرده‌ام؟
- [ ] آیا دست‌کم یک failure probe و نتیجه موردانتظار آن را نوشته‌ام؟
- [ ] آیا fact، inference و design choice از هم مشخص‌اند؟
- [ ] آیا non-claim و evidence گمشده را ثبت کرده‌ام؟
- [ ] آیا transfer را روی context تغییرکرده و بدون پاسخ آماده انجام داده‌ام؟
منابع و مرز تازگی
sourceها در 2026-09-19 طبق Bible منجمدشده مرور شده‌اند. تاریخ review_due یک trigger برای بازبینی نسخه‌ای است؛ هیچ بسته‌ای نباید درجا و بدون نسخه جدید تغییر کند.
- OWASP-ASVS — Used for ASVS purpose, current stable version 5.0.0, and guidance to version-pin requirement identifiers. (https://owasp.org/www-project-application-security-verification-standard/; review: 2026-10-02)
- NIST-SSDF-11 — Used for final SSDF Version 1.1 scope as high-level secure software development practices. (https://csrc.nist.gov/pubs/sp/800/218/final; review: 2026-10-02)
- NIST-SSDF-12-IPD — Used only to record that SSDF Version 1.2 is an Initial Public Draft, not final authority, at retrieval time. (https://csrc.nist.gov/pubs/sp/800/218/r1/ipd; review: 2026-10-02)
- NIST-SSDF-PUBS — Used to distinguish the project publication status: 1.1 final and 1.2 draft at retrieval time. (https://csrc.nist.gov/projects/ssdf/publications; review: 2026-10-02)
ارزیابی
پاسخ‌نامه‌ی این درس در بسته‌ی آموزش وجود ندارد؛ خودت جواب بده و صادقانه علامت بزن. «نیاز به مرور» درس را به صف تکرار می‌فرستد.
SEC-016-S1 retrieval
SEC-016-S2 application
SEC-016-S3 diagnosis
SEC-016-S4 decision
SEC-016-S5 transfer
ملاک‌های ارزیابی (rubric)
| Dimension | Critical | Sufficient evidence |
|---|---|---|
| bounded security model correctness | yes | Explanation preserves the owned trust/control boundary and declared assumptions. |
| evidence quality | yes | Positive and negative observations are traceable and separated from inference. |
| scope discipline | yes | Adjacent security outcomes and unsupported assurance claims are deferred. |
| transfer independence | yes | Changed-context task is solved without decisive scaffold. |
A submission passes only when every critical dimension is sufficient and the learner states missing evidence honestly. AI suggestions are not observed evidence; the learner remains accountable for the final bounded judgment.
منابع و تازگی
مطالعهٔ موارد (case studies)
فایل‌های آزمایشگاه
با fixture امن محلی، رکورد رهگیری baseline راستی‌آزمایی امنیت نسخه ۱ را بسازید. ابتدا prediction را بنویسید؛ سپس baseline و failure probeهای اعلام‌شده را ثبت کنید و observation مثبت و منفی را نگه دارید. transfer را بدون کپی تصمیم مثال انجام دهید.
starter عمداً classification یا risk decision نهایی را انتخاب نمی‌کند. evaluate_record.py و evidence template را تکمیل کنید. اجرای python3 ../run_checks.py فقط environment و شکل fileها را بررسی می‌کند و تصمیم محتوایی شما را grade نمی‌کند.
مرز ایمنی: Synthetic defensive environment only; no real credentials, production systems, external targets, exploitation, vulnerability scanning or covert access.
رسانه و اسلایدهای درس
فایل‌های آموزشی (دانلود)