GitHub Repository را Public کنیم یا Private؟

اولین سوال هنگام ساخت مخزن روی GitHub اغلب ساده به نظر می‌رسد: Public یا Private؟ پاسخ به مدل محصول، میزان حساسیت کد و داده، نیاز به همکاری بیرونی، و آمادگی‌تان برای پایش Secret بستگی دارد — نه به مد روز «همه‌چیز باید Open Source باشد» یا ترس مبهم «اگر Private نباشد دزدیده می‌شود».

طبق مستندات GitHub دربارهٔ مخازن، می‌توانید دسترسی را با انتخاب دیدپذیری محدود کنید: مخزن Public برای همه در اینترنت قابل دسترسی است؛ مخزن Private فقط برای شما، کسانی که صریح دسترسی داده‌اید، و در مخازن سازمانی برخی اعضای سازمان. در GitHub Enterprise Cloud نوع Internal هم وجود دارد که خارج از محدودهٔ این تصمیم دوتایی روزمره است.

این مقاله معیارهای امنیت، همکاری، Open Source، و ریسک نشت را کنار هم می‌گذارد تا بتوانید برای هر مخزن جدا تصمیم بگیرید — نه یک قانون برای کل سازمان.

پاسخ کوتاه

اگر کد باید برای عموم قابل Clone/خواندن باشد (کتابخانهٔ متن‌باز، نمونهٔ آموزشی، پروژهٔ جامعه)، Public منطقی است — به‌شرطی که Secret، دادهٔ مشتری و کلید داخلش نباشد و پایش نشت فعال باشد. اگر کد مالکیتی، منطق کسب‌وکار حساس، یا وابستگی به دادهٔ داخلی دارد، پیش‌فرض Private است و دسترسی را حداقلی بدهید.

Private به‌معنی «امن مطلق» نیست. GitHub صریحاً می‌گوید حتی با محدودیت دسترسی، کنترل دسترسی قوی، احراز هویت چندمرحله‌ای و ممیزی منظم لازم است. Public هم لزوماً بی‌پروا نیست: با Secret Scanning، Push Protection، سیاست گزارش آسیب‌پذیری (SECURITY.md) و انضباط .gitignore می‌توان ریسک را کم کرد — اما سطح حملهٔ مشاهدهٔ کد بزرگ‌تر است.

دیدپذیری را با حساسیت محتوا و مدل همکاری تنظیم کنید؛ Private جای انضباط Secret را نمی‌گیرد و Public جای طراحی امن را.

تعریف رسمی دیدپذیری

• Public: هر کسی روی اینترنت می‌تواند مخزن را ببیند (و بسته به تنظیمات، Fork کند).
• Private: فقط مالک و کسانی که صریح دعوت شده‌اند (و قواعد عضویت سازمان).
• تغییر دیدپذیری برای کسانی با دسترسی Admin ممکن است؛ در سازمان می‌توان این تغییر را محدود کرد.

مالکان سازمان معمولاً به همهٔ مخازن سازمان دسترسی دارند. یعنی «Private برای هم‌تیمی مخفی» با «Private از اینترنت» فرق دارد. قبل از گذاشتن Secret حتی در Private، بدانید چه کسانی عضو سازمان‌اند.

جدول تصمیم سریع

امنیت: Public چه ریسکی دارد؟

مستندات GitHub در بخش ملاحظات امنیتی دیدپذیری می‌گوید مخازن Public کدبیس را در معرض همه قرار می‌دهند و ریسک بهره‌برداری از آسیب‌پذیری یا دسترسی به اطلاعات حساس را بالا می‌برند. کاهش ریسک پیشنهادی رسمی شامل فعال‌سازی قابلیت‌هایی مثل Dependabot، secret scanning، push protection و code scanning است، به‌علاوهٔ افزودن سیاست امنیتی (SECURITY.md) برای گزارش آسیب‌پذیری.

ترجمهٔ عملی: اگر Public می‌روید، فرض کنید هر Commit را مهاجم هم می‌خواند. الگوریتم ضعیف، درِ پشتی آزمایشی، و کلید تستی که اتفاقاً به محیط واقعی وصل است، همه可见 می‌شوند. Public بودن با «امنیت از طریق مبهم‌بودن» ناسازگار است — که در واقع همیشه هم ضعیف بود.

امنیت: Private چه توهمی می‌سازد؟

Private فقط اینترنت را از Clone ناشناس محروم می‌کند. هنوز این‌ها می‌توانند Secret را بیرون ببرند: لپ‌تاپ دزدیده‌شده با Session، پیمانکار با دسترسی زیاد، اشتباه Admin در تغییر به Public، Fork داخلی کنترل‌نشده، و لاگ CI. به همین دلیل GitHub در راهنمای جلوگیری از نشت داده روی 2FA اجباری، محدود کردن Fork/تغییر دیدپذیری/ساخت مخزن، محدود کردن PAT، و پایش با secret scanning و audit log تأکید می‌کند.

اشتباه کلاسیک تیم‌های کوچک ایرانی: «مخزن Private است پس API Key داخل کد اشکالی ندارد.» مقالهٔ ۰۴۷ و ۰۸۱ خلاف این را می‌گویند؛ Private بودن litmus test دوازده‌عاملی را عوض نمی‌کند.

همکاری و Open Source

Public برای جذب مشارکت، شفافیت رزومهٔ فنی، و اعتماد مشتری به «ما چیزی برای پنهان کردن در این لایه نداریم» مفید است. مدل Fork and pull در GitHub برای OSS طراحی شده: دیگران Fork می‌کنند و Pull Request می‌فرستند. هزینه: مدیریت Issue، Code of Conduct، و مسئولیت پاسخ به آسیب‌پذیری عمومی.

Private برای همکاری کنترل‌شده با کارکنان و پیمانکاران بهتر است. می‌توانید خارج‌همکار (outside collaborator) اضافه کنید بدون اینکه کل اینترنت بخواند. هزینه: onboarding دسترسی، و خطر انباشت دسترسی بعد از پایان قرارداد.

اگر بخشی از محصول باید متن‌باز و هسته Private بماند، دو مخزن جدا با مرز واضح بهتر از یک مخزن Public با پوشهٔ «لطفاً نگاه نکنید» است.

نشت Secret و دیدپذیری

طبق About secret scanning، این قابلیت برای مخازن Public به‌صورت رایگان و خودکار اجرا می‌شود و به جلوگیری از سوءاستفاده از credentialهای hard-coded کمک می‌کند. برای بسیاری از مخازن Private سازمانی به GitHub Secret Protection / طرح مناسب وابسته است. Push protection برای کاربران روی GitHub.com به‌صورت پیش‌فرض جلوی Push Secret به مخازن Public را می‌گیرد؛ برای مخازن خاص می‌توان سطح مخزن/سازمان را هم فعال کرد.

پیام تصمیم: Public بودن یعنی نشت سریع‌تر دیده و گاهی توسط Partner باطل می‌شود — اما قبل از باطل شدن هم در تاریخچهٔ عمومی مانده است. Private بودن ممکن است نشت را دیرتر علنی کند، نه اینکه آن را بی‌اثر کند. در هر دو حالت، اقدام اول پس از نشت Rotate است (مقالهٔ ۰۸۲).

کنترل‌های سازمانی مرتبط با دیدپذیری

راهنمای Best practices for preventing data leaks پیشنهادهایی دارد که مستقیماً به این تصمیم وصل می‌شوند:

• محدود یا غیرفعال کردن امکان Fork در صورت نیاز.
• محدود کردن تغییر دیدپذیری مخزن.
• محدود کردن ساخت مخزن به Private/Internal.
• تبدیل مخازن Public نامناسب به Private وقتی محتوا حساس است.
• الزام 2FA برای اعضا.
• فعال نگه داشتن push protection برای کاربران.

این‌ها جایگزین فکر کردن دربارهٔ هر مخزن نیستند؛ لایه‌ای هستند تا اشتباه یک کلیک کل سازمان را Public نکند.

چک‌لیست قبل از Public کردن

1. تاریخچه را برای Secret، .env، dump و کلید خصوصی بگردید — نه فقط فایل‌های فعلی.
2. اطمینان از نبود دادهٔ واقعی مشتری یا PII.
3. فعال بودن secret scanning و در صورت امکان push protection.
4. وجود LICENSE و در صورت نیاز SECURITY.md.
5. README که بگوید چه چیزی عمداً Public است و چه چیزی نیست.
6. برنامهٔ پاسخ اگر فردا کلید در Issue عمومی Paste شد.

چک‌لیست قبل از اعتماد به Private

1. فهرست دسترسی‌ها را هر فصل مرور کنید؛ پیمانکار تمام‌شده را حذف کنید.
2. 2FA را برای حساب‌های دارای Write اجباری کنید.
3. Secret را از کد جدا کنید؛ Private را بهانهٔ hard-code نکنید.
4. تغییر دیدپذیری را در سازمان قفل کنید اگر ریسک انسانی بالاست.
5. Audit log را برای رویدادهای حساس بشناسید.

جمع‌بندی برای تصمیم

Public یعنی خواندن برای اینترنت باز است؛ برای OSS و شفافیت لایهٔ غیرحساس عالی است و سطح مشاهدهٔ آسیب‌پذیری را بالا می‌برد. Private یعنی دسترسی دعوت‌محور؛ برای کد تجاری پیش‌فرض درست است ولی امنیت را تضمین نمی‌کند. GitHub برای هر دو مسیر ابزار پایش و پیشگیری Secret دارد؛ مسئولیت انضباط با شماست.

یک قاعدهٔ عملی: پیش‌فرض سازمان را Private بگذارید، و Public را فقط برای مخازنی روشن کنید که از چک‌لیست بالا عبور کرده‌اند.

سناریوهای تصمیم واقعی

استارتاپ B2B با منطق قیمت‌گذاری اختصاصی: هسته را Private بگذارید. اگر می‌خواهید SDK مشتری متن‌باز باشد، مخزن جدا با سطح API پایدار و بدون Secret. پیوند دادن هر دو در یک مونورپوی Public ریسک اشتباه مسیر را بالا می‌برد.

تیم آموزشی: Public برای تمرین و شفافیت مفید است، به‌شرط پاکسازی دادهٔ واقعی و کلیدهای ابری. قالب تمرین را از ابتدا با secret scanning چک کنید.

پیمانکار خارجی روی فیچر حساس: Private با همکار بیرونی محدود به همان مخزن، نه دعوت به کل سازمان. بعد از قرارداد، دسترسی و در صورت نیاز کلیدها را بچرخانید.

Internal visibility در یک نگاه

در GitHub Enterprise Cloud، مخازن Internal می‌توانند برای اعضای سازمانی دیده شوند بدون اینکه اینترنت عمومی بخواند. اگر سازمان شما این طرح را دارد، Internal گاهی میانهٔ بهتری برای کتابخانه‌های مشترک داخلی است. اگر ندارید، تصمیم همان دوتایی Public و Private می‌ماند.

تغییر دیدپذیری بعد از انتشار

از Public به Private رفتن محتوا را از اینترنت جمع نمی‌کند: Forkها، Mirrorها و آرشیوها ممکن است کپی داشته باشند. Secretای که وقتی Public بود نشت کرده را باید Rotate کنید؛ Private کردن کافی نیست. از Private به Public رفتن بدون اسکن تاریخچه یکی از کلاسیک‌ترین حوادث است.

قبل از Public کردن، علاوه بر Secret به License، علامت تجاری و دادهٔ شخص ثالث داخل مخزن فکر کنید. کد شما ممکن است شامل دارایی‌ای باشد که حق انتشار عمومی‌اش را ندارید.

همکاری و اعتماد

بعضی مشتری‌ها متن‌باز بودن بخش‌هایی از سامانه را نشانهٔ اعتماد می‌دانند؛ بعضی دیگر می‌پرسند چرا منطق تجاری آشکار است. با محصول و حقوقی هم‌تراز کنید نه با مد مهندسی. تصمیم دیدپذیری یک تصمیم محصولی-امنیتی است.

چک‌لیست فصلی سازمان

1. فهرست مخازن Public را مرور کنید؛ آیا هنوز باید Public باشند؟
2. مخازن Private با تعداد همکار زیاد را از نظر حداقل دسترسی ببینید.
3. سیاست Fork و تغییر Visibility را بازبینی کنید.
4. وضعیت secret scanning و push protection را نمونه‌گیری کنید.
5. آموزش کوتاه onboarding دربارهٔ env و دیدپذیری را تازه نگه دارید.

منابع و مراجع

• GitHub Docs — About repositories (visibility & security considerations) — https://docs.github.com/en/repositories/creating-and-managing-repositories/about-repositories
• GitHub Docs — Best practices for preventing data leaks in your organization — https://docs.github.com/en/code-security/getting-started/best-practices-for-preventing-data-leaks-in-your-organization
• GitHub Docs — About secret scanning — https://docs.github.com/en/code-security/secret-scanning/introduction/about-secret-scanning
• GitHub Docs — Push protection — https://docs.github.com/en/code-security/concepts/secret-security/push-protection

ادعاهای امنیتی این صفحه فقط از مستندات رسمی GitHub آمده‌اند؛ تنظیمات دقیق طرح/نسخه را در همان لحظه در docs و پنل حساب خودتان核对 کنید.