خطرات امنیتی کدنویسی با هوش مصنوعی و شکاف دیدپذیری آن

کدهای باهوش، ریسک های نامرئی؛ چرا باید ردپای برنامه نویسی هوش مصنوعی را ببینیم؟

ابزارهای مولد سرعت توسعه نرم افزار را حسابی بالا برده اند، اما پشت این سرعت هیجان انگیز یک دردسر جدی پنهان شده است: امنیت کدنویسی با هوش مصنوعی. وقتی تیم ها نمی دانند هر قطعه کد از کدام مدل، پرامپت یا منبع آمده، شکاف دیدپذیری شکل می گیرد و شناسایی آسیب پذیری های کد تولیدشده با هوش مصنوعی سخت تر می شود. این وضعیت می تواند امنیت نرم افزار و مدیریت ریسک هوش مصنوعی را مستقیما تحت تأثیر قرار دهد.

ماجرا فقط این نیست که یک دستیار هوشمند شاید تابعی اشتباه بنویسد. خطر اصلی از جایی شروع می شود که آن تابع بدون ثبت سابقه، بررسی دقیق یا مشخص بودن منبع وارد مخزن اصلی می شود. چند هفته بعد هم دیگر کسی یادش نیست کدام بخش را توسعه دهنده نوشته و کدام بخش با پیشنهاد یک مدل زبانی ساخته شده است.

مطالعه مقاله قبلی در دسته بندی بازی و سرگرمی با عنوان مدت زمان داستان بازی Fable بین ۱۵ تا ۲۰ ساعت خواهد بود.

سرعت بیشتر، اما با چه هزینه ای؟

هوش مصنوعی حالا می تواند در چند ثانیه کدهای تکراری بنویسد، تست بسازد، خطاها را توضیح دهد و حتی ساختار یک سرویس کامل را پیشنهاد کند. برای توسعه دهنده ای که با فهرست بلندبالای کارها درگیر است، چنین قابلیتی واقعا نجات بخش به نظر می رسد.

مشکل اینجاست که سرعت تولید کد لزوما با سرعت بررسی آن برابر نیست. ممکن است یک برنامه نویس در یک ساعت ده ها پیشنهاد را بپذیرد، اما تیم امنیت فرصت نداشته باشد همه آن ها را با همان دقت بررسی کند. در نتیجه، حجم کد رشد می کند و توان نظارت عقب می ماند.

کد پیشنهادی شاید در نگاه اول تمیز، منطقی و حتی حرفه ای باشد. بااین حال، ظاهر مرتب تضمین نمی کند که الگوریتم امن است. مدل ممکن است یک الگوی قدیمی، تابع منسوخ شده یا روش احراز هویتی را پیشنهاد کند که سال هاست استفاده از آن توصیه نمی شود.

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

ریسک فقط یک باگ ساده نیست

وقتی درباره کد تولیدشده با هوش مصنوعی حرف می زنیم، خیلی ها فوری یاد باگ می افتند. باگ مهم است، اما تنها نگرانی نیست. یک پیشنهاد اشتباه می تواند مجوز نرم افزاری نامناسب، وابستگی ناامن، کتابخانه جعلی یا بخشی از کدی با منشأ نامعلوم را وارد محصول کند.

مدل های مولد معمولا پاسخ را براساس الگوهایی می سازند که در داده های آموزشی دیده اند. توسعه دهنده هم همیشه نمی تواند بفهمد خروجی واقعا تازه است یا شباهت زیادی به یک نمونه موجود دارد. اگر منشأ کد ثبت نشود، بررسی مسائل حقوقی و مجوزها بعدا به کاری پیچیده و پرهزینه تبدیل خواهد شد.

از طرف دیگر، مهاجمان می توانند بسته هایی با نام های شبیه کتابخانه های معروف منتشر کنند. اگر ابزار هوشمند نام یکی از این بسته ها را پیشنهاد دهد و توسعه دهنده بدون بررسی آن را نصب کند، راه ورود مهاجم به زنجیره تأمین نرم افزار باز می شود.

حتی یک وابستگی کوچک می تواند سطح دسترسی بزرگی داشته باشد. بسته ای که برای تبدیل تاریخ یا اعتبارسنجی یک ورودی نصب شده، شاید هنگام اجرا به متغیرهای محیطی، کلیدهای API یا اطلاعات حساس دسترسی پیدا کند. همین جزئیات ظاهرا ساده، امنیت نرم افزار را به خطر می اندازند.

مدل همچنین ممکن است پاسخ هایی با اعتمادبه نفس بالا تولید کند. کد بدون هشدار ارائه می شود و توضیحاتش هم قانع کننده است، اما در عمل ورودی را درست پاک سازی نمی کند یا کنترل دسترسی ناقصی دارد. لحن مطمئن ابزار نباید جای آزمون فنی را بگیرد.

مشکل اصلی، گم شدن ردپای کد است

در فرایند سنتی، معمولا می توان فهمید چه کسی یک تغییر را ایجاد کرده، چرا آن را نوشته و چه افرادی آن را بازبینی کرده اند. سامانه کنترل نسخه، درخواست ادغام و پیام های ثبت تغییرات بخشی از این سابقه را نگه می دارند.

اما اگر توسعه دهنده خروجی ابزار هوشمند را کپی کند و مستقیم داخل پروژه بگذارد، تنها نام همان توسعه دهنده در تاریخچه باقی می ماند. اطلاعاتی درباره مدل، نسخه آن، متن درخواست، پاسخ اولیه و اصلاحات بعدی ثبت نمی شود.

این کمبود اطلاعات، مدیریت ریسک هوش مصنوعی را دشوار می کند. فرض کنید بعدا مشخص شود نسخه خاصی از یک مدل، پیاده سازی ناامنی برای رمزنگاری پیشنهاد می کرده است. اگر سازمان نداند کدام فایل ها با آن نسخه ساخته شده اند، مجبور می شود کل پروژه را بگردد.

در مقابل، داشتن سابقه دقیق کمک می کند دامنه حادثه سریع مشخص شود. تیم می تواند ببیند کدام قطعه ها با ابزار موردنظر تولید شده اند، چه کسی آن ها را تأیید کرده و آیا پیش از انتشار اسکن امنیتی روی آن ها انجام شده است یا نه.

این اطلاعات قرار نیست برای سرزنش برنامه نویس جمع آوری شود. هدف، ساختن یک زنجیره روشن از تصمیم هاست. اگر کارکنان احساس کنند ثبت استفاده از هوش مصنوعی به ابزار نظارتی علیه آن ها تبدیل می شود، احتمالا استفاده خود را مخفی می کنند و مشکل بدتر خواهد شد.

ابزارهای قدیمی همه چیز را نمی بینند

اسکنرهای امنیتی همچنان ضروری اند. آن ها می توانند بسیاری از الگوهای خطرناک، رمزهای افشاشده و وابستگی های آسیب پذیر را پیدا کنند. بااین حال، بیشتر این ابزارها خروجی نهایی را بررسی می کنند و اطلاعات چندانی درباره چگونگی تولید کد ندارند.

دو قطعه کد ممکن است کاملا مشابه باشند، اما سطح ریسک یکسانی نداشته باشند. یکی را یک متخصص پس از بررسی مستندات نوشته و دیگری از پاسخ مدلی ناشناس، با تنظیمات نامعلوم، کپی شده است. اسکنر معمولا این تفاوت زمینه ای را تشخیص نمی دهد.

همین مسئله باعث می شود امنیت کدنویسی با هوش مصنوعی فقط با خرید یک ابزار اسکن تازه حل نشود. سازمان باید کنترل های امنیتی را از انتهای مسیر به ابتدای آن منتقل کند؛ یعنی از لحظه ای که پرامپت نوشته می شود تا زمانی که کد به محیط عملیاتی می رسد.

البته ثبت پرامپت ها هم باید با احتیاط انجام شود. گاهی توسعه دهنده ناخواسته بخشی از اطلاعات مشتری، کد محرمانه یا کلید دسترسی را در متن درخواست قرار می دهد. ذخیره بی حساب این داده ها می تواند خودش یک ریسک تازه بسازد.

راه منطقی، ثبت حداقل اطلاعات ضروری همراه با حذف خودکار داده های حساس است. نام ابزار، نسخه مدل، زمان تولید، فایل مقصد و نتیجه بررسی امنیتی معمولا برای ایجاد دید اولیه کافی هستند. جزئیات بیشتر باید براساس حساسیت پروژه نگهداری شوند.

دیدپذیری واقعی از محیط توسعه آغاز می شود

امنیت نباید فقط نزدیک زمان انتشار وارد بازی شود. اگر یک پیشنهاد خطرناک از همان محیط توسعه شناسایی شود، اصلاحش ساده و ارزان است. اما همان پیشنهاد پس از ورود به چند سرویس و انتشار برای مشتریان، به یک بحران واقعی تبدیل می شود.

سازمان ها بهتر است فهرست روشنی از ابزارهای مجاز داشته باشند. این فهرست باید مشخص کند چه مدل هایی برای پروژه های عمومی، داخلی یا بسیار حساس قابل استفاده اند. ممنوعیت مبهم و کلی معمولا جواب نمی دهد؛ چون کارکنان سراغ ابزارهای شخصی و حساب های ثبت نشده می روند.

سیاست خوب باید قابل اجرا باشد. مثلا می توان تعیین کرد کد مربوط به احراز هویت، پرداخت، رمزنگاری و کنترل دسترسی همیشه به بازبینی انسانی دوم نیاز دارد. پیشنهادهای مربوط به کتابخانه های تازه نیز باید پیش از نصب، از نظر اعتبار و مجوز بررسی شوند.

آموزش توسعه دهندگان هم نباید به جمله «به هوش مصنوعی اعتماد نکنید» محدود شود. آن ها باید نمونه های واقعی خطا را ببینند، روش اعتبارسنجی خروجی را یاد بگیرند و بدانند چه نوع اطلاعاتی نباید وارد پرامپت شود.

وقتی تیم بداند چرا یک قانون ایجاد شده، همکاری بهتری نشان می دهد. ولی اگر سیاست ها فقط سرعت کار را کم کنند و توضیحی پشت آن ها نباشد، خیلی زود راه های دور زدنشان پیدا می شود.

بررسی انسانی هنوز قابل حذف نیست

برخی تیم ها تصور می کنند اگر مدل کد را نوشته و یک مدل دیگر آن را بررسی کند، دیگر نیازی به بازبینی انسان نیست. این روش می تواند مفید باشد، اما استقلال واقعی ایجاد نمی کند. دو مدل شاید تحت تأثیر الگوهای مشابه، یک اشتباه مشترک را درست تشخیص ندهند.

بازبین انسانی زمینه کسب وکار را می شناسد. او می داند یک تابع قرار است با چه داده ای کار کند، چه سطح دسترسی قابل قبول است و شکست آن چه اثری روی مشتری دارد. این درکی نیست که همیشه از خود کد قابل استخراج باشد.

البته انسان هم خسته می شود و اشتباه می کند. بهترین رویکرد، ترکیب بررسی انسانی با آزمون خودکار، تحلیل ایستا، اسکن وابستگی و تست های امنیتی است. هر لایه بخشی از خطر را می گیرد و مجموع آن ها دفاع قابل اعتمادتری می سازد.

برای کد تولیدشده با هوش مصنوعی، تست منفی اهمیت بیشتری دارد. نباید فقط بررسی کنیم که برنامه در حالت عادی کار می کند؛ باید ورودی مخرب، دسترسی غیرمجاز، قطع سرویس و رفتار خارج از انتظار را هم امتحان کنیم.

چطور شکاف دیدپذیری را ببندیم؟

قدم اول این است که سازمان واقعا بداند کارکنان از چه ابزارهایی استفاده می کنند. یک بررسی بدون تنبیه می تواند تصویر خوبی از وضعیت فعلی بدهد. احتمالا نتیجه نشان می دهد استفاده از هوش مصنوعی خیلی بیشتر از چیزی است که مدیران تصور می کردند.

قدم دوم، متصل کردن اطلاعات تولید کد به جریان توسعه است. سابقه استفاده از مدل می تواند کنار درخواست ادغام، نتیجه تست ها و تأیید بازبین ذخیره شود. این کار ردپایی می سازد که هنگام ممیزی یا واکنش به حادثه حسابی به درد می خورد.

قدم سوم، درجه بندی ریسک است. یک اسکریپت داخلی ساده با سامانه پرداخت یا پرونده های پزشکی برابر نیست. کنترل ها باید با حساسیت داده، اهمیت سرویس و میزان دسترسی کد تناسب داشته باشند.

قدم چهارم، اندازه گیری مداوم است. تیم باید بداند چه مقدار کد با کمک مدل ها ساخته شده، چند پیشنهاد رد شده، چه آسیب پذیری هایی تکرار می شوند و اصلاح آن ها چقدر زمان می برد. بدون این داده ها، مدیریت ریسک هوش مصنوعی بیشتر شبیه حدس زدن خواهد بود.

در نهایت، هدف متوقف کردن نوآوری نیست. ابزارهای مولد می توانند کارهای خسته کننده را کم کنند و فرصت بیشتری برای حل مسئله های مهم بدهند. اما سرعت وقتی ارزشمند است که بدانیم چه چیزی وارد محصول شده و در صورت بروز مشکل، چطور آن را پیدا کنیم.

امنیت کدنویسی با هوش مصنوعی به معنی ترسیدن از هر پیشنهاد خودکار نیست. معنی اش این است که خروجی مدل را مثل کدی واقعی، اثرگذار و نیازمند پاسخ گویی ببینیم. با بستن شکاف دیدپذیری، ثبت منشأ کد و حفظ بازبینی انسانی می توان از مزایای این فناوری استفاده کرد، بدون اینکه یک ریسک نامرئی را یواشکی وارد نرم افزار کنیم.

برای دریافت جدیدترین اخبار تکنولوژی با مجله هوش مصنوعی با ما همراه باشید