بحث هوش مصنوعی و امنیت سایبری بیش از هر موضوع دیگری در این حوزه دچار اغراق است. این صفحه عمداً محافظه‌کارانه نوشته شده: بدون پیشبینی، بدون ادعای توانایی اثبات‌نشده و بدون آمار بی‌منبع. آنچه برای یک تیم توسعه یا امنیت واقعاً اهمیت دارد سه چیز است — AI در دست مدافع چه کاری را سریعتر میکند، در دست مهاجم چه چیزی را ارزان‌تر میکند، و مهم‌تر از هر دو: کدی که با کمک AI نوشته میشود چه آسیب‌پذیری‌هایی می‌آورد. پاسخ آخری نامنتظر نیست؛ همان دستههای همیشگی OWASP.
در یک نگاه
- AI کار مدافع را در غربال و اولویت‌بندی سریعتر میکند، اما داوری نهایی همچنان انسانی است.
- کد تولیدشده با کمک AI همان دستههای OWASP Top 10:2025 را بازتولید میکند — بهویژه کنترل دسترسی و تزریق.
- OWASP فهرست جداگانه‌ای برای برنامه‌های مبتنی بر مدل‌های زبانی دارد؛ پیش از استناد به شماره‌ی نسخه، آن را از owasp.org راستی‌آزمایی کنید.
- هیچ ابزاری — با AI یا بدون آن — نقص کنترل دسترسی و منطق کسبوکار را قابل اتکا پیدا نمی‌کند.
چه چیزی واقعاً تغییر کرده و چه چیزی نه
تفکیک ساده‌ای که بیشتر بحث‌ها را روشن میکند:
- تغییر کرده: هزینهی تولید متن، کد و محتوای قانعکننده؛ سرعت خلاصه‌سازی حجم زیاد داده؛ سرعت نوشتن اسکریپتهای کمکی و قواعد تحلیل.
- تغییر نکرده: ماهیت آسیب‌پذیری‌ها. یک نقص کنترل دسترسی، همان نقص کنترل دسترسی است؛ کوئری پارامتری همچنان راهکار تزریق SQL است؛ و WAF همچنان نسبت به منطق کسبوکار نابیناست.
به‌بیان دیگر، AI اقتصاد کار را تغییر داده، نه فیزیک آن را. برای یک تیم امنیت، معنای عملی این است که فهرست کارها تغییر نمی‌کند؛ سرعت انجام برخی از آن‌ها تغییر میکند.
AI در دست مدافع: کجا واقعاً کمک میکند
کاربردهایی که امروز قابل دفاع‌اند:
- غربال اولیه‌ی حجم زیاد داده. خلاصه‌کردن لاگ، دسته‌بندی هشدارها و کاهش نویز پیش از رسیدن به تحلیل‌گر.
- کمک به بازبینی کد. توضیح بخش‌های ناآشنا و نشانه‌گذاری الگوهای مشکوک به‌عنوان نقطه‌ی شروع بازبینی انسانی — نه به‌عنوان نتیجه‌ی نهایی. چارچوب این کار در بازبینی کد منبع آمده است.
- نگاشت و طبقه‌بندی. نمونه‌ی مستند این کاربرد، خودِ فرایند تدوین فهرست ۲۵ ضعف پرخطر MITRE برای سال ۲۰۲۵ است: از یک ابزار مبتنی بر مدل زبانی برای پیشنهاد نگاشت مجدد رکوردهای CVE استفاده شد و سپس ۲۸۱ نهاد صادرکننده برای بازبینی انسانی این پیشنهادها فراخوانده شدند. الگوی درست همین است: پیشنهاد ماشینی، تأیید انسانی.
- تسریع کارهای تکراری — نوشتن اسکریپت پردازش خروجی، ساخت قاعده، تبدیل فرمت.
و محدودیت‌ها، که به همان اندازه مهم‌اند: خروجی می‌تواند با اطمینان بالا نادرست باشد، در دامنه‌های تخصصی جزئیات را از دست می‌دهد، و در تصمیم‌های حساس امنیتی نمی‌تواند مسئولیت بپذیرد. هر خروجی باید مثل خروجی یک ابزار خودکار دیگر برخورد شود: نقطه‌ی شروع بررسی، نه یافته.
AI در دست مهاجم: واقع‌بینانه
آنچه با اطمینان قابل گفتن است: AI هزینهی تولید محتوای قانعکننده را پایین آورده. متن فیشینگ بدون خطای زبانی، متناسب با زمینه‌ی سازمانی و در حجم بالا، امروز ارزان‌تر از گذشته تولید میشود. همچنین سرعت نوشتن اسکریپتهای کمکی و درک سریع کد ناآشنا برای هر دو طرف افزایش یافته است.
آنچه نباید ادعا کرد: این‌که AI کشف آسیب‌پذیری‌های بنیادی جدید را ممکن کرده، یا این‌که ماهیت حملات را تغییر داده. حمله‌های واقعی همچنان از همان مسیرهای شناختهشده انجام می‌شوند: اعتبارنامهی افشاشده، مؤلفهی وصلهنشده، پیکربندی نادرست و نقص کنترل دسترسی. توضیح این مسیرها در حمله‌ی سایبری آمده است.
«هوش مصنوعی به‌زودی جای تست نفوذ را میگیرد.» پرارزش‌ترین یافتههای یک ارزیابی — نقص کنترل دسترسی، IDOR و نقص منطق کسبوکار — نیازمند دانستن نیت برنامه‌اند: این‌که کاربر A باید رکورد B را ببیند یا نه، در کد نوشته نشده و از هیچ پاسخی قابل استنتاج نیست؛ در ذهن صاحب محصول است. همین محدودیت درباره‌ی ابزارهای تحلیل ایستا هم صادق است: این ابزارها دستههای تزریق و سوءاستفاده از رمزنگاری را نسبتاً خوب پیدا میکنند و نقص‌های کنترل دسترسی و منطق را عملاً پیدا نمی‌کنند — دقیقاً همان‌جایی که پرخطرترین یافته‌ها زندگی میکنند.
کد تولیدشده با کمک AI: مسئله‌ی عملی امروز
این مهم‌ترین بخش این صفحه برای یک تیم توسعه است. کدی که با کمک دستیار هوشمند نوشته میشود، آسیب‌پذیری‌های جدیدی نمی‌سازد؛ همان دستههای شناختهشده را بازتولید میکند — و چون سریعتر تولید میشود، حجم بازبینی لازم بالاتر می‌رود.
| الگوی پرتکرار | دسته‌ی OWASP | چرا رخ می‌دهد |
|---|---|---|
| نبود بررسی مالکیت رکورد در نقطه‌ی انتهایی جدید | A01:2025 | قواعد مجوزدهی در زمینه‌ی محلی کد وجود ندارد و قابل استنتاج نیست |
| ساخت کوئری با الحاق رشته در مسیرهای غیرمتعارف | A05:2025 | الگوی پارامتری در مسیر اصلی رعایت میشود اما در فیلتر پویا یا مرتب‌سازی نه |
| اعتبارنامه یا کلید در کد نمونه | A07:2025 | کد نمونه برای اجرا شدن نوشته شده، نه برای تولید (CWE-798) |
| مدیریت خطای ناقص و افشای جزئیات | A10:2025 | مسیر خطا کمتر از مسیر موفق بازبینی میشود |
| وابستگی پیشنهادی بدون راستی‌آزمایی منبع | A03:2025 | نام بسته پذیرفته میشود بدون بررسی منبع رسمی و امضا |
| پیکربندی بازِ نمونه در استقرار | A02:2025 | تنظیمات آسان‌گیرانه‌ی محیط توسعه به تولید منتقل میشود |
ردیف نخست تعیین‌کننده‌ترین است. مجوزدهی، دانشی است که فقط در سطح محصول وجود دارد و در هیچ فایلی نوشته نشده — به همین دلیل کد تولیدشده به‌طور نظام‌مند آن را جا می‌اندازد. راهکار عملی: مجوزدهی را متمرکز کنید تا نوشتن یک نقطه‌ی انتهایی جدید بدون عبور از آن لایه ممکن نباشد.
ردیف پنجم هم اقدام مشخصی دارد و دقیقاً همان توصیه‌ی A03:2025 است: هر وابستگی باید از منبع رسمی و با راستی‌آزمایی امضا دریافت شود. پیشنهاد یک نام بسته، دلیل موجودیت آن نیست.
امنیت خودِ برنامه‌های مبتنی بر مدل زبانی
وقتی یک مدل زبانی را داخل محصول خود قرار می‌دهید، دسته‌ی تازه‌ای از ملاحظات ایجاد میشود. OWASP برای این حوزه یک فهرست جداگانه با عنوان OWASP Top 10 for LLM Applications منتشر میکند که مستقل از Top 10 عمومی است. پیش از استناد به شماره‌ی نسخه یا سال آن، نسخه‌ی جاری را مستقیماً از owasp.org بررسی کنید؛ این فهرست سریعتر از فهرست اصلی به‌روز میشود.
مستقل از آن فهرست، دو نکتهی معماری که در آزمون این نوع برنامه‌ها همیشه بررسی می‌شوند:
- هر ورودی مدل، ورودی غیرقابل اعتماد است — چه از کاربر بیاید و چه از سندی که برنامه بازیابی کرده. اگر خروجی مدل به یک عمل حساس متصل شود، باید همان اعتبارسنجی‌ای روی آن اعمال شود که روی ورودی کاربر اعمال می‌کنید.
- مجوزدهی باید در لایهی سرویس بماند، نه در دستور مدل. اگر برنامه به مدل اجازه‌ی فراخوانی ابزار یا کوئری می‌دهد، محدودیت دسترسی باید در همان سرویس اعمال شود. دستور متنی، مرز امنیتی نیست — دقیقاً به همان دلیلی که کنترل سمت مرورگر مرز امنیتی نیست.
در نهایت، یک برنامهی مبتنی بر مدل زبانی همچنان یک برنامهی وب است و همه‌ی دستههای متعارف روی آن صدق میکند. اگر چنین محصولی می‌سازید، ترتیب درست این است: ابتدا پوشش متعارف امنیت برنامهی وب، سپس ملاحظات ویژه‌ی مدل. سنجش این پوشش هم کار تست نفوذ وب است، و برای الگوهای کدنویسی تیم، دوره‌ی سازمانی توسعه‌ی امن نقطه‌ی اثر پایدارتری است.
پرسش‌های متداول
هوش مصنوعی جای متخصص امنیت را میگیرد؟
نه در افق قابل پیشبینی، به یک دلیل ساختاری: پرخطرترین یافتههای یک برنامه — نقص کنترل دسترسی و منطق کسبوکار — نیازمند دانستن نیت محصولاند، و آن نیت در کد نوشته نشده است. AI کارهای غربال و تکراری را سریعتر میکند، اما داوری نهایی همچنان انسانی است.
کدی که با کمک هوش مصنوعی نوشته میشود امن است؟
نه ذاتاً. کد تولیدشده همان دستههای آسیبپذیری شناختهشده را بازتولید میکند: نبود بررسی مالکیت رکورد، الحاق رشته در کوئریهای غیرمتعارف، اعتبارنامه در کد نمونه و مدیریت خطای ناقص. چون سرعت تولید بالاتر است، حجم بازبینی لازم هم بیشتر میشود.
مهاجمان از هوش مصنوعی چطور استفاده میکنند؟
آنچه با اطمینان قابل گفتن است، کاهش هزینهی تولید محتوای قانعکننده — بهویژه متن فیشینگ بدون خطای زبانی و در حجم بالا — و تسریع نوشتن اسکریپتهای کمکی است. ماهیت حملات تغییر نکرده و مسیرهای واقعی همچنان اعتبارنامهی افشاشده، مؤلفهی وصلهنشده و نقص کنترل دسترسیاند.
OWASP برای برنامه‌های مبتنی بر مدل زبانی فهرست جداگانه دارد؟
بله، فهرستی با عنوان OWASP Top 10 for LLM Applications که مستقل از Top 10 عمومی منتشر میشود. پیش از استناد به شماره‌ی نسخه یا سال آن، نسخه‌ی جاری را مستقیماً از owasp.org بررسی کنید، چون این فهرست سریعتر به‌روز میشود.
برای محصولی که از مدل زبانی استفاده میکند از کجا شروع کنیم؟
ابتدا از پوشش متعارف امنیت برنامهی وب، چون محصول شما پیش از هر چیز یک برنامهی وب است. سپس دو نکتهی ویژه: هر ورودی مدل را غیرقابل اعتماد در نظر بگیرید، و مجوزدهی را در لایهی سرویس اعمال کنید نه در دستور متنی مدل.
منابع
محمدرضا مقدم
مغز خودکارسازی تیم؛ ابزارها و زیرساخت داخلی پی‌هانتر را می‌سازد تا اسکن و گزارش‌گیری سریعتر و دقیق‌تر انجام شود.