کسب‌وکار آنلاین خبر و تحلیل

گزارش تازه از ریسک «وایب‌کدینگ»: وقتی ساختِ سریع از بررسی امنیتی جلو می‌زند

قلعه‌های مقواییِ عصر هوش مصنوعی
یونس مرادی
زمان مطالعه ۵ دقیقه
بازبینی: دانیال طبایی
صحت سنجی شده

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

ریسک پنهان برنامه‌نویسی آسان با هوش مصنوعی

تحقیقات رد اکسس نشان می‌دهد که این شرکت حدود ۳۸۰ هزار دارایی عمومی مرتبط با ابزارها و پلتفرم‌هایی مانند «لاوبل» (Lovable)، «رپلیت» (Replit)، «بیس۴۴» (Base44) و «نتلیفای» (Netlify) را بررسی کرده است.
حدود ۵۰۰۰ مورد از این دارایی‌ها ظاهراً برای استفاده‌های کاری یا شرکتی ساخته شده بودند و نزدیک به ۴۰ درصد از همین گروه، به‌دلیل ضعف یا نبود کنترل دسترسی مؤثر، بخشی از داده‌های حساس را در معرض مشاهده عمومی قرار داده‌اند.

نکته:

این عددها مربوط به دامنه همین پژوهش است و نباید به همه اپلیکیشن‌های ساخته‌شده با هوش مصنوعی تعمیم داده شود

نمونه‌هایی که در گزارش رد اکسس و بررسی رسانه‌هایی مانند «وایرد» (WIRED) و «اکسیوس» (Axios) به آن‌ها اشاره شده، شامل این موارد است:

  • اطلاعات شخصی و برنامه‌ کاری پزشکان
  • اسناد مالی و فروش شرکت‌ها
  • سوابق گفت‌وگوی مشتریان با چت‌بات‌ها (شامل نام کامل و اطلاعات تماس آن‌ها)
  • سوابق فروش و اطلاعات محموله‌ شرکت‌ها

این نمونه‌ها نشان می‌دهند مسئله فقط «کد بد» نیست؛ گاهی داده واقعی وارد ابزاری شده که هنوز برای استفاده کاری امن‌سازی نشده است.

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

مشکل از هوش مصنوعی است یا نحوه استفاده از آن؟

مشکل لزوماً از خود هوش مصنوعی شروع نمی‌شود؛ خطر اصلی وقتی شکل می‌گیرد که یک ابزار آزمایشی، بدون دانش امنیتی و بدون بررسی فنی، به داده واقعی وصل شود. مثلاً اگر یک کارمند غیر فنی با «وایب‌کدینگ» (Vibe Coding) یک فرم ثبت‌سفارش یا داشبورد داخلی بسازد، ممکن است ظاهر کار درست به نظر برسد؛ اما اگر احراز هویت، سطح دسترسی، وضعیت انتشار و محل نگهداری داده‌ها بررسی نشده باشد، همان ابزار ساده می‌تواند راهی برای دسترسی عمومی به اطلاعات حساس باز کند.

از طرف دیگر شرکت‌های نام‌برده همه‌ی روایت RedAccess را بدون قید نپذیرفته‌اند. Replit گفته کاربران می‌توانند عمومی یا خصوصی بودن اپ‌های خود را انتخاب کنند و عمومی بودن یک اپِ منتشرشده در اینترنت، به‌خودی‌خود نشانه رخنه امنیتی نیست. مالک Base44، هم تأکید کرده که در برخی موارد مسئله به انتخاب یا تنظیمات کاربر برمی‌گردد، نه آسیب‌پذیری پلتفرم. Lovable نیز اعلام کرده گزارش‌های مربوط به داده‌های افشاشده و سایت‌های فیشینگ را جدی می‌گیرد و برای بررسی دقیق‌تر به اطلاعات فنی و URLهای مشخص نیاز دارد. بنابراین مسئله را باید ترکیبی از طراحی پلتفرم، تنظیمات انتشار، آگاهی کاربر و نبود نظارت سازمانی دانست.

خطری برای کاربران عادی

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

برای حفظ امنیت باید چه کار کنیم؟

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

اگر کارمند یا مدیر یک کسب‌وکار هستید:

  • هرگز اطلاعات واقعی مشتریان، رمزهای عبور، اسناد مالی یا داده‌های حساس شرکت را در اپلیکیشن‌های ساخته شده با هوش مصنوعی وارد نکنید.
  • با تیم خود یک قانون روشن بگذارید: هیچ ابزار ساخته‌شده با هوش مصنوعی نباید بدون بررسیِ امنیتیِ یک فرد متخصص، وارد چرخه‌ی کار روزانه شود.
  • نمونه‌سازی با هوش مصنوعی آزاد است، اما استفاده کاری با داده واقعی فقط بعد از بررسی فنی و امنیتی مجاز است.
  • اگر به عمومی بودن یا امن بودن یک ابزار شک دارید، اول دسترسی آن را محدود کنید، بعد از فرد متخصص کمک بگیرید.
  • کلیدهای API، توکن‌ها، رمزهای اتصال و اطلاعات دیتابیس را داخل پرامپت، چت ابزار، کد، صفحه عمومی یا بخش قابل مشاهده قرار ندهید؛ برای این موارد باید از بخش‌های امن مخصوص نگهداری secret استفاده شود.
  • اگر با ابزارهایی مثل Lovable، Replit، Netlify یا Base44 چیزی ساخته‌اید، فقط به ظاهر خصوصی بودن پروژه اکتفا نکنید؛ دسترسی اپ منتشرشده، صفحه ورود، نقش کاربران، اتصال به دیتابیس و قابل مشاهده نبودن داده‌ها را هم بررسی کنید.
نوشدارو پلاس
نوشدارو پلاس

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

در آخر

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

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

بازبینی: دانیال طبایی

پست‌های مرتبط

مطالب پرنگاه

ویدیوهای نوشدارو

ویدیو های بیشتر

حکایت‌های کوتاه، حقیقت‌های بزرگ

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

ویدیو های بیشتر

منابع

  1. Wired
    https://www.wired.com/story/thousands-of-vibe-coded-apps-expose-corporate-and-personal-data-on-the-open-web/