ابزارهای هوش مصنوعی برنامه‌نویسی قرار است سرعت توسعه نرم‌افزار را افزایش دهند، بسیاری از کارهای تکراری را خودکار کنند و تعامل توسعه‌دهندگان با محیط سیستم‌عامل و ابزارهای خط فرمان را ساده‌تر سازند. اما گزارش تازه شرکت امنیت سایبری Apiiro نشان می‌دهد که همین قابلیت‌های ساده‌ساز، در صورت طراحی یا استفاده نادرست، می‌توانند به یک مسیر جدی برای افشای اطلاعات محرمانه تبدیل شوند.
بر اساس این گزارش که در نوامبر ۲۰۲۶ منتشر شده، هزاران رمز عبور، کلید API، توکن دسترسی و اطلاعات اتصال به پایگاه‌های داده در مخازن عمومی GitHub قرار گرفته‌اند. بخش قابل توجهی از این اطلاعات به دلیل نحوه ذخیره‌سازی مجوزهای اجرای دستورات در ابزار Claude Code شرکت Anthropic در معرض دسترسی عمومی قرار گرفته است.
نکته نگران‌کننده این است که برای ایجاد این وضعیت، لزوماً نیازی به حمله سایبری پیچیده، نفوذ به زیرساخت یا سوءاستفاده از یک آسیب‌پذیری نرم‌افزاری نیست. گاهی یک انتخاب ساده توسط توسعه‌دهنده کافی است.
ماجرای گزینه «Yes, and don’t ask again» چیست؟
Claude Code به‌عنوان یک دستیار هوش مصنوعی برنامه‌نویسی، می‌تواند دستورات مختلفی را در محیط Shell اجرا کند. این دستورات ممکن است شامل اجرای تست‌ها، نصب وابستگی‌ها، اتصال به پایگاه داده، اجرای اسکریپت‌های مدیریتی یا ارتباط با سرویس‌های خارجی باشند.
برای جلوگیری از اجرای ناخواسته دستورات، Claude Code در حالت عادی پیش از اجرای بسیاری از فرمان‌ها از کاربر اجازه می‌گیرد.
اما یک گزینه به نام «Yes, and don’t ask again» یا همان «بله، دیگر نپرس» وجود دارد که به کاربر اجازه می‌دهد یک دستور یا الگوی مشخص را تأیید کند تا در دفعات بعد بدون درخواست مجوز مجدد اجرا شود.
مشکل دقیقاً از همین‌جا آغاز می‌شود.
زمانی که توسعه‌دهنده این گزینه را برای یک دستور مشخص انتخاب می‌کند، Claude Code می‌تواند متن کامل آن دستور را در فایل زیر ذخیره کند:
.claude/settings.local.json
این فایل برای نگهداری تنظیمات محلی و مجوزهای اجرای دستورات استفاده می‌شود. اما اگر دستور تأییدشده حاوی اطلاعات حساسی مانند رمز عبور پایگاه داده، کلید API یا توکن دسترسی باشد، همان اطلاعات نیز به‌صورت متن ساده در فایل ذخیره خواهد شد.
برای مثال، تصور کنید توسعه‌دهنده برای اتصال به یک پایگاه داده از دستوری مشابه زیر استفاده کند:
PGPASSWORD=MySecretPassword psql -h db.example.com -U admin
اگر چنین دستوری به‌صورت کامل در فهرست مجوزها ذخیره شود، رمز عبور نیز در کنار سایر اطلاعات دستور باقی می‌ماند.
به این ترتیب، فایلی که قرار است صرفاً تنظیمات اجرای دستورات را نگهداری کند، ممکن است به محلی برای ذخیره اطلاعات محرمانه تبدیل شود.
آمار نگران‌کننده بررسی مخازن GitHub
شرکت Apiiro با بررسی مخازن عمومی GitHub، ابعاد این مشکل را ارزیابی کرده است.
نتایج اولیه این بررسی نشان می‌دهد:
- بیش از ۱۰۴ هزار نسخه از فایل
settings.local.jsonدر مخازن عمومی GitHub شناسایی شده است. - ۱۱۲۲ نسخه از این فایل حداقل یک اطلاعات محرمانه واقعی در خود داشته‌اند.
- مجموعاً ۱۳۷۹ رمز عبور، توکن و کلید محرمانه در این فایل‌ها شناسایی شده است.
- ۶۳ سازمان مختلف در میان مخازن آسیب‌دیده قرار داشته‌اند.
اما موضوع به همین‌جا ختم نمی‌شود.
بررسی تاریخچه تغییرات Git، فایل‌های تنظیمات مشترک و مکالمات ذخیره‌شده دستیارهای هوش مصنوعی، تعداد اطلاعات محرمانه شناسایی‌شده را به ۲۵۳۹ مورد در ۱۹۹۴ مخزن عمومی رسانده است.
در میان اطلاعات افشاشده، مواردی مانند ۳۷۹ رمز عبور پایگاه داده، ۴۳ اعتبارنامه SSH برای سرورهای عمومی، ۴۲ توکن GitHub، GitLab و npm و ۲۳ کلید AWS وجود داشته است.
برخی نمونه‌های کشف‌شده حتی شامل کلید مدیریتی یک شرکت ارائه‌دهنده پایگاه داده و رمز عبور مالک یک پایگاه داده مرتبط با اطلاعات پزشکی بوده‌اند.
نکته مهم این است که محققان اعتبار تمام این اطلاعات را با اتصال به سرویس‌های مربوطه آزمایش نکرده‌اند. با این حال، یکی از سازمان‌های مطلع‌شده تأیید کرده که کلید افشاشده آن در زمان بررسی همچنان فعال بوده است.
چرا سازوکار Git Ignore نتوانست جلوی افشا را بگیرد؟
شاید اولین پرسشی که برای توسعه‌دهندگان مطرح شود این باشد که اگر فایل settings.local.json قرار نیست وارد مخزن Git شود، پس چگونه این تعداد فایل به GitHub راه پیدا کرده‌اند؟
Claude Code برای جلوگیری از انتشار ناخواسته این فایل، هنگام ایجاد آن در یک مخزن Git، مسیر مربوطه را به فهرست Ignore سراسری Git در سیستم توسعه‌دهنده اضافه می‌کند.
اما این راهکار یک محدودیت اساسی دارد.
تنظیمات Global Git Ignore فقط روی همان سیستم و همان حساب کاربری اعمال می‌شود و بخشی از تنظیمات خود مخزن پروژه نیست.
به عبارت دیگر، اگر فایل پیش از اعمال این تنظیمات وارد مخزن شده باشد، یا در شرایطی قرار گیرد که تنظیمات محلی Git از آن محافظت نکنند، احتمال انتشار آن وجود دارد.
از طرف دیگر، Claude Code این فایل را به‌صورت خودکار به فایل .gitignore اختصاصی پروژه اضافه نمی‌کند. بنابراین این محافظت به همراه پروژه به سایر سیستم‌های توسعه منتقل نمی‌شود.
مسئله مهم‌تر این است که Git حتی پس از حذف یک فایل از پروژه، نسخه‌های قبلی آن را در تاریخچه تغییرات نگهداری می‌کند. بنابراین حذف فایل از نسخه فعلی مخزن به معنای حذف اطلاعات افشاشده نیست.
همچنین Forkهای مخزن می‌توانند نسخه‌های آلوده را برای مدت طولانی‌تری در دسترس نگه دارند.
مشکل فقط Claude Code نیست، بلکه نحوه مدیریت اطلاعات محرمانه توسط AI Agentهاست
اگرچه گزارش Apiiro روی Claude Code تمرکز دارد، اما پیام اصلی آن بسیار گسترده‌تر است.
دستیارهای هوش مصنوعی برنامه‌نویسی به‌تدریج از ابزارهای ساده تکمیل کد فراتر رفته‌اند. این ابزارها اکنون می‌توانند دستورات سیستم‌عامل را اجرا کنند، به پایگاه داده متصل شوند، فایل‌های پیکربندی را بخوانند و با سرویس‌های مختلف ارتباط برقرار کنند.
در چنین شرایطی، فایل‌های مربوط به تنظیمات، حافظه، تاریخچه مکالمات و مجوزهای اجرای دستورات می‌توانند حاوی اطلاعاتی باشند که از نظر امنیتی تفاوتی با فایل‌های .env یا سایر فایل‌های حاوی اعتبارنامه ندارند.
در بررسی Apiiro، نمونه‌هایی از اطلاعات محرمانه در فایل‌های تنظیمات مشترک Claude Code، فایل‌های مکالمات دستیارهای هوش مصنوعی، فایل‌های حافظه Agentها و حتی یادداشت‌های مربوط به تحویل و استقرار پروژه‌ها نیز شناسایی شده است.
این موضوع نشان می‌دهد که محدوده حفاظت از اطلاعات محرمانه دیگر نباید به فایل‌های سنتی مانند .env، config.php یا credentials.json محدود شود.
هر فایلی که یک AI Agent در جریان فعالیت خود ایجاد یا تغییر می‌دهد، بالقوه می‌تواند حاوی اطلاعات حساس باشد.
حتی ابزارهای امنیتی شناخته‌شده هم همه اطلاعات را شناسایی نمی‌کنند
یکی دیگر از بخش‌های مهم این تحقیق، بررسی عملکرد ابزارهای تشخیص نشت اطلاعات محرمانه است.
محققان فایل‌های شناسایی‌شده را با دو ابزار شناخته‌شده Gitleaks و TruffleHog بررسی کردند.
نتیجه نشان داد که Gitleaks تنها ۵۶۴ مورد و TruffleHog تعداد ۶۴۳ مورد از ۱۱۲۲ فایل حاوی اطلاعات محرمانه را شناسایی کرده‌اند.
جالب‌تر اینکه ۲۱۵ فایل توسط هیچ‌یک از این دو ابزار شناسایی نشده‌اند.
دلیل اصلی این مسئله به نحوه تشخیص اطلاعات محرمانه بازمی‌گردد.
بسیاری از ابزارهای Secret Scanning به دنبال الگوهای مشخص کلیدهای API، توکن‌های شناخته‌شده و رشته‌های تصادفی با ساختار خاص می‌گردند.
اما یک رمز عبور معمولی که در دستوری مانند sshpass -p یا PGPASSWORD= قرار گرفته، ممکن است از دید این ابزارها صرفاً یک رشته متنی عادی باشد.
در نتیجه، حتی استفاده از ابزارهای امنیتی شناخته‌شده نیز بدون تنظیم قواعد مناسب برای شناسایی رمزهای عبور تعبیه‌شده در دستورات، نمی‌تواند تضمین‌کننده امنیت باشد.
واکنش Anthropic و برنامه‌های احتمالی برای رفع مشکل
بر اساس به‌روزرسانی گزارش Apiiro در ۸ نوامبر ۲۰۲۶، Boris Cherny، مدیر Claude Code در Anthropic، به این گزارش واکنش نشان داده است.
او اعلام کرده که تیم توسعه در حال بررسی راهکارهایی برای جلوگیری از تکرار این وضعیت است.
از جمله اقداماتی که برای نمونه‌سازی و ارزیابی مطرح شده‌اند می‌توان به موارد زیر اشاره کرد:
- افزودن قابلیت تشخیص اطلاعات محرمانه به Claude Code
- بهبود کنترل دستورات حساس در حالت Auto
- بررسی روش‌هایی برای جلوگیری از ذخیره اطلاعات محرمانه در فایل‌های تنظیمات
با این حال، این موارد در زمان انتشار گزارش در مرحله بررسی و نمونه‌سازی بوده‌اند و نباید آن‌ها را قابلیت‌های منتشرشده و قطعی محصول در نظر گرفت.
سازمان‌ها و توسعه‌دهندگان چگونه باید از این اتفاق جلوگیری کنند؟
این اتفاق یک هشدار جدی برای تیم‌های توسعه نرم‌افزار و مدیران امنیت اطلاعات است. استفاده از دستیارهای هوش مصنوعی در محیط‌های توسعه باید با همان حساسیتی مدیریت شود که برای دسترسی به پایگاه داده‌ها، سرورها و سایر زیرساخت‌های سازمانی در نظر گرفته می‌شود.
مهم‌ترین اقدامات پیشنهادی عبارت‌اند از:
۱. بررسی مخازن Git و تاریخچه تغییرات
تمام مخازن عمومی و خصوصی سازمان باید برای یافتن فایل‌های زیر بررسی شوند:
.claude/settings.local.json.claude/settings.json
این بررسی نباید فقط به فایل‌های فعلی محدود شود و تاریخچه Commitها نیز باید مورد بررسی قرار گیرد.
۲. تغییر فوری اطلاعات افشاشده
اگر رمز عبور، کلید API یا توکنی در یک مخزن عمومی منتشر شده است، صرفاً حذف فایل کافی نیست.
ابتدا باید تمام اعتبارنامه‌های افشاشده باطل یا تعویض شوند. سپس پاک‌سازی مخزن و تاریخچه آن انجام شود.
۳. استفاده از متغیرهای محیطی و Secret Manager
اطلاعات محرمانه نباید مستقیماً داخل دستورات خط فرمان قرار بگیرند.
به‌جای قرار دادن رمز عبور واقعی در دستور، باید از متغیرهای محیطی یا سامانه‌های مدیریت اسرار استفاده کرد تا متن ذخیره‌شده در فایل تنظیمات صرفاً شامل نام متغیر باشد.
۴. بازنگری در مجوزهای اجرای دستورات AI Agentها
بهتر است به‌جای تأیید یک دستور کامل حاوی اطلاعات حساس، الگوهای مشخص و محدود برای دستورات مجاز تعریف شوند.
۵. گسترش Secret Scanning
اسکن امنیتی باید علاوه بر فایل‌های سنتی، پوشه‌های مربوط به AI Agentها، فایل‌های حافظه و تاریخچه مخازن را نیز پوشش دهد.
همچنین قواعد تشخیص باید به‌گونه‌ای تنظیم شوند که رمزهای عبور قرارگرفته در دستورات Shell را نیز شناسایی کنند.
جمع‌بندی: هوش مصنوعی جدیدترین عضو زنجیره امنیتی سازمان‌هاست
گزارش Apiiro نشان می‌دهد که با گسترش ابزارهای برنامه‌نویسی مبتنی بر هوش مصنوعی، سطح حمله سازمان‌ها نیز در حال تغییر است.
تا پیش از این، مدیران امنیت اطلاعات معمولاً روی محافظت از فایل‌های پیکربندی، کلیدهای API، حساب‌های کاربری و اطلاعات اتصال به زیرساخت تمرکز داشتند. اما اکنون باید فایل‌هایی را نیز در نظر بگیرند که توسط دستیارهای هوش مصنوعی تولید یا مدیریت می‌شوند.
نکته کلیدی این است که یک AI Agent صرفاً یک ابزار پیشنهاددهنده کد نیست. این ابزار می‌تواند به منابع حساس دسترسی داشته باشد، فرمان اجرا کند و اطلاعاتی را در فایل‌های مختلف ذخیره کند که بعدها ناخواسته وارد مخزن نرم‌افزار شوند.
بنابراین، استفاده امن از ابزارهایی مانند Claude Code، Cursor و سایر دستیارهای برنامه‌نویسی نیازمند بازنگری در سیاست‌های مدیریت دسترسی، نگهداری اطلاعات محرمانه و فرایندهای انتشار کد است.
در دنیایی که هوش مصنوعی به بخشی از تیم توسعه تبدیل شده، فایل‌های تولیدشده توسط آن نیز باید مانند هر منبع دیگری که ممکن است حاوی اطلاعات محرمانه باشد، تحت نظارت و کنترل امنیتی قرار گیرند.
دیدگاهتان را بنویسید
برای نوشتن دیدگاه باید وارد بشوید.