محافظت جدید GitHub Actions؛ Workflow مشکوک چرا برای تأیید متوقف می شود؟

حملات جدید زنجیره تأمین فقط Dependency آلوده منتشر نمی کنند؛ مهاجم می تواند Credential حساب GitHub را بگیرد، Workflow مخرب Push کند و از Runner برای سرقت Secretهای CI/CD یا حمله بعدی استفاده کند. GitHub از 28 ژوئیه 2026 در Repositoryهای عمومی روی github.com بعضی اجرای مشکوک را پیش از شروع نگه می دارد تا Collaborator دارای دسترسی Write آن را از یک Session احراز شده بررسی و تأیید کند. این لایه خودکار مفید است، اما جای Hardening Workflow را نمی گیرد.

حمله از طریق Workflow چگونه رخ می دهد؟

Runner یک محیط اجرایی با دسترسی به Source، Token، Artifact و گاهی Cloud Credential است. اگر مهاجم حساب Maintainer را تصاحب کند یا تغییر مخرب را وارد Branch قابل اجرا کند، Workflow می تواند Secret را به مقصد خارجی ارسال، Artifact را آلوده یا Release جعلی بسازد. این مسیر خطرناک است چون عملیات از زیرساخت معتبر پروژه اجرا می شود و ممکن است در Log عادی به نظر برسد.

GitHub می گوید حملات اخیر از Credentialهای سرقت شده برای Push کردن Workflowهای مخرب استفاده کرده اند. پس مسئله فقط Pull Request ناشناس نیست؛ Commit ممکن است با حساب واقعی عضو تیم ثبت شود. تحلیل باید Context ورود، تغییر Permission، زمان Commit، IP و رفتار غیرمعمول را در کنار Diff کد بررسی کند.

محافظت جدید GitHub چه می کند؟

وقتی GitHub اجرای Workflow را بالقوه مخرب تشخیص دهد، Run پیش از شروع Hold می شود. تا Collaborator دارای Write Access آن را بررسی و از Web Session احراز شده Approve نکند، Runner هیچ Step را اجرا نمی کند. الزام Web Session از Approval صرفاً API یا Credential سرقت شده جلوگیری می کند و یک نقطه کنترل انسانی اضافه می سازد.

این قابلیت خودکار است و Repository Owner لازم نیست Setting خاصی فعال کند. بااین حال، تشخیص خودکار کامل نیست. Workflow مخرب ممکن است Hold نشود و Workflow سالم ممکن است نیازمند Review شود. تیم باید Held Run را Signal با اولویت بالا بداند، اما Approval را نیز براساس Evidence انجام دهد.

محدوده فعلی محافظت

اعلام فعلی فقط Repositoryهای عمومی روی github.com را پوشش می دهد. Repository خصوصی و GitHub Enterprise Server در متن اطلاعیه به عنوان مشمول این کنترل معرفی نشده اند و GHES صراحتاً فعلاً فاقد آن است. سازمانی که GHES یا Runner داخلی دارد باید کنترل معادل را با Branch Protection، Review، Environment Approval و Monitoring بسازد.

حتی در Repository عمومی، همه Attack Surfaceها به این Hold وابسته نیستند. Workflow موجود می تواند Permission بیش ازحد داشته باشد، Action Third-party می تواند Compromise شود یا Script دانلودی تغییر کند. محافظت جدید بیشتر یک لایه تشخیص رفتاری قبل از Run است.

قبل از Approve کردن چه چیزهایی را بررسی کنیم؟

اول Actor و Commit را بررسی کنید: آیا تغییر با کار برنامه ریزی شده تیم سازگار است؟ سپس Diff فایل های .github/workflows، Actionهای Composite، Scriptهای Shell و فایل های Package را ببینید. Trigger جدید مانند workflow_run، pull_request_target، schedule یا repository_dispatch می تواند مسیر اجرای متفاوتی بسازد. Permissionهای GITHUB_TOKEN و دسترسی به Environment را خط به خط بررسی کنید.

به Commandهایی که curl، wget، PowerShell Invoke-WebRequest، Base64 Decode یا اجرای Script Remote دارند حساس باشید. تغییر مقصد Upload Artifact، Registry، Cloud CLI و Docker Login نیز مهم است. Obfuscation، رشته طولانی Encode شده و نام Variable گمراه کننده می تواند نشانه باشد. اگر علت Hold روشن نیست، Approve نکنید و حساب Actor را بررسی امنیتی کنید.

GITHUB_TOKEN را حداقلی کنید

Workflow بدون Permission صریح ممکن است دسترسی بیشتری از نیاز داشته باشد. در سطح Workflow یا Job، permissions را تعیین کنید و فقط Scope لازم را فعال کنید. Job تست معمولاً به Read محتوا نیاز دارد و نباید Package Write، Issue Write یا ID Token داشته باشد. Permission اضافی Blast Radius مهاجرت Credential یا Injection را بالا می برد.

id-token: write فقط برای OIDC و در Job مشخص فعال شود. Secret و Credential Cloud را در Job عمومی یا Matrix گسترده قرار ندهید. Job Build و Deploy را جدا کنید تا کد ناشناس پیش از Approval به Credential Production دسترسی نگیرد.

Actionهای Third-party را با Commit SHA Pin کنید

استفاده از actions/checkout@v4 خواناست، اما Tag می تواند به Commit دیگری اشاره کند. برای Action حساس، Full Commit SHA را Pin کنید و Update آن را با Dependabot یا Review کنترل شده انجام دهید. SHA نیز نیازمند بررسی Publisher و Repository است؛ Pin کردن Action مخرب امنیت ایجاد نمی کند.

Composite Action داخلی را مانند کد Production Review کنید. Marketplace Description کافی نیست. Permission، Network Call، Dependency و Release Process Action را بررسی کنید. Action Fork شده یا کم نگه داری شده ریسک بیشتری دارد.

Triggerهای پرریسک و کد غیرقابل اعتماد

pull_request برای کد Fork معمولاً Token محدودتری دارد، اما pull_request_target در Context Base Repository اجرا می شود و می تواند Secret یا Permission بیشتری داشته باشد. اگر Checkout کد Pull Request مهاجم را با pull_request_target ترکیب کنید، مسیر خطرناک ایجاد می شود. Trigger را براساس هدف انتخاب کنید و کد غیرقابل اعتماد را در محیط بدون Secret اجرا کنید.

workflow_run نیز می تواند Artifact Workflow قبلی را مصرف کند. Artifact باید اعتبارسنجی و به Run قابل اعتماد متصل شود. نام Artifact یا Branch به تنهایی Evidence کافی نیست. Cache و Artifact از Trigger نامطمئن باید Read-only یا جدا باشند.

Environment Protection و Approval انسانی

Deployment Production را داخل Environment محافظت شده قرار دهید. Required Reviewer، Branch Rule و Secret Environment کمک می کنند Workflow Build به تنهایی Credential Deploy نگیرد. Approval باید Diff Artifact، Source Run و Change Ticket را ببیند. تأیید سریع بدون Context فقط یک Button اضافه است.

Environment جدا برای Stage و Production بسازید و Secret را در Scope مناسب نگه دارید. Runner Production نیز Network و Permission محدود داشته باشد. اگر Self-hosted Runner با Repository عمومی استفاده می کنید، اجرای کد غیرقابل اعتماد می تواند Persistence ایجاد کند؛ Ephemeral Runner یا Isolation قوی لازم است.

Secret Exfiltration و Log

Secret Masking تضمین کامل نیست. مهاجم می تواند Secret را Encode، تکه تکه یا از طریق Network خارج کند. بنابراین اصل اصلی، عدم دراختیارگذاشتن Secret به Job نامطمئن است. Scope، TTL و Rotation نیز اهمیت دارد. Credential کوتاه عمر OIDC از Cloud Key ثابت بهتر است، به شرط Policy Trust دقیق.

Egress Network Runner را در محیط حساس محدود کنید. Log Command، Artifact و Cache را برای داده حساس بررسی کنید. پس از Incident، فقط Workflow را اصلاح نکنید؛ Tokenها را Revoke، Sessionها را بررسی و Artifact منتشرشده را اعتبارسنجی کنید.

امنیت حساب Maintainer

چون سناریوی اعلام شده شامل Credential Compromise است، Hardening Workflow بدون امنیت حساب کافی نیست. Passkey یا 2FA، Session Review، SSH Key Audit، Fine-grained Token و حذف Member قدیمی ضروری اند. Organization باید Require 2FA و Role حداقلی داشته باشد.

Commit Signing می تواند Signal اضافه بسازد، اما اگر کلید همان دستگاه Compromise شود کافی نیست. Audit Log، اعلان تغییر Workflow و Alert Login غیرعادی را به SOC یا Owner Repository متصل کنید.

اگر Workflow مشکوک اجرا شده باشد

ابتدا Run را Cancel و Runner را Isolation کنید. Secretهای در دسترس Job را فهرست و Rotate کنید. Network Destination، Command، Artifact و تغییر Package را بررسی کنید. اگر Release یا Container ساخته شده، آن را Trusted فرض نکنید و Provenance را بازسازی کنید.

Repositoryهای downstream و مصرف کنندگان Artifact باید مطلع شوند. Incident Timeline شامل Actor، Commit، Workflow، Token، Runner و مقصد Exfiltration باشد. پس از مهار، Root Cause حساب، Action یا Dependency مشخص شود. فقط حذف فایل Workflow پایان Incident نیست.

چگونه Approval را به فرایند واقعی تبدیل کنیم؟

یک Runbook کوتاه در Repository یا Security Handbook بنویسید. Reviewer باید بداند چه Evidenceهایی لازم است و چه زمانی Security Team وارد شود. Approval Held Run را Metric کنید؛ افزایش ناگهانی ممکن است نشانه Campaign یا Misconfiguration باشد.

Reviewer با Write Access لزوماً متخصص امنیت نیست. برای Repository حساس، CODEOWNERS فایل Workflow، Required Review و تیم مشخص تعریف کنید. تغییرات .github/workflows باید Review جدا داشته باشند.

محافظت خودکار GitHub در برابر Hardening تیم

امنیت مؤثر لایه ای است. Hold خودکار احتمال بعضی حملات را کاهش می دهد، اما Workflow امن باید حتی در نبود این قابلیت نیز Blast Radius محدودی داشته باشد.

محدودیت ها، ریسک ها و نکات مهم

چک لیست Hardening GitHub Actions

1. برای فایل های Workflow CODEOWNERS و Review اجباری تعریف کنید.
2. permissions را در Workflow و Job حداقلی کنید.
3. Actionهای Third-party را با Full Commit SHA Pin کنید.
4. کد Fork را با Secret یا Runner حساس اجرا نکنید.
5. Deploy را پشت Environment و Required Reviewer قرار دهید.
6. برای Cloud از OIDC کوتاه عمر با Trust Policy دقیق استفاده کنید.
7. Self-hosted Runner را Ephemeral و Network-limited کنید.
8. تغییر Workflow و Login غیرعادی را Alert کنید.
9. Runbook Approval و Incident داشته باشید.

Audit را از Repositoryهای عمومی و Pipelineهای Deploy شروع کنید؛ جایی که یک Workflow مخرب می تواند سریع تر به Secret یا Artifact قابل انتشار برسد.

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

چه کسی می تواند Workflow متوقف شده را تأیید کند؟

Collaborator دارای Write Access که از Web Session احراز شده استفاده می کند.

آیا این قابلیت نیاز به فعال سازی دارد؟

خیر. GitHub اعلام کرده این محافظت را خودکار اعمال می کند.

آیا Repository خصوصی را پوشش می دهد؟

اطلاعیه فعلی فقط Repositoryهای عمومی روی github.com را ذکر می کند.

آیا GitHub Enterprise Server پشتیبانی می شود؟

در زمان اعلام، GHES این محافظت را اضافه نمی کند.

قبل از Approval چه چیزی را بررسی کنیم؟

Commit و Actor، Diff Workflow، Trigger، Permission، Secret، Action Pin، Script دانلودی و مقصد Network.

جمع بندی سریع

• هر Workflow متوقف شده را به عنوان Signal امنیتی بررسی کنید.
• قبل از Approval، Diff، Trigger، Permission، Action Reference و Secret Access را ببینید.
• GITHUB_TOKEN را با Permission حداقلی تعریف کنید.
• Actionها را با Commit SHA Pin و Environment حساس را محافظت کنید.
• محافظت جدید را لایه اضافی بدانید، نه جایگزین Review و Monitoring.

امروز Permissionهای Workflow، Actionهای Third-party و Environmentهای دارای Secret را Audit کنید و یک Runbook مشخص برای Workflowهای Held بسازید.

منابع رسمی

اطلاعیه رسمی توقف Workflowهای مشکوک — دامنه محافظت، Approval و Repositoryهای مشمول

راهنمای رسمی Hardening در GitHub Actions — Permission، Secret، Third-party Action و کنترل Workflow

تغییرات جدید امنیت زنجیره تأمین GitHub و npm — زمینه حملات Package و کنترل های Registry