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

سود:

• امکان تایید خروجی هوش مصنوعی در سه لایه: دقت، امنیت و منبع/مجوز
• امکان پوشش خطراتی مانند تزریق، بسته های توهم و اسرار مدفون با قالب و ابزار ایمن
• امکان ارائه کد حیاتی امنیتی به تایید مهندس ذیصلاح و درک عدم انتقال مسئولیت

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

در اینجا ما "تأیید اعتبار" را در سه لایه در نظر می گیریم: درستی (آیا کد واقعا کار را انجام می دهد؟)، امنیت (آیا در مقابل ورودی های مخرب مقاومت می کند؟)، و منشأ/مجوز (آیا من حق استفاده از این کد را دارم؟). هر لایه ابزار کنترل خود را دارد و هیچ یک از آنها را نمی توان با "این چیزی است که هوش مصنوعی گفت" دور زد.

سه لایه ریسک

1. خطر دقت (توهم). این مدل ممکن است یک تابع ناموجود را فراخوانی کند، از یک API سوء استفاده کند، یک مورد لبه را بی‌صدا دور بزند. کد به نظر "معقول" است اما اشتباه است. پادزهر: جمع آوری، آزمایش، تجزیه و تحلیل استاتیک و بازرسی بصری.

2. خطر امنیتی. هوش مصنوعی می تواند الگوهای ناامن را در داده های آموزشی تکرار کند: پرس و جو آسیب پذیر به تزریق SQL، ورودی کاربر تایید نشده، رمزگذاری ضعیف، سریال زدایی ناامن، تغییر مسیر باز. کد کار می کند اما در برابر حمله آسیب پذیر است. پادزهر: بررسی متمرکز بر امنیت، اسکنرهای خودکار (SAST) و تحمیل الگوهای امن شناخته شده.

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

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

گام به گام: گیت تأیید هویت لایه ای

1. با درک بخوانید. قبل از پذیرش کد، واقعاً آن را درک کنید. کدهایی را که درک نمی کنید ادغام نکنید. اگر نمی توانید توضیح دهید "چرا کار می کند"، هنوز تایید نشده است.
2. تأیید کنید که وجود دارد. تأیید کنید که هر تابع، API و بسته استفاده شده در واقع وجود دارد و به درستی استفاده می شود (دروازه توهم).
3. ابزارهای خودکار را اجرا کنید. کامپایلر، لینتر (اسکنر سبک/خطا)، بررسی‌کننده نوع، تست‌های واحد و در صورت امکان SAST (تست امنیت برنامه استاتیک - ابزاری که کد منبع را برای آسیب‌پذیری‌ها اسکن می‌کند).
4. از منظر امنیتی به آن نگاه کنید. آیا ورودی تایید شده است؟ آیا پرس و جو پارامتری است؟ آیا راز دفن شده است؟ آیا کنترل مجوز وجود دارد؟
5. منبع و مجوز را بررسی کنید. آیا وابستگی های جدید مجوز دارند؟ آیا خروجی بیش از حد شبیه به یک پایگاه کد شناخته شده است؟
6. اگر از نظر امنیتی حیاتی است، از متخصص درخواست کنید. بررسی مستقل توسط یک مهندس متخصص در زمینه هایی مانند احراز هویت، پرداخت، رمزنگاری، کنترل دسترسی الزامی است.

سه کیف کوچک

مورد 1 - تزریق SQL در دروازه بازرسی گرفتار شد. کد ایجاد شده توسط هوش مصنوعی که ورودی کاربر را مستقیماً به جستجوی SQL برای نقطه پایانی جستجو ("... WHERE name = '" + q + "'") الحاق می کند. کد کار می کرد و تست را با موفقیت پشت سر گذاشت. بازرسی متمرکز بر امنیت و اسکن SAST متوجه این موضوع شد. آن را به یک پرس و جو پارامتری (گزاره آماده) تبدیل شد. اگر کشف نمی شد، یک آسیب پذیری کلاسیک نشت داده بود.

مورد 2 - بسته توهم. هوش مصنوعی یک بسته npm غیر موجود (تجزیه سریع-ایمن) را برای یک کار پیشنهاد کرد. وقتی توسعه دهنده سعی کرد آن را نصب کند، بسته پیدا نشد. بدتر: در برخی موارد، مهاجمان می‌توانند نام‌های بسته‌های "شبح" را با بسته‌های واقعی و مخرب پر کنند (گیج شدن وابستگی). درس: هر بسته توصیه شده را در برابر رجیستری رسمی و تاریخچه دانلود/نگهداری بررسی کنید.

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

چهار قالب قابل کپی

خودآزمایی قبل از پذیرش:

قبل از پذیرش کد تولید شده توسط هوش مصنوعی زیر، بررسی کنید: 1) آیا هر تابع/API/بسته ای که استفاده می کند واقعا وجود دارد؟ مظنونان را علامت گذاری کنید. 2) آیا ورودی نامعتبر، الحاق SQL/فرمان، راز مدفون، رمزنگاری ضعیف وجود دارد؟ 3) اشکالات / موارد لبه خطاب نشده چیست؟ هر یافته را به عنوان "محتمل / محتمل" برچسب بزنید و راه حل هایی را پیشنهاد دهید.{{code}}

بررسی متمرکز بر امنیت:

این کد را با یک چشم امنیتی بررسی کنید. به دنبال آسیب‌پذیری‌های رایج سبک OWASP باشید: تزریق، احراز هویت/مجوز شکسته، افشای داده‌های حساس، سریال‌زدایی ناامن، تغییر مسیر غیرقانونی. برای هر یافته: خطر، سناریوی بهره برداری، اصلاح. این یک غربالگری اولیه است. یافته‌های مهم را به بررسی امنیت انسانی ارجاع دهید.{{code}}

وابستگی و بررسی مجوز:

وابستگی های اضافه شده/پیشنهاد شده توسط این کد را فهرست کنید. برای هر کدام: آیا بسته واقعاً وجود دارد، آیا نگهداری می‌شود، مجوز معمولی آن چیست (MUST BE VERIFIED)، و آیا واقعاً برای پروژه مورد نیاز است یا می‌توان آن را با یک ابزار موجود انجام داد؟{{کد یا لیست وابستگی}}

تحمیل قالب ایمن (در تولید):

برای {{وظیفه}} کد بنویسید. قوانین امنیتی اجباری: - تمام ورودی های خارجی را اعتبار سنجی/عفونی کنید. - فقط از پرس و جوی پارامتری در دسترسی به پایگاه داده استفاده کنید. - اسرار را در کد جاسازی نکنید. متغیر محیطی/مدیر مخفی را فرض کنید - خطاها را قورت ندهید. آن را معنادار در نظر بگیرید. نحوه انطباق کد با این قوانین را در 3 مورد توضیح دهید.

اعلان ضعیف / اعلان قوی

ضعیف: "پرسشی بنویسید که با نام کاربری جستجو می کند." (یک کد آسیب پذیر در برابر تزریق ممکن است رخ دهد.)

Strong: "یک تابع بنویسید که بر اساس نام کاربری جستجو می کند. هرگز ورودی کاربر را به عنوان یک رشته به یک پرس و جو ملحق نکنید؛ از یک پرس و جوی پارامتری (عبارت آماده شده) استفاده کنید. ورودی را برای طول و کاراکتر اعتبار سنجی کنید. در 2 جمله توضیح دهید که چرا کد برای تزریق بسته است."

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

لایه احراز هویت

ابزار/روش

آیا "AI گفته شده" کافی است؟

دقت

گردآوری، تست، بازرسی بصری

نه

API/واقعیت بسته

کنترل سند/سوابق رسمی

نه

امنیت

SAST، بررسی امنیتی

نه

مجوز/منبع

وابستگی و بررسی مجوز

نه

منطق انتقادی امنیت

تاییدیه مهندس خبره

مطلقا نه

مسئولیت قابل انتقال نیست

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

نکته: یک چک لیست کوتاه در تیم خود ایجاد کنید که آن را "دروازه اعتبار سنجی برای کدهای تولید شده توسط هوش مصنوعی" می نامید (ساخت + تست + اسکن امنیتی + بازرسی بصری). هنگامی که این دروازه تبدیل به یک عادت شد، از دست دادن سرعت به حداقل می رسد و کاهش ریسک حداکثر است.

اشتباهات رایج

• اشتباه گرفتن "کارها" با "ایمن". کدی که تست را پشت سر می گذارد ممکن است در برابر حمله آسیب پذیر باشد.
• استفاده از بسته/API بدون تأیید آن. بسته های توهم زا هم فاسد می شوند و هم یک خطر امنیتی ایجاد می کنند.
• دور زدن ابزارهای خودکار لنتر، تایپ چکر و SAST به قیمت ارزانی چیزی را که انسان از دست می دهد می گیرد.
• نادیده گرفتن مجوز وابستگی مجوز نامناسب بار قانونی بر توزیع ایجاد می کند.
• سپردن مسئولیت بر عهده وسیله نقلیه تیم مسئول کد در تولید است. "هوش مصنوعی این کار را کرد" بهانه ای نیست.

به طور خلاصه

پذیرش خروجی هوش مصنوعی به سه لایه تأیید نیاز دارد: صحت (کامپایل، آزمایش، بازرسی بصری)، امنیت (SAST و بررسی متمرکز بر امنیت)، و منبع/مجوز (بررسی وابستگی). تأیید کنید که هر بسته و API مورد استفاده واقعاً وجود دارد، الگوهای ایمن را از ابتدا اعمال کنید، و کدهای مهم امنیتی را برای تأیید توسط یک مهندس واجد شرایط ارسال کنید. "کار می کند" به معنای ایمن نیست و "AI تولید شده" مسئولیت را حذف نمی کند. دروازه تأیید بهای حرفه ای بودن است، نه سرعت.

وظیفه کاربردی

عمداً به هوش مصنوعی یک وظیفه حساس به امنیت بدهید (مثلاً "عملکردی که پایگاه داده را با ورودی کاربر جستجو می کند")، این بار بدون تحمیل الگوی ایمن. کد دریافتی را از طریق الگوهای «ممیزی خود پیش از پذیرش» و «بررسی متمرکز بر امنیت» عبور دهید: آیا تزریق، راز مدفون، بسته توهم‌آمیز، یا ورودی تایید نشده وجود دارد؟ سپس با الگوی «تحمیل الگوی امن» دوباره همان کار را بپرسید و دو خروجی را با هم مقایسه کنید. در صورت امکان، یک ابزار linter/SAST را اجرا کنید و یافته ها را با خود تنظیمی هوش مصنوعی مقایسه کنید.

چک لیست

• [ ] من خروجی هوش مصنوعی را در سه لایه تأیید می کنم: دقت، امنیت و مجوز.
• [ ] تایید می کنم که هر تابع، API و بسته استفاده شده در واقع وجود دارد.
• [ ] من ابزارهای کامپایل، تست، linter و در صورت امکان SAST را اجرا می کنم.
• [ ] من از ابتدا الگوهای امن (پرس و جو پارامتری، اعتبارسنجی ورودی، مدیریت مخفی) را اعمال می کنم.
• [ ] من مجوز و الزامات وابستگی های جدید را بررسی می کنم.
• [ ] من کد مهم امنیتی را برای تأیید توسط یک مهندس ذیصلاح ارسال می کنم و می دانم که مسئولیت آن بر عهده من است.