مقدمه
گزارش رسمی GitHub در ۵ نوامبر ۲۰۲۶ یک به‌روزرسانی محدود اما معنادار برای Secret scanning (پویش اسرار) معرفی می‌کند. طبق همان اعلامیه، SpaceX به برنامهٔ شراکت Secret scanning پیوسته و شناساگر starlink_public_api_v2_secret برای تشخیص این نوع اعتبارنامه افزوده شده است. هم‌زمان، GitHub برای شناساگرهای Alibaba، AWS، Google، OpenVSX، Pydantic Services و Tencent پالایش‌های تازه‌ای انجام داده تا تطبیق‌های کاذب کمتری ایجاد شود. این تغییر را باید به‌عنوان بهبود پوشش و کیفیت تشخیص خواند، نه به‌عنوان حذف کامل خطر افشای اعتبارنامه.
این گزارش دو منبع رسمی را کنار هم می‌گذارد. بخش‌های «واقعیت منبع» خلاصهٔ مستقیم همان صفحات‌اند و «تحلیل تحریریه» برداشت عملی بر پایهٔ آن‌هاست. در منابع، CVE یا CVSS برای این تغییر اعلام نشده؛ بنابراین چنین مشخصاتی نسبت داده نمی‌شود.
خبر دقیق چیست؟
واقعیت منبع: شریک و شناساگر جدید
GitHub اعلام کرده است که SpaceX اکنون شریک Secret scanning است. نوع سرّی معرفی‌شده در جدول رسمی، starlink_public_api_v2_secret نام دارد. در توضیح برنامه آمده است که وقتی یک رازِ شریک در یک مخزن عمومی پیدا شود، GitHub آن را به صادرکنندهٔ راز گزارش می‌کند تا صادرکننده بتواند پیش از سوءاستفاده، اعتبارنامه را باطل (revoke) یا چرخش‌پذیر/تعویض (rotate) کند. همان نوع سرّ در بخش شناساگرهای افزوده‌شده نیز تکرار شده است؛ یعنی این مورد هم در پوشش تشخیص خودکار قرار گرفته و هم در مسیر اطلاع‌رسانی شریک جای می‌گیرد.
این نکته با هشدار مهم مستندات تفاوت دارد: اسرار شریک مستقیماً به ارائه‌دهنده گزارش می‌شوند و در هشدارهای مخزن نمایش داده نمی‌شوند؛ در مقابل، اسرار کاربر وقتی در مخزن عمومی یا خصوصی پیدا شوند، هشدار Secret scanning ایجاد می‌کنند. بنابراین، نبودن هشدار قابل مشاهده در صفحهٔ مخزن لزوماً به معنای نبودن رخداد گزارش‌شده به شریک نیست.
واقعیت منبع: اصلاح شش خانوادهٔ شناساگر
اعلامیه برای شش ارائه‌دهنده، کاهش تطبیق کاذب را ثبت کرده است. در Alibaba، برای alibaba_cloud_access_key_id، وقتی پالایش واژه‌نامه همهٔ اسرار همراه معتبر را حذف کند، تطبیقِ بدون جفت سرکوب می‌شود. همین منطق برای aws_access_key_id، aws_session_token و aws_temporary_access_key_id در AWS به کار رفته است. برای Google نیز سه نوع google_cloud_storage_access_key_secret، google_cloud_storage_service_account_access_key_id و google_cloud_storage_user_access_key_id در همین خانوادهٔ پالایش قرار گرفته‌اند.
در OpenVSX، تطبیق زمینه‌ای برای توکن‌های قدیمی سخت‌گیرانه‌تر شده تا یک UUID نامرتبط به‌عنوان اعتبارنامه تلقی نشود. در Pydantic Services، نوع logfire_token باید طول و مجموعه‌کاراکتر مستندشده را رعایت کند؛ هدف اعلام‌شده، کنار گذاشتن مقدارهای جای‌نگهدار و توکن‌های عمومی مرورگر است. در Tencent، نوع tencent_cloud_secret_id اکنون بعد از پیشوند توکن به وجود هم‌زمان حرف و رقم نیاز دارد تا شناسه‌های فقط‌حرفی، مانند نام تابع، کنار گذاشته شوند.
معماری و مسیر تشخیص
دامنهٔ اسکن
مستندات GitHub می‌گوید Secret scanning کل تاریخ Git مخزن را در همهٔ شاخه‌ها برای اعتبارنامه‌های سخت‌کدشده بررسی می‌کند. نمونه‌های ذکرشده شامل کلیدهای API، گذرواژه‌ها، توکن‌ها و انواع شناخته‌شدهٔ دیگرِ راز است. این دامنه فقط آخرین نسخهٔ فایل نیست؛ تاریخچهٔ شاخه‌ها نیز در مدل توضیح‌داده‌شده قرار دارد. GitHub همچنین مخزن‌ها را هنگام افزوده‌شدن نوع‌های جدید راز، به‌صورت دوره‌ای دوباره پویش می‌کند. از دید عملی، این بازپویش همان دلیلی است که تیم نباید روی «قدیمی بودن commit» یا حذف خط مشی راز از فایل فعلی حساب کند.
سطح‌های دیگری هم در مستندات آمده‌اند: توضیح و نظر issueها، عنوان و توضیح و نظر pull requestها، از جمله issueهای تاریخیِ باز و بسته، گفت‌وگوهای GitHub، ویکی‌ها و secret gistها. در نتیجه، کنترل نشت فقط وظیفهٔ بررسی فایل‌های کد نیست؛ متن عملیاتی، نمونهٔ پیکربندی، قطعه‌کد آموزشی و گفت‌وگوی بازبینی نیز باید با همان حساسیت مدیریت شوند.
سه لایهٔ منطقی
می‌توان معماری مفهومی این سرویس را در سه لایه دید. لایهٔ نخست، جمع‌آوری سطح حمله است: تاریخچهٔ Git، شاخه‌ها و محتوای متنی جانبی که مستندات نام می‌برند. لایهٔ دوم، شناساگر است: الگوهای ارائه‌دهنده‌محور، الگوهای عمومی و الگوهای سفارشی. لایهٔ سوم، اولویت‌بندی و پاسخ است: هشدار مخزن برای موارد قابل نمایش، بررسی اعتبار برای تشخیص فعال‌بودن احتمالی راز، و مسیر شریک برای گزارش مستقیم به صادرکننده.
شریک، کاربر و ارائه‌دهنده
در مستندات، راز شریک هنگامی که شناسایی شود به ارائه‌دهنده اطلاع داده می‌شود و در هشدار مخزن نمایش داده نمی‌شود. اعلامیهٔ SpaceX همین سازوکار را برای راز شریک توضیح می‌دهد. در مقابل، رازهای کاربر در مخزن عمومی یا خصوصی هشدار Secret scanning می‌سازند. این تفاوت، در طراحی فرآیند پاسخ مهم است: تیم امنیت نباید تنها داشبورد هشدار مخزن را منبع کامل حقیقت بداند؛ باید کانال تماس و گردش‌کار مربوط به ارائه‌دهندگان را نیز روشن کند.
مستندات امکان الگوهای عمومی برای رازهایی مانند کلید خصوصی، رشتهٔ اتصال و کلید API عمومی را ذکر می‌کند. الگوهای سفارشی نیز اجازه می‌دهند سازمان برای رازهای اختصاصی خود عبارت منظم تعریف کند. همچنین «بررسی اعتبار» می‌تواند به اولویت‌بندی کمک کند؛ این بررسی ممکن است برای فهمیدن ابطال‌شدن اعتبارنامه با سرویس صادرکننده تماس بگیرد. این تماس، ملاحظهٔ حریم خصوصی و شبکه‌ای دارد و باید پیش از فعال‌سازی در سیاست سازمان بررسی شود.
تحلیل تأثیر برای سازمان‌ها
کاهش نویز، نه کاهش الزام پاسخ
تحلیل تحریریه: وقتی یک شناساگر کمتر به UUID بی‌ربط، نام تابع، جای‌نگهدار یا توکن عمومی مرورگر گیر بدهد، تیم بررسی‌کننده می‌تواند زمان بیشتری را برای موارد محتملِ واقعی صرف کند. کاهش مثبت کاذب به‌طور بالقوه کیفیت صف triage (غربال و اولویت‌بندی) را بهتر می‌کند و فرسودگی ناشی از هشدارهای کم‌ارزش را پایین می‌آورد. اما این مزیت نباید به معنی خاموش‌کردن بررسی انسانی تعبیر شود. یک تطبیق کاذبِ کمتر، تضمین نمی‌کند که هر تطبیق باقی‌مانده معتبر، فعال یا متعلق به محیط تولید باشد.
در طرف پوشش، اضافه‌شدن starlink_public_api_v2_secret یک شکاف مشخص را برای نوع سرّ SpaceX هدف می‌گیرد. اگر چنین مقدارهایی قبلاً در مخزن عمومی، issue، ویکی یا gist قرار گرفته باشند، سازمان باید کشف را محرک پاسخ بداند، نه پایان پاسخ. مستندات صریحاً توصیه می‌کند اعتبارنامهٔ در معرض دید فوراً چرخانده شود؛ حذف از تاریخچه کاری زمان‌بر است و اگر اعتبارنامه قبلاً باطل شده باشد، اغلب غیرضروری است. این توصیه، یک ترتیب عملی روشن می‌دهد: نخست مهار اعتبارنامه، سپس تصمیم‌گیری دربارهٔ پاک‌سازی تاریخچه و دامنهٔ افشای آن.
پیامد برای چرخهٔ توسعه
تیم توسعه باید Secret scanning را بخشی از چرخهٔ عمر راز ببیند. راز نباید برای رفع سریع خطای اتصال داخل کد، فایل نمونه یا pull request قرار گیرد. نگهداری در متغیر محیطی، سامانهٔ مدیریت راز یا سازوکار امن سازمانی، مشکل را به‌طور خودکار حل نمی‌کند، اما سطح دیده‌شدن در مخزن را کم می‌کند. از آن سو، چون مستندات اسکن تاریخچه و محتوای جانبی را هم بیان می‌کند، آموزش باید مثال‌های issue، نظر بازبینی، ویکی و gist را شامل شود.
محدودیت‌های قابل مشاهده
منابع حاضر تضمین نمی‌کنند که Secret scanning همهٔ رازها را بیابد، راز را پیش از هر مشاهده‌ای مسدود کند، یا بعد از افشا خودکار همهٔ سرویس‌های وابسته را پاک‌سازی کند. اعلامیه فقط تغییرهای فهرست‌شده را بیان می‌کند و مستندات نیز هدف و دامنهٔ قابلیت را شرح می‌دهد، نه یک تضمین امنیتی مطلق. همچنین دسترسی بر اساس نوع مخزن فرق دارد: مخزن عمومی به‌صورت رایگان خودکار پویش می‌شود؛ مخزن خصوصی و داخلیِ متعلق به سازمان با GitHub Secret Protection در طرح‌های مشخص GitHub در دسترس است؛ وضعیت مخزن کاربر نیز شرایط خاص خود را دارد.
کاربردهای عملی مجاز
سناریوی اول: مخزن عمومی و راز SpaceX
سناریوی دوم: بازبینی مثبت کاذب
سناریوی سوم: پوشش اختصاصی
راهنمای گام‌به‌گام دفاعی
۱. دامنه را مشخص کنید. فهرست مخزن‌های عمومی، خصوصی و داخلی، شاخه‌ها، issueها، pull requestها، گفت‌وگوها، ویکی‌ها و gistهای سازمانی را مشخص کنید. سطح دسترسی و مالک هر بخش را ثبت کنید.
۲. نوع راز را طبقه‌بندی کنید. اگر تطبیق به starlink_public_api_v2_secret یا یکی از شناساگرهای فهرست‌شده مربوط است، ارائه‌دهنده، محیط مصرف، مالک فنی و احتمال فعال‌بودن را ثبت کنید؛ خود مقدار را در تیکت عادی ننویسید.
۳. فوراً مهار کنید. طبق مستندات، اعتبارنامهٔ افشاشده را بلافاصله rotate یا revoke کنید. برای اعتبارنامهٔ زنجیره‌ای، سرویس‌های وابسته و کارهای زمان‌بندی‌شده را هم بررسی کنید. تا پایان مهار، افشا را حادثهٔ واقعی فرض کنید؛ از حدس‌زدن دربارهٔ سوءاستفاده خودداری کنید.
۴. مسیر شریک را بررسی کنید. برای راز شریک، ممکن است گزارش مستقیم به صادرکننده انجام شده باشد و هشدار در صفحهٔ مخزن دیده نشود. کانال تماس و وضعیت اقدام SpaceX یا ارائه‌دهندهٔ مربوط را از مسیرهای مجاز سازمان پیگیری کنید؛ از ارسال دوبارهٔ مقدار حساس به کانال عمومی بپرهیزید.
۵. ردپای تاریخی را ارزیابی کنید. پس از ابطال یا چرخش، بررسی کنید راز در commitهای قبلی، شاخهٔ حذف‌شده، issue، نظر pull request، ویکی یا gist ظاهر شده است یا نه. حذف تاریخچه ممکن است زمان‌بر باشد و مستندات می‌گوید اگر راز باطل شده باشد اغلب ضرورتی ندارد؛ تصمیم نهایی را با ارزیابی ریسک و نیازهای نگهداری سوابق بگیرید.
۶. منبع ورود را اصلاح کنید. فایل پیکربندی، اسکریپت، مستندات، الگوی pull request و آموزش داخلی را اصلاح کنید تا راز دوباره در مخزن یا متن جانبی قرار نگیرد. مسیر امن جایگزین را به توسعه‌دهنده نشان دهید، نه اینکه فقط خطا را ببندید.
۷. اعتبارسنجی کنترل را انجام دهید. پس از چرخش، تست غیرحساس انجام دهید: آیا برنامه از راز جدید استفاده می‌کند؟ آیا دسترسی قدیمی واقعاً بی‌اعتبار است؟ آیا مالک هشدار می‌داند چه زمانی باید پاسخ دهد؟ نتیجه را ثبت کنید، اما مقدار secret را ذخیره نکنید.
ملاحظات امنیتی و حریم خصوصی
هر هشدار را باید حداقلی‌سازی کرد. در اعلان تیمی، مسیر و نوع شناساگر کافی است؛ نمایش کامل کلید یا توکن می‌تواند افشای دوم ایجاد کند. دسترسی به هشدارها را بر اساس نقش تنظیم کنید و دادهٔ رخداد را به مدت لازم نگه دارید. اگر برای بررسی اعتبار، تماس با سرویس صادرکننده برقرار می‌شود، تیم باید بداند چه متادیتایی از آن تماس قابل مشاهده است و آیا سیاست سازمان آن را مجاز می‌داند. مستندات تنها می‌گوید ممکن است چنین تماسی رخ دهد؛ از این عبارت نمی‌توان دربارهٔ شکل دقیق درخواست یا دادهٔ منتقل‌شده نتیجه‌گیری کرد.
چک‌لیست عملیاتی
- [ ] تاریخچهٔ همهٔ شاخه‌ها و محتوای جانبیِ نام‌برده‌شده در مستندات در دامنهٔ بررسی قرار گرفته است.
- [ ] مالک فنی برای
starlink_public_api_v2_secretو هر شناساگر دیگر تعیین شده است. - [ ] برای راز شریک، احتمال گزارش مستقیم به ارائه‌دهنده در نظر گرفته شده است.
- [ ] اعتبارنامهٔ افشاشده بدون انتظار برای تحلیل طولانی rotate یا revoke شده است.
- [ ] مقدار کامل راز در issue، چت، گزارش یا commit جدید بازنشر نشده است.
- [ ] مثبت کاذب با زمینه، جفت شناساگر، طول و مجموعه‌کاراکتر بررسی شده است.
- [ ] الگوهای عمومی و سفارشی بر اساس نیاز واقعی سازمان و با آزمون غیرحساس تنظیم شده‌اند.
- [ ] دسترسی به هشدارها و دادهٔ تماس‌های بررسی اعتبار بازبینی شده است.
- [ ] مسیر جلوگیری از ورود دوبارهٔ راز به کد، pull request و مستندات آموزش داده شده است.
- [ ] نتیجهٔ تستِ بی‌اعتبارشدن مقدار قدیمی و فعال‌شدن مقدار جدید ثبت شده است.
پرسش‌های متداول
آیا اضافه‌شدن شناساگر SpaceX یعنی همهٔ کلیدهای مرتبط کشف می‌شوند؟
خیر. منبع فقط نوع مشخص starlink_public_api_v2_secret را اعلام می‌کند. نمی‌توان از آن، پوشش همهٔ شکل‌های ممکن credential یا تضمین کشف هر مقدار مرتبط را نتیجه گرفت. تیم باید فهرست رسمی شناساگرها و الگوهای اختصاصی خود را جداگانه مدیریت کند.
آیا کاهش مثبت کاذب یعنی هشدارهای قبلی اشتباه بوده‌اند؟
نه لزوماً. اعلامیه می‌گوید قواعد برای کاهش تطبیق کاذب بهبود یافته‌اند؛ این گزاره دربارهٔ هدف و رفتار جدید است و همهٔ هشدارهای پیشین را باطل نمی‌کند. هر مورد باید با متن، زمینه، مالک و وضعیت اعتبار بررسی شود.
اگر راز از فایل حذف شده باشد، حادثه پایان یافته است؟
خیر. مستندات می‌گوید Secret scanning تاریخچهٔ Git را هم بررسی می‌کند و برای پاسخ، چرخش فوری اعتبارنامه را توصیه می‌کند. حذف خط از نسخهٔ فعلی ممکن است مقدار را از تاریخچه پاک نکند و حتی اگر پاک کند، به‌تنهایی اعتبارنامهٔ صادرشده را بی‌اعتبار نمی‌سازد.
چرا راز شریک در هشدار مخزن دیده نمی‌شود؟
طبق مستندات، رازهای شریک مستقیماً به ارائه‌دهنده گزارش می‌شوند و در هشدارهای مخزن نمایش داده نمی‌شوند. این تفاوت طراحی گزارش‌دهی است؛ تیم باید مسیر پاسخ ارائه‌دهنده را هم پیگیری کند و نبودن هشدار محلی را نشانهٔ بی‌خطر بودن نداند.
آیا بررسی اعتبار همیشه باید فعال باشد؟
نه می‌توان چنین الزام کلی ساخت و نه منابع آن را گفته‌اند. بررسی اعتبار برای اولویت‌بندی کمک می‌کند و ممکن است با صادرکننده تماس بگیرد. سازمان باید پیش از فعال‌سازی، دسترسی، حریم خصوصی، مجوز و ارزش عملی آن را ارزیابی کند.
آیا برای این تغییر CVE یا CVSS وجود دارد؟
در دو منبع مورد استفاده، CVE یا CVSS برای این به‌روزرسانی اعلام نشده است. این خبر دربارهٔ شناساگرها، شراکت و پالایش مثبت کاذب است، نه اعلام یک آسیب‌پذیری قابل امتیازدهی؛ بنابراین نسبت‌دادن عدد یا شناسه، جعل مشخصات خواهد بود.
نتیجه‌گیری
به‌روزرسانی ۵ نوامبر ۲۰۲۶ دو پیام عملی دارد: نخست، پوشش Secret scanning با شریک‌شدن SpaceX و شناساگر starlink_public_api_v2_secret گسترده‌تر شده است؛ دوم، پالایش قواعد Alibaba، AWS، Google، OpenVSX، Pydantic Services و Tencent می‌تواند صف بررسی را از برخی تطبیق‌های کاذب پاک‌تر کند. ارزش واقعی این تغییر زمانی نمایان می‌شود که سازمان آن را در کنار تاریخچهٔ کامل Git، محتوای issue و pull request، الگوهای سفارشی، کنترل دسترسی و پاسخ فوری به اعتبارنامهٔ افشاشده به کار گیرد.
برداشت مسئولانه این نیست که ابزار خطر را حذف می‌کند؛ برداشت دقیق این است که تشخیص و اطلاع‌رسانی، فرصت بهتری برای اقدام می‌دهند. پاسخ نهایی همچنان به مالک سرویس، ابطال یا چرخش اعتبارنامه، ارزیابی دامنهٔ افشا، اصلاح فرایند توسعه و حفاظت از داده‌های رخداد وابسته است. تیمی که این تفکیک میان «کشف»، «گزارش به شریک»، «هشدار قابل مشاهده» و «مهار واقعی» را حفظ کند، از قابلیت جدید استفاده‌ای دقیق‌تر و کم‌خطرتر خواهد داشت.
