DevSecOps چیست؟ مدل عملیاتی، کنترل و شواهد توسعه امن

اگر هر Finding با برچسب «High» را بدون Context مانع Build کنید، احتمالاً تیم بعد از چند روز Gate را دور می‌زند. اگر هیچ‌چیز را متوقف نکنید، Pipeline فقط یک دستگاه تولید گزارش است. DevSecOps خوب میان این دو افراط قرار ندارد؛ یک مدل عملیاتی است که برای هر ریسک، کنترل قابل‌استفاده، مالک پاسخ‌گو و شاهد قابل‌راستی‌آزمایی می‌سازد.

این راهنما DevSecOps را از شعار «امنیت مسئولیت همه است» به سیستم اجرایی تبدیل می‌کند: Product و Service inventory، Risk tier، Security requirements، Threat modeling، Paved road، اسکن هدفمند، امنیت زنجیره تأمین، مدیریت یافته و استثنا، شواهد، Telemetry، Runbook و برنامه ۹۰روزه. هدف، بیشترکردن ابزار یا Finding نیست؛ کاهش ریسک قابل‌سوءاستفاده بدون تبدیل امنیت به صف انتظار مبهم است.

DevSecOps چیست؟

DevSecOps شیوه‌ای برای ادغام مستمر امنیت در تصمیم‌های محصول، طراحی، توسعه، Build، Release و عملیات است. «Sec» یک Stage تازه میان Dev و Ops نیست؛ مجموعه‌ای از Capabilityها و Feedback loopهاست که نزدیک به زمان و محل تصمیم عمل می‌کنند. بعضی کنترل‌ها پیش از Commit، بعضی هنگام Build، بعضی پیش از Deploy و بعضی فقط در Runtime یا Incident معنا دارند.

چارچوب SSDF نسخه ۱.۱ در NIST SP ۸۰۰-۲۱۸ چهار گروه Practice دارد: آماده‌سازی سازمان، حفاظت از نرم‌افزار، تولید نرم‌افزار خوب‌امن‌شده و پاسخ به آسیب‌پذیری‌ها. این ساختار یادآوری می‌کند که Secure development فقط SAST یا Pipeline نیست؛ محیط توسعه، Provenance، Requirements و Vulnerability response هم جزو سیستم‌اند.

Intent و مرز این مقاله

کلیدواژه اصلی «DevSecOps چیست» و «پیاده‌سازی DevSecOps» است. کلیدواژه‌های مکمل شامل فرهنگ DevSecOps، ابزار DevSecOps، Shift left، Secure SDLC، Security champions، SAST/SCA/DAST، SBOM، SLSA، Policy as code و شاخص‌های امنیت نرم‌افزارند. نیت خواننده معمولاً اجرایی یا مدیریتی است: از کجا شروع کنیم، چه چیزی را اجباری کنیم و چطور اثر را بسنجیم؟

این صفحه مالک Operating model و برنامه سازمانی DevSecOps است. جزئیات Build once، Artifact، Provenance و Progressive delivery در راهنمای CI/CD امن عمیق‌تر آمده و راهنمای امنیت API و OWASP مالک Threat model و کنترل‌های REST/GraphQL/Webhook است.

چهار سوءبرداشت رایج

ادعای ثابت «رفع باگ در Production صد برابر گران‌تر است» مبنای مناسبی برای بودجه نیست. هزینه به نوع نقص، معماری، زمان کشف، داده در معرض، Migration و Incident بستگی دارد. Business case را با سناریوی خود، Frequency، Impact و هزینه کنترل بسازید؛ برای مدل‌سازی مالی به راهنمای هزینه نقض داده و بودجه امنیت مراجعه کنید.

اصل‌های یک مدل DevSecOps قابل‌اتکا

1. Outcome پیش از Tool: کنترل باید ریسک یا Failure mode معینی را کاهش دهد.
2. Risk-tiered: خدمت پرداخت و سایت محتوایی یک Control profile ندارند.
3. Secure by default: مسیر عادی توسعه باید امن‌ترین مسیر عملی باشد.
4. Fast feedback: Finding نزدیک به Change، با توضیح و Fix path برسد.
5. Evidence by design: کنترل هنگام اجرا شاهد Machine-readable تولید کند.
6. Exception is a state: Waiver مالک، جبران، انقضا و Revalidation دارد.
7. Production closes the loop: Incident، Exploit و Drift به Backlog طراحی برگردند.
8. Developer experience matters: کنترل دشوار به Shadow workflow و Bypass می‌انجامد.

راهنمای CISA درباره Secure by Design بر مالکیت نتیجه امنیت مشتری، شفافیت/پاسخ‌گویی و رهبری سازمانی تأکید می‌کند. این نگاه با «تنظیم امن را به مشتری بسپاریم» یا «Security team بعداً بررسی کند» متفاوت است.

چارچوب را به‌عنوان نقشه استفاده کنید، نه گواهی

OWASP SAMM 2 بلوغ Software assurance را در پنج Business function می‌بیند: Governance، Design، Implementation، Verification و Operations. سه سطح بلوغ و سنجش Coverage/Quality برای برنامه Roadmap مفیدند؛ Score بالا بدون Evidence واقعی یا متناسب‌نبودن با Risk، هدف نیست.

OWASP ASVS 5.0 که ۳۰ مه ۲۰۲۵ منتشر شده، می‌تواند منبع Requirement و Acceptance امنیت اپلیکیشن باشد. ASVS را کامل و یکسان روی هر سیستم کپی نکنید؛ Scope، سطح Risk و معماری تعیین می‌کنند کدام الزام برای کدام Component و Journey کاربرد دارد.

اول Inventory قابل‌اعتماد بسازید

نمی‌توان کنترل، Patch یا Incident response را روی چیزی که نمی‌شناسید اعمال کرد. Catalog حداقلی باید Product/Service، Owner، Repository، Pipeline، Artifact، Runtime، Domain، Data class، Internet exposure، Dependency و Critical journey را به هم وصل کند. Spreadsheet ابتدایی قابل‌قبول است، اگر Update و Reconciliation مالک داشته باشد.

Repository count را با Runtime route، Registry، DNS/Cloud account و Telemetry تطبیق دهید. Repo آرشیوشده ممکن است هنوز در Production اجرا شود؛ Service فعال ممکن است Source یا Owner نامشخص داشته باشد. Coverage denominator از همین Catalog می‌آید.

Risk tier کنترل را تعیین می‌کند

شدت برنامه را بر اساس Brand یا اندازه تیم نسازید. یک Service کوچک احراز هویت ممکن است از یک Portal بزرگ محتوایی پرریسک‌تر باشد. Tier را با Impact و Exposure قابل‌توضیح تعیین کنید.

برای هر Tier یک Minimum control profile تعریف کنید، اما اجازه دهید Threat model کنترل اضافه یا Applicability را اصلاح کند. Tier «بالا» به معنای Block کردن همه Findingها نیست؛ به معنای Requirement، Evidence و Response قوی‌تر است.

Control contract؛ Policy را قابل‌اجرا کنید

عبارت «SAST در همه پروژه‌ها اجباری است» Contract ناقص است. Control contract باید دقیق کند چه ریسکی، کجا، با چه Trigger، Configuration، Threshold، Owner، Evidence و Failure policy کنترل می‌شود.

Control ID: APP-SAST-01
Risk: injection and unsafe data flow in changed application code
Scope: Tier 1/2 repositories with supported languages
Trigger: pull request + default-branch scheduled full scan
Configuration: versioned ruleset; generated/vendor/test exclusions documented
Gate: confirmed new finding in applicable high-risk rule family
Evidence: tool/ruleset version, commit, paths, result, suppression/exception refs
Failure: fail-open only for scanner outage under time-boxed incident rule
Owner: AppSec platform; remediation owner: service team
Exception: risk owner, compensating control, expiry and review

این Contract اجازه می‌دهد Coverage، کیفیت و Failure را بسنجید. اگر Tool یک زبان را پشتیبانی نمی‌کند، «اسکن سبز» شاهد Coverage نیست؛ Applicability باید Unknown/Not covered را نشان دهد.

Security requirements را از Threat و Context بسازید

«همه داده‌ها AES-۲۵۶» یک Requirement قابل‌قبول عمومی نیست؛ معلوم نمی‌کند چه داده‌ای، در برابر کدام تهدید، با چه Key lifecycle و در کدام Trust boundary محافظت می‌شود. Requirement باید رفتار قابل‌تست تعریف کند: Subject، Resource، Action، Context، Failure و Evidence.

برای Requirement دقیق Endpoint و تست‌های منفی، چک‌لیست Hardening امنیت API را ببینید.

Threat modeling باید با تغییر سیستم زنده بماند

راهنمای Threat Modeling در OWASP چهار پرسش ساده را محور قرار می‌دهد: چه می‌سازیم، چه چیز ممکن است بد پیش برود، چه می‌کنیم و آیا کار کافی بوده است؟ Threat model یک جلسه بزرگ سالانه نیست؛ برای تغییر Trust boundary، Data flow، identity، Third party و Privileged action باید به‌روزرسانی شود.

1. System/Trust/Data/Actor را با Diagram یا مدل ساده مشخص کنید.
2. Abuse case و Failure را برای Critical journey شناسایی کنید.
3. Risk response را Mitigate/Eliminate/Transfer/Accept و مالک‌دار کنید.
4. Mitigation را به Requirement، Code/Config، Test و Telemetry وصل کنید.
5. فرض‌ها و Residual risk را ثبت و Trigger بازبینی را تعیین کنید.

Template بدون Workshop کوتاه با Developer/Operator/Product می‌تواند Diagram زیبا اما بی‌اثر بسازد. از یک Flow حساس آغاز کنید؛ کیفیت تصمیم از تعداد Threatهای فهرست‌شده مهم‌تر است.

«مسئولیت مشترک» را به RACI تبدیل کنید

Security Champion چه کاری انجام می‌دهد؟

Champion رابط و تسهیل‌گر داخل تیم است: Requirement را قابل‌فهم می‌کند، Threat modeling را راه می‌اندازد، Feedback Tool را جمع می‌کند و Finding الگووار را Escalate می‌کند. Champion Security gatekeeper، بازرس پاره‌وقت بدون ظرفیت یا جایگزین AppSec نیست. زمان، آموزش، Community و مسیر رشد باید رسمی باشند.

Paved road؛ امنیت را به مسیر کم‌اصطکاک تبدیل کنید

Golden path مجموعه Template و Capability پشتیبانی‌شده است: Repository baseline، Pipeline، Secret access، Logging، dependency update، image build، deployment و telemetry. تیم باید بتواند سرویس استاندارد را با Default امن بسازد، نه اینکه ده Ticket و Wiki قدیمی را دنبال کند.

Escape hatch لازم است، اما Usage آن Signal محصول داخلی است. اگر بسیاری از تیم‌ها از Path خارج می‌شوند، مشکل را فقط «عدم انطباق» ننامید؛ شاید Path نیاز واقعی، زبان یا Runtime را پوشش نمی‌دهد.

محیط توسعه و Control plane را فراموش نکنید

مهاجم می‌تواند به‌جای اپلیکیشن، حساب توسعه‌دهنده، SCM، CI runner، Registry یا Secret store را هدف بگیرد. کنترل‌های اپلیکیشن برای Artifactی که در Pipeline دست‌کاری شده کافی نیستند.

• هویت Human و Workload جدا، MFA مقاوم متناسب و Least privilege باشند.
• Tokenهای بلندعمر با Credential کوتاه‌عمر/فدره جایگزین و Scope محدود شوند.
• Branch protection، Review، change history و recovery account آزموده شوند.
• Runner موقت یا پاک‌سازی‌شونده، network egress محدود و محیط Build جدا باشد.
• Secret در Log، Artifact، Cache، PR، Fork و Debug dump ظاهر نشود.
• Admin action و policy change audit و Alert متناسب داشته باشند.
• Backup تنظیمات حیاتی و بازیابی SCM/Registry/Pipeline تمرین شود.

Feedback محلی: IDE، Lint و Pre-commit

Control سریع و Deterministic را نزدیک Developer قرار دهید: secret pattern، formatting امن، dependency policy اولیه و تست واحد امنیتی. Hook محلی را تنها Enforcement ندانید؛ قابل‌عبور است و محیط همه یکسان نیست. همان Rule مهم باید در Server-side CI نیز اجرا شود.

Feedback خوب مسیر فایل/خط، Risk، Data flow یا نمونه امن و روش Suppression معتبر دارد. پیام «CWE-۷۹ detected» بدون Context یا Fix، Developer را به Ignore سوق می‌دهد. زمان اجرا و False positive را مانند SLI یک محصول داخلی بسنجید.

SAST؛ Coverage و Tuning مهم‌تر از تعداد Finding

SAST می‌تواند Pattern و برخی Data flowهای ناامن را بدون اجرای برنامه پیدا کند؛ اما Business logic، Runtime config، Authorization contextual و همه Frameworkها را کامل نمی‌بیند. «Scan passed» با «کد امن است» برابر نیست.

SCA، SBOM و Vulnerability intelligence

SCA فقط یافتن CVE نیست. باید Component مستقیم/Transitive، Version واقعی Artifact، License/maintenance signal، Advisory source و محل مصرف را بدانید. CVSS به‌تنهایی اولویت نیست؛ Exposure، Reachability، Exploit maturity، Asset criticality و Compensating control مهم‌اند.

1. Manifest و Lockfile را enforce و dependency resolution را تکرارپذیر کنید.
2. SBOM را از Artifact ساخته‌شده تولید و با Digest پیوند دهید.
3. Advisory intake را مداوم اجرا کنید؛ اسکن زمان Build Finding بعدی را نمی‌بیند.
4. Component affected را در Portfolio پیدا و Context سرویس را اضافه کنید.
5. Fix version را با Compatibility، Regression و Source معتبر بررسی کنید.
6. اگر Not affected است، VEX/Justification نسخه‌دار و قابل‌بازبینی نگه دارید.
7. Remediation را Deploy و Runtime digest را تأیید کنید؛ merge شدن Fix کافی نیست.

Package بدون CVE می‌تواند مخرب، Typosquat یا تازه تصاحب‌شده باشد. Source/maintainer/release behavior، Registry namespace، install script و provenance نیز بخشی از Supply-chain risk هستند.

Secret scanning؛ کشف بدون Revocation کافی نیست

Secret scanner باید قبل از Commit Feedback دهد و Repository history، Artifact و Log را نیز پوشش دهد. وقتی Secret پیدا شد، حذف از فایل یا Force-push درمان کامل نیست؛ آن Credential را Compromised فرض کنید.

Detect → validate exposure without replaying harm
Contain → revoke/rotate credential and block active use
Scope → repository/history/log/artifact/fork/consumer access
Recover → issue least-privilege replacement through secret manager
Verify → old credential fails; services healthy
Prevent → identity federation, shorter lifetime, guardrail and training

IaC، Container و Kubernetes

IaC scanner Misconfigurationهای شناخته‌شده را زود نشان می‌دهد، اما Effective permission، Runtime mutation و Cloud control plane را کامل نمی‌بیند. Static manifest را با plan/effective config، Admission policy و Runtime inventory تطبیق دهید.

• Base image حداقلی، نسخه/Digest مشخص، Patch cadence و provenance داشته باشد.
• Image scan هم OS و هم Application component را ببیند؛ Running digest را Join کنید.
• Root، privilege، capability، writable filesystem، host mount و network policy Risk-specific باشند.
• IaC module approved و تغییر IAM/Network/Encryption/Logging Review قوی‌تر بگیرد.
• Drift میان Git، Cloud و Cluster کشف و مسیر اصلاح/پذیرش داشته باشد.

برای مرزهای Control plane، Workload، Image و عملیات، راهنمای Kubernetes و Containerization را ببینید.

پشته Verification را لایه‌ای بسازید

DAST «مهاجم واقعی» را کامل شبیه‌سازی نمی‌کند و RASP «سپر قطعی» نیست. Coverage و Failure mode هر ابزار را بسنجید. تست نفوذ مستقل برای Risk بالا باقی می‌ماند؛ Scope، Evidence و Retest را در راهنمای تست نفوذ وب‌اپلیکیشن ببینید.

زنجیره تأمین؛ از Source تا Artifact قابل‌تأیید

در Snapshot ۱۰ اوت ۲۰۲۶، SLSA 1.2 نسخه Approved جاری است و Source/Build track و قالب‌های Attestation از جمله Provenance را تعریف می‌کند. هدف این نیست که نام SLSA روی Slide بیاید؛ Consumer باید Artifact و Provenance را واقعاً Verify کند.

OpenSSF Scorecard می‌تواند Signalهایی درباره Practiceهای پروژه متن‌باز بدهد، اما Score، ارزیابی کامل Supplier یا تضمین سالم‌بودن Package نیست. Evidence را با Criticality و Use case خود ترکیب کنید.

Gate را Risk-based و Failure-aware طراحی کنید

Gate خوب فقط Threshold ندارد؛ Outage policy، Baseline، New-vs-existing، Exception و Recovery دارد. اگر scanner در دسترس نبود، انتخاب fail-open/fail-closed باید به Tier و نوع Change وابسته باشد، نه رفتار اتفاقی Pipeline.

هدف Gate توقف Change پرریسک است، نه اثبات امن‌بودن Release. Gate coverage و bypass را Monitor کنید و SLA خود Gate را داشته باشید؛ Security tool کند می‌تواند Lead time را بدون کاهش Risk بالا ببرد.

Finding lifecycle؛ Scan نتیجه نیست

1. Ingest: Source، Tool/ruleset، Artifact/commit و Timestamp ثبت شود.
2. Normalize/Deduplicate: یک Root cause از چند scanner چند Ticket نسازد.
3. Contextualize: Asset/Tier/Exposure/Reachability/Exploit/Control اضافه شود.
4. Assign: Owner و پاسخ اولیه با SLA روشن باشد.
5. Decide: Fix/Mitigate/Accept/Not affected/False positive با Evidence.
6. Remediate: Code/Config/Dependency/Architecture تغییر کند.
7. Verify: Test و Runtime version، نه صرفاً Ticket resolution.
8. Learn: Root cause، کنترل پیشگیرانه و Regression test به سیستم برگردد.

Security debt را Portfolio کنید

Baseline کردن Finding قدیمی به معنای بخشیدن آن نیست. Debt را بر اساس Theme و Root cause گروه‌بندی کنید: framework قدیمی، auth library مشترک، secret pattern، unsafe serializer یا نبود test fixture. Fix پلتفرمی می‌تواند صدها Ticket را بهتر از Remediation تک‌موردی ببندد.

Age تنها معیار نیست؛ Expected loss، Change frequency، blast radius، exploitability و هزینه Migration را بسنجید. روش اداره Backlog و Interest بدهی در راهنمای مدیریت بدهی فنی آمده است.

استثنا را قابل‌دیدن و منقضی کنید

Exception بخشی مشروع از Risk management است، نه راه فرار و نه ممنوعیت مطلق. نبود استثنا رسمی معمولاً استثنای مخفی می‌سازد.

Exception: scope/control/finding/rule version
Reason: why remediation is currently infeasible
Risk: scenario, likelihood/impact, affected users/data
Compensating controls: what reduces risk now; evidence
Owner: accountable business/service owner
Expiry: date or release; no permanent default
Trigger: exploit/change/incident invalidates exception early
Plan: remediation milestone and verification
Approval: proportional to risk; immutable audit trail

Expiry بدون Reminder و Escalation فقط تاریخ تزئینی است. Extension باید شواهد تازه و تصمیم دوباره بخواهد. تعداد Exception ممکن است Signal ضعف Paved road یا Requirement نامتناسب باشد.

Deploy و Runtime؛ Shift right را جدی بگیرید

امنیت در Merge پایان نمی‌یابد. Artifact مجاز باید با Configuration و Identity درست، روی محیط درست و با Rollout قابل‌بازگشت اجرا شود. Runtime telemetry نشان می‌دهد فرض طراحی در Production چگونه رفتار می‌کند.

• Artifact/Digest و Attestation پیش از Deploy Verify شود.
• Config/secret/reference محیط با Policy و Drift check کنترل شود.
• Canary و progressive rollout هم Security signal و هم Reliability را ببیند.
• Rollback با Schema/Data compatibility و Credential revocation هماهنگ باشد.
• Admin/privileged action، auth failure، policy denial و data export Event داشته باشند.
• Runtime protection و WAF را Compensating control بدانید، نه رفع Root cause.
• Incident و Attack pattern به Threat model، test و rule pack برگردند.

Security observability با Telemetry کمینه

ثبت همه Request/Response می‌تواند Secret و PII بسازد. Event schema را برای تصمیم‌های امنیتی طراحی کنید: Actor/Subject، Action، Target، Policy/version، Outcome، reason code، correlation ID و Time؛ Payload حساس را Redact یا اصلاً جمع نکنید.

برای SLO و Alert، راهنمای Observability و مانیتورینگ مرجع زمینه‌ای است. Signal امنیتی باید Runbook، Owner، Severity و Retention داشته باشد؛ Alert بدون Action به فرسودگی منجر می‌شود.

Vulnerability disclosure و پاسخ

برنامه DevSecOps باید ورودی خارج سازمان را هم بپذیرد: پژوهشگر، مشتری، Supplier یا Advisory. کانال امن، Scope، تأیید دریافت، Triage، Coordination، Fix/mitigation، Retest و Communication تعریف کنید. Finding خارجی را به دلیل نبود Ticket داخلی نادیده نگیرید.

Evidence؛ «انجام شد» را قابل‌راستی‌آزمایی کنید

Screenshot یک Dashboard شاهد ضعیفی است. Evidence باید به Service، Version، Commit/Artifact، Control configuration، زمان و نتیجه وصل باشد. Freshness، Completeness و Integrity مهم‌اند. Compliance می‌تواند همین شواهد را مصرف کند، اما Passed control به معنای نبود Risk نیست.

Metricهای DevSecOps که رفتار غلط نمی‌سازند

هدف‌گذاری «صفر Finding» باعث Suppression و گزارش‌نکردن می‌شود. Metric را برای یادگیری و تصمیم به‌کار ببرید، نه رتبه‌بندی تنبیهی تیم‌ها. Trend را با تغییر Tool، Ruleset، Coverage و Portfolio Annotation کنید.

ابزار DevSecOps را چگونه انتخاب کنیم؟

نام Vendor را از Problem statement شروع نکنید. ابتدا Control contract و Workflow را بنویسید، سپس ابزار را با نمونه واقعی ارزیابی کنید.

PoC را با Repository ساختگی سبز اجرا نکنید؛ یک سرویس کم‌ریسک اما واقعی، چند Finding بذرگذاری‌شده، Dependency و IaC نمونه، Pipeline failure و Export drill لازم است.

DevSecOps برای تیم ایرانی

اصل کنترل تغییر نمی‌کند، اما Availability ابزار، پرداخت، Registry، اینترنت، Talent و Support روی معماری برنامه اثر دارند. وابستگی خارجی را با هویت جعلی یا دورزدن شرایط سرویس «حل» نکنید؛ Eligibility و شرایط رسمی را بررسی کنید و برای خروج آماده باشید.

نسخه کمینه برای تیم کوچک

1. پنج سرویس/Repo بحرانی و Owner را فهرست کنید.
2. یک Risk tier ساده و ۱۰ Requirement پایه بسازید.
3. Secret scan، dependency update/scan و branch review را فعال کنید.
4. یک Threat model برای حساس‌ترین Journey انجام دهید.
5. Artifact را با Digest و SBOM ثبت کنید؛ Production version معلوم باشد.
6. Finding board با Owner/SLA/Retest و Exception دارای Expiry داشته باشید.
7. یک Incident drill برای Secret یا Dependency بحرانی اجرا کنید.

پنج Runbook ضروری

۱. احتمال compromise شدن CI runner

Jobها را متوقف و Runner را Quarantine کنید؛ Token/secret و Artifactهای ساخته‌شده در پنجره را Scope و Revoke کنید؛ Provenance/Log را حفظ و Artifactها را از Builder سالم Rebuild/Verify کنید؛ Deploy مشکوک را Rollback یا Reconcile و Root cause شبکه/ایمیج/Plugin/permission را ببندید.

۲. Advisory بحرانی Dependency

affected component/version را با SBOM در Portfolio پیدا کنید، Runtime digest و Reachability/Exposure را تأیید، Exploit و Vendor guidance را بررسی، Mitigation موقت را اعمال، Fix را با Regression/Canary منتشر و Production را Verify کنید. «پکیج در Manifest هست» و «کد آسیب‌پذیر قابل‌اجراست» یکسان نیستند.

۳. Secret در Repository یا Log

Credential را فوراً Revoke/Rotate، دسترسی رخ‌داده را Audit، Consumerها را با کمترین اختلال به Credential جدید منتقل و همه نسخه‌های Repository/Artifact/Log/Fork را Scope کنید. سپس Short-lived identity و Guardrail را اصلاح کنید؛ پاک‌کردن Commit به‌تنهایی کافی نیست.

۴. Gate پرنویز Release را متوقف کرده است

Rule/tool version و Failure را تثبیت، راه دورزدن پنهان نسازید؛ time-boxed exception یا fail policy متناسب با Tier ثبت، False positive را نمونه‌برداری و Ruleset را اصلاح کنید. پس از رفع، missed scanها را اجرا و Impact روی Risk/Lead time را بازبینی کنید.

۵. ابزار یا Feed خارجی در دسترس نیست

Last-success و Data age را اعلام، Cache/secondary source یا مسیر Manual محدود را فعال و نوع Changeهای مجاز را بر اساس Risk محدود کنید. Evidence gap را ثبت و بعد از بازیابی Backfill کنید. Outage مکرر باید Vendor/architecture/exit decision را باز کند.

برنامه ۳۰، ۶۰ و ۹۰روزه DevSecOps

چک‌لیست پیاده‌سازی

• Service/Repo/Pipeline/Artifact/Runtime/Supplier inventory و Owner دارید.
• Risk tier بر Data/Action/Exposure/Blast radius/Recovery بنا شده است.
• Control profile هر Tier و Applicability قابل‌توضیح است.
• هر Control ریسک، Scope، Trigger، Gate، Evidence، Owner و Failure policy دارد.
• Requirement و Threat model به Test و Telemetry متصل‌اند.
• RACI، ظرفیت AppSec و نقش Champion رسمی‌اند.
• Paved road امن و Escape hatch قابل‌ممیزی وجود دارد.
• SCM/CI/Registry/Secret store و Workload identity حفاظت می‌شوند.
• SAST/SCA/secret/IaC/container coverage و محدودیت‌شان اندازه‌گیری می‌شود.
• SBOM/Provenance به Artifact digest وصل و هنگام Deploy Verify می‌شوند.
• Gate New-vs-existing، Risk context، outage و exception را مدیریت می‌کند.
• Finding تا Fix/Deploy/Retest و Root-cause learning دنبال می‌شود.
• Exception مالک، جبران، Expiry، Trigger و Remediation plan دارد.
• Runtime event، Alert، Disclosure و Incident loop تعریف شده‌اند.
• Metricهای Coverage/Quality/Flow/Risk/DX/Outcome با denominator معتبرند.
• Eligibility/TCO/Export/Exit ابزارها برای ایران سنجیده شده است.
• Runbookها در Game day تمرین و Evidence بازبینی شده‌اند.

پرسش‌های متداول

تفاوت DevOps و DevSecOps چیست؟

DevOps روی Flow و Feedback میان توسعه و عملیات تمرکز دارد. DevSecOps Capabilityهای امنیت، Risk decision و Evidence را در همان Flow و Runtime ادغام می‌کند. DevSecOps یک Stage یا تیم سوم نیست و وجود DevOps به‌تنهایی امنیت را تضمین نمی‌کند.

Shift Left در DevSecOps یعنی چه؟

یعنی Requirement، Threat modeling و Feedback کنترل‌هایی مانند تست و اسکن را زودتر و نزدیک Change انجام دهیم. Shift left نباید Runtime protection، Telemetry، Incident، Disclosure و پاسخ به Advisory را حذف کند؛ حلقه کامل هم چپ و هم راست دارد.

آیا هر آسیب‌پذیری High باید Build را Fail کند؟

نه صرفاً بر اساس Label. Asset criticality، Applicability، Reachability، Exposure، Exploit، New-vs-existing و Compensating control باید در Policy باشند. بعضی موارد مانند Secret معتبر جدید ممکن است Block فوری بخواهند؛ برخی به Triage و SLA نیاز دارند.

بهترین ابزارهای DevSecOps کدام‌اند؟

فهرست ثابت وجود ندارد. ابتدا Control contract را تعریف و سپس Coverage، Signal quality، Workflow، Developer UX، Evidence، امنیت داده، TCO و Exit را روی Repository واقعی PoC کنید. Tool بدون Owner و Finding lifecycle ارزش محدودی دارد.

DevSecOps سرعت توسعه را کم می‌کند؟

ممکن است کنترل بدطراحی‌شده Lead time را بالا ببرد؛ همان‌طور که نبود کنترل می‌تواند Rework و Incident بسازد. اثر را با Feedback latency، bypass، time-to-fix/deploy/retest، Lead time و Risk outcome بسنجید. Paved road و Tuning باید اصطکاک بی‌ارزش را کم کنند.

جمع‌بندی

DevSecOps فرهنگ مبهم یا مجموعه اسکنرها نیست. یک Operating model است که Risk را به Requirement و Control، Control را به Evidence، Finding را به Owner و Remediation، و Production را به Feedback طراحی وصل می‌کند. «مسئولیت همه» زمانی معنا دارد که Accountable owner، ظرفیت و راه امنِ کم‌اصطکاک وجود داشته باشد.

از کل سازمان شروع نکنید. یک Journey پرریسک و یک تیم آماده انتخاب کنید؛ Inventory و Tier را روشن، پنج Control contract بسازید، Paved road را Pilot و Finding را تا Retest ببندید. سپس با شواهد Coverage، Quality، Flow و Outcome تصمیم بگیرید چه چیزی مقیاس بگیرد، چه چیزی اصلاح و چه ابزاری حذف شود.