خبر تأییدشده
GitHub در ۲۸ اکتبر افزونه امنیتی برنامه Copilot را به پیش‌نمایش عمومی برد. کاربران دارای دسترسی می‌توانند هشدارهای باز code scanning را مرور کنند، توضیح بخواهند یا اصلاح پیشنهادی بگیرند. تغییرها در نسخه کاری محلی اعمال می‌شوند و ابزار خودکار commit یا push نمی‌کند. فرمان /security-review نیز تغییرهای جاری را بررسی می‌کند. استفاده از Explain، Fix و بررسی امنیتی مصرف AI دارد، اما مرور و کنارگذاشتن هشدارها چنین مصرفی ندارد. این پیش‌نمایش برای github.com و Enterprise Cloud با اقامت داده ارائه شده و Enterprise Server را پوشش نمی‌دهد. نمایش هشدار مخازن خصوصی به GitHub Code Security نیاز دارد.
تحلیل مستقل IROSG
جابه‌جایی مداوم میان صفحه هشدار و محیط کدنویسی می‌تواند اصلاح امنیتی را به کاری پراکنده تبدیل کند. نزدیک‌شدن این دو بخش از نظر تجربه کاربری مفید است، اما نباید باعث شود مفهوم «اصلاح شد» با «کد پیشنهادی تولید شد» یکی گرفته شود. پیشنهاد تحریریه این است که تیم برای هر هشدار، علاوه بر تغییر کد، شاهدی از رفع مسیر خطا نیز نگه دارد؛ مثلاً تستی که پیش از تغییر شکست می‌خورد و پس از آن موفق می‌شود.
اولویت‌بندی هشدارها بهتر است با زمینه سامانه انجام شود. شدت عمومی یک یافته همه چیز را درباره دسترسی بیرونی، حساسیت داده یا کنترل‌های موجود نمی‌گوید. مسئول بازبینی باید بداند آیا مسیر آسیب‌پذیر در پیکربندی واقعی قابل دسترسی است و آیا اصلاح پیشنهادی رفتار مورد انتظار کاربران را تغییر می‌دهد. این بررسی به‌ویژه برای کنترل دسترسی و اعتبارسنجی ورودی اهمیت دارد؛ جایی که رفع ظاهری هشدار ممکن است قابلیت ضروری برنامه را نیز مختل کند.
یک استفاده مناسب در شروع، انتخاب یک مخزن کم‌ریسک و چند هشدار شناخته‌شده است. اعضای تیم می‌توانند کیفیت توضیح، محدودبودن تغییر و زمان لازم برای تأیید اصلاح را ثبت کنند. اگر ابزار برای حل یک مشکل کوچک فایل‌های نامرتبط را هم تغییر داد، همان اتفاق باید در نتیجه آزمایش دیده شود. صرف کاهش تعداد هشدارهای باز، بدون بررسی دلیل بسته‌شدن آن‌ها، معیار کافی برای موفقیت نیست.
موضوع دسترسی نیز باید در طراحی گردش کار روشن باشد. پیشنهاد ما این است که نقش مشاهده‌کننده هشدار، نویسنده اصلاح و تأییدکننده کنارگذاشتن هشدار از نظر مسئولیت مشخص شوند، حتی اگر یک فرد در تیم کوچک چند نقش داشته باشد. این شفافیت کمک می‌کند تصمیم امنیتی در تاریخچه پروژه قابل پیگیری بماند و انتقال کار میان شیفت‌ها آسان‌تر شود.
در نهایت، نزدیکی ابزار به محل کار توسعه‌دهنده فرصت خوبی برای آموزش است. توضیح یک هشدار می‌تواند به شناخت الگوی خطا کمک کند، به شرط آنکه تیم پاسخ مدل را با کد، تست و مستندات خود تطبیق دهد. نتیجه مطلوب، تنها بسته‌شدن سریع‌تر یک مورد نیست؛ کمترشدن تکرار همان نوع خطا در تغییرهای بعدی است. این بخش تحلیل مستقل IROSG است و ادعای سنجش عملی عملکرد افزونه محسوب نمی‌شود.
ثبت نسخه ابزار و تاریخ آزمون نیز مهم است، چون نتیجه بازبینی باید به شرایط مشخصی قابل نسبت‌دادن باشد و در اجرای بعدی بتوان اختلاف رفتار را توضیح داد.
