GitHub Advanced Security یا GHAS مجموعه‌ای از قابلیت‌های امنیتی پیشرفته است که در سطح مخزن، PR و زنجیره‌ی تأمین عمل می‌کند. برخلاف ابزارهای سنتی که امنیت را به مرحله‌ی بعد از انتشار موکول می‌کنند، GHAS تلاش می‌کند آسیب‌پذیری را در همان لحظه‌ی نوشتن کد شناسایی کند. CodeQL، Secret Scanning و Dependabot سه ستون اصلی این مجموعه هستند که هرکدام لایه‌ای متفاوت از ریسک را پوشش می‌دهند. اما فعال‌سازی این ابزارها به‌تنهایی کافی نیست؛ بدون سیاست‌های روشن، تیم‌ها به‌سرعت در انبوه هشدارها غرق می‌شوند و ابزار به یک تیک قالب تبدیل می‌شود. این نوشته مسیر کامل از معماری GHAS تا پیاده‌سازی عملی و پرهیز از دام‌های رایج را پوشش می‌دهد.

بیشترین بدهی امنیتی در پروژه‌ها، از مشکلات بزرگ ناشی نمی‌شود؛ از تصمیم‌های کوچکی می‌آید که در لحظه‌ی merge گرفته می‌شوند. یک وابستگی ناشناخته، یک سکرت لو رفته در branch قدیمی، یک الگوی کد ناامن که در بازبینی از قلم می‌افتد. GHAS دقیقاً برای بستن همین شکاف طراحی شده است، اما فقط اگر به‌درستی در فرآیند جا بیفتد.

GitHub Advanced Security چیست و چه تفاوتی با ابزارهای سنتی دارد

ابزارهای امنیتی سنتی معمولاً در مرحله‌ی بعد از build یا در محیط staging اجرا می‌شوند. یعنی آسیب‌پذیری زمانی کشف می‌شود که توسعه‌دهنده از زمینه‌ی اولیه‌اش فاصله گرفته و اصلاح آن نیازمند جابه‌جایی در چند لایه است. GHAS این منطق را معکوس می‌کند: امنیت در همان PR، در همان لحظه‌ی نوشتن کد و در همان محیطی که توسعه‌دهنده کار می‌کند.

سه قابلیت اصلی GHAS:

  • Code Scanning: تحلیل ایستای کد با CodeQL برای کشف الگوهای آسیب‌پذیر.
  • Secret Scanning: کشف اعتبارنامه‌هایی که به‌اشتباه در مخزن قرار گرفته‌اند.
  • Dependabot: شناسایی و به‌روزرسانی وابستگی‌های آسیب‌پذیر.

تفاوت اصلی این مجموعه با ابزارهای سنتی، یکپارچگی عمیق با workflow GitHub است. نتیجه‌ی هر بررسی، مستقیماً در تب Security مخزن یا در قالب کامنت روی PR ظاهر می‌شود. همین نزدیکی، فاصله‌ی میان کشف و اصلاح را به حداقل می‌رساند. اصول کلی این حوزه با آنچه در استانداردهای امنیت وب توضیح داده شده، هم‌راستاست.

محدودیت اصلی GHAS این است که برای مخازن خصوصی به پلن GitHub Enterprise نیاز دارد. برای تیم‌های کوچک‌تر، ممکن است هزینه‌ی آن توجیه‌پذیر نباشد. اما برای سازمان‌هایی که با داده‌های حساس یا کد مشتری کار می‌کنند، بازده سرمایه‌گذاری بالاست.

امنیت مؤثر، امنیتی است که در لحظه‌ی تصمیم حضور داشته باشد، نه امنیتی که بعد از انتشار گزارش بدهد.

Code Scanning و موتور تحلیل کد CodeQL

CodeQL یک موتور تحلیل ایستا است که کد را به یک پایگاه‌داده‌ی قابل پرس‌وجو تبدیل می‌کند. برخلاف ابزارهای لینت که بر قواعد ساده تکیه می‌کنند، CodeQL از الگوهای مبتنی بر جریان داده (Data Flow) و تینت (Taint Analysis) استفاده می‌کند. این رویکرد، امکان کشف آسیب‌پذیری‌های پیچیده مثل SQL Injection، XSS و Path Traversal را در سطحی فراهم می‌کند که ابزارهای ساده نمی‌توانند.

چند ویژگی مهم CodeQL:

  • پشتیبانی از زبان‌های متعدد: JavaScript، TypeScript، Python، Java، C#، Go، Ruby، C++ و PHP.
  • کوئری‌های آماده: مجموعه‌ی گسترده‌ای از کوئری‌های آماده برای آسیب‌پذیری‌های رایج.
  • قابلیت نوشتن کوئری سفارشی: برای قواعد اختصاصی سازمان.
  • اجرای خودکار در هر PR: با تنظیم default setup یا advanced setup.
name: CodeQL
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]
  schedule:
    - cron: "0 3 * * 1"

jobs:
  analyze:
    runs-on: ubuntu-latest
    permissions:
      security-events: write
      contents: read
    strategy:
      matrix:
        language: [javascript, python]
    steps:
      - uses: actions/checkout@v4
      - uses: github/codeql-action/init@v3
        with:
          languages: ${{ matrix.language }}
      - uses: github/codeql-action/autobuild@v3
      - uses: github/codeql-action/analyze@v3

نکته‌ی مهم در استفاده از CodeQL، مدیریت نرخ هشدارهاست. اگر در پروژه‌ای با کد قدیمی، CodeQL فعال شود، ممکن است صدها هشدار تولید کند. اگر این هشدارها بدون رسیدگی باقی بمانند، تیم به آن‌ها بی‌اعتنا می‌شود و ابزار اثر خود را از دست می‌دهد. راه‌حل عملی، کاهش تدریجی سطح حساسیت در ابتدا و افزایش آن با پاک‌سازی کد است. اصول این رویکرد در آسیب‌پذیری وب چیست و چگونه شناسایی می‌شود؟ بررسی شده است.

Secret Scanning و کشف زودهنگام اعتبارنامه‌ها

Secret Scanning به‌طور خودکار مخزن را برای الگوهای شناخته‌شده‌ی اعتبارنامه بررسی می‌کند: کلیدهای AWS، توکن‌های GitHub، کلیدهای Google Cloud، اعتبارنامه‌های پایگاه داده و صدها الگوی دیگر. مهم‌ترین مزیت این قابلیت، شناسایی در لحظه‌ی push است، نه در بازبینی بعدی.

چند نکته در استفاده‌ی مؤثر:

  • Push protection: جلوگیری از push شدن commit حاوی سکرت.
  • Custom patterns: تعریف الگوهای اختصاصی برای سازمان.
  • Alerts و چرخش: دریافت هشدار و چرخش فوری سکرت.
  • Bypass auditing: ثبت مواردی که push protection دور زده شده.
# .github/secret_scanning.yml
paths-ignore:
  - "tests/fixtures/**"
  - "docs/examples/**"

فایل پیکربندی secret_scanning.yml به شما اجازه می‌دهد مسیرهایی که شامل سکرت‌های آزمایشی هستند را نادیده بگیرید. این تنظیم، نویز هشدارها را کاهش می‌دهد و تمرکز روی موارد واقعی را حفظ می‌کند. اما باید با احتیاط استفاده شود، چون مسیرهای نادیده گرفته‌شده می‌توانند به پناهگاه سکرت‌های واقعی تبدیل شوند.

در پروژه‌های واقعی، مهم‌ترین اقدام پس از کشف سکرت، چرخش فوری است. حذف commit کافی نیست، چون سکرت در تاریخچه باقی می‌ماند و توسط هر کسی که به مخزن دسترسی دارد قابل بازیابی است. اصول مدیریت سکرت و چرخش آن در مدیریت سکرت‌ها در گیت‌هاب اکشنز به‌تفصیل آمده است.

Dependabot و مدیریت وابستگی‌های آسیب‌پذیر

بخش زیادی از کد یک پروژه‌ی مدرن، وابستگی‌های شخص ثالث است. هر وابستگی، یک سطح ریسک اضافه می‌کند. Dependabot این ریسک را با سه قابلیت مدیریت می‌کند:

  • Dependabot Alerts: هشدار درباره وابستگی‌های آسیب‌پذیر.
  • Dependabot Security Updates: پیشنهاد به‌روزرسانی خودکار.
  • Dependabot Version Updates: به‌روزرسانی دوره‌ای وابستگی‌ها.
# .github/dependabot.yml
version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    open-pull-requests-limit: 10
    reviewers:
      - "team-lead"
  - package-ecosystem: "composer"
    directory: "/"
    schedule:
      interval: "weekly"

مدیریت تعداد PRهای Dependabot یک چالش واقعی است. اگر Dependabot آزاد باشد، می‌تواند روزانه ده‌ها PR بسازد و تیم را در انبوه تغییرات غرق کند. تنظیم open-pull-requests-limit و زمان‌بندی هفتگی، تعادل بهتری برقرار می‌کند.

نکته‌ی مهم دیگر، تست خودکار به‌روزرسانی‌هاست. اگر پروژه تست خوبی ندارد، merge کردن به‌روزرسانی‌های Dependabot بدون بررسی، می‌تواند به شکستن production منجر شود. ترکیب Dependabot با CI کامل، این ریسک را کاهش می‌دهد. اصول CI مؤثر در گیت‌هاب اکشنز بررسی شده است.

Security Advisories و مدیریت آسیب‌پذیری در اکوسیستم

GitHub Advisory Database یک پایگاه‌داده‌ی عمومی از آسیب‌پذیری‌هاست که توسط GitHub و جامعه به‌روزرسانی می‌شود. سازمان‌ها می‌توانند advisories اختصاصی برای پروژه‌های خصوصی خود بسازند و از طریق آن، به مشتریان یا کاربران اطلاع‌رسانی کنند.

مفاهیم کلیدی در این حوزه:

  • CVE: شناسه‌ی جهانی آسیب‌پذیری‌ها.
  • GHSA: شناسه‌ی GitHub برای advisories.
  • Severity: سطح شدت (Low تا Critical).
  • CVSS: معیار امتیازدهی شدت.

برای سازمان‌هایی که محصول نرم‌افزاری می‌فروشند، انتشار advisory در زمان کشف آسیب‌پذیری بخشی از تعهد حرفه‌ای است. GitHub این فرآیند را ساده می‌کند و امکان هماهنگی با CVE Numbering Authority را فراهم می‌کند. اصول کلی CVE و نقش آن در امنیت در CVE چیست و چه نقشی در امنیت دارد؟ بررسی شده است.

امنیت زنجیره‌ی تأمین؛ از Actionها تا پکیج‌ها

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

GHAS چند ابزار برای کاهش این ریسک ارائه می‌دهد:

  • Dependency Review Action: بررسی تغییرات وابستگی در PR پیش از merge.
  • SBOM Export: تولید فهرست اجزای نرم‌افزار.
  • Attestations: امضای دیجیتال برای artifactها.
  • Artifact Attestations: تأیید اصالت build.
- uses: actions/dependency-review-action@v4
  with:
    fail-on-severity: high
    deny-licenses: GPL-3.0, AGPL-3.0

این Action در هر PR، تغییرات وابستگی را بررسی می‌کند و اگر آسیب‌پذیری یا لایسنس ممنوعه‌ای وارد شود، merge را متوقف می‌کند. در سازمان‌هایی که با لایسنس‌های نرم‌افزاری حساس هستند، این بررسی تفاوت مهمی ایجاد می‌کند.

در پروژه‌های وردپرسی که وابستگی‌ها معمولاً با composer مدیریت می‌شوند، همین منطق اعمال می‌شود. Packageهای composer می‌توانند آسیب‌پذیری داشته باشند یا لایسنس نامناسب وارد کنند. بررسی خودکار در CI، از ورود این وابستگی‌ها جلوگیری می‌کند.

زنجیره‌ی تأمین، در ضعیف‌ترین حلقه‌اش می‌شکند؛ و ضعیف‌ترین حلقه معمولاً وابستگی است که هیچ‌کس آن را بررسی نکرده.

یکپارچگی با GitHub Actions و PR Checkها

GHAS زمانی بیشترین اثر را دارد که به‌عنوان یک PR Check اجباری تنظیم شود. یعنی PR تا زمانی که بررسی‌های امنیتی موفق نشوند، merge نشود. این سخت‌گیری، در نگاه اول سرعت توسعه را کاهش می‌دهد، اما در بلندمدت از ورود آسیب‌پذیری جلوگیری می‌کند.

چند نکته در پیاده‌سازی PR Checkها:

  • Branch protection: اجبار به موفقیت بررسی‌ها پیش از merge.
  • Required status checks: انتخاب بررسی‌های اجباری.
  • Auto-dismiss: رد خودکار تأییدها پس از تغییرات جدید.
  • Stale review dismissal: رد تأییدهای قدیمی پس از commit جدید.
# Branch protection
required_status_checks:
  - "CodeQL / analyze"
  - "Dependency Review"
  - "Test"
dismiss_stale_reviews: true
require_code_owner_reviews: true

در تیم‌های بزرگ، تعریف Code Owners برای مسیرهای حساس باعث می‌شود تغییرات در آن مسیرها نیازمند تأیید افراد مسئول باشد. این ترکیب با بررسی‌های امنیتی، یک لایه‌ی حاکمیتی مؤثر می‌سازد. اصول بازبینی حرفه‌ای در Pull Request در GitHub راهنمای حرفه‌ای آمده است.

Governance و مدیریت دسترسی در سازمان

در سطح سازمان، GHAS چند ابزار برای مدیریت متمرکز ارائه می‌دهد:

  • Security Overview: داشبورد یکپارچه برای مشاهده وضعیت امنیتی همه‌ی مخازن.
  • Organization-level policies: تعریف سیاست‌های امنیتی در سطح سازمان.
  • Security Manager role: نقش اختصاصی برای مدیریت امنیت.
  • Audit Log: ثبت رویدادهای مرتبط با امنیت.

در سازمان‌هایی که چند صد مخزن دارند، مدیریت دستی امنیت غیرعملی است. Security Overview اجازه می‌دهد تیم امنیت، مخازنی که نیاز به توجه دارند را سریع‌تر شناسایی کنند و اقدامات اصلاحی را اولویت‌بندی کنند. این رویکرد، مشابه همان چیزی است که در چرا مدیریت آسیب‌پذیری‌ها در بیشتر سازمان‌ها شکست می‌خورد؟ از زاویه‌ی فرآیندی بررسی شده است.

کاربرد GHAS در پروژه‌های وردپرسی و PHP

پروژه‌های وردپرسی با چند چالش امنیتی مشخص روبرو هستند: افزونه‌های شخص ثالث، قالب‌های قدیمی و کدهای سفارشی که ممکن است الگوهای ناامن داشته باشند. GHAS در این بستر چند کاربرد عملی دارد:

  • CodeQL برای PHP: کشف الگوهای ناامن مثل SQL Injection و XSS.
  • Dependabot برای composer: مدیریت وابستگی‌های PHP و JavaScript.
  • Secret Scanning برای wp-config: جلوگیری از لو رفتن اطلاعات پایگاه داده.
  • Dependency Review برای افزونه‌ها: بررسی لایسنس و امنیت وابستگی‌ها.

در پروژه‌هایی که با افزونه‌های تجاری کار می‌کنید، بررسی خودکار محدودیت دارد چون افزونه‌ها در مخزن نیستند. اما برای کد سفارشی و قالب اختصاصی، GHAS می‌تواند لایه‌ی مهمی از دفاع باشد. اصول امنیتی مرتبط در بهترین افزونه‌های امنیتی وردپرس کدامند؟ بررسی شده است.

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

  • فعال‌سازی بدون سیاست: روشن کردن ابزار بدون تعریف فرآیند رسیدگی به هشدارها.
  • نادیده گرفتن هشدارهای قدیمی: انبار شدن هشدارها و بی‌اعتنایی تدریجی تیم.
  • اجبار اجباری بدون آموزش: تیم باید بداند چگونه هشدار را بخواند و رفع کند.
  • تنظیم آستانه‌ی بیش از حد حساس: انبوه هشدارهای غیرمهم.
  • نادیده گرفتن تست خودکار: Dependabot بدون CI، منبع شکست است.
  • فعال نکردن push protection: سکرت‌ها قبل از کشف وارد مخزن می‌شوند.
  • عدم چرخش سکرت پس از کشف: حذف commit کافی نیست.
  • نادیده گرفتن زنجیره‌ی تأمین اکشن‌ها: Actionهای شخص ثالث منبع ریسک هستند.
  • نداشتن نقش مسئول امنیت: بدون مالک مشخص، فرآیند رها می‌شود.
  • یکسان‌سازی سیاست‌ها برای همه‌ی مخازن: هر مخزن بسته به حساسیت، سیاست متفاوتی نیاز دارد.

این اشتباهات معمولاً در پروژه‌هایی رخ می‌دهد که GHAS را به‌عنوان یک «تیک قالب» فعال کرده‌اند، بدون آنکه فرآیند انسانی پشت آن تعریف شود. امنیت یک فرآیند است، نه یک قابلیت. اصول این نگاه در امنیت وب چیست و چه اصولی دارد؟ بررسی شده است.

پرسش‌های پرتکرار درباره GitHub Advanced Security

GitHub Advanced Security برای چه سازمان‌هایی مناسب است؟ برای سازمان‌هایی که با کد حساس، داده‌ی مشتری یا محصول نرم‌افزاری تجاری کار می‌کنند و به سطح امنیتی بالاتر از ابزارهای پایه نیاز دارند.

آیا CodeQL روی همه‌ی زبان‌ها کار می‌کند؟ پشتیبانی از زبان‌های اصلی مثل JavaScript، Python، Java، C#، Go، Ruby، C++ و PHP ارائه می‌شود. برای زبان‌های خاص‌تر، ممکن است محدودیت وجود داشته باشد.

چطور تعداد هشدارهای CodeQL را کم کنم؟ با تنظیم query suite مناسب، تعریف فایل‌های مستثنی و پاک‌سازی تدریجی کد قدیمی.

تفاوت Secret Scanning و push protection چیست؟ Secret Scanning پس از push مخزن را بررسی می‌کند. Push protection قبل از push جلوی ارسال سکرت را می‌گیرد.

آیا Dependabot جایگزین بررسی دستی وابستگی‌هاست؟ خیر. Dependabot هشدار می‌دهد و به‌روزرسانی پیشنهاد می‌کند، اما ارزیابی تأثیر و تصمیم نهایی همچنان انسانی است.

آیا GHAS روی مخزن خصوصی کار می‌کند؟ بله، اما نیازمند پلن GitHub Enterprise است.

چطور می‌توانم بدون GHAS سطح امنیت را بالا ببرم؟ با ابزارهای متن‌باز مثل Semgrep، Trivy و گیت‌هوک‌های سفارشی، به‌همراه سیاست‌های روشن و آموزش تیم.

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

آیا GHAS با GitHub Actions یکپارچه می‌شود؟ بله، بهترین کاربرد آن زمانی است که به‌عنوان PR Check اجباری تنظیم شود.

آیا GHAS روی پروژه‌های وردپرسی کاربرد دارد؟ بله، به‌ویژه برای کد سفارشی قالب و افزونه. اصول مشابه در امنیت وردپرس چیست و چرا یک روز غفلت، همه‌چیز را می‌سوزاند؟ بررسی شده است.

هزینه‌ی GHAS چقدر است؟ هزینه به تعداد مصرف‌کننده‌های فعال و پلن حساب بستگی دارد. برای اطلاعات دقیق، صفحه‌ی رسمی قیمت‌گذاری GitHub را بررسی کنید.

نگاه مهندسی سطح بالا به امنیت زنجیره‌ی تأمین

از منظر معماری امنیتی، زنجیره‌ی تأمین نرم‌افزار یک سیستم توزیع‌شده با مرزهای نامشخص است. هر وابستگی، یک سرور مستقل با سیاست‌های امنیتی متفاوت است. اعتماد به این زنجیره، بر پایه‌ی چند فرض بنا شده: نگه‌دارنده صادق است، پکیج دستکاری نشده، انتقال امن است و نسخه‌ی مورد استفاده همان است که فرض می‌شود.

در عمل، همه‌ی این فرض‌ها می‌توانند شکسته شوند. حملات supply chain از سال ۲۰۲۰ به بعد رشد چشمگیری داشته‌اند و در چند مورد، پروژه‌های محبوب مستقیماً هدف قرار گرفته‌اند. برای کاهش این ریسک، معماری دفاع چندلایه ضروری است:

  • Lockfile: تثبیت نسخه‌های دقیق وابستگی‌ها.
  • Integrity check: بررسی hash بسته‌ها پیش از نصب.
  • SBOM: تولید فهرست اجزای نرم‌افزار برای ممیزی.
  • Signature verification: بررسی امضای دیجیتال artifactها.
  • Least privilege: محدود کردن دسترسی هر جزء به حداقل لازم.

در سطح معماری CI، استفاده از runnerهای self-hosted با محیط ایزوله می‌تواند سطح حمله را کاهش دهد. در محیط‌های ابری، استفاده از IAM Role با دامنه‌ی محدود، از افشای اعتبارنامه‌های گسترده جلوگیری می‌کند. ترکیب این لایه‌ها با ابزارهای GHAS، یک سیستم دفاع چندگانه می‌سازد.

در سطح مدل‌سازی تهدید، هر پروژه باید یک نقشه‌ی مشخص از دارایی‌های حساس، مهاجم‌های بالقوه و سطح حمله‌ی هر جزء داشته باشد. بدون این نقشه، تلاش‌های امنیتی پراکنده و ناکارآمد می‌شوند. اصول این نوع تحلیل با آنچه در انواع آسیب‌پذیری‌های رایج وب کدامند؟ توضیح داده شده، هم‌راستاست.

در لایه‌ی عملیاتی، مدیریت حادثه (Incident Response) بخشی از استراتژی امنیت است. سازمان‌هایی که سناریوهای مشخص برای واکنش به نشت سکرت، انتشار آسیب‌پذیری صفر‌روز یا حمله زنجیره‌ی تأمین دارند، سریع‌تر و مؤثرتر واکنش نشان می‌دهند. اصول این حوزه با آنچه در آسیب‌پذیری Zero Day چیست؟ بررسی شده، هم‌راستاست. 🧩

در نهایت، از منظر اقتصادی، امنیت یک سرمایه‌گذاری است با بازده نامشخص در کوتاه‌مدت و اثر مشخص در بلندمدت. هزینه‌ی یک حادثه‌ی امنیتی معمولاً چند برابر هزینه‌ی پیشگیری است. سازمان‌هایی که این محاسبه را جدی می‌گیرند، حتی پیش از وقوع حادثه، سرمایه‌گذاری روی امنیت را توجیه‌پذیر می‌بینند. 📊

بستن بحث

GitHub Advanced Security مجموعه‌ای از ابزارهای قدرتمند است که وقتی با فرآیند درست و سیاست روشن ترکیب شود، سطح امنیت یک پروژه یا سازمان را به‌طور محسوس بالا می‌برد. اما فعال‌سازی ساده، کافی نیست. باید مالک مشخصی برای فرآیند وجود داشته باشد، آموزش تیم جدی گرفته شود و هشدارها با سرعت معقول رسیدگی شوند.

اگر در ابتدای مسیر هستید، از Secret Scanning و Dependabot شروع کنید؛ این دو سریع‌ترین اثر را دارند و کمترین اصطکاک را با فرآیند فعلی ایجاد می‌کنند. به‌تدریج CodeQL را اضافه کنید و با پاک‌سازی کد، نرخ هشدارها را کنترل کنید. اگر در سازمان بزرگ کار می‌کنید، Security Overview و نقش Security Manager به مدیریت متمرکز کمک می‌کنند.

اگر تجربه‌ای از پیاده‌سازی GHAS در پروژه‌ای واقعی دارید، برایم جالب است بدانید کدام بخش بیشترین اثر را روی کاهش آسیب‌پذیری داشت. تجربه‌تان را در دیدگاه‌ها بنویسید؛ به‌خصوص اگر رویکرد جایگزینی برای مدیریت امنیت زنجیره‌ی تأمین پیدا کرده‌اید.