گیت‌هاب اکنون به‌طور پیش‌فرض کلیدهای API آنتروپیک را هنگام ارسال مسدود می‌کند
امنیت برنامه
تیم OpenTools — ۱۴ اکتبر ۲۰۲۶
GitHub Secret Scanning الگوهای کلیدهای API سرویس و کاربر آنتروپیک را به فهرست شناسایی خود اضافه کرده و محافظت هنگام ارسال (push protection) را برای آن‌ها به‌طور پیش‌فرض فعال کرده است. همین انتشار همچنین شناسایی Cloudsmith و تبدیل Salesforce به یکی از شرکای اسکن اسرار گیت‌هاب را به همراه دارد.
دو نوع کلید آنتروپیک اکنون محافظت پیش‌فرض هنگام ارسال را فعال می‌کنند
گیت‌هاب در ۱۳ اکتبر اعلام کرد که Secret Scanning اکنون anthropic_service_api_key و anthropic_user_api_key را شناسایی می‌کند. هر دو آشکارساز به‌صورت پیش‌فرض در قابلیت محافظت هنگام ارسال قرار گرفته‌اند.
برای مخازنی که Secret Scanning در آن‌ها فعال است، از جمله مخازن عمومی رایگان، کامیتی که یکی از این الگوها را داشته باشد پیش از رسیدن به مخزن راه دور مسدود می‌شود. این کنترل مسیر ارسال را هدف می‌گیرد و ثابت نمی‌کند که یک راز هرگز در فایل محلی، تاریخچه ترمینال، گزارش ساخت یا سرویس دیگری کپی نشده است.
یک ارسال مسدودشده باید نشانه‌ای تلقی شود که یک اعتبارنامه وارد کد منبع شده است، حتی اگر آن کامیت هرگز عمومی نشده باشد.
شناسایی اسرار و گزارش‌دهی شرکا دو فرایند متفاوت هستند
این انتشار همچنین آشکارساز cloudsmith_api_key و الگوی توکن OAuth2 مربوط به Salesforce Marketing Cloud را اضافه می‌کند. Salesforce اکنون یکی از شرکای اسکن اسرار گیت‌هاب است.
گیت‌هاب می‌گوید اسرار شرکایی که در مخازن عمومی پیدا می‌شوند به صادرکننده آن‌ها گزارش می‌شوند تا ارائه‌دهنده بتواند آن‌ها را باطل یا جایگزین کند. الگوهای اسرار کاربران در مخازن عمومی یا خصوصی هشدار ایجاد می‌کنند. مرجع الگوهای پشتیبانی‌شده مشخص می‌کند کدام الگوها بررسی شریک، محافظت هنگام ارسال یا بررسی اعتبار را دریافت می‌کنند.
نباید فرض کرد هر آشکارساز جدید همان واکنش بعدی را دارد. تطبیق یک الگو، مسدود شدن ارسال، ایجاد هشدار، اطلاع‌رسانی به شریک و تأیید ابطال، رویدادهای جداگانه‌ای هستند.
کلید مسدودشده همچنان به چرخش و بررسی سابقه نیاز دارد
وقتی محافظت هنگام ارسال یک کلید آنتروپیک را متوقف می‌کند، آن را از تغییر حذف کنید و مقدار آن را به مخزن تأییدشده اسرار تیم منتقل کنید. سپس طبق کنترل‌های ارائه‌دهنده، اعتبارنامه افشاشده را تغییر دهید یا باطل کنید. ویرایش فایل به‌تنهایی باعث بی‌اعتبار شدن کلید اصلی نمی‌شود.
کامیت‌های قبلی، درخواست‌های ادغام باز، فورک‌ها، خروجی‌های CI و گزارش‌های محلی توسعه‌دهندگان را برای همان مقدار بررسی کنید. اگر کلید به یک سیستم ساخت یا مخزن راه دور مشترک رسیده باشد، بازه افشا را از نخستین کپی تأییدشده در نظر بگیرید، نه زمان دریافت هشدار.
مالک اعتبارنامه، محیط آسیب‌دیده، زمان چرخش و هرگونه بررسی استفاده را مستند کنید. تا زمانی که گزارش‌های ارائه‌دهنده استفاده ناشناخته‌ای را مشخص نکرده‌اند، آن را ناشناخته در نظر بگیرید.
دور زدن محافظت باید نادر و مبتنی بر شواهد باشد
محافظت هنگام ارسال در شرایط پشتیبانی‌شده به کاربر اجازه می‌دهد مسدودسازی را دور بزند، اما این کار به معنی امن شدن رشته شناسایی‌شده نیست. فقط زمانی از این امکان استفاده کنید که مقدار موردنظر به‌طور مشخص یک داده آزمایشی، مثبت کاذب یا اعتبارنامه باطل‌شده باشد و سیاست مخزن نیز این استثنا را اجازه دهد.
بهتر است داده‌های آزمایشی را تغییر دهید تا شبیه اعتبارنامه‌های واقعی نباشند. این کار خستگی ناشی از هشدارها را کاهش می‌دهد و مانع می‌شود نمونه‌های کپی‌شده به مسیری برای افشای کلیدهای واقعی تبدیل شوند.
مرور کلی Secret Scanning گیت‌هاب توضیح می‌دهد که دسترسی به این قابلیت بسته به نوع مشاهده‌پذیری مخزن، تنظیمات سازمان و پوشش GitHub Advanced Security متفاوت است. سیاست واقعی مخزن را بررسی کنید و تصور نکنید تنظیم پیش‌فرض در همه جا اعمال می‌شود.
کنترل را با یک الگوی آزمایشی تأییدشده از سوی ارائه‌دهنده بررسی کنید
یک آزمایش ایمن برای راه‌اندازی باید از یک مقدار آزمایشی مستند و غیرمحرمانه استفاده کند، نه یک اعتبارنامه واقعی آنتروپیک، Cloudsmith یا Salesforce. بررسی کنید که کامیت مسدود می‌شود، هشدار الگوی مورد انتظار را نشان می‌دهد و رویداد از مسیر معمول به تیم امنیتی می‌رسد.
سپس مطمئن شوید توسعه‌دهندگان مسیر بازیابی را می‌دانند: مقدار را حذف کنند، در صورت واقعی بودن آن را تغییر دهند، میزان افشا را بررسی کنند و دوباره یک کامیت پاک ارسال کنند. نتیجه مطلوب فقط نمایش یک هشدار قرمز در محیط توسعه نیست، بلکه بستن یک رخداد با اعتبارنامه جایگزین و تأییدشده است.
این به‌روزرسانی یکی از مسیرهای رایج نشت اعتبارنامه‌های ارائه‌دهندگان هوش مصنوعی را کاهش می‌دهد، اما مدیریت چرخه عمر کلیدها و واکنش به رخداد همچنان مسئولیت مالک مخزن است. برای تغییرات مهم امنیتی، صفحه سازمان GitHub در OpenTools را دنبال کنید.
تصویر: اسکرین‌شات واقعی از صفحه رسمی انتشار Secret Scanning گیت‌هاب در ۱۳ اکتبر. OpenTools صفحه منبع را برای این گزارش ثبت کرده است؛ هیچ تغییر مولد یا بزرگ‌نمایی مصنوعی روی تصویر انجام نشده است.