۱۲٪ از مخازن کد ساخته‌شده با هوش مصنوعی دارای حفره‌های امنیتی بحرانی هستند

اگر امروز برای پیاده‌سازی لایه‌های امنیتی پروژه‌تان به ابزارهای کدنویسی هوش مصنوعی تکیه می‌کنید، احتمالاً در حال ساخت یک ویترین زیبا اما توخالی هستید. طبق یک ممیزی فنی که در ۵ سپتامبر ۲۰۲۶ انجام شد، ۱۲.۵٪ از مخازن کدی که توسط ابزارهای Lovable، Bolt و v0 ساخته شده‌اند، حداقل یک حفره امنیتی بحرانی دارند. این رقم از بررسی قطعی ۳۹۳ مخزن عمومی به دست آمده است.

بسیاری از توسعه‌دهندگان تصور می‌کنند هوش مصنوعی می‌تواند کدهای تکراری (Boilerplate) امنیتی را به‌درستی مدیریت کند، اما واقعیت این است که این ابزارها اغلب «توهم امنیت» ایجاد می‌کنند. مطالعه نشان می‌دهد ابزارهای AI مکرراً کدهایی تولید می‌کنند که برای یک انسان یا یک داشبورد مدیریتی درست به نظر می‌رسند، اما در محیط عملیاتی به‌طور بنیادین شکست می‌خورند. این وضعیت لایه‌ای پنهان از بدهی فنی ایجاد می‌کند؛ جایی که برنامه‌نویس تنها به این دلیل باور دارد ویژگی خاصی امن است که هوش مصنوعی ادعا کرده است.

متدولوژی و بستر پژوهش

پژوهشگر برای تضمین بازتولیدپذیری نتایج، از ممیزی‌های مبتنی بر مدل زبانی بزرگ (LLM) — که ماهیتی غیرقطعی دارند — فاصله گرفت و در عوض ۲۶ قانون ثابت و صلب را روی ۱,۱۶۳ فایل اجرا کرد. رویکردهای مدل‌محور پیشین مورد انتقاد بودند، زیرا قضاوت یک مدل قابل ممیزی نیست؛ وقتی از یک مدل پرسیده شود «دقیقاً چگونه این مورد را شمردی؟»، پاسخ معمولاً به صورت «مدل تصمیم گرفت» داده می‌شود. این چالش در صحت‌سنجی خروجی‌های AI موضوع متعددی است، مشابه آنچه در راهکارهای جدید برای جلوگیری از توهمات در مستندات کد بررسی شده است.

در این مطالعه، مخازن بر اساس اثرات ساختاری (Build Artefacts) و نه متن فایل README انتخاب شدند. یک مخزن زمانی واجد شرایط می‌شد که شامل فایل‌های .lovable ،lovable-tagger یا .bolt باشد. برای جلوگیری از تغییر در نمونه‌ها (Sample Drift)، داده‌ها در تاریخ ۵ سپتامبر ۲۰۲۶ منجمد شدند. معیارهای انتخاب شامل یک مخزن به ازای هر مالک، حذف فورک‌ها (Forks) و بررسی حداکثر سه فایل از هر مخزن بود.

از مجموع ۱,۱۸۵ فایل، ۱,۱۶۳ مورد در ۳۹۳ مخزن قابل خواندن بودند؛ ۲۲ فایل از زمان منجمد شدن داده‌ها از گیت‌هاب حذف شده بودند. این اجرای قطعی (Deterministic) تنها ۹۰ ثانیه زمان برد و هیچ هزینه‌ای نداشت؛ این یک بهبود چشمگیر نسبت به اولین تلاش پژوهشگر بود که در میانه راه، موجودی API او را به طور کامل تمام کرد.

جزئیات یافته‌ها

بر اساس گزارشی که در پلتفرم dev.to منتشر شد، ۲۷٪ از فایل‌ها (۳۰۹ مورد از ۱,۱۶۳ فایل) حداقل یک مورد مشکوک داشتند. از این میان، ۵۸ فایل حاوی آسیب‌پذیری‌های بحرانی بودند که در ۴۹ مخزن مختلف پراکنده شده بودند.

الگوی «امنیت کاذب»

هشداردهنده‌ترین یافته، شیوع سیاست‌های ناکارآمد امنیت سطح ردیف (Row-Level Security یا RLS) بود. در ۳۹ فایل، هوش مصنوعی سیاست‌های RLS را با عبارت using (true) نوشته بود. این وضعیت حتی از فراموش کردن فعال‌سازی RLS بدتر است، زیرا این کد امضای کسی است که سعی کرده امنیت را پیاده کند اما در آن شکست خورده است.

وقتی از یک ابزار AI خواسته می‌شود «RLS را اضافه کن»، ممکن است پاسخی تحت‌اللفظی بدهد که برای هر کاربر و در هر زمان، تایید شود. برای مثال، مدل ممکن است چنین کدی تولید کند:
alter table orders enable row level security; create policy "read orders" on orders for select using (true);

در حالی که کد صحیح باید به این شکل باشد:
create policy "read own orders" on orders for select using (auth.uid() = user_id);

در نسخه اول، داشبورد Supabase نشان می‌دهد که RLS فعال است و تیک مربوطه زده شده، اما جدول همچنان مانند قبل باز است. از آنجایی که کلیدهای ناشناس (Anon Key) طبق طراحی در باندل فرانت‌اند قرار دارند، داده‌ها کاملاً در معرض افشا هستند.

سایر حفره‌های بحرانی شناسایی شده توسط اسکن قانون‌محور عبارتند از:

• کوکی‌های تنظیم شده بدون پرچم‌های Secure یا SameSite (۱۱۱ مورد)
• هدرهای CORS با علامت ستاره یا Wildcard (Access-Control-Allow-Origin: *) (۷۴ مورد)
• استفاده از dangerouslySetInnerHTML از متغیرها (۶۰ مورد)
• سیاست‌های RLS با عبارت using (true) (۳۹ مورد)
• کوئری‌های SQL ساخته شده از طریق درونی‌سازی قالب یا Template Interpolation (۱۴ مورد)
• تخصیص innerHTML از یک متغیر (۶ مورد)
• ثبت کلیدهای API گوگل در سورس کد (۳ مورد)
• سایر موارد شامل eval()، تصادفی‌سازی ضعیف توکن‌ها و عدم وجود RLS (۷ مورد)

شکاف بازتولیدپذیری

پژوهشگر نتایج را با یک اسکن قبلی که توسط خودِ هوش مصنوعی روی همان مجموعه داده انجام شده بود مقایسه کرد. در حالی که مدل AI در ۵۹٪ مخازن مسائل بحرانی شناسایی کرده بود، قوانین قطعی تنها در ۱۲٪ موارد آن‌ها را یافتند. در ۱۱۵ فایلی که هر دو روش بررسی کردند، مدل در ۱۱۳ مورد خطا گزارش کرد، اما قوانین تنها ۳۲ مورد را تایید کردند. نرخ توافق این دو روش تنها ۳۰٪ بود.

این تفاوت، یک موازنه بنیادی در ممیزی امنیتی AI را نشان می‌دهد: مدل‌های زبانی وسعت دید بالایی دارند اما بازتولیدپذیر نیستند، در حالی که سیستم‌های قانون‌محور سخت‌گیرند اما خطاهای منطقی پیچیده را به طور سیستماتیک کمتر می‌شمارند. قوانین الگوهای نحوی (Syntactic) — مانند هدر CORS ستاره‌ای — را می‌گیرند، اما نسبت به «قصد» (Intent) کور هستند؛ مثلاً نمی‌توانند بفهمند یک نقطه انتهایی (Endpoint) هرگز بررسی نمی‌کند چه کسی درخواست داده است، یا ورودی کاربر سه تابع بعدتر به یک Sink می‌رسد.

عدد ۱۲٪ در واقع «کف» آسیب‌پذیری است؛ یعنی حداقلِ مواردی که می‌توان خط به خط ثابت کرد. عدد واقعی احتمالاً بالاتر است، اما این کف، تنها عددی است که در برابر استدلال‌های فنی قابل دفاع است.

ریسک پنهان اسرار (Secrets)

تنها سه مورد افشای رمز یا Secret در فایل‌های اصلی یافت شد، اما این عدد گمراه‌کننده است. هیچ‌یک از دو روش، فایل‌های .env را باز نکردند، در حالی که مطالعه‌ای پیشین نشان داد ۱۸.۵٪ از این مخازن، این فایل‌ها را در گیت ثبت کرده‌اند. این تایید می‌کند که اسرار در پروژه‌های ساخته‌شده با AI معمولاً در کامپوننت‌ها چسبانده نمی‌شوند، بلکه در فایل‌های محیطی قرار دارند که در اولین کامیت ارسال شده‌اند. این نوع مدیریت ناقص داده‌ها در گیت، اهمیت سیستم‌های حافظه ساختاریافته را دوچندان می‌کند، مشابه رویکردی که در مدیریت شرکت با حافظه گیت توسط BKS-Lab برای پایان دادن به فراموشی عامل‌های AI پیشنهاد شده است.

برای توسعه‌دهندگانی که از این ابزارها استفاده می‌کنند، این مطالعه سه بررسی فوری را پیشنهاد می‌کند:

• در کدهای SQL خود عبارت using (true) را جست‌وجو کنید؛ اگر این عبارت در جدولی با داده‌های مشتری وجود دارد، اپلیکیشن شما در معرض خطر است.
• دستور git log --all -- .env را اجرا کنید. هر خروجی به این معناست که فایل در تاریخچه گیت موجود است. حذف ساده فایل کافی نیست، زیرا تاریخچه گیت Blob قدیمی را نگه می‌دارد. تنها راه حل، تغییر (Rotate) تمام کلیدهاست.
• درخواست‌های کاربرِ خارج از سیستم (Signed-out) را تست کنید. از آنجایی که یک جدول محافظت‌شده و یک جدول خالی از بیرون یکسان به نظر می‌رسند، تنها راه اثبات امنیت، ورود با یک کاربر و تلاش برای خواندن ردیف‌های کاربر دیگر است.

این تغییر در شواهد نشان می‌دهد که اتکای صنعت به هوش مصنوعی برای کدهای زیرساختی امنیت، در حال ایجاد یک آسیب‌پذیری سیستمی است. برای جلوگیری از چنین شکست‌های عملیاتی در استقرار مدل‌ها، استفاده از مانیفست‌های نسخه‌بندی می‌تواند راهکاری حیاتی برای کنترل تغییرات و بازگشت به نسخه‌های امن باشد. خطر اصلی این نیست که AI امنیت را فراموش کند، بلکه این است که پاسخی تحت‌اللفظی و غیرعملی بدهد که از فیلترهای سطحی عبور کند. اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.