بازبین امن: هوش مصنوعی در DevSecOps و اطمینان کد

بازبینی امنیتی جست‌وجوی چند الگوی مشکوک در نحو کد نیست. یک یافته زمانی اهمیت دارد که تغییر، مسیری باورپذیر از ورودی تحت کنترل مهاجم به دارایی ارزشمند بسازد، کنترلی را تضعیف کند یا اعتماد به زنجیره تأمین نرم‌افزار را کاهش دهد. هوش مصنوعی می‌تواند در یک تغییر بزرگ حرکت کند، وابستگی‌ها را کنار هم بگذارد، سناریوی سوءاستفاده پیشنهاد کند و شواهد را مرتب سازد؛ اما مسئولیت پذیرش ریسک را به ارث نمی‌برد.

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

از تصمیم امنیتی شروع کنید، نه از مدل

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

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

چارچوب SSDF را به نقشه کنترل تبدیل کنید

چارچوب توسعه امن نرم‌افزار NIST SP 800-218 نسخه ۱.۱ توسعه امن را حول آماده‌سازی سازمان، حفاظت از نرم‌افزار، تولید نرم‌افزار امن‌تر و پاسخ به آسیب‌پذیری سازمان می‌دهد. این سند مجموعه‌ای از توصیه‌های سطح‌بالا و زبان مشترک است؛ نه گواهی محصول و نه تضمین امنیت یک انتشار.

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

مدل تهدید را تا گردش‌کار هوش مصنوعی گسترش دهید

NIST SP 800-218A یک پروفایل نهایی جامعه برای تکمیل SSDF در توسعه هوش مصنوعی مولد و مدل‌های پایه دومنظوره است. مخاطب آن تولیدکنندگان مدل، سازندگان سامانه هوش مصنوعی و خریداران در چرخه عمر است و باید کنار SP 800-218 استفاده شود. این راهنما قانون و اثبات ایمن بودن یک مدل خاص نیست.

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

تمام زنجیره تأمین نرم‌افزار را بازبینی کنید

OWASP Top 10:2025 A03 درباره شکست‌های زنجیره تأمین نرم‌افزار آگاهانه از کتابخانه آسیب‌پذیر فراتر می‌رود و مخزن منبع، سامانه ساخت، محیط توسعه، مخزن آرتیفکت، مدیریت وابستگی، توزیع و مسیر به‌روزرسانی را شامل می‌شود. فهرست OWASP یک سند آگاهی‌رسانی است، نه گواهی انطباق؛ اما دامنه گسترده آن اصلاح خوبی برای بازبینی صرفاً کدمحور است.

مشخصات SLSA نسخه ۱.۲ که وضعیت Approved دارد، برای منشأ کد و ساخت، قالب attestation و سطوح تدریجی تضمین ارائه می‌کند. SLSA استاندارد اجماع صنعتی است، نه تنظیم‌گر و نه تضمین کلی ایمن‌بودن نرم‌افزار. سابقه منشأ آن را برای بررسی چگونگی تولید آرتیفکت به‌کار ببرید و سپس با بازبینی، آزمون، مدیریت آسیب‌پذیری و سیاست استقرار ترکیب کنید.

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

زمینه و مجوز بازبین را محدود کنید

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

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

برای هر یافته شواهد بازتولیدپذیر بخواهید

یافته مفید، فایل و خط، قاعده نقض‌شده، منبع تحت کنترل مهاجم، مقصد حساس یا کنترل، مسیر اجرای محتمل و راه تأیید یا رد ادعا را نام می‌برد. یافته وابستگی باید بسته دقیق، نسخه حل‌شده، نشانه منشأ، منبع هشدار یا سیاست و در صورت امکان استفاده قابل‌دسترسی را نشان دهد. جمله «ممکن است ناامن باشد» فرضیه است، نه مانع انتشار.

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

تحلیل احتمالی را با کنترل قطعی ترکیب کنید

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

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

با حالت‌های شکست واقعی ارزیابی کنید

مجموعه ارزیابی را از تاریخ واقعی سازمان بسازید: آسیب‌پذیری تأییدشده، هشدار پرنویز اسکنر، پسرفت مجوز، بسته مخرب یا رهاشده، تغییر ناامن اسکریپت ساخت، افشای راز و استثنای قابل‌قبول. نمونه منفی دشوار هم بگذارید؛ مواردی که شبیه آسیب‌پذیری‌اند اما قابل‌دسترسی نیستند یا کنترل جبرانی دارند. تلاش برای دست‌کاری بازبین از طریق comment، متن مسئله، فایل تولیدی و مستند وابستگی را نیز بیازمایید.

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

کنترل درخواست تغییر باید ایمن شکست بخورد

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

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

اصلاح تولیدشده را کد غیرقابل‌اعتماد بدانید

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

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

حلقه یادگیری اطمینان را اداره کنید

بازخورد تولید باید هم سامانه تشخیص و هم فرایند توسعه را بهتر کند. ثبت کنید کدام یافته پذیرفته، رد، به تعویق انداخته یا بعداً دوباره کشف شده است. خوشه‌ها را بررسی کنید: تکرار کد ناامن شاید از نبود primitive پلتفرم خبر دهد؛ مثبت کاذب تکراری شاید قاعده مستندنشده را نشان دهد؛ و استثنای زیاد وابستگی شاید ضعف خرید یا سیاست ساخت باشد.

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

برنامه عملی سی‌روزه

در هفته نخست یک مخزن و یک تصمیم محدود، مثلاً تغییر API حساس به مجوز، انتخاب کنید. آن را به رویه SSDF وصل کنید، مالک بنویسید و عمل ممنوع را مشخص سازید. هفته دوم زمینه فقط‌خواندنی و اسکنر قطعی را متصل کنید و یافته مدرک‌دار بسازید. هفته سوم با تغییرات تاریخی و محتوای خصمانه مخزن ارزیابی کنید، درحالی‌که نتیجه هنوز توصیه‌ای است.

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

یادداشت منابع

منابع در ۳۰ ژوئیه ۲۰۲۶ بازبینی شدند. NIST SP 800-218 نسخه نهایی ۱.۱ در سال ۲۰۲۲ است؛ NIST یک پیش‌نویس نسخه ۱.۲ منتشرشده در دسامبر ۲۰۲۵ نیز فهرست می‌کند و این مقاله آن پیش‌نویس را نهایی معرفی نمی‌کند. SP 800-218A پروفایل نهایی جامعه برای هوش مصنوعی است که باید کنار SSDF استفاده شود. OWASP A03 بخشی از فهرست آگاهی‌رسانی ۲۰۲۵ است و گواهی، مقرره یا برنامه کامل توسعه امن به‌شمار نمی‌رود.

منابع اصلی و معتبر:

• چارچوب توسعه امن نرم‌افزار NIST نسخه ۱.۱
• پروفایل جامعه NIST SP 800-218A برای هوش مصنوعی مولد
• OWASP Top 10:2025 A03 — شکست‌های زنجیره تأمین نرم‌افزار
• مشخصات SLSA نسخه ۱.۲