استفاده از دستیارهای هوش مصنوعی در توسعه نرم افزار سرعت کار برنامه نویس ها را بالا برده. ولی یک گزارش امنیتی تازه نشان می دهد تنظیمات بعضی از همین ابزارها می تواند راه نشت اطلاعات محرمانه شود.
شرکت Apiiro که در امنیت نرم افزار کار می کند، پژوهشی منتشر کرده است. طبق این پژوهش، بیش از 1122 نسخه عمومی از فایل های تنظیمات Claude Code در GitHub اطلاعات محرمانه داشته اند. رمز عبور، کلید API و توکن دسترسی بین این اطلاعات بوده. مخازن هم عمومی بودند. یعنی هر کسی که اینترنت داشت می توانست آن ها را ببیند.
نشت اطلاعات از تنظیمات Claude Code چگونه اتفاق افتاد؟
ریشه مشکل کجاست؟ در رفتار خود ابزار. Claude Code دستیار برنامه نویسی شرکت Anthropic است و قبل از اجرای بیشتر دستورهای ترمینال از کاربر اجازه می گیرد. اگر توسعه دهنده گزینه Yes, and don’t ask again را بزند، ابزار آن دستور را به عنوان یک قانون مجاز ذخیره می کند. دفعه بعد دیگر نمی پرسد. تا اینجا اشکالی نیست. مشکل وقتی پیش می آید که خود دستور رمز یا کلید داشته باشد. این قانون ها در فایل .claude/settings.local.json نوشته می شوند.
آمار افشای اطلاعات در GitHub؛ بیش از ۱۳۰۰ رمز و کلید دسترسی
آمارها کوچک نیستند. پژوهشگران 104185 نسخه از این فایل را پیدا کردند. این نسخه ها در بیش از 103 هزار مخزن عمومی بودند. از این تعداد، 1122 فایل دست کم یک مورد محرمانه داشتند. روی هم 1379 مورد متفاوت پیدا شد. بیش از یک سوم آن ها مستقیم به پایگاه داده راه می دادند. بین موارد پیدا شده 379 رمز پایگاه داده بود. 43 مورد ورود SSH، 42 توکن برای GitHub و GitLab و npm و 23 کلید AWS هم دیده شد.
همه این ها به 63 سازمان تعلق داشت. پژوهشگران بین نمونه ها یک کلید مدیریتی سطح بالا از یک ارائه دهنده خدمات پایگاه داده پیدا کردند. رمز مالک یک پایگاه داده سوابق پزشکی هم آنجا بود. اعتبار همه موارد آزمایش نشده. ولی یکی از شرکت ها پیش از انتشار گزارش باخبر شد و تأیید کرد که کلید افشاشده اش هنوز فعال بوده.
حذف فایل از GitHub، مشکل را حل نمی کند
حذف فایل از GitHub مشکل را حل نمی کند. این را باید جدی گرفت. حتی اگر برنامه نویس فایل را از نسخه فعلی پاک کند، نسخه های قدیمی در تاریخچه Git یا در Fork ها می مانند. پژوهشگران 734 مورد محرمانه دیگر هم در نسخه های قدیمی پیدا کردند که در نسخه فعلی دیگر نبودند. 211 Fork از 74 مخزن هم همان موارد مخزن اصلی را داشتند.
با فایل های تنظیمات مشترک، تاریخچه مخازن و گزارش گفتگوهای دستیارهای هوش مصنوعی، شمار کل به 2539 مورد در 1994 مخزن می رسد. پس پاک کردن یک فایل کافی نیست. دست بردن در تنظیمات Git هم کافی نیست.
چرا ابزارهای اسکن امنیتی همه اطلاعات را پیدا نکردند؟
یک نکته دیگر هم هست. ابزارهای معمول اسکن هم همه این موارد را پیدا نکردند. پژوهشگران فایل ها را با Gitleaks و TruffleHog اسکن کردند. Gitleaks در 564 فایل مورد محرمانه پیدا کرد. TruffleHog در 643 فایل. ولی 215 فایل از چشم هر دو دور ماند. دلیلش به شکل ذخیره شدن رمزها برمی گردد.
یشتر این ابزارها دنبال الگوی مشخص کلید API و توکن هستند. اما رمزی که به صورت یک پارامتر معمولی در دستوری مثل PGPASSWORD= یا sshpass -p آمده باشد، برای ابزار فقط یک متن عادی است. پس اسکن با ابزارهای رایج، به تنهایی همه چیز را پیدا نمی کند.
چطور جلوی نشت اطلاعات محرمانه را بگیریم؟
تیم Apiiro چند کار مشخص پیشنهاد می کند. اول این که مخازن سازمان را برای فایل های .claude/settings.local.json و .claude/settings.json بگردید. تاریخچه Commit ها را هم ببینید، حتی اگر فایل از نسخه فعلی پاک شده باشد. اگر رمز یا توکن یا کلیدی پیدا کردید، اول اعتبارنامه ها را عوض کنید. فقط حذف فایل کافی نیست. فایل تنظیمات محلی را به .gitignore پروژه اضافه کنید. اگر Git آن را دنبال می کند، با git rm –cached .claude/settings.local.json از فهرست فایل های تحت مدیریتش بیرون بیاورید.
رمز را مستقیم توی دستور ترمینال ننویسید. متغیر محیطی یا Secret Manager برای همین کار است. مثلاً به جای رمز پایگاه داده، از متغیری مثل $DB_URL استفاده کنید. و تا جایی که می شود، به جای تأیید دستورهای حساس و مشخص، الگوهای عمومی و کنترل شده را مجاز کنید. قوانین دسترسی ابزار را هم هر چند وقت یک بار مرور کنید.
این مشکل فقط به Claude Code محدود نمی شود
مسئله فقط برای Claude Code نیست. پوشه های .claude/ و .cursor/ و .gemini/ و .specstory/ هم باید بررسی شوند. تیم های امنیت بهتر است با این فایل ها مثل فایل های .env رفتار کنند. یعنی اسکن اطلاعات محرمانه در مرحله Pre-commit و CI/CD باشد. تاریخچه Git هم بررسی شود، نه فقط نسخه فعلی.
رمزهای داخل دستورهای ترمینال هم باید پیدا شوند و فقط کلیدهایی که الگوی شناخته شده دارند کافی نیست. فایل های تنظیمات ابزارهای هوش مصنوعی هم باید توی الگوهای پیش فرض .gitignore بیایند. اعتبارنامه هایی که کنار آدرس سرورهای عمومی ذخیره شده اند هم باید دوباره دیده شوند.
امنیت ابزارهای هوش مصنوعی را جدی بگیرید
به نظر من درس این ماجرا ساده است. قابلیتی که برای کم کردن درخواست های تأیید ساخته شده، اگر درست مدیریت نشود، خودش راه نشت می شود. این ابزارها فقط به کد دسترسی ندارند. دستورهای ترمینال و فایل های تنظیمات و دسترسی های محیط توسعه هم جلوی چشم شان است. پس امنیتشان بخشی از امنیت زیرساخت سازمان است. باید توی سیاست های امنیت اطلاعات بیاید، کنار حفاظت از سرورها و پایگاه های داده. یادتان هست گفتیم «رمز مستقیم داخل دستور»؟ ریشه این نشت همین عادت ساده است.