Note
Кампании по безопасности в настоящее время находятся в public preview и подвергаются изменению.
Элементы успешной кампании по обеспечению безопасности
Успешные кампании безопасности для устранения оповещений в масштабе имеют множество общих функций, в том числе:
- Выбор связанной группы оповещений системы безопасности для исправления.
- Убедитесь, что менеджер кампании доступен для совместной работы, отзывов и вопросов об исправлениях.
- Предоставление доступа к образовательным сведениям о типе оповещений, включенных в кампанию.
- Предоставление разработчикам доступа к данным GitHub Copilot Chat для получения сведений об уязвимостях, выделенных оповещениями системы безопасности в кампании.
- Определение реалистичного срока для кампании, учитывая количество оповещений, которые вы стремитесь исправить.
- Публикуйте совместную работу в командах разработчиков и определите лучший способ их привлечения для вашей организации.
Сведения о интерфейсе разработчика см. в разделе Устранение оповещений в кампании безопасности.
Выбор оповещений системы безопасности для исправления
Ваше первое мнение может быть определение всех наиболее срочных оповещений и создание кампании безопасности для их устранения. Если у разработчиков уже есть хорошее представление о безопасном коде и стремится устранить потенциальные уязвимости, это может быть успешным подходом для вашей компании. Тем не менее, если вам нужно создать знания о безопасном кодировании и распространенных уязвимостях, вы сможете воспользоваться более государственным подходом.
Например, если у вас много оповещений об уязвимостях межсайтовых сценариев, можно:
- Создание учебного содержимого для разработчиков в репозитории с помощью ресурсов из OWASP Foundation см. в разделе "Межсайтовые скрипты" (XSS).
- Создайте кампанию для исправления всех оповещений для этой уязвимости, включая ссылку на образовательный контент в описании кампании.
- Провести обучающий сеанс или другое событие, чтобы подчеркнуть эту возможность, чтобы получить уверенность в безопасном коде при исправлении реальных ошибок.
- Убедитесь, что участник группы безопасности, назначенный для управления кампанией, доступен для проверки запросов на вытягивание, созданных для исправления оповещений кампании, совместной работы по мере необходимости.
Шаблоны фильтров кампании
При выборе оповещений для включения в кампанию безопасности можно использовать любой из фильтров на странице оповещений системы безопасности для определения подмножества оповещений. Кроме того, можно выбрать шаблон кампании для использования одного из предварительно определенных фильтров для распространенных потребностей, например "Межсайтовые скрипты (CWE-79)."
Ограничения для кампаний безопасности
Следующие ограничения предназначены для поощрения сбалансированного и измеряемого подхода к исправлению оповещений в коде. Итеративный подход, направленный на несколько целевых наборов оповещений за раз, скорее всего, приведет к устойчивому и долгосрочному изменению состояния безопасности.
- Не более 10 активных кампаний безопасности за раз (без ограничений на закрытые кампании).
- Каждая кампания может содержать до 1000 оповещений, распределенных по 100 репозиториям.
Если вы решили создать кампанию, которая превышает эти ограничения, оповещения будут оповещены, чтобы привести кампанию в соответствие с ограничениями. Оповещения в репозиториях с последними push-уведомлениями приоритетны для включения в кампанию.
Определение роли руководителя кампании
При создании кампании безопасности необходимо выбрать диспетчер кампании. Менеджер кампании должен иметь роль владелец организации или диспетчера безопасности.
Имя руководителя кампании видно разработчикам, когда они принимают участие в кампании. Если вы хотите увеличить частоту исправления оповещений и масштабировать знания команды безопасности, это ключевая возможность для создания отношений совместной работы с разработчиками. В идеале менеджер кампании доступен для ответа на вопросы, совместной работы над сложными исправлениями и просмотра запросов на вытягивание исправлений в течение всей кампании.
Объединение обучения безопасности с кампанией безопасности
Если ваша команда безопасности уже предоставляет подготовку разработчиков по безопасному кодированию, создание кампании с оповещениями, выбранными для того, чтобы разработчики могли использовать навыки из учебного сеанса , это отличный способ укрепить свое обучение. Даже если у вас нет официальной программы обучения, имеет смысл предоставить информацию о типах уязвимостей безопасности, включенных в кампанию, примеры того, как их исправить, и как протестировать исправления. Это упрощает роль руководителя кампании, так как они смогут направлять разработчиков к этим ресурсам для ответов на основные вопросы.
Фонд OWASP предоставляет множество ресурсов для изучения наиболее распространенных уязвимостей и MITRE Corporation поддерживает подробный список распространенных слабых мест, см. статью "О фонде OWASP" и "О CWE".
Предоставление поддержки искусственного интеллекта для изучения уязвимостей безопасности
GitHub Copilot Autofix автоматически активируется для предложения разрешения для каждого оповещения системы безопасности. Однако разработчики часто хотят получить дополнительные сведения о том, почему исходный код незащищен и как проверить правильность исправления и не прерывать другие компоненты.
GitHub Copilot — это важное средство для разработчиков, которые имеют вопросы о безопасном кодировании, устранении оповещений системы безопасности и тестировании их исправления. Убедитесь, что у всех разработчиков в организации есть доступ к Copilot в интегрированной среде разработки и GitHub, см . раздел AUTOTITLE.
Tip
Навык GitHub Advanced Security предоставляет Copilot Chat с дополнительным контекстом для ответа на вопросы о оповещениях системы безопасности.
Рекомендации по запуску кампании безопасности и определению крайнего срока
Как и в любом другом проекте, важно определить реалистичные шкалы времени, чтобы избежать отказа разработчиков от участия в кампании безопасности. Если ваша компания не исправляет оповещения системы безопасности в рамках более крупной кампании по сокращению технического долга, большинство разработчиков не будут иметь времени, выделенного для устранения оповещений. Необходимо оценить ставки исправления на основе времени, когда разработчики могут находить между запланированными задачами. Кроме того, всегда стоит проверить ключевые сроки компании, которые разработчики могут работать над и проверять национальные праздники.