‏وقتی دستیار کدنویسی AI تیم امنیتت رو به شورش واداشت

یه تجربه واقعی از دل یه جلسه ریسک: نویسنده تأیید می‌کنه که یه دستیار کدنویسی AI در تیم توسعه استفاده بشه — نه به خاطر هیجان‌زدگی از فناوری، بلکه چون توسعه‌دهنده‌ها زیر بار کارهای تکراری له شده بودن. بوروکراسی بدهی فنی، drift مستندات، و کدهای legacy قدیمی وقت و انرژی آدم‌ها رو می‌خورد. ابزاری مثل GitHub Copilot که در ۲۰۲۵ بیش از ۱۵ میلیون توسعه‌دهنده ازش استفاده می‌کردن، یه تسکین واقعی به نظر می‌رسید، نه یه معجزه.

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

Snyk یه مورد واقعی از فوریه ۲۰۲۶ گزارش داد که در اون یه زنجیره آسیب‌پذیری، بات triage یه ابزار کدنویسی AI رو به مسیر حمله supply chain تبدیل کرد. این دیگه یه بحث فلسفی نیست؛ یه سوال عملیاتیه. کد تولیدشده توسط AI می‌تونه ظاهر تمیز و منظمی داشته باشه و در عین حال secrets رو بد مدیریت کنه، validation ضعیف داشته باشه، یا dependency هایی رو وارد کنه که هیچ‌کس قصد نداشت مالکشون باشه.

دعوای اصلی بین تیم امنیت و بقیه، جنگ engineering در برابر security نبود. جنگ سرعت در برابر اثبات بود. چهار محور اصلی مشکل: Velocity (خروجی ابزار از ظرفیت تضمین کیفیت پیشی گرفت)، Visibility (مشخص نبود ابزار کجا و با چه promptهایی استفاده شده)، Validation (فرآیندهای بررسی برای دنیایی طراحی شده بودن که انسان اولین پیش‌نویس رو می‌نوشت)، و Governance (هیچ‌کس قوانینی که مهم بودن رو ننوشته بود).

راه‌حل نه ممنوعیت بود نه چشم‌پوشی. آن‌ها rollout رو محدود کردن و شرایط اعتماد رو بازنویسی کردن. موارد کم‌ریسک مثل نوشتن تست، توضیح کدهای قدیمی و پیشنهاد boilerplate باز موندن. اما موارد پرریسک مثل auth flow، مدیریت secrets، منطق رمزنگاری و infrastructure-as-code محیط‌های حساس، یا محدودیت‌های سخت‌تر گرفتن یا از scope خارج شدن. یه خط قرمز هم برای prompt hygiene کشیده شد: هیچ داده مشتری، هیچ credential، و هیچ جزئیات معماری محرمانه‌ای نباید وارد پنجره chat می‌شد.

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

نکات کلیدی:

• ابزارهای AI کدنویسی فقط تحویل نرم‌افزار رو تغییر نمی‌دن؛ شرایط اعتماد داخل سازمان رو هم عوض می‌کنن
• خطر اصلی کیفیت کد نیست، بلکه حجم، منشأ، و سرعت رسیدن کد به production هست
• تفاوت بین rollout موفق و بی‌نظمی مودبانه، همون governance هست که کسی حوصله نوشتنش رو نداره
• prompt hygiene یه قانون واضح می‌خواد، نه یه چیز «که همه می‌دونن»
• امنیت باید از اول در طراحی باشه، نه آخر لحظه به عنوان منتقد
• NIST هم تأکید داره که monitoring پس از استقرار سیستم‌های AI ضروریه چون رفتار واقعی drift می‌کنه