Secret Scanning گیت هاب چیست؟ راهنمای کامل Public Monitoring و واکنش به نشت کلید
نشت یک API Key همیشه داخل مخزن اصلی شرکت رخ نمی دهد. ممکن است توسعه دهنده آن را در Fork شخصی، Issue عمومی، Pull Request یا پروژه آزمایشی قرار دهد. Public Monitoring گیت هاب دقیقاً برای همین نقطه کور ساخته شده است: پیدا کردن Secretهای مرتبط با یک Enterprise در سراسر سطح عمومی GitHub، حتی وقتی مخزن متعلق به خود سازمان نیست.
در یک نگاه
- Secret Scanning تاریخچه Git و محتوای مخزن را برای Credentialهای شناخته شده بررسی می کند.
- Public Monitoring دامنه بررسی را به مخازن عمومی سراسر GitHub گسترش می دهد.
- اتصال یافته به Enterprise از طریق عضویت کاربر یا دامنه ایمیل تأییدشده انجام می شود.
- حذف Secret از فایل کافی نیست؛ Credential باید فوراً Rotate یا Revoke شود.
- Push Protection بهترین لایه پیشگیرانه برای متوقف کردن نشت قبل از Commit است.
Secret Scanning چیست و چرا فقط یک جست وجوی متن ساده نیست؟
Secret به Credential حساسی گفته می شود که امکان دسترسی به یک سرویس را فراهم می کند؛ مانند API Key، Access Token، Private Key، رمز، Connection String یا Token سرویس ابری. Secret Scanning گیت هاب الگوهای شناخته شده این Credentialها را در تاریخچه Git، شاخه ها و محتوای مخزن پیدا می کند. این سیستم با فهرست بزرگی از Providerها و Patternها کار می کند و هنگام اضافه شدن نوع جدید، مخازن را دوباره بررسی می کند.
تفاوت با جست وجوی ساده در شناخت ساختار Secret است. بسیاری از Tokenها Prefix، طول، Checksum یا Metadata مشخص دارند. GitHub می تواند نوع Credential و صادرکننده آن را تشخیص دهد، بعضی Secretها را اعتبارسنجی کند و در موارد Partner Alert، یافته را مستقیماً به Provider گزارش دهد. این فرایند به تیم کمک می کند میان یک رشته تصادفی و Credential واقعی اولویت بندی بهتری داشته باشد.
| نوع هشدار | مخاطب اصلی | رفتار |
|---|---|---|
| User Alert | مالک یا مدیر مخزن | یافته در بخش Security and quality نمایش داده می شود |
| Push Protection Alert | توسعه دهنده و تیم امنیت | Secret قبل از ورود به مخزن متوقف یا Bypass آن ثبت می شود |
| Partner Alert | صادرکننده Secret | GitHub یافته عمومی را به Provider گزارش می دهد تا واکنش انجام شود |
Secret Sprawl چیست؟
Secret Sprawl یعنی Credentialها بدون کنترل در فایل ها، مخازن، Scriptها، پیام ها و محیط های مختلف پخش شوند. یک کلید ممکن است ابتدا برای تست ساخته شود، بعد در فایل تنظیمات بماند، در چند Branch کپی شود و سرانجام داخل نمونه کد یا Issue عمومی قرار بگیرد. هرچه تعداد نسخه ها بیشتر شود، Rotate کردن و تشخیص مالک آن دشوارتر خواهد شد.
Public Monitoring چه چیزی به Secret Scanning اضافه می کند؟
Secret Scanning سنتی روی مخازنی تمرکز دارد که سازمان یا Enterprise مالک آن هاست. Public Monitoring مرز مالکیت مخزن را کنار می زند و سطح عمومی GitHub را برای Secretهای مرتبط با Enterprise بررسی می کند. بنابراین اگر کارمند شرکت، Credential سازمانی را در یک Repository عمومی شخصی یا مخزن متعلق به فرد دیگری قرار دهد، هشدار می تواند در Security Overview سطح Enterprise ظاهر شود.
GitHub این قابلیت را در 1 ژوئیه 2026 به صورت Public Preview برای Enterpriseهایی که GitHub Secret Protection دارند عرضه کرد. Public Preview یعنی قابلیت قابل استفاده است، اما API، رابط یا جزئیات آن ممکن است تغییر کند. در 15 ژوئیه نیز GitHub Insight Cardهایی برای Alert List اضافه کرد که Attribution، تعداد اعضا و دامنه های تأییدشده را بهتر نشان می دهند.
Public Monitoring به این سؤال پاسخ می دهد: «Secretهای شرکت بیرون از مخازن شرکت کجا لو رفته اند؟»
GitHub نشت را چگونه به Enterprise نسبت می دهد؟
پیداکردن یک Token در مخزن عمومی کافی نیست؛ GitHub باید تشخیص دهد آن یافته به کدام Enterprise مربوط است. Public Monitoring از دو روش Attribution استفاده می کند. روش اول عضویت Enterprise است: اگر کاربری که Secret را منتشر کرده عضو Enterprise باشد، یافته می تواند به همان مجموعه نسبت داده شود. روش دوم تطبیق دامنه ایمیل تأییدشده است: حتی اگر کاربر عضو مستقیم نباشد، ایمیل Commit با دامنه Verify شده شرکت تطبیق داده می شود.
روش دوم برای پیمانکاران، حساب های جانبی و کاربرانی که هنوز وارد Enterprise نشده اند اهمیت دارد. بااین حال، کیفیت Attribution به تنظیم درست Verified Domain وابسته است. سازمانی که دامنه های خودش را ثبت نکرده، بخش مهمی از دید Public Monitoring را از دست می دهد. GitHub نیز پیش از فعال سازی توصیه می کند حداقل یک دامنه تأییدشده داشته باشید.
| روش Attribution | شرط | نمونه |
|---|---|---|
| Enterprise Membership | منتشرکننده عضو Enterprise باشد | کارمند در مخزن عمومی شخصی Token را Commit کرده است |
| Verified Domain | ایمیل Commit با دامنه تأییدشده مطابقت داشته باشد | پیمانکار با ایمیل سازمانی Secret را در پروژه متن باز قرار داده است |
Public Monitoring چه محتواهایی را بررسی می کند؟
دامنه بررسی فقط فایل کد نیست. مستندات رسمی GitHub می گویند Public Monitoring مخازن عمومی و محتوای غیرکدی مانند Commentهای Issue و Pull Request را نیز اسکن می کند. این موضوع مهم است؛ چون توسعه دهنده ممکن است برای توضیح یک خطا، Log یا نمونه درخواست را در Comment قرار دهد و ناخواسته Authorization Header را منتشر کند.
- فایل ها و تاریخچه مخازن عمومی
- Commitهای مرتبط با اعضا یا دامنه سازمان
- Issue Commentها
- Pull Request Commentها
- Fork و مخازن عمومی خارج از مالکیت Enterprise
این گستردگی به معنای پوشش صددرصد نیست. Secret سفارشی با الگوی ناشناخته، Credential رمزنگاری شده یا رشته ای که به درستی شناسایی نشود ممکن است از اسکن عبور کند. برای Tokenهای داخلی باید Custom Pattern تعریف شود و فرایندهای دیگری مانند DLP، Log Monitoring و محدودیت شبکه نیز کنار Secret Scanning قرار بگیرند.
بعد از دریافت هشدار Secret چه کنیم؟
اولین واکنش نباید پاک کردن فایل باشد. فرض امنیتی درست این است که هر Secret عمومی قبلاً دیده و کپی شده است. حتی اگر Commit فقط چند ثانیه عمومی بوده، Crawlerها می توانند آن را ثبت کنند. بنابراین Credential باید فوراً Revoke یا Rotate شود. Revoke یعنی دسترسی قبلی کاملاً باطل شود؛ Rotate یعنی Credential تازه ساخته و نسخه قدیمی غیرفعال شود.
- اعتبار Secret را بررسی کنید: Provider، مالک، محیط و سطح دسترسی را مشخص کنید.
- فوراً Revoke یا Rotate کنید: نسخه قبلی نباید قابل استفاده بماند.
- Logها را بررسی کنید: IP، زمان، Endpoint و عملیات مشکوک را پیدا کنید.
- دامنه آسیب را مشخص کنید: Secret به Production، داده مشتری یا عملیات نوشتن دسترسی داشته است؟
- منبع نشت را پاک سازی کنید: فایل، History، Comment یا Artifact را اصلاح کنید.
- نسخه های دیگر را جست وجو کنید: همان Secret ممکن است در چند مخزن یا Log وجود داشته باشد.
- Incident را ثبت کنید: علت، Timeline، اقدام و پیشگیری را مستند کنید.
آیا باید Git History را بازنویسی کنیم؟
پس از Revoke، پاک کردن Secret از History برای کاهش انتشار و رعایت سیاست سازمان مفید است، اما عملیات پرهزینه ای است. بازنویسی History می تواند Hashها را تغییر دهد و Cloneها یا Branchهای دیگر را ناسازگار کند. اگر Secret باطل شده، خطر دسترسی قبلی کنترل شده است. تصمیم پاک سازی باید براساس حساسیت، Compliance و دامنه انتشار گرفته شود.
چطور جلوی نشت دوباره را بگیریم؟
Secret Scanning ابزار تشخیص است، اما بهترین Incident همان Incidentی است که رخ نمی دهد. Push Protection هنگام Push تلاش می کند Credential را شناسایی و قبل از ورود به مخزن متوقف کند. اگر کاربر Bypass کند، دلیل و رویداد باید قابل بررسی باشد. تیم امنیت می تواند Bypass را به فرایند تأیید یا بررسی پس از Push متصل کند.
- Secretها را در Secret Manager یا Vault نگه دارید.
- برای محیط محلی از فایل های خارج از Git و Template بدون مقدار استفاده کنید.
- Credentialها را کوتاه عمر و با حداقل مجوز بسازید.
- Push Protection را برای مخازن حساس اجباری کنید.
- برای Secretهای داخلی Custom Pattern تعریف کنید.
- Credentialهای Production را از Test جدا کنید.
- Webhook هشدار را به SIEM یا فرایند Incident متصل کنید.
.env
.env.*
secrets.json
appsettings.Production.json
*.pfx
*.pem
Gitignore فقط از Commit ناخواسته فایل های مشخص جلوگیری می کند و جایگزین Secret Manager نیست. فایل ممکن است قبل از اضافه شدن Rule وارد History شده باشد یا کاربر با Force آن را Commit کند. همچنین Secret می تواند داخل Source Code، Issue یا Log قرار بگیرد. بنابراین Gitignore فقط یکی از لایه هاست.
Public Monitoring را چگونه برای Enterprise فعال کنیم؟
طبق مستندات GitHub، Enterprise باید GitHub Advanced Security یا GitHub Secret Protection فعال داشته باشد. این قابلیت برای GitHub Enterprise Cloud ارائه شده و در محیط Data Residency در دسترس نیست. داشتن Verified Domain اجباری نیست، اما برای Attribution کامل توصیه می شود.
- وارد صفحه Enterprise شوید.
- Settings را باز کنید.
- به بخش Advanced Security یا Code security بروید.
- در Additional Settings، گزینه Public monitoring را فعال کنید.
- Security Overview و Alert List را بررسی کنید.
- مالک پاسخ گویی، SLA و مسیر Escalation تعریف کنید.
فعال سازی فنی پایان کار نیست. اگر Alert بدون Owner بماند، ابزار فقط فهرست خطر تولید می کند. بهتر است برای Secretهای Production زمان پاسخ کوتاه، برای Test Credential اولویت پایین تر و برای Secret نامشخص مسیر Triage تعریف شود. Insightهای Enterprise نیز برای شناخت الگوی نشت و تیم های پرریسک استفاده شوند.
محدودیت ها و خطاهای رایج در استفاده از Secret Scanning
- اعتماد به حذف فایل: Secret عمومی باید باطل شود.
- نادیده گرفتن False Positive: Alert باید Triage شود، نه اینکه کورکورانه بسته شود.
- نداشتن Verified Domain: Attribution خارج از عضویت Enterprise ناقص می شود.
- نداشتن Owner: هشدار بین تیم امنیت و توسعه رها می شود.
- Secretهای داخلی ناشناخته: بدون Custom Pattern شناسایی نمی شوند.
- کلیدهای بلندمدت: دامنه آسیب یک نشت را افزایش می دهند.
- تمرکز فقط روی Repository: Comment، Artifact و Log نیز می توانند منبع نشت باشند.
پرسش های متداول
Public Monitoring با Secret Scanning معمولی چه تفاوتی دارد؟
Secret Scanning معمولی مخازن تحت مالکیت سازمان را بررسی می کند. Public Monitoring مخازن و محتوای عمومی سراسر GitHub را برای Secretهای مرتبط با اعضا یا دامنه سازمان اسکن می کند.
آیا حذف Commit مشکل را حل می کند؟
خیر. اگر Secret عمومی شده، باید فرض کنید کپی شده است. ابتدا Credential را Revoke یا Rotate کنید و سپس History را پاک سازی کنید.
آیا Issue و Pull Request Comment هم اسکن می شوند؟
بله. Public Monitoring محتوای غیرکدی عمومی مانند Commentهای Issue و Pull Request را نیز در دامنه اسکن قرار می دهد.
آیا این قابلیت رایگان است؟
Public Monitoring برای Enterpriseهای واجد شرایط با GitHub Secret Protection در Public Preview بدون هزینه اضافه معرفی شد. شرایط و قیمت باید از صفحه رسمی فعلی بررسی شود.
بهترین راه پیشگیری چیست؟
ترکیب Secret Manager، Credential کوتاه عمر، حداقل مجوز، Push Protection، Custom Pattern و آموزش تیم بهترین پوشش را ایجاد می کند.
معیارهای عملیاتی که باید اندازه بگیرید
فعال کردن اسکن پایان کار نیست. تیم امنیت باید زمان میان ایجاد Alert تا Revoke شدن Credential، درصد Alertهای دارای Owner، تعداد نشت های تکراری هر Repository و سهم Push Protection در جلوگیری پیش از Commit را اندازه بگیرد. اگر زمان واکنش بالا بماند، افزایش Detectorها فقط صف هشدار را بزرگ تر می کند. همچنین بهتر است Incidentهای واقعی به آموزش کوتاه و اصلاح فرایند منتهی شوند؛ مثلاً افزودن Secret Manager به Template پروژه یا حذف Credentialهای بلندعمر از مستندات توسعه.
این شاخص ها کمک می کنند مسئله از «داشتن ابزار» به «کاهش واقعی ریسک» تبدیل شود. هدف نهایی کم شدن زمان اعتبار Secret افشاشده و جلوگیری از تکرار همان الگو است، نه فقط بسته شدن Alert در داشبورد.
جمع بندی سریع
- Public Monitoring نقطه کور مخازن عمومی خارج از سازمان را پوشش می دهد.
- Attribution از عضویت Enterprise و Verified Domain استفاده می کند.
- نخستین واکنش به نشت، Revoke یا Rotate است.
- Push Protection و Secret Manager باید قبل از Incident فعال باشند.
- Alert بدون Owner و SLA ارزش عملی محدودی دارد.
برای جزئیات رسمی، مستندات Public Monitoring گیت هاب، راهنمای Secret Scanning و بهبودهای ژوئیه 2026 را ببینید. برای آشنایی با مسئولیت های حرفه ای توسعه دهنده نیز مطلب برنامه نویس کیست؟ را بخوانید. همین امروز یک Credential آزمایشی را از مسیر ایجاد تا Rotate در تیم خود مستند کنید.
