ریسکهای کد تولیدشده با هوش مصنوعی
مشکل کد تولیدشده این نیست که بد به نظر میرسد. مشکل این است که خوب به نظر میرسد.
نامگذاری تمیز است، ساختار مرتب است، و منطقش قابل قبول. بازبینی سرسری از آن عبور میکند — و همان جایی اشتباه دارد که سرسری دیده نمیشود.
چرا اشتباهها اینجا متمرکزند
این ابزارها روی حجم عظیمی از کد آموزش دیدهاند — و بخش زیادی از آن کد، نمونهٔ آموزشی است، نه کد تولیدی.
نمونههای آموزشی عمداً سادهاند: بررسی خطا ندارند، اعتبارسنجی ندارند، بررسی دسترسی ندارند. هدفشان توضیح یک مفهوم است، نه امن بودن.
نتیجهٔ عملی: کد تولیدی، مسیر موفق را خوب مینویسد و مسیرهای دیگر را ناقص.
الگوهای پرتکرار
بررسی دسترسی جاافتاده
کدی که رکورد را با شناسه میخواند و برمیگرداند — بدون بررسی اینکه این کاربر حق دیدن این رکورد را دارد.
این شایعترین و پرهزینهترین است، چون در تست دیده نمیشود: تست با کاربر خودش انجام میشود و همیشه میگذرد. همان رخنهای که در امنیت نرمافزار و سطوح دسترسی شایعترین نامیدیمش.
بپرسید: آیا اینجا بررسی شده که این کاربر مجاز است این رکورد خاص را ببیند؟
اعتبارسنجی فقط سمت کاربر
کد فرانتاندی که اعتبارسنجی کامل دارد و سمت سرور هیچ. اعتبارسنجی سمت کاربر تجربهٔ کاربری است نه امنیت — که در امنیت سمت کاربر گفتیم.
ساخت کوئری با چسباندن رشته
هنوز اتفاق میافتد، بهویژه وقتی کوئری پیچیده باشد و ابزار برای «خواناتر شدن» رشتهها را به هم بچسباند.
مدیریت ضعیف خطا
بلوکهایی که خطا را میگیرند و بیصدا رد میشوند. خطای خاموش، بدتر از خرابی است — چون سامانه ظاهراً کار میکند و داده غلط تولید میشود.
رمزنگاری قدیمی یا خودساخته
الگوریتمهای منسوخ، یا بدتر: کد رمزنگاری دستساز. قاعدهٔ همیشگی: رمزنگاری را خودتان ننویسید — و این وقتی ابزار با اطمینان کدی تولید میکند که درست به نظر میرسد، مهمتر میشود.
اطلاعات حساس در لاگ
لاگهایی که برای اشکالزدایی مفیدند و توکن و رمز و دادهٔ شخصی را ثبت میکنند.
مقادیر پیشفرض ناامن
دسترسی باز بهجای بسته، رمز پیشفرض، پیکربندی توسعه که به تولید میرود.
وابستگی جعلی، ریسکی که کمتر شناخته شده
الگوی خاصی که ارزش دانستن دارد: ابزار گاهی نام کتابخانهای را پیشنهاد میدهد که وجود ندارد.
خطر اینجاست که مهاجم میتواند بستهٔ واقعی با همان نام منتشر کند و منتظر بماند تا کسی نصبش کند. نام قابل باور است، در کد پیشنهادشده آمده، و برنامهنویس عجول نصبش میکند.
قاعده: هر وابستگی جدیدی که در کد پیشنهادی آمده را پیش از نصب بررسی کنید — وجود دارد؟ چند وقت است؟ چه کسی نگهداریاش میکند؟
همان بررسیای که برای هر وابستگی باید انجام شود، اینجا فقط ضروریتر است.
مسئلهٔ مجوز
کد تولیدشده ممکن است به کد موجودی شبیه باشد که مجوز محدودکننده دارد.
برای پروژههای داخلی معمولاً مسئلهساز نیست. برای محصولی که میفروشید یا کدی که به مشتری تحویل میدهید، این ریسک را در قرارداد ببینید — بهویژه بند مالکیت که در مدلهای برونسپاری گفتیم باید صریح باشد.
چه چیزی این ریسکها را کم میکند
تحلیل ایستا و بررسی خودکار امنیت در خط لوله. اینها الگوهای شناختهشده را میگیرند و در برابر کد تولیدی بهمراتب ارزشمندتر شدهاند، چون حجم کد بالا رفته.
بررسی خودکار وابستگیهای آسیبپذیر، که هم مسئلهٔ وابستگی جعلی را کم میکند و هم آسیبپذیریهای شناختهشده را.
بازبینی انسانی سختگیرتر، نه شلتر. با فهرست مشخص: دسترسی، اعتبارسنجی سرور، مدیریت خطا، لاگ.
قاعدهٔ «هیچ کدی که نمیفهمید وارد پروژه نمیشود»، که در دستیار کدنویسی گفتیم و اینجا شکل امنیتی پیدا میکند.
و مهمترین: کد امنیتی حساس را دستی بنویسید. احراز هویت، رمزنگاری، بررسی دسترسی، پرداخت. اینها بخش کوچکی از کدند و بیشترین خسارت را دارند.
سیاست عملی
اگر تیم دارید، این چهار بند کافی است:
۱. کد تولیدی در این حوزهها استفاده نشود: احراز هویت، رمزنگاری، بررسی دسترسی، پرداخت. ۲. هیچ کلید، رمز، دادهٔ مشتری یا کد تحت NDA در ورودی نرود. ۳. هر وابستگی جدید پیش از نصب بررسی شود. ۴. مسئولیت با نویسنده است. «هوش مصنوعی نوشت» توضیح قابل قبولی برای رخنه نیست.
و یک تصحیح انتظار
هیچکدام از این ریسکها جدید نیستند. کد ناامن پیش از این ابزارها هم نوشته میشد.
آنچه عوض شده سرعت تولید است: کد بیشتری در زمان کمتری وارد پروژه میشود، و ظرفیت بازبینی به همان نسبت بالا نرفته.
پس مسئلهٔ واقعی نه کیفیت ابزار است و نه هوشیاری برنامهنویس. نسبت حجم کد به ظرفیت بازبینی است — و راهحلش سرمایهگذاری روی همان لایههای خودکاری است که بالا گفتیم، نه سختگیری بیشتر روی آدمها.