{"meta":{"title":"Проведение кампании по безопасности по исправлению оповещений в масштабах","intro":"Запустите целенаправленную кампанию по безопасности для устранения определённого класса оповещений, таких как кросс-сайтовое скриптирование (XSS), по всей вашей организации.","product":"Безопасность и качество кода","breadcrumbs":[{"href":"/ru/code-security","title":"Безопасность и качество кода"},{"href":"/ru/code-security/tutorials","title":"Tutorials"},{"href":"/ru/code-security/tutorials/secure-your-organization","title":"Защита организации"},{"href":"/ru/code-security/tutorials/secure-your-organization/best-practice-fix-alerts-at-scale","title":"Исправление оповещений в масштабе"}],"documentType":"article"},"body":"# Проведение кампании по безопасности по исправлению оповещений в масштабах\n\nЗапустите целенаправленную кампанию по безопасности для устранения определённого класса оповещений, таких как кросс-сайтовое скриптирование (XSS), по всей вашей организации.\n\n## Запуск вашей первой кампании\n\nВ этом туториале вы планируете и проведёте свою первую кампанию по безопасности на уровне всей организации, сосредоточенную на оповещениях XSS. По ходу дела вы научитесь выбирать правильные оповещения, готовить разработчиков к успеху и строить кампанию, способствующую значимому улучшению вашей безопасности.\n\nПредставьте, что вы обнаружили повторяющуюся закономерность уязвимостей XSS в нескольких репозиториях. Вместо того чтобы решать оповещения по одному, вы решаете провести скоординированную кампанию, которая снижает риски и помогает разработчикам обрести уверенность в безопасном коде.\n\n## 1. Определите сфокусированную цель\n\nПри проведении кампании в масштабах возникает соблазн нацеливаться на все срочные оповещения сразу. Если у ваших разработчиков уже есть прочная база в защищённом кодировании и доступных возможностях, это может сработать.\n\nОднако если ваша цель — снизить риски и улучшить безопасные практики кодирования, целенаправленная кампания часто оказывается более эффективной. Выбор одного типа уязвимости, например кросс-сайтовое скриптинг, позволяет разработчикам распознавать шаблоны, применять обучение для нескольких исправлений и набирать импульс.\n\nВ этой кампании вы решаете сосредоточиться на XSS-оповещениях по всей вашей организации, в пределах количества оповещений в одной кампании.\n\n## 2. Выберите оповещения для вашей кампании\n\nНа странице оповещений о безопасности начните с фильтрации на наличие оповещений о скриптах между сайтами. Вы также можете использовать заранее заданный шаблон кампании, например **Cross-site scripting (CWE-79**), чтобы быстро определить область действия. Для информации о фильтрационных уведомлениях см. [Обзор фильтрации оповещений в области безопасности](/ru/code-security/how-tos/manage-security-alerts/remediate-alerts-at-scale/filtering-alerts-in-security-overview).\n\n> \\[!NOTE]\n> Кампании безопасности могут включать до 1000 оповещений. Если в вашей организации более 1000 XSS-оповещений, сузьте фильтры (например, по репозиторию, степени тяжести или языку), пока количество совпадающих оповещений не достигнет этого лимита, либо запланируйте несколько кампаний, чтобы охватить оставшиеся оповещения.\n\nЕсли Автофикс второго пилота доступен для вашей кампании, вы можете дополнительно уточнить область действия, используя фильтр `autofix:supported` . Это позволяет разработчикам использовать предложения исправлений, генерируемые ИИ, для более эффективной обработки оповещений.\n\nПеред запуском кампании вы также готовите поддерживающие образовательные материалы. Рассмотрим пример.\n\n* Создайте репозиторий с рекомендациями по предотвращению уязвимостей XSS.\n* Ссылка на ресурсы Фонда OWASP, такие как [Cross Site Scripting (XSS).](https://owasp.org/www-community/attacks/xss/)\n* Приведите примеры безопасных шаблонов кодирования и подходов к тестированию.\n\nВы будете включать ссылки на эти ресурсы в описание кампании, чтобы разработчики могли обращаться к ним по мере работы с назначенными оповещениями.\n\n## 3. Назначьте менеджеров кампаний и определите каналы коммуникации\n\nПеред запуском кампании решите, кто будет поддерживать разработчиков на протяжении всего процесса исправления.\n\nПри создании кампании безопасности необходимо назначить одного или нескольких **менеджеров кампаний**. Менеджеры кампаний должны быть:\n\n* Пользователь с ролью владельца организации или менеджера по безопасности, или\n* Член команды с одной из таких ролей\n\nВыбирайте менеджеров, которые могут:\n\n* Ответьте на вопросы о уязвимостях XSS\n* Проверьте pull requests на поиск исправлений\n* Помощь в разрешении крайних случаев или сложных сценариев устранения\n\nПоскольку менеджеры кампаний видны разработчикам, участвующим в кампании, это также возможность установить чёткую коммуникацию. При создании кампании включите контактную ссылку, например, ссылку на thread GitHub Discussions или другой канал коммуникации, чтобы разработчики знали, куда задавать вопросы.\n\nЗаранее устанавливая ожидания и делая поддержку видимой, вы повышаете доверие и повышаете показатели исправления.\n\n## 4. Создайте и опубликуйте кампанию\n\nТеперь вы готовы создать кампанию.\n\nПри определении кампании:\n\n* Используйте фильтр или шаблон XSS для выбора оповещений.\n* Добавьте чёткое описание цели кампании.\n* Включите ссылки на учебные материалы, которые вы подготовили ранее.\n* Установите реалистичную дату сдачи на основе количества уведомлений и ожидаемой возможности по устранению.\n\nЕсли вы не уверены в масштабе, сначала создайте **черновик кампании** . Черновик позволяет просмотреть включенные оповещения и сотрудничать внутри перед публикацией.\n\n## 5. Включите отслеживание проблем для повышения видимости\n\nЧтобы помочь разработчикам отслеживать свою работу и предоставить менеджерам видимость, вы можете выбрать автоматическое создание проблемы в каждом репозитории, включённом в кампанию. Это позволяет разработчикам управлять своими работами по устранению в рамках существующих рабочих процессов и проектных плат.\n\nПри включении создания выпуска в раздел задачи автоматически включаются «Краткое описание», «Контактная ссылка» и дата окончания кампании. Если вы обновите краткое описание, контактную ссылку или дату сдачи, эти изменения отражаются в выпусках. Кроме того, когда кампания достигает срока сдачи или закрывается, по каждому выпуску публикуется комментарий для уведомления разработчиков. Такая интеграция помогает поддерживать чёткую коммуникацию и поддерживать организацию кампании в нескольких репозиториях.\n\n## 6. Поддержка разработчиков во время устранения\n\nКогда кампания запускается, ваша роль меняется от организатора к стороннику. Разработчики начнут проверять и исправлять XSS-оповещения в своих репозиториях. Чтобы помочь им действовать эффективно и уверенно:\n\n* Убедитесь, что менеджеры кампаний готовы проверять pull requests и отвечать на вопросы.\n* Поощряйте разработчиков использовать Копилот Чат, чтобы лучше понять, почему код уязвим и как проверить их исправления.\n* Если поддерживается, поощряйте разработчиков рассматривать и тестировать предложения Автофикс второго пилота перед объединением изменений.\n\nЕсли вы подготовили образовательные материалы заранее, ссылайтесь на них в обсуждениях и отзывах по pull request. Укрепление совместного руководства снижает повторяющиеся вопросы и помогает выработать долгосрочные безопасные привычки в программировании.\n\nОставаясь заметным и отзывчивым во время кампании, вы подтверждаете, что это совместная работа, а не просто соблюдение требований.\n\n## 7. Установите реалистичный срок\n\nВы устанавливаете срок при создании кампании. По мере развития кампании убедитесь, что сроки остаются достижимыми.\n\nПри установлении или корректировке срока учитывайте:\n\n* Количество предупреждений, включённых в кампанию\n* Ожидаемая способность разработчиков по устранению (например, сколько времени они могут потратить на исправление оповещений наряду с обычной работой)\n* Любые предстоящие дедлайны или праздники компании, которые могут повлиять на доступность\n\nЕсли устранение оповещений не является специализированной инициативой, большинство разработчиков будут совмещать эту работу с разработкой функций. Установление реалистичных сроков увеличивает участие и предотвращает разочарование.\n\nПри необходимости можно запускать несколько специализированных кампаний, а не пытаться одновременно справляться со всеми типами оповещений.\n\n## 8. Закройте кампанию и повторяйте\n\nПо мере приближения дедлайна следите за прогрессом и сотрудничайте над оставшимися сложными исправлениями.\n\nКогда кампания заканчивается:\n\n* Проблемы с репозиторием обновляются автоматически.\n* Разработчики устранили целый набор уязвимостей.\n* Ваша организация снизила риски измеримым образом.\n\nСамое главное — разработчики получили практический опыт в распознавании и исправлении определённого класса уязвимости.\n\nДалее вы можете повторить процесс с помощью другого целевого набора оповещений, таких как SQL-инъекция, небезопасная десериализация или раскрытие секретов, чтобы постепенно улучшать уровень безопасности вашей организации со временем.\n\n## Дальнейшие шаги\n\nГотовы запустить свою кампанию? Чтобы создать и управлять вашей кампанией безопасности, смотрите [Создание кампаний безопасности и управление ими](/ru/code-security/securing-your-organization/fixing-security-alerts-at-scale/creating-managing-security-campaigns)."}