تقریباً در هر جلسهٔ آنبوردینگ نسخهای از این سؤال را میشنوم، معمولاً با احتیاط بیان میشود، طوری که انگار پرسنده نیمی از وجودش انتظار دارد کسی نگرانیاش را کنار بزند. نباید کنار زده شود. امنیت یکی از معدود حوزههایی است که میزان سالمی از بدبینی، بهدرستی سنجیده شده، فارغ از اینکه کد را انسان نوشته باشد یا مدل. سؤالاتی که واقعاً میشنوم را در ادامه تا حد امکان مستقیم پاسخ دادهام.
آیا کدی که هوش مصنوعی مینویسد از کد نوشتهٔ انسان کمامنیتتر است؟
بهطور میانگین، و اگر بدون بررسی رها شود، بله — کمی. یک پژوهش دانشگاه استنفورد از چند سال پیش (پری و همکاران، که اغلب بهعنوان اولین بررسی جدی این موضوع ذکر میشود) نشان داد توسعهدهندگانی که از دستیار کدنویسی هوش مصنوعی استفاده میکردند، کد کمامنیتتری تولید کردند — و بخشی که باید بیشتر نگرانتان کند این است که — کد خودشان را امنتر از واقعیت ارزیابی کردند. اطمینان بالا رفت درحالیکه کیفیت پایین آمد. بررسیهای امنیتی کد تولیدشده با هوش مصنوعی از Veracode هم عددی تقریبی به دست میدهد: چیزی حدود ۴ از هر ۱۰ نمونه کد هوش مصنوعی که آزمایش کردند، حداقل یک نقص قابل بهرهبرداری داشت، معمولاً چیزی پیشپاافتاده مثل نبود بررسی ورودی یا یک مقدار پیشفرض ضعیف. هیچکدام از اینها به این معنا نیست که کد نوشتهشده با هوش مصنوعی ذاتاً محکوم به شکست است. یعنی کد بررسینشدهٔ هوش مصنوعی همان ریسک کد بررسینشدهٔ انسانی را دارد، و خطر واقعی در همان بخش «بررسینشده» نهفته است. مدلی که سریع مینویسد و هرگز بررسی نمیشود، همان اشتباهاتی را مرتکب میشود که یک برنامهنویس تازهکار عصر یک جمعه مرتکب میشود — فقط سریعتر و بیشتر.
چه اتفاقی برای کلیدهای API و اطلاعات محرمانهٔ من میافتد؟
این همان چیزی است که واقعاً خواب را از من میگیرد، چون این اشتباه تا زمانی که اتفاق نیفتاده نامرئی است. حالت شکست چندان دراماتیک نیست — سرور کسی مثل فیلمهای هکری هک نمیشود. بلکه یک کلید در یک گفتوگو پیست میشود، در یک فایل تولیدشده بازتاب پیدا میکند، کامیت میشود، و شش ماه بعد بیصدا بهصورت متن ساده در یک مخزن مینشیند تا وقتی کسی از سر کنجکاوی یک اسکنر اطلاعات محرمانه روی آن اجرا کند. در این پلتفرم، اطلاعات محرمانه هرگز در کد تولیدشده قرار نمیگیرند — در زمان اجرا از یک مخزن رمزگذاریشده، مخصوص تنانت شما، تزریق میشوند و به عاملهای ساخت (build agents) دستور داده شده که آنها را فقط با نام ارجاع دهند، نه با مقدار. اما اگر جای دیگری میسازید، یا اطلاعات محرمانه را مستقیماً در پنجرهٔ گفتوگوی هر ابزاری پیست میکنید، فرض کنید آن متن اکنون بخشی از یک لاگ مرتبط با آموزش مدل در جایی است، مگر اینکه ارائهدهنده صراحتاً خلاف آن را بگوید. هر چیزی که تا به حال در یک کادر گفتوگو تایپ کردهاید را، از باب اصل احتیاط، همان روزی که تست را تمام میکنید تعویض کنید.
آیا کسی میتواند از طریق یک پرامپت، مثل حملهٔ تزریق پرامپت، سایت من را هک کند؟
اینجا دو چیز متفاوت با هم قاطی میشوند، و این تفاوت اهمیت دارد. تزریق پرامپت علیه سازنده — کسی که هوش مصنوعیای که برنامهٔ شما را میسازد را فریب میدهد تا کاری کند که شما نخواستهاید — یک ریسک واقعی و مطالعهشده است، و به همین دلیل عاملهای ساخت با مجوزهای ابزار محدود اجرا میشوند نه با دسترسی کامل شل، و هر چیزی که به سیستم فایل یا خط لولهٔ استقرار شما دست بزند از یک لاگ عملیاتی صریح عبور میکند که بعداً میتوانید حسابرسی کنید. تزریق پرامپت علیه برنامهٔ منتشرشدهٔ شما موضوع جداگانهای است که فقط زمانی صدق میکند که خودِ برنامهتان در زمان اجرا یک LLM را در خود جای داده باشد — یک چتبات پشتیبانی، یک قابلیت جستوجوی هوش مصنوعی، از این دست چیزها. اگر چنین است، هر متنی که کاربر بتواند تایپ کند را ورودی نامعتبر برای آن مدل در نظر بگیرید، درست همانطور که آن را ورودی نامعتبر برای یک کوئری SQL در نظر میگرفتید. قاعده قدیمی است، تنها چیز جدید این است که کدام سیستم دارد رشته را تجزیه میکند.
آیا سازنده پیش از انتشار، کد خودش را از نظر آسیبپذیری بررسی میکند؟
بررسیهای خودکار موارد ملالآور و پرتکرار را بهطور قابلاعتماد شناسایی میکنند: اطلاعات محرمانهٔ هاردکدشده، نبود احراز هویت روی نقطهٔ پایانیای که واضحاً به آن نیاز دارد، کوئری SQL ساختهشده با اتصال رشته بهجای پارامتر، وابستگیهایی با CVE شناختهشده. چیزی که خوب شناسایی نمیکنند، نقصهای منطق کسبوکار هستند — از نوعی که هر خط کد بهتنهایی درست است و آسیبپذیری در شکاف میان دو ویژگی است که هیچکس فکر نکرده باهم بررسیشان کند. کد تخفیفی که بهصورت نامحدود با پاداش ارجاع روی هم انباشته میشود. یک فرآیند بازنشانی رمز عبور که فاش میکند آیا یک ایمیل در سیستم وجود دارد یا نه. اینها به کسی نیاز دارند که بفهمد برنامه برای چه ساخته شده، نه فقط اینکه کد چه کاری انجام میدهد، و هیچ اسکنری — هوش مصنوعی یا غیر آن — هنوز بهطور قابلاعتماد اینها را پیدا نمیکند. بازبینی خودکار یک کف است، نه یک سقف.
بستهٔهای شخص ثالثی که نصب میکند چطور — آیا این یک ریسک زنجیرهٔ تأمین است؟
بله، و صادقانه بگویم، در دنیای واقعی ریسک بزرگتری از خودِ کد نوشتهشده با هوش مصنوعی است. بیشتر برنامهها از نظر تعداد خطوط، ۸۰ تا ۹۵ درصدشان وابستگی هستند؛ کدی که سازنده مینویسد فقط لایهای نازک روی npm، PyPI، یا هر اکوسیستمی است که پشته از آن استفاده میکند. یک بستهٔ مخرب یا ربودهشده میتواند شما را، فارغ از اینکه چه کسی یا چه چیزی کد اتصالی اطراف آن را نوشته، در معرض خطر قرار دهد — رخدادهای event-stream و colors.js را ببینید تا بدانید این در دنیای واقعی چطور رخ میدهد. راهکارهای کاهش ریسک ساده و مؤثرند: بهجای پیگیری آخرین نسخه، نسخهها را پین کنید، بستههایی با سابقهٔ نگهداری واقعی را به بستههایی که هفتهٔ پیش منتشر شدهاند ترجیح دهید، و یک ممیزی وابستگی (`npm audit`، `pip-audit`، یا هرچه با پشتهٔ شما سازگار است) را بهعنوان یک عادت دائمی اجرا کنید، نه یک قدم یکباره پیش از راهاندازی.
| ریسک | چه کسی آن را ایجاد میکند | معمولاً چگونه شناسایی میشود | رفع آن وظیفهٔ کیست |
|---|---|---|---|
| اطلاعات محرمانهٔ هاردکدشده در کد تولیدشده | فرآیند ساخت، اگر اطلاعات محرمانه بهدرستی تزریق نشده باشند | اسکن استاتیک، بررسی پیش از استقرار | پلتفرم |
| نبود اعتبارسنجی ورودی | مدل یا انسان، هرکدام | بازبینی خودکار و دستی کد | هر دو |
| وابستگی آسیبپذیر (CVE) | نگهدارندهٔ بستهٔ بالادستی | ممیزی وابستگی | شما، بهطور مستمر |
| نقص منطق کسبوکار (باگهای انباشتی، IDOR) | هرکسی که ویژگی را ناقص مشخص کرده | تست دستی، معمولاً فقط اگر کسی نگاه کند | شما |
| تزریق پرامپت به یک قابلیت LLM جاسازیشده | کاربران نهایی برنامهٔ منتشرشدهٔ شما | پاکسازی ورودی + مجوزهای محدود مدل | شما |
در صورت نقض امنیتی، مسئولیت با کیست؟
تقریباً همیشه، از نظر قانونی، مسئولیت با شماست — اگر برنامه و دادههای مشتریان متعلق به شماست. این موضوع کسانی را که فکر میکنند «هوش مصنوعی آن را نوشته» مسئولیت را جایی دیگر منتقل میکند، غافلگیر میکند. اینطور نیست، درست مثل اینکه استخدام یک پیمانکار مسئولیت نقض مقررات ساختمانی را از دوش مالک ملک برندارد. پلتفرمها مسئولیت زیرساختی را که خودشان کنترل میکنند بر عهده دارند: چگونگی ذخیرهٔ اطلاعات محرمانه، چگونگی جداسازی دادههای تنانتها، اینکه آیا خودِ لایهٔ میزبانی وصله شده است یا نه. اما منطق برنامهای که شما مشخص کردهاید، دادهای که تصمیم گرفتید جمعآوری کنید، و شرایطی که به کاربرانتان ارائه دادید، متعلق به شماست. اگر با هرچیز حساسی سروکار دارید — جزئیات پرداخت، اطلاعات سلامت، هرچیز مشمول GDPR یا CCPA — بهجای فرض اینکه «ساختهشده با هوش مصنوعی» به معنای یک لایهٔ حفاظت قانونی اضافی است، توافقنامهٔ واقعی پردازش دادههای هر پلتفرمی که استفاده میکنید را بخوانید. اینطور نیست.
یک بار یک بنیانگذار، بیشتر با شوخی، به من گفت که به کد هوش مصنوعی بیشتر از کد خودش اعتماد دارد چون «حداقل ساعت ۲ بامداد خسته نمیشود.» شاید. اما انسانهای خسته معمولاً میدانند که خستهاند. یک هوش مصنوعی هیچ ایدهای ندارد که تازه یک اشتباه مرتکب شده، و با همان لحن مطمئن به شما میگوید کد آماده است، فارغ از اینکه بینقص باشد یا پر از سوراخ. اطمینان یک نشانهٔ امنیتی نیست، از هیچکدام از این دو منبع.
آیا باید پیش از راهاندازی، هزینهٔ یک ممیزی امنیتی واقعی را بپردازم؟
اگر پرداخت میپذیرید، هرچیزی که یک نهاد قانونگذار PII بنامد ذخیره میکنید، یا برای یک مشتری تجاری میسازید که بههرحال گزارش SOC 2 درخواست خواهد کرد — بله، و نگذارید هزینه شما را منصرف کند. یک ممیزی متمرکز روی یک برنامهٔ کوچک، بسته به دامنه، از چند صد تا چند هزار دلار هزینه دارد که در مقایسه با نامهٔ اطلاعرسانی نقض امنیتی، ارزان است. اگر یک پروژهٔ سرگرمی، یک ابزار داخلی، یا چیزی بدون دادهٔ واقعی کاربر میسازید، ممیزی پولی بیشازحد است؛ بهجای آن لایهٔ رایگان و ارزان را اجرا کنید — اسکن وابستگی، مرور دستی هر مرز احراز هویت (آیا کاربر A میتواند با تغییر یک URL چیزهای کاربر B را ببیند؟)، و یک نگاه دوم انسانی به هرچیزی که به پول یا رمز عبور مربوط میشود.
رایجترین اشتباه امنیتی که مردم مرتکب میشوند چیست، و کِی رخ میدهد؟
نه در زمان راهاندازی — سه ماه بعد، وقتی برنامه کار میکند و دیگر کسی به آن نگاه نمیکند. یک مسیر مدیریتی است که بدون محافظت رها شده چون فقط توسط کسی تست شده که آن را ساخته، درحالیکه با حساب خودش وارد شده بود. یک نقطهٔ پایانی دیباگ است که در محیط تولید ردیابی کامل خطا را برمیگرداند. یک رمز عبور پیشفرض روی یک پایگاهداده است که قرار بود «فقط برای تست» باشد و هرگز عوض نشد. هیچکدام از اینها عجیبوغریب نیستند. معادل امنیتی گذاشتن یک کلید یدکی زیر پادری خانه هستند چون آن یکبار عجله داشتید و بعد فراموش کردید آنجاست. راهحل ابزار بهتر نیست، یک عادت پنجدقیقهای است: یک بار در ماه، پنج دقیقه به برنامهتان همانطور نگاه کنید که یک مهاجم نگاه میکند، پیش از اینکه همانطور که یک سازندهٔ مغرور نگاه میکند به آن نگاه کنید.
