DevSecOps چیست؟ چگونه امنیت را وارد فرایند توسعه و CI/CD کنیم؟

DevSecOps رویکردی برای ادغام امنیت با تمام مراحل توسعه، تست، ساخت و استقرار نرم‌افزار است؛ به‌طوری‌که امنیت به جای یک بررسی نهایی قبل از انتشار، از زمان طراحی و نوشتن کد تا اجرای برنامه در محیط Production حضور داشته باشد. در یک معماری DevSecOps مناسب، کنترل‌هایی مانند Threat Modeling، بررسی کد، SAST، SCA، Secret Scanning، اسکن Infrastructure as Code، ارزیابی Container Image، DAST، تولید SBOM، امضای Artifact و Monitoring به شکل مرحله‌ای و تا حد ممکن خودکار وارد CI/CD Pipeline می‌شوند.

در مدل سنتی توسعه نرم‌افزار، تیم توسعه ممکن بود هفته‌ها یا ماه‌ها روی یک محصول کار کند و تنها در مراحل پایانی پروژه، تیم امنیت برای بررسی آسیب‌پذیری‌ها وارد شود. نتیجه این روش معمولاً مجموعه‌ای از مشکلات امنیتی بود که اصلاح آن‌ها در مراحل پایانی توسعه پرهزینه، زمان‌بر و گاهی حتی نیازمند تغییر معماری نرم‌افزار بود.

DevSecOps تلاش می‌کند این مسئله را از پایه تغییر دهد.

در این رویکرد امنیت دیگر مسئولیت یک تیم جداگانه در انتهای پروژه نیست. توسعه‌دهنده، تیم عملیات، مهندس Cloud، مسئول CI/CD و تیم امنیت همگی بخشی از یک چرخه مشترک هستند و کنترل‌های امنیتی در همان مسیری اجرا می‌شوند که نرم‌افزار از Source Code به Build و سپس Production می‌رسد.

اما DevSecOps صرفاً به معنی نصب یک ابزار SAST روی Jenkins یا GitHub Actions نیست. اگر فرهنگ تیم، معماری Pipeline، مدیریت Secretها، دسترسی‌ها، Dependencyها، Artifactها و فرآیند واکنش به آسیب‌پذیری‌ها اصلاح نشده باشند، اضافه‌کردن چند Scanner به Pipeline الزاماً امنیت واقعی ایجاد نمی‌کند.

در این مقاله به‌صورت کامل بررسی می‌کنیم DevSecOps چیست، چه تفاوتی با DevOps دارد، چگونه امنیت را وارد SDLC و CI/CD کنیم، چه تست‌هایی باید در هر مرحله اجرا شوند، Security Gate چگونه تعریف می‌شود و چگونه می‌توان بدون تبدیل Pipeline به یک مانع دائمی برای توسعه‌دهندگان، امنیت نرم‌افزار را افزایش داد.

DevSecOps چیست؟

DevSecOps از ترکیب سه مفهوم Development، Security و Operations شکل گرفته است.

در DevOps هدف اصلی نزدیک‌ترکردن تیم توسعه و عملیات، افزایش Automation و کوتاه‌کردن چرخه Build، Test و Deployment است.

DevSecOps همین مدل را گسترش می‌دهد و Security را نیز به بخشی از چرخه دائمی توسعه تبدیل می‌کند.

در یک محیط DevSecOps، امنیت باید از همان زمانی که Requirement تعریف می‌شود مورد توجه باشد و تا زمانی که برنامه در Production اجرا می‌شود ادامه پیدا کند.

برای مثال ممکن است Pipeline یک پروژه مراحل زیر را داشته باشد:

Commit ↓ Code Review ↓ SAST ↓ Secret Scanning ↓ Build ↓ SCA ↓ Unit Test ↓ Container Scan ↓ Deployment to Test ↓ DAST ↓ Security Gate ↓ Production Deployment ↓ Runtime Monitoring

این ساختار نشان می‌دهد امنیت یک مرحله مستقل در انتهای Pipeline نیست، بلکه در نقاط مختلف توسعه تکرار می‌شود.

هدف DevSecOps این نیست که تمام مشکلات امنیتی به‌طور خودکار پیدا شوند. چنین چیزی در عمل امکان‌پذیر نیست.

هدف اصلی ایجاد فرآیندی است که احتمال ورود آسیب‌پذیری به محصول را کاهش دهد، مشکلات را زودتر شناسایی کند، Supply Chain نرم‌افزار را قابل اعتمادتر کند و امکان واکنش سریع‌تر به آسیب‌پذیری‌های جدید را فراهم سازد.

چرا مدل سنتی امنیت نرم‌افزار کافی نیست؟

در مدل‌های قدیمی Software Development Life Cycle یا SDLC معمولاً توسعه و امنیت دو فرآیند تقریباً جدا بودند.

توسعه‌دهندگان نرم‌افزار را می‌ساختند و پس از آماده‌شدن نسخه Release، محصول برای تست امنیتی تحویل داده می‌شد.

این روش چند مشکل اساسی داشت.

اول اینکه بعضی آسیب‌پذیری‌ها ریشه معماری دارند.

فرض کنید سیستم Authorization برنامه از ابتدا اشتباه طراحی شده باشد. کشف این مشکل در پایان پروژه ممکن است به تغییر بخش بزرگی از Backend نیاز داشته باشد.

اما اگر Threat Modeling هنگام طراحی انجام شده بود، احتمال داشت مشکل قبل از نوشتن هزاران خط کد شناسایی شود.

مشکل دوم مربوط به سرعت توسعه مدرن است.

بسیاری از پروژه‌ها دیگر هر شش ماه یک نسخه منتشر نمی‌کنند. ممکن است روزانه چندین Deployment انجام شود.

در چنین شرایطی نمی‌توان قبل از هر Deployment چند روز منتظر تست دستی امنیت ماند.

مشکل سوم وابستگی شدید نرم‌افزارهای امروزی به Packageها، Container Imageها، Cloud Serviceها و Build Toolهای خارجی است.

بنابراین سطح حمله فقط کدی نیست که تیم شما نوشته است.

به همین دلیل امنیت باید تا حد امکان در فرآیند توسعه و CI/CD خودکار شود.

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

DevOps و DevSecOps دو رویکرد متضاد نیستند.

DevSecOps در واقع توسعه طبیعی DevOps است.

DevOps روی همکاری Development و Operations و Automation تمرکز می‌کند.

DevSecOps این ساختار را حفظ می‌کند اما Security را به یکی از الزامات اصلی Pipeline تبدیل می‌کند.

در DevOps ممکن است سؤال اصلی این باشد:

«چگونه کد را سریع‌تر و پایدارتر Deploy کنیم؟»

در DevSecOps سؤال کامل‌تر می‌شود:

«چگونه کد را سریع، پایدار و با کنترل امنیتی مناسب Deploy کنیم؟»

تفاوت مهم دیگر در Ownership است.

در مدل سنتی ممکن است امنیت صرفاً مسئولیت تیم Security باشد.

در DevSecOps توسعه‌دهنده نیز در قبال امنیت کدی که تولید می‌کند مسئولیت دارد.

البته این به معنی حذف تیم امنیت نیست.

تیم امنیت همچنان نقش مهمی در تعریف Policy، Threat Modeling، معماری، بررسی یافته‌های پیچیده، Incident Response و تست‌های تخصصی دارد.

تفاوت در این است که Security دیگر خارج از جریان توسعه قرار ندارد.

مفهوم Shift Left در DevSecOps چیست؟

یکی از اصطلاحات رایج در DevSecOps عبارت Shift Left است.

اگر SDLC را از چپ به راست تصور کنیم، سمت چپ شامل Planning، Design و Coding است و سمت راست شامل Deployment و Production.

Shift Left یعنی کنترل‌های امنیتی تا جای ممکن به مراحل ابتدایی منتقل شوند.

برای مثال به جای اینکه SQL Injection فقط در تست نفوذ قبل از انتشار پیدا شود، می‌توان بخشی از مشکلات احتمالی را هنگام Code Review یا SAST شناسایی کرد.

یا به جای اینکه Secret قرارگرفته در Repository چند ماه بعد کشف شود، Secret Scanner می‌تواند همان زمان Pull Request هشدار ایجاد کند.

مزیت اصلی Shift Left کاهش هزینه اصلاح است.

هرچه یک نقص امنیتی زودتر پیدا شود، معمولاً رفع آن ساده‌تر خواهد بود.

اما Shift Left نباید به اشتباه به معنی «تمام امنیت قبل از Production» تفسیر شود.

امنیت فقط با Shift Left کامل نمی‌شود.

Shift Right چیست؟

Shift Right مکمل Shift Left است.

حتی اگر تمام تست‌های امنیتی CI/CD موفق باشند، نمی‌توان نتیجه گرفت برنامه در Production هیچ آسیب‌پذیری ندارد.

بعضی مشکلات تنها در شرایط واقعی آشکار می‌شوند.

به همین دلیل DevSecOps باید امنیت Runtime را نیز پوشش دهد.

Shift Right می‌تواند شامل مواردی مانند این‌ها باشد:

Monitoring

Security Logging

Runtime Detection

Alerting

Incident Response

WAF Monitoring

Container Runtime Security

Cloud Security Monitoring

بررسی رفتار غیرعادی کاربران

بنابراین معماری مناسب DevSecOps ترکیبی از Shift Left و Shift Right است.

DevSecOps از کدام مرحله باید شروع شود؟

اشتباه رایج این است که تیم ابتدا ده ابزار امنیتی خریداری کند و بعد تلاش کند آن‌ها را وارد Pipeline کند.

شروع مناسب باید از شناخت سیستم و ریسک‌ها باشد.

قبل از انتخاب ابزار باید مشخص شود:

نرم‌افزار چه کاری انجام می‌دهد؟

چه داده‌هایی پردازش می‌کند؟

چه سرویس‌هایی اینترنتی هستند؟

چه قسمت‌هایی بیشترین Impact را دارند؟

چه Technology Stackهایی استفاده می‌شوند؟

Build و Deployment چگونه انجام می‌شود؟

چه Dependencyهایی وجود دارند؟

چه کسانی به Pipeline دسترسی دارند؟

بعد از این مرحله می‌توان کنترل‌های مناسب را انتخاب کرد.

یک وبلاگ ساده و یک سامانه بانکی الزاماً به Pipeline امنیتی یکسان نیاز ندارند.

DevSecOps باید Risk-Based باشد.

امنیت از مرحله Requirement شروع می‌شود

یکی از مهم‌ترین اصول Secure Software Development این است که Security Requirementها قبل از نوشتن کد تعریف شوند.

اگر سیستم اطلاعات حساس کاربران را ذخیره می‌کند، باید از ابتدا الزامات مربوط به Access Control، Encryption، Logging و Data Retention مشخص باشند.

برای مثال Requirement امنیتی می‌تواند چنین باشد:

«تمام عملیات مدیریتی باید فقط پس از احراز هویت چندمرحله‌ای در دسترس باشند.»

یا:

«Secretهای Production نباید در Source Code یا Repository ذخیره شوند.»

این نوع Requirementها بعداً می‌توانند به Test Case و Policy تبدیل شوند.

Threat Modeling در DevSecOps

Threat Modeling فرآیندی برای شناسایی تهدیدها قبل از تبدیل‌شدن آن‌ها به Incident واقعی است.

در Threat Modeling معمولاً معماری سیستم، Data Flow، Trust Boundary، دارایی‌های حساس و مهاجمان احتمالی بررسی می‌شوند.

برای مثال یک معماری ساده ممکن است شامل این بخش‌ها باشد:

User ↓ CDN ↓ Load Balancer ↓ Web Application ↓ API ↓ Database

در Threat Modeling باید سؤال‌هایی مطرح شوند.

اگر API مستقیماً از اینترنت قابل دسترسی باشد چه اتفاقی می‌افتد؟

اگر Access Token سرقت شود چه می‌شود؟

اگر سرویس داخلی به اشتباه Public شود چه خطری ایجاد می‌کند؟

آیا یک کاربر عادی می‌تواند Resource متعلق به کاربر دیگری را درخواست کند؟

Threat Modeling کمک می‌کند کنترل‌های امنیتی قبل از پیاده‌سازی مشخص شوند.

امنیت Source Code Repository

Repository یکی از مهم‌ترین دارایی‌های Software Supply Chain است.

اگر مهاجم بتواند Source Code را تغییر دهد، ممکن است کد مخرب را وارد نسخه رسمی نرم‌افزار کند.

بنابراین Repository باید با همان جدیتی که Production محافظت می‌شود مدیریت شود.

مهم‌ترین کنترل‌ها شامل موارد زیر هستند:

فعال‌سازی MFA یا 2FA

محدودکردن Administratorها

استفاده از Branch Protection

اجباری‌کردن Pull Request

اجباری‌کردن Code Review

محدودکردن Force Push

بررسی تغییرات فایل‌های Pipeline

حذف حساب کارکنان سابق

استفاده از Least Privilege

ثبت Audit Log

Branch اصلی پروژه نباید در پروژه‌های حساس مستقیماً توسط هر توسعه‌دهنده‌ای قابل تغییر باشد.

Code Review چه نقشی در DevSecOps دارد؟

Automated Scannerها قدرتمند هستند، اما همه مشکلات امنیتی را پیدا نمی‌کنند.

Code Review انسانی هنوز اهمیت زیادی دارد.

برای مثال یک Scanner ممکن است متوجه نشود که منطق Business Logic اجازه می‌دهد کاربر محدودیت برداشت روزانه را دور بزند.

یا ممکن است نتواند Authorization اشتباه میان دو Role را به‌درستی تشخیص دهد.

در Code Review امنیتی باید علاوه بر کیفیت کد، موضوعاتی مانند Authentication، Authorization، Input Validation، Session Management، Error Handling و Secret Management بررسی شوند.

SAST چیست؟

SAST مخفف Static Application Security Testing است.

در SAST کد یا Build Artifact بدون اجرای واقعی برنامه تحلیل می‌شود.

SAST می‌تواند الگوهای مشکوک امنیتی را شناسایی کند.

برای مثال ابزار ممکن است مسیر ورودی کاربر به یک Query حساس را بررسی کند و احتمال Injection را گزارش دهد.

SAST معمولاً در مراحل ابتدایی CI اجرا می‌شود.

یکی از بهترین نقاط اجرای آن هنگام Pull Request است.

این کار باعث می‌شود مشکل قبل از Merge شدن کد شناسایی شود.

با این حال SAST محدودیت دارد.

وجود Finding به معنی قابل سوءاستفاده‌بودن قطعی آسیب‌پذیری نیست.

False Positive نیز ممکن است وجود داشته باشد.

بنابراین یافته‌ها باید Triage شوند.

Security Linting

Linting فقط برای Style کد نیست.

Security Linter می‌تواند الگوهای ناامن شناخته‌شده را هنگام توسعه شناسایی کند.

مزیت Linting سرعت بالا است.

در بسیاری از پروژه‌ها می‌توان Security Linter را قبل از Commit یا هنگام Pull Request اجرا کرد.

این کنترل جای SAST کامل را نمی‌گیرد، اما می‌تواند Feedback بسیار سریعی به توسعه‌دهنده بدهد.

Secret Scanning چیست؟

یکی از خطرناک‌ترین اشتباهات در پروژه‌ها Commit کردن Credential داخل Repository است.

نمونه‌های رایج عبارت‌اند از:

API Key

Cloud Access Key

Database Password

Private Key

JWT Signing Secret

Webhook Secret

Token

قرارگرفتن Secret در Repository ممکن است خطرناک باشد حتی اگر فایل بعداً حذف شود، زیرا Secret ممکن است در Git History باقی بماند.

Secret Scanning باید قبل از Merge و ترجیحاً قبل از Push انجام شود.

اگر Secret واقعی افشا شد، فقط پاک‌کردن آن از کد کافی نیست.

Credential باید Rotate یا Revoke شود.

Secrets باید کجا نگهداری شوند؟

Secretها نباید داخل Source Code قرار گیرند.

برای سیستم‌های حرفه‌ای بهتر است از Secret Management Solution استفاده شود.

Pipeline هنگام اجرا Credential مورد نیاز را دریافت می‌کند.

Secret باید فقط برای مدت و Scope لازم در اختیار Job قرار گیرد.

نباید تمام Jobهای Pipeline به تمام Secretهای Production دسترسی داشته باشند.

این اصل همان Least Privilege است.

چرا Long-Lived Credential خطرناک است؟

فرض کنید یک AWS Access Key با دسترسی Production داخل CI/CD ذخیره شده باشد و چند سال تغییر نکند.

اگر این Credential افشا شود، مهاجم می‌تواند تا زمانی که Key غیرفعال نشده از آن استفاده کند.

راهکار بهتر در پلتفرم‌هایی که پشتیبانی می‌کنند استفاده از Identity Federation و Credentialهای کوتاه‌عمر است.

برای نمونه، یک CI Workflow می‌تواند از OIDC برای دریافت Token موقت Cloud استفاده کند و نیازی به ذخیره دائمی Cloud Secret نداشته باشد. چنین Tokenهایی می‌توانند برای همان Job و محدوده دسترسی مشخص صادر شوند.

Software Composition Analysis یا SCA چیست؟

بخش قابل توجهی از نرم‌افزار مدرن از کد Third-Party تشکیل شده است.

توسعه‌دهنده ممکن است هزار خط کد بنویسد اما برنامه او ده‌ها یا صدها Package خارجی داشته باشد.

SCA برای شناسایی Componentها و Dependencyهای نرم‌افزار و تطبیق آن‌ها با اطلاعات آسیب‌پذیری‌ها استفاده می‌شود.

برای مثال اگر پروژه از نسخه آسیب‌پذیر یک Library استفاده کند، ابزار SCA می‌تواند هشدار دهد.

SCA باید Direct Dependency و Transitive Dependency را نیز در نظر بگیرد.

Dependencyهای Transitive چیست؟

فرض کنید برنامه مستقیماً Package A را نصب کرده باشد.

Package A نیز Package B را نیاز دارد.

شما Package B را مستقیماً انتخاب نکرده‌اید اما همچنان وارد محصول شده است.

این Dependency غیرمستقیم را Transitive Dependency می‌نامند.

ممکن است آسیب‌پذیری دقیقاً در همین Dependency وجود داشته باشد.

به همین دلیل صرفاً بررسی فایل Package اصلی کافی نیست.

آیا هر CVE باید Build را متوقف کند؟

خیر.

یکی از بدترین پیاده‌سازی‌های DevSecOps این است که Pipeline برای هر Finding بدون توجه به Context متوقف شود.

در نتیجه توسعه‌دهندگان به‌مرور Scannerها را مانع کار می‌بینند.

Policy باید Risk-Based باشد.

برای مثال:

Critical و Exploitable → Block

High با Exposure اینترنتی → Block یا نیازمند Approval

Medium → Ticket و SLA

Low → ثبت و بررسی دوره‌ای

شدت CVSS تنها معیار تصمیم‌گیری نیست.

باید Context نیز بررسی شود.

ممکن است یک آسیب‌پذیری Critical در Componentی وجود داشته باشد که Feature آسیب‌پذیر آن اصلاً در برنامه استفاده نمی‌شود.

از طرف دیگر ممکن است یک آسیب‌پذیری با Severity پایین در بخش بسیار حساس Business Logic اهمیت بیشتری داشته باشد.

SBOM چیست؟

SBOM مخفف Software Bill of Materials است.

می‌توان آن را مشابه فهرست مواد تشکیل‌دهنده نرم‌افزار در نظر گرفت.

SBOM اطلاعاتی درباره Componentها، Packageها، نسخه‌ها و Dependencyهای محصول ارائه می‌کند و برای مدیریت Software Supply Chain اهمیت زیادی دارد. راهنماهای جدید امنیت زنجیره تأمین نیز تولید SBOM قابل پردازش توسط ماشین را به‌عنوان ابزاری برای افزایش شفافیت Componentها مطرح می‌کنند.

فرض کنید آسیب‌پذیری مهمی در یک Library منتشر شده است.

اگر سازمان نداند کدام برنامه‌ها از آن Library استفاده می‌کنند، پاسخ به حادثه ممکن است ساعت‌ها یا روزها طول بکشد.

اما با SBOM می‌توان سریع‌تر محصولات وابسته را شناسایی کرد.

SBOM را چه زمانی تولید کنیم؟

یکی از نقاط مناسب تولید SBOM مرحله Build است.

در این مرحله نسخه واقعی Dependencyهای Resolve‌شده مشخص شده است.

بهتر است SBOM همراه Release نگهداری شود تا مشخص باشد هر نسخه محصول دقیقاً شامل چه Componentهایی بوده است.

فرمت‌هایی مانند CycloneDX و SPDX برای SBOM استفاده می‌شوند.

امنیت Build Environment

Build Server یکی از حساس‌ترین نقاط DevSecOps است.

این سیستم Source Code را دریافت می‌کند، Dependency دانلود می‌کند، Artifact می‌سازد و در بسیاری از پروژه‌ها Credential انتشار را نیز در اختیار دارد.

اگر مهاجم Build Environment را تصاحب کند، ممکن است بدون تغییر آشکار Source Code، Artifact خروجی را دستکاری کند.

بنابراین CI Runner باید Hardening شود.

موارد مهم عبارت‌اند از:

Patch منظم

حداقل سرویس‌های لازم

Network Segmentation

عدم استفاده عمومی از Runner حساس

محدودکردن دسترسی

پاک‌کردن Workspace پس از Build

عدم نگهداری دائمی Secret

ثبت Log

استفاده از Build Environment قابل بازتولید

OWASP نیز CI/CD را بخشی حیاتی از Software Supply Chain می‌داند و توصیه می‌کند زیرساخت Pipeline با کنترل دسترسی، Hardening و Monitoring مناسب محافظت شود.

Pipeline as Code

یکی از بهترین روش‌ها نگهداری تنظیمات CI/CD به شکل Code است.

برای مثال Workflowها و Pipeline Definitionها داخل Version Control قرار می‌گیرند.

مزیت این روش این است که تغییر Pipeline نیز مانند تغییر Source Code قابل Review خواهد بود.

اگر شخصی بخواهد مرحله Security Scan را حذف کند یا Deployment Permission را تغییر دهد، تغییر او در Pull Request دیده می‌شود.

Pipeline Configuration نباید یک تنظیم مخفی و بدون Audit در رابط گرافیکی باشد.

امنیت GitHub Actions، GitLab CI و Jenkins

صرف نظر از اینکه از GitHub Actions، GitLab CI، Jenkins، Azure DevOps یا ابزار دیگری استفاده می‌کنید، چند اصل تقریباً مشترک هستند.

Pipeline نباید Permission بیشتر از نیاز داشته باشد.

Jobهای Build نباید بدون دلیل Credential Production داشته باشند.

Runner حساس نباید کد کنترل‌نشده اجرا کند.

Workflowهای Third-Party باید با دقت انتخاب شوند.

نسخه Action، Plugin یا Dependencyهای Pipeline باید کنترل شوند.

تغییر فایل CI/CD باید Review شود.

Environmentهای Production باید Protection Rule داشته باشند.

خطر اجرای کد Pull Request

یکی از سناریوهای مهم امنیتی زمانی است که CI کد Pull Request را اجرا می‌کند.

اگر Contributor غیرقابل اعتماد بتواند Pipeline را وادار کند کد دلخواه او را روی Runner اجرا کند، ممکن است تلاش کند Environment Variable، Secret یا Credential را بخواند.

به همین دلیل باید Trust Boundary میان Pull Requestهای داخلی و خارجی مشخص باشد.

Jobی که روی کد کنترل‌نشده اجرا می‌شود نباید بدون دلیل به Secret حساس دسترسی داشته باشد.

Dependency Pinning

در Pipelineها معمولاً ابزار، Action، Container یا Package خارجی استفاده می‌شود.

اگر همیشه «آخرین نسخه» دریافت شود، رفتار Build ممکن است بدون تغییر Source Code تغییر کند.

Pinning نسخه Dependency می‌تواند کنترل بیشتری ایجاد کند.

اما Pinning به تنهایی کافی نیست.

نسخه Pinشده نیز باید Patch و Update شود.

هدف تعادل بین Reproducibility و Patch Management است.

Dependency Confusion چیست؟

Dependency Confusion نوعی ریسک Software Supply Chain است.

در این سناریو سیستم Package Management ممکن است به جای Package داخلی سازمان، Package دیگری با نام مشابه را از Repository عمومی دریافت کند.

برای کاهش ریسک باید Source Dependencyها مشخص، Repositoryها کنترل‌شده و Naming Strategy مناسب باشد.

استفاده از Private Artifact Repository نیز می‌تواند کنترل بیشتری روی Packageهای مورد استفاده سازمان فراهم کند.

Artifact Repository چیست؟

Build Artifact نباید روی سیستم‌های مختلف به صورت پراکنده نگهداری شود.

یک Artifact Repository مرکزی می‌تواند محل نگهداری Packageها، Binaryها و Container Imageهای تأییدشده باشد.

بهتر است Deployment Production فقط از Artifact Repository مورد اعتماد انجام شود.

این کار مانع از آن می‌شود که هر Developer فایل Buildشده روی Laptop خود را مستقیماً وارد Production کند.

Build Once, Deploy Many

الگوی مناسب این است که Artifact یک‌بار ساخته شود و همان Artifact در Test، Staging و Production ارتقا پیدا کند.

اگر برای Production دوباره Build انجام شود، ممکن است خروجی با نسخه تست‌شده متفاوت باشد.

بنابراین بهتر است Integrity Artifact حفظ شود.

برای مثال:

Build Artifact ↓ Security Scan ↓ Sign ↓ Store ↓ Deploy to Staging ↓ Approval ↓ Deploy same Artifact to Production

Artifact Signing چیست؟

Artifact Signing برای اثبات Integrity و Origin نرم‌افزار اهمیت دارد.

امضای دیجیتال کمک می‌کند مشخص شود Artifact پس از Build تغییر نکرده و از فرآیند مورد انتظار تولید شده است.

در یک معماری قوی، سیستم Deployment قبل از اجرای Artifact می‌تواند Signature را Verify کند.

اگر Signature معتبر نباشد، Deployment متوقف می‌شود.

این کنترل مخصوصاً در Software Supply Chain اهمیت زیادی دارد.

Provenance چیست؟

Provenance اطلاعاتی درباره نحوه تولید Artifact ارائه می‌کند.

برای مثال:

کدام Repository؟

کدام Commit؟

کدام Build System؟

چه زمانی؟

با چه Workflowی؟

چه Artifactی؟

Frameworkهایی مانند SLSA روی قابلیت اثبات منشأ Artifact و مقاوم‌سازی Software Supply Chain تمرکز دارند و OWASP نیز استفاده از Provenance برای ارتباط قابل بررسی میان Artifact و فرآیند Build را توصیه می‌کند.

Infrastructure as Code یا IaC چیست؟

در محیط Cloud بخش بزرگی از Infrastructure با Code تعریف می‌شود.

برای مثال Terraform، CloudFormation، Kubernetes Manifest یا Ansible ممکن است مشخص کنند چه منابعی ایجاد شوند.

اشتباه در IaC می‌تواند آسیب‌پذیری زیرساختی ایجاد کند.

برای مثال:

Storage Public

Security Group باز

Database قابل دسترسی از اینترنت

IAM Role با Permission بسیار گسترده

Container با Privileged Mode

نبود Encryption

IaC Security Scanner می‌تواند بخشی از این Misconfigurationها را قبل از Deployment شناسایی کند.

چرا IaC Scan باید قبل از Deployment باشد؟

اصلاح یک Security Group اشتباه قبل از Deployment ساده‌تر از کشف آن بعد از قرارگرفتن Database روی اینترنت است.

IaC Scan نمونه خوبی از Shift Left است.

Pipeline می‌تواند Pull Request مربوط به Infrastructure را بررسی کند و در صورت نقض Policy هشدار دهد.

برای Ruleهای بسیار حساس حتی می‌توان Merge را Block کرد.

Policy as Code چیست؟

Policy as Code یعنی سیاست‌های امنیتی نیز به شکل Machine-Readable تعریف شوند.

برای مثال:

هیچ Storage عمومی مجاز نیست.

هیچ Database نباید Public IP داشته باشد.

تمام Volumeهای حساس باید Encryption فعال داشته باشند.

Container نباید Privileged باشد.

تمام Production Deploymentها باید Approval داشته باشند.

با این مدل Enforcement از حالت دستی خارج می‌شود.

امنیت Container در DevSecOps

Container Image ممکن است شامل موارد زیر باشد:

Operating System Package

Runtime

Library

Application

Configuration

اگر Base Image قدیمی باشد، آسیب‌پذیری می‌تواند وارد تمام Containerهای ساخته‌شده از آن شود.

Container Scanning باید در Pipeline انجام شود.

بهتر است Image نهایی Scan شود، نه فقط Dockerfile.

زیرا خروجی نهایی ممکن است Packageهایی داشته باشد که از بررسی Dockerfile مشخص نباشند.

انتخاب Base Image

Base Image کوچک‌تر معمولاً سطح حمله کمتری دارد، زیرا Packageهای غیرضروری کمتری دارد.

ولی کوچک‌بودن به معنی امنیت قطعی نیست.

Base Image باید:

از منبع معتبر باشد.

Patch شود.

Version مشخص داشته باشد.

به‌طور دوره‌ای Rebuild شود.

وجود Image چند ماهه حتی اگر Source Code تغییر نکرده باشد ممکن است مشکل‌ساز شود، زیرا آسیب‌پذیری‌های جدید در Packageهای سیستم عامل کشف می‌شوند.

Registry خصوصی و Image Signing

برای سازمان‌های حساس بهتر است Imageها در Registry کنترل‌شده نگهداری شوند.

Production نباید هر Image ناشناخته‌ای را اجرا کند.

می‌توان Policy تعریف کرد که فقط Imageهایی که از Registry مجاز آمده‌اند و Signature معتبر دارند اجرا شوند.

این موضوع احتمال اجرای Artifact دستکاری‌شده را کاهش می‌دهد.

DAST چیست؟

DAST مخفف Dynamic Application Security Testing است.

برخلاف SAST، در DAST برنامه در حال اجرا بررسی می‌شود.

Scanner مانند یک Client خارجی با Application تعامل می‌کند و رفتار آن را ارزیابی می‌کند.

DAST می‌تواند برای پیدا کردن بخشی از مشکلات Web Security مفید باشد.

معمولاً DAST روی محیط Test یا Staging اجرا می‌شود.

انجام اسکن تهاجمی روی Production بدون طراحی و مجوز مناسب می‌تواند اختلال ایجاد کند.

تفاوت SAST و DAST

SAST کد را از داخل بررسی می‌کند.

DAST رفتار برنامه در حال اجرا را از بیرون ارزیابی می‌کند.

هیچ‌کدام جای دیگری را نمی‌گیرد.

برای مثال SAST ممکن است مسیر کد خطرناک را نشان دهد اما نتواند Configuration واقعی Reverse Proxy را ببیند.

DAST می‌تواند رفتار HTTP واقعی را مشاهده کند اما دسترسی به منطق داخلی کد ندارد.

ترکیب آن‌ها پوشش بهتری ایجاد می‌کند.

IAST چیست؟

IAST یا Interactive Application Security Testing در زمان اجرای برنامه فعالیت می‌کند اما برخلاف DAST دید بیشتری به داخل Application دارد.

Agent یا Instrumentation می‌تواند Flow داده و رفتار داخلی برنامه را مشاهده کند.

IAST در برخی پروژه‌ها می‌تواند Context بیشتری نسبت به SAST یا DAST ارائه دهد.

اما استفاده از آن به Technology Stack، Performance و معماری پروژه بستگی دارد.

تست امنیت API

در بسیاری از پروژه‌های امروزی بخش اصلی Application یک API است.

بنابراین Pipeline باید API Security را نیز در نظر بگیرد.

موضوعات مهم عبارت‌اند از:

Authentication

Authorization

Object-Level Access Control

Rate Limiting

Input Validation

Schema Validation

Token Handling

Error Handling

یک API ممکن است از نظر Injection کاملاً سالم باشد اما Authorization آن اجازه دهد کاربر اطلاعات Account دیگران را مشاهده کند.

این نوع مشکل همیشه با Scanner عمومی به‌راحتی پیدا نمی‌شود.

Unit Test امنیتی

بعضی کنترل‌های امنیتی را می‌توان مستقیماً وارد Test Suite کرد.

برای مثال می‌توان Test نوشت که:

کاربر بدون Permission به Endpoint حساس دسترسی نداشته باشد.

User A نتواند Object متعلق به User B را مشاهده کند.

Password Reset Token پس از استفاده دوباره معتبر نباشد.

Role معمولی نتواند API مدیریتی را فراخوانی کند.

Security Unit Test باعث می‌شود اگر تغییر جدیدی رفتار امنیتی را بشکند، Pipeline سریعاً Fail شود.

تست Integration برای امنیت

بسیاری از مشکلات تنها هنگام تعامل چند Component مشخص می‌شوند.

Integration Test می‌تواند مواردی مثل این‌ها را بررسی کند:

هماهنگی Authentication Service و API

انتقال صحیح Security Header

رفتار Session پس از Logout

Invalidation Token

دسترسی بین Microserviceها

محدودیت Roleها

این تست‌ها می‌توانند بخشی از Regression Security Testing باشند.

Security Regression چیست؟

فرض کنید تیم یک آسیب‌پذیری Authorization را اصلاح کرده باشد.

اگر فقط Fix انجام شود اما Test ایجاد نشود، ممکن است چند ماه بعد همان Bug دوباره وارد سیستم شود.

بهتر است برای آسیب‌پذیری‌های مهم پس از Fix یک Regression Test ایجاد شود.

در نتیجه Pipeline در آینده مانع بازگشت همان مشکل می‌شود.

Security Gate چیست؟

Security Gate نقطه‌ای از Pipeline است که بر اساس Policy تصمیم می‌گیرد Build اجازه ادامه دارد یا خیر.

برای مثال Policy می‌تواند چنین باشد:

وجود Secret واقعی → Block

Critical SAST → Block

Critical Dependency با Exploitability تأییدشده → Block

Container با Critical CVE و Fix موجود → Block

IaC با Public Database → Block

DAST Critical → Block

در مقابل Findingهای کم‌ریسک می‌توانند فقط Ticket ایجاد کنند.

چرا Gateهای زیاد خطرناک‌اند؟

اگر Pipeline برای هر هشدار کوچک متوقف شود، توسعه‌دهندگان ممکن است به‌دنبال راه دورزدن سیستم بروند.

DevSecOps موفق باید Balance ایجاد کند.

هدف امنیت بیشتر است، نه ایجاد هزاران Warning بی‌ارزش.

معیارهای Gate باید:

شفاف باشند.

قابل اندازه‌گیری باشند.

بر اساس Risk باشند.

Exception Process داشته باشند.

به‌طور دوره‌ای بازبینی شوند.

False Positive Management

Scannerهای امنیتی ممکن است False Positive تولید کنند.

اگر تیم Security فقط هزاران Finding ایجاد کند و مسئولیت Triage را روی Developer بیندازد، اعتماد به سیستم کاهش می‌یابد.

باید فرآیند مشخصی برای Classification وجود داشته باشد.

Finding می‌تواند:

Confirmed

False Positive

Accepted Risk

Mitigated

Not Applicable

باشد.

تصمیم‌ها نیز باید مستند شوند.

Exception نباید دائمی باشد

گاهی لازم است یک Finding موقتاً پذیرفته شود.

برای مثال Patch سازگار هنوز منتشر نشده است.

در این حالت Security Exception ممکن است لازم باشد.

اما Exception باید:

Owner داشته باشد.

دلیل داشته باشد.

Expiry Date داشته باشد.

Mitigation داشته باشد.

دوباره بررسی شود.

Exception بدون تاریخ انقضا معمولاً به بدهی امنیتی دائمی تبدیل می‌شود.

Vulnerability Management بعد از Release

DevSecOps با Deployment تمام نمی‌شود.

Dependencyی که امروز سالم است ممکن است هفته بعد دارای CVE جدید شود.

بنابراین باید Componentهای Production به شکل مستمر Monitoring شوند.

وجود SBOM در اینجا بسیار مفید است.

وقتی آسیب‌پذیری جدید منتشر می‌شود، سازمان می‌تواند بررسی کند کدام محصولات تحت تأثیر هستند.

این مدل بخشی از Continuous Vulnerability Management است.

امنیت Production Deployment

Deployment Production باید کنترل‌شده باشد.

یک Developer نباید الزاماً بتواند هر Commit دلخواه را مستقیم به Production Deploy کند.

بسته به حساسیت سیستم می‌توان از موارد زیر استفاده کرد:

Protected Environment

Approval

Change Management

Signed Artifact

Restricted Deployment Role

Automated Verification

Rollback

Deployment Credential محدود

Separation of Duties

در سیستم‌های حساس ممکن است لازم باشد فردی که Code را نوشته نتواند به‌تنهایی همان تغییر را Approve و Deploy کند.

این اصل Separation of Duties است.

البته این سطح کنترل برای همه پروژه‌ها ضروری نیست.

اما در زیرساخت‌های مالی، دولتی یا حیاتی می‌تواند اهمیت زیادی داشته باشد.

Least Privilege در CI/CD

Pipelineها معمولاً Permission بیش از حد دریافت می‌کنند.

برای مثال یک Job که فقط باید Container Image را Push کند ممکن است Administrator کامل Cloud باشد.

این کار Blast Radius را افزایش می‌دهد.

هر Job باید فقط Permission مورد نیاز همان عملیات را داشته باشد.

اگر Build Job نیازی به Production Database ندارد، نباید Credential آن را ببیند.

اگر Deployment فقط یک Namespace Kubernetes را مدیریت می‌کند، نباید Cluster Admin باشد.

Network Segmentation

Runnerهای حساس بهتر است از محیط‌های دیگر جدا باشند.

برای مثال Build عمومی نباید مستقیماً به Database Production دسترسی داشته باشد.

Network Policy می‌تواند مشخص کند هر Job به چه Destinationهایی دسترسی داشته باشد.

این کنترل در صورت Compromise شدن Runner می‌تواند حرکت مهاجم را محدود کند.

Logging برای CI/CD

Pipeline خود یک سیستم حساس امنیتی است و باید Log مناسب داشته باشد.

موارد مهم می‌توانند شامل این‌ها باشند:

Login مدیریتی

تغییر Permission

تغییر Secret

تغییر Workflow

Deployment

تغییر Branch Protection

ایجاد Token

تغییر Runner

Logها باید برای مدت مناسب نگهداری شوند و در پروژه‌های حساس به SIEM ارسال شوند.

Monitoring پس از Deployment

بعد از انتشار باید بررسی شود برنامه چگونه رفتار می‌کند.

Monitoring امنیتی می‌تواند شامل موارد زیر باشد:

افزایش Login Failure

تغییر غیرعادی Permission

افزایش Error

درخواست غیرعادی API

افزایش Traffic از Source مشخص

اجرای Process غیرمنتظره

تغییر File

رفتار مشکوک Container

اما جمع‌آوری Log بدون Alert مناسب ارزش محدودی دارد.

Incident Response در DevSecOps

تیم باید از قبل بداند در صورت Incident چه کاری انجام دهد.

مثلاً اگر یک Secret در Repository افشا شد:

چه کسی Credential را Revoke می‌کند؟

چه سیستم‌هایی از آن استفاده کرده‌اند؟

Logها کجا هستند؟

آیا نیاز به Redeploy وجود دارد؟

آیا باید History پاک‌سازی شود؟

آیا Tokenهای مرتبط Rotate شوند؟

Incident Response باید بخشی از طراحی DevSecOps باشد، نه سندی که بعد از حمله نوشته شود.

Feedback Loop

یکی از مهم‌ترین ویژگی‌های DevSecOps ایجاد Feedback Loop است.

اطلاعات Production باید به Development بازگردد.

مثلاً اگر یک Incident نشان داد تیم چند بار Authorization Bug ایجاد کرده است، فقط همان Bug نباید اصلاح شود.

باید Root Cause بررسی شود.

ممکن است نیاز باشد:

Secure Coding Guideline تغییر کند.

Library مشترک Authorization ساخته شود.

Code Review Checklist اصلاح شود.

SAST Rule جدید اضافه شود.

Test جدید نوشته شود.

Training انجام شود.

این رویکرد احتمال تکرار مشکل را کاهش می‌دهد.

نقش Secure Coding Training

ابزار نمی‌تواند جای آموزش را بگیرد.

اگر Developer مفهوم Access Control را درک نکند، ممکن است بارها همان اشتباه را با شکل‌های مختلف ایجاد کند.

آموزش باید مرتبط با Technology Stack تیم باشد.

برای مثال توسعه‌دهنده PHP باید Riskهای متداول PHP و Framework خودش را بشناسد.

توسعه‌دهنده Node.js باید با Dependency Management اکوسیستم npm آشنا باشد.

آموزش عمومی بدون ارتباط با پروژه معمولاً اثر محدودی دارد.

Security Champion چیست؟

در بعضی سازمان‌ها از مدل Security Champion استفاده می‌شود.

Security Champion یک توسعه‌دهنده یا عضو تیم محصول است که دانش امنیتی بیشتری دارد و رابط میان Development و Security محسوب می‌شود.

این فرد جای متخصص امنیت را نمی‌گیرد.

هدف او کمک به انتقال دانش و جلوگیری از ایجاد فاصله میان تیم‌هاست.

DevSecOps و NIST SSDF

چارچوب Secure Software Development Framework یا SSDF متعلق به NIST مجموعه‌ای از Practiceهای سطح بالا برای توسعه امن نرم‌افزار ارائه می‌کند که می‌توان آن‌ها را با SDLCهای مختلف ادغام کرد.

هدف این رویکرد کاهش Vulnerabilityهای محصول، کاهش Impact مشکلات کشف‌نشده و پرداختن به Root Cause آسیب‌پذیری‌هاست. نسخه نهایی فعلی SSDF همچنان نسخه 1.1 در NIST SP 800-218 است و NIST در دسامبر ۲۰۲۵ پیش‌نویس اولیه نسخه 1.2 را نیز منتشر کرده است.

DevSecOps می‌تواند یکی از روش‌های اجرایی‌کردن بسیاری از این Practiceها باشد.

DevSecOps و OWASP

OWASP نیز DevSecOps را فقط به SAST محدود نمی‌کند.

راهنمای DevSecOps این پروژه موضوعاتی مثل Threat Modeling، Secrets Management، SAST، DAST، IAST، SCA، Infrastructure Scanning و Container Scanning را در چرخه CI/CD مطرح می‌کند.

این موضوع نشان می‌دهد Pipeline امنیتی واقعی باید چندلایه باشد.

نمونه معماری یک CI/CD امن

یک معماری نمونه می‌تواند چنین باشد:

Developer ↓ Local Security Lint ↓ Git Push ↓ Secret Scan ↓ Pull Request ↓ Code Review ↓ SAST ↓ SCA ↓ Unit Test ↓ Security Unit Tests ↓ Build ↓ SBOM Generation ↓ Artifact Scan ↓ Container Scan ↓ Artifact Signing ↓ Trusted Registry ↓ Deploy to Staging ↓ DAST ↓ Integration Security Tests ↓ Security Gate ↓ Approval ↓ Production Deployment ↓ Monitoring ↓ Incident Feedback

این فقط یک نمونه است.

هر پروژه باید Pipeline را متناسب با Risk خود طراحی کند.

DevSecOps برای تیم کوچک چگونه پیاده‌سازی شود؟

تیم کوچک لازم نیست از روز اول ده‌ها محصول امنیتی داشته باشد.

می‌توان با چند کنترل مؤثر شروع کرد.

مرحله اول:

MFA برای Repository

Branch Protection

Code Review

Secret Scanning

SCA

Backup مناسب

مرحله دوم:

SAST

Container Scan

IaC Scan

Security Test

مرحله سوم:

SBOM

Artifact Signing

DAST

Policy as Code

Runtime Monitoring

این روش معمولاً بهتر از تلاش برای پیاده‌سازی یک معماری بسیار پیچیده در روز اول است.

DevSecOps برای سازمان بزرگ

سازمان بزرگ با مشکل دیگری روبه‌رو است: Scale.

ممکن است صدها Repository و هزاران Pipeline وجود داشته باشند.

در این شرایط Platform Engineering اهمیت زیادی پیدا می‌کند.

تیم مرکزی می‌تواند Template امن ایجاد کند.

برای مثال تمام پروژه‌ها از Pipeline استانداردی استفاده کنند که موارد زیر را به شکل پیش‌فرض دارد:

SAST

SCA

Secret Scan

SBOM

Container Scan

Signing

Logging

این مدل باعث می‌شود هر تیم مجبور نباشد امنیت را از صفر طراحی کند.

Golden Pipeline چیست؟

Golden Pipeline یک Template استاندارد و از قبل Hardening‌شده است.

تیم‌های توسعه می‌توانند پروژه جدید را با این Pipeline شروع کنند.

کنترل‌های اصلی به صورت Default فعال هستند.

این مفهوم با Secure by Default هماهنگ است.

به جای اینکه از Developer بخواهیم ده تنظیم امنیتی را دستی فعال کند، زیرساخت باید حالت امن را به‌صورت پیش‌فرض ارائه دهد.

Metrics در DevSecOps

چیزی که اندازه‌گیری نمی‌شود معمولاً به سختی بهبود پیدا می‌کند.

اما Metric اشتباه نیز می‌تواند رفتار اشتباه ایجاد کند.

برای مثال تعداد Vulnerability پیدا شده به‌تنهایی معیار موفقیت نیست.

Metricهای مفیدتر می‌توانند شامل این‌ها باشند:

Mean Time to Remediate

درصد Repositoryهای دارای Branch Protection

درصد Buildهای دارای SCA

درصد Artifactهای Signed

زمان رفع Critical Vulnerability

تعداد Secretهای افشاشده

درصد Pipelineهای دارای SBOM

درصد Security Findingهای تکرارشونده

هدف Metric باید بهبود Risk باشد، نه افزایش تعداد Dashboard.

اشتباهات رایج در پیاده‌سازی DevSecOps

نصب ابزار بدون تعریف فرآیند

بزرگ‌ترین اشتباه تصور این است که خرید ابزار یعنی پیاده‌سازی DevSecOps.

Scanner فقط Finding تولید می‌کند.

اگر مشخص نباشد چه کسی Finding را بررسی می‌کند، چه زمانی باید Fix شود و چه چیزی Pipeline را Block می‌کند، ابزار ارزش محدودی دارد.

اجرای همه Scannerها روی هر Commit

بعضی تست‌ها سریع هستند و می‌توانند روی هر Commit اجرا شوند.

بعضی تست‌ها زمان‌بر هستند.

Pipeline باید چند سطح داشته باشد.

Fast Check می‌تواند سریع Feedback بدهد و اسکن‌های سنگین‌تر در Stageهای مناسب اجرا شوند.

Block کردن تمام یافته‌ها

این کار باعث Alert Fatigue و مقاومت تیم می‌شود.

Gate باید Risk-Based باشد.

دادن Permission بیش از حد به Pipeline

CI/CD یکی از جذاب‌ترین اهداف برای مهاجمان Supply Chain است.

Credential و Permission آن باید حداقلی باشند.

نگهداری Secret در فایل YAML

حتی اگر Repository Private باشد، Secret نباید Hardcode شود.

Private Repository معادل Secret Vault نیست.

نادیده‌گرفتن Dependencyها

امنیت فقط Source Code داخلی نیست.

Packageهای Third-Party بخشی از محصول هستند.

نادیده‌گرفتن خود Pipeline

ممکن است SAST عالی داشته باشید ولی Jenkins با رمز ضعیف و Plugin قدیمی اجرا شود.

در این حالت خود سیستم امنیت تبدیل به نقطه حمله شده است.

اعتماد کامل به Scanner

ابزار خودکار Business Logic پیچیده را همیشه تشخیص نمی‌دهد.

Manual Review و Penetration Testing همچنان اهمیت دارند.

نبود Owner

هر Finding باید Owner داشته باشد.

Finding بدون Owner معمولاً ماه‌ها باقی می‌ماند.

نداشتن SLA

برای رفع آسیب‌پذیری باید زمان‌بندی مشخص وجود داشته باشد.

Critical نمی‌تواند مانند Low در Backlog عادی قرار گیرد.

آیا DevSecOps جای Penetration Testing را می‌گیرد؟

خیر.

DevSecOps تعداد زیادی از کنترل‌های امنیتی را خودکار می‌کند و احتمال ورود Vulnerability به Production را کاهش می‌دهد.

اما Penetration Testing تخصصی همچنان ارزشمند است.

تستر انسانی می‌تواند Chainهای پیچیده Attack، مشکلات Business Logic، Authorization و Interaction میان چند سیستم را بررسی کند.

رویکرد مناسب ترکیب Automation و Manual Security Testing است.

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

اگر بد پیاده‌سازی شود، بله.

Pipeline پر از Scanner کند، False Positive و Approval دستی می‌تواند سرعت تیم را کاهش دهد.

اما DevSecOps خوب باید Feedback را سریع‌تر کند.

اگر Developer همان زمان Pull Request متوجه Vulnerability شود، رفع آن معمولاً بسیار سریع‌تر از اصلاح مشکل بعد از Release است.

هدف DevSecOps ایجاد اصطکاک هوشمند است، نه اصطکاک دائمی.

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

برای ارزیابی اولیه می‌توان از این چک‌لیست استفاده کرد:

1. MFA برای Repository فعال است.
2. Branch اصلی Protection دارد.
3. Merge نیازمند Code Review است.
4. Permissionها بر اساس Least Privilege هستند.
5. Secret Scanning فعال است.
6. Secretها در Source Code ذخیره نمی‌شوند.
7. SAST در Pipeline وجود دارد.
8. SCA برای Dependencyها اجرا می‌شود.
9. Dependencyهای مستقیم و غیرمستقیم بررسی می‌شوند.
10. Container Image اسکن می‌شود.
11. IaC Scan وجود دارد.
12. Security Policy برای Block کردن Build مشخص است.
13. False Positive Process تعریف شده است.
14. Security Exception تاریخ انقضا دارد.
15. SBOM برای Release تولید می‌شود.
16. Artifactها در Repository مورد اعتماد نگهداری می‌شوند.
17. Artifactهای حساس امضا می‌شوند.
18. Production از Artifact تأییدشده Deploy می‌شود.
19. Credentialهای CI/CD حداقل دسترسی را دارند.
20. Credentialهای کوتاه‌عمر در صورت امکان استفاده می‌شوند.
21. Runnerها Hardening شده‌اند.
22. تغییر Pipeline Code Review می‌شود.
23. DAST روی محیط مناسب اجرا می‌شود.
24. Security Regression Test وجود دارد.
25. Production Monitoring فعال است.
26. Audit Log نگهداری می‌شود.
27. Incident Response تعریف شده است.
28. Dependencyهای Production به‌طور مستمر Monitoring می‌شوند.
29. Developerها Secure Coding Training دریافت می‌کنند.
30. Metricهای DevSecOps به‌طور دوره‌ای بررسی می‌شوند.

نقشه راه عملی پیاده‌سازی DevSecOps

مرحله اول: شناخت وضعیت فعلی

ابتدا Repositoryها، Pipelineها، Cloud Accountها، Secretها و Dependencyها را Inventory کنید.

بدون Asset Inventory امکان طراحی صحیح کنترل‌ها وجود ندارد.

مرحله دوم: محافظت از Source Control

MFA، Branch Protection، Roleها و Code Review را اصلاح کنید.

این مرحله معمولاً هزینه کمی دارد ولی اثر زیادی ایجاد می‌کند.

مرحله سوم: کنترل Secret

Secretهای موجود در Repository را شناسایی و Rotate کنید.

Secret Manager یا مکانیزم امن CI/CD را پیاده‌سازی کنید.

مرحله چهارم: SAST و SCA

اسکن کد و Dependency را وارد Pull Request کنید.

Policy اولیه را ساده نگه دارید.

مرحله پنجم: امنیت Build

Runnerها را Hardening کنید.

دسترسی‌ها را کاهش دهید.

Build Process را Version Control کنید.

مرحله ششم: IaC و Container Security

Infrastructure و Container Image را پیش از Deployment اسکن کنید.

مرحله هفتم: SBOM و Artifact Integrity

برای Releaseها SBOM تولید کنید و Artifactهای مهم را Sign کنید.

مرحله هشتم: DAST و Integration Test

محیط Staging را برای تست Runtime آماده کنید.

مرحله نهم: Production Controls

Approval، Environment Protection و Monitoring را اضافه کنید.

مرحله دهم: Continuous Improvement

Incident، Finding و Metricها را بررسی کنید و Pipeline را اصلاح کنید.

DevSecOps مقصد نهایی ندارد؛ یک فرآیند مداوم است.

سؤالات متداول درباره DevSecOps

DevSecOps چیست؟

DevSecOps رویکردی است که Security را در تمام مراحل Development و Operations ادغام می‌کند. هدف آن شناسایی و کاهش ریسک‌های امنیتی از زمان طراحی و Coding تا CI/CD، Deployment و Monitoring در Production است.

CI/CD چیست؟

CI/CD مجموعه‌ای از فرآیندهای خودکار برای Integration، Build، Test و Delivery یا Deployment نرم‌افزار است. DevSecOps کنترل‌های امنیتی را وارد همین فرآیند می‌کند.

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

DevOps روی همکاری Development و Operations و Automation تمرکز دارد. DevSecOps همین ساختار را حفظ می‌کند اما Security را به بخشی دائمی از Planning، Development، Build، Test، Deployment و Operations تبدیل می‌کند.

Shift Left چیست؟

Shift Left یعنی اجرای کنترل‌های امنیتی در مراحل اولیه توسعه. برای مثال SAST و Secret Scanning در Pull Request نمونه‌هایی از Shift Left هستند.

Shift Right چیست؟

Shift Right به کنترل‌های امنیتی بعد از Deployment مانند Monitoring، Detection، Logging و Incident Response اشاره دارد.

SAST چیست؟

SAST روشی برای بررسی Source Code یا Artifact بدون اجرای واقعی Application است و برای شناسایی برخی الگوهای امنیتی در مراحل اولیه توسعه استفاده می‌شود.

DAST چیست؟

DAST برنامه در حال اجرا را از بیرون بررسی می‌کند و رفتار Application را از طریق Interfaceهای واقعی مانند HTTP ارزیابی می‌کند.

SCA چیست؟

Software Composition Analysis برای شناسایی Dependencyها و بررسی آسیب‌پذیری‌های شناخته‌شده در Componentهای Third-Party استفاده می‌شود.

Secret Scanning چیست؟

Secret Scanning برای شناسایی Credentialهایی مثل API Key، Token و Password که به اشتباه وارد Repository شده‌اند استفاده می‌شود.

SBOM چیست؟

Software Bill of Materials فهرستی ساختاریافته از Componentها و Dependencyهای یک نرم‌افزار است که به Vulnerability Management و امنیت Software Supply Chain کمک می‌کند.

آیا DevSecOps فقط برای شرکت‌های بزرگ است؟

خیر. حتی تیم‌های کوچک می‌توانند با MFA، Branch Protection، Code Review، Secret Scanning، SAST و SCA بخش بزرگی از اصول DevSecOps را اجرا کنند.

آیا DevSecOps به ابزار خاصی وابسته است؟

خیر. ابزار مهم است، اما DevSecOps بیشتر یک مدل Process، Culture و Automation است. ابزار بدون Policy و Ownership کافی نیست.

آیا تمام آسیب‌پذیری‌ها باید Pipeline را Fail کنند؟

خیر. Security Gate باید Risk-Based باشد. Findingهای Critical و قابل سوءاستفاده ممکن است Deployment را Block کنند، اما Finding کم‌ریسک می‌تواند وارد فرآیند Triage شود.

آیا DevSecOps جای تست نفوذ را می‌گیرد؟

خیر. تست‌های خودکار CI/CD و Penetration Testing مکمل یکدیگر هستند. تستر انسانی همچنان برای Business Logic و سناریوهای پیچیده اهمیت دارد.

مهم‌ترین نقطه شروع DevSecOps چیست؟

برای بسیاری از تیم‌ها شروع با محافظت Repository، MFA، Code Review، Secret Management، SAST و Dependency Scanning منطقی‌تر از ایجاد Pipeline بسیار پیچیده در مرحله اول است.

چرا امنیت خود CI/CD مهم است؟

CI/CD به Source Code، Build Artifact و معمولاً Credentialهای مهم دسترسی دارد. اگر Pipeline تصاحب شود، مهاجم ممکن است Software Supply Chain را دستکاری کند حتی اگر Application اصلی Vulnerability مستقیمی نداشته باشد.

جمع‌بندی

DevSecOps به معنی اضافه‌کردن یک مرحله «Security Scan» به انتهای CI/CD نیست. مفهوم اصلی آن این است که امنیت باید جزئی از تمام چرخه تولید نرم‌افزار باشد.

این چرخه از Requirement و Threat Modeling آغاز می‌شود، وارد Secure Coding، Code Review، SAST، Secret Scanning و SCA می‌شود و در مراحل Build با کنترل Dependency، امنیت Runner، SBOM، Artifact Signing، Container Scanning و IaC Security ادامه پیدا می‌کند.

پس از آن نیز DAST، Integration Test، Security Gate و کنترل‌های Deployment وارد فرآیند می‌شوند و در Production، Monitoring، Logging، Vulnerability Management و Incident Response چرخه را کامل می‌کنند.

یکی از مهم‌ترین نکات در موفقیت DevSecOps ایجاد تعادل میان Security و Developer Experience است.

Pipelineی که ده‌ها False Positive تولید کند و تمام Buildها را بدون دلیل متوقف کند، به‌مرور دور زده خواهد شد.

از طرف دیگر Pipelineی که فقط گزارش تولید کند ولی هیچ Critical Vulnerability را Block نکند، امنیت واقعی ایجاد نمی‌کند.

راه‌حل مناسب استفاده از Risk-Based Security Gate، Policy مشخص، Ownership، SLA و Feedback Loop است.

همچنین باید خود CI/CD به‌عنوان یک دارایی حیاتی محافظت شود. Repository، Runner، Build System، Secret Store، Artifact Repository و Cloud Credentialها همگی بخشی از Software Supply Chain هستند.

در نهایت DevSecOps یک محصول، Scanner یا Plugin نیست. DevSecOps یک روش سازمانی برای تبدیل امنیت از یک بررسی دیرهنگام به بخشی دائمی از توسعه نرم‌افزار است.

هرچه Security Requirementها زودتر تعریف شوند، آسیب‌پذیری‌ها سریع‌تر شناسایی شوند و کنترل‌های امنیتی بیشتر به Automation قابل اعتماد تبدیل شوند، احتمال رسیدن مشکلات جدی به Production کاهش پیدا می‌کند.

سازمانی که DevSecOps را درست اجرا می‌کند فقط نرم‌افزار را سریع‌تر اسکن نمی‌کند؛ بلکه فرآیند ساخت، تست، انتشار و نگهداری نرم‌افزار را به شکلی طراحی می‌کند که امنیت از ابتدا جزئی از همان فرآیند باشد.